Thanks for laying this out Rob. Comments and
feedback?
Regarding which demo scenario is being run, we had decided
on one of the calls that there would be 2 lists of idP's used on the SP, one for
the base use cases and one for the optional. Selecting from a particular
idP list defines which use case, not the user name. It sounds like you
have a problem doing it this way. Anyone else?
Regards,
Bob
From: Philpott, Robert
[mailto:]
Sent: Monday, January 31, 2005
10:09 AM
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:
