[keycloak-dev] Pairwise Subject Identifier

Martin Hardselius martin.hardselius at gmail.com
Mon Aug 22 09:50:44 EDT 2016 

Ok, thanks for the clarification.

Where would it make sense to put the PairwiseSubGeneratorSpi? Which
package, that is?

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

> On 22 August 2016 at 14:16, Martin Hardselius <martin.hardselius at gmail.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."
>>
>> 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. [...]
>>
>
> Yes, but I meant from a documentation perspective. It should be clear from
> the documentation that is the case.
>
>
>>
>> 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/7c87dc43/attachment-0001.html

More information about the keycloak-dev mailing list