Rob,
see below.
-----Original Message-----
From: Philpott, Robert
[mailto:]
Sent: Monday, January 31, 2005
2:39 PM
To: Thomas Wisniewski; samldemotech
Subject: RE: ?
on AuthnRequest
From: Thomas
Wisniewski [mailto:]
Sent: Monday, January 31, 2005 1:32
PM
To: Philpott, Robert;
samldemotech
Subject: RE: ?
on AuthnRequest
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.
[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.
I also think the
following should also be allowed.
AssertionConsumerServiceIndex
with a value of 0 (in addition to not being present).
[RSP]
that’s okay with me – I just preferred to keep the AuthnRequest messages short
because we’re using redirect HTTP. So allowing it in addition to allowing it
to not be present is fine.
But
can we all agree to use the same index value (0 is fine with me also) so we
don’t have configuration issues (i.e. one vendor might use 0, another use 1,
another use 99)?
[Thomas
Wisniewski] Yes. It would have to be 0 or not
included.
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:
