+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