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


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.

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