OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

samldemotech message

[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 itthis 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]