[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: SAML 2.0 Optional Use Cases
+1 to Greg's comment User accounts: here's a simpler alternative on the user account naming... If every system creates N user accounts for each vendor and each vendor uses only the users assigned to them, they can federate/defederate without fear of interfering. So every system would define, say 5 accounts for each vendor to use. So every system would have rsaUser1 through rsaUser5, hpUser1-5, caUser1-5, neteUser1-5, entrustUser1-5, and so on. When a NETE person wants to demo, they always log in at any system using the neteUser<n> accounts, which they can federate/defederate to their hearts content. When an RSA person wants to demo, they always use the rsaUser<n> accounts. This presumes, of course, that a single account on every vendor's system can handle federations in both directions (which they should). I think I've walked back through the possible cases and this works. It's probably the simplest approach. My previous recommendation attempted to embed in the login name an indicator that the account was located on a particular system. But this really isn't necessary. For example, I can log in as rsaUser1 at any IDP and ask to federate with rsaUser2 at the NETE SP and rsaUser5 at the HP SP, and rsaUser1 at the CA SP. And re: Attributes... For Attributes, I recommend that we stick to, say, 3 of them (4 if you twist my arm) and also just stick with string types. In the past, common name, email address, and membership level were quite sufficient to meet the needs of the demo. The point of the attributes (I think) is to provide simple personalization of the target resource content (sample application) based on the attributes retrieved from the IDP. 3 should be plenty for that purpose. Again, don't overestimate the amount of time a visitor will sit there and want to play with a fancy demo. You really won't have that much time, and again, the point is to talk about SAML 2.0 and interoperability, not the fancy demo. Rob Philpott Senior Consulting Engineer RSA Security Inc. Tel: 781-515-7115 Mobile: 617-510-0893 Fax: 781-515-7020 mailto:rphilpott@rsasecurity.com > -----Original Message----- > From: Greg Whitehead [mailto:grw@trustgenix.com] > Sent: Tuesday, January 11, 2005 11:01 PM > To: Philpott, Robert > Cc: Thomas Wisniewski; Yuzo Koga; Mark Joynes; samldemotech > Subject: Re: SAML 2.0 Optional Use Cases > > My 2c on this thread: > > We want to spend our time with people talking about SAML and our > products, not trying to run / explain complicated demos. In my > experience manning booths at trade shows, most people don't want to > spend a lot of time messing around with demos anyway. They assume the > technology works and are more interested in understanding how it can be > used to solve their particular problem. A demo can be a useful tool for > explaining how technology works, but only if it doesn't distract the > viewer with irrelevant details. The scenario should be instantly > understandable without a lot of explanation, and should achieve a > balance between engaging and boring that allows people to focus on how > it works not what it does. > > I guess what I'm trying to say is that it's very easy to make a demo > too complicated to be useful for it's intended purpose. I think we'd be > much better served with a simple demo using fixed accounts and fixed > attributes, as we've done in the past, where we can focus on the > underlying technology and not running of the demo. If we have a > standard flow that we can operate with minimal keyboarding or > attention, we'll be able to spend a lot more time explaining the > underlying technology! > > -Greg > > > On Jan 11, 2005, at 9:14 PM, Philpott, Robert wrote: > > > Except that some products may not permit a wildcard query (i.e. no > > attribute(s) listed in the query). It's legal by SAML rules to reject > > such requests if local policy precludes wildcard attributes. If > > products only support this policy, then they are stuck. > > > > Rob Philpott > > Senior Consulting Engineer > > RSA Security Inc. > > Tel: 781-515-7115 > > Mobile: 617-510-0893 > > Fax: 781-515-7020 > > mailto:rphilpott@rsasecurity.com > > > >> -----Original Message----- > >> From: Yuzo Koga [mailto:koga.yuzo@lab.ntt.co.jp] > >> Sent: Tuesday, January 11, 2005 9:51 PM > >> To: Thomas Wisniewski > >> Cc: Mark Joynes; samldemotech > >> 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]