Appendix A - Agency Use Cases and Usage Patterns

[ Table of Contents ]

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 Education Sector Authentication and Authorisation (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)
• Cross domain single sign-on across multiple education sector applications. (See Appendix E for 'Issues for the Future').

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

Figure A1 – ESAA use case (Functional Model)

Figure A2 – Interaction Model for ESAA usage of SAML v2.0

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).
2. The Access Check 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 Authentication Service (ESAA) together with the <AuthnRequest>.
3. Assuming no authentication session exists within the ESAA Authentication Service Session Manager, 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>.
4. The GLS sends an HTML logon form to the browser.
5. The user provides valid credentials in the form of username and password (or other acceptable credentials).
6. 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. 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.
7. The GLS Connector will send a SAML <ArtifactResolve> message to the GLS SAML responder containing the artifact supplied by the GLS.
8. The GLS SAML responder supplies back a SAML <ArtifactResponse> message containing the assertion previously generated.
9. 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, adding any attributes mapped from the assertions provided by GLS (for example the authentication strength). The assertions will be retained locally with a handle created for future reference.
10. 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 9).
    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 an HTTP POST.
11. 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.
12. 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 the configuration information of the Authentication Connector. It is not dynamic based on some response.
13. The Authentication Service then sends back a SAML <ArtifactResponse> 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.
14. 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 Generic example of a user obtaining an assertion of identity

Figure A3 is derived from the IRD use case where a resource provided by an SP requires authentication of/use of the service user's identity attributes to complete the registration process. It reflects the generic use case for enabling a user to assert their identity to a service agency. The use case was supplied by the IVS programme to the Secure Messaging Working Group. When the service user attempts to access a service within the service agency which requires additional identity information, the service user is instructed that they are required to verify their identity using igovt.

The service agency redirects the service user to igovt (IVS) and requests an identity assertion. In order to verify their identity the service user must first successfully authenticate to the IVS using the GLS (refer GLS use case in Appendix A4). An assertion of identity is only provided to the service agency when the service user gives their consent to the IVS.

This use case was considered by the IVS programme in discussion with NZ SAMS and prototyped using SAML AuthnRequests and Responses.

Figure A3 – Assert Identity (Functional Model)

Figure A4 – Generic example of a user obtaining an assertion of identity (Interaction Model)

A3 MAF SSO scenario 2 – shared transactions

Figure A5 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, no formalised solution mapped to a SAML profile has been developed for this use case. Nevertheless, this use case did assist the Working Group in clarifying issues with other use cases.

Figure A5 follows.

Figure A5 – MAF SSO scenario 2 – shared transactions (Functional Model)

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

This use case is derived from internal sources at the State 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 by the State Services Commission (externally), as the GLS. The acronym SA means Service Agency, referred to in SAML terminology as service provider(SP).

Figure A6 below is a summary of the SLI message exchanges when a service user authenticates. The messages shown in Figure A6 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 A6 – Overview of messaging (Functional Model)

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.

Figure A7 – GLS SAML v1.1 implementation (Interaction Model)

[ Previous | Contents | Next ]