[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: ? on AuthnRequest
Sure, but as a sanity check here, pseudonyms were designed to protect the privacy of users, so it's a little strange to have a configuration that will offer up either an X509Name or a pseudonym to an SP depending on what is requested. Fine for the demo, but probably not so useful in real life. -Greg On Jan 31, 2005, at 3:29 PM, Thomas Wisniewski wrote: > 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 > > >>> > > >>> > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]