[keycloak-dev] Pairwise clients and authorization services

[Pedro Igor Silva]

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