RE: ? on AuthnRequest

["Philpott, Robert" <rphilpott@rsasecurity.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).

[RSP] Does that mean we've got to configure our SP to know about 2 separate IDP's for your site and then pick one based on the scenario?  Ugh - that really complicates the configuration if everyone does that. Does this mean you have 2 different EntityID's based on which one responds?  This is more configuration than we had planned for.

We have been assuming that there'd just be a SINGLE IDP SSO endpoint for each vendor.  That is, if we were using metadata, there is just one EntityDescriptor for each vendor, each with an IDPSSODescriptor that has one <SingleSignOnService> element with the endpoint defined.  

Or are you handling that behind your SSO service endpoint and it is transparent to everyone else?

> 
> 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
> >
> >