Title: RE: SAML 2.0 Optional Use Cases
Bob,
if the ID federations are already set up ahead of time, then this is pretty
much exactly like the basic user case we agree to last week where we are
using X509 Subject names.
I
think what we should show, and I think it was implied by all the email thread
replies, that the actual ID federation and then the defederation is the
more advanced use case (hence optional). There isn't that much add'l typing
to do except:
-
Logging into the SP as well as the IDP initially.
-
Selecting a link on a page that say defederate me.
The
main point of the use case being: SAML 2.0 now lets you federate your identity
between providers (no out of band or apriori information about the user is
requried between the two sites). The user is in control of
this.
Tom.
-----Original Message-----
From: Ciochon, Robert
[mailto:]
Sent: Wednesday, January 12, 2005
2:42 PM
To: Thomas Wisniewski; Dave Silver; Greg Whitehead;
Philpott, Robert
Cc: Yuzo Koga; Mark Joynes;
samldemotech
Subject: 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
>
>
>
