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.
[RSP] sleep deprivation… I don’t recall that discussion…
but I now concur. I’ve talked it over here and we’ll handle
that. Sorry for the confusion.
So just to confirm – for the basic scenario, will
there still be a NameIDPolicy with Format=X509SubjectName? Or will there be NO
NameIDPolicy? Is AllowCreate included? If so, what should it be set to?
[Thomas Wisniewski] I think that since there are 2 id
formats, it makes things clearer if we explicitly state them for each use
case. Allow create (which defaults to false I believe), can be
included with a false value or the attribute can be
omitted.
For the federation use case, Then I assume we will use
Format=urn:…:persistent and AllowCreate=true.
[Thomas Wisniewski] Yes.
-----Original Message-----
From: Philpott, Robert
[mailto:rphilpott@rsasecurity.com]
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:rphilpott@rsasecurity.com