[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]