[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: ? on AuthnRequest
Right. I think it was just a problem of emails crossing paths. As long as we're including the format in the request, which I think we've agreed to, we're ok. It's easy for us either way. -Greg On Jan 31, 2005, at 3:02 PM, Philpott, Robert wrote: >> >> 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 >>>>> >>>>> >>> >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]