[keycloak-dev] Pairwise Subject Identifier

Mon Aug 22 08:16:49 EDT 2016

"IMO it's sufficient to document the algorithm to create the sub, which
should make it clear that the origin in the redirect uri will affect the
sub."

Reasonable. :)

"One client could also have multiple redirect uris with different origins
so could get different sub's generated depending on the redirect uri used."

That case is probably caught by
[...] If there are multiple hostnames in the registered redirect_uris, the
Client MUST register a sector_identifier_uri. [...]

On Mon, 22 Aug 2016 at 10:42 Stian Thorgersen <sthorger at redhat.com> wrote:

> IMO it's sufficient to document the algorithm to create the sub, which
> should make it clear that the origin in the redirect uri will affect the
> sub. One client could also have multiple redirect uris with different
> origins so could get different sub's generated depending on the redirect
> uri used.
>
> On 22 August 2016 at 09:58, Martin Hardselius <martin.hardselius at gmail.com
> > wrote:
>
>> Sounds fair enough.
>>
>> What about the case where you don't provide a sector_identifier_uri, set
>> up a single redirect uri on myhost and then later go on to change that
>> redirect uri to something on myotherhost? That would change the
>> sector_identifier and subsequently all the user subs. Do we protect against
>> such "mistakes" or do we warn people (in the docs and/or admin gui) that
>> it's not a good idea to do that?
>>
>> On Mon, 22 Aug 2016 at 09:38 Stian Thorgersen <sthorger at redhat.com>
>> wrote:
>>
>>> We need to follow the spec and verify that sector_identifier_uri points
>>> to a URL that contains the corresponding URIs. As an enhancement we could
>>> support wildcards in the JSON returned by sector_identifier_uri. For
>>> example if it returns:
>>>
>>> [ https://www.mydomain.com/*, https://www.myotherdomain.com/* ]
>>>
>>> A client with the redirect uri 'https://www.myotherdomain.com/myapp'
>>> would work
>>>
>>> On 18 August 2016 at 15:09, Martin Hardselius <
>>> martin.hardselius at gmail.com> wrote:
>>>
>>>> Speaking of subject_identifier_uri
>>>>
>>>> From the spec:
>>>>
>>>> "When a sector_identifier_uri is provided, the host component of that
>>>> URL is used as the Sector Identifier for the pairwise identifier
>>>> calculation. The value of the sector_identifier_uri MUST be a URL
>>>> using the https scheme that points to a JSON file containing an array
>>>> of redirect_uri values. The values of the registered redirect_uris MUST
>>>> be included in the elements of the array."
>>>>
>>>> What's your stance on sanity/health checking the sector_identifier_uri?
>>>> URI validation is one thing, but should we also make a request to the uri
>>>> in order to validate the response?
>>>>
>>>> The spec also mentions that the sector_identifier_uri isn't strictly
>>>> required if a client has all it's redirect_uris under the same domain. How
>>>> do we deal with changes to clients if the sector_identifier_uri isn't
>>>> required for enabling pairwise subs?
>>>>
>>>> Example:
>>>>
>>>> I create a client, enabling pairwise subs. Valid redirect_uris are [
>>>> https://www.mydomain.com/* ]. The sector_identifier would be mydomain.
>>>>
>>>> Later on, I update the redirect_uris to [ https://www.mydomain.com/*,
>>>> https://www.myotherdomain.com/* ] Do we
>>>>
>>>> * keep the old sector_identifier, or
>>>> * reject the update, or
>>>> * allow the update if a valid subject_identifier_uri is provided at
>>>> mydomain, or
>>>> * just allow it and let the client devs deal with the consequences, or
>>>> * take some other path you can think of ?
>>>>
>>>> Having the sector_identifier_uri as a hard requirement seems safer, but
>>>> it's also means more work implementing a client. Leaving it optional is a
>>>> lot more scary.
>>>>
>>>>
>>>> On Thu, 18 Aug 2016 at 10:45 Stian Thorgersen <sthorger at redhat.com>
>>>> wrote:
>>>>
>>>>> Makes sense to make this pluggable. The default should
>>>>> probably SHA-256( sector_identifier || local_sub || salt ).
>>>>>
>>>>> We would love a PR for this, but there's a few bits required:
>>>>>
>>>>> * OIDC clients need option for subject type and sector_identifier_uri.
>>>>> If not set it should default to public so existing clients continue to
>>>>> work. These options can just be set as client attributes so there's no need
>>>>> to update db schema
>>>>> * Admin console update for the above
>>>>> * PairwiseSubGeneratorSpi and default implementation
>>>>> * Generation of salt for clients. This should be done when a client
>>>>> sets subject type to pairwise
>>>>> * Tests and docs
>>>>>
>>>>> I'd say the PairwiseSubGeneratorSpi signature should probably be:
>>>>>
>>>>> * public String getPairwiseSub(UserModel user, ClientModel client)
>>>>>
>>>>> It might even be an option to let the default PairwiseSubGenerator
>>>>> provider create the salt and store it as an attribute on the client, making
>>>>> that part pluggable as well.
>>>>>
>>>>> On 17 August 2016 at 15:59, Martin Hardselius <
>>>>> martin.hardselius at gmail.com> wrote:
>>>>>
>>>>>> I'm going to bump this, as I want to continue the discussion/provide
>>>>>> some input.
>>>>>>
>>>>>> Does it make sense to support more than type of pairwise subject
>>>>>> identifier generator? E.g through a PairwiseSubGeneratorSpi?
>>>>>>
>>>>>> Let's say I want to generate the pairwise sub as a salted hash: sub =
>>>>>> SHA-256( sector_identifier || local_sub || salt )
>>>>>> To me, it makes sense to allow for per-client salts. These salts
>>>>>> should probably be generated and persisted during client creation. Thoughts?
>>>>>>
>>>>>> On Fri, 12 Aug 2016 at 09:57 Martin Hardselius <
>>>>>> martin.hardselius at gmail.com> wrote:
>>>>>>
>>>>>>> Thank you for your response. Did not see that ticket before. Great
>>>>>>> news!
>>>>>>>
>>>>>>> I looked into using protocol mappers to achieve this, and while it
>>>>>>> would work I'm worried that once KEYCLOAK-3422 has been resolved and
>>>>>>> included in a proper release we would run into migration issues if the
>>>>>>> method used for calculating "native" pairwise subs is different from what
>>>>>>> we implement. Clients could loose / be forced to re-register all their
>>>>>>> users if we decide to switch. The example methods in the spec are just
>>>>>>> that. Examples. Maybe the method/alg for computing the pairwise sub should
>>>>>>> be pluggable?
>>>>>>>
>>>>>>> --
>>>>>>> Martin
>>>>>>>
>>>>>>> On Thu, 11 Aug 2016 at 17:15 Marek Posolda <mposolda at redhat.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> Sorry for late response.
>>>>>>>>
>>>>>>>> We have JIRA created for that. You can possibly add yourself as a
>>>>>>>> watcher. See https://issues.jboss.org/browse/KEYCLOAK-3422
>>>>>>>>
>>>>>>>> Maybe an alternative for you is to use protocolMappers. That should
>>>>>>>> allow you to "construct" the token for particular client exactly how you
>>>>>>>> want and also use the different value for "sub" claim.
>>>>>>>>
>>>>>>>> Another possibility is, to handle this on adapter side. We already
>>>>>>>> have an adapter option "principal-attribute", which specifies that
>>>>>>>> application will see the different attribute instead of "sub" as subject.
>>>>>>>> For example when in appllication you call
>>>>>>>> "httpServletRequest.getRemoteUser()" it will return "john" instead of
>>>>>>>> "123456-unique-johns-uuid" . See
>>>>>>>> https://keycloak.gitbooks.io/securing-client-applications-guide/content/v/2.1/topics/oidc/java/java-adapter-config.html
>>>>>>>>
>>>>>>>> Hopefully some of the options can be useful for you?
>>>>>>>>
>>>>>>>> Marek
>>>>>>>>
>>>>>>>>
>>>>>>>> On 02/08/16 14:13, Martin Hardselius wrote:
>>>>>>>>
>>>>>>>> Me and my team are working towards getting Keycloak, customized for
>>>>>>>> our needs, into production but we've identified the need for Pairwise
>>>>>>>> Subject Identifiers as we don't want to expose internal user ids.
>>>>>>>>
>>>>>>>> Right now, the only subject_types_supported seems to be "public".
>>>>>>>> Are there any near-future plans to include "pairwise"? Can we pitch in with
>>>>>>>> a PR to make this happen as soon as possible?
>>>>>>>>
>>>>>>>> Links to relevant sections in the spec:
>>>>>>>>
>>>>>>>> http://openid.net/specs/openid-connect-core-1_0.html#SubjectIDTypes
>>>>>>>> http://openid.net/specs/openid-connect-core-1_0.html#PairwiseAlg
>>>>>>>>
>>>>>>>> --
>>>>>>>> Martin
>>>>>>>>
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> keycloak-dev mailing listkeycloak-dev at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>> _______________________________________________
>>>>>> keycloak-dev mailing list
>>>>>> keycloak-dev at lists.jboss.org
>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>>>
>>>>>
>>>>>
>>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160822/3b59b189/attachment.html 