[keycloak-dev] Pairwise clients and authorization services

[Pedro Igor Silva]

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