[keycloak-dev] Pairwise clients and authorization services

[Martin Hardselius]

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.

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