[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: ? on AuthnRequest
I don't know that it's that strange - we can discuss non-demo use cases over a beer at the show :-) Rob Philpott Senior Consulting Engineer RSA Security Inc. Tel: 781-515-7115 Mobile: 617-510-0893 Fax: 781-515-7020 mailto:rphilpott@rsasecurity.com > -----Original Message----- > From: Greg Whitehead [mailto:grw@trustgenix.com] > Sent: Monday, January 31, 2005 4:36 PM > To: Thomas Wisniewski > Cc: Ciochon, Robert; Philpott, Robert; samldemotech > 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]