Rob,
some comments (all other items I agree on).
In
terms of NameIDPolicy, we had decided on the last call that the SP would decide
what format to use (vs. the ID value implying this). We would
have two lists of IDPs on the SP site (one for the basic case idps and one
for the optional use cases). How difficult would it be to implement
this. The alternative of having the IDP know (on a per user basis which format
to use), doesn't seem to be the right approach.
I also
think the following should also be allowed.
AssertionConsumerServiceIndex with a value of 0 (in addition to not
being present).
Tom.
-----Original Message-----
From: Philpott, Robert
[mailto:]
Sent: Monday, January 31, 2005
1:09 PM
To: samldemotech
Subject: ? on
AuthnRequest
The interop spec doesn’t say
anything about what we’ll be sending in the AuthnRequest messages of the demo
scenarios. Let me throw out what I think we should do and see if it
sticks.
AuthnRequest:
-
Attributes from
RequestAbstractType:
o
ID: NCName string; required by
SAML – MUST be sent
o
Version: string; required by SAML;
value = “2.0” – MUST be sent
o
IssueInstant: xs:dateTime;
required by SAML – MUST be sent
o
Destination: URI; required by SAML
when using HTTP Redirect or POST bindings – MUST be
sent
o
Consent: values from spec – MUST
NOT be sent
-
Elements from
RequestAbstractType:
o
<saml:Issuer>: IssuerType –
required for all profiles we’re using – MUST be
sent
§
Format must be omitted or must be
set to “urn:…:nameid-format: entity”.
§
NameQualifier, SPNameQualifier,
and SPProvidedID – MUST NOT be sent
o
<ds:Signature> - MUST NOT be
sent
§
Note that the redirect binding
will sign the URL parameters as defined in the spec, so the message itself
should not include a signature
-
AuthnRequest-specific Attributes
:
o
ForceAuthn – MUST NOT be
sent
o
IsPassive – MUST NOT be
sent
o
AssertionconsumerServiceIndex –
MUST NOT be sent
o
AssertionConsumerServiceURL – MUST
NOT be sent
o
ProtocolBinding – MUST NOT be
sent
o
AttributeConsumingServiceIndex –
MUST NOT be sent
-
AuthnRequest-specific Elements
:
o
<saml:Subject> – MUST NOT be
sent
o
<saml:NameIDPolicy> – MUST
be sent
§
Format: MUST NOT be
included
§
AllowCreate flag is
“true”
§
SPNameQualifier – MUST NOT be
sent
o
<saml:Conditions> – MUST NOT
be sent
o
<RequestedAuthnContext> –
MUST NOT be sent
o
<Scoping> – MUST NOT be
sent
The only item I debated about was
the NameIDPolicy. AllowCreate must be true for the optional use cases,
but when the SP sends the user to the IDP it normally doesn’t know which use
case is being run. I believe that is controlled by what user account the
use logs in with at the IDP. Alice, Bob, and Charlie are for the base use case
and <vendor>user<n> (e.g. rsauser1) users are for the optional use
cases.
So we could have defined the
<NameIDPolicy> as follows:
o
For the base use
case:
§
Format:
urn:…:nameid-format:X509SubjectName
§
AllowCreate flag is omitted or
must be set to “false”
§
SPNameQualifier – MUST NOT be
sent
o
For the optional use
case:
§
Format:
urn:…:nameid-format:persistent
§
AllowCreate flag is
“true”
§
SPNameQualifier – MUST NOT be
sent
But this means the SP has to know
which demo the user is running before they are sent to the SP. Our SP
can’t easily do this.
Comments/Questions/Complaints?
Rob
Philpott
Senior Consulting
Engineer
RSA Security
Inc.
Tel: 781-515-7115
Mobile: 617-510-0893
Fax: 781-515-7020
mailto:
