[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
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 |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]