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


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]