SAML 2.0 Optional Use Cases

[Thomas Wisniewski <Thomas.Wisniewski@entrust.com>]

Title: SAML 2.0 Optional Use Cases

Hi, for those vendors considering the optional use cases (around persistent identifiers and attribute queries), I would like to propose the following use cases. It would require each vendor to support 4 simple resources/applications.

A. User registration. Allow the user to perform a simple online registration to an SP or IDP (no SAML processing exists in this case). User is allowed specifies the following fields:

- username
- password
- password (again)
// the remaining attributes are only for IDPs:
- spending limit
- age
- shoe size (or any other attribute(s) that we should decide on)

B Local user attribute management. This is a protected application that is avaliable to the user once they have logged into an IDP. This allows the user to see their local attributes described in (A). I.e., at the provider they logged into (no SAML processing exists in this case).

C. User persistent Identifier management. This is a protected application that is avaliable to the user once they have logged into a provider. It allows them to view their current ID federations and either TERMINATE and existing one or FEDERATE to a new IDP. The respective SAML MNI terminate or SAML SSO with ID Federation AllowCreate=true would occur.

NOTE: we should discuss is a 3rd option NEW_ID (or REFRESH) should be included. This is allows and IDP or SP to change the opaque id (e.g., the user wants their opaque id changed for security purposes).

D. User SAML attribute inquiry. This is a protected application that is avaliable to the user once they have logged into a provider AND they used SAML authentication to some IDP. If so, it should display the attributes described in (A) by doing a SAML Attribute Query to the IDP (the assumption is that the IDP is also acting as the Attribute Authority).

Use Cases:

1. User Registration. The user registers at both the IDP and SP (i.e., application A above). The main point is that they can use different ids at the SP and IDP site.

2. User Federation. The user logs into an SP and selects ID Federation with an IDP (i.e., application C above). The flows are similar to the basic SSL case but with ID federation and using persistent identifiers.

3. Single Logout. The user logs out of the SP. The flow follows that of the basic case.

4. Single Signon. The user, after logging out of the SP, uses SAML SSO to log back into the SP. The flow follows that of the basic case.

5. Attribute Query. From the SP site the user logged into, they view their IDP attributes that they set at the IDP. A SAML Attribute Query is performed by the SP to the IDP (application D above).

6. Change IDP Attributes. The User may be allowed to go to the IDP site and change their attributes (i.e., application B above executed at the IDP). After updating these attributes, the user (without any need to re-login) can go back to the link in step 5 and see their attributes have been updated from the SPs perspective as well.

7. User Defederation. The user selects ID Defederation with an IDP (i.e., application C above). Either HTTP-Redirects or SOAP can be used to accomplish this.

Do this sound reasonable? It would seem to capture the essense of SAML id federation/defederation and the dynamics or SAML attributes.

Tom.

Thomas Wisniewski
Software Architect
Phone: (201) 891-0524
Cell: (201) 248-3668
 
Entrust
Securing Digital Identities
& Information
<http://www.entrust.com>