Title: RE: SAML 2.0 Optional Use Cases
I don't believe showing the federation process (step
1) or defederation process (step 6) adds to the customer
experience. As someone noted earlier, typing in data
detracts from the demo.
Perhaps we could have a user from each vendor who wants to
do the advanced cases already federated on a single idP. Each
participating vendor would supply an SP. When the person goes to the first
SP, they go through the normal login step, and the SP page shows something like
"Welcome Vendor1User1". They click on a link to a second SP, and without
logging in get the second SP page with something like "Welcome
Vendor2User1". We could have additional users set aside in case some
customer really wants to see the whole thing working from start to finish, but I
think just describing it to most would suffice.
Opinions?
Bob
From: Thomas Wisniewski
[mailto:]
Sent: Wednesday, January 12,
2005 8:40 AM
To: Dave Silver; Greg Whitehead; Philpott,
Robert
Cc: Thomas Wisniewski; Yuzo Koga; Mark Joynes;
samldemotech
Subject: RE: SAML 2.0 Optional Use
Cases
Based on the thread and the use of "<vendor>User1" thru
"<vendor>User5" ids/pwds, I've rewritten my original email to include the
following use case flows (mean to be considered in order).
Use Cases:
1. SSO (with User Federation). The user accesses the SP login
site by virtue of trying to access a protected page at the SP. On the login
site, the user selects an IDP to use. At the IDP site, the user will log into
the IDP (IDP will perform federation steps as necessary) and will be redirected
back to the SP. The SP will then ask the user to log in to complete the
federation (SP will perform federation steps as necessary). User will access the
original protected page.
2. Single Logout. The user logs out of the SP using SAML logout.
The flow follows that of the basic case.
3. SSO (post User Federation). The user, after logging out of
the SP (or restarting the browser), access the SP again and selects the IDP as
in (1). SAML SSO is used to log back into the SP. The user does not have to log
into the SP this time. The flow follows that of the basic case.
4. Attribute Query. From the SP site, the user can access a
protected application that uses/displays the IDP attributes (via a SAML
Attribute Query). This is application D below.
5. (Optional to vendors who choose to do this) Change IDP
Attributes. The User may be allowed to go to the IDP site (e.g., through another
browser application) and change their attributes. After updating these
attributes, the user can re-submit the request from the SP (as defined in 4
above) and see the updated IDP attributes.
6. User Defederation. The user selects SAML Persistent ID
Management which allows them to defederate with an IDP. Either HTTP-Redirects or
SOAP can be used to accomplish this (we should decide).
-- I would also like to discuss the option of doing federation
from this step as well. I.e., the user can defederate with an IDP or they can
add additional federations to other IDPs.
I believe the attributes should include at least one dynamic
value, whether this is a counter like "NumberOfTimesAccessed" or perhaps
something more like "CurrentTime". Basically, showing that if you perform the
Attribute Query multiple times, you can see different data. In some sense this
is a potiential, albeit weaker, alternative to (5) above to show values are in
fact dynamically coming from the IDP.
Tom.
-----Original Message-----
From: Dave
Silver [mailto:]
Sent: Wednesday, January 12, 2005 7:25 AM
To: Greg Whitehead; Philpott, Robert
Cc: Thomas
Wisniewski; Yuzo Koga; Mark Joynes; samldemotech
Subject: Re: SAML 2.0 Optional Use Cases
I fully agree. Last year's Interop demo was so successful
because it was
simple, low risk, and very
straightforward. It easily and quickly
facilitated
discussion of SAML and how it could be used to solve real
business/authentication problems. And that didn't preclude more
in-depth
technical discussion, if that is what the
visitor desired.
The clock is ticking down - 3 weeks to the dry run and then 1
1/2 weeks to
the conference. Perhaps I'm being too
conservative, but I suggest we first
focus on nailing
down and successfully implementing the required demo.
Dave
At 11:01 PM 1/11/2005, Greg Whitehead wrote:
>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:
>>
>>>-----Original
Message-----
>>>From: Yuzo Koga [mailto:]
>>>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.,
, 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"></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:]
>>>>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:]
>>>>>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 <>
>>>>>NTT Information Sharing Platform Labs.
>>>>>tel: +81 422 59 3202, fax: +81 422 59 5652,
aol: yzkoga
>>>>----
>>>>Yuzo KOGA <>
>>>>NTT Information Sharing Platform Labs.
>>>>tel: +81 422 59 3202, fax: +81 422 59 5652,
aol: yzkoga
>>>----
>>>Yuzo KOGA <>
>>>NTT Information Sharing Platform Labs.
>>>tel: +81 422 59 3202, fax: +81 422 59 5652, aol:
yzkoga
>
>
>
