Re: SAML 2.0 Optional Use Cases

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

I agree with you.  If we can prepare such things,
the demo will be very flexible and attractive.

However, with regard to exchanging attributes between
providers, I think we need to previously know what kind of
attributes, and with what name, are exhanged.

I think we need a concrete scenario for it.
Or, we should decide at the F2F dry-run event at GSA?

Yuzo

On 2005/01/11, at 21:20, Thomas Wisniewski wrote:

> Hey Yuzo.
>
> I was initially proposing a more advanced scenario where the user can 
> create their own id (username) and respective values and also update 
> these values. The updating of these values is something that isn't 
> absolutely necessary, however, without the user being able to create 
> their own id we could run into race conditions if multiple folks at 
> the conference are manipulating the same "sample" identifier. I.e., 
> someone is doing SSO as alice while someone else is in the process of 
> terminating the ID federation of alice.
>
> Thoughts?
>
> Tom.
>
> -----Original Message-----
> From: Yuzo Koga [mailto:koga.yuzo@lab.ntt.co.jp]
> Sent: Tuesday, January 11, 2005 6:13 AM
> To: Thomas Wisniewski
> Cc: Mark Joynes; samldemotech
> Subject: Re: SAML 2.0 Optional Use Cases
>
>
>
> 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
>
----
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