Re: ? on AuthnRequest

[Greg Whitehead <grw@trustgenix.com>]

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:rphilpott@rsasecurity.com]
>  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:rphilpott@rsasecurity.com
>
>