Cookie-based SSO

Given that a service is allowed to use SSO, and the user does not actively disallow the use of SSO when logging on, each successful authentication attempt will result in a SSO cookie being set by Moria2 in the user's browser. This cookie will contain a unique session ticket referring to the existing SSO session, which will linger for a Moria2-configured time following initial authentication. Note that depending on the Moria2 administrator's choice of configuration, the cookie may or may not be persistent.

Thus, the next time the service (or any SSO-enabled service) requests authentication, the user's SSO cookie will allow the user to skip the login process. The service may override this and insist on reauthentication if need be.

Each user attribute the service is allowed to read is marked as being SSO enabled or disabled. If a service requests one or more SSO disabled attributes, the user will have to log on again. This is true even if the user has a valid SSO cookie.

The actual steps involved in cookie-based SSO are identical to those for the interactive authentication.

Ticket-based SSO

Ticket-based SSO requires that a service profile contains one or more subservices. A subservice is a regular service profile, with one exception; the parent service may perform authentication on behalf of its subservices, letting the subservices read user attributes through proxy authentication without requiring another round of interactive authentication.

If the service profile allows a service to use ticket-based SSO, the service may request an attribute tgt along with the ordinary user attributes. The tgt attribute, or ticket granting ticket, is used to issue a proxy ticket to a subservice. This approach is particularly useful for web portals.

Note that Moria does not offer a mechanism for transferring proxy tickets to subservices. However, it is strongly suggested that this should be done in a way as not to compromise security. A proxy ticket can only be used by the subservice it was issued to.

The subservice may use a proxy ticket to verify the earlier authentication, and to request necessary attributes on its own behalf.

The initial steps of ticket-based SSO are identical to those for the interactive authentication, with one exception; the service also requests (and receives) the attribute tgt.

After this is completed, the following steps take place.

1. The service requests a proxy ticket for a subservice, using its tgt. Note that the tgt may be used several times, as long as the SSO session it belongs to does not exceed the Moria2-configured session lifetime.

   Method used by service: getProxyTicket (JavaDoc, SOAP Example, Java/Axis Example)

2. Moria2 responds with a proxy ticket, issued for the given subservice.

3. The service hands over the proxy ticket to the subservice. How this is to be done is not specified by Moria2.

4. The subservice uses the proxy ticket to check the earlier authentication performed by the parent service, optionally including its own request for user attributes. Note that the proxy ticket can only be used once.

   Method used by subservice: proxyAuthentication (JavaDoc, SOAP Example, Java/Axis Example)

5. If the proxy ticket can be matched to a previously authenticated user, Moria2 will return the requested attributes.

The subservice will only need to perform one SOAP call in order to accomplish this.