RE: SAML 2.0 Optional Use Cases

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

Title: RE: SAML 2.0 Optional Use Cases

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