-----Original Message-----
From: Ciochon, Robert
[mailto:Robert.Ciochon@ca.com]
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:Thomas.Wisniewski@entrust.com]
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:dave.silver@enspier.com]
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: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
>
>
>