[keycloak-dev] Pairwise Subject Identifier

[Stian Thorgersen]

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/20160818/3f14a1ef/attachment-0001.html