RE: ? on AuthnRequest

[Thomas Wisniewski <Thomas.Wisniewski@entrust.com>]

Title: RE: ? on AuthnRequest

Rob, my interpretation is the same as yours.

The IDP is then able to respond to a request based on the requested name id format. It's not a long stretch to say that the IDP has a default name id format (e.g., X509SubjectName). But I would suggest including the format in all authn requests. This way there is less confusion.

Tom.

-----Original Message-----
From: Philpott, Robert [mailto:rphilpott@rsasecurity.com]
Sent: Monday, January 31, 2005 4:02 PM
To: Greg Whitehead
Cc: Ciochon, Robert; samldemotech
Subject: RE: ? on AuthnRequest

>
> Well, many things are possible, but I thought that this was what we
> were talking about doing when we decided to have two lists of IDPs. I'm
> find to have one IDP and dispatch based on the name format in the
> request, as long as we agree that it will always be there.
>
[RSP] I interpret this differently. I had thought that when the SP provides a list of IDP's to choose from, the links would tell the SP how to build the AuthnRequest, but the requests would still go to the one SSO Service at the IDP.  What we are planning to do is have our IDP selection page tell our SP what NameIDPolicy it should build.  We thus will provide one list of IDP's, but the user would choose a separate link or check a box or a radio button to indicate which demo scenario they want.  This might look something like last years' portal page where the vendor icons had a radio button underneath to choose the BAP or BPP demo scenario.

I would REALLY prefer having to configure one IDP for each partner at my SP, build the right NameIDPolicy for the AuthnRequest to send to it, and then expect it to send me back a Response with the right identifier.

> -Greg
>
> On Jan 31, 2005, at 2:01 PM, Philpott, Robert wrote:
>
> >> 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
> >>>
> >>>
> >