[Openid-specs-ab] Spec call notes 18-May-15

Chuck Mortimore cmortimore at salesforce.com
Fri May 22 00:20:45 UTC 2015


We're trying to stay away from it if we can.    I'd rather see the proxy
interpret the client_id and convey required policy or LOA to the IDP, then
the IDP having direct knowledge of all the RPs.

-cmort


On Thu, May 21, 2015 at 5:08 PM, John Bradley <ve7jtb at ve7jtb.com> wrote:

> I agree that perhaps it should be put as a configuration context hint to
> the IDP proxy.
>
> Do you see a need for the IDP to know the identity of the original
> requester, or the RP to know the IDP?
>
> The specific use case that brought that up was the IDP wanting to apply
> different loa or max age based on the origin of the request given they
> normally set that by client_id.
>
> Sent from my iPhone
>
> On May 21, 2015, at 8:56 PM, Chuck Mortimore <cmortimore at salesforce.com>
> wrote:
>
> In our system, we've consciously kept RPs from hard coupling to a specific
> IDP, and consider it a bad practice.
>
> We do use something similar to domain hint, but in our case it specifies a
> particular configuration/context within the IDP proxy itself.     This
> context can be configured to point at 1 or more IDPs.     This indirection
> allows changing of policy and discovery overtime without impacting the RPs.
>
>
> Responding more directly, I will second what John said about not seeing
> IDPlists in the wild greater than 1, and second what Mike said about
> complexity.   No point replicating the complicated parts of SAML that no
> one appears to use.
>
> -cmort
>
> On Thu, May 21, 2015 at 4:43 PM, Mike Jones <Michael.Jones at microsoft.com>
> wrote:
>
>>  WS-Fed “whr” and domain_hint appear to solve the 90+% case without any
>> counts or lists and are used in practice.  Do we really need any of the
>> rest of it?  (And if we do, shouldn’t we be representing
>> act-as/on-behalf-of information with general-purpose JWT extensions to do
>> that, rather than OAuth request parameters specific to this use case.)
>>
>>
>>
>>                                                             -- Mike
>>
>>
>>
>> *From:* John Bradley [mailto:ve7jtb at ve7jtb.com]
>> *Sent:* Thursday, May 21, 2015 3:55 PM
>> *To:* Mike Jones
>> *Cc:* Edmund Jay; openid-specs-ab at lists.openid.net
>> *Subject:* Re: [Openid-specs-ab] Spec call notes 18-May-15
>>
>>
>>
>> There are four things that SAML defines for proxies.
>>
>>
>>
>> 1 <IDPList> [Optional] An advisory list of identity providers and
>> associated information that the requester deems acceptable to respond to
>> the request.
>>
>>
>>
>> That is a bit like domain_hint but multi valued as more than one hop is
>> allowed.
>>
>>
>>
>> Because there can be more than one hop
>>
>>
>>
>> 2 ProxyCount [Optional] Specifies the number of proxying indirections
>> permissible between the identity provider that receives
>>
>>    1. this <AuthnRequest> and the identity provider who ultimately
>>    authenticates the principal. A count of
>>    2. zero permits no proxying, while omitting this attribute expresses
>>    no such restriction.
>>
>>
>>
>>
>>
>> 3 <RequesterID> [Zero or More]
>>
>> Identifies the set of requesting entities on whose behalf the requester
>> is acting. Used to communicate the chain of requesters when proxying
>> occurs, as described in Section 3.4.1.5. See Section 8.3.6 for a
>> description of entity identifiers.
>>
>>
>>
>> This identifies the original requester to the IdP.
>>
>>
>>
>> 4 <AuthenticatingAuthority> [Zero or More]
>>
>> Zero or more unique identifiers of authentication authorities that were
>> involved in the authentication of the principal (not including the
>> assertion issuer, who is presumed to have been involved without being
>> explicitly named here)
>>
>> This identifies the IdP/proxys involved to the RP
>>
>>
>>
>> Now I have to admit that in the wild l have only seen IDPList used as a
>> dingle element similar to domain_hint.   This is often used when you have a
>> SP login triggered by a deep link that tells you the user is coming from
>> some organization with a specific IdP in ah hub and spoke model.
>>
>>
>>
>> I could live without proxy count if we limit domain_hint to one.
>>
>>
>>
>> It is useful for auditing and policy if you have the option of
>> documenting the hops an assertion takes in each direction.
>>
>>
>>
>> Those I would probably prefer as arrays.
>>
>>
>>
>> This is a first cut at what I was thinking
>>
>>
>>
>> domain_hint:  “https://idp.example.com”
>>
>>                                     String, optional paramater sent by
>> the client to a IdP proxy to indicate the idp that may be used to
>> authenticate the user.
>>
>>
>>
>>
>>
>> The requester_sequence Authentication Request parameter indicates the
>> authentication requesters prior to the client making the current request.
>> It is represented as a JSON object containing an array of
>> requester identifiers. The requestor_sequence parameter value is
>> represented in an OAuth 2.0 request as UTF-8 encoded JSON (which ends up
>> being form-urlencoded when passed as an OAuth parameter). When used in a
>> Request Object value, per *Section 6.1*
>> <http://openid.net/specs/openid-connect-core-1_0.html#RequestObject>,
>> the JSON is used as the value of the requester_sequence member.
>>
>>
>>
>>
>>
>> requester_sequence: [ “client1”, “prox1” ]
>>
>>                                     Array,  each hop must add an
>> identifier for the requester of authentication to the array.   The array is
>> an ordered list with element 0 always identifying the initial origin of the
>> authentication request.
>>
>>                                     If there are two proxies then the
>> second one would add the first proxy as element 1.
>>
>>
>>
>> Connect Response
>>
>>
>>
>> id_token member
>>
>> “auth_sequence”: [“https://issuer.examle.com”]
>>
>>                          Optional array of strings containing one or more
>> unique identifiers for the entities involved in authenticating the subject
>> (not including the token issuer who is presumed to have been involved
>> without being explicitly named in this element).
>>
>>                                     Example, if the subject is
>> authenticated by example.com and the response passes back to the client
>> via a proxy, that proxy would add a element to the id_token it is issuing
>> containing an array with one element containing the iss value contained in
>> the id_token it received.
>>
>>
>>
>>
>>
>> So I think one of them overlaps with what MS is doing.  How do people
>> feel about the others.
>>
>>
>>
>> The main problem is that without knowing who the originating client is
>> the AS can’t tune defaults defaults for some things like max_age other than
>> by grouping all the connections through the proxy together.  (The proxy
>> could crate separate client_id for each downstream connection but that
>> seems like overkill.)
>>
>>
>>
>> John B
>>
>>
>>
>>  On May 21, 2015, at 6:45 PM, Mike Jones <Michael.Jones at microsoft.com>
>> wrote:
>>
>>
>>
>> Microsoft uses a parameter called domain_hint that allows the RP to
>> specify a preferred IdP.  It’s modelled after the WS-Federation “whr”
>> parameter.
>>
>>
>>
>> It’s mentioned at
>> https://msdn.microsoft.com/en-us/library/azure/dn645542.aspx, where its
>> description is:
>>
>>
>>
>> *domain_hint*
>>
>> [Optional] Provides a hint about the tenant or domain that the user
>> should use to sign in. The value of the*domain_hint* is a registered
>> domain for the tenant. If the tenant is federated to an on-premises
>> directory, AAD redirects to the specified tenant federation server.
>>
>>
>>
>> If that will do the job, maybe we can write a mini-spec to standardize
>> that.
>>
>>
>>
>>                                                             -- Mike
>>
>>
>>
>> *From:* Openid-specs-ab [mailto:openid-specs-ab-bounces at lists.openid.net
>> <openid-specs-ab-bounces at lists.openid.net>] *On Behalf Of *Edmund Jay
>> *Sent:* Monday, May 18, 2015 5:10 PM
>> *To:* openid-specs-ab at lists.openid.net
>> *Subject:* [Openid-specs-ab] Spec call notes 18-May-15
>>
>>
>>
>> Spec call notes 18-May-15
>>
>>
>>
>> John Bradley
>>
>> Nat Sakimura
>>
>> Edmund Jay
>>
>>
>>
>>
>>
>> - Discussed the need for extension spec for supporting proxies in
>> enterprise scenarios.
>>
>>
>>
>>
>>
>> - RP Certification Testing
>>
>>  Nothing new has been discussed.
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> _______________________________________________
>> Openid-specs-ab mailing list
>> Openid-specs-ab at lists.openid.net
>> http://lists.openid.net/mailman/listinfo/openid-specs-ab
>>
>>
>>
>> _______________________________________________
>> Openid-specs-ab mailing list
>> Openid-specs-ab at lists.openid.net
>> http://lists.openid.net/mailman/listinfo/openid-specs-ab
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20150521/77a26398/attachment-0001.html>


More information about the Openid-specs-ab mailing list