OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

samldemotech message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: SAML 2.0 Optional Use Cases


> For simplicity, we could assume that any AttributeQuery should not 
> contain an <Attribute> element, implying that all attributes are 
> returned by the IDP each time. Sound reasonable?

In order to cope with various scenarios for AttributeQuery,
I think it's reasonable.  All the IDP have to do is
to respond all the attributes associating with the specified
Subject :)  And, how to show/use the attributes that SP gets
from IDP depends on SP side.  It's reasonable for demo.

Yuzo

On 2005/01/11, at 23:25, Thomas Wisniewski wrote:

> Yuzo. Exactly. I think we can definitely resolve which attributes 
> prior to the dry-run. For starters we have the following (note that 
> the first 2 are NOT meant to be exchanged but are there for login 
> purposes to the respective provider):
>
> >   - username
> >   - password
>
> >   - common name (e.g., john smith, type string)
> >   - email address (e.g., jsmith@company.com, type string)
> >   - membership level (e.g., gold, type string)
> >   - spending limit (e.g., 2500, type int)
> >   - age (e.g., 31, type int)
> >   - shoe size (e.g., 10.5, type string)
>
> The attribute profile would be basic and the data types would be only 
> string or int.
>
> For simplicity, we could assume that any AttributeQuery should not 
> contain an <Attribute> element, implying that all attributes are 
> returned by the IDP each time. Sound reasonable?
>
> Here's the example <AttributeStatement> that should be returned based 
> on the attributes above.
>
> <saml:AttributeStatement>
> <saml:Attribute
>    NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic"
>   Name="CommonName">
>   <saml:AttributeValue xsi:type="xs:string">john 
> smith</saml:AttributeValue>
> </saml:Attribute>
> <saml:Attribute
>    NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic"
>   Name="EmailAddress">
>   <saml:AttributeValue 
> xsi:type="xs:string">jsmith@company.com</saml:AttributeValue>
> </saml:Attribute><saml:Attribute
>    NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic"
>   Name="MembershipLevel">
>   <saml:AttributeValue xsi:type="xs:string">gold</saml:AttributeValue>
> </saml:Attribute>
> <saml:Attribute
>    NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic"
>   Name="SpendingLimit">
>   <saml:AttributeValue xsi:type="xs:int">2500</saml:AttributeValue>
> </saml:Attribute>
> <saml:Attribute
>    NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic"
>   Name="Age">
>   <saml:AttributeValue xsi:type="xs:int">31</saml:AttributeValue>
> </saml:Attribute>
> <saml:Attribute
>    NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic"
>   Name="ShoeSize">
>   <saml:AttributeValue xsi:type="xs:string">10.5</saml:AttributeValue>
> </saml:Attribute>
> </saml:AttributeStatement>
>
> Tom.
>
> -----Original Message-----
> From: Yuzo Koga [mailto:koga.yuzo@lab.ntt.co.jp]
> Sent: Tuesday, January 11, 2005 8:04 AM
> To: Thomas Wisniewski
> Cc: Mark Joynes; samldemotech
> Subject: Re: SAML 2.0 Optional Use Cases
>
>
>
> 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
>
----
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



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]