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

John Bradley ve7jtb at ve7jtb.com
Thu May 21 22:55:16 UTC 2015

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
this <AuthnRequest> and the identity provider who ultimately authenticates the principal. A count of

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 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 <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 <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 <http://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 <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 thedomain_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] 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20150521/284e8ab0/attachment-0001.html>

More information about the Openid-specs-ab mailing list