Re: SAML 2.0 Optional Use Cases

[Yuzo Koga <koga.yuzo@lab.ntt.co.jp>]

Hello Tom, all,

Let me clarify.

According to the A, an account at IDP has following attributes,
correct?

  - username
  - password
  - common name
  - email address
  - membership level
  - spending limit
  - age
  - shoe size

And, IDP can set any values (i.e. a user don't set values)
to the common name, email address, and membership level,
correct?

Yuzo

On 2005/01/10, at 23:18, Thomas Wisniewski wrote:

> 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>
>
>
----
Yuzo KOGA <koga.yuzo@lab.ntt.co.jp>
NTT Information Sharing Platform Labs.
tel: +81 422 59 3202, fax: +81 422 59 5652, aol: yzkoga