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(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-dev

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(a)redhat.com&gt; 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(a)gmail.com&gt; 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(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> > >

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.

Martin On Mon, 19 Feb 2018 at 19:20 Pedro Igor Silva <psilva(a)redhat.com&gt; 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(a)gmail.com&gt; 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(a)redhat.com&gt; 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(a)gmail.com&gt; 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(a)lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>>> >>> >>> >

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(a)redhat.com&gt; wrote: > On Mon, Feb 19, 2018 at 3:41 PM, Martin Hardselius < > martin.hardselius(a)gmail.com&gt; 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(a)redhat.com&gt; 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(a)gmail.com&gt; 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(a)redhat.com&gt; >>>> 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(a)gmail.com&gt; 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(a)lists.jboss.org >>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>>>>> >>>>> >>>>> >>>

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(a)redhat.com&gt; wrote: > On Thu, Mar 1, 2018 at 11:48 AM, Martin Hardselius < > martin.hardselius(a)gmail.com&gt; 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(a)redhat.com&gt; wrote: >> >>> On Mon, Feb 19, 2018 at 3:41 PM, Martin Hardselius < >>> martin.hardselius(a)gmail.com&gt; 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(a)redhat.com&gt; >>>> 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(a)gmail.com&gt; 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(a)redhat.com&gt; >>>>>> 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(a)gmail.com&gt; 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(a)lists.jboss.org >>>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>>>>>>> >>>>>>> >>>>>>> >>>>> >