[keycloak-dev] Pairwise clients and authorization services

[Martin Hardselius]

Rebase is all good. PR sent: https://github.com/keycloak/keycloak/pull/5050

- Martin

On Thu, 1 Mar 2018 at 17:17 Pedro Igor Silva <psilva at redhat.com> wrote:

> Btw, you may need to rebase (if you did not already) due to some changes
> we merged this week ... Let me now if everything goes fine when rebasing.
>
> On Thu, Mar 1, 2018 at 1:10 PM, Pedro Igor Silva <psilva at redhat.com>
> wrote:
>
>> On Thu, Mar 1, 2018 at 11:48 AM, Martin Hardselius <
>> martin.hardselius at gmail.com> wrote:
>>
>>> Ok, I have something that seems to be working now. Extended the
>>> AuthorizationAPITest and EntitlementAPITest with cases that use a pairwise
>>> resource server.
>>>
>>> Are there any particular tests you want me to add? I want to avoid too
>>> much duplication of code, and since Arquillian has no support for
>>> parameterized tests without extensions I would like some input on what you
>>> think is important.
>>>
>>
>> Those two tests are enough. Thanks for the contribution.
>>
>> Will review your PR once it is there in the queue.
>>
>>
>>>
>>> Martin
>>>
>>> On Mon, 19 Feb 2018 at 20:28 Pedro Igor Silva <psilva at redhat.com> wrote:
>>>
>>>> On Mon, Feb 19, 2018 at 3:41 PM, Martin Hardselius <
>>>> martin.hardselius at gmail.com> wrote:
>>>>
>>>>> It's possible to get the user from the session given a token. That way
>>>>> we can still resolve the local sub. But for a client configured with a
>>>>> SHA-256 based mapper it might be important to check if the resolved sub
>>>>> hashes to the same sub in the token, whereas an encryption based sub should
>>>>> decrypt to match a local sub.
>>>>>
>>>>
>>>>> Given the client for which the token was issued, it should be easy to
>>>>> find out which algorithm was used (check mapper configuration).
>>>>>
>>>>> I'm prepared to help out with a PR if you need assistance.
>>>>>
>>>>
>>>> Sure, go ahead. I'm happy to review your changes once you have
>>>> something.
>>>>
>>>> In fact, it should be better to rely on the session state instead of
>>>> the sub claim.
>>>>
>>>>
>>>>>
>>>>> Martin
>>>>>
>>>>>
>>>>> On Mon, 19 Feb 2018 at 19:20 Pedro Igor Silva <psilva at redhat.com>
>>>>> wrote:
>>>>>
>>>>>> Thanks for the info. It seems the spec was changed to include other
>>>>>> algorithms and examples.
>>>>>>
>>>>>> I think we can add support for encryption as an additional pairwise
>>>>>> configuration. That would help us with the original issue and may be useful
>>>>>> for those with a similar requirement.
>>>>>>
>>>>>> I've created https://issues.jboss.org/browse/KEYCLOAK-6659.
>>>>>>
>>>>>> Thanks.
>>>>>>
>>>>>> On Mon, Feb 19, 2018 at 2:32 PM, Martin Hardselius <
>>>>>> martin.hardselius at gmail.com> wrote:
>>>>>>
>>>>>>> Yes, the default implementation is using SHA-256. That makes things
>>>>>>> a bit more complicated. In retrospect, it might have been wiser to go with
>>>>>>> AES-128 or some other kind of encryption.
>>>>>>>
>>>>>>> No specific reason. It was one of the suggestions in from the spec
>>>>>>> and I suppose we failed to think of scenarios where we would wan't to
>>>>>>> resolve the local sub.
>>>>>>>
>>>>>>> Martin
>>>>>>>
>>>>>>> On Mon, 19 Feb 2018 at 17:19 Pedro Igor Silva <psilva at redhat.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> We did not consider subject type pairwise in authorization
>>>>>>>> services, we need to review this ...
>>>>>>>>
>>>>>>>> If we can resolve local sub from the a pairwise subject type, I
>>>>>>>> think this is the best way to go. But pairwise is using SHA26, right ?
>>>>>>>>
>>>>>>>> I also noticed you are the main contributor of subject pairwise,
>>>>>>>> any specific reason why we are not using encryption ?
>>>>>>>>
>>>>>>>> Regards.
>>>>>>>> Pedro Igor
>>>>>>>>
>>>>>>>> On Mon, Feb 19, 2018 at 11:40 AM, Martin Hardselius <
>>>>>>>> martin.hardselius at gmail.com> wrote:
>>>>>>>>
>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>> It seems like authorization services break when using them with a
>>>>>>>>> pairwise
>>>>>>>>> enabled client. I've not investigated the full extent of this but
>>>>>>>>> long
>>>>>>>>> story short, the sub from the token is used in token validation
>>>>>>>>> and in
>>>>>>>>> org.keyclak.authorization.common.KeycloakIdentity for some
>>>>>>>>> comparisons.
>>>>>>>>>
>>>>>>>>> Steps to reproduce:
>>>>>>>>> 1. Create pairwise a client with authorization enabled
>>>>>>>>> 3. Get access token (client_credentials)
>>>>>>>>> 3, Try post a new resource_set
>>>>>>>>>
>>>>>>>>> I'm not sure what the best way to fix this is.
>>>>>>>>> 1. Re-write token validation and KeycloakIdentity to not rely on
>>>>>>>>> the sub in
>>>>>>>>> the token,
>>>>>>>>> 2. Re-write the pairwise protocol mapper to ignore service
>>>>>>>>> accounts (feels
>>>>>>>>> like putting make-up on a pig), or
>>>>>>>>> 3. "terminate" pairwise subs, replacing them with the internal
>>>>>>>>> sub, before
>>>>>>>>> further processing.
>>>>>>>>>
>>>>>>>>> Thoughts?
>>>>>>>>>
>>>>>>>>> Regards,
>>>>>>>>> Martin
>>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>>> keycloak-dev mailing list
>>>>>>>>> keycloak-dev at lists.jboss.org
>>>>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>
>>
>