+1 to Jeff’s
objection to self-registration.
The face time with
someone looking at the demo is almost always very short and entering data on
registration pages is way too time-consuming. It’s tough enough to get the
points across to them without spending the visitor’s time filling in forms.
In order to federate
2 user accounts, you have to be able to log into both accounts the first
time. So, to make the demos easy to run from each vendors station to any
other vendors station, I think this means we should standardize on naming
conventions for user identities across the sites as well as standardize on the
attributes.
In order for me to
demo federation, I need a local user identity at the IDP and a user identity
at the SP. We can define a convention that makes it easy to remember the names
at each IDP and SP. Each vendor will need a set of these identities to
use when they are demoing so that we don’t walk on each other. I offer a
suggested convention of “<vendor1>idp<vendor2>user<N>” and
“<vendor1>sp<vendor2>user<N>”. The former format is an
account I log into at <vendor1>’s IDP when I am <vendor2>,
etc. In the examples below, I am using 5 IDP user accounts and 5 SP
users accounts for each vendor to use. We can adjust this count as
necessary.
For example, at the
RSA site running an IDP and an SP, I’d create the following user accounts for
use when <vendor2> wants to demo federations using the RSA
IDP:
-
“rsaIdpRsaUser1”
through “rsaIdpRsaUser5”
-
“rsaIdpHpUser1”
through “rsaIdpHpUser5”
-
“rsaIdpCaUser1”
through “rsaIdpCaUser5”
-
Etc.
And I’d create the
following user accounts for use when <vendor2> wants to demo federations
using the RSA SP:
-
“rsaSpRsaUser1”
through “rsaSpRsaUser5”
-
“rsaSpHpUser1”
through “rsaSpHpUser5”
-
“rsaSpCaUser1”
through “rsaSpCaUser5”
-
Etc.
HP would need to
create the following user accounts at their site for when <vendor2>
wants to demo federations using the HP IDP:
-
“hpIdpRsaUser1”
through “hpIdpRsaUser5”
-
“hpIdpHpUser1”
through “hpIdpHpUser5”
-
“hpIdpCaUser1”
through “hpIdpCaUser5”
-
Etc.
And they’d create
accounts for when <vendor2> wants to use the HP
SP:
-
“hpSpRsaUser1”
through “hpSpRsaUser5”
-
“hpSpHpUser1” through
“hpSpHpUser5”
-
“hpSpCaUser1” through
“hpSpCaUser5”
-
Etc.
At the RSA station,
if I want to demo federation of an RSA IDP user account with an HP SP user
account, I would:
- Access the HP SP
resource.
- Since I’m not authenticated, I
would be asked to either log in locally or choose an IDP. I would
choose the RSA IDP and would be sent there with an <AuthnRequest> that
has a NameIDPolicy asking for a persistent identifier and AllowCreate set to
true.
- At the RSA IDP site, I would log
in as “rsaIdpRsaUser1”.
- The RSA IDP would see that this
account has no federation with the HP SP and create a persistent federated
identity for the account for use at the HP SP.
- The RSA IDP creates an SSO
assertion (including user attributes from the rsaIdpUser1 account) and use
the POST binding to send the user back to the AssertionConsumerService at
the HP SP.
- The HP SP sees that the
persistent federated identity in the assertion is not known locally and
forces the user to log in locally to complete the federation. The user
logs in using the account “hpSpRsaUser1”. The HP SP completes the
federation and lets me access the resource.
- I can now kill the browser and
start a new request to access the HP SP resource.
- It would again ask me to choose
an IDP or log in locally. I choose the RSA IDP and get sent there with
the same <AuthnRequest> as described in #2.
- I log in at the IDP as
“rsaIdpRsaUser1”.
- The RSA IDP sends me back to the
HP SP with the SSO assertion containing my persistent
identifier.
- The HP SP finds my local user
account associated with the federated identifier (hpSpRsaUser1) and
transparently logs me in to the site.
The naming convention
needs to allow for all vendors to choose any other vendor’s IDP or SP to
federate with their own Sp or IDP. If one wishes to show it, it actually
allows going to any SP and federating with any IDP without stepping on each
other (i.e. an RSA employee could demo use of the CA SP (using caSpRsaUser1)
and federating this account with the HP IDP (using
hpIdpRsaUser1).
Make
sense?
From: Jeff
Bohren [mailto:jbohren@opennetwork.com]
Sent: Tuesday, January 11, 2005 10:05
AM
To:
samldemotech
Subject: RE:
SAML 2.0 Optional Use Cases
Standardizing the
attributes is a great idea, but I can tell you from personal experience that
the self-registration won’t work well. The OASIS Provisioning Services TC (the
SPML TC) did an Interop at Burton two years ago and tried to
use the self-service approach. Most people watching the demo did not want to
actively participate so the demo drivers just made up people for each
demo.
I would suggest that
we standardize on a list of attributes and then just leave it up to each to
decide how to create identities for their own demos. Each vendor could either
use a predefined set of users, or create them on the fly as
needed.
Jeff
Bohren
Product
Architect
OpenNetwork
Technologies, Inc
Try the industry's
only 100% .NET-enabled identity management software. Download your free
copy of Universal IdP Standard Edition today. Go to
www.opennetwork.com/eval.
-----Original
Message-----
From: Thomas
Wisniewski [mailto:Thomas.Wisniewski@entrust.com]
Sent: Tuesday, January 11, 2005 9:26
AM
To: Yuzo Koga; Thomas
Wisniewski
Cc: Mark Joynes;
samldemotech
Subject: RE:
SAML 2.0 Optional Use Cases
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