[keycloak-dev] Pairwise clients and authorization services

[Pedro Igor Silva]

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
>>>>>>>
>>>>>>
>>>>>>
>>>>