Yes, I had been counting on running a separate instance of our IDP for
the optional use case (and configuring the default name format
appropriately in that instance).
I don't mind passing the requested name format in the AuthnRequest if
that helps other folks, though.
-Greg
On Jan 31, 2005, at 1:07 PM, Ciochon, Robert wrote:
> 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:
>
>
