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