Appendix A - Agency Use Cases and Usage Patterns

The following draft use cases and usage patterns were used in preparing this Standard. They are for example purposes only and not necessarily the final definitive, confirmed requirements of the contributors.

The purpose of showing the draft use cases here is to indicate to readers the basis on which the selected applicable OASIS SAML v2.0 Profiles were derived.

They are informative and may be omitted from the final release of this Standard.

A1 Education sector ESAA project: GLS key – redirect->artifact binding

The (IdP Proxy) scenario in the following figure, Figure A1, demonstrates how the ESAA and GLS components might interact when a service user authenticates with a GLS provided key in order to access an agency application. In this case the Redirect->Artifact binding has been used because the attribute information being supplied is large in size and better performed via a direct connection as opposed to being packaged in an HTML FORM.

Variations of this scenario include:

• Authentication with an ESAA supplied key
• Authentication with other key types (e.g. client certificate).

Figure A1 provides a diagrammatic representation of the messages, together with a description of each message step.

Figure A1 – ESAA use case

NOTE – The message flows are as follows:

1. The service user attempts to access a resource on www.agency.govt.nz. The service user does not have any current logon session (i.e. Security Context) on this site (application) and is unknown to it.
2. The Access Check component sends a Web Service request to the Session Manager to determine whether the service user has any current security context within the Authentication Service www.esaa.govt.nz. The XML packet contains SAML assertions for the Session manager to interpret.
3. The session manager sends a response back to the access check with the status of the service user’s current security context.
4. Assuming no authentication exists the application sends a redirect message to the browser with HTTP status code of either 302 or 303. The Location HTTP header contains the destination URI of the Government Logon Service (GLS) together with the <AuthnRequest> as a query variable named SAMLRequest. The query string is encoded using the DEFLATE encoding. The browser processes the redirect message and issues a GET request to the Session Manager with the SAMLrequest query parameter.
5. The GLS sends an HTML logon form to the browser.
6. The service user provides valid credentials in the form of u sername and p assword.
7. The GLS generates an assertion for the service user while also creating an artifact. The artifact contains the source ID of the GLS SAML responder together with a reference to the assertion (the MessageHandle ). The Service will then redirect the browser to the Session Manager component of the Authentication Service ( www.esaa.govt.nz ).
   The browser, either due to a service user action or via an “Auto-submit”, issues a HTTP POST containing the SAML response to be sent to the Session Manager.
   On receiving the HTTP message, the Session Manager, extracts the SourceID from the SAML artifact and hands control to the GLS Connector.
8. The GLS Connector will send a SAML <ArtifactResolve> message to GLS SAML responder containing the artifact supplied by the GLS.
9. The GLS SAML responder supplies back a SAML <ArtifactResponse> message containing the assertion previously generated.
10. The Assertion Producer locates attributes from IAM Directory Store. These attributes may be different depending on the application that is requesting authentication. The Session Manager Service will package the attributes as SAML Assertions along with the assertions from GLS.
    The assertions will be retained locally with a handle created for future reference.
11. The Session Manager Service sends a HTML FORM back to the browser. The HTML FORM contains a SAML response in form of SAMLart, within which is a handle to the SAML assertion (created at step 10).
    NOTE – The SAML Specifications mandate that the response must be digitally-signed .
    Typically the HTML FORM will contain an input or submit action that will result in a HTTP POST.
12. The Access Check validates the digital signature of the SAML Response, queries the assertion handle from the response and passes control to the Assertion Consumer, with the handle.
13. The assertion consumer will send a SAML <ArtifactResolve> message to the Authentication Service containing the handle to the assertion (provided at step 8).
    The information about who the assertion consumer communicates with has been previously setup within configuration information of the Authentication Connector i.e. it is not dynamic based on some response.
14. The Authentication Service then sends back a SAML <ArtifactRepsonse> message containing the assertion previously generated at step 10. Once a successful response is received the service user is considered authenticated and an application session can be created.
15. The Access Check then sends a HTTP redirect to the browser causing it to access the TARGET resource, with a cookie that identifies the local session.
    The access check is then made to establish whether the service user has the correct authorisation to access the site www.agency.govt.nz and the TARGET resource.
    The TARGET resource is then returned to the browser.

A2 IRD e-enablement project: registering a new service user authenticated previously at another SAML entity.

Figure A2 is the use case supplied to the Secure Messaging working group where a resource provided by an SP requires authentication of/use of the service user’s identity attributes to complete the registration/resource access process. The use case would have required the need for the service user to authenticate twice; once to authenticate themselves at the SP, and again to the SAML entity storing his/her identity attributes. The use case assumes that SP is a party to the all-of government authentication programme and therefore in both cases, authentication is carried out centrally by the GLS.

The Secure Messaging working group considered the use case and proposed that the use of the Name Identifier Mapping Profile would, subject to the service user’s agreement and previous authentication at the SAML entity, allow the SP to fetch identity attributes that have been stored at another SAML entity to complete his/her registration for a new service, thereby removing the need to authenticate again at the SAML entity.

Figure A2 follows.

Figure A2 – IRD e-enablement Project: registering a new service user authenticated previously at another SAML entity.

A3 MAF SSO scenario 2 – shared transactions

Figure A3 reflects a use case encompassing the concepts of authorisation and identity, as well as authentication, in access to and delivery of online transactions, where more than one agency is party to a transaction. Due to the very formative stage of this use case, together with the technical and legislative implications, meant that no formalised solution mapped to a SAML profile was developed for this use case. Nevertheless, this use case did assist the working group in clarifying issues with other use cases.

Figure A3 follows.

Figure A3 – MAF SSO scenario 2 – shared transactions

A4 All-of-government authentication: user authentication at the GLS

This use case is derived from internal sources at the Sate Services Commission where the terminology differs from that used externally. The acronyms SLI or SLII mean Shared Logon (Initial) Implementation and are generally referred to externally, by the State Services Commission, as the GLS. The acronym SA means Service Agency, referred to in SAML terminology as Service Provider (SP).

Figure A4 below is a summary of the SLI message exchanges when a service user authenticates. The messages shown in are divided into two classes:

1. Messages 1 and 7 are internal to the SA; as such this document gives only a description of these messages. Each SA is free to implement these messages as it sees fit.
2. The other messages are defined by SLI and the descriptions of these messages contained in this document should be taken as prescriptive.

Figure A4 – Overview of messaging

A significant concern for each message described is security. Each carries sensitive information across a network, frequently over the Internet. This makes each message a candidate for attack by a malicious third party. For this reason, special attention is paid to message security.