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


Right. I think it was just a problem of emails crossing paths. As long 
as we're including the format in the request, which I think we've 
agreed to, we're ok.

It's easy for us either way.

-Greg

On Jan 31, 2005, at 3:02 PM, Philpott, Robert wrote:

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