From mposolda at redhat.com Thu Mar 1 03:25:49 2018 From: mposolda at redhat.com (Marek Posolda) Date: Thu, 1 Mar 2018 09:25:49 +0100 Subject: [keycloak-dev] Cross-datacenter configuration issues In-Reply-To: References: Message-ID: I've just simulated the issue and created https://issues.jboss.org/browse/KEYCLOAK-6783 . I am looking at it. What works and what we tested is: * Setup with infinispan-server-8.2.8 on "local" network (infinispan server bind on loopback address like "localhost" . Different infinispan servers running on the same laptop, but on various port offsets) * Setup with JDG server 7.1.0 on "local" network (JDG server bound on loopback address like "localhost" . Different JDG servers running on the same laptop, but on various port offsets) * Setup with infinispan-server-8.2.8 on "real" network (testing with infinispan hosts bound to real host with IP addresses like 192.168.0.1 ) We didn't test the combination with JDG server bind on "real" addresses and this is the only one where the issue happens It seems JDG 7.1.0 has some additional security when compared with the community infinispan-server 8.2.8 . The easiest workaround for you might be to test with community infinispan-server 8.2.8 instead of JDG 7.1.0 . Server can be downloaded from this address: http://downloads.jboss.org/infinispan/8.2.8.Final/infinispan-server-8.2.8.Final-bin.zip . I hope to update you later today once I have some more info. Thanks for the report and all the details you mentioned. Marek On 28/02/18 21:36, Jared Blashka wrote: > Hey all, > > I'm working on testing out the cross-datacenter replication > configuration in our development environment and I'm running into some > issues. > > I stood up some JDG 7.1 instances and some RH-SSO 7.2 instances all > running on my localhost all with different port offsets, followed the > instructions[1], and everything seemed to work well enough. > > Once I got beyond that and tried running RH-SSO and JDG on separate > servers I started running into issues[2] during RH-SSO startup. Looks > like RH-SSO is unable to connect to the remote ___script_cache but > that cache isn't mentioned anywhere in the RH-SSO documentation. The > error message (and online searching) indicates that this cache only > allows remote connections if authorization is enabled. I didn't see > any mention of configuration related to authentication or security for > the remote caches in the documentation either. > > At this point we roped in a JDG expert (cc'ed here) and found some > additional Infinispan documentation[3] on how to add authentication to > the *remote* caches within the JDG configuration but nothing much in > the way of adding authentication to the client cache configuration > inside RH-SSO that didn't involve programmatic changes. After some > additional searching we found some info[4] detailing how to add > security configurations to a remote-cache configuration in Infinispan > *9.1* but EAP 7.1 is only running Infinispan *8.2* which doesn't have > these changes. > > How did you get this working? > > Jared Blashka - Identity & Access Management > > > [1] > https://access.redhat.com/documentation/en-us/red_hat_single_sign-on/7.2/pdf/server_installation_and_configuration_guide/Red_Hat_Single_Sign-On-7.2-Server_Installation_and_Configuration_Guide-en-US.pdf#__WKANCHOR_1e > [2] http://pastebin.test.redhat.com/559674 > [3] > http://infinispan.org/docs/stable/server_guide/server_guide.html#general_concepts > [4] > https://docs.jboss.org/infinispan/9.1/configdocs/infinispan-cachestore-remote-config-9.1.html From hmlnarik at redhat.com Thu Mar 1 03:33:17 2018 From: hmlnarik at redhat.com (Hynek Mlnarik) Date: Thu, 1 Mar 2018 09:33:17 +0100 Subject: [keycloak-dev] Cross-datacenter configuration issues In-Reply-To: References: Message-ID: I can only agree that it seems to be a difference between Infinispan server and JDG, since we did test it in Amazon where each instance of Keycloak and Infinispan was installed on separate VM [1]. Whether this difference might be indeed there should be confirmed by someone from JDG team. William, could you please comment here? [1] http://blog.keycloak.org/2018/01/keycloak-cross-data-center-setup-in-aws.html On Thu, Mar 1, 2018 at 9:25 AM, Marek Posolda wrote: > I've just simulated the issue and created > https://issues.jboss.org/browse/KEYCLOAK-6783 . I am looking at it. > > What works and what we tested is: > > * Setup with infinispan-server-8.2.8 on "local" network (infinispan > server bind on loopback address like "localhost" . Different > infinispan servers running on the same laptop, but on various port > offsets) > > * Setup with JDG server 7.1.0 on "local" network (JDG server bound on > loopback address like "localhost" . Different JDG servers running on > the same laptop, but on various port offsets) > > * Setup with infinispan-server-8.2.8 on "real" network (testing with > infinispan hosts bound to real host with IP addresses like 192.168.0.1 > ) > > We didn't test the combination with JDG server bind on "real" addresses > and this is the only one where the issue happens > > It seems JDG 7.1.0 has some additional security when compared with the > community infinispan-server 8.2.8 . > > The easiest workaround for you might be to test with community > infinispan-server 8.2.8 instead of JDG 7.1.0 . Server can be downloaded > from this address: > http://downloads.jboss.org/infinispan/8.2.8.Final/ > infinispan-server-8.2.8.Final-bin.zip > . > > I hope to update you later today once I have some more info. Thanks for > the report and all the details you mentioned. > > Marek > > > On 28/02/18 21:36, Jared Blashka wrote: > > Hey all, > > > > I'm working on testing out the cross-datacenter replication > > configuration in our development environment and I'm running into some > > issues. > > > > I stood up some JDG 7.1 instances and some RH-SSO 7.2 instances all > > running on my localhost all with different port offsets, followed the > > instructions[1], and everything seemed to work well enough. > > > > Once I got beyond that and tried running RH-SSO and JDG on separate > > servers I started running into issues[2] during RH-SSO startup. Looks > > like RH-SSO is unable to connect to the remote ___script_cache but > > that cache isn't mentioned anywhere in the RH-SSO documentation. The > > error message (and online searching) indicates that this cache only > > allows remote connections if authorization is enabled. I didn't see > > any mention of configuration related to authentication or security for > > the remote caches in the documentation either. > > > > At this point we roped in a JDG expert (cc'ed here) and found some > > additional Infinispan documentation[3] on how to add authentication to > > the *remote* caches within the JDG configuration but nothing much in > > the way of adding authentication to the client cache configuration > > inside RH-SSO that didn't involve programmatic changes. After some > > additional searching we found some info[4] detailing how to add > > security configurations to a remote-cache configuration in Infinispan > > *9.1* but EAP 7.1 is only running Infinispan *8.2* which doesn't have > > these changes. > > > > How did you get this working? > > > > Jared Blashka - Identity & Access Management > > > > > > [1] > > https://access.redhat.com/documentation/en-us/red_hat_ > single_sign-on/7.2/pdf/server_installation_and_ > configuration_guide/Red_Hat_Single_Sign-On-7.2-Server_Installation_and_ > Configuration_Guide-en-US.pdf#__WKANCHOR_1e > > [2] http://pastebin.test.redhat.com/559674 > > [3] > > http://infinispan.org/docs/stable/server_guide/server_ > guide.html#general_concepts > > [4] > > https://docs.jboss.org/infinispan/9.1/configdocs/ > infinispan-cachestore-remote-config-9.1.html > > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > -- --Hynek From martin.hardselius at gmail.com Thu Mar 1 09:48:31 2018 From: martin.hardselius at gmail.com (Martin Hardselius) Date: Thu, 01 Mar 2018 14:48:31 +0000 Subject: [keycloak-dev] Pairwise clients and authorization services In-Reply-To: References: Message-ID: 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 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 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 >>>> 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 >>>>>> >>>>> >>>>> >>> From psilva at redhat.com Thu Mar 1 11:10:38 2018 From: psilva at redhat.com (Pedro Igor Silva) Date: Thu, 1 Mar 2018 13:10:38 -0300 Subject: [keycloak-dev] Pairwise clients and authorization services In-Reply-To: References: Message-ID: 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 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 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 >>>>> 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 >>>>>>> >>>>>> >>>>>> >>>> From psilva at redhat.com Thu Mar 1 11:17:57 2018 From: psilva at redhat.com (Pedro Igor Silva) Date: Thu, 1 Mar 2018 13:17:57 -0300 Subject: [keycloak-dev] Pairwise clients and authorization services In-Reply-To: References: Message-ID: 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 wrote: > 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 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 >>>> 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 >>>>>> 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 >>>>>>>> >>>>>>> >>>>>>> >>>>> > From asaldanha1947 at gmail.com Thu Mar 1 11:27:35 2018 From: asaldanha1947 at gmail.com (Anil Saldanha) Date: Thu, 1 Mar 2018 10:27:35 -0600 Subject: [keycloak-dev] Non-UMA Use Cases In-Reply-To: References: Message-ID: Pedro, my personal opinion here. The goal of the Entitlements API is to use for contextual authorization. It does not just rely on user attributes including privacy. There are other aspects to the context - resource attributes, environmental attributes, channel attributes etc. :-) UMA is focused on User managed attributes and privacy controls. While you are trying to unify the api into one under the UMA endpoint umbrella, I feel that it may be better to keep them separate. If the Entitlements API usage by users/applications is very very low, just drop it and start using the new UMA grant type. Regards, Anil On Wed, Feb 28, 2018 at 1:25 PM, Pedro Igor Silva wrote: > Hi, > > There are situations where you don't want to use the UMA protocol to obtain > permissions from the server in form of an access token. Reasons can be: you > don't have any privacy requirements or your requirements don't require all > the UMA dance to obtain an access token. > > In these situations, you may just want to send a request with the resources > and scopes you want to get access and get back the access token with these > permissions. > > This is what we provide today with the Entitlement API, an alternative that > simplifies how clients can obtain permissions from the server. > > However, with the introduction of UMA 2.0 support, we have now a specific > grant type [1] for obtaining permissions from the server using the token > endpoint. Just like any other OAuth2 grant type, the UMA grant type expects > a HTTP FORM request with some parameters. > > The Entitlement API no longer exists but the same behavior can be achieved > with the new UMA grant type that was introduced. In other words, you can > use this grant type to ask for an access token with permissions without > sending a permission ticket but a list of resources/scopes (as parameters) > you want to get access. > > The reason for reusing the grant type is that I would like to avoid having > two endpoints for obtaining permissions from the server. I think it makes > things simple. > > Would like to know your opinion if moving the Entitlement API functionality > to this new grant type makes sense and if, maybe, we should have a specific > grant type (based on UMA grant type) that allows authorization requests > without a permission ticket (but a list of resources and scopes you want to > access). As side note, the code for UMA and non-UMA authorization is pretty > much the same, the main difference is on the format of the authorization > request/protocol. > > [1] https://docs.kantarainitiative.org/uma/wg/oauth-uma-grant-2.0-09.html > > Regards. > Pedro Igor > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > From asaldanha1947 at gmail.com Thu Mar 1 12:06:15 2018 From: asaldanha1947 at gmail.com (Anil Saldanha) Date: Thu, 1 Mar 2018 11:06:15 -0600 Subject: [keycloak-dev] Non-UMA Use Cases In-Reply-To: References: Message-ID: Also Entitlements API is useful in cloud environments or API based billing environments - - you want to minimize the number of calls you make to decide on an access check. This may be different from UMA usecases > On Mar 1, 2018, at 10:27 AM, Anil Saldanha wrote: > > Pedro, > > my personal opinion here. > > The goal of the Entitlements API is to use for contextual authorization. It does not just rely on user attributes including privacy. There are other aspects to the context - resource attributes, environmental attributes, channel attributes etc. :-) > > UMA is focused on User managed attributes and privacy controls. > > While you are trying to unify the api into one under the UMA endpoint umbrella, I feel that it may be better to keep them separate. > > If the Entitlements API usage by users/applications is very very low, just drop it and start using the new UMA grant type. > > Regards, > Anil > >> On Wed, Feb 28, 2018 at 1:25 PM, Pedro Igor Silva wrote: >> Hi, >> >> There are situations where you don't want to use the UMA protocol to obtain >> permissions from the server in form of an access token. Reasons can be: you >> don't have any privacy requirements or your requirements don't require all >> the UMA dance to obtain an access token. >> >> In these situations, you may just want to send a request with the resources >> and scopes you want to get access and get back the access token with these >> permissions. >> >> This is what we provide today with the Entitlement API, an alternative that >> simplifies how clients can obtain permissions from the server. >> >> However, with the introduction of UMA 2.0 support, we have now a specific >> grant type [1] for obtaining permissions from the server using the token >> endpoint. Just like any other OAuth2 grant type, the UMA grant type expects >> a HTTP FORM request with some parameters. >> >> The Entitlement API no longer exists but the same behavior can be achieved >> with the new UMA grant type that was introduced. In other words, you can >> use this grant type to ask for an access token with permissions without >> sending a permission ticket but a list of resources/scopes (as parameters) >> you want to get access. >> >> The reason for reusing the grant type is that I would like to avoid having >> two endpoints for obtaining permissions from the server. I think it makes >> things simple. >> >> Would like to know your opinion if moving the Entitlement API functionality >> to this new grant type makes sense and if, maybe, we should have a specific >> grant type (based on UMA grant type) that allows authorization requests >> without a permission ticket (but a list of resources and scopes you want to >> access). As side note, the code for UMA and non-UMA authorization is pretty >> much the same, the main difference is on the format of the authorization >> request/protocol. >> >> [1] https://docs.kantarainitiative.org/uma/wg/oauth-uma-grant-2.0-09.html >> >> Regards. >> Pedro Igor >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev > From psilva at redhat.com Thu Mar 1 12:24:08 2018 From: psilva at redhat.com (Pedro Igor Silva) Date: Thu, 1 Mar 2018 14:24:08 -0300 Subject: [keycloak-dev] Non-UMA Use Cases In-Reply-To: References: Message-ID: Hey Anil ! I appreciate the feedback. On Thu, Mar 1, 2018 at 1:27 PM, Anil Saldanha wrote: > Pedro, > > my personal opinion here. > > The goal of the Entitlements API is to use for contextual authorization. > It does not just rely on user attributes including privacy. There are > other aspects to the context - resource attributes, environmental > attributes, channel attributes etc. :-) > In addition to that, we try to provide a more lightweight protocol for obtaining permissions from the server. > UMA is focused on User managed attributes and privacy controls. > True but with UMA it should also be possible to push contextual data, considering that the resource server is responsible to create permission tickets and put whatever data they want there. So we can use these same data later when evaluating policies. In Keycloak permission tickets are not persisted and are short-lived. Of course, depending on the "contextual" data you have in a permission ticket more quickly you need use it. Otherwise you may evaluate policies with stale data. > > While you are trying to unify the api into one under the UMA endpoint > umbrella, I feel that it may be better to keep them separate. > I'm not really trying to "unify" both approaches, you know. But have the Entitlement API also working using the standard OAuth2 Token Endpoint, which a specific grant type. Like I said, right now I'm reusing "urn:ietf:params:oauth:grant-type:uma-ticket" but I'm inclined to define a specific grant type for the "entitlement api", something like "urn:ietf:params:oauth:grant-type:kc-entitlement". In a nutshell, the "unification" here is basically an alignment with OAuth2 standard. An extension/custom grant type. > > If the Entitlements API usage by users/applications is very very low, just > drop it and start using the new UMA grant type. > My feeling is that Entitlement API usage is higher than UMA. I think the main reason for that is that people is not yet (but I believe more and more privacy will be a first-class concern to apps and services) concerned about privacy. But security ... and how to protect APIs and application resources. I have seen people get really confused about the UMA dance ... But that is until they understand all motivations and the beauty behind it :) > > Regards, > Anil > > On Wed, Feb 28, 2018 at 1:25 PM, Pedro Igor Silva > wrote: > >> Hi, >> >> There are situations where you don't want to use the UMA protocol to >> obtain >> permissions from the server in form of an access token. Reasons can be: >> you >> don't have any privacy requirements or your requirements don't require all >> the UMA dance to obtain an access token. >> >> In these situations, you may just want to send a request with the >> resources >> and scopes you want to get access and get back the access token with these >> permissions. >> >> This is what we provide today with the Entitlement API, an alternative >> that >> simplifies how clients can obtain permissions from the server. >> >> However, with the introduction of UMA 2.0 support, we have now a specific >> grant type [1] for obtaining permissions from the server using the token >> endpoint. Just like any other OAuth2 grant type, the UMA grant type >> expects >> a HTTP FORM request with some parameters. >> >> The Entitlement API no longer exists but the same behavior can be achieved >> with the new UMA grant type that was introduced. In other words, you can >> use this grant type to ask for an access token with permissions without >> sending a permission ticket but a list of resources/scopes (as parameters) >> you want to get access. >> >> The reason for reusing the grant type is that I would like to avoid having >> two endpoints for obtaining permissions from the server. I think it makes >> things simple. >> >> Would like to know your opinion if moving the Entitlement API >> functionality >> to this new grant type makes sense and if, maybe, we should have a >> specific >> grant type (based on UMA grant type) that allows authorization requests >> without a permission ticket (but a list of resources and scopes you want >> to >> access). As side note, the code for UMA and non-UMA authorization is >> pretty >> much the same, the main difference is on the format of the authorization >> request/protocol. >> >> [1] https://docs.kantarainitiative.org/uma/wg/oauth-uma-grant-2.0-09.html >> >> Regards. >> Pedro Igor >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> > > From psilva at redhat.com Thu Mar 1 12:28:34 2018 From: psilva at redhat.com (Pedro Igor Silva) Date: Thu, 1 Mar 2018 14:28:34 -0300 Subject: [keycloak-dev] Non-UMA Use Cases In-Reply-To: References: Message-ID: On Thu, Mar 1, 2018 at 2:06 PM, Anil Saldanha wrote: > Also Entitlements API is useful in cloud environments or API based billing > environments - - you want to minimize the number of calls you make to > decide on an access check. > > This may be different from UMA usecases > Indeed, they have different audiences .... Although is perfectly fine to use UMA in all these use cases, IMO. The main reason behind the Entitlement API is provide a (UMA-1)-legged protocol for obtaining permissions. > > > On Mar 1, 2018, at 10:27 AM, Anil Saldanha > wrote: > > Pedro, > > my personal opinion here. > > The goal of the Entitlements API is to use for contextual authorization. > It does not just rely on user attributes including privacy. There are > other aspects to the context - resource attributes, environmental > attributes, channel attributes etc. :-) > > UMA is focused on User managed attributes and privacy controls. > > While you are trying to unify the api into one under the UMA endpoint > umbrella, I feel that it may be better to keep them separate. > > If the Entitlements API usage by users/applications is very very low, just > drop it and start using the new UMA grant type. > > Regards, > Anil > > On Wed, Feb 28, 2018 at 1:25 PM, Pedro Igor Silva > wrote: > >> Hi, >> >> There are situations where you don't want to use the UMA protocol to >> obtain >> permissions from the server in form of an access token. Reasons can be: >> you >> don't have any privacy requirements or your requirements don't require all >> the UMA dance to obtain an access token. >> >> In these situations, you may just want to send a request with the >> resources >> and scopes you want to get access and get back the access token with these >> permissions. >> >> This is what we provide today with the Entitlement API, an alternative >> that >> simplifies how clients can obtain permissions from the server. >> >> However, with the introduction of UMA 2.0 support, we have now a specific >> grant type [1] for obtaining permissions from the server using the token >> endpoint. Just like any other OAuth2 grant type, the UMA grant type >> expects >> a HTTP FORM request with some parameters. >> >> The Entitlement API no longer exists but the same behavior can be achieved >> with the new UMA grant type that was introduced. In other words, you can >> use this grant type to ask for an access token with permissions without >> sending a permission ticket but a list of resources/scopes (as parameters) >> you want to get access. >> >> The reason for reusing the grant type is that I would like to avoid having >> two endpoints for obtaining permissions from the server. I think it makes >> things simple. >> >> Would like to know your opinion if moving the Entitlement API >> functionality >> to this new grant type makes sense and if, maybe, we should have a >> specific >> grant type (based on UMA grant type) that allows authorization requests >> without a permission ticket (but a list of resources and scopes you want >> to >> access). As side note, the code for UMA and non-UMA authorization is >> pretty >> much the same, the main difference is on the format of the authorization >> request/protocol. >> >> [1] https://docs.kantarainitiative.org/uma/wg/oauth-uma-grant-2.0-09.html >> >> Regards. >> Pedro Igor >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> > > From asaldanha1947 at gmail.com Thu Mar 1 12:28:40 2018 From: asaldanha1947 at gmail.com (Anil Saldanha) Date: Thu, 1 Mar 2018 11:28:40 -0600 Subject: [keycloak-dev] Non-UMA Use Cases In-Reply-To: References: Message-ID: Authorization is pretty hard for people to wrap their heads around. Now if you try to push the UMA dance (however good it is) as the holy grail for all your authorization needs, it may make things more confusing. That is why people just stick to authentication and passwords because everything else is hard. :) On Thu, Mar 1, 2018 at 11:24 AM, Pedro Igor Silva wrote: > Hey Anil ! > > I appreciate the feedback. > > On Thu, Mar 1, 2018 at 1:27 PM, Anil Saldanha > wrote: > >> Pedro, >> >> my personal opinion here. >> >> The goal of the Entitlements API is to use for contextual authorization. >> It does not just rely on user attributes including privacy. There are >> other aspects to the context - resource attributes, environmental >> attributes, channel attributes etc. :-) >> > > In addition to that, we try to provide a more lightweight protocol for > obtaining permissions from the server. > > > >> UMA is focused on User managed attributes and privacy controls. >> > > True but with UMA it should also be possible to push contextual data, > considering that the resource server is responsible to create permission > tickets and put whatever data they want there. So we can use these same > data later when evaluating policies. In Keycloak permission tickets are > not persisted and are short-lived. Of course, depending on the "contextual" > data you have in a permission ticket more quickly you need use it. > Otherwise you may evaluate policies with stale data. > > >> >> While you are trying to unify the api into one under the UMA endpoint >> umbrella, I feel that it may be better to keep them separate. >> > > I'm not really trying to "unify" both approaches, you know. But have the > Entitlement API also working using the standard OAuth2 Token Endpoint, > which a specific grant type. Like I said, right now I'm reusing > "urn:ietf:params:oauth:grant-type:uma-ticket" but I'm inclined to define > a specific grant type for the "entitlement api", something like > "urn:ietf:params:oauth:grant-type:kc-entitlement". > > In a nutshell, the "unification" here is basically an alignment with > OAuth2 standard. An extension/custom grant type. > > >> >> If the Entitlements API usage by users/applications is very very low, >> just drop it and start using the new UMA grant type. >> > > My feeling is that Entitlement API usage is higher than UMA. I think the > main reason for that is that people is not yet (but I believe more and more > privacy will be a first-class concern to apps and services) concerned about > privacy. But security ... and how to protect APIs and application resources. > > I have seen people get really confused about the UMA dance ... But that is > until they understand all motivations and the beauty behind it :) > > >> >> Regards, >> Anil >> >> On Wed, Feb 28, 2018 at 1:25 PM, Pedro Igor Silva >> wrote: >> >>> Hi, >>> >>> There are situations where you don't want to use the UMA protocol to >>> obtain >>> permissions from the server in form of an access token. Reasons can be: >>> you >>> don't have any privacy requirements or your requirements don't require >>> all >>> the UMA dance to obtain an access token. >>> >>> In these situations, you may just want to send a request with the >>> resources >>> and scopes you want to get access and get back the access token with >>> these >>> permissions. >>> >>> This is what we provide today with the Entitlement API, an alternative >>> that >>> simplifies how clients can obtain permissions from the server. >>> >>> However, with the introduction of UMA 2.0 support, we have now a specific >>> grant type [1] for obtaining permissions from the server using the token >>> endpoint. Just like any other OAuth2 grant type, the UMA grant type >>> expects >>> a HTTP FORM request with some parameters. >>> >>> The Entitlement API no longer exists but the same behavior can be >>> achieved >>> with the new UMA grant type that was introduced. In other words, you can >>> use this grant type to ask for an access token with permissions without >>> sending a permission ticket but a list of resources/scopes (as >>> parameters) >>> you want to get access. >>> >>> The reason for reusing the grant type is that I would like to avoid >>> having >>> two endpoints for obtaining permissions from the server. I think it makes >>> things simple. >>> >>> Would like to know your opinion if moving the Entitlement API >>> functionality >>> to this new grant type makes sense and if, maybe, we should have a >>> specific >>> grant type (based on UMA grant type) that allows authorization requests >>> without a permission ticket (but a list of resources and scopes you want >>> to >>> access). As side note, the code for UMA and non-UMA authorization is >>> pretty >>> much the same, the main difference is on the format of the authorization >>> request/protocol. >>> >>> [1] https://docs.kantarainitiative.org/uma/wg/oauth-uma-grant-2. >>> 0-09.html >>> >>> Regards. >>> Pedro Igor >>> _______________________________________________ >>> keycloak-dev mailing list >>> keycloak-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>> >> >> > From psilva at redhat.com Thu Mar 1 12:32:43 2018 From: psilva at redhat.com (Pedro Igor Silva) Date: Thu, 1 Mar 2018 14:32:43 -0300 Subject: [keycloak-dev] Non-UMA Use Cases In-Reply-To: References: Message-ID: Yeah ... that is a reality. Authorization is not easy. At least if you think beyond simple RBAC. But I think things are changing, authorization requirements are becoming more complex (including now privacy), with all this cloud native stuff and everything being externalized from apps ... A lot of challenges .... On Thu, Mar 1, 2018 at 2:28 PM, Anil Saldanha wrote: > Authorization is pretty hard for people to wrap their heads around. Now > if you try to push the UMA dance (however good it is) as the holy grail for > all your authorization needs, it may make things more confusing. That is > why people just stick to authentication and passwords because everything > else is hard. :) > > On Thu, Mar 1, 2018 at 11:24 AM, Pedro Igor Silva > wrote: > >> Hey Anil ! >> >> I appreciate the feedback. >> >> On Thu, Mar 1, 2018 at 1:27 PM, Anil Saldanha >> wrote: >> >>> Pedro, >>> >>> my personal opinion here. >>> >>> The goal of the Entitlements API is to use for contextual >>> authorization. It does not just rely on user attributes including >>> privacy. There are other aspects to the context - resource attributes, >>> environmental attributes, channel attributes etc. :-) >>> >> >> In addition to that, we try to provide a more lightweight protocol for >> obtaining permissions from the server. >> >> >> >>> UMA is focused on User managed attributes and privacy controls. >>> >> >> True but with UMA it should also be possible to push contextual data, >> considering that the resource server is responsible to create permission >> tickets and put whatever data they want there. So we can use these same >> data later when evaluating policies. In Keycloak permission tickets are >> not persisted and are short-lived. Of course, depending on the "contextual" >> data you have in a permission ticket more quickly you need use it. >> Otherwise you may evaluate policies with stale data. >> >> >>> >>> While you are trying to unify the api into one under the UMA endpoint >>> umbrella, I feel that it may be better to keep them separate. >>> >> >> I'm not really trying to "unify" both approaches, you know. But have the >> Entitlement API also working using the standard OAuth2 Token Endpoint, >> which a specific grant type. Like I said, right now I'm reusing >> "urn:ietf:params:oauth:grant-type:uma-ticket" but I'm inclined to define >> a specific grant type for the "entitlement api", something like >> "urn:ietf:params:oauth:grant-type:kc-entitlement". >> >> In a nutshell, the "unification" here is basically an alignment with >> OAuth2 standard. An extension/custom grant type. >> >> >>> >>> If the Entitlements API usage by users/applications is very very low, >>> just drop it and start using the new UMA grant type. >>> >> >> My feeling is that Entitlement API usage is higher than UMA. I think the >> main reason for that is that people is not yet (but I believe more and more >> privacy will be a first-class concern to apps and services) concerned about >> privacy. But security ... and how to protect APIs and application resources. >> >> I have seen people get really confused about the UMA dance ... But that >> is until they understand all motivations and the beauty behind it :) >> >> >>> >>> Regards, >>> Anil >>> >>> On Wed, Feb 28, 2018 at 1:25 PM, Pedro Igor Silva >>> wrote: >>> >>>> Hi, >>>> >>>> There are situations where you don't want to use the UMA protocol to >>>> obtain >>>> permissions from the server in form of an access token. Reasons can be: >>>> you >>>> don't have any privacy requirements or your requirements don't require >>>> all >>>> the UMA dance to obtain an access token. >>>> >>>> In these situations, you may just want to send a request with the >>>> resources >>>> and scopes you want to get access and get back the access token with >>>> these >>>> permissions. >>>> >>>> This is what we provide today with the Entitlement API, an alternative >>>> that >>>> simplifies how clients can obtain permissions from the server. >>>> >>>> However, with the introduction of UMA 2.0 support, we have now a >>>> specific >>>> grant type [1] for obtaining permissions from the server using the token >>>> endpoint. Just like any other OAuth2 grant type, the UMA grant type >>>> expects >>>> a HTTP FORM request with some parameters. >>>> >>>> The Entitlement API no longer exists but the same behavior can be >>>> achieved >>>> with the new UMA grant type that was introduced. In other words, you can >>>> use this grant type to ask for an access token with permissions without >>>> sending a permission ticket but a list of resources/scopes (as >>>> parameters) >>>> you want to get access. >>>> >>>> The reason for reusing the grant type is that I would like to avoid >>>> having >>>> two endpoints for obtaining permissions from the server. I think it >>>> makes >>>> things simple. >>>> >>>> Would like to know your opinion if moving the Entitlement API >>>> functionality >>>> to this new grant type makes sense and if, maybe, we should have a >>>> specific >>>> grant type (based on UMA grant type) that allows authorization requests >>>> without a permission ticket (but a list of resources and scopes you >>>> want to >>>> access). As side note, the code for UMA and non-UMA authorization is >>>> pretty >>>> much the same, the main difference is on the format of the authorization >>>> request/protocol. >>>> >>>> [1] https://docs.kantarainitiative.org/uma/wg/oauth-uma-grant-2. >>>> 0-09.html >>>> >>>> Regards. >>>> Pedro Igor >>>> _______________________________________________ >>>> keycloak-dev mailing list >>>> keycloak-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>>> >>> >>> >> > From martin.hardselius at gmail.com Thu Mar 1 14:03:31 2018 From: martin.hardselius at gmail.com (Martin Hardselius) Date: Thu, 01 Mar 2018 19:03:31 +0000 Subject: [keycloak-dev] Pairwise clients and authorization services In-Reply-To: References: Message-ID: Rebase is all good. PR sent: https://github.com/keycloak/keycloak/pull/5050 - Martin On Thu, 1 Mar 2018 at 17:17 Pedro Igor Silva wrote: > 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 > wrote: > >> 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 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 >>>>> 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 >>>>>>> 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 >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>> >> > From mposolda at redhat.com Fri Mar 2 07:05:09 2018 From: mposolda at redhat.com (Marek Posolda) Date: Fri, 2 Mar 2018 13:05:09 +0100 Subject: [keycloak-dev] Cross-datacenter configuration issues In-Reply-To: <1190516630.5452826.1519915371405.JavaMail.zimbra@redhat.com> References: <1190516630.5452826.1519915371405.JavaMail.zimbra@redhat.com> Message-ID: <8a133b3f-fbf1-570b-5a79-8be9e01fd5ed@redhat.com> Thanks William for the help! I've tried your approach (1) and I've updated just infinispan-cachestore-remote to 9.1.6 and left the other dependencies not updated. It failed for me with some NoClassDefFoundErrors. This is not so surprising as the other infinispan modules and also wildfly-clustering integration and parser modules were still using the old 8.2.8 versions and there seem to be some API incompatibility though, which break things. Here is stacktrace if you want to take a look: https://pastebin.com/hzDSX2um In the end, I've chosen a bit different solution, which works for me. The RemoteStore of 8.2.8 doesn't support "security" but the RemoteCache of 8.2.8 supports that. So I've changed some integration code on Keycloak side to read RemoteCache configuration, which is retrieved from the RemoteStore, and use it as a configuration template. Then I've programatically added security into it and retrieve "secured" RemoteCacheManager to access '__script_cache' and some parts of our code, which need to execute remote scripts. See [1]. The RemoteStore itself is not secured. So on JDG side, I need to keep 2 hotrod endpoints (one unsecured accessed by RemoteStores and second secured accessed by __script cache). I've added setup instructions to the JIRA: [2] . Jared, I hope this can help you to have things working. There maybe also another approach, which Hynek pointed, that we will somehow bypass security on JDG side at all. Picketbox has some login modules like org.jboss.security.auth.spi.AnonLoginModule and org.jboss.security.auth.spi.IdentityLoginModule, which might allow to configure JAAS realm in a way that "anonymous" user will be automatically authenticated and role ___script_manager' granted to him. In other words, this is completely bypass security. But possibly it may allow to have things working without require changes on Keycloak code. Another thing is, that I didn't manage to have it working, but I didn't try to deeply and I am not too familiar with the Wildfly security + picketbox stuff. So to summary, The approaches I see is: (1) Upgrade all infinispan modules in Keycloak to use 9.1.6 (or JDG 7.2.ER4). Will require to upgrade wildfly infinispan subsystem and bunch of other dependencies (maybe whole EAP in the end). I guess it's not an option regarding support, testing etc. On the other hand, it will allow to configure RemoteStore security OOTB. (2) Create our own subclass of Infinispan RemoteStore on Keycloak side, which will allow to configure secure RemoteCache instances. Will require changes on Keycloak sources, and also in the Keycloak servers configuration, which will need to use new implementation of RemoteStore, so the configuration of the RemoteStore will be completely changed. (3) Use the approach, which works for me and which I put in JIRA. So have 2 hotrod endpoints on JDG side (unsecured and secured). RemoteStore access the unsecured endpoint. Just some sources, which deals with __script cache, access the secured hotrod endpoint. This requires to "patch" module keycloak-model-infinispan on RHSSO side and also require some smaller changes in the configuration (some new configuration properties are added on RHSSO side to allow configuration of hotrod endpoint security, username ,password etc). (4) Bypass JDG security entirely with some picketbox "anonymous access" JAAS login modules. I didn't manage to have it working and it completely bypass security. On the other hand, it seems to be the only solution, which won't require changes on Keycloak/RHSSO side. But we don't know yet if it works... For now, my vote is to go with (3) and it's the only working. Any more options? [1] https://github.com/mposolda/keycloak/blob/jdg-security/model/infinispan/src/main/java/org/keycloak/connections/infinispan/RemoteCacheProvider.java#L110-L149 [2] https://issues.jboss.org/browse/KEYCLOAK-6783?focusedCommentId=13540721&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13540721 Marek On 01/03/18 15:42, William Burns wrote: > So I was helping out Jared when found this issue. > > This is caused by a combination of issues due to varying versions (Infinispaan 8.2.8 and JDG 7.1) > > 1. JDG 7.1 only allows accessing internal caches remotely over loopback or when authorization is enabled. This came about in Infinispan 9.0 in [a] > 2. Infinispan 8.2.6 does not allow for remote cache stores to use authentication. This was added in Infinispan 9.0.(2|3) and 9.1 in [b] > > Unfortunately with the combination of the 2 there is now way for an ISPN pre 9.0.2 from accessing a remote server 9.0 internal caches not on loopback, such as the script cache. > > There are 2 ways that I was able to come up with (thanks Tristan for the second) > > 1. Replace the infinispan-cachestore-remote.jar in the ISPN 8.2.6 install to have a newer version such as 9.1.6.Final at [c]. This should allow the 8.2.8 instance to use authorization on the remote store. I have not tested this, but everything should be contained in the jar (including parser). > 2. Use JDG 7.2.ER4 or newer in the keycloak EAP instances as a module. This is the first version that allows for the user to deploy their own version of JDG as a module accessible over JNDI. > > - Will > > [a] https://issues.jboss.org/browse/ISPN-6457 > [b] https://issues.jboss.org/browse/ISPN-7868 > [c] https://mvnrepository.com/artifact/org.infinispan/infinispan-cachestore-remote > > ----- Original Message ----- >> From: "Hynek Mlnarik" >> To: "Jared Blashka" >> Cc: "Marek Posolda" , "Boleslaw Dawidowicz" , "keycloak-dev" >> , "William Burns" , "iam-list" >> Sent: Thursday, March 1, 2018 3:33:17 AM >> Subject: Re: [keycloak-dev] Cross-datacenter configuration issues >> >> I can only agree that it seems to be a difference between Infinispan server >> and JDG, since we did test it in Amazon where each instance of Keycloak and >> Infinispan was installed on separate VM [1]. Whether this difference might >> be indeed there should be confirmed by someone from JDG team. William, >> could you please comment here? >> >> [1] >> http://blog.keycloak.org/2018/01/keycloak-cross-data-center-setup-in-aws.html >> >> On Thu, Mar 1, 2018 at 9:25 AM, Marek Posolda wrote: >> >>> I've just simulated the issue and created >>> https://issues.jboss.org/browse/KEYCLOAK-6783 . I am looking at it. >>> >>> What works and what we tested is: >>> >>> * Setup with infinispan-server-8.2.8 on "local" network (infinispan >>> server bind on loopback address like "localhost" . Different >>> infinispan servers running on the same laptop, but on various port >>> offsets) >>> >>> * Setup with JDG server 7.1.0 on "local" network (JDG server bound on >>> loopback address like "localhost" . Different JDG servers running on >>> the same laptop, but on various port offsets) >>> >>> * Setup with infinispan-server-8.2.8 on "real" network (testing with >>> infinispan hosts bound to real host with IP addresses like 192.168.0.1 >>> ) >>> >>> We didn't test the combination with JDG server bind on "real" addresses >>> and this is the only one where the issue happens >>> >>> It seems JDG 7.1.0 has some additional security when compared with the >>> community infinispan-server 8.2.8 . >>> >>> The easiest workaround for you might be to test with community >>> infinispan-server 8.2.8 instead of JDG 7.1.0 . Server can be downloaded >>> from this address: >>> http://downloads.jboss.org/infinispan/8.2.8.Final/ >>> infinispan-server-8.2.8.Final-bin.zip >>> . >>> >>> I hope to update you later today once I have some more info. Thanks for >>> the report and all the details you mentioned. >>> >>> Marek >>> >>> >>> On 28/02/18 21:36, Jared Blashka wrote: >>>> Hey all, >>>> >>>> I'm working on testing out the cross-datacenter replication >>>> configuration in our development environment and I'm running into some >>>> issues. >>>> >>>> I stood up some JDG 7.1 instances and some RH-SSO 7.2 instances all >>>> running on my localhost all with different port offsets, followed the >>>> instructions[1], and everything seemed to work well enough. >>>> >>>> Once I got beyond that and tried running RH-SSO and JDG on separate >>>> servers I started running into issues[2] during RH-SSO startup. Looks >>>> like RH-SSO is unable to connect to the remote ___script_cache but >>>> that cache isn't mentioned anywhere in the RH-SSO documentation. The >>>> error message (and online searching) indicates that this cache only >>>> allows remote connections if authorization is enabled. I didn't see >>>> any mention of configuration related to authentication or security for >>>> the remote caches in the documentation either. >>>> >>>> At this point we roped in a JDG expert (cc'ed here) and found some >>>> additional Infinispan documentation[3] on how to add authentication to >>>> the *remote* caches within the JDG configuration but nothing much in >>>> the way of adding authentication to the client cache configuration >>>> inside RH-SSO that didn't involve programmatic changes. After some >>>> additional searching we found some info[4] detailing how to add >>>> security configurations to a remote-cache configuration in Infinispan >>>> *9.1* but EAP 7.1 is only running Infinispan *8.2* which doesn't have >>>> these changes. >>>> >>>> How did you get this working? >>>> >>>> Jared Blashka - Identity & Access Management >>>> >>>> >>>> [1] >>>> https://access.redhat.com/documentation/en-us/red_hat_ >>> single_sign-on/7.2/pdf/server_installation_and_ >>> configuration_guide/Red_Hat_Single_Sign-On-7.2-Server_Installation_and_ >>> Configuration_Guide-en-US.pdf#__WKANCHOR_1e >>>> [2] http://pastebin.test.redhat.com/559674 >>>> [3] >>>> http://infinispan.org/docs/stable/server_guide/server_ >>> guide.html#general_concepts >>>> [4] >>>> https://docs.jboss.org/infinispan/9.1/configdocs/ >>> infinispan-cachestore-remote-config-9.1.html >>> >>> >>> _______________________________________________ >>> keycloak-dev mailing list >>> keycloak-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>> >> >> >> -- >> >> --Hynek >> From wburns at redhat.com Fri Mar 2 09:24:30 2018 From: wburns at redhat.com (William Burns) Date: Fri, 2 Mar 2018 09:24:30 -0500 (EST) Subject: [keycloak-dev] Cross-datacenter configuration issues In-Reply-To: <8a133b3f-fbf1-570b-5a79-8be9e01fd5ed@redhat.com> References: <1190516630.5452826.1519915371405.JavaMail.zimbra@redhat.com> <8a133b3f-fbf1-570b-5a79-8be9e01fd5ed@redhat.com> Message-ID: <667192371.5842268.1520000670050.JavaMail.zimbra@redhat.com> ----- Original Message ----- > From: "Marek Posolda" > To: "William Burns" , "Hynek Mlnarik" > Cc: "Jared Blashka" , "Boleslaw Dawidowicz" , "keycloak-dev" > , "iam-list" , "Tristan Tarrant" , "Pedro > Zapata Fernandez" > Sent: Friday, March 2, 2018 7:05:09 AM > Subject: Re: [keycloak-dev] Cross-datacenter configuration issues > > Thanks William for the help! > > I've tried your approach (1) and I've updated just > infinispan-cachestore-remote to 9.1.6 and left the other dependencies > not updated. It failed for me with some NoClassDefFoundErrors. This is > not so surprising as the other infinispan modules and also > wildfly-clustering integration and parser modules were still using the > old 8.2.8 versions and there seem to be some API incompatibility though, > which break things. Here is stacktrace if you want to take a look: > https://pastebin.com/hzDSX2um Yeah actually I was talking with Jared about this yesterday. Unfortunately it doesn't work. I was thinking of the embedded mode which allows you to use custom parsers. So this isn't an option. > > In the end, I've chosen a bit different solution, which works for me. > The RemoteStore of 8.2.8 doesn't support "security" but the RemoteCache > of 8.2.8 supports that. So I've changed some integration code on > Keycloak side to read RemoteCache configuration, which is retrieved from > the RemoteStore, and use it as a configuration template. Then I've > programatically added security into it and retrieve "secured" > RemoteCacheManager to access '__script_cache' and some parts of our > code, which need to execute remote scripts. See [1]. > > The RemoteStore itself is not secured. So on JDG side, I need to keep 2 > hotrod endpoints (one unsecured accessed by RemoteStores and second > secured accessed by __script cache). I've added setup instructions to > the JIRA: [2] . Jared, I hope this can help you to have things working. > > There maybe also another approach, which Hynek pointed, that we will > somehow bypass security on JDG side at all. Picketbox has some login > modules like org.jboss.security.auth.spi.AnonLoginModule and > org.jboss.security.auth.spi.IdentityLoginModule, which might allow to > configure JAAS realm in a way that "anonymous" user will be > automatically authenticated and role ___script_manager' granted to him. > In other words, this is completely bypass security. But possibly it may > allow to have things working without require changes on Keycloak code. > Another thing is, that I didn't manage to have it working, but I didn't > try to deeply and I am not too familiar with the Wildfly security + > picketbox stuff. > > So to summary, The approaches I see is: > > (1) Upgrade all infinispan modules in Keycloak to use 9.1.6 (or JDG > 7.2.ER4). Will require to upgrade wildfly infinispan subsystem and bunch > of other dependencies (maybe whole EAP in the end). I guess it's not an > option regarding support, testing etc. On the other hand, it will allow > to configure RemoteStore security OOTB. You and others are more familiar with how modules work. TBH I am not that familiar, but this sounds like a no go to me as well. > > (2) Create our own subclass of Infinispan RemoteStore on Keycloak side, > which will allow to configure secure RemoteCache instances. Will require > changes on Keycloak sources, and also in the Keycloak servers > configuration, which will need to use new implementation of RemoteStore, > so the configuration of the RemoteStore will be completely changed. > > (3) Use the approach, which works for me and which I put in JIRA. So > have 2 hotrod endpoints on JDG side (unsecured and secured). RemoteStore > access the unsecured endpoint. Just some sources, which deals with > __script cache, access the secured hotrod endpoint. This requires to > "patch" module keycloak-model-infinispan on RHSSO side and also require > some smaller changes in the configuration (some new configuration > properties are added on RHSSO side to allow configuration of hotrod > endpoint security, username ,password etc). > > (4) Bypass JDG security entirely with some picketbox "anonymous access" > JAAS login modules. I didn't manage to have it working and it completely > bypass security. On the other hand, it seems to be the only solution, > which won't require changes on Keycloak/RHSSO side. But we don't know > yet if it works... Actually there is another way to bypass security that Tristan brought up that we were was discussing. For JDG 7.2.CR1 we can relax access to protected caches, such as scriptcache, so that there is no global authorization check (removing a single if block). This way the cache just uses the normal authorization checks if it is even enabled for that cache. Unfortunately CR1 is not going to be available for another 3 weeks though. In the mean time Jared and I discussed just testing with community server version 8.2.8 for the standalone install until we can get JDG 7.2.CR1 installed there. He may even want to test with something a little newer. Unfortunately that means that this version of keycloak would only work with JDG 7.2.0.CR1 or ISPN 9.0.3 [1] and newer. Either way I will be creating a PR for this on the JDG 7.2 branch today. [1] https://issues.jboss.org/browse/ISPN-7814 > > For now, my vote is to go with (3) and it's the only working. Any more > options? > > [1] > https://github.com/mposolda/keycloak/blob/jdg-security/model/infinispan/src/main/java/org/keycloak/connections/infinispan/RemoteCacheProvider.java#L110-L149 > [2] > https://issues.jboss.org/browse/KEYCLOAK-6783?focusedCommentId=13540721&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13540721 > > Marek > > > On 01/03/18 15:42, William Burns wrote: > > So I was helping out Jared when found this issue. > > > > This is caused by a combination of issues due to varying versions > > (Infinispaan 8.2.8 and JDG 7.1) > > > > 1. JDG 7.1 only allows accessing internal caches remotely over loopback or > > when authorization is enabled. This came about in Infinispan 9.0 in [a] > > 2. Infinispan 8.2.6 does not allow for remote cache stores to use > > authentication. This was added in Infinispan 9.0.(2|3) and 9.1 in [b] > > > > Unfortunately with the combination of the 2 there is now way for an ISPN > > pre 9.0.2 from accessing a remote server 9.0 internal caches not on > > loopback, such as the script cache. > > > > There are 2 ways that I was able to come up with (thanks Tristan for the > > second) > > > > 1. Replace the infinispan-cachestore-remote.jar in the ISPN 8.2.6 install > > to have a newer version such as 9.1.6.Final at [c]. This should allow the > > 8.2.8 instance to use authorization on the remote store. I have not tested > > this, but everything should be contained in the jar (including parser). > > 2. Use JDG 7.2.ER4 or newer in the keycloak EAP instances as a module. This > > is the first version that allows for the user to deploy their own version > > of JDG as a module accessible over JNDI. > > > > - Will > > > > [a] https://issues.jboss.org/browse/ISPN-6457 > > [b] https://issues.jboss.org/browse/ISPN-7868 > > [c] > > https://mvnrepository.com/artifact/org.infinispan/infinispan-cachestore-remote > > > > ----- Original Message ----- > >> From: "Hynek Mlnarik" > >> To: "Jared Blashka" > >> Cc: "Marek Posolda" , "Boleslaw Dawidowicz" > >> , "keycloak-dev" > >> , "William Burns" , > >> "iam-list" > >> Sent: Thursday, March 1, 2018 3:33:17 AM > >> Subject: Re: [keycloak-dev] Cross-datacenter configuration issues > >> > >> I can only agree that it seems to be a difference between Infinispan > >> server > >> and JDG, since we did test it in Amazon where each instance of Keycloak > >> and > >> Infinispan was installed on separate VM [1]. Whether this difference might > >> be indeed there should be confirmed by someone from JDG team. William, > >> could you please comment here? > >> > >> [1] > >> http://blog.keycloak.org/2018/01/keycloak-cross-data-center-setup-in-aws.html > >> > >> On Thu, Mar 1, 2018 at 9:25 AM, Marek Posolda wrote: > >> > >>> I've just simulated the issue and created > >>> https://issues.jboss.org/browse/KEYCLOAK-6783 . I am looking at it. > >>> > >>> What works and what we tested is: > >>> > >>> * Setup with infinispan-server-8.2.8 on "local" network (infinispan > >>> server bind on loopback address like "localhost" . Different > >>> infinispan servers running on the same laptop, but on various port > >>> offsets) > >>> > >>> * Setup with JDG server 7.1.0 on "local" network (JDG server bound on > >>> loopback address like "localhost" . Different JDG servers running on > >>> the same laptop, but on various port offsets) > >>> > >>> * Setup with infinispan-server-8.2.8 on "real" network (testing with > >>> infinispan hosts bound to real host with IP addresses like > >>> 192.168.0.1 > >>> ) > >>> > >>> We didn't test the combination with JDG server bind on "real" addresses > >>> and this is the only one where the issue happens > >>> > >>> It seems JDG 7.1.0 has some additional security when compared with the > >>> community infinispan-server 8.2.8 . > >>> > >>> The easiest workaround for you might be to test with community > >>> infinispan-server 8.2.8 instead of JDG 7.1.0 . Server can be downloaded > >>> from this address: > >>> http://downloads.jboss.org/infinispan/8.2.8.Final/ > >>> infinispan-server-8.2.8.Final-bin.zip > >>> . > >>> > >>> I hope to update you later today once I have some more info. Thanks for > >>> the report and all the details you mentioned. > >>> > >>> Marek > >>> > >>> > >>> On 28/02/18 21:36, Jared Blashka wrote: > >>>> Hey all, > >>>> > >>>> I'm working on testing out the cross-datacenter replication > >>>> configuration in our development environment and I'm running into some > >>>> issues. > >>>> > >>>> I stood up some JDG 7.1 instances and some RH-SSO 7.2 instances all > >>>> running on my localhost all with different port offsets, followed the > >>>> instructions[1], and everything seemed to work well enough. > >>>> > >>>> Once I got beyond that and tried running RH-SSO and JDG on separate > >>>> servers I started running into issues[2] during RH-SSO startup. Looks > >>>> like RH-SSO is unable to connect to the remote ___script_cache but > >>>> that cache isn't mentioned anywhere in the RH-SSO documentation. The > >>>> error message (and online searching) indicates that this cache only > >>>> allows remote connections if authorization is enabled. I didn't see > >>>> any mention of configuration related to authentication or security for > >>>> the remote caches in the documentation either. > >>>> > >>>> At this point we roped in a JDG expert (cc'ed here) and found some > >>>> additional Infinispan documentation[3] on how to add authentication to > >>>> the *remote* caches within the JDG configuration but nothing much in > >>>> the way of adding authentication to the client cache configuration > >>>> inside RH-SSO that didn't involve programmatic changes. After some > >>>> additional searching we found some info[4] detailing how to add > >>>> security configurations to a remote-cache configuration in Infinispan > >>>> *9.1* but EAP 7.1 is only running Infinispan *8.2* which doesn't have > >>>> these changes. > >>>> > >>>> How did you get this working? > >>>> > >>>> Jared Blashka - Identity & Access Management > >>>> > >>>> > >>>> [1] > >>>> https://access.redhat.com/documentation/en-us/red_hat_ > >>> single_sign-on/7.2/pdf/server_installation_and_ > >>> configuration_guide/Red_Hat_Single_Sign-On-7.2-Server_Installation_and_ > >>> Configuration_Guide-en-US.pdf#__WKANCHOR_1e > >>>> [2] http://pastebin.test.redhat.com/559674 > >>>> [3] > >>>> http://infinispan.org/docs/stable/server_guide/server_ > >>> guide.html#general_concepts > >>>> [4] > >>>> https://docs.jboss.org/infinispan/9.1/configdocs/ > >>> infinispan-cachestore-remote-config-9.1.html > >>> > >>> > >>> _______________________________________________ > >>> keycloak-dev mailing list > >>> keycloak-dev at lists.jboss.org > >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev > >>> > >> > >> > >> -- > >> > >> --Hynek > >> > > From mposolda at redhat.com Fri Mar 2 12:20:18 2018 From: mposolda at redhat.com (Marek Posolda) Date: Fri, 2 Mar 2018 18:20:18 +0100 Subject: [keycloak-dev] Cross-datacenter configuration issues In-Reply-To: <667192371.5842268.1520000670050.JavaMail.zimbra@redhat.com> References: <1190516630.5452826.1519915371405.JavaMail.zimbra@redhat.com> <8a133b3f-fbf1-570b-5a79-8be9e01fd5ed@redhat.com> <667192371.5842268.1520000670050.JavaMail.zimbra@redhat.com> Message-ID: On 02/03/18 15:24, William Burns wrote: >> (3) Use the approach, which works for me and which I put in JIRA. So >> have 2 hotrod endpoints on JDG side (unsecured and secured). RemoteStore >> access the unsecured endpoint. Just some sources, which deals with >> __script cache, access the secured hotrod endpoint. This requires to >> "patch" module keycloak-model-infinispan on RHSSO side and also require >> some smaller changes in the configuration (some new configuration >> properties are added on RHSSO side to allow configuration of hotrod >> endpoint security, username ,password etc). >> >> (4) Bypass JDG security entirely with some picketbox "anonymous access" >> JAAS login modules. I didn't manage to have it working and it completely >> bypass security. On the other hand, it seems to be the only solution, >> which won't require changes on Keycloak/RHSSO side. But we don't know >> yet if it works... > Actually there is another way to bypass security that Tristan brought up that we were was discussing. For JDG 7.2.CR1 we can relax access to protected caches, such as scriptcache, so that there is no global authorization check (removing a single if block). This way the cache just uses the normal authorization checks if it is even enabled for that cache. Unfortunately CR1 is not going to be available for another 3 weeks though. In the mean time Jared and I discussed just testing with community server version 8.2.8 for the standalone install until we can get JDG 7.2.CR1 installed there. He may even want to test with something a little newer. Thanks for the update. If Jared is fine to temporarily test with Infinispan server 8.2.8, it's cool. We will try to see if we can bypass security even for JDG 7.1 (Hynek is looking into picketbox "anonymous" modules) and there is this patch from me to secure access to "_script" cache, which works with 7.1, but will require to patch Keycloak/RHSSO. I afraid we can officially update to JDG 7.2 at the moment, when 7.2.GA is released. However it may be good to test early with 7.2, so we can find earlier if some fixes are needed on JDG side and notify you before GA. Hopefully we have time for trying that... :) BTV. Will JDG 7.2 have better "pagination" support for RemoteCaches, so I can do something like: remoteCache.keySet().stream().skip(100).limit(10).collect(Collectors.toList()); to ensure that just 10 items from 100 to 110 are sent over the network? And will it have Server tasks support? If yes, we will be hopefully able to get rid of remote scripting entirely :) But problem is also "client" (Keycloak) side as we rely on the infinispan version provided by Wildfly/EAP. In other words, we are always few months (or years?) behind all the cool features and fixes, which you are currently developing in infinispan master :( Marek > > Unfortunately that means that this version of keycloak would only work with JDG 7.2.0.CR1 or ISPN 9.0.3 [1] and newer. Either way I will be creating a PR for this on the JDG 7.2 branch today. > > [1]https://issues.jboss.org/browse/ISPN-7814 > From wburns at redhat.com Sat Mar 3 17:40:50 2018 From: wburns at redhat.com (William Burns) Date: Sat, 3 Mar 2018 17:40:50 -0500 (EST) Subject: [keycloak-dev] [IAM] Cross-datacenter configuration issues In-Reply-To: <13F5E052-4210-4D57-BA05-34140A4535C4@redhat.com> References: <1190516630.5452826.1519915371405.JavaMail.zimbra@redhat.com> <8a133b3f-fbf1-570b-5a79-8be9e01fd5ed@redhat.com> <667192371.5842268.1520000670050.JavaMail.zimbra@redhat.com> <13F5E052-4210-4D57-BA05-34140A4535C4@redhat.com> Message-ID: <1067619488.6003904.1520116850668.JavaMail.zimbra@redhat.com> ----- Original Message ----- > From: "Brian Atkisson" > To: "Marek Posolda" > Cc: "William Burns" , "Pedro Zapata Fernandez" , "iam-list" > , "keycloak-dev" , "Hynek Mlnarik" , > "Tristan Tarrant" , "Boleslaw Dawidowicz" , mmccomas at redhat.com > Sent: Friday, March 2, 2018 6:52:19 PM > Subject: Re: [IAM] [keycloak-dev] Cross-datacenter configuration issues > > +Mike > > > On Mar 2, 2018, at 12:20 PM, Marek Posolda wrote: > > > >> On 02/03/18 15:24, William Burns wrote: > >>> (3) Use the approach, which works for me and which I put in JIRA. So > >>> have 2 hotrod endpoints on JDG side (unsecured and secured). RemoteStore > >>> access the unsecured endpoint. Just some sources, which deals with > >>> __script cache, access the secured hotrod endpoint. This requires to > >>> "patch" module keycloak-model-infinispan on RHSSO side and also require > >>> some smaller changes in the configuration (some new configuration > >>> properties are added on RHSSO side to allow configuration of hotrod > >>> endpoint security, username ,password etc). > >>> > >>> (4) Bypass JDG security entirely with some picketbox "anonymous access" > >>> JAAS login modules. I didn't manage to have it working and it completely > >>> bypass security. On the other hand, it seems to be the only solution, > >>> which won't require changes on Keycloak/RHSSO side. But we don't know > >>> yet if it works... > >> Actually there is another way to bypass security that Tristan brought up > >> that we were was discussing. For JDG 7.2.CR1 we can relax access to > >> protected caches, such as scriptcache, so that there is no global > >> authorization check (removing a single if block). This way the cache > >> just uses the normal authorization checks if it is even enabled for that > >> cache. Unfortunately CR1 is not going to be available for another 3 weeks > >> though. In the mean time Jared and I discussed just testing with > >> community server version 8.2.8 for the standalone install until we can > >> get JDG 7.2.CR1 installed there. He may even want to test with something > >> a little newer. > > Thanks for the update. > > > > If Jared is fine to temporarily test with Infinispan server 8.2.8, it's > > cool. We will try to see if we can bypass security even for JDG 7.1 (Hynek > > is looking into picketbox "anonymous" modules) and there is this patch > > from me to secure access to "_script" cache, which works with 7.1, but > > will require to patch Keycloak/RHSSO. > > > > I afraid we can officially update to JDG 7.2 at the moment, when 7.2.GA is > > released. However it may be good to test early with 7.2, so we can find > > earlier if some fixes are needed on JDG side and notify you before GA. > > Hopefully we have time for trying that... :) > > > > > > BTV. Will JDG 7.2 have better "pagination" support for RemoteCaches, so I > > can do something like: > > > > remoteCache.keySet().stream().skip(100).limit(10).collect(Collectors.toList()); The remote client added support for the various keySet/entrySet/values collections in this version :) The way this works is these implement bulk operations such as stream on top of the retrieveEntries method. This internally invokes [1] with a default batch size of [2]. You can override this default by setting the batch size of the remote cache [3][4] or by invoking the [1] method directly, passing your desired batch size and creating a stream from that. If you want it to be the most efficient I would do [5] - this way it only pulls down 110 entries and only has the key as well (it uses the always registered converter that the keySet().iterator() uses). Unfortunately this points out there is no easy way to configure batch size for key iteration on the client (we need to fix that). [1] https://github.com/infinispan/infinispan/blob/master/client/hotrod-client/src/main/java/org/infinispan/client/hotrod/RemoteCache.java#L229 [2] https://github.com/infinispan/infinispan/commit/a5d8babfcca031227106c546a3388fee2da4ee6e#diff-76807cffef27c52bdd3fafd782945895R75 [3] https://github.com/infinispan/infinispan/blob/master/client/hotrod-client/src/main/java/org/infinispan/client/hotrod/configuration/ConfigurationBuilder.java#L293 [4] https://github.com/infinispan/infinispan/commit/a5d8babfcca031227106c546a3388fee2da4ee6e#diff-76807cffef27c52bdd3fafd782945895R65 [5] https://gist.github.com/wburns/140e288f27ce7a4b04aec8ee65d9f819 By the way you should be able to do [5] even in ISPN 8.2.8 as well. The only thing that was added was the support of the standard collection methods on Map (ie. keySet, entrySet and values). > > > > to ensure that just 10 items from 100 to 110 are sent over the network? And > > will it have Server tasks support? If yes, we will be hopefully able to Hrmm, JDG 7.1 should have ServerTask, what was missing there? > > get rid of remote scripting entirely :) > > > > But problem is also "client" (Keycloak) side as we rely on the infinispan > > version provided by Wildfly/EAP. In other words, we are always few months > > (or years?) behind all the cool features and fixes, which you are > > currently developing in infinispan master :( Yeah that is sad :( > > > > Marek > >> > >> Unfortunately that means that this version of keycloak would only work > >> with JDG 7.2.0.CR1 or ISPN 9.0.3 [1] and newer. Either way I will be > >> creating a PR for this on the JDG 7.2 branch today. > >> > >> [1] https://issues.jboss.org/browse/ISPN-7814 > >> > > > From bela.berde at gmail.com Sun Mar 4 18:48:07 2018 From: bela.berde at gmail.com (Bela Berde) Date: Mon, 5 Mar 2018 00:48:07 +0100 Subject: [keycloak-dev] Client Adapters for Golang Message-ID: Hi, Is there someone who successfully connected Keycloak to a Golang Frontend-Backend? Many thanks. Cheers From thomas.darimont at googlemail.com Mon Mar 5 04:07:02 2018 From: thomas.darimont at googlemail.com (Thomas Darimont) Date: Mon, 5 Mar 2018 10:07:02 +0100 Subject: [keycloak-dev] Client Adapters for Golang In-Reply-To: References: Message-ID: Hello Bela, what framework or library are you using in your Go Web App? The thing is, there is no such thing as a "single" Keycloak integration, due to the myriads of web frameworks available for Go. Of course most of them support a Servlet Filter like middleware pattern (as shown below) that could be implemented somewhat generic but in the end you probably need an integration that is custom to your framework. I just started to adding support for Keycloak to https://github.com/stretchr/gomniauth but the library is missing a bit of functionality such as logout etc. There is https://github.com/gambol99/keycloak-proxy where you could look for the OIDC protocol interaction create your own implementation. Another option would be to just use an OIDC go client implementation like: https://github.com/coreos/go-oidc or https://github.com/ericchiang/oidc Cheers, Thomas package main import ( "flag" "fmt" "github.com/gorilla/mux" "log" "net/http" "net/http/httputil" "os" "time" ) var greeting string func main() { flag.StringVar(&greeting, "g", "Hello", "The greeting message, defaults to 'Hello'") flag.Parse() logger := *log.New(os.Stdout, "logger: ", log.Lshortfile) router := mux.NewRouter() router.Handle("/greet", http.HandlerFunc(greet)) //for all routes apply the follwing list of handlers http.Handle("/", Adapt(router, WithLogger(&logger), WithRequestTracing(), WithHeaders(map[string]string{"foo": "42", "bar": "1337"}), )) http.ListenAndServe(":8080", nil) } // Adapter wraps an http.Handler with Additional functionality. type Adapter func(http.Handler) http.Handler // Adapt h with all specified adapters. func Adapt(h http.Handler, adapters ...Adapter) http.Handler { // apply handler backwards so that they are executed in declared order for i := len(adapters) - 1; i >= 0; i-- { h = adapters[i](h) } return h } // curl -v http://localhost:8080/greet func greet(w http.ResponseWriter, r *http.Request) { w.WriteHeader(http.StatusOK) fmt.Fprintf(w, greeting+" %v\n", time.Now().String()) } func WithRequestTracing() Adapter { return func(h http.Handler) http.Handler { return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) { dump, err := httputil.DumpRequest(r, true) if err != nil { http.Error(w, fmt.Sprint(err), http.StatusInternalServerError) return } fmt.Printf("Request Dump:\n%q\n", dump) h.ServeHTTP(w, r) }) } } func WithHeaders(headers map[string]string) Adapter { return func(h http.Handler) http.Handler { return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) { for key, value := range headers { w.Header().Add(key, value) } h.ServeHTTP(w, r) }) } } func WithLogger(l *log.Logger) Adapter { return func(h http.Handler) http.Handler { return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) { l.Println(r.Method, r.URL.Path) h.ServeHTTP(w, r) }) } } 2018-03-05 0:48 GMT+01:00 Bela Berde : > Hi, > Is there someone who successfully connected Keycloak to a Golang > Frontend-Backend? > Many thanks. > Cheers > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > From bdawidow at redhat.com Mon Mar 5 04:55:46 2018 From: bdawidow at redhat.com (Boleslaw Dawidowicz) Date: Mon, 05 Mar 2018 09:55:46 +0000 Subject: [keycloak-dev] infinispan as a storage mechanism In-Reply-To: References: <55656cbe-6b45-96a2-fb91-d8e791633b46@redhat.com> Message-ID: It testsuite local time is a main concern I know some companies are mocking DB or part of data layer to keep it down to minutes. Having ?good enough? but fast for local and proper setup in CI invoked per PR. Or proper timely one invoked locally only rarely before wrapping up the work. W dniu ?r., 28.02.2018 o 15:20 Bill Burke napisa?(a): > I often have tests that pass within the IDE, or if run singly through > maven, but fail on a maven build. So, I'm often running a full build. > > In my measurements, skipping Liquibase only shaves off 1-2 seconds > (which is still a lot). JPA initialization takes 5 seconds. > Testsuite slowness is 90% because of Liquibase/JPA. At least on my > laptop. Eventually I'll be able to give you numbers when I finish the > Infinispan backend, but I'm weeks away from that as I'm only doing it > off and on. > > On Wed, Feb 28, 2018 at 4:23 AM, Marek Posolda > wrote: > > I am also personally not concerned about running full testsuite through > "mvn > > clean install", however I agree will be good to improve startup when you > run > > single test from IDE. > > > > We already use in-memory H2 by default on embedded undertow. But maybe it > > helps if we skip liquibase at all and let Hibernate to create the schema > > when running testsuite with in-mem H2? The problem with Liquibase is, > that > > there are more and more changelogs and more and more changes and we can't > > get rid old changelogs. So there are many things like the table is > created > > by jpa-changelog-1.0.0, but then immediately dropped by > jpa-changelog-1.5.0 > > etc. This is not so big issue for production environments when schema is > > created just once, but sucks during development IMO. > > > > Question is, how much time is spent on schema initialization and how > much on > > other initialization things (EG. importing master realm and "test" realm > > etc)... Maybe to try some startup profiling will help... > > > > Marek > > > > > > > > On 27/02/18 21:08, Stian Thorgersen wrote: > >> > >> It's not going to help with startup time, but perhaps one simple way to > >> make the testsuite run faster would be configuring the h2 dB as > >> in-mem/non-persisted. > >> > >> On 27 Feb 2018 7:11 pm, "Stian Thorgersen" wrote: > >> > >>> > >>> On 27 February 2018 at 15:02, Bill Burke wrote: > >>> > >>>> This is something I've been doing off and on for awhile. An hour here > >>>> or there. Its a lot of monotonous work. > >>>> > >>>> Well worth it IMO if our build times drop drastically. 30 min build > >>>> is becoming burdensome. If the console tests get turned on combined > >>>> with all the other tests that are added daily, I can see this turning > >>>> into 60 min by the end of the year. Not to mention when I run a > >>>> single test from the IDE it takes like 10 seconds to start. I'm just > >>>> sick and tired of it. > >>>> > >>> I can only see how it saves time on starting the Keycloak server, not > for > >>> individual tests. That means you're only saving a few seconds each time > >>> the > >>> server is started, which is not many times for a full run. You'll > >>> probably > >>> end up shaving 1 min of the whole 30 min at best. > >>> > >>> Andy also mentioned that the Hibernate guys are working on performance. > >>> There is something weird about the Hibernate startup time in general. > So > >>> if > >>> there's improvements there that 1 min you could shave would become even > >>> less. > >>> > >>> We're also working towards having the full testsuite ran on PRs, which > >>> means as a dev you would be better of picking and running only the > tests > >>> you believe may be affected and let the CI run the complete set of > jobs. > >>> > >>> I'd never bother running the admin console tests locally unless I've > done > >>> some changes to the admin console. I also found that running the tests > >>> from > >>> the IDE run significantly quicker than through Maven. The difference > >>> there > >>> is down to something else than JPA as that's used in both cases. > >>> Personally > >>> I very rarely build the full distro or run the tests from Maven at > all. I > >>> just let Travis do that, while I run tests through the IDE. > >>> > >>> > >>>> For migration, if you base your stored objects on Maps, you only have > >>>> to worry about cases where you're modifying objects that are > >>>> serialized. These would need to be versioned as per java > >>>> serialization. New things > >>>> > >>> I really don't want us to maintain two different persistence layers. > It's > >>> a lot of duplicated effort. Becomes even worse when you start thinking > >>> about things like migration, cross-dc, rolling upgrades, etc.. > >>> > >>> If you are suggesting to completely drop our JPA store altogether and > use > >>> Infinispan with a cache store instead that could be an interesting > >>> option, > >>> but I have loads and loads of concerns around that. > >>> > >>> > >>>> > >>>> On Tue, Feb 27, 2018 at 1:53 AM, Stian Thorgersen < > sthorger at redhat.com> > >>>> wrote: > >>>>> > >>>>> I'm really not convinced about this. Infinispan still needs to > persist > >>>> > >>>> the > >>>>> > >>>>> data. It still needs to handle migration whenever we change things. > >>>>> It's > >>>>> another layer to get working correctly, etc.. I think we have more > >>>> > >>>> important > >>>>> > >>>>> work than to work on another data layer. > >>>>> > >>>>> On 26 February 2018 at 21:47, Bill Burke wrote: > >>>>>> > >>>>>> I'm thinking of this mostly for running our testsuite. If you're > not > >>>>>> developing on DB, much nicer if your test startup times is > >>>>>> milliseconds rather than 5-10 secs. > >>>>>> > >>>>>> For production, I'm thinking more of when people need lightweight > >>>>>> keycloak instances and are doing a lot of identity federation. This > >>>>>> is really long term thoughts though. > >>>>>> > >>>>>> On Mon, Feb 26, 2018 at 2:56 PM, Pedro Igor Silva < > psilva at redhat.com> > >>>>>> wrote: > >>>>>>> > >>>>>>> I think MongoDB will start supporting transactions very soon on v4 > >>>> > >>>> .... > >>>>>>> > >>>>>>> I'm not sure about running both app and database in the same VM > >>>> > >>>> though. > >>>>>>> > >>>>>>> For > >>>>>>> dev purposes that is fine, but in real world scenarios you probably > >>>> > >>>> want > >>>>>>> > >>>>>>> to > >>>>>>> avoid sharing resources (mem, cpu) with your DB. In your case, > people > >>>>>>> will > >>>>>>> probably need JBoss DataGrid in production. > >>>>>>> > >>>>>>> On Mon, Feb 26, 2018 at 4:30 PM, Bill Burke > >>>> > >>>> wrote: > >>>>>>>> > >>>>>>>> Other than MongoDB not supporting transactions or even sessions? > >>>> > >>>> And > >>>>>>>> > >>>>>>>> requiring a DB to be run in a separate VM? > >>>>>>>> > >>>>>>>> No not really :) > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> On Mon, Feb 26, 2018 at 12:54 PM, Pedro Igor Silva < > >>>> > >>>> psilva at redhat.com> > >>>>>>>> > >>>>>>>> wrote: > >>>>>>>>> > >>>>>>>>> Isn't this somewhat related with what we used to have with > >>>> > >>>> MongoDB ? > >>>>>>>>> > >>>>>>>>> On Mon, Feb 26, 2018 at 2:35 PM, Bill Burke > >>>>>>>>> wrote: > >>>>>>>>>> > >>>>>>>>>> If we had a built-in, clusterable storage mechanism for Keycloak > >>>>>>>>>> using > >>>>>>>>>> Infinispan we would: > >>>>>>>>>> * Shorten build times drastically. 30 minutes and growing for > me > >>>>>>>>>> for > >>>>>>>>>> JPA builds. Liquibase + JPA startup takes 5-7 seconds on my > box. > >>>>>>>>>> * Simpler startup. No need to start a DB. > >>>>>>>>>> * Reduce memory footprint? I think JPA is responsible for a lot > >>>> > >>>> of > >>>>>>>>>> > >>>>>>>>>> classes loaded. > >>>>>>>>>> > >>>>>>>>>> I've started some work on this in spare time. I'd say I'd be > >>>> > >>>> done > >>>>>>>>>> > >>>>>>>>>> in > >>>>>>>>>> like 2 months considering the other work I have in queue. > >>>>>>>>>> > >>>>>>>>>> Looking at FineGrainAtomicMap as an implementation. Should make > >>>> > >>>> DB > >>>>>>>>>> > >>>>>>>>>> migration simple and replication quicker. > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> -- > >>>>>>>>>> Bill Burke > >>>>>>>>>> Red Hat > >>>>>>>>>> _______________________________________________ > >>>>>>>>>> keycloak-dev mailing list > >>>>>>>>>> keycloak-dev at lists.jboss.org > >>>>>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev > >>>>>>>>> > >>>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> -- > >>>>>>>> Bill Burke > >>>>>>>> Red Hat > >>>>>>> > >>>>>>> > >>>>>> > >>>>>> > >>>>>> -- > >>>>>> Bill Burke > >>>>>> Red Hat > >>>>>> _______________________________________________ > >>>>>> keycloak-dev mailing list > >>>>>> keycloak-dev at lists.jboss.org > >>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev > >>>>> > >>>>> > >>>> > >>>> > >>>> -- > >>>> Bill Burke > >>>> Red Hat > >>>> > >>> > >> _______________________________________________ > >> keycloak-dev mailing list > >> keycloak-dev at lists.jboss.org > >> https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > > > > > > > > -- > Bill Burke > Red Hat > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > From sthorger at redhat.com Mon Mar 5 06:29:10 2018 From: sthorger at redhat.com (Stian Thorgersen) Date: Mon, 5 Mar 2018 12:29:10 +0100 Subject: [keycloak-dev] infinispan as a storage mechanism In-Reply-To: References: <55656cbe-6b45-96a2-fb91-d8e791633b46@redhat.com> Message-ID: With regards to test execution time we're talking extra maintenance effort to save a few seconds. The base testsuite takes 20 min to run and it only starts/initializes jpa/liquibase once. In memory h2 is actually a very fast persistence option once running so we're only talking about startup time. We'll also easily end up with issues where it worked on a local build with the mock persistence layer and it fails on jpa in ci. Or the other way around. Personally I really have no interest in debugging/fixing a mock persistence layer or adding/extending it for that matter. We have enough pita here with the undertow in ide vs full dist in Maven/vi already not sure why we would like to make life even more complicated for ourselves. I'm also sure there's loads of improvements we could do to the testsuite to make it run faster both for developers and CI. I would much rather like to see improvements/effort spent there than in a mock persistence layer for testing only. On 5 Mar 2018 10:56 am, "Boleslaw Dawidowicz" wrote: > It testsuite local time is a main concern I know some companies are > mocking DB or part of data layer to keep it down to minutes. Having ?good > enough? but fast for local and proper setup in CI invoked per PR. Or proper > timely one invoked locally only rarely before wrapping up the work. > > > W dniu ?r., 28.02.2018 o 15:20 Bill Burke napisa?(a): > >> I often have tests that pass within the IDE, or if run singly through >> maven, but fail on a maven build. So, I'm often running a full build. >> >> In my measurements, skipping Liquibase only shaves off 1-2 seconds >> (which is still a lot). JPA initialization takes 5 seconds. >> Testsuite slowness is 90% because of Liquibase/JPA. At least on my >> laptop. Eventually I'll be able to give you numbers when I finish the >> Infinispan backend, but I'm weeks away from that as I'm only doing it >> off and on. >> >> On Wed, Feb 28, 2018 at 4:23 AM, Marek Posolda >> wrote: >> > I am also personally not concerned about running full testsuite through >> "mvn >> > clean install", however I agree will be good to improve startup when >> you run >> > single test from IDE. >> > >> > We already use in-memory H2 by default on embedded undertow. But maybe >> it >> > helps if we skip liquibase at all and let Hibernate to create the schema >> > when running testsuite with in-mem H2? The problem with Liquibase is, >> that >> > there are more and more changelogs and more and more changes and we >> can't >> > get rid old changelogs. So there are many things like the table is >> created >> > by jpa-changelog-1.0.0, but then immediately dropped by >> jpa-changelog-1.5.0 >> > etc. This is not so big issue for production environments when schema is >> > created just once, but sucks during development IMO. >> > >> > Question is, how much time is spent on schema initialization and how >> much on >> > other initialization things (EG. importing master realm and "test" realm >> > etc)... Maybe to try some startup profiling will help... >> > >> > Marek >> > >> > >> > >> > On 27/02/18 21:08, Stian Thorgersen wrote: >> >> >> >> It's not going to help with startup time, but perhaps one simple way to >> >> make the testsuite run faster would be configuring the h2 dB as >> >> in-mem/non-persisted. >> >> >> >> On 27 Feb 2018 7:11 pm, "Stian Thorgersen" >> wrote: >> >> >> >>> >> >>> On 27 February 2018 at 15:02, Bill Burke wrote: >> >>> >> >>>> This is something I've been doing off and on for awhile. An hour >> here >> >>>> or there. Its a lot of monotonous work. >> >>>> >> >>>> Well worth it IMO if our build times drop drastically. 30 min build >> >>>> is becoming burdensome. If the console tests get turned on combined >> >>>> with all the other tests that are added daily, I can see this turning >> >>>> into 60 min by the end of the year. Not to mention when I run a >> >>>> single test from the IDE it takes like 10 seconds to start. I'm just >> >>>> sick and tired of it. >> >>>> >> >>> I can only see how it saves time on starting the Keycloak server, not >> for >> >>> individual tests. That means you're only saving a few seconds each >> time >> >>> the >> >>> server is started, which is not many times for a full run. You'll >> >>> probably >> >>> end up shaving 1 min of the whole 30 min at best. >> >>> >> >>> Andy also mentioned that the Hibernate guys are working on >> performance. >> >>> There is something weird about the Hibernate startup time in general. >> So >> >>> if >> >>> there's improvements there that 1 min you could shave would become >> even >> >>> less. >> >>> >> >>> We're also working towards having the full testsuite ran on PRs, which >> >>> means as a dev you would be better of picking and running only the >> tests >> >>> you believe may be affected and let the CI run the complete set of >> jobs. >> >>> >> >>> I'd never bother running the admin console tests locally unless I've >> done >> >>> some changes to the admin console. I also found that running the tests >> >>> from >> >>> the IDE run significantly quicker than through Maven. The difference >> >>> there >> >>> is down to something else than JPA as that's used in both cases. >> >>> Personally >> >>> I very rarely build the full distro or run the tests from Maven at >> all. I >> >>> just let Travis do that, while I run tests through the IDE. >> >>> >> >>> >> >>>> For migration, if you base your stored objects on Maps, you only have >> >>>> to worry about cases where you're modifying objects that are >> >>>> serialized. These would need to be versioned as per java >> >>>> serialization. New things >> >>>> >> >>> I really don't want us to maintain two different persistence layers. >> It's >> >>> a lot of duplicated effort. Becomes even worse when you start thinking >> >>> about things like migration, cross-dc, rolling upgrades, etc.. >> >>> >> >>> If you are suggesting to completely drop our JPA store altogether and >> use >> >>> Infinispan with a cache store instead that could be an interesting >> >>> option, >> >>> but I have loads and loads of concerns around that. >> >>> >> >>> >> >>>> >> >>>> On Tue, Feb 27, 2018 at 1:53 AM, Stian Thorgersen < >> sthorger at redhat.com> >> >>>> wrote: >> >>>>> >> >>>>> I'm really not convinced about this. Infinispan still needs to >> persist >> >>>> >> >>>> the >> >>>>> >> >>>>> data. It still needs to handle migration whenever we change things. >> >>>>> It's >> >>>>> another layer to get working correctly, etc.. I think we have more >> >>>> >> >>>> important >> >>>>> >> >>>>> work than to work on another data layer. >> >>>>> >> >>>>> On 26 February 2018 at 21:47, Bill Burke wrote: >> >>>>>> >> >>>>>> I'm thinking of this mostly for running our testsuite. If you're >> not >> >>>>>> developing on DB, much nicer if your test startup times is >> >>>>>> milliseconds rather than 5-10 secs. >> >>>>>> >> >>>>>> For production, I'm thinking more of when people need lightweight >> >>>>>> keycloak instances and are doing a lot of identity federation. >> This >> >>>>>> is really long term thoughts though. >> >>>>>> >> >>>>>> On Mon, Feb 26, 2018 at 2:56 PM, Pedro Igor Silva < >> psilva at redhat.com> >> >>>>>> wrote: >> >>>>>>> >> >>>>>>> I think MongoDB will start supporting transactions very soon on v4 >> >>>> >> >>>> .... >> >>>>>>> >> >>>>>>> I'm not sure about running both app and database in the same VM >> >>>> >> >>>> though. >> >>>>>>> >> >>>>>>> For >> >>>>>>> dev purposes that is fine, but in real world scenarios you >> probably >> >>>> >> >>>> want >> >>>>>>> >> >>>>>>> to >> >>>>>>> avoid sharing resources (mem, cpu) with your DB. In your case, >> people >> >>>>>>> will >> >>>>>>> probably need JBoss DataGrid in production. >> >>>>>>> >> >>>>>>> On Mon, Feb 26, 2018 at 4:30 PM, Bill Burke >> >>>> >> >>>> wrote: >> >>>>>>>> >> >>>>>>>> Other than MongoDB not supporting transactions or even sessions? >> >>>> >> >>>> And >> >>>>>>>> >> >>>>>>>> requiring a DB to be run in a separate VM? >> >>>>>>>> >> >>>>>>>> No not really :) >> >>>>>>>> >> >>>>>>>> >> >>>>>>>> >> >>>>>>>> On Mon, Feb 26, 2018 at 12:54 PM, Pedro Igor Silva < >> >>>> >> >>>> psilva at redhat.com> >> >>>>>>>> >> >>>>>>>> wrote: >> >>>>>>>>> >> >>>>>>>>> Isn't this somewhat related with what we used to have with >> >>>> >> >>>> MongoDB ? >> >>>>>>>>> >> >>>>>>>>> On Mon, Feb 26, 2018 at 2:35 PM, Bill Burke >> >>>>>>>>> wrote: >> >>>>>>>>>> >> >>>>>>>>>> If we had a built-in, clusterable storage mechanism for >> Keycloak >> >>>>>>>>>> using >> >>>>>>>>>> Infinispan we would: >> >>>>>>>>>> * Shorten build times drastically. 30 minutes and growing for >> me >> >>>>>>>>>> for >> >>>>>>>>>> JPA builds. Liquibase + JPA startup takes 5-7 seconds on my >> box. >> >>>>>>>>>> * Simpler startup. No need to start a DB. >> >>>>>>>>>> * Reduce memory footprint? I think JPA is responsible for a >> lot >> >>>> >> >>>> of >> >>>>>>>>>> >> >>>>>>>>>> classes loaded. >> >>>>>>>>>> >> >>>>>>>>>> I've started some work on this in spare time. I'd say I'd be >> >>>> >> >>>> done >> >>>>>>>>>> >> >>>>>>>>>> in >> >>>>>>>>>> like 2 months considering the other work I have in queue. >> >>>>>>>>>> >> >>>>>>>>>> Looking at FineGrainAtomicMap as an implementation. Should >> make >> >>>> >> >>>> DB >> >>>>>>>>>> >> >>>>>>>>>> migration simple and replication quicker. >> >>>>>>>>>> >> >>>>>>>>>> >> >>>>>>>>>> -- >> >>>>>>>>>> Bill Burke >> >>>>>>>>>> Red Hat >> >>>>>>>>>> _______________________________________________ >> >>>>>>>>>> keycloak-dev mailing list >> >>>>>>>>>> keycloak-dev at lists.jboss.org >> >>>>>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> >>>>>>>>> >> >>>>>>>>> >> >>>>>>>> >> >>>>>>>> >> >>>>>>>> -- >> >>>>>>>> Bill Burke >> >>>>>>>> Red Hat >> >>>>>>> >> >>>>>>> >> >>>>>> >> >>>>>> >> >>>>>> -- >> >>>>>> Bill Burke >> >>>>>> Red Hat >> >>>>>> _______________________________________________ >> >>>>>> keycloak-dev mailing list >> >>>>>> keycloak-dev at lists.jboss.org >> >>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> >>>>> >> >>>>> >> >>>> >> >>>> >> >>>> -- >> >>>> Bill Burke >> >>>> Red Hat >> >>>> >> >>> >> >> _______________________________________________ >> >> keycloak-dev mailing list >> >> keycloak-dev at lists.jboss.org >> >> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> > >> > >> > >> >> >> >> -- >> Bill Burke >> Red Hat >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> > From mposolda at redhat.com Mon Mar 5 08:41:47 2018 From: mposolda at redhat.com (Marek Posolda) Date: Mon, 5 Mar 2018 14:41:47 +0100 Subject: [keycloak-dev] [IAM] Cross-datacenter configuration issues In-Reply-To: <1067619488.6003904.1520116850668.JavaMail.zimbra@redhat.com> References: <1190516630.5452826.1519915371405.JavaMail.zimbra@redhat.com> <8a133b3f-fbf1-570b-5a79-8be9e01fd5ed@redhat.com> <667192371.5842268.1520000670050.JavaMail.zimbra@redhat.com> <13F5E052-4210-4D57-BA05-34140A4535C4@redhat.com> <1067619488.6003904.1520116850668.JavaMail.zimbra@redhat.com> Message-ID: <6886edc6-b664-584f-f7e2-f58d824748fb@redhat.com> On 03/03/18 23:40, William Burns wrote: > > ----- Original Message ----- >> From: "Brian Atkisson" >> To: "Marek Posolda" >> Cc: "William Burns" , "Pedro Zapata Fernandez" , "iam-list" >> , "keycloak-dev" , "Hynek Mlnarik" , >> "Tristan Tarrant" , "Boleslaw Dawidowicz" , mmccomas at redhat.com >> Sent: Friday, March 2, 2018 6:52:19 PM >> Subject: Re: [IAM] [keycloak-dev] Cross-datacenter configuration issues >> >> +Mike >> >>> On Mar 2, 2018, at 12:20 PM, Marek Posolda wrote: >>> >>>> On 02/03/18 15:24, William Burns wrote: >>>>> (3) Use the approach, which works for me and which I put in JIRA. So >>>>> have 2 hotrod endpoints on JDG side (unsecured and secured). RemoteStore >>>>> access the unsecured endpoint. Just some sources, which deals with >>>>> __script cache, access the secured hotrod endpoint. This requires to >>>>> "patch" module keycloak-model-infinispan on RHSSO side and also require >>>>> some smaller changes in the configuration (some new configuration >>>>> properties are added on RHSSO side to allow configuration of hotrod >>>>> endpoint security, username ,password etc). >>>>> >>>>> (4) Bypass JDG security entirely with some picketbox "anonymous access" >>>>> JAAS login modules. I didn't manage to have it working and it completely >>>>> bypass security. On the other hand, it seems to be the only solution, >>>>> which won't require changes on Keycloak/RHSSO side. But we don't know >>>>> yet if it works... >>>> Actually there is another way to bypass security that Tristan brought up >>>> that we were was discussing. For JDG 7.2.CR1 we can relax access to >>>> protected caches, such as scriptcache, so that there is no global >>>> authorization check (removing a single if block). This way the cache >>>> just uses the normal authorization checks if it is even enabled for that >>>> cache. Unfortunately CR1 is not going to be available for another 3 weeks >>>> though. In the mean time Jared and I discussed just testing with >>>> community server version 8.2.8 for the standalone install until we can >>>> get JDG 7.2.CR1 installed there. He may even want to test with something >>>> a little newer. >>> Thanks for the update. >>> >>> If Jared is fine to temporarily test with Infinispan server 8.2.8, it's >>> cool. We will try to see if we can bypass security even for JDG 7.1 (Hynek >>> is looking into picketbox "anonymous" modules) and there is this patch >>> from me to secure access to "_script" cache, which works with 7.1, but >>> will require to patch Keycloak/RHSSO. >>> >>> I afraid we can officially update to JDG 7.2 at the moment, when 7.2.GA is >>> released. However it may be good to test early with 7.2, so we can find >>> earlier if some fixes are needed on JDG side and notify you before GA. >>> Hopefully we have time for trying that... :) >>> >>> >>> BTV. Will JDG 7.2 have better "pagination" support for RemoteCaches, so I >>> can do something like: >>> >>> remoteCache.keySet().stream().skip(100).limit(10).collect(Collectors.toList()); > The remote client added support for the various keySet/entrySet/values collections in this version :) > > The way this works is these implement bulk operations such as stream on top of the retrieveEntries method. This internally invokes [1] with a default batch size of [2]. You can override this default by setting the batch size of the remote cache [3][4] or by invoking the [1] method directly, passing your desired batch size and creating a stream from that. > > If you want it to be the most efficient I would do [5] - this way it only pulls down 110 entries and only has the key as well (it uses the always registered converter that the keySet().iterator() uses). Unfortunately this points out there is no easy way to configure batch size for key iteration on the client (we need to fix that). > > [1] https://github.com/infinispan/infinispan/blob/master/client/hotrod-client/src/main/java/org/infinispan/client/hotrod/RemoteCache.java#L229 > [2] https://github.com/infinispan/infinispan/commit/a5d8babfcca031227106c546a3388fee2da4ee6e#diff-76807cffef27c52bdd3fafd782945895R75 > [3] https://github.com/infinispan/infinispan/blob/master/client/hotrod-client/src/main/java/org/infinispan/client/hotrod/configuration/ConfigurationBuilder.java#L293 > [4] https://github.com/infinispan/infinispan/commit/a5d8babfcca031227106c546a3388fee2da4ee6e#diff-76807cffef27c52bdd3fafd782945895R65 > [5] https://gist.github.com/wburns/140e288f27ce7a4b04aec8ee65d9f819 > > By the way you should be able to do [5] even in ISPN 8.2.8 as well. The only thing that was added was the support of the standard collection methods on Map (ie. keySet, entrySet and values). Thanks for the pointers > >>> to ensure that just 10 items from 100 to 110 are sent over the network? And >>> will it have Server tasks support? If yes, we will be hopefully able to > Hrmm, JDG 7.1 should have ServerTask, what was missing there? ah, indeed. I somehow missed that for some reason... Just checked that it requires a module with server task to be deployed on JDG side, which I am not sure works for us. The JS code has an advantage, that it can be deployed "on the fly" without additional need for packaging the JAR etc. But maybe it's way to go for us anyway as we may need some our classes to be available on JDG side for better filtering etc. I need to doublecheck that... Marek > >>> get rid of remote scripting entirely :) >>> >>> But problem is also "client" (Keycloak) side as we rely on the infinispan >>> version provided by Wildfly/EAP. In other words, we are always few months >>> (or years?) behind all the cool features and fixes, which you are >>> currently developing in infinispan master :( > Yeah that is sad :( > >>> Marek >>>> Unfortunately that means that this version of keycloak would only work >>>> with JDG 7.2.0.CR1 or ISPN 9.0.3 [1] and newer. Either way I will be >>>> creating a PR for this on the JDG 7.2 branch today. >>>> >>>> [1] https://issues.jboss.org/browse/ISPN-7814 >>>> From sthorger at redhat.com Mon Mar 5 08:58:55 2018 From: sthorger at redhat.com (Stian Thorgersen) Date: Mon, 5 Mar 2018 14:58:55 +0100 Subject: [keycloak-dev] infinispan as a storage mechanism In-Reply-To: References: <55656cbe-6b45-96a2-fb91-d8e791633b46@redhat.com> Message-ID: To be honest the idea of replacing our JPA layer with Infinispan completely is interesting if it works/performs. Having/maintaining two in the long run is very unattractive On 5 Mar 2018 11:29 am, "Stian Thorgersen" wrote: > With regards to test execution time we're talking extra maintenance effort > to save a few seconds. The base testsuite takes 20 min to run and it only > starts/initializes jpa/liquibase once. In memory h2 is actually a very fast > persistence option once running so we're only talking about startup time. > > We'll also easily end up with issues where it worked on a local build with > the mock persistence layer and it fails on jpa in ci. Or the other way > around. Personally I really have no interest in debugging/fixing a mock > persistence layer or adding/extending it for that matter. We have enough > pita here with the undertow in ide vs full dist in Maven/vi already not > sure why we would like to make life even more complicated for ourselves. > > I'm also sure there's loads of improvements we could do to the testsuite > to make it run faster both for developers and CI. I would much rather like > to see improvements/effort spent there than in a mock persistence layer for > testing only. > > On 5 Mar 2018 10:56 am, "Boleslaw Dawidowicz" wrote: > >> It testsuite local time is a main concern I know some companies are >> mocking DB or part of data layer to keep it down to minutes. Having ?good >> enough? but fast for local and proper setup in CI invoked per PR. Or proper >> timely one invoked locally only rarely before wrapping up the work. >> >> >> W dniu ?r., 28.02.2018 o 15:20 Bill Burke napisa?(a): >> >>> I often have tests that pass within the IDE, or if run singly through >>> maven, but fail on a maven build. So, I'm often running a full build. >>> >>> In my measurements, skipping Liquibase only shaves off 1-2 seconds >>> (which is still a lot). JPA initialization takes 5 seconds. >>> Testsuite slowness is 90% because of Liquibase/JPA. At least on my >>> laptop. Eventually I'll be able to give you numbers when I finish the >>> Infinispan backend, but I'm weeks away from that as I'm only doing it >>> off and on. >>> >>> On Wed, Feb 28, 2018 at 4:23 AM, Marek Posolda >>> wrote: >>> > I am also personally not concerned about running full testsuite >>> through "mvn >>> > clean install", however I agree will be good to improve startup when >>> you run >>> > single test from IDE. >>> > >>> > We already use in-memory H2 by default on embedded undertow. But maybe >>> it >>> > helps if we skip liquibase at all and let Hibernate to create the >>> schema >>> > when running testsuite with in-mem H2? The problem with Liquibase is, >>> that >>> > there are more and more changelogs and more and more changes and we >>> can't >>> > get rid old changelogs. So there are many things like the table is >>> created >>> > by jpa-changelog-1.0.0, but then immediately dropped by >>> jpa-changelog-1.5.0 >>> > etc. This is not so big issue for production environments when schema >>> is >>> > created just once, but sucks during development IMO. >>> > >>> > Question is, how much time is spent on schema initialization and how >>> much on >>> > other initialization things (EG. importing master realm and "test" >>> realm >>> > etc)... Maybe to try some startup profiling will help... >>> > >>> > Marek >>> > >>> > >>> > >>> > On 27/02/18 21:08, Stian Thorgersen wrote: >>> >> >>> >> It's not going to help with startup time, but perhaps one simple way >>> to >>> >> make the testsuite run faster would be configuring the h2 dB as >>> >> in-mem/non-persisted. >>> >> >>> >> On 27 Feb 2018 7:11 pm, "Stian Thorgersen" >>> wrote: >>> >> >>> >>> >>> >>> On 27 February 2018 at 15:02, Bill Burke wrote: >>> >>> >>> >>>> This is something I've been doing off and on for awhile. An hour >>> here >>> >>>> or there. Its a lot of monotonous work. >>> >>>> >>> >>>> Well worth it IMO if our build times drop drastically. 30 min build >>> >>>> is becoming burdensome. If the console tests get turned on combined >>> >>>> with all the other tests that are added daily, I can see this >>> turning >>> >>>> into 60 min by the end of the year. Not to mention when I run a >>> >>>> single test from the IDE it takes like 10 seconds to start. I'm >>> just >>> >>>> sick and tired of it. >>> >>>> >>> >>> I can only see how it saves time on starting the Keycloak server, >>> not for >>> >>> individual tests. That means you're only saving a few seconds each >>> time >>> >>> the >>> >>> server is started, which is not many times for a full run. You'll >>> >>> probably >>> >>> end up shaving 1 min of the whole 30 min at best. >>> >>> >>> >>> Andy also mentioned that the Hibernate guys are working on >>> performance. >>> >>> There is something weird about the Hibernate startup time in >>> general. So >>> >>> if >>> >>> there's improvements there that 1 min you could shave would become >>> even >>> >>> less. >>> >>> >>> >>> We're also working towards having the full testsuite ran on PRs, >>> which >>> >>> means as a dev you would be better of picking and running only the >>> tests >>> >>> you believe may be affected and let the CI run the complete set of >>> jobs. >>> >>> >>> >>> I'd never bother running the admin console tests locally unless I've >>> done >>> >>> some changes to the admin console. I also found that running the >>> tests >>> >>> from >>> >>> the IDE run significantly quicker than through Maven. The difference >>> >>> there >>> >>> is down to something else than JPA as that's used in both cases. >>> >>> Personally >>> >>> I very rarely build the full distro or run the tests from Maven at >>> all. I >>> >>> just let Travis do that, while I run tests through the IDE. >>> >>> >>> >>> >>> >>>> For migration, if you base your stored objects on Maps, you only >>> have >>> >>>> to worry about cases where you're modifying objects that are >>> >>>> serialized. These would need to be versioned as per java >>> >>>> serialization. New things >>> >>>> >>> >>> I really don't want us to maintain two different persistence layers. >>> It's >>> >>> a lot of duplicated effort. Becomes even worse when you start >>> thinking >>> >>> about things like migration, cross-dc, rolling upgrades, etc.. >>> >>> >>> >>> If you are suggesting to completely drop our JPA store altogether >>> and use >>> >>> Infinispan with a cache store instead that could be an interesting >>> >>> option, >>> >>> but I have loads and loads of concerns around that. >>> >>> >>> >>> >>> >>>> >>> >>>> On Tue, Feb 27, 2018 at 1:53 AM, Stian Thorgersen < >>> sthorger at redhat.com> >>> >>>> wrote: >>> >>>>> >>> >>>>> I'm really not convinced about this. Infinispan still needs to >>> persist >>> >>>> >>> >>>> the >>> >>>>> >>> >>>>> data. It still needs to handle migration whenever we change things. >>> >>>>> It's >>> >>>>> another layer to get working correctly, etc.. I think we have more >>> >>>> >>> >>>> important >>> >>>>> >>> >>>>> work than to work on another data layer. >>> >>>>> >>> >>>>> On 26 February 2018 at 21:47, Bill Burke >>> wrote: >>> >>>>>> >>> >>>>>> I'm thinking of this mostly for running our testsuite. If you're >>> not >>> >>>>>> developing on DB, much nicer if your test startup times is >>> >>>>>> milliseconds rather than 5-10 secs. >>> >>>>>> >>> >>>>>> For production, I'm thinking more of when people need lightweight >>> >>>>>> keycloak instances and are doing a lot of identity federation. >>> This >>> >>>>>> is really long term thoughts though. >>> >>>>>> >>> >>>>>> On Mon, Feb 26, 2018 at 2:56 PM, Pedro Igor Silva < >>> psilva at redhat.com> >>> >>>>>> wrote: >>> >>>>>>> >>> >>>>>>> I think MongoDB will start supporting transactions very soon on >>> v4 >>> >>>> >>> >>>> .... >>> >>>>>>> >>> >>>>>>> I'm not sure about running both app and database in the same VM >>> >>>> >>> >>>> though. >>> >>>>>>> >>> >>>>>>> For >>> >>>>>>> dev purposes that is fine, but in real world scenarios you >>> probably >>> >>>> >>> >>>> want >>> >>>>>>> >>> >>>>>>> to >>> >>>>>>> avoid sharing resources (mem, cpu) with your DB. In your case, >>> people >>> >>>>>>> will >>> >>>>>>> probably need JBoss DataGrid in production. >>> >>>>>>> >>> >>>>>>> On Mon, Feb 26, 2018 at 4:30 PM, Bill Burke >>> >>>> >>> >>>> wrote: >>> >>>>>>>> >>> >>>>>>>> Other than MongoDB not supporting transactions or even sessions? >>> >>>> >>> >>>> And >>> >>>>>>>> >>> >>>>>>>> requiring a DB to be run in a separate VM? >>> >>>>>>>> >>> >>>>>>>> No not really :) >>> >>>>>>>> >>> >>>>>>>> >>> >>>>>>>> >>> >>>>>>>> On Mon, Feb 26, 2018 at 12:54 PM, Pedro Igor Silva < >>> >>>> >>> >>>> psilva at redhat.com> >>> >>>>>>>> >>> >>>>>>>> wrote: >>> >>>>>>>>> >>> >>>>>>>>> Isn't this somewhat related with what we used to have with >>> >>>> >>> >>>> MongoDB ? >>> >>>>>>>>> >>> >>>>>>>>> On Mon, Feb 26, 2018 at 2:35 PM, Bill Burke >> > >>> >>>>>>>>> wrote: >>> >>>>>>>>>> >>> >>>>>>>>>> If we had a built-in, clusterable storage mechanism for >>> Keycloak >>> >>>>>>>>>> using >>> >>>>>>>>>> Infinispan we would: >>> >>>>>>>>>> * Shorten build times drastically. 30 minutes and growing >>> for me >>> >>>>>>>>>> for >>> >>>>>>>>>> JPA builds. Liquibase + JPA startup takes 5-7 seconds on my >>> box. >>> >>>>>>>>>> * Simpler startup. No need to start a DB. >>> >>>>>>>>>> * Reduce memory footprint? I think JPA is responsible for a >>> lot >>> >>>> >>> >>>> of >>> >>>>>>>>>> >>> >>>>>>>>>> classes loaded. >>> >>>>>>>>>> >>> >>>>>>>>>> I've started some work on this in spare time. I'd say I'd be >>> >>>> >>> >>>> done >>> >>>>>>>>>> >>> >>>>>>>>>> in >>> >>>>>>>>>> like 2 months considering the other work I have in queue. >>> >>>>>>>>>> >>> >>>>>>>>>> Looking at FineGrainAtomicMap as an implementation. Should >>> make >>> >>>> >>> >>>> DB >>> >>>>>>>>>> >>> >>>>>>>>>> migration simple and replication quicker. >>> >>>>>>>>>> >>> >>>>>>>>>> >>> >>>>>>>>>> -- >>> >>>>>>>>>> Bill Burke >>> >>>>>>>>>> Red Hat >>> >>>>>>>>>> _______________________________________________ >>> >>>>>>>>>> keycloak-dev mailing list >>> >>>>>>>>>> keycloak-dev at lists.jboss.org >>> >>>>>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>> >>>>>>>>> >>> >>>>>>>>> >>> >>>>>>>> >>> >>>>>>>> >>> >>>>>>>> -- >>> >>>>>>>> Bill Burke >>> >>>>>>>> Red Hat >>> >>>>>>> >>> >>>>>>> >>> >>>>>> >>> >>>>>> >>> >>>>>> -- >>> >>>>>> Bill Burke >>> >>>>>> Red Hat >>> >>>>>> _______________________________________________ >>> >>>>>> keycloak-dev mailing list >>> >>>>>> keycloak-dev at lists.jboss.org >>> >>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>> >>>>> >>> >>>>> >>> >>>> >>> >>>> >>> >>>> -- >>> >>>> Bill Burke >>> >>>> Red Hat >>> >>>> >>> >>> >>> >> _______________________________________________ >>> >> keycloak-dev mailing list >>> >> keycloak-dev at lists.jboss.org >>> >> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>> > >>> > >>> > >>> >>> >>> >>> -- >>> Bill Burke >>> Red Hat >>> _______________________________________________ >>> keycloak-dev mailing list >>> keycloak-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>> >> From wtr at redhat.com Mon Mar 5 09:25:09 2018 From: wtr at redhat.com (Wojciech Trocki) Date: Mon, 5 Mar 2018 14:25:09 +0000 Subject: [keycloak-dev] Keycloak.js - allow to provide custom adapters Message-ID: Hi I have been using keycloak.js for more than year mainly with the mobile applications (Cordova). Library is pretty well designed however there are some minor limitations in terms of what adapters could do. >From my point of view javascript library is missing ability to provide some custom implementations for adapters. Additionally implementations are provided as objects so it's hard to see and conform this undocumented interface. I'm happy to contribute any changes that will make sense upstream. I have created issue to cover exact use case where this is needed: https://issues.jboss.org/browse/KEYCLOAK-6798 Adding this functionality will also make it trivial to implement support for different mobile platforms like ReactNative etc. Regards Wojtek From bburke at redhat.com Mon Mar 5 10:21:20 2018 From: bburke at redhat.com (Bill Burke) Date: Mon, 5 Mar 2018 10:21:20 -0500 Subject: [keycloak-dev] infinispan as a storage mechanism In-Reply-To: References: <55656cbe-6b45-96a2-fb91-d8e791633b46@redhat.com> Message-ID: I don't see how any incremental improvements would be noticable when the bulk of the time running a single test in the IDE is spent in JPA/Liquibase initialization. This has really annoyed me for years. Also, I always had this worry that our RDBMS requirement might be a turn off or complete overkill for some users, especially if they are storing everything in LDAP or doing identity brokering. This is different than Mongo in that this would be self-contained. In the long run, removing RDBMS as a hard requirement for us would be pretty huge. Removes a big installation headache for customers. Allows Keycloak to be clusterable out of the box with parameters that we control. Anyways, I've been implementing this off and on for almost a year and have never been able to finish it so we're arguing over vaporware. On Mon, Mar 5, 2018 at 8:58 AM, Stian Thorgersen wrote: > To be honest the idea of replacing our JPA layer with Infinispan completely > is interesting if it works/performs. Having/maintaining two in the long run > is very unattractive > > On 5 Mar 2018 11:29 am, "Stian Thorgersen" wrote: >> >> With regards to test execution time we're talking extra maintenance effort >> to save a few seconds. The base testsuite takes 20 min to run and it only >> starts/initializes jpa/liquibase once. In memory h2 is actually a very fast >> persistence option once running so we're only talking about startup time. >> >> We'll also easily end up with issues where it worked on a local build with >> the mock persistence layer and it fails on jpa in ci. Or the other way >> around. Personally I really have no interest in debugging/fixing a mock >> persistence layer or adding/extending it for that matter. We have enough >> pita here with the undertow in ide vs full dist in Maven/vi already not sure >> why we would like to make life even more complicated for ourselves. >> >> I'm also sure there's loads of improvements we could do to the testsuite >> to make it run faster both for developers and CI. I would much rather like >> to see improvements/effort spent there than in a mock persistence layer for >> testing only. >> >> On 5 Mar 2018 10:56 am, "Boleslaw Dawidowicz" wrote: >>> >>> It testsuite local time is a main concern I know some companies are >>> mocking DB or part of data layer to keep it down to minutes. Having ?good >>> enough? but fast for local and proper setup in CI invoked per PR. Or proper >>> timely one invoked locally only rarely before wrapping up the work. >>> >>> >>> W dniu ?r., 28.02.2018 o 15:20 Bill Burke napisa?(a): >>>> >>>> I often have tests that pass within the IDE, or if run singly through >>>> maven, but fail on a maven build. So, I'm often running a full build. >>>> >>>> In my measurements, skipping Liquibase only shaves off 1-2 seconds >>>> (which is still a lot). JPA initialization takes 5 seconds. >>>> Testsuite slowness is 90% because of Liquibase/JPA. At least on my >>>> laptop. Eventually I'll be able to give you numbers when I finish the >>>> Infinispan backend, but I'm weeks away from that as I'm only doing it >>>> off and on. >>>> >>>> On Wed, Feb 28, 2018 at 4:23 AM, Marek Posolda >>>> wrote: >>>> > I am also personally not concerned about running full testsuite >>>> > through "mvn >>>> > clean install", however I agree will be good to improve startup when >>>> > you run >>>> > single test from IDE. >>>> > >>>> > We already use in-memory H2 by default on embedded undertow. But maybe >>>> > it >>>> > helps if we skip liquibase at all and let Hibernate to create the >>>> > schema >>>> > when running testsuite with in-mem H2? The problem with Liquibase is, >>>> > that >>>> > there are more and more changelogs and more and more changes and we >>>> > can't >>>> > get rid old changelogs. So there are many things like the table is >>>> > created >>>> > by jpa-changelog-1.0.0, but then immediately dropped by >>>> > jpa-changelog-1.5.0 >>>> > etc. This is not so big issue for production environments when schema >>>> > is >>>> > created just once, but sucks during development IMO. >>>> > >>>> > Question is, how much time is spent on schema initialization and how >>>> > much on >>>> > other initialization things (EG. importing master realm and "test" >>>> > realm >>>> > etc)... Maybe to try some startup profiling will help... >>>> > >>>> > Marek >>>> > >>>> > >>>> > >>>> > On 27/02/18 21:08, Stian Thorgersen wrote: >>>> >> >>>> >> It's not going to help with startup time, but perhaps one simple way >>>> >> to >>>> >> make the testsuite run faster would be configuring the h2 dB as >>>> >> in-mem/non-persisted. >>>> >> >>>> >> On 27 Feb 2018 7:11 pm, "Stian Thorgersen" >>>> >> wrote: >>>> >> >>>> >>> >>>> >>> On 27 February 2018 at 15:02, Bill Burke wrote: >>>> >>> >>>> >>>> This is something I've been doing off and on for awhile. An hour >>>> >>>> here >>>> >>>> or there. Its a lot of monotonous work. >>>> >>>> >>>> >>>> Well worth it IMO if our build times drop drastically. 30 min >>>> >>>> build >>>> >>>> is becoming burdensome. If the console tests get turned on >>>> >>>> combined >>>> >>>> with all the other tests that are added daily, I can see this >>>> >>>> turning >>>> >>>> into 60 min by the end of the year. Not to mention when I run a >>>> >>>> single test from the IDE it takes like 10 seconds to start. I'm >>>> >>>> just >>>> >>>> sick and tired of it. >>>> >>>> >>>> >>> I can only see how it saves time on starting the Keycloak server, >>>> >>> not for >>>> >>> individual tests. That means you're only saving a few seconds each >>>> >>> time >>>> >>> the >>>> >>> server is started, which is not many times for a full run. You'll >>>> >>> probably >>>> >>> end up shaving 1 min of the whole 30 min at best. >>>> >>> >>>> >>> Andy also mentioned that the Hibernate guys are working on >>>> >>> performance. >>>> >>> There is something weird about the Hibernate startup time in >>>> >>> general. So >>>> >>> if >>>> >>> there's improvements there that 1 min you could shave would become >>>> >>> even >>>> >>> less. >>>> >>> >>>> >>> We're also working towards having the full testsuite ran on PRs, >>>> >>> which >>>> >>> means as a dev you would be better of picking and running only the >>>> >>> tests >>>> >>> you believe may be affected and let the CI run the complete set of >>>> >>> jobs. >>>> >>> >>>> >>> I'd never bother running the admin console tests locally unless I've >>>> >>> done >>>> >>> some changes to the admin console. I also found that running the >>>> >>> tests >>>> >>> from >>>> >>> the IDE run significantly quicker than through Maven. The difference >>>> >>> there >>>> >>> is down to something else than JPA as that's used in both cases. >>>> >>> Personally >>>> >>> I very rarely build the full distro or run the tests from Maven at >>>> >>> all. I >>>> >>> just let Travis do that, while I run tests through the IDE. >>>> >>> >>>> >>> >>>> >>>> For migration, if you base your stored objects on Maps, you only >>>> >>>> have >>>> >>>> to worry about cases where you're modifying objects that are >>>> >>>> serialized. These would need to be versioned as per java >>>> >>>> serialization. New things >>>> >>>> >>>> >>> I really don't want us to maintain two different persistence layers. >>>> >>> It's >>>> >>> a lot of duplicated effort. Becomes even worse when you start >>>> >>> thinking >>>> >>> about things like migration, cross-dc, rolling upgrades, etc.. >>>> >>> >>>> >>> If you are suggesting to completely drop our JPA store altogether >>>> >>> and use >>>> >>> Infinispan with a cache store instead that could be an interesting >>>> >>> option, >>>> >>> but I have loads and loads of concerns around that. >>>> >>> >>>> >>> >>>> >>>> >>>> >>>> On Tue, Feb 27, 2018 at 1:53 AM, Stian Thorgersen >>>> >>>> >>>> >>>> wrote: >>>> >>>>> >>>> >>>>> I'm really not convinced about this. Infinispan still needs to >>>> >>>>> persist >>>> >>>> >>>> >>>> the >>>> >>>>> >>>> >>>>> data. It still needs to handle migration whenever we change >>>> >>>>> things. >>>> >>>>> It's >>>> >>>>> another layer to get working correctly, etc.. I think we have more >>>> >>>> >>>> >>>> important >>>> >>>>> >>>> >>>>> work than to work on another data layer. >>>> >>>>> >>>> >>>>> On 26 February 2018 at 21:47, Bill Burke >>>> >>>>> wrote: >>>> >>>>>> >>>> >>>>>> I'm thinking of this mostly for running our testsuite. If you're >>>> >>>>>> not >>>> >>>>>> developing on DB, much nicer if your test startup times is >>>> >>>>>> milliseconds rather than 5-10 secs. >>>> >>>>>> >>>> >>>>>> For production, I'm thinking more of when people need lightweight >>>> >>>>>> keycloak instances and are doing a lot of identity federation. >>>> >>>>>> This >>>> >>>>>> is really long term thoughts though. >>>> >>>>>> >>>> >>>>>> On Mon, Feb 26, 2018 at 2:56 PM, Pedro Igor Silva >>>> >>>>>> >>>> >>>>>> wrote: >>>> >>>>>>> >>>> >>>>>>> I think MongoDB will start supporting transactions very soon on >>>> >>>>>>> v4 >>>> >>>> >>>> >>>> .... >>>> >>>>>>> >>>> >>>>>>> I'm not sure about running both app and database in the same VM >>>> >>>> >>>> >>>> though. >>>> >>>>>>> >>>> >>>>>>> For >>>> >>>>>>> dev purposes that is fine, but in real world scenarios you >>>> >>>>>>> probably >>>> >>>> >>>> >>>> want >>>> >>>>>>> >>>> >>>>>>> to >>>> >>>>>>> avoid sharing resources (mem, cpu) with your DB. In your case, >>>> >>>>>>> people >>>> >>>>>>> will >>>> >>>>>>> probably need JBoss DataGrid in production. >>>> >>>>>>> >>>> >>>>>>> On Mon, Feb 26, 2018 at 4:30 PM, Bill Burke >>>> >>>> >>>> >>>> wrote: >>>> >>>>>>>> >>>> >>>>>>>> Other than MongoDB not supporting transactions or even >>>> >>>>>>>> sessions? >>>> >>>> >>>> >>>> And >>>> >>>>>>>> >>>> >>>>>>>> requiring a DB to be run in a separate VM? >>>> >>>>>>>> >>>> >>>>>>>> No not really :) >>>> >>>>>>>> >>>> >>>>>>>> >>>> >>>>>>>> >>>> >>>>>>>> On Mon, Feb 26, 2018 at 12:54 PM, Pedro Igor Silva < >>>> >>>> >>>> >>>> psilva at redhat.com> >>>> >>>>>>>> >>>> >>>>>>>> wrote: >>>> >>>>>>>>> >>>> >>>>>>>>> Isn't this somewhat related with what we used to have with >>>> >>>> >>>> >>>> MongoDB ? >>>> >>>>>>>>> >>>> >>>>>>>>> On Mon, Feb 26, 2018 at 2:35 PM, Bill Burke >>>> >>>>>>>>> >>>> >>>>>>>>> wrote: >>>> >>>>>>>>>> >>>> >>>>>>>>>> If we had a built-in, clusterable storage mechanism for >>>> >>>>>>>>>> Keycloak >>>> >>>>>>>>>> using >>>> >>>>>>>>>> Infinispan we would: >>>> >>>>>>>>>> * Shorten build times drastically. 30 minutes and growing >>>> >>>>>>>>>> for me >>>> >>>>>>>>>> for >>>> >>>>>>>>>> JPA builds. Liquibase + JPA startup takes 5-7 seconds on my >>>> >>>>>>>>>> box. >>>> >>>>>>>>>> * Simpler startup. No need to start a DB. >>>> >>>>>>>>>> * Reduce memory footprint? I think JPA is responsible for a >>>> >>>>>>>>>> lot >>>> >>>> >>>> >>>> of >>>> >>>>>>>>>> >>>> >>>>>>>>>> classes loaded. >>>> >>>>>>>>>> >>>> >>>>>>>>>> I've started some work on this in spare time. I'd say I'd be >>>> >>>> >>>> >>>> done >>>> >>>>>>>>>> >>>> >>>>>>>>>> in >>>> >>>>>>>>>> like 2 months considering the other work I have in queue. >>>> >>>>>>>>>> >>>> >>>>>>>>>> Looking at FineGrainAtomicMap as an implementation. Should >>>> >>>>>>>>>> make >>>> >>>> >>>> >>>> DB >>>> >>>>>>>>>> >>>> >>>>>>>>>> migration simple and replication quicker. >>>> >>>>>>>>>> >>>> >>>>>>>>>> >>>> >>>>>>>>>> -- >>>> >>>>>>>>>> Bill Burke >>>> >>>>>>>>>> Red Hat >>>> >>>>>>>>>> _______________________________________________ >>>> >>>>>>>>>> keycloak-dev mailing list >>>> >>>>>>>>>> keycloak-dev at lists.jboss.org >>>> >>>>>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>>> >>>>>>>>> >>>> >>>>>>>>> >>>> >>>>>>>> >>>> >>>>>>>> >>>> >>>>>>>> -- >>>> >>>>>>>> Bill Burke >>>> >>>>>>>> Red Hat >>>> >>>>>>> >>>> >>>>>>> >>>> >>>>>> >>>> >>>>>> >>>> >>>>>> -- >>>> >>>>>> Bill Burke >>>> >>>>>> Red Hat >>>> >>>>>> _______________________________________________ >>>> >>>>>> keycloak-dev mailing list >>>> >>>>>> keycloak-dev at lists.jboss.org >>>> >>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>>> >>>>> >>>> >>>>> >>>> >>>> >>>> >>>> >>>> >>>> -- >>>> >>>> Bill Burke >>>> >>>> Red Hat >>>> >>>> >>>> >>> >>>> >> _______________________________________________ >>>> >> keycloak-dev mailing list >>>> >> keycloak-dev at lists.jboss.org >>>> >> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>>> > >>>> > >>>> > >>>> >>>> >>>> >>>> -- >>>> Bill Burke >>>> Red Hat >>>> _______________________________________________ >>>> keycloak-dev mailing list >>>> keycloak-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev -- Bill Burke Red Hat From sthorger at redhat.com Mon Mar 5 11:45:16 2018 From: sthorger at redhat.com (Stian Thorgersen) Date: Mon, 5 Mar 2018 17:45:16 +0100 Subject: [keycloak-dev] infinispan as a storage mechanism In-Reply-To: References: <55656cbe-6b45-96a2-fb91-d8e791633b46@redhat.com> Message-ID: On 5 Mar 2018 3:21 pm, "Bill Burke" wrote: I don't see how any incremental improvements would be noticable when the bulk of the time running a single test in the IDE is spent in JPA/Liquibase initialization. This has really annoyed me for years. If we're only talking the time it takes to run a single test then improvements can be made to liquibase. We can create a new starting point. Then there's also Hibernate that could/should be improved. We talked to Andy about that a while ago and they where looking into it. For total execution time there's probably loads we can do, but all takes time and effort. Also, I always had this worry that our RDBMS requirement might be a turn off or complete overkill for some users, especially if they are storing everything in LDAP or doing identity brokering. This is different than Mongo in that this would be self-contained. In the long run, removing RDBMS as a hard requirement for us would be pretty huge. Removes a big installation headache for customers. Allows Keycloak to be clusterable out of the box with parameters that we control. Anyways, I've been implementing this off and on for almost a year and have never been able to finish it so we're arguing over vaporware. If we can find out from Infinispan team perhaps if it can do what we want and would work well then perhaps it is something worth spending time on calendar completing. Perhaps we can drop jpa altogether and use Infinispan with different stores instead. Maybe we could do a course dump realm config as a single blob, but do more broken up stuff for users, roles, clients, etc.. Would probably at least be worth looking into. On Mon, Mar 5, 2018 at 8:58 AM, Stian Thorgersen wrote: > To be honest the idea of replacing our JPA layer with Infinispan completely > is interesting if it works/performs. Having/maintaining two in the long run > is very unattractive > > On 5 Mar 2018 11:29 am, "Stian Thorgersen" wrote: >> >> With regards to test execution time we're talking extra maintenance effort >> to save a few seconds. The base testsuite takes 20 min to run and it only >> starts/initializes jpa/liquibase once. In memory h2 is actually a very fast >> persistence option once running so we're only talking about startup time. >> >> We'll also easily end up with issues where it worked on a local build with >> the mock persistence layer and it fails on jpa in ci. Or the other way >> around. Personally I really have no interest in debugging/fixing a mock >> persistence layer or adding/extending it for that matter. We have enough >> pita here with the undertow in ide vs full dist in Maven/vi already not sure >> why we would like to make life even more complicated for ourselves. >> >> I'm also sure there's loads of improvements we could do to the testsuite >> to make it run faster both for developers and CI. I would much rather like >> to see improvements/effort spent there than in a mock persistence layer for >> testing only. >> >> On 5 Mar 2018 10:56 am, "Boleslaw Dawidowicz" wrote: >>> >>> It testsuite local time is a main concern I know some companies are >>> mocking DB or part of data layer to keep it down to minutes. Having ?good >>> enough? but fast for local and proper setup in CI invoked per PR. Or proper >>> timely one invoked locally only rarely before wrapping up the work. >>> >>> >>> W dniu ?r., 28.02.2018 o 15:20 Bill Burke napisa?(a): >>>> >>>> I often have tests that pass within the IDE, or if run singly through >>>> maven, but fail on a maven build. So, I'm often running a full build. >>>> >>>> In my measurements, skipping Liquibase only shaves off 1-2 seconds >>>> (which is still a lot). JPA initialization takes 5 seconds. >>>> Testsuite slowness is 90% because of Liquibase/JPA. At least on my >>>> laptop. Eventually I'll be able to give you numbers when I finish the >>>> Infinispan backend, but I'm weeks away from that as I'm only doing it >>>> off and on. >>>> >>>> On Wed, Feb 28, 2018 at 4:23 AM, Marek Posolda >>>> wrote: >>>> > I am also personally not concerned about running full testsuite >>>> > through "mvn >>>> > clean install", however I agree will be good to improve startup when >>>> > you run >>>> > single test from IDE. >>>> > >>>> > We already use in-memory H2 by default on embedded undertow. But maybe >>>> > it >>>> > helps if we skip liquibase at all and let Hibernate to create the >>>> > schema >>>> > when running testsuite with in-mem H2? The problem with Liquibase is, >>>> > that >>>> > there are more and more changelogs and more and more changes and we >>>> > can't >>>> > get rid old changelogs. So there are many things like the table is >>>> > created >>>> > by jpa-changelog-1.0.0, but then immediately dropped by >>>> > jpa-changelog-1.5.0 >>>> > etc. This is not so big issue for production environments when schema >>>> > is >>>> > created just once, but sucks during development IMO. >>>> > >>>> > Question is, how much time is spent on schema initialization and how >>>> > much on >>>> > other initialization things (EG. importing master realm and "test" >>>> > realm >>>> > etc)... Maybe to try some startup profiling will help... >>>> > >>>> > Marek >>>> > >>>> > >>>> > >>>> > On 27/02/18 21:08, Stian Thorgersen wrote: >>>> >> >>>> >> It's not going to help with startup time, but perhaps one simple way >>>> >> to >>>> >> make the testsuite run faster would be configuring the h2 dB as >>>> >> in-mem/non-persisted. >>>> >> >>>> >> On 27 Feb 2018 7:11 pm, "Stian Thorgersen" >>>> >> wrote: >>>> >> >>>> >>> >>>> >>> On 27 February 2018 at 15:02, Bill Burke wrote: >>>> >>> >>>> >>>> This is something I've been doing off and on for awhile. An hour >>>> >>>> here >>>> >>>> or there. Its a lot of monotonous work. >>>> >>>> >>>> >>>> Well worth it IMO if our build times drop drastically. 30 min >>>> >>>> build >>>> >>>> is becoming burdensome. If the console tests get turned on >>>> >>>> combined >>>> >>>> with all the other tests that are added daily, I can see this >>>> >>>> turning >>>> >>>> into 60 min by the end of the year. Not to mention when I run a >>>> >>>> single test from the IDE it takes like 10 seconds to start. I'm >>>> >>>> just >>>> >>>> sick and tired of it. >>>> >>>> >>>> >>> I can only see how it saves time on starting the Keycloak server, >>>> >>> not for >>>> >>> individual tests. That means you're only saving a few seconds each >>>> >>> time >>>> >>> the >>>> >>> server is started, which is not many times for a full run. You'll >>>> >>> probably >>>> >>> end up shaving 1 min of the whole 30 min at best. >>>> >>> >>>> >>> Andy also mentioned that the Hibernate guys are working on >>>> >>> performance. >>>> >>> There is something weird about the Hibernate startup time in >>>> >>> general. So >>>> >>> if >>>> >>> there's improvements there that 1 min you could shave would become >>>> >>> even >>>> >>> less. >>>> >>> >>>> >>> We're also working towards having the full testsuite ran on PRs, >>>> >>> which >>>> >>> means as a dev you would be better of picking and running only the >>>> >>> tests >>>> >>> you believe may be affected and let the CI run the complete set of >>>> >>> jobs. >>>> >>> >>>> >>> I'd never bother running the admin console tests locally unless I've >>>> >>> done >>>> >>> some changes to the admin console. I also found that running the >>>> >>> tests >>>> >>> from >>>> >>> the IDE run significantly quicker than through Maven. The difference >>>> >>> there >>>> >>> is down to something else than JPA as that's used in both cases. >>>> >>> Personally >>>> >>> I very rarely build the full distro or run the tests from Maven at >>>> >>> all. I >>>> >>> just let Travis do that, while I run tests through the IDE. >>>> >>> >>>> >>> >>>> >>>> For migration, if you base your stored objects on Maps, you only >>>> >>>> have >>>> >>>> to worry about cases where you're modifying objects that are >>>> >>>> serialized. These would need to be versioned as per java >>>> >>>> serialization. New things >>>> >>>> >>>> >>> I really don't want us to maintain two different persistence layers. >>>> >>> It's >>>> >>> a lot of duplicated effort. Becomes even worse when you start >>>> >>> thinking >>>> >>> about things like migration, cross-dc, rolling upgrades, etc.. >>>> >>> >>>> >>> If you are suggesting to completely drop our JPA store altogether >>>> >>> and use >>>> >>> Infinispan with a cache store instead that could be an interesting >>>> >>> option, >>>> >>> but I have loads and loads of concerns around that. >>>> >>> >>>> >>> >>>> >>>> >>>> >>>> On Tue, Feb 27, 2018 at 1:53 AM, Stian Thorgersen >>>> >>>> >>>> >>>> wrote: >>>> >>>>> >>>> >>>>> I'm really not convinced about this. Infinispan still needs to >>>> >>>>> persist >>>> >>>> >>>> >>>> the >>>> >>>>> >>>> >>>>> data. It still needs to handle migration whenever we change >>>> >>>>> things. >>>> >>>>> It's >>>> >>>>> another layer to get working correctly, etc.. I think we have more >>>> >>>> >>>> >>>> important >>>> >>>>> >>>> >>>>> work than to work on another data layer. >>>> >>>>> >>>> >>>>> On 26 February 2018 at 21:47, Bill Burke >>>> >>>>> wrote: >>>> >>>>>> >>>> >>>>>> I'm thinking of this mostly for running our testsuite. If you're >>>> >>>>>> not >>>> >>>>>> developing on DB, much nicer if your test startup times is >>>> >>>>>> milliseconds rather than 5-10 secs. >>>> >>>>>> >>>> >>>>>> For production, I'm thinking more of when people need lightweight >>>> >>>>>> keycloak instances and are doing a lot of identity federation. >>>> >>>>>> This >>>> >>>>>> is really long term thoughts though. >>>> >>>>>> >>>> >>>>>> On Mon, Feb 26, 2018 at 2:56 PM, Pedro Igor Silva >>>> >>>>>> >>>> >>>>>> wrote: >>>> >>>>>>> >>>> >>>>>>> I think MongoDB will start supporting transactions very soon on >>>> >>>>>>> v4 >>>> >>>> >>>> >>>> .... >>>> >>>>>>> >>>> >>>>>>> I'm not sure about running both app and database in the same VM >>>> >>>> >>>> >>>> though. >>>> >>>>>>> >>>> >>>>>>> For >>>> >>>>>>> dev purposes that is fine, but in real world scenarios you >>>> >>>>>>> probably >>>> >>>> >>>> >>>> want >>>> >>>>>>> >>>> >>>>>>> to >>>> >>>>>>> avoid sharing resources (mem, cpu) with your DB. In your case, >>>> >>>>>>> people >>>> >>>>>>> will >>>> >>>>>>> probably need JBoss DataGrid in production. >>>> >>>>>>> >>>> >>>>>>> On Mon, Feb 26, 2018 at 4:30 PM, Bill Burke >>>> >>>> >>>> >>>> wrote: >>>> >>>>>>>> >>>> >>>>>>>> Other than MongoDB not supporting transactions or even >>>> >>>>>>>> sessions? >>>> >>>> >>>> >>>> And >>>> >>>>>>>> >>>> >>>>>>>> requiring a DB to be run in a separate VM? >>>> >>>>>>>> >>>> >>>>>>>> No not really :) >>>> >>>>>>>> >>>> >>>>>>>> >>>> >>>>>>>> >>>> >>>>>>>> On Mon, Feb 26, 2018 at 12:54 PM, Pedro Igor Silva < >>>> >>>> >>>> >>>> psilva at redhat.com> >>>> >>>>>>>> >>>> >>>>>>>> wrote: >>>> >>>>>>>>> >>>> >>>>>>>>> Isn't this somewhat related with what we used to have with >>>> >>>> >>>> >>>> MongoDB ? >>>> >>>>>>>>> >>>> >>>>>>>>> On Mon, Feb 26, 2018 at 2:35 PM, Bill Burke >>>> >>>>>>>>> >>>> >>>>>>>>> wrote: >>>> >>>>>>>>>> >>>> >>>>>>>>>> If we had a built-in, clusterable storage mechanism for >>>> >>>>>>>>>> Keycloak >>>> >>>>>>>>>> using >>>> >>>>>>>>>> Infinispan we would: >>>> >>>>>>>>>> * Shorten build times drastically. 30 minutes and growing >>>> >>>>>>>>>> for me >>>> >>>>>>>>>> for >>>> >>>>>>>>>> JPA builds. Liquibase + JPA startup takes 5-7 seconds on my >>>> >>>>>>>>>> box. >>>> >>>>>>>>>> * Simpler startup. No need to start a DB. >>>> >>>>>>>>>> * Reduce memory footprint? I think JPA is responsible for a >>>> >>>>>>>>>> lot >>>> >>>> >>>> >>>> of >>>> >>>>>>>>>> >>>> >>>>>>>>>> classes loaded. >>>> >>>>>>>>>> >>>> >>>>>>>>>> I've started some work on this in spare time. I'd say I'd be >>>> >>>> >>>> >>>> done >>>> >>>>>>>>>> >>>> >>>>>>>>>> in >>>> >>>>>>>>>> like 2 months considering the other work I have in queue. >>>> >>>>>>>>>> >>>> >>>>>>>>>> Looking at FineGrainAtomicMap as an implementation. Should >>>> >>>>>>>>>> make >>>> >>>> >>>> >>>> DB >>>> >>>>>>>>>> >>>> >>>>>>>>>> migration simple and replication quicker. >>>> >>>>>>>>>> >>>> >>>>>>>>>> >>>> >>>>>>>>>> -- >>>> >>>>>>>>>> Bill Burke >>>> >>>>>>>>>> Red Hat >>>> >>>>>>>>>> _______________________________________________ >>>> >>>>>>>>>> keycloak-dev mailing list >>>> >>>>>>>>>> keycloak-dev at lists.jboss.org >>>> >>>>>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>>> >>>>>>>>> >>>> >>>>>>>>> >>>> >>>>>>>> >>>> >>>>>>>> >>>> >>>>>>>> -- >>>> >>>>>>>> Bill Burke >>>> >>>>>>>> Red Hat >>>> >>>>>>> >>>> >>>>>>> >>>> >>>>>> >>>> >>>>>> >>>> >>>>>> -- >>>> >>>>>> Bill Burke >>>> >>>>>> Red Hat >>>> >>>>>> _______________________________________________ >>>> >>>>>> keycloak-dev mailing list >>>> >>>>>> keycloak-dev at lists.jboss.org >>>> >>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>>> >>>>> >>>> >>>>> >>>> >>>> >>>> >>>> >>>> >>>> -- >>>> >>>> Bill Burke >>>> >>>> Red Hat >>>> >>>> >>>> >>> >>>> >> _______________________________________________ >>>> >> keycloak-dev mailing list >>>> >> keycloak-dev at lists.jboss.org >>>> >> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>>> > >>>> > >>>> > >>>> >>>> >>>> >>>> -- >>>> Bill Burke >>>> Red Hat >>>> _______________________________________________ >>>> keycloak-dev mailing list >>>> keycloak-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev -- Bill Burke Red Hat From bburke at redhat.com Mon Mar 5 12:39:16 2018 From: bburke at redhat.com (Bill Burke) Date: Mon, 5 Mar 2018 12:39:16 -0500 Subject: [keycloak-dev] infinispan as a storage mechanism In-Reply-To: References: <55656cbe-6b45-96a2-fb91-d8e791633b46@redhat.com> Message-ID: On Mon, Mar 5, 2018 at 11:45 AM, Stian Thorgersen wrote: > > > On 5 Mar 2018 3:21 pm, "Bill Burke" wrote: > > I don't see how any incremental improvements would be noticable when > the bulk of the time running a single test in the IDE is spent in > JPA/Liquibase initialization. This has really annoyed me for years. > 1.5-2 secs for liquibase. 5 secs for JPA layer. > > If we're only talking the time it takes to run a single test then > improvements can be made to liquibase. We can create a new starting point. > Then there's also Hibernate that could/should be improved. We talked to Andy > about that a while ago and they where looking into it. > > For total execution time there's probably loads we can do, but all takes > time and effort. > > Also, I always had this worry that our RDBMS requirement might be a > turn off or complete overkill for some users, especially if they are > storing everything in LDAP or doing identity brokering. This is > different than Mongo in that this would be self-contained. In the > long run, removing RDBMS as a hard requirement for us would be pretty > huge. Removes a big installation headache for customers. Allows > Keycloak to be clusterable out of the box with parameters that we > control. > > Anyways, I've been implementing this off and on for almost a year and > have never been able to finish it so we're arguing over vaporware. > > > If we can find out from Infinispan team perhaps if it can do what we want > and would work well then perhaps it is something worth spending time on > calendar completing. Perhaps we can drop jpa altogether and use Infinispan > with different stores instead. Maybe we could do a course dump realm config > as a single blob, but do more broken up stuff for users, roles, clients, > etc.. Would probably at least be worth looking into. > > > On Mon, Mar 5, 2018 at 8:58 AM, Stian Thorgersen > wrote: >> To be honest the idea of replacing our JPA layer with Infinispan >> completely >> is interesting if it works/performs. Having/maintaining two in the long >> run >> is very unattractive >> >> On 5 Mar 2018 11:29 am, "Stian Thorgersen" wrote: >>> >>> With regards to test execution time we're talking extra maintenance >>> effort >>> to save a few seconds. The base testsuite takes 20 min to run and it only >>> starts/initializes jpa/liquibase once. In memory h2 is actually a very >>> fast >>> persistence option once running so we're only talking about startup time. >>> >>> We'll also easily end up with issues where it worked on a local build >>> with >>> the mock persistence layer and it fails on jpa in ci. Or the other way >>> around. Personally I really have no interest in debugging/fixing a mock >>> persistence layer or adding/extending it for that matter. We have enough >>> pita here with the undertow in ide vs full dist in Maven/vi already not >>> sure >>> why we would like to make life even more complicated for ourselves. >>> >>> I'm also sure there's loads of improvements we could do to the testsuite >>> to make it run faster both for developers and CI. I would much rather >>> like >>> to see improvements/effort spent there than in a mock persistence layer >>> for >>> testing only. >>> >>> On 5 Mar 2018 10:56 am, "Boleslaw Dawidowicz" >>> wrote: >>>> >>>> It testsuite local time is a main concern I know some companies are >>>> mocking DB or part of data layer to keep it down to minutes. Having >>>> ?good >>>> enough? but fast for local and proper setup in CI invoked per PR. Or >>>> proper >>>> timely one invoked locally only rarely before wrapping up the work. >>>> >>>> >>>> W dniu ?r., 28.02.2018 o 15:20 Bill Burke >>>> napisa?(a): >>>>> >>>>> I often have tests that pass within the IDE, or if run singly through >>>>> maven, but fail on a maven build. So, I'm often running a full build. >>>>> >>>>> In my measurements, skipping Liquibase only shaves off 1-2 seconds >>>>> (which is still a lot). JPA initialization takes 5 seconds. >>>>> Testsuite slowness is 90% because of Liquibase/JPA. At least on my >>>>> laptop. Eventually I'll be able to give you numbers when I finish the >>>>> Infinispan backend, but I'm weeks away from that as I'm only doing it >>>>> off and on. >>>>> >>>>> On Wed, Feb 28, 2018 at 4:23 AM, Marek Posolda >>>>> wrote: >>>>> > I am also personally not concerned about running full testsuite >>>>> > through "mvn >>>>> > clean install", however I agree will be good to improve startup when >>>>> > you run >>>>> > single test from IDE. >>>>> > >>>>> > We already use in-memory H2 by default on embedded undertow. But >>>>> > maybe >>>>> > it >>>>> > helps if we skip liquibase at all and let Hibernate to create the >>>>> > schema >>>>> > when running testsuite with in-mem H2? The problem with Liquibase is, >>>>> > that >>>>> > there are more and more changelogs and more and more changes and we >>>>> > can't >>>>> > get rid old changelogs. So there are many things like the table is >>>>> > created >>>>> > by jpa-changelog-1.0.0, but then immediately dropped by >>>>> > jpa-changelog-1.5.0 >>>>> > etc. This is not so big issue for production environments when schema >>>>> > is >>>>> > created just once, but sucks during development IMO. >>>>> > >>>>> > Question is, how much time is spent on schema initialization and how >>>>> > much on >>>>> > other initialization things (EG. importing master realm and "test" >>>>> > realm >>>>> > etc)... Maybe to try some startup profiling will help... >>>>> > >>>>> > Marek >>>>> > >>>>> > >>>>> > >>>>> > On 27/02/18 21:08, Stian Thorgersen wrote: >>>>> >> >>>>> >> It's not going to help with startup time, but perhaps one simple way >>>>> >> to >>>>> >> make the testsuite run faster would be configuring the h2 dB as >>>>> >> in-mem/non-persisted. >>>>> >> >>>>> >> On 27 Feb 2018 7:11 pm, "Stian Thorgersen" >>>>> >> wrote: >>>>> >> >>>>> >>> >>>>> >>> On 27 February 2018 at 15:02, Bill Burke wrote: >>>>> >>> >>>>> >>>> This is something I've been doing off and on for awhile. An hour >>>>> >>>> here >>>>> >>>> or there. Its a lot of monotonous work. >>>>> >>>> >>>>> >>>> Well worth it IMO if our build times drop drastically. 30 min >>>>> >>>> build >>>>> >>>> is becoming burdensome. If the console tests get turned on >>>>> >>>> combined >>>>> >>>> with all the other tests that are added daily, I can see this >>>>> >>>> turning >>>>> >>>> into 60 min by the end of the year. Not to mention when I run a >>>>> >>>> single test from the IDE it takes like 10 seconds to start. I'm >>>>> >>>> just >>>>> >>>> sick and tired of it. >>>>> >>>> >>>>> >>> I can only see how it saves time on starting the Keycloak server, >>>>> >>> not for >>>>> >>> individual tests. That means you're only saving a few seconds each >>>>> >>> time >>>>> >>> the >>>>> >>> server is started, which is not many times for a full run. You'll >>>>> >>> probably >>>>> >>> end up shaving 1 min of the whole 30 min at best. >>>>> >>> >>>>> >>> Andy also mentioned that the Hibernate guys are working on >>>>> >>> performance. >>>>> >>> There is something weird about the Hibernate startup time in >>>>> >>> general. So >>>>> >>> if >>>>> >>> there's improvements there that 1 min you could shave would become >>>>> >>> even >>>>> >>> less. >>>>> >>> >>>>> >>> We're also working towards having the full testsuite ran on PRs, >>>>> >>> which >>>>> >>> means as a dev you would be better of picking and running only the >>>>> >>> tests >>>>> >>> you believe may be affected and let the CI run the complete set of >>>>> >>> jobs. >>>>> >>> >>>>> >>> I'd never bother running the admin console tests locally unless >>>>> >>> I've >>>>> >>> done >>>>> >>> some changes to the admin console. I also found that running the >>>>> >>> tests >>>>> >>> from >>>>> >>> the IDE run significantly quicker than through Maven. The >>>>> >>> difference >>>>> >>> there >>>>> >>> is down to something else than JPA as that's used in both cases. >>>>> >>> Personally >>>>> >>> I very rarely build the full distro or run the tests from Maven at >>>>> >>> all. I >>>>> >>> just let Travis do that, while I run tests through the IDE. >>>>> >>> >>>>> >>> >>>>> >>>> For migration, if you base your stored objects on Maps, you only >>>>> >>>> have >>>>> >>>> to worry about cases where you're modifying objects that are >>>>> >>>> serialized. These would need to be versioned as per java >>>>> >>>> serialization. New things >>>>> >>>> >>>>> >>> I really don't want us to maintain two different persistence >>>>> >>> layers. >>>>> >>> It's >>>>> >>> a lot of duplicated effort. Becomes even worse when you start >>>>> >>> thinking >>>>> >>> about things like migration, cross-dc, rolling upgrades, etc.. >>>>> >>> >>>>> >>> If you are suggesting to completely drop our JPA store altogether >>>>> >>> and use >>>>> >>> Infinispan with a cache store instead that could be an interesting >>>>> >>> option, >>>>> >>> but I have loads and loads of concerns around that. >>>>> >>> >>>>> >>> >>>>> >>>> >>>>> >>>> On Tue, Feb 27, 2018 at 1:53 AM, Stian Thorgersen >>>>> >>>> >>>>> >>>> wrote: >>>>> >>>>> >>>>> >>>>> I'm really not convinced about this. Infinispan still needs to >>>>> >>>>> persist >>>>> >>>> >>>>> >>>> the >>>>> >>>>> >>>>> >>>>> data. It still needs to handle migration whenever we change >>>>> >>>>> things. >>>>> >>>>> It's >>>>> >>>>> another layer to get working correctly, etc.. I think we have >>>>> >>>>> more >>>>> >>>> >>>>> >>>> important >>>>> >>>>> >>>>> >>>>> work than to work on another data layer. >>>>> >>>>> >>>>> >>>>> On 26 February 2018 at 21:47, Bill Burke >>>>> >>>>> wrote: >>>>> >>>>>> >>>>> >>>>>> I'm thinking of this mostly for running our testsuite. If >>>>> >>>>>> you're >>>>> >>>>>> not >>>>> >>>>>> developing on DB, much nicer if your test startup times is >>>>> >>>>>> milliseconds rather than 5-10 secs. >>>>> >>>>>> >>>>> >>>>>> For production, I'm thinking more of when people need >>>>> >>>>>> lightweight >>>>> >>>>>> keycloak instances and are doing a lot of identity federation. >>>>> >>>>>> This >>>>> >>>>>> is really long term thoughts though. >>>>> >>>>>> >>>>> >>>>>> On Mon, Feb 26, 2018 at 2:56 PM, Pedro Igor Silva >>>>> >>>>>> >>>>> >>>>>> wrote: >>>>> >>>>>>> >>>>> >>>>>>> I think MongoDB will start supporting transactions very soon on >>>>> >>>>>>> v4 >>>>> >>>> >>>>> >>>> .... >>>>> >>>>>>> >>>>> >>>>>>> I'm not sure about running both app and database in the same VM >>>>> >>>> >>>>> >>>> though. >>>>> >>>>>>> >>>>> >>>>>>> For >>>>> >>>>>>> dev purposes that is fine, but in real world scenarios you >>>>> >>>>>>> probably >>>>> >>>> >>>>> >>>> want >>>>> >>>>>>> >>>>> >>>>>>> to >>>>> >>>>>>> avoid sharing resources (mem, cpu) with your DB. In your case, >>>>> >>>>>>> people >>>>> >>>>>>> will >>>>> >>>>>>> probably need JBoss DataGrid in production. >>>>> >>>>>>> >>>>> >>>>>>> On Mon, Feb 26, 2018 at 4:30 PM, Bill Burke >>>>> >>>> >>>>> >>>> wrote: >>>>> >>>>>>>> >>>>> >>>>>>>> Other than MongoDB not supporting transactions or even >>>>> >>>>>>>> sessions? >>>>> >>>> >>>>> >>>> And >>>>> >>>>>>>> >>>>> >>>>>>>> requiring a DB to be run in a separate VM? >>>>> >>>>>>>> >>>>> >>>>>>>> No not really :) >>>>> >>>>>>>> >>>>> >>>>>>>> >>>>> >>>>>>>> >>>>> >>>>>>>> On Mon, Feb 26, 2018 at 12:54 PM, Pedro Igor Silva < >>>>> >>>> >>>>> >>>> psilva at redhat.com> >>>>> >>>>>>>> >>>>> >>>>>>>> wrote: >>>>> >>>>>>>>> >>>>> >>>>>>>>> Isn't this somewhat related with what we used to have with >>>>> >>>> >>>>> >>>> MongoDB ? >>>>> >>>>>>>>> >>>>> >>>>>>>>> On Mon, Feb 26, 2018 at 2:35 PM, Bill Burke >>>>> >>>>>>>>> >>>>> >>>>>>>>> wrote: >>>>> >>>>>>>>>> >>>>> >>>>>>>>>> If we had a built-in, clusterable storage mechanism for >>>>> >>>>>>>>>> Keycloak >>>>> >>>>>>>>>> using >>>>> >>>>>>>>>> Infinispan we would: >>>>> >>>>>>>>>> * Shorten build times drastically. 30 minutes and growing >>>>> >>>>>>>>>> for me >>>>> >>>>>>>>>> for >>>>> >>>>>>>>>> JPA builds. Liquibase + JPA startup takes 5-7 seconds on my >>>>> >>>>>>>>>> box. >>>>> >>>>>>>>>> * Simpler startup. No need to start a DB. >>>>> >>>>>>>>>> * Reduce memory footprint? I think JPA is responsible for a >>>>> >>>>>>>>>> lot >>>>> >>>> >>>>> >>>> of >>>>> >>>>>>>>>> >>>>> >>>>>>>>>> classes loaded. >>>>> >>>>>>>>>> >>>>> >>>>>>>>>> I've started some work on this in spare time. I'd say I'd >>>>> >>>>>>>>>> be >>>>> >>>> >>>>> >>>> done >>>>> >>>>>>>>>> >>>>> >>>>>>>>>> in >>>>> >>>>>>>>>> like 2 months considering the other work I have in queue. >>>>> >>>>>>>>>> >>>>> >>>>>>>>>> Looking at FineGrainAtomicMap as an implementation. Should >>>>> >>>>>>>>>> make >>>>> >>>> >>>>> >>>> DB >>>>> >>>>>>>>>> >>>>> >>>>>>>>>> migration simple and replication quicker. >>>>> >>>>>>>>>> >>>>> >>>>>>>>>> >>>>> >>>>>>>>>> -- >>>>> >>>>>>>>>> Bill Burke >>>>> >>>>>>>>>> Red Hat >>>>> >>>>>>>>>> _______________________________________________ >>>>> >>>>>>>>>> keycloak-dev mailing list >>>>> >>>>>>>>>> keycloak-dev at lists.jboss.org >>>>> >>>>>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>>>> >>>>>>>>> >>>>> >>>>>>>>> >>>>> >>>>>>>> >>>>> >>>>>>>> >>>>> >>>>>>>> -- >>>>> >>>>>>>> Bill Burke >>>>> >>>>>>>> Red Hat >>>>> >>>>>>> >>>>> >>>>>>> >>>>> >>>>>> >>>>> >>>>>> >>>>> >>>>>> -- >>>>> >>>>>> Bill Burke >>>>> >>>>>> Red Hat >>>>> >>>>>> _______________________________________________ >>>>> >>>>>> keycloak-dev mailing list >>>>> >>>>>> keycloak-dev at lists.jboss.org >>>>> >>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>>>> >>>>> >>>>> >>>>> >>>>> >>>> >>>>> >>>> >>>>> >>>> -- >>>>> >>>> Bill Burke >>>>> >>>> Red Hat >>>>> >>>> >>>>> >>> >>>>> >> _______________________________________________ >>>>> >> keycloak-dev mailing list >>>>> >> keycloak-dev at lists.jboss.org >>>>> >> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>>>> > >>>>> > >>>>> > >>>>> >>>>> >>>>> >>>>> -- >>>>> Bill Burke >>>>> Red Hat >>>>> _______________________________________________ >>>>> keycloak-dev mailing list >>>>> keycloak-dev at lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > > -- > Bill Burke > Red Hat > > -- Bill Burke Red Hat From sthorger at redhat.com Mon Mar 5 15:04:57 2018 From: sthorger at redhat.com (Stian Thorgersen) Date: Mon, 5 Mar 2018 21:04:57 +0100 Subject: [keycloak-dev] infinispan as a storage mechanism In-Reply-To: References: <55656cbe-6b45-96a2-fb91-d8e791633b46@redhat.com> Message-ID: On 5 Mar 2018 5:39 pm, "Bill Burke" wrote: On Mon, Mar 5, 2018 at 11:45 AM, Stian Thorgersen wrote: > > > On 5 Mar 2018 3:21 pm, "Bill Burke" wrote: > > I don't see how any incremental improvements would be noticable when > the bulk of the time running a single test in the IDE is spent in > JPA/Liquibase initialization. This has really annoyed me for years. > 1.5-2 secs for liquibase. 5 secs for JPA layer. Which is just plain odd. Liquibase actually does a lot of work looping through the migration files to build the schema. What Hibernate does for 5 seconds is just weird. If I remember a long time ago when I was first annoyed by Hibernate startup time it was 5 seconds for a single entity war. > > If we're only talking the time it takes to run a single test then > improvements can be made to liquibase. We can create a new starting point. > Then there's also Hibernate that could/should be improved. We talked to Andy > about that a while ago and they where looking into it. > > For total execution time there's probably loads we can do, but all takes > time and effort. > > Also, I always had this worry that our RDBMS requirement might be a > turn off or complete overkill for some users, especially if they are > storing everything in LDAP or doing identity brokering. This is > different than Mongo in that this would be self-contained. In the > long run, removing RDBMS as a hard requirement for us would be pretty > huge. Removes a big installation headache for customers. Allows > Keycloak to be clusterable out of the box with parameters that we > control. > > Anyways, I've been implementing this off and on for almost a year and > have never been able to finish it so we're arguing over vaporware. > > > If we can find out from Infinispan team perhaps if it can do what we want > and would work well then perhaps it is something worth spending time on > calendar completing. Perhaps we can drop jpa altogether and use Infinispan > with different stores instead. Maybe we could do a course dump realm config > as a single blob, but do more broken up stuff for users, roles, clients, > etc.. Would probably at least be worth looking into. > > > On Mon, Mar 5, 2018 at 8:58 AM, Stian Thorgersen > wrote: >> To be honest the idea of replacing our JPA layer with Infinispan >> completely >> is interesting if it works/performs. Having/maintaining two in the long >> run >> is very unattractive >> >> On 5 Mar 2018 11:29 am, "Stian Thorgersen" wrote: >>> >>> With regards to test execution time we're talking extra maintenance >>> effort >>> to save a few seconds. The base testsuite takes 20 min to run and it only >>> starts/initializes jpa/liquibase once. In memory h2 is actually a very >>> fast >>> persistence option once running so we're only talking about startup time. >>> >>> We'll also easily end up with issues where it worked on a local build >>> with >>> the mock persistence layer and it fails on jpa in ci. Or the other way >>> around. Personally I really have no interest in debugging/fixing a mock >>> persistence layer or adding/extending it for that matter. We have enough >>> pita here with the undertow in ide vs full dist in Maven/vi already not >>> sure >>> why we would like to make life even more complicated for ourselves. >>> >>> I'm also sure there's loads of improvements we could do to the testsuite >>> to make it run faster both for developers and CI. I would much rather >>> like >>> to see improvements/effort spent there than in a mock persistence layer >>> for >>> testing only. >>> >>> On 5 Mar 2018 10:56 am, "Boleslaw Dawidowicz" >>> wrote: >>>> >>>> It testsuite local time is a main concern I know some companies are >>>> mocking DB or part of data layer to keep it down to minutes. Having >>>> ?good >>>> enough? but fast for local and proper setup in CI invoked per PR. Or >>>> proper >>>> timely one invoked locally only rarely before wrapping up the work. >>>> >>>> >>>> W dniu ?r., 28.02.2018 o 15:20 Bill Burke >>>> napisa?(a): >>>>> >>>>> I often have tests that pass within the IDE, or if run singly through >>>>> maven, but fail on a maven build. So, I'm often running a full build. >>>>> >>>>> In my measurements, skipping Liquibase only shaves off 1-2 seconds >>>>> (which is still a lot). JPA initialization takes 5 seconds. >>>>> Testsuite slowness is 90% because of Liquibase/JPA. At least on my >>>>> laptop. Eventually I'll be able to give you numbers when I finish the >>>>> Infinispan backend, but I'm weeks away from that as I'm only doing it >>>>> off and on. >>>>> >>>>> On Wed, Feb 28, 2018 at 4:23 AM, Marek Posolda >>>>> wrote: >>>>> > I am also personally not concerned about running full testsuite >>>>> > through "mvn >>>>> > clean install", however I agree will be good to improve startup when >>>>> > you run >>>>> > single test from IDE. >>>>> > >>>>> > We already use in-memory H2 by default on embedded undertow. But >>>>> > maybe >>>>> > it >>>>> > helps if we skip liquibase at all and let Hibernate to create the >>>>> > schema >>>>> > when running testsuite with in-mem H2? The problem with Liquibase is, >>>>> > that >>>>> > there are more and more changelogs and more and more changes and we >>>>> > can't >>>>> > get rid old changelogs. So there are many things like the table is >>>>> > created >>>>> > by jpa-changelog-1.0.0, but then immediately dropped by >>>>> > jpa-changelog-1.5.0 >>>>> > etc. This is not so big issue for production environments when schema >>>>> > is >>>>> > created just once, but sucks during development IMO. >>>>> > >>>>> > Question is, how much time is spent on schema initialization and how >>>>> > much on >>>>> > other initialization things (EG. importing master realm and "test" >>>>> > realm >>>>> > etc)... Maybe to try some startup profiling will help... >>>>> > >>>>> > Marek >>>>> > >>>>> > >>>>> > >>>>> > On 27/02/18 21:08, Stian Thorgersen wrote: >>>>> >> >>>>> >> It's not going to help with startup time, but perhaps one simple way >>>>> >> to >>>>> >> make the testsuite run faster would be configuring the h2 dB as >>>>> >> in-mem/non-persisted. >>>>> >> >>>>> >> On 27 Feb 2018 7:11 pm, "Stian Thorgersen" >>>>> >> wrote: >>>>> >> >>>>> >>> >>>>> >>> On 27 February 2018 at 15:02, Bill Burke wrote: >>>>> >>> >>>>> >>>> This is something I've been doing off and on for awhile. An hour >>>>> >>>> here >>>>> >>>> or there. Its a lot of monotonous work. >>>>> >>>> >>>>> >>>> Well worth it IMO if our build times drop drastically. 30 min >>>>> >>>> build >>>>> >>>> is becoming burdensome. If the console tests get turned on >>>>> >>>> combined >>>>> >>>> with all the other tests that are added daily, I can see this >>>>> >>>> turning >>>>> >>>> into 60 min by the end of the year. Not to mention when I run a >>>>> >>>> single test from the IDE it takes like 10 seconds to start. I'm >>>>> >>>> just >>>>> >>>> sick and tired of it. >>>>> >>>> >>>>> >>> I can only see how it saves time on starting the Keycloak server, >>>>> >>> not for >>>>> >>> individual tests. That means you're only saving a few seconds each >>>>> >>> time >>>>> >>> the >>>>> >>> server is started, which is not many times for a full run. You'll >>>>> >>> probably >>>>> >>> end up shaving 1 min of the whole 30 min at best. >>>>> >>> >>>>> >>> Andy also mentioned that the Hibernate guys are working on >>>>> >>> performance. >>>>> >>> There is something weird about the Hibernate startup time in >>>>> >>> general. So >>>>> >>> if >>>>> >>> there's improvements there that 1 min you could shave would become >>>>> >>> even >>>>> >>> less. >>>>> >>> >>>>> >>> We're also working towards having the full testsuite ran on PRs, >>>>> >>> which >>>>> >>> means as a dev you would be better of picking and running only the >>>>> >>> tests >>>>> >>> you believe may be affected and let the CI run the complete set of >>>>> >>> jobs. >>>>> >>> >>>>> >>> I'd never bother running the admin console tests locally unless >>>>> >>> I've >>>>> >>> done >>>>> >>> some changes to the admin console. I also found that running the >>>>> >>> tests >>>>> >>> from >>>>> >>> the IDE run significantly quicker than through Maven. The >>>>> >>> difference >>>>> >>> there >>>>> >>> is down to something else than JPA as that's used in both cases. >>>>> >>> Personally >>>>> >>> I very rarely build the full distro or run the tests from Maven at >>>>> >>> all. I >>>>> >>> just let Travis do that, while I run tests through the IDE. >>>>> >>> >>>>> >>> >>>>> >>>> For migration, if you base your stored objects on Maps, you only >>>>> >>>> have >>>>> >>>> to worry about cases where you're modifying objects that are >>>>> >>>> serialized. These would need to be versioned as per java >>>>> >>>> serialization. New things >>>>> >>>> >>>>> >>> I really don't want us to maintain two different persistence >>>>> >>> layers. >>>>> >>> It's >>>>> >>> a lot of duplicated effort. Becomes even worse when you start >>>>> >>> thinking >>>>> >>> about things like migration, cross-dc, rolling upgrades, etc.. >>>>> >>> >>>>> >>> If you are suggesting to completely drop our JPA store altogether >>>>> >>> and use >>>>> >>> Infinispan with a cache store instead that could be an interesting >>>>> >>> option, >>>>> >>> but I have loads and loads of concerns around that. >>>>> >>> >>>>> >>> >>>>> >>>> >>>>> >>>> On Tue, Feb 27, 2018 at 1:53 AM, Stian Thorgersen >>>>> >>>> >>>>> >>>> wrote: >>>>> >>>>> >>>>> >>>>> I'm really not convinced about this. Infinispan still needs to >>>>> >>>>> persist >>>>> >>>> >>>>> >>>> the >>>>> >>>>> >>>>> >>>>> data. It still needs to handle migration whenever we change >>>>> >>>>> things. >>>>> >>>>> It's >>>>> >>>>> another layer to get working correctly, etc.. I think we have >>>>> >>>>> more >>>>> >>>> >>>>> >>>> important >>>>> >>>>> >>>>> >>>>> work than to work on another data layer. >>>>> >>>>> >>>>> >>>>> On 26 February 2018 at 21:47, Bill Burke >>>>> >>>>> wrote: >>>>> >>>>>> >>>>> >>>>>> I'm thinking of this mostly for running our testsuite. If >>>>> >>>>>> you're >>>>> >>>>>> not >>>>> >>>>>> developing on DB, much nicer if your test startup times is >>>>> >>>>>> milliseconds rather than 5-10 secs. >>>>> >>>>>> >>>>> >>>>>> For production, I'm thinking more of when people need >>>>> >>>>>> lightweight >>>>> >>>>>> keycloak instances and are doing a lot of identity federation. >>>>> >>>>>> This >>>>> >>>>>> is really long term thoughts though. >>>>> >>>>>> >>>>> >>>>>> On Mon, Feb 26, 2018 at 2:56 PM, Pedro Igor Silva >>>>> >>>>>> >>>>> >>>>>> wrote: >>>>> >>>>>>> >>>>> >>>>>>> I think MongoDB will start supporting transactions very soon on >>>>> >>>>>>> v4 >>>>> >>>> >>>>> >>>> .... >>>>> >>>>>>> >>>>> >>>>>>> I'm not sure about running both app and database in the same VM >>>>> >>>> >>>>> >>>> though. >>>>> >>>>>>> >>>>> >>>>>>> For >>>>> >>>>>>> dev purposes that is fine, but in real world scenarios you >>>>> >>>>>>> probably >>>>> >>>> >>>>> >>>> want >>>>> >>>>>>> >>>>> >>>>>>> to >>>>> >>>>>>> avoid sharing resources (mem, cpu) with your DB. In your case, >>>>> >>>>>>> people >>>>> >>>>>>> will >>>>> >>>>>>> probably need JBoss DataGrid in production. >>>>> >>>>>>> >>>>> >>>>>>> On Mon, Feb 26, 2018 at 4:30 PM, Bill Burke >>>>> >>>> >>>>> >>>> wrote: >>>>> >>>>>>>> >>>>> >>>>>>>> Other than MongoDB not supporting transactions or even >>>>> >>>>>>>> sessions? >>>>> >>>> >>>>> >>>> And >>>>> >>>>>>>> >>>>> >>>>>>>> requiring a DB to be run in a separate VM? >>>>> >>>>>>>> >>>>> >>>>>>>> No not really :) >>>>> >>>>>>>> >>>>> >>>>>>>> >>>>> >>>>>>>> >>>>> >>>>>>>> On Mon, Feb 26, 2018 at 12:54 PM, Pedro Igor Silva < >>>>> >>>> >>>>> >>>> psilva at redhat.com> >>>>> >>>>>>>> >>>>> >>>>>>>> wrote: >>>>> >>>>>>>>> >>>>> >>>>>>>>> Isn't this somewhat related with what we used to have with >>>>> >>>> >>>>> >>>> MongoDB ? >>>>> >>>>>>>>> >>>>> >>>>>>>>> On Mon, Feb 26, 2018 at 2:35 PM, Bill Burke >>>>> >>>>>>>>> >>>>> >>>>>>>>> wrote: >>>>> >>>>>>>>>> >>>>> >>>>>>>>>> If we had a built-in, clusterable storage mechanism for >>>>> >>>>>>>>>> Keycloak >>>>> >>>>>>>>>> using >>>>> >>>>>>>>>> Infinispan we would: >>>>> >>>>>>>>>> * Shorten build times drastically. 30 minutes and growing >>>>> >>>>>>>>>> for me >>>>> >>>>>>>>>> for >>>>> >>>>>>>>>> JPA builds. Liquibase + JPA startup takes 5-7 seconds on my >>>>> >>>>>>>>>> box. >>>>> >>>>>>>>>> * Simpler startup. No need to start a DB. >>>>> >>>>>>>>>> * Reduce memory footprint? I think JPA is responsible for a >>>>> >>>>>>>>>> lot >>>>> >>>> >>>>> >>>> of >>>>> >>>>>>>>>> >>>>> >>>>>>>>>> classes loaded. >>>>> >>>>>>>>>> >>>>> >>>>>>>>>> I've started some work on this in spare time. I'd say I'd >>>>> >>>>>>>>>> be >>>>> >>>> >>>>> >>>> done >>>>> >>>>>>>>>> >>>>> >>>>>>>>>> in >>>>> >>>>>>>>>> like 2 months considering the other work I have in queue. >>>>> >>>>>>>>>> >>>>> >>>>>>>>>> Looking at FineGrainAtomicMap as an implementation. Should >>>>> >>>>>>>>>> make >>>>> >>>> >>>>> >>>> DB >>>>> >>>>>>>>>> >>>>> >>>>>>>>>> migration simple and replication quicker. >>>>> >>>>>>>>>> >>>>> >>>>>>>>>> >>>>> >>>>>>>>>> -- >>>>> >>>>>>>>>> Bill Burke >>>>> >>>>>>>>>> Red Hat >>>>> >>>>>>>>>> _______________________________________________ >>>>> >>>>>>>>>> keycloak-dev mailing list >>>>> >>>>>>>>>> keycloak-dev at lists.jboss.org >>>>> >>>>>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>>>> >>>>>>>>> >>>>> >>>>>>>>> >>>>> >>>>>>>> >>>>> >>>>>>>> >>>>> >>>>>>>> -- >>>>> >>>>>>>> Bill Burke >>>>> >>>>>>>> Red Hat >>>>> >>>>>>> >>>>> >>>>>>> >>>>> >>>>>> >>>>> >>>>>> >>>>> >>>>>> -- >>>>> >>>>>> Bill Burke >>>>> >>>>>> Red Hat >>>>> >>>>>> _______________________________________________ >>>>> >>>>>> keycloak-dev mailing list >>>>> >>>>>> keycloak-dev at lists.jboss.org >>>>> >>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>>>> >>>>> >>>>> >>>>> >>>>> >>>> >>>>> >>>> >>>>> >>>> -- >>>>> >>>> Bill Burke >>>>> >>>> Red Hat >>>>> >>>> >>>>> >>> >>>>> >> _______________________________________________ >>>>> >> keycloak-dev mailing list >>>>> >> keycloak-dev at lists.jboss.org >>>>> >> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>>>> > >>>>> > >>>>> > >>>>> >>>>> >>>>> >>>>> -- >>>>> Bill Burke >>>>> Red Hat >>>>> _______________________________________________ >>>>> keycloak-dev mailing list >>>>> keycloak-dev at lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > > -- > Bill Burke > Red Hat > > -- Bill Burke Red Hat From lholmqui at redhat.com Mon Mar 5 21:25:43 2018 From: lholmqui at redhat.com (Luke Holmquist) Date: Mon, 5 Mar 2018 21:25:43 -0500 Subject: [keycloak-dev] Question on Node.js adapter - Wrong response code when not logged in, maybe Message-ID: Hi, given this example application https://github.com/bucharest-gold/nodejs-rest-http-secured , there is 1 endpoint "/api/greeting", it is protected with the basic keycloak-connect setup. https://github.com/bucharest-gold/nodejs-rest-http-secured/blob/master/app.js#L49 If we run this locally, with "npm start", and just curl that endpoint, "curl http://localhost:3000/api/greeting" it will return with a 403. There was an issue raised that it should be a 401, https://github.com/bucharest-gold/nodejs-rest-http-secured/issues/52 The way this comment makes it sound, https://github.com/keycloak/keycloak-nodejs-connect/blob/master/index.js#L232 is that the 403 is correct If we look at the complimentary vert.x and swarm examples, https://github.com/openshiftio-vertx-boosters/vertx-secured-http-booster and https://github.com/wildfly-swarm-openshiftio-boosters/wfswarm-rest-http-secured a similar curl will result in a 401 when not logged in. I'm just wondering if that 403 the node adapter is correct and if so, why does it differ from the other runtimes -Luke From sblanc at redhat.com Tue Mar 6 01:55:10 2018 From: sblanc at redhat.com (Sebastien Blanc) Date: Tue, 6 Mar 2018 07:55:10 +0100 Subject: [keycloak-dev] Question on Node.js adapter - Wrong response code when not logged in, maybe In-Reply-To: References: Message-ID: Hi Luke, Yes this looks like a bug, 403 should only be returned if you are already authorized but you don't have the needed role for instance. When you are not authenticated we should just return a 401. Could you open a ticket for us ? Sebi On Tue, Mar 6, 2018 at 3:25 AM, Luke Holmquist wrote: > Hi, > > given this example application > https://github.com/bucharest-gold/nodejs-rest-http-secured , there is 1 > endpoint "/api/greeting", it is protected with the basic keycloak-connect > setup. > https://github.com/bucharest-gold/nodejs-rest-http-secured/ > blob/master/app.js#L49 > > > If we run this locally, with "npm start", and just curl that endpoint, > "curl http://localhost:3000/api/greeting" it will return with a 403. > > There was an issue raised that it should be a 401, > https://github.com/bucharest-gold/nodejs-rest-http-secured/issues/52 > > The way this comment makes it sound, > https://github.com/keycloak/keycloak-nodejs-connect/blob/ > master/index.js#L232 > is > that the 403 is correct > > > If we look at the complimentary vert.x and swarm examples, > https://github.com/openshiftio-vertx-boosters/vertx-secured-http-booster > and > > https://github.com/wildfly-swarm-openshiftio-boosters/ > wfswarm-rest-http-secured > > > a similar curl will result in a 401 when not logged in. > > > I'm just wondering if that 403 the node adapter is correct and if so, why > does it differ from the other runtimes > > > -Luke > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > From bruno at abstractj.org Tue Mar 6 08:07:25 2018 From: bruno at abstractj.org (Bruno Oliveira) Date: Tue, 06 Mar 2018 13:07:25 +0000 Subject: [keycloak-dev] Question on Node.js adapter - Wrong response code when not logged in, maybe In-Reply-To: References: Message-ID: +1 please file a Jira for it. On Tue, Mar 6, 2018 at 3:56 AM Sebastien Blanc wrote: > Hi Luke, > > Yes this looks like a bug, 403 should only be returned if you are already > authorized but you don't have the needed role for instance. When you are > not authenticated we should just return a 401. > Could you open a ticket for us ? > > Sebi > > > > On Tue, Mar 6, 2018 at 3:25 AM, Luke Holmquist > wrote: > > > Hi, > > > > given this example application > > https://github.com/bucharest-gold/nodejs-rest-http-secured , there is 1 > > endpoint "/api/greeting", it is protected with the basic keycloak-connect > > setup. > > https://github.com/bucharest-gold/nodejs-rest-http-secured/ > > blob/master/app.js#L49 > > > > > > If we run this locally, with "npm start", and just curl that endpoint, > > "curl http://localhost:3000/api/greeting" it will return with a 403. > > > > There was an issue raised that it should be a 401, > > https://github.com/bucharest-gold/nodejs-rest-http-secured/issues/52 > > > > The way this comment makes it sound, > > https://github.com/keycloak/keycloak-nodejs-connect/blob/ > > master/index.js#L232 > > is > > that the 403 is correct > > > > > > If we look at the complimentary vert.x and swarm examples, > > https://github.com/openshiftio-vertx-boosters/vertx-secured-http-booster > > and > > > > https://github.com/wildfly-swarm-openshiftio-boosters/ > > wfswarm-rest-http-secured > > > > > > a similar curl will result in a 401 when not logged in. > > > > > > I'm just wondering if that 403 the node adapter is correct and if so, why > > does it differ from the other runtimes > > > > > > -Luke > > _______________________________________________ > > keycloak-dev mailing list > > keycloak-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > From lholmqui at redhat.com Tue Mar 6 08:29:59 2018 From: lholmqui at redhat.com (Luke Holmquist) Date: Tue, 6 Mar 2018 08:29:59 -0500 Subject: [keycloak-dev] Question on Node.js adapter - Wrong response code when not logged in, maybe In-Reply-To: References: Message-ID: thanks guys!!, will do On Tue, Mar 6, 2018 at 8:07 AM, Bruno Oliveira wrote: > +1 please file a Jira for it. > > On Tue, Mar 6, 2018 at 3:56 AM Sebastien Blanc wrote: > >> Hi Luke, >> >> Yes this looks like a bug, 403 should only be returned if you are already >> authorized but you don't have the needed role for instance. When you are >> not authenticated we should just return a 401. >> Could you open a ticket for us ? >> >> Sebi >> >> >> >> On Tue, Mar 6, 2018 at 3:25 AM, Luke Holmquist >> wrote: >> >> > Hi, >> > >> > given this example application >> > https://github.com/bucharest-gold/nodejs-rest-http-secured , there is 1 >> > endpoint "/api/greeting", it is protected with the basic >> keycloak-connect >> > setup. >> > https://github.com/bucharest-gold/nodejs-rest-http-secured/ >> > blob/master/app.js#L49 >> > >> > >> > If we run this locally, with "npm start", and just curl that endpoint, >> > "curl http://localhost:3000/api/greeting" it will return with a 403. >> > >> > There was an issue raised that it should be a 401, >> > https://github.com/bucharest-gold/nodejs-rest-http-secured/issues/52 >> > >> > The way this comment makes it sound, >> > https://github.com/keycloak/keycloak-nodejs-connect/blob/ >> > master/index.js#L232 >> > is >> > that the 403 is correct >> > >> > >> > If we look at the complimentary vert.x and swarm examples, >> > https://github.com/openshiftio-vertx-boosters/ >> vertx-secured-http-booster >> > and >> > >> > https://github.com/wildfly-swarm-openshiftio-boosters/ >> > wfswarm-rest-http-secured >> > >> > >> > a similar curl will result in a 401 when not logged in. >> > >> > >> > I'm just wondering if that 403 the node adapter is correct and if so, >> why >> > does it differ from the other runtimes >> > >> > >> > -Luke >> > _______________________________________________ >> > keycloak-dev mailing list >> > keycloak-dev at lists.jboss.org >> > https://lists.jboss.org/mailman/listinfo/keycloak-dev >> > >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> > From lholmqui at redhat.com Tue Mar 6 08:32:04 2018 From: lholmqui at redhat.com (Luke Holmquist) Date: Tue, 6 Mar 2018 08:32:04 -0500 Subject: [keycloak-dev] Question on Node.js adapter - Wrong response code when not logged in, maybe In-Reply-To: References: Message-ID: https://issues.jboss.org/browse/KEYCLOAK-6810 On Tue, Mar 6, 2018 at 8:29 AM, Luke Holmquist wrote: > thanks guys!!, will do > > On Tue, Mar 6, 2018 at 8:07 AM, Bruno Oliveira > wrote: > >> +1 please file a Jira for it. >> >> On Tue, Mar 6, 2018 at 3:56 AM Sebastien Blanc wrote: >> >>> Hi Luke, >>> >>> Yes this looks like a bug, 403 should only be returned if you are already >>> authorized but you don't have the needed role for instance. When you are >>> not authenticated we should just return a 401. >>> Could you open a ticket for us ? >>> >>> Sebi >>> >>> >>> >>> On Tue, Mar 6, 2018 at 3:25 AM, Luke Holmquist >>> wrote: >>> >>> > Hi, >>> > >>> > given this example application >>> > https://github.com/bucharest-gold/nodejs-rest-http-secured , there is >>> 1 >>> > endpoint "/api/greeting", it is protected with the basic >>> keycloak-connect >>> > setup. >>> > https://github.com/bucharest-gold/nodejs-rest-http-secured/ >>> > blob/master/app.js#L49 >>> > >>> > >>> > If we run this locally, with "npm start", and just curl that endpoint, >>> > "curl http://localhost:3000/api/greeting" it will return with a 403. >>> > >>> > There was an issue raised that it should be a 401, >>> > https://github.com/bucharest-gold/nodejs-rest-http-secured/issues/52 >>> > >>> > The way this comment makes it sound, >>> > https://github.com/keycloak/keycloak-nodejs-connect/blob/ >>> > master/index.js#L232 >>> > is >>> > that the 403 is correct >>> > >>> > >>> > If we look at the complimentary vert.x and swarm examples, >>> > https://github.com/openshiftio-vertx-boosters/vertx-secured- >>> http-booster >>> > and >>> > >>> > https://github.com/wildfly-swarm-openshiftio-boosters/ >>> > wfswarm-rest-http-secured >>> > >>> > >>> > a similar curl will result in a 401 when not logged in. >>> > >>> > >>> > I'm just wondering if that 403 the node adapter is correct and if so, >>> why >>> > does it differ from the other runtimes >>> > >>> > >>> > -Luke >>> > _______________________________________________ >>> > keycloak-dev mailing list >>> > keycloak-dev at lists.jboss.org >>> > https://lists.jboss.org/mailman/listinfo/keycloak-dev >>> > >>> _______________________________________________ >>> keycloak-dev mailing list >>> keycloak-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>> >> > From aron.bustya.js at gmail.com Tue Mar 6 13:59:23 2018 From: aron.bustya.js at gmail.com (Aron Bustya) Date: Tue, 6 Mar 2018 19:59:23 +0100 Subject: [keycloak-dev] disable url check on introspection Message-ID: Hello! We are operating keycloak and an API gateway which protects our resource servers, the gateway uses the token introspection feature of keycloak to validate requests. Our problem is that keycloak only accepts introspection request when called with the same fqdn as the token was issued for, so the gateway cannot call keycloak using its internal address. I know this is a 'solvable' problem, but solutions raise further questions, and it would be simpler to just allow the introspection call without the url check. I see others have encountered the problem also: https://issues.jboss.org/browse/KEYCLOAK-5045 The RSATokenVerifier used for introspection actually has a checkRealmUrl setting, but it can't be influenced from any server configuration. So my question is: if I made the checkRealmUrl setting configurable using a realm attribute or client attribute, would that be an acceptable feature for a pull request? Best regards, ?ron Bustya From aron.bustya.js at gmail.com Tue Mar 6 14:13:17 2018 From: aron.bustya.js at gmail.com (Aron Bustya) Date: Tue, 6 Mar 2018 20:13:17 +0100 Subject: [keycloak-dev] make sending a request object mandatory for certain clients In-Reply-To: References: Message-ID: Hello! Can I get some reaction to this? (The community guidelines say I need to ask around before sending pull requests.) Regards, ?ron Bustya On 2 December 2017 at 04:44, Aron Bustya wrote: > Hi! > > I have a use case where the server must accept authorization requests only > when they contain a signed request object (should be configurable per > client). > > I have found a way to make the signing of the request object mandatory by > specifying a 'request.object.signature.alg' attribute on the client, but > this only applies if a request object exists in the first place. > > I would like to propose a pull request: It defines a new client attribute > 'request.object.required'. If this is set to 'true', the client must send a > request object when initiating an authorization request. > > Current code can be checked here: https://github.com/abustya/ > keycloak/commit/476912906a3ad0d290220a1f54abee073dba687a > > What do you think? > > Regards, > ?ron Bustya > From c.majeri at gmail.com Wed Mar 7 07:51:16 2018 From: c.majeri at gmail.com (Chervine Majeri) Date: Wed, 7 Mar 2018 13:51:16 +0100 Subject: [keycloak-dev] Running Keycloak in a clustered mode In-Reply-To: References: Message-ID: Hi, We're considering attempting the exact same setup, with 2 standalone keycloaks connected to the same backend DB. User session is one example. There are some other things, which won't work. We never tried to test such setup and I wouldn't do it. >From what I've seen, only what's stored in the cache ends up being different, meaning the HA models really only differ in that they have a distributed cache. Is this correct? Or does it affect the connection to the DB too? >From that assumption, seeing the content of "standalone-ha.xml", I see that it's mostly session related stuff and things like loginFailures that end up in the distributed cache. Since we have a session cookie, unique for every session, can we use session stickiness in the reverse-proxy to circumvent most the issues? Obviously the loginFailures feature wouldn't work all that well, but that would be acceptable for my use-case. Thanks, Chervine. From mposolda at redhat.com Wed Mar 7 12:30:34 2018 From: mposolda at redhat.com (Marek Posolda) Date: Wed, 7 Mar 2018 18:30:34 +0100 Subject: [keycloak-dev] Running Keycloak in a clustered mode In-Reply-To: References: Message-ID: <99fdb6b6-ce06-92f6-40db-ff26854aa0c4@redhat.com> On 07/03/18 13:51, Chervine Majeri wrote: > Hi, > We're considering attempting the exact same setup, with 2 standalone > keycloaks connected to the same backend DB. > > User session is one example. There are some other things, which won't > > work. We never tried to test such setup and I wouldn't do it. > > From what I've seen, only what's stored in the cache ends up being > different, meaning the HA models really only differ in that they have > a distributed cache. Is this correct? Or does it affect the connection > to the DB too? > > From that assumption, seeing the content of "standalone-ha.xml", I see > that it's mostly session related stuff and things like loginFailures > that end up in the distributed cache. > Since we have a session cookie, unique for every session, can we use > session stickiness in the reverse-proxy to circumvent most the issues? The session stickyness is usually not sufficient. The OpenID Connect specification uses some "backchannel" requests, which are not sent as part of browser session, but they are sent directly between client application and Keycloak (For example code-to-token request, Refresh token request etc). Those requests won't see sticky session cookie, and hence can be directed to the other node, then the one who owns the session. Only possibility, when everything may work is, if all your clients are using keycloak.js adapter (javascript clients run fully inside browser and so they can participate in sticky session as backchannel requests are sent from browser as well). There are also some other cases when sticky session is not sufficient. For example in scenarios when mail is sent to user (EG. "Forget password" functionality) and user clicks on the link, but the link is opened in the other browser then the one, who "owns" sticky session cookie. Then it may happen that request is served on the other browser then the one, who owns the session. Finally invalidations won't work. Keycloak uses caches to cache some data for performance reasons. Those caches are "realms", "users" and "keys" . Every cluster node cache the data locally, however when some change happens (data are updated), then the node, who did the update, must notify other nodes in cluster about the change. If you don't use cluster, this won't work and other cluster nodes won't be notified and will still see stale data in their caches. In other words, when for example you update user "john" on node1, then node2 won't be aware about this update and will still see stale (old) data of user "john" in it's cache. The only possibilities how to workaround is: - Disable cache entirely (See our docs for more details) - Ensure that cache is cleared after every update (This is usually not possible to achieve unless you have some special kind of deployment (EG. something close to read-only deployment)). Marek > > Obviously the loginFailures feature wouldn't work all that well, but > that would be acceptable for my use-case. > > Thanks, > Chervine. From sthorger at redhat.com Thu Mar 8 02:51:25 2018 From: sthorger at redhat.com (Stian Thorgersen) Date: Thu, 8 Mar 2018 08:51:25 +0100 Subject: [keycloak-dev] Keycloak.js - allow to provide custom adapters In-Reply-To: References: Message-ID: Adding a way to pass in a custom adapter would be fine to add. I think this is already supported though, but need to check code to confirm that (I'm travelling right now so can't do it now). However, what is it that you actually want? To extend the Cordova support to also be able to use the native browser (i.e. custom tabs on Android, https://openid.github.io/AppAuth-Android/)? If so that's something we would like to have directly. On 5 March 2018 at 15:25, Wojciech Trocki wrote: > Hi > > I have been using keycloak.js for more than year mainly with the mobile > applications (Cordova). > Library is pretty well designed however there are some minor limitations in > terms of what adapters could do. > > >From my point of view javascript library is missing ability to provide > some > custom implementations for adapters. > Additionally implementations are provided as objects so it's hard to see > and conform this undocumented interface. > I'm happy to contribute any changes that will make sense upstream. > > I have created issue to cover exact use case where this is needed: > https://issues.jboss.org/browse/KEYCLOAK-6798 > > Adding this functionality will also make it trivial to implement support > for different mobile platforms like ReactNative etc. > > Regards > Wojtek > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > From sthorger at redhat.com Thu Mar 8 02:59:21 2018 From: sthorger at redhat.com (Stian Thorgersen) Date: Thu, 8 Mar 2018 08:59:21 +0100 Subject: [keycloak-dev] disable url check on introspection In-Reply-To: References: Message-ID: This is just one out of several issues you'll encounter if you have clients reaching Keycloak through an internal IP address. I believe you can probably use Undertow filters to map the internal IP to a fqdn so Keycloak will use the proper domain name regardless. That would probably be the way we'd support this if/when we get around to doing it as we need the ability to map an internal IP address to a domain name. Keycloak always needs to know its domain name. On 6 March 2018 at 19:59, Aron Bustya wrote: > Hello! > > We are operating keycloak and an API gateway which protects our resource > servers, the gateway uses the token introspection feature of keycloak to > validate requests. > > Our problem is that keycloak only accepts introspection request when called > with the same fqdn as the token was issued for, so the gateway cannot call > keycloak using its internal address. > I know this is a 'solvable' problem, but solutions raise further questions, > and it would be simpler to just allow the introspection call without the > url check. > I see others have encountered the problem also: > https://issues.jboss.org/browse/KEYCLOAK-5045 > > The RSATokenVerifier used for introspection actually has a checkRealmUrl > setting, but it can't be influenced from any server configuration. > So my question is: if I made the checkRealmUrl setting configurable using a > realm attribute or client attribute, would that be an acceptable feature > for a pull request? > Best regards, > ?ron Bustya > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev From c.majeri at gmail.com Thu Mar 8 07:34:48 2018 From: c.majeri at gmail.com (Chervine Majeri) Date: Thu, 8 Mar 2018 13:34:48 +0100 Subject: [keycloak-dev] Running Keycloak in a clustered mode In-Reply-To: <99fdb6b6-ce06-92f6-40db-ff26854aa0c4@redhat.com> References: <99fdb6b6-ce06-92f6-40db-ff26854aa0c4@redhat.com> Message-ID: That's a lot more than I imagined, good thing I consulted here first! Sounds like I'll have to use the standalone-ha mode with distributed cache then. Thanks a lot for the explanations, Chervine. From mposolda at redhat.com Thu Mar 8 09:25:09 2018 From: mposolda at redhat.com (Marek Posolda) Date: Thu, 8 Mar 2018 15:25:09 +0100 Subject: [keycloak-dev] make sending a request object mandatory for certain clients In-Reply-To: References: Message-ID: <0cea416f-6bdb-9eeb-8770-0d9133a05f14@redhat.com> Hi, sorry to not respond earlier. Your usecase makes sense to me and the code you did as well. One minor thing, which is missing, is admin console update. I think you need to add new switch to the client details page. Please add it to same section like "Advanced config" where are other things like request object signature algorithm etc. Thanks, Marek On 06/03/18 20:13, Aron Bustya wrote: > Hello! > > Can I get some reaction to this? (The community guidelines say I need to > ask around before sending pull requests.) > > Regards, > ?ron Bustya > > On 2 December 2017 at 04:44, Aron Bustya wrote: > >> Hi! >> >> I have a use case where the server must accept authorization requests only >> when they contain a signed request object (should be configurable per >> client). >> >> I have found a way to make the signing of the request object mandatory by >> specifying a 'request.object.signature.alg' attribute on the client, but >> this only applies if a request object exists in the first place. >> >> I would like to propose a pull request: It defines a new client attribute >> 'request.object.required'. If this is set to 'true', the client must send a >> request object when initiating an authorization request. >> >> Current code can be checked here: https://github.com/abustya/ >> keycloak/commit/476912906a3ad0d290220a1f54abee073dba687a >> >> What do you think? >> >> Regards, >> ?ron Bustya >> > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev From mposolda at redhat.com Thu Mar 8 11:23:45 2018 From: mposolda at redhat.com (Marek Posolda) Date: Thu, 8 Mar 2018 17:23:45 +0100 Subject: [keycloak-dev] make sending a request object mandatory for certain clients In-Reply-To: <0cea416f-6bdb-9eeb-8770-0d9133a05f14@redhat.com> References: <0cea416f-6bdb-9eeb-8770-0d9133a05f14@redhat.com> Message-ID: <91dc9ea6-9112-ffa6-9bb9-512f4feef5a9@redhat.com> On 08/03/18 15:25, Marek Posolda wrote: > Hi, > > sorry to not respond earlier. Your usecase makes sense to me and the > code you did as well. One minor thing, which is missing, is admin > console update. I think you need to add new switch to the client > details page. Please add it to same section like "Advanced config" > where are other things like request object signature algorithm etc. Forgot to mention, that it will be nice if you send PR once you do it :) Thanks, Marek > > Thanks, > Marek > > On 06/03/18 20:13, Aron Bustya wrote: >> Hello! >> >> Can I get some reaction to this? (The community guidelines say I need to >> ask around before sending pull requests.) >> >> Regards, >> ?ron Bustya >> >> On 2 December 2017 at 04:44, Aron Bustya >> wrote: >> >>> Hi! >>> >>> I have a use case where the server must accept authorization >>> requests only >>> when they contain a signed request object (should be configurable per >>> client). >>> >>> I have found a way to make the signing of the request object >>> mandatory by >>> specifying a 'request.object.signature.alg' attribute on the client, >>> but >>> this only applies if a request object exists in the first place. >>> >>> I would like to propose a pull request: It defines a new client >>> attribute >>> 'request.object.required'. If this is set to 'true', the client must >>> send a >>> request object when initiating an authorization request. >>> >>> Current code can be checked here: https://github.com/abustya/ >>> keycloak/commit/476912906a3ad0d290220a1f54abee073dba687a >>> >>> What do you think? >>> >>> Regards, >>> ?ron Bustya >>> >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev > > From wtrocki at redhat.com Thu Mar 8 11:39:48 2018 From: wtrocki at redhat.com (Wojciech Trocki) Date: Thu, 8 Mar 2018 16:39:48 +0000 Subject: [keycloak-dev] Keycloak.js - allow to provide custom adapters In-Reply-To: References: Message-ID: > Adding a way to pass in a custom adapter would be fine to add. Thank you so much for that! This will help with so many issues and will allow community (like myself) to experiment with different platforms like ReactNative. I created PR to show what I mean: https://github.com/keycloak/keycloak/pull/5067 Change is really small and do not affect any current api. I'm just adding additional option to library that could be available for advanced use cases. I'm happy to do further improvements in this area, but that PR will be resolving main extensibility problem. > However, what is it that you actually want? To extend the Cordova support to also be able to use the native browser (i.e. custom tabs on Android, https://openid.github.io/AppAuth-Android/)? Idea is to be able to use keycloak.js adapter and configure it to match some security recommendations for mobile devices. The main thing is to avoid using hardcoded localhost url in redirects and to be able to redirects with protocol that will launch the application: https://github.com/keycloak/keycloak-js-bower/blob/master/dist/keycloak.js#L1056 could use `yourapp://...` protocol instead. This requires some additional setup and may not be suitable to be done directly in the keycloak.js adapter. Having this option will be good to produce ultra secure Cordova application template and work with other mobile cross platform tools that keycloak team do not need to care about. > If so that's something we would like to have directly. Happy to contribute that change, but this will mean that setup for Cordova will become more complex (additional plugins will be needed) This will involve much more documentation updates and I was worried if I will suggest that option it could be really hard to get that merged. I would say this could be phase 2 of this work where actual adapters will be available outside keycloak.js class and then they could be passed to constructor. Every adapter will require different arguments or even external plugins (for Cordova etc.) and could have dedicated chapter in documentation. To implement that for Cordova adapter an app identifier URL would also need to be defined. This will be used to perform redirects back to yourapp:// namespaces, rather than just URL's. Regards On Thu, Mar 8, 2018 at 7:51 AM, Stian Thorgersen wrote: > Adding a way to pass in a custom adapter would be fine to add. I think > this is already supported though, but need to check code to confirm that > (I'm travelling right now so can't do it now). > > However, what is it that you actually want? To extend the Cordova support > to also be able to use the native browser (i.e. custom tabs on Android, > https://openid.github.io/AppAuth-Android/)? If so that's something we > would like to have directly. > > On 5 March 2018 at 15:25, Wojciech Trocki wrote: > >> Hi >> >> I have been using keycloak.js for more than year mainly with the mobile >> applications (Cordova). >> Library is pretty well designed however there are some minor limitations >> in >> terms of what adapters could do. >> >> >From my point of view javascript library is missing ability to provide >> some >> custom implementations for adapters. >> Additionally implementations are provided as objects so it's hard to see >> and conform this undocumented interface. >> I'm happy to contribute any changes that will make sense upstream. >> >> I have created issue to cover exact use case where this is needed: >> https://issues.jboss.org/browse/KEYCLOAK-6798 >> >> Adding this functionality will also make it trivial to implement support >> for different mobile platforms like ReactNative etc. >> >> Regards >> Wojtek >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> > > -- WOJCIECH TROCKI Red Hat Mobile IM: wtrocki From naftali at vanderloon.nl Thu Mar 8 11:52:06 2018 From: naftali at vanderloon.nl (Naftali van der Loon) Date: Thu, 8 Mar 2018 17:52:06 +0100 Subject: [keycloak-dev] kubernetes keycloak chart: persistent volume for themes? Message-ID: Hi, I'm using the kubernetes keycloak chart, and I must say, very nice piece of work! This helped me so much! Only question I have is: what is the best way to deploy the theme in a HA setup? I think ideal would be a to use a persistent volume. Or is there another way to get this working? Thanks for your help in advance! Grz Naftali From youssef.elhouti at gmail.com Thu Mar 8 19:11:12 2018 From: youssef.elhouti at gmail.com (Youssef EL HOUTI) Date: Fri, 9 Mar 2018 01:11:12 +0100 Subject: [keycloak-dev] Testing a custom Provider In-Reply-To: References: Message-ID: Hi Martin, These two examples are a bit confusing for someone starting with arquillian, but thanks for pointing me to them, they?ve been a good starting point. I finally managed to understand how arquillian works and make some tests. For any one interested here is the module: https://github.com/cloudtrust/keycloak-export Thanks again for the help Bests > On 23 Feb 2018, at 08:35, Martin Kanis wrote: > > Hi Youssef, > > try to have a look to Keycloak quickstarts repository [1][2] where you can find an examples how to test providers. > > Hope this helps you. > > Martin > > [1] https://github.com/keycloak/keycloak-quickstarts/blob/latest/action-token-authenticator/src/test/java/org/keycloak/quickstart/ArquillianActionTokenWithAuthenticatorTest.java > [2] https://github.com/keycloak/keycloak-quickstarts/blob/latest/action-token-required-action/src/test/java/org/keycloak/quickstart/ArquillianActionTokenTest.java > > On Fri, Feb 23, 2018 at 7:27 AM, Youssef EL HOUTI > wrote: > Hi, > > I'm building a custom RealmResourceProvider to be able run a full realm > export and import while the app is running. Since these are sensitive > tasks, I want to secure the endpoint. I think i managed to do that by > "copying" what is done with the adminResource. > Now I want to (integration) test my custom provider > How should proceed to build tests like the ones available in the test suite > (using: AbstractKeycloakTest) > > Also is this the right approach? > > Things I would like to test: > User is connected to master and has create-realm role to be able to import > new realm > User is importing from the realm specified in the file to avoid mistakes > User has the role manage-realm to be able to import... > ... > > Thanks for your help > > Youssef > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > From aron.bustya.js at gmail.com Fri Mar 9 03:58:48 2018 From: aron.bustya.js at gmail.com (Aron Bustya) Date: Fri, 9 Mar 2018 09:58:48 +0100 Subject: [keycloak-dev] disable url check on introspection In-Reply-To: References: Message-ID: Hi Stian! We actually have clients reach keycloak through it's the internal address. We use these for integration suff like client registration, user data querying etc. We haven't encountered any issues other than the one with introspection. I'll look into undertow filters though. Thanks, ?ron Bustya On 8 March 2018 at 08:59, Stian Thorgersen wrote: > This is just one out of several issues you'll encounter if you have > clients reaching Keycloak through an internal IP address. > > I believe you can probably use Undertow filters to map the internal IP to > a fqdn so Keycloak will use the proper domain name regardless. That would > probably be the way we'd support this if/when we get around to doing it as > we need the ability to map an internal IP address to a domain name. > Keycloak always needs to know its domain name. > > On 6 March 2018 at 19:59, Aron Bustya wrote: > >> Hello! >> >> We are operating keycloak and an API gateway which protects our resource >> servers, the gateway uses the token introspection feature of keycloak to >> validate requests. >> >> Our problem is that keycloak only accepts introspection request when >> called >> with the same fqdn as the token was issued for, so the gateway cannot call >> keycloak using its internal address. >> I know this is a 'solvable' problem, but solutions raise further >> questions, >> and it would be simpler to just allow the introspection call without the >> url check. >> I see others have encountered the problem also: >> https://issues.jboss.org/browse/KEYCLOAK-5045 >> >> The RSATokenVerifier used for introspection actually has a checkRealmUrl >> setting, but it can't be influenced from any server configuration. >> So my question is: if I made the checkRealmUrl setting configurable using >> a >> realm attribute or client attribute, would that be an acceptable feature >> for a pull request? > > >> Best regards, >> ?ron Bustya >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > From aron.bustya.js at gmail.com Fri Mar 9 04:32:47 2018 From: aron.bustya.js at gmail.com (Aron Bustya) Date: Fri, 9 Mar 2018 10:32:47 +0100 Subject: [keycloak-dev] make sending a request object mandatory for certain clients In-Reply-To: <91dc9ea6-9112-ffa6-9bb9-512f4feef5a9@redhat.com> References: <0cea416f-6bdb-9eeb-8770-0d9133a05f14@redhat.com> <91dc9ea6-9112-ffa6-9bb9-512f4feef5a9@redhat.com> Message-ID: Hi Marek, Thans for the reply. In the meantime I found out that we must only accept a request object entered directly, and not a request_uri (my first implementation handles the two together). But I'm afraid this makes the configuration more complicated. I can imagine it with 3 switches: -Accept auth. request without request object -Accept auth. request with request object included in request param -Accept auth. request with request object referenced with request_uri (All of them true by default.) Or maybe with a dropdown "Accept auth. request": -any (default) -with request object included in request param or referenced with request_uri -with request object included in request param -with request object referenced with request_uri Is this too much to add on the UI? Do you have a better idea? Thanks, ?ron On 8 March 2018 at 17:23, Marek Posolda wrote: > On 08/03/18 15:25, Marek Posolda wrote: > >> Hi, >> >> sorry to not respond earlier. Your usecase makes sense to me and the code >> you did as well. One minor thing, which is missing, is admin console >> update. I think you need to add new switch to the client details page. >> Please add it to same section like "Advanced config" where are other things >> like request object signature algorithm etc. >> > Forgot to mention, that it will be nice if you send PR once you do it :) > > Thanks, > Marek > > >> Thanks, >> Marek >> >> On 06/03/18 20:13, Aron Bustya wrote: >> >>> Hello! >>> >>> Can I get some reaction to this? (The community guidelines say I need to >>> ask around before sending pull requests.) >>> >>> Regards, >>> ?ron Bustya >>> >>> On 2 December 2017 at 04:44, Aron Bustya >>> wrote: >>> >>> Hi! >>>> >>>> I have a use case where the server must accept authorization requests >>>> only >>>> when they contain a signed request object (should be configurable per >>>> client). >>>> >>>> I have found a way to make the signing of the request object mandatory >>>> by >>>> specifying a 'request.object.signature.alg' attribute on the client, but >>>> this only applies if a request object exists in the first place. >>>> >>>> I would like to propose a pull request: It defines a new client >>>> attribute >>>> 'request.object.required'. If this is set to 'true', the client must >>>> send a >>>> request object when initiating an authorization request. >>>> >>>> Current code can be checked here: https://github.com/abustya/ >>>> keycloak/commit/476912906a3ad0d290220a1f54abee073dba687a >>>> >>>> What do you think? >>>> >>>> Regards, >>>> ?ron Bustya >>>> >>>> _______________________________________________ >>> keycloak-dev mailing list >>> keycloak-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>> >> >> >> > From mposolda at redhat.com Fri Mar 9 05:01:38 2018 From: mposolda at redhat.com (Marek Posolda) Date: Fri, 9 Mar 2018 11:01:38 +0100 Subject: [keycloak-dev] make sending a request object mandatory for certain clients In-Reply-To: References: <0cea416f-6bdb-9eeb-8770-0d9133a05f14@redhat.com> <91dc9ea6-9112-ffa6-9bb9-512f4feef5a9@redhat.com> Message-ID: <02916eba-3638-fb71-0d05-2247f6d8daeb@redhat.com> Ah, really? I am curious why you have this requirement? Is it due the security? I wonder that if request is signed with the private key of the client, then it's not any difference regarding security if it's "request" or "request_uri" . It can't happen that someone will be able to construct request object and "put" it on specific URI due the fact that he won't be able to sign it (unless he steal the client RSA key, but that would be broken security anyway and he will be able to construct "request" object the exactly same way). Thanks, Marek On 09/03/18 10:32, Aron Bustya wrote: > Hi Marek, > > Thans for the reply. > In the meantime I found out that we must only accept a request object > entered directly, and not a request_uri (my first implementation > handles the two together). > > But I'm afraid this makes the configuration more complicated. > > I can imagine it with 3 switches: > -Accept auth. request without request object > -Accept auth. request with request object included in request param > -Accept auth. request with request object?referenced with request_uri > (All of them true by default.) > > Or maybe with a dropdown "Accept auth. request": > -any (default) > -with request object included in request paramor referenced > withrequest_uri > -with request object included in request param > -withrequest object?referenced withrequest_uri > > Is this too much to add on the UI? > Do you have a better idea? > > Thanks, > ?ron > > > On 8 March 2018 at 17:23, Marek Posolda > wrote: > > On 08/03/18 15:25, Marek Posolda wrote: > > Hi, > > sorry to not respond earlier. Your usecase makes sense to me > and the code you did as well. One minor thing, which is > missing, is admin console update. I think you need to add new > switch to the client details page. Please add it to same > section like "Advanced config" where are other things like > request object signature algorithm etc. > > Forgot to mention, that it will be nice if you send PR once you do > it :) > > Thanks, > Marek > > > Thanks, > Marek > > On 06/03/18 20:13, Aron Bustya wrote: > > Hello! > > Can I get some reaction to this? (The community guidelines > say I need to > ask around before sending pull requests.) > > Regards, > ?ron Bustya > > On 2 December 2017 at 04:44, Aron Bustya > > wrote: > > Hi! > > I have a use case where the server must accept > authorization requests only > when they contain a signed request object (should be > configurable per > client). > > I have found a way to make the signing of the request > object mandatory by > specifying a 'request.object.signature.alg' attribute > on the client, but > this only applies if a request object exists in the > first place. > > I would like to propose a pull request: It defines a > new client attribute > 'request.object.required'. If this is set to 'true', > the client must send a > request object when initiating an authorization request. > > Current code can be checked here: > https://github.com/abustya/ > keycloak/commit/476912906a3ad0d290220a1f54abee073dba687a > > What do you think? > > Regards, > ?ron Bustya > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > > > > From aron.bustya.js at gmail.com Fri Mar 9 07:16:59 2018 From: aron.bustya.js at gmail.com (Aron Bustya) Date: Fri, 9 Mar 2018 13:16:59 +0100 Subject: [keycloak-dev] make sending a request object mandatory for certain clients In-Reply-To: <02916eba-3638-fb71-0d05-2247f6d8daeb@redhat.com> References: <0cea416f-6bdb-9eeb-8770-0d9133a05f14@redhat.com> <91dc9ea6-9112-ffa6-9bb9-512f4feef5a9@redhat.com> <02916eba-3638-fb71-0d05-2247f6d8daeb@redhat.com> Message-ID: I am not entirely sure, to be honest. I also think the signature should be enogh for security. We are implementing this specification: https://openbanking.atlassian.net/wiki/spaces/DZ/pages/7046134/Open+Banking+Security+Profile+-+Implementer+s+Draft+v1.1.0 The only reasoning for the decision is: "OpenBanking, in conjuction with major IAM vendors, is ruling out the use of JWT Request objects by reference due a number of delivery risks and remaining security concerns." Not very specific. I'll check with our architect if we really need to comply with this, or requiring any kind of request object will be enough. Thanks, ?ron On 9 March 2018 at 11:01, Marek Posolda wrote: > Ah, really? > > I am curious why you have this requirement? Is it due the security? I > wonder that if request is signed with the private key of the client, then > it's not any difference regarding security if it's "request" or > "request_uri" . It can't happen that someone will be able to construct > request object and "put" it on specific URI due the fact that he won't be > able to sign it (unless he steal the client RSA key, but that would be > broken security anyway and he will be able to construct "request" object > the exactly same way). > > Thanks, > Marek > > > On 09/03/18 10:32, Aron Bustya wrote: > > Hi Marek, > > Thans for the reply. > In the meantime I found out that we must only accept a request object > entered directly, and not a request_uri (my first implementation handles > the two together). > > But I'm afraid this makes the configuration more complicated. > > I can imagine it with 3 switches: > -Accept auth. request without request object > -Accept auth. request with request object included in request param > -Accept auth. request with request object referenced with request_uri > (All of them true by default.) > > Or maybe with a dropdown "Accept auth. request": > -any (default) > -with request object included in request param or referenced with > request_uri > -with request object included in request param > -with request object referenced with request_uri > > Is this too much to add on the UI? > Do you have a better idea? > > Thanks, > ?ron > > > On 8 March 2018 at 17:23, Marek Posolda wrote: > >> On 08/03/18 15:25, Marek Posolda wrote: >> >>> Hi, >>> >>> sorry to not respond earlier. Your usecase makes sense to me and the >>> code you did as well. One minor thing, which is missing, is admin console >>> update. I think you need to add new switch to the client details page. >>> Please add it to same section like "Advanced config" where are other things >>> like request object signature algorithm etc. >>> >> Forgot to mention, that it will be nice if you send PR once you do it :) >> >> Thanks, >> Marek >> >> >>> Thanks, >>> Marek >>> >>> On 06/03/18 20:13, Aron Bustya wrote: >>> >>>> Hello! >>>> >>>> Can I get some reaction to this? (The community guidelines say I need to >>>> ask around before sending pull requests.) >>>> >>>> Regards, >>>> ?ron Bustya >>>> >>>> On 2 December 2017 at 04:44, Aron Bustya >>>> wrote: >>>> >>>> Hi! >>>>> >>>>> I have a use case where the server must accept authorization requests >>>>> only >>>>> when they contain a signed request object (should be configurable per >>>>> client). >>>>> >>>>> I have found a way to make the signing of the request object mandatory >>>>> by >>>>> specifying a 'request.object.signature.alg' attribute on the client, >>>>> but >>>>> this only applies if a request object exists in the first place. >>>>> >>>>> I would like to propose a pull request: It defines a new client >>>>> attribute >>>>> 'request.object.required'. If this is set to 'true', the client must >>>>> send a >>>>> request object when initiating an authorization request. >>>>> >>>>> Current code can be checked here: https://github.com/abustya/ >>>>> keycloak/commit/476912906a3ad0d290220a1f54abee073dba687a >>>>> >>>>> What do you think? >>>>> >>>>> Regards, >>>>> ?ron Bustya >>>>> >>>>> _______________________________________________ >>>> keycloak-dev mailing list >>>> keycloak-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>>> >>> >>> >>> >> > > From bela.berde at gmail.com Fri Mar 9 10:22:32 2018 From: bela.berde at gmail.com (Bela Berde) Date: Fri, 9 Mar 2018 16:22:32 +0100 Subject: [keycloak-dev] Configuring the built GitHub version Message-ID: Hi, I am using the GitHub version that I am recompiling if necessary. Now, I want to configure the built binary with a realm etc. Where should I add my json files? Many thanks From thomas.darimont at googlemail.com Fri Mar 9 10:48:25 2018 From: thomas.darimont at googlemail.com (Thomas Darimont) Date: Fri, 9 Mar 2018 16:48:25 +0100 Subject: [keycloak-dev] Configuring the built GitHub version In-Reply-To: References: Message-ID: Hi Bela, I think you should use the keycloak-user list for such questions. The keycloak documentation contains a section about import / export of realms. http://www.keycloak.org/docs/3.2/server_admin/topics/export-import.html You could also look at this Dockerfile for a concrete example. https://github.com/dfranssen/docker-keycloak-import-realm/blob/master/Dockerfile Cheers, Thomas Am 09.03.2018 4:33 nachm. schrieb "Bela Berde" : > Hi, > I am using the GitHub version that I am recompiling if necessary. > > Now, I want to configure the built binary with a realm etc. > > Where should I add my json files? > > Many thanks > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > From youssef.elhouti at gmail.com Fri Mar 9 16:35:27 2018 From: youssef.elhouti at gmail.com (Youssef EL HOUTI) Date: Fri, 9 Mar 2018 22:35:27 +0100 Subject: [keycloak-dev] Arquillian test override keycloak class Message-ID: Hi, I'm writing a module for keycloak to deny access for clients using policies (the same way it's done with UMA but before gicing the token the first time). To achieve that I need my module to override some classes (ex: org.keycloak.protocol.oidc.endpoints.TokenEndpoint). In my Arquillian test, I do the following: @Deployment(name=MODULE_JAR, testable = false) @TargetsContainer("keycloak-remote") public static Archive createProviderArchive() throws IOException { return ShrinkWrap.create(JavaArchive.class, "keycloak-authorization.jar") .addClasses( org.keycloak.protocol.oidc.endpoints.TokenEndpoint.class, LocalAuthorizationService.class) .addAsManifestResource(new File("src/test/resources", "MANIFEST.MF")) ; Unfortunately it doesn't work, any ideas please. Thank you. From aron.bustya.js at gmail.com Mon Mar 12 03:53:19 2018 From: aron.bustya.js at gmail.com (Aron Bustya) Date: Mon, 12 Mar 2018 08:53:19 +0100 Subject: [keycloak-dev] make sending a request object mandatory for certain clients In-Reply-To: References: <0cea416f-6bdb-9eeb-8770-0d9133a05f14@redhat.com> <91dc9ea6-9112-ffa6-9bb9-512f4feef5a9@redhat.com> <02916eba-3638-fb71-0d05-2247f6d8daeb@redhat.com> Message-ID: Hi, it turns out we do need to comply with this. Another way of putting it on the UI would be to add a switch "Request object required" (false by default). And if is set to true, display a dropdown "Request object delivery method" with options of "any" (default), "by value", "by reference". Is it ok if I do this? Thanks, ?ron On 9 March 2018 at 13:16, Aron Bustya wrote: > I am not entirely sure, to be honest. I also think the signature should be > enogh for security. > > We are implementing this specification: https://openbanking.atlassian. > net/wiki/spaces/DZ/pages/7046134/Open+Banking+Security+ > Profile+-+Implementer+s+Draft+v1.1.0 > The only reasoning for the decision is: > "OpenBanking, in conjuction with major IAM vendors, is ruling out the use > of JWT Request objects by reference due a number of delivery risks and > remaining security concerns." > Not very specific. > > I'll check with our architect if we really need to comply with this, or > requiring any kind of request object will be enough. > > Thanks, > ?ron > > On 9 March 2018 at 11:01, Marek Posolda wrote: > >> Ah, really? >> >> I am curious why you have this requirement? Is it due the security? I >> wonder that if request is signed with the private key of the client, then >> it's not any difference regarding security if it's "request" or >> "request_uri" . It can't happen that someone will be able to construct >> request object and "put" it on specific URI due the fact that he won't be >> able to sign it (unless he steal the client RSA key, but that would be >> broken security anyway and he will be able to construct "request" object >> the exactly same way). >> >> Thanks, >> Marek >> >> >> On 09/03/18 10:32, Aron Bustya wrote: >> >> Hi Marek, >> >> Thans for the reply. >> In the meantime I found out that we must only accept a request object >> entered directly, and not a request_uri (my first implementation handles >> the two together). >> >> But I'm afraid this makes the configuration more complicated. >> >> I can imagine it with 3 switches: >> -Accept auth. request without request object >> -Accept auth. request with request object included in request param >> -Accept auth. request with request object referenced with request_uri >> (All of them true by default.) >> >> Or maybe with a dropdown "Accept auth. request": >> -any (default) >> -with request object included in request param or referenced with >> request_uri >> -with request object included in request param >> -with request object referenced with request_uri >> >> Is this too much to add on the UI? >> Do you have a better idea? >> >> Thanks, >> ?ron >> >> >> On 8 March 2018 at 17:23, Marek Posolda wrote: >> >>> On 08/03/18 15:25, Marek Posolda wrote: >>> >>>> Hi, >>>> >>>> sorry to not respond earlier. Your usecase makes sense to me and the >>>> code you did as well. One minor thing, which is missing, is admin console >>>> update. I think you need to add new switch to the client details page. >>>> Please add it to same section like "Advanced config" where are other things >>>> like request object signature algorithm etc. >>>> >>> Forgot to mention, that it will be nice if you send PR once you do it :) >>> >>> Thanks, >>> Marek >>> >>> >>>> Thanks, >>>> Marek >>>> >>>> On 06/03/18 20:13, Aron Bustya wrote: >>>> >>>>> Hello! >>>>> >>>>> Can I get some reaction to this? (The community guidelines say I need >>>>> to >>>>> ask around before sending pull requests.) >>>>> >>>>> Regards, >>>>> ?ron Bustya >>>>> >>>>> On 2 December 2017 at 04:44, Aron Bustya >>>>> wrote: >>>>> >>>>> Hi! >>>>>> >>>>>> I have a use case where the server must accept authorization requests >>>>>> only >>>>>> when they contain a signed request object (should be configurable per >>>>>> client). >>>>>> >>>>>> I have found a way to make the signing of the request object >>>>>> mandatory by >>>>>> specifying a 'request.object.signature.alg' attribute on the client, >>>>>> but >>>>>> this only applies if a request object exists in the first place. >>>>>> >>>>>> I would like to propose a pull request: It defines a new client >>>>>> attribute >>>>>> 'request.object.required'. If this is set to 'true', the client must >>>>>> send a >>>>>> request object when initiating an authorization request. >>>>>> >>>>>> Current code can be checked here: https://github.com/abustya/ >>>>>> keycloak/commit/476912906a3ad0d290220a1f54abee073dba687a >>>>>> >>>>>> What do you think? >>>>>> >>>>>> Regards, >>>>>> ?ron Bustya >>>>>> >>>>>> _______________________________________________ >>>>> keycloak-dev mailing list >>>>> keycloak-dev at lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>>>> >>>> >>>> >>>> >>> >> >> > From bburke at redhat.com Mon Mar 12 09:29:07 2018 From: bburke at redhat.com (Bill Burke) Date: Mon, 12 Mar 2018 09:29:07 -0400 Subject: [keycloak-dev] kcinit console sso tool Message-ID: I'm finally finishing the generic console login tool I've been promising and working on for awhile now. Its an extension of KeycloakInstalled, but it works entirely on the command line and doesn't require a browser. Its all text input and output in your command line console to login. All driven by the server and rendered by the utility. Supports localization just like the browser too. * To enable this a simple challenge-based protocol was implemented. OAuth Code to token flow is required. Authenticator returns 401 with a WWW-Authenticate header with value of X-Text-Form-Challenge callback="{url}" param="username" label="Username: " mask="false" param/label/mask are input parameter definitions that require command line console input and can be repeated for each input parameter you require from the console. Label is what should be outputed to the console. If mask is true, this means it is a password field and should be hidden on input. If the Response contains "text/plain" content, then that should be outputed before command input is asked for. Client should loop and render/ask for input until a 302 response is returned that contains a "code" parameter. Then regular OAuth is used to get the token. * The access and refresh token is stored locally in a password protected file (like ssh does). This file is checked before login is initiated to see if the user is still logged in. * If logged in, and the client has permission, the kcinit tool can also perform token exchange to obtain tokens for other clients. It stores these tokens in password protected files on local disk. * I have extended the OAuth layer on the server to support the OIDC "display" parameter. (It just stores this value in the AuthSession. I'm also in the process to refactor all the built-in Authenticators and Required Actions to support the "display" parameter and use the texts protocol described above if the "display" parameter is "console". * kcinit is implemented via Java and a shell and windows batch scripts. There's also a wrapper template script that can be used to secure existing command line tools. here's example usage with the target app command being `oc`. $ . kcinit Initially you will be prompted for the "local password" that protects token files on local disk. If you do not "source" this script (with a '.' or 'source' command), then you will have to enter in this local password every time you interact with kcinit utility. the kcinit script will prompt for this local password. Once it gets the password value, it will invoke the Java kcinit program: read -sp 'Local password: ' password KC_SESSION_KEY=`java -jar kcinit.jar password $password` The `password` command will generate an AES key from the password that will be used encrypt and decrypt locally stored files. I do it this way so that when the user's shell is exited, they can no longer access stored tokens. Once the user is logged in, they can start using command line utilities that are secured by it. To secure a command line utility the developer must use a wrapper script for each of their command line tools. The wrapper script looks like this - checks to see if KC_SESSION_KEY is set. If not, it will prompt for the local password and generate this key. - It then tries to obtain the token for the app token=`java -jar kcinit.jar token oc` This will perform a token exchange to obtain a token for the `oc` client. If this is not successful, an error message is displayed (i.e. "You are not logged in".) If successful, then the target command line tool is invoked. The tool extracts the "token" environment variable to invoke on its REST services. $path_to_real_command/$0 $@ * There is an install option for kcinit $ kcinit install This will prompt you for auth server url, realm, client, client secret, and the local password to encrypt things. -- Bill Burke Red Hat From sthorger at redhat.com Mon Mar 12 10:16:04 2018 From: sthorger at redhat.com (Stian Thorgersen) Date: Mon, 12 Mar 2018 15:16:04 +0100 Subject: [keycloak-dev] kcinit console sso tool In-Reply-To: References: Message-ID: Very cool. A few questions/comments: * As it's Java based it does make it harder to package/install. Compare 'oc' tool for instance to our 'kcadmin' and 'kcclient' tools. Not sure how realistic it would be to write our CLI tools in for instance Go though. * I assume the console display is optional and it basically means that you can only use authenticators that support this rather than all authenticators require to implement it. * Not sure I fully understand the user experience with the encrypted password file. How does this compare to kinit and ssh-agent for instance? They both allow unlocking automatically through the regular OS login I believe. For 'kcadmin' and 'kcclient' we don't currently protect the tokens so we should probably consider aligning these approaches (probably even getting rid of the auth stuff there in favour of kcinit). * Should we consider merging all our CLIs into one CLI? Just 'kc' instead of 'kcinit', 'kcadmin' and 'kcclient'? If we someone could get this stuff in Go and get native binaries that'd be even easier for users to use. On 12 March 2018 at 14:29, Bill Burke wrote: > I'm finally finishing the generic console login tool I've been > promising and working on for awhile now. Its an extension of > KeycloakInstalled, but it works entirely on the command line and > doesn't require a browser. Its all text input and output in your > command line console to login. All driven by the server and rendered > by the utility. Supports localization just like the browser too. > > * To enable this a simple challenge-based protocol was implemented. > OAuth Code to token flow is required. > > Authenticator returns 401 with a WWW-Authenticate header with value of > > X-Text-Form-Challenge callback="{url}" param="username" > label="Username: " mask="false" > > param/label/mask are input parameter definitions that require command > line console input and can be repeated for each input parameter you > require from the console. Label is what should be outputed to the > console. If mask is true, this means it is a password field and > should be hidden on input. > > If the Response contains "text/plain" content, then that should be > outputed before command input is asked for. Client should loop and > render/ask for input until a 302 response is returned that contains a > "code" parameter. Then regular OAuth is used to get the token. > > * The access and refresh token is stored locally in a password > protected file (like ssh does). This file is checked before login is > initiated to see if the user is still logged in. > > * If logged in, and the client has permission, the kcinit tool can > also perform token exchange to obtain tokens for other clients. It > stores these tokens in password protected files on local disk. > > * I have extended the OAuth layer on the server to support the OIDC > "display" parameter. (It just stores this value in the AuthSession. > I'm also in the process to refactor all the built-in Authenticators > and Required Actions to support the "display" parameter and use the > texts protocol described above if the "display" parameter is > "console". > > * kcinit is implemented via Java and a shell and windows batch > scripts. There's also a wrapper template script that can be used to > secure existing command line tools. here's example usage with the > target app command being `oc`. > > $ . kcinit > > Initially you will be prompted for the "local password" that protects > token files on local disk. If you do not "source" this script (with a > '.' or 'source' command), then you will have to enter in this local > password every time you interact with kcinit utility. > > the kcinit script will prompt for this local password. Once it gets > the password value, it will invoke the Java kcinit program: > > read -sp 'Local password: ' password > KC_SESSION_KEY=`java -jar kcinit.jar password $password` > > The `password` command will generate an AES key from the password that > will be used encrypt and decrypt locally stored files. I do it this > way so that when the user's shell is exited, they can no longer access > stored tokens. > > Once the user is logged in, they can start using command line > utilities that are secured by it. To secure a command line utility > the developer must use a wrapper script for each of their command line > tools. The wrapper script looks like this > > - checks to see if KC_SESSION_KEY is set. If not, it will prompt for > the local password and generate this key. > - It then tries to obtain the token for the app > > token=`java -jar kcinit.jar token oc` > > This will perform a token exchange to obtain a token for the `oc` > client. If this is not successful, an error message is displayed > (i.e. "You are not logged in".) If successful, then the target > command line tool is invoked. The tool extracts the "token" > environment variable to invoke on its REST services. > > $path_to_real_command/$0 $@ > > * There is an install option for kcinit > > $ kcinit install > > This will prompt you for auth server url, realm, client, client > secret, and the local password to encrypt things. > > > > > > > > > > > > -- > Bill Burke > Red Hat > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > From sthorger at redhat.com Mon Mar 12 10:17:33 2018 From: sthorger at redhat.com (Stian Thorgersen) Date: Mon, 12 Mar 2018 15:17:33 +0100 Subject: [keycloak-dev] kubernetes keycloak chart: persistent volume for themes? In-Reply-To: References: Message-ID: I'd say during development you may want to use a persistent volume, but for real use extend the image to add your themes. By the way KC 4.0.0 will support deploying themes as a jar in the deployments directory. On 8 March 2018 at 17:52, Naftali van der Loon wrote: > Hi, I'm using the kubernetes keycloak chart, and I must say, very nice > piece of work! > This helped me so much! > > Only question I have is: what is the best way to deploy the theme in a HA > setup? > I think ideal would be a to use a persistent volume. > Or is there another way to get this working? > > Thanks for your help in advance! > > Grz > Naftali > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > From roregan at redhat.com Mon Mar 12 13:15:36 2018 From: roregan at redhat.com (Rachael O'Regan) Date: Mon, 12 Mar 2018 17:15:36 +0000 Subject: [keycloak-dev] How is JWK being parsed? Message-ID: Hi all, I'm trying to figure out how Keycloak is parsing JWK. Am I correct in thinking the JWSBuilder class is responsible for this? And if so how can I run individual tests to debug this class? Thank you, -- Rachael O'Regan Red Hat Mobile Communications House, Cork Road Waterford City, Ireland X91NY33 roregan at redhat.com IM: roregan From bburke at redhat.com Mon Mar 12 13:59:12 2018 From: bburke at redhat.com (Bill Burke) Date: Mon, 12 Mar 2018 13:59:12 -0400 Subject: [keycloak-dev] kcinit console sso tool In-Reply-To: References: Message-ID: On Mon, Mar 12, 2018 at 10:16 AM, Stian Thorgersen wrote: > Very cool. A few questions/comments: > > * As it's Java based it does make it harder to package/install. Compare 'oc' > tool for instance to our 'kcadmin' and 'kcclient' tools. Not sure how > realistic it would be to write our CLI tools in for instance Go though. > Its a pretty simple tool so it could be ported. The only thing that might be a tiny bit challenging is making sure there's crypto stuff available in another language to encrypt/decrypt token files. Might be a nice little project for me to learn Go. > * I assume the console display is optional and it basically means that you > can only use authenticators that support this rather than all authenticators > require to implement it. > I don't have a switch to launch browser, but, I could as this functionality is already implemented. Not sure if that would be portable to Go or another language though. Java has a facility to automatically launch browser (I think you know that already as you wrote KeycloakInstalled). BTW, what sucks about a browser login is that you have to manually kill the browser window after you complete the login. > * Not sure I fully understand the user experience with the encrypted > password file. How does this compare to kinit and ssh-agent for instance? > They both allow unlocking automatically through the regular OS login I > believe. For 'kcadmin' and 'kcclient' we don't currently protect the tokens > so we should probably consider aligning these approaches (probably even > getting rid of the auth stuff there in favour of kcinit). > I just read up on kinit and ssh-agent. Have you actually used either of these before(I haven't)? I don't think they work as you think they do. For instance, ssh-agent is a bit convoluted and requires IPC communication with a background process using a file-based socket. The background process holds private keys in memory which must be unlocked and loaded with a password when you boot your windows manager or your shell. The socket used must be set as an environment variable before you can invoke ssh in your shell. I think when you invoke ssh, it looks for this environment variable and works with the ssh-agent to establish a connection over the local file socket. For kinit, I think to have a global login for the entire machine, it creates a keytab file which has file permissions readable by any process started by the user. And the keytab contains the tickets. This is no different than what we do now for kcadmin. The current solution I have is only for creating an sso session for the current shell and any processes run within the shell would be able to figure out how to access the encrypted token files. > * Should we consider merging all our CLIs into one CLI? Just 'kc' instead of > 'kcinit', 'kcadmin' and 'kcclient'? If we someone could get this stuff in Go > and get native binaries that'd be even easier for users to use. > kcadmin and kcclient should be merged. kcinit should be a separate small generic reusable utility. > On 12 March 2018 at 14:29, Bill Burke wrote: >> >> I'm finally finishing the generic console login tool I've been >> promising and working on for awhile now. Its an extension of >> KeycloakInstalled, but it works entirely on the command line and >> doesn't require a browser. Its all text input and output in your >> command line console to login. All driven by the server and rendered >> by the utility. Supports localization just like the browser too. >> >> * To enable this a simple challenge-based protocol was implemented. >> OAuth Code to token flow is required. >> >> Authenticator returns 401 with a WWW-Authenticate header with value of >> >> X-Text-Form-Challenge callback="{url}" param="username" >> label="Username: " mask="false" >> >> param/label/mask are input parameter definitions that require command >> line console input and can be repeated for each input parameter you >> require from the console. Label is what should be outputed to the >> console. If mask is true, this means it is a password field and >> should be hidden on input. >> >> If the Response contains "text/plain" content, then that should be >> outputed before command input is asked for. Client should loop and >> render/ask for input until a 302 response is returned that contains a >> "code" parameter. Then regular OAuth is used to get the token. >> >> * The access and refresh token is stored locally in a password >> protected file (like ssh does). This file is checked before login is >> initiated to see if the user is still logged in. >> >> * If logged in, and the client has permission, the kcinit tool can >> also perform token exchange to obtain tokens for other clients. It >> stores these tokens in password protected files on local disk. >> >> * I have extended the OAuth layer on the server to support the OIDC >> "display" parameter. (It just stores this value in the AuthSession. >> I'm also in the process to refactor all the built-in Authenticators >> and Required Actions to support the "display" parameter and use the >> texts protocol described above if the "display" parameter is >> "console". >> >> * kcinit is implemented via Java and a shell and windows batch >> scripts. There's also a wrapper template script that can be used to >> secure existing command line tools. here's example usage with the >> target app command being `oc`. >> >> $ . kcinit >> >> Initially you will be prompted for the "local password" that protects >> token files on local disk. If you do not "source" this script (with a >> '.' or 'source' command), then you will have to enter in this local >> password every time you interact with kcinit utility. >> >> the kcinit script will prompt for this local password. Once it gets >> the password value, it will invoke the Java kcinit program: >> >> read -sp 'Local password: ' password >> KC_SESSION_KEY=`java -jar kcinit.jar password $password` >> >> The `password` command will generate an AES key from the password that >> will be used encrypt and decrypt locally stored files. I do it this >> way so that when the user's shell is exited, they can no longer access >> stored tokens. >> >> Once the user is logged in, they can start using command line >> utilities that are secured by it. To secure a command line utility >> the developer must use a wrapper script for each of their command line >> tools. The wrapper script looks like this >> >> - checks to see if KC_SESSION_KEY is set. If not, it will prompt for >> the local password and generate this key. >> - It then tries to obtain the token for the app >> >> token=`java -jar kcinit.jar token oc` >> >> This will perform a token exchange to obtain a token for the `oc` >> client. If this is not successful, an error message is displayed >> (i.e. "You are not logged in".) If successful, then the target >> command line tool is invoked. The tool extracts the "token" >> environment variable to invoke on its REST services. >> >> $path_to_real_command/$0 $@ >> >> * There is an install option for kcinit >> >> $ kcinit install >> >> This will prompt you for auth server url, realm, client, client >> secret, and the local password to encrypt things. >> >> >> >> >> >> >> >> >> >> >> >> -- >> Bill Burke >> Red Hat >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev > > -- Bill Burke Red Hat From psilva at redhat.com Mon Mar 12 14:36:19 2018 From: psilva at redhat.com (Pedro Igor Silva) Date: Mon, 12 Mar 2018 15:36:19 -0300 Subject: [keycloak-dev] kcinit console sso tool In-Reply-To: References: Message-ID: Bill, I'm curious about why you are not using resource owner password credentials grant type. Wouldn't be simpler instead of using authorization code ? On Mon, Mar 12, 2018 at 2:59 PM, Bill Burke wrote: > On Mon, Mar 12, 2018 at 10:16 AM, Stian Thorgersen > wrote: > > Very cool. A few questions/comments: > > > > * As it's Java based it does make it harder to package/install. Compare > 'oc' > > tool for instance to our 'kcadmin' and 'kcclient' tools. Not sure how > > realistic it would be to write our CLI tools in for instance Go though. > > > > Its a pretty simple tool so it could be ported. The only thing that > might be a tiny bit challenging is making sure there's crypto stuff > available in another language to encrypt/decrypt token files. Might > be a nice little project for me to learn Go. > > > * I assume the console display is optional and it basically means that > you > > can only use authenticators that support this rather than all > authenticators > > require to implement it. > > > > I don't have a switch to launch browser, but, I could as this > functionality is already implemented. Not sure if that would be > portable to Go or another language though. Java has a facility to > automatically launch browser (I think you know that already as you > wrote KeycloakInstalled). > > BTW, what sucks about a browser login is that you have to manually > kill the browser window after you complete the login. > > > * Not sure I fully understand the user experience with the encrypted > > password file. How does this compare to kinit and ssh-agent for instance? > > They both allow unlocking automatically through the regular OS login I > > believe. For 'kcadmin' and 'kcclient' we don't currently protect the > tokens > > so we should probably consider aligning these approaches (probably even > > getting rid of the auth stuff there in favour of kcinit). > > > > I just read up on kinit and ssh-agent. Have you actually used either > of these before(I haven't)? I don't think they work as you think they > do. > > For instance, ssh-agent is a bit convoluted and requires IPC > communication with a background process using a file-based socket. > The background process holds private keys in memory which must be > unlocked and loaded with a password when you boot your windows manager > or your shell. The socket used must be set as an environment variable > before you can invoke ssh in your shell. I think when you invoke ssh, > it looks for this environment variable and works with the ssh-agent to > establish a connection over the local file socket. > > For kinit, I think to have a global login for the entire machine, it > creates a keytab file which has file permissions readable by any > process started by the user. And the keytab contains the tickets. > This is no different than what we do now for kcadmin. > > The current solution I have is only for creating an sso session for > the current shell and any processes run within the shell would be able > to figure out how to access the encrypted token files. > > > > * Should we consider merging all our CLIs into one CLI? Just 'kc' > instead of > > 'kcinit', 'kcadmin' and 'kcclient'? If we someone could get this stuff > in Go > > and get native binaries that'd be even easier for users to use. > > > > kcadmin and kcclient should be merged. kcinit should be a separate > small generic reusable utility. > > > > On 12 March 2018 at 14:29, Bill Burke wrote: > >> > >> I'm finally finishing the generic console login tool I've been > >> promising and working on for awhile now. Its an extension of > >> KeycloakInstalled, but it works entirely on the command line and > >> doesn't require a browser. Its all text input and output in your > >> command line console to login. All driven by the server and rendered > >> by the utility. Supports localization just like the browser too. > >> > >> * To enable this a simple challenge-based protocol was implemented. > >> OAuth Code to token flow is required. > >> > >> Authenticator returns 401 with a WWW-Authenticate header with value of > >> > >> X-Text-Form-Challenge callback="{url}" param="username" > >> label="Username: " mask="false" > >> > >> param/label/mask are input parameter definitions that require command > >> line console input and can be repeated for each input parameter you > >> require from the console. Label is what should be outputed to the > >> console. If mask is true, this means it is a password field and > >> should be hidden on input. > >> > >> If the Response contains "text/plain" content, then that should be > >> outputed before command input is asked for. Client should loop and > >> render/ask for input until a 302 response is returned that contains a > >> "code" parameter. Then regular OAuth is used to get the token. > >> > >> * The access and refresh token is stored locally in a password > >> protected file (like ssh does). This file is checked before login is > >> initiated to see if the user is still logged in. > >> > >> * If logged in, and the client has permission, the kcinit tool can > >> also perform token exchange to obtain tokens for other clients. It > >> stores these tokens in password protected files on local disk. > >> > >> * I have extended the OAuth layer on the server to support the OIDC > >> "display" parameter. (It just stores this value in the AuthSession. > >> I'm also in the process to refactor all the built-in Authenticators > >> and Required Actions to support the "display" parameter and use the > >> texts protocol described above if the "display" parameter is > >> "console". > >> > >> * kcinit is implemented via Java and a shell and windows batch > >> scripts. There's also a wrapper template script that can be used to > >> secure existing command line tools. here's example usage with the > >> target app command being `oc`. > >> > >> $ . kcinit > >> > >> Initially you will be prompted for the "local password" that protects > >> token files on local disk. If you do not "source" this script (with a > >> '.' or 'source' command), then you will have to enter in this local > >> password every time you interact with kcinit utility. > >> > >> the kcinit script will prompt for this local password. Once it gets > >> the password value, it will invoke the Java kcinit program: > >> > >> read -sp 'Local password: ' password > >> KC_SESSION_KEY=`java -jar kcinit.jar password $password` > >> > >> The `password` command will generate an AES key from the password that > >> will be used encrypt and decrypt locally stored files. I do it this > >> way so that when the user's shell is exited, they can no longer access > >> stored tokens. > >> > >> Once the user is logged in, they can start using command line > >> utilities that are secured by it. To secure a command line utility > >> the developer must use a wrapper script for each of their command line > >> tools. The wrapper script looks like this > >> > >> - checks to see if KC_SESSION_KEY is set. If not, it will prompt for > >> the local password and generate this key. > >> - It then tries to obtain the token for the app > >> > >> token=`java -jar kcinit.jar token oc` > >> > >> This will perform a token exchange to obtain a token for the `oc` > >> client. If this is not successful, an error message is displayed > >> (i.e. "You are not logged in".) If successful, then the target > >> command line tool is invoked. The tool extracts the "token" > >> environment variable to invoke on its REST services. > >> > >> $path_to_real_command/$0 $@ > >> > >> * There is an install option for kcinit > >> > >> $ kcinit install > >> > >> This will prompt you for auth server url, realm, client, client > >> secret, and the local password to encrypt things. > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> -- > >> Bill Burke > >> Red Hat > >> _______________________________________________ > >> keycloak-dev mailing list > >> keycloak-dev at lists.jboss.org > >> https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > > > > > > -- > Bill Burke > Red Hat > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > From bburke at redhat.com Mon Mar 12 15:15:57 2018 From: bburke at redhat.com (Bill Burke) Date: Mon, 12 Mar 2018 15:15:57 -0400 Subject: [keycloak-dev] kcinit console sso tool In-Reply-To: References: Message-ID: The "resource owner password credentials" grant type isn't really implemented as a multi-request flow and would have taken a bit of refactoring work. On Mon, Mar 12, 2018 at 2:36 PM, Pedro Igor Silva wrote: > Bill, I'm curious about why you are not using resource owner password > credentials grant type. Wouldn't be simpler instead of using authorization > code ? > > On Mon, Mar 12, 2018 at 2:59 PM, Bill Burke wrote: >> >> On Mon, Mar 12, 2018 at 10:16 AM, Stian Thorgersen >> wrote: >> > Very cool. A few questions/comments: >> > >> > * As it's Java based it does make it harder to package/install. Compare >> > 'oc' >> > tool for instance to our 'kcadmin' and 'kcclient' tools. Not sure how >> > realistic it would be to write our CLI tools in for instance Go though. >> > >> >> Its a pretty simple tool so it could be ported. The only thing that >> might be a tiny bit challenging is making sure there's crypto stuff >> available in another language to encrypt/decrypt token files. Might >> be a nice little project for me to learn Go. >> >> > * I assume the console display is optional and it basically means that >> > you >> > can only use authenticators that support this rather than all >> > authenticators >> > require to implement it. >> > >> >> I don't have a switch to launch browser, but, I could as this >> functionality is already implemented. Not sure if that would be >> portable to Go or another language though. Java has a facility to >> automatically launch browser (I think you know that already as you >> wrote KeycloakInstalled). >> >> BTW, what sucks about a browser login is that you have to manually >> kill the browser window after you complete the login. >> >> > * Not sure I fully understand the user experience with the encrypted >> > password file. How does this compare to kinit and ssh-agent for >> > instance? >> > They both allow unlocking automatically through the regular OS login I >> > believe. For 'kcadmin' and 'kcclient' we don't currently protect the >> > tokens >> > so we should probably consider aligning these approaches (probably even >> > getting rid of the auth stuff there in favour of kcinit). >> > >> >> I just read up on kinit and ssh-agent. Have you actually used either >> of these before(I haven't)? I don't think they work as you think they >> do. >> >> For instance, ssh-agent is a bit convoluted and requires IPC >> communication with a background process using a file-based socket. >> The background process holds private keys in memory which must be >> unlocked and loaded with a password when you boot your windows manager >> or your shell. The socket used must be set as an environment variable >> before you can invoke ssh in your shell. I think when you invoke ssh, >> it looks for this environment variable and works with the ssh-agent to >> establish a connection over the local file socket. >> >> For kinit, I think to have a global login for the entire machine, it >> creates a keytab file which has file permissions readable by any >> process started by the user. And the keytab contains the tickets. >> This is no different than what we do now for kcadmin. >> >> The current solution I have is only for creating an sso session for >> the current shell and any processes run within the shell would be able >> to figure out how to access the encrypted token files. >> >> >> > * Should we consider merging all our CLIs into one CLI? Just 'kc' >> > instead of >> > 'kcinit', 'kcadmin' and 'kcclient'? If we someone could get this stuff >> > in Go >> > and get native binaries that'd be even easier for users to use. >> > >> >> kcadmin and kcclient should be merged. kcinit should be a separate >> small generic reusable utility. >> >> >> > On 12 March 2018 at 14:29, Bill Burke wrote: >> >> >> >> I'm finally finishing the generic console login tool I've been >> >> promising and working on for awhile now. Its an extension of >> >> KeycloakInstalled, but it works entirely on the command line and >> >> doesn't require a browser. Its all text input and output in your >> >> command line console to login. All driven by the server and rendered >> >> by the utility. Supports localization just like the browser too. >> >> >> >> * To enable this a simple challenge-based protocol was implemented. >> >> OAuth Code to token flow is required. >> >> >> >> Authenticator returns 401 with a WWW-Authenticate header with value of >> >> >> >> X-Text-Form-Challenge callback="{url}" param="username" >> >> label="Username: " mask="false" >> >> >> >> param/label/mask are input parameter definitions that require command >> >> line console input and can be repeated for each input parameter you >> >> require from the console. Label is what should be outputed to the >> >> console. If mask is true, this means it is a password field and >> >> should be hidden on input. >> >> >> >> If the Response contains "text/plain" content, then that should be >> >> outputed before command input is asked for. Client should loop and >> >> render/ask for input until a 302 response is returned that contains a >> >> "code" parameter. Then regular OAuth is used to get the token. >> >> >> >> * The access and refresh token is stored locally in a password >> >> protected file (like ssh does). This file is checked before login is >> >> initiated to see if the user is still logged in. >> >> >> >> * If logged in, and the client has permission, the kcinit tool can >> >> also perform token exchange to obtain tokens for other clients. It >> >> stores these tokens in password protected files on local disk. >> >> >> >> * I have extended the OAuth layer on the server to support the OIDC >> >> "display" parameter. (It just stores this value in the AuthSession. >> >> I'm also in the process to refactor all the built-in Authenticators >> >> and Required Actions to support the "display" parameter and use the >> >> texts protocol described above if the "display" parameter is >> >> "console". >> >> >> >> * kcinit is implemented via Java and a shell and windows batch >> >> scripts. There's also a wrapper template script that can be used to >> >> secure existing command line tools. here's example usage with the >> >> target app command being `oc`. >> >> >> >> $ . kcinit >> >> >> >> Initially you will be prompted for the "local password" that protects >> >> token files on local disk. If you do not "source" this script (with a >> >> '.' or 'source' command), then you will have to enter in this local >> >> password every time you interact with kcinit utility. >> >> >> >> the kcinit script will prompt for this local password. Once it gets >> >> the password value, it will invoke the Java kcinit program: >> >> >> >> read -sp 'Local password: ' password >> >> KC_SESSION_KEY=`java -jar kcinit.jar password $password` >> >> >> >> The `password` command will generate an AES key from the password that >> >> will be used encrypt and decrypt locally stored files. I do it this >> >> way so that when the user's shell is exited, they can no longer access >> >> stored tokens. >> >> >> >> Once the user is logged in, they can start using command line >> >> utilities that are secured by it. To secure a command line utility >> >> the developer must use a wrapper script for each of their command line >> >> tools. The wrapper script looks like this >> >> >> >> - checks to see if KC_SESSION_KEY is set. If not, it will prompt for >> >> the local password and generate this key. >> >> - It then tries to obtain the token for the app >> >> >> >> token=`java -jar kcinit.jar token oc` >> >> >> >> This will perform a token exchange to obtain a token for the `oc` >> >> client. If this is not successful, an error message is displayed >> >> (i.e. "You are not logged in".) If successful, then the target >> >> command line tool is invoked. The tool extracts the "token" >> >> environment variable to invoke on its REST services. >> >> >> >> $path_to_real_command/$0 $@ >> >> >> >> * There is an install option for kcinit >> >> >> >> $ kcinit install >> >> >> >> This will prompt you for auth server url, realm, client, client >> >> secret, and the local password to encrypt things. >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> -- >> >> Bill Burke >> >> Red Hat >> >> _______________________________________________ >> >> keycloak-dev mailing list >> >> keycloak-dev at lists.jboss.org >> >> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> > >> > >> >> >> >> -- >> Bill Burke >> Red Hat >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev > > -- Bill Burke Red Hat From psilva at redhat.com Mon Mar 12 15:36:02 2018 From: psilva at redhat.com (Pedro Igor Silva) Date: Mon, 12 Mar 2018 16:36:02 -0300 Subject: [keycloak-dev] kcinit console sso tool In-Reply-To: References: Message-ID: Another thing you might consider is talk with Peter about how you can use Elytron to secure tokens using a credential store. Elytron is a very tinny library and there is an API for managing/storing credentials in a secure manner. If you are not going to move everything to Go .... On Mon, Mar 12, 2018 at 4:15 PM, Bill Burke wrote: > The "resource owner password credentials" grant type isn't really > implemented as a multi-request flow and would have taken a bit of > refactoring work. > > On Mon, Mar 12, 2018 at 2:36 PM, Pedro Igor Silva > wrote: > > Bill, I'm curious about why you are not using resource owner password > > credentials grant type. Wouldn't be simpler instead of using > authorization > > code ? > > > > On Mon, Mar 12, 2018 at 2:59 PM, Bill Burke wrote: > >> > >> On Mon, Mar 12, 2018 at 10:16 AM, Stian Thorgersen > > >> wrote: > >> > Very cool. A few questions/comments: > >> > > >> > * As it's Java based it does make it harder to package/install. > Compare > >> > 'oc' > >> > tool for instance to our 'kcadmin' and 'kcclient' tools. Not sure how > >> > realistic it would be to write our CLI tools in for instance Go > though. > >> > > >> > >> Its a pretty simple tool so it could be ported. The only thing that > >> might be a tiny bit challenging is making sure there's crypto stuff > >> available in another language to encrypt/decrypt token files. Might > >> be a nice little project for me to learn Go. > >> > >> > * I assume the console display is optional and it basically means that > >> > you > >> > can only use authenticators that support this rather than all > >> > authenticators > >> > require to implement it. > >> > > >> > >> I don't have a switch to launch browser, but, I could as this > >> functionality is already implemented. Not sure if that would be > >> portable to Go or another language though. Java has a facility to > >> automatically launch browser (I think you know that already as you > >> wrote KeycloakInstalled). > >> > >> BTW, what sucks about a browser login is that you have to manually > >> kill the browser window after you complete the login. > >> > >> > * Not sure I fully understand the user experience with the encrypted > >> > password file. How does this compare to kinit and ssh-agent for > >> > instance? > >> > They both allow unlocking automatically through the regular OS login I > >> > believe. For 'kcadmin' and 'kcclient' we don't currently protect the > >> > tokens > >> > so we should probably consider aligning these approaches (probably > even > >> > getting rid of the auth stuff there in favour of kcinit). > >> > > >> > >> I just read up on kinit and ssh-agent. Have you actually used either > >> of these before(I haven't)? I don't think they work as you think they > >> do. > >> > >> For instance, ssh-agent is a bit convoluted and requires IPC > >> communication with a background process using a file-based socket. > >> The background process holds private keys in memory which must be > >> unlocked and loaded with a password when you boot your windows manager > >> or your shell. The socket used must be set as an environment variable > >> before you can invoke ssh in your shell. I think when you invoke ssh, > >> it looks for this environment variable and works with the ssh-agent to > >> establish a connection over the local file socket. > >> > >> For kinit, I think to have a global login for the entire machine, it > >> creates a keytab file which has file permissions readable by any > >> process started by the user. And the keytab contains the tickets. > >> This is no different than what we do now for kcadmin. > >> > >> The current solution I have is only for creating an sso session for > >> the current shell and any processes run within the shell would be able > >> to figure out how to access the encrypted token files. > >> > >> > >> > * Should we consider merging all our CLIs into one CLI? Just 'kc' > >> > instead of > >> > 'kcinit', 'kcadmin' and 'kcclient'? If we someone could get this stuff > >> > in Go > >> > and get native binaries that'd be even easier for users to use. > >> > > >> > >> kcadmin and kcclient should be merged. kcinit should be a separate > >> small generic reusable utility. > >> > >> > >> > On 12 March 2018 at 14:29, Bill Burke wrote: > >> >> > >> >> I'm finally finishing the generic console login tool I've been > >> >> promising and working on for awhile now. Its an extension of > >> >> KeycloakInstalled, but it works entirely on the command line and > >> >> doesn't require a browser. Its all text input and output in your > >> >> command line console to login. All driven by the server and rendered > >> >> by the utility. Supports localization just like the browser too. > >> >> > >> >> * To enable this a simple challenge-based protocol was implemented. > >> >> OAuth Code to token flow is required. > >> >> > >> >> Authenticator returns 401 with a WWW-Authenticate header with value > of > >> >> > >> >> X-Text-Form-Challenge callback="{url}" param="username" > >> >> label="Username: " mask="false" > >> >> > >> >> param/label/mask are input parameter definitions that require command > >> >> line console input and can be repeated for each input parameter you > >> >> require from the console. Label is what should be outputed to the > >> >> console. If mask is true, this means it is a password field and > >> >> should be hidden on input. > >> >> > >> >> If the Response contains "text/plain" content, then that should be > >> >> outputed before command input is asked for. Client should loop and > >> >> render/ask for input until a 302 response is returned that contains a > >> >> "code" parameter. Then regular OAuth is used to get the token. > >> >> > >> >> * The access and refresh token is stored locally in a password > >> >> protected file (like ssh does). This file is checked before login is > >> >> initiated to see if the user is still logged in. > >> >> > >> >> * If logged in, and the client has permission, the kcinit tool can > >> >> also perform token exchange to obtain tokens for other clients. It > >> >> stores these tokens in password protected files on local disk. > >> >> > >> >> * I have extended the OAuth layer on the server to support the OIDC > >> >> "display" parameter. (It just stores this value in the AuthSession. > >> >> I'm also in the process to refactor all the built-in Authenticators > >> >> and Required Actions to support the "display" parameter and use the > >> >> texts protocol described above if the "display" parameter is > >> >> "console". > >> >> > >> >> * kcinit is implemented via Java and a shell and windows batch > >> >> scripts. There's also a wrapper template script that can be used to > >> >> secure existing command line tools. here's example usage with the > >> >> target app command being `oc`. > >> >> > >> >> $ . kcinit > >> >> > >> >> Initially you will be prompted for the "local password" that protects > >> >> token files on local disk. If you do not "source" this script (with > a > >> >> '.' or 'source' command), then you will have to enter in this local > >> >> password every time you interact with kcinit utility. > >> >> > >> >> the kcinit script will prompt for this local password. Once it gets > >> >> the password value, it will invoke the Java kcinit program: > >> >> > >> >> read -sp 'Local password: ' password > >> >> KC_SESSION_KEY=`java -jar kcinit.jar password $password` > >> >> > >> >> The `password` command will generate an AES key from the password > that > >> >> will be used encrypt and decrypt locally stored files. I do it this > >> >> way so that when the user's shell is exited, they can no longer > access > >> >> stored tokens. > >> >> > >> >> Once the user is logged in, they can start using command line > >> >> utilities that are secured by it. To secure a command line utility > >> >> the developer must use a wrapper script for each of their command > line > >> >> tools. The wrapper script looks like this > >> >> > >> >> - checks to see if KC_SESSION_KEY is set. If not, it will prompt for > >> >> the local password and generate this key. > >> >> - It then tries to obtain the token for the app > >> >> > >> >> token=`java -jar kcinit.jar token oc` > >> >> > >> >> This will perform a token exchange to obtain a token for the `oc` > >> >> client. If this is not successful, an error message is displayed > >> >> (i.e. "You are not logged in".) If successful, then the target > >> >> command line tool is invoked. The tool extracts the "token" > >> >> environment variable to invoke on its REST services. > >> >> > >> >> $path_to_real_command/$0 $@ > >> >> > >> >> * There is an install option for kcinit > >> >> > >> >> $ kcinit install > >> >> > >> >> This will prompt you for auth server url, realm, client, client > >> >> secret, and the local password to encrypt things. > >> >> > >> >> > >> >> > >> >> > >> >> > >> >> > >> >> > >> >> > >> >> > >> >> > >> >> > >> >> -- > >> >> Bill Burke > >> >> Red Hat > >> >> _______________________________________________ > >> >> keycloak-dev mailing list > >> >> keycloak-dev at lists.jboss.org > >> >> https://lists.jboss.org/mailman/listinfo/keycloak-dev > >> > > >> > > >> > >> > >> > >> -- > >> Bill Burke > >> Red Hat > >> _______________________________________________ > >> keycloak-dev mailing list > >> keycloak-dev at lists.jboss.org > >> https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > > > > > > -- > Bill Burke > Red Hat > From nirmal_131 at yahoo.com Tue Mar 13 00:31:33 2018 From: nirmal_131 at yahoo.com (nirmal a) Date: Tue, 13 Mar 2018 04:31:33 +0000 (UTC) Subject: [keycloak-dev] Keycloak authentication References: <1880764885.166157.1520915493975.ref@mail.yahoo.com> Message-ID: <1880764885.166157.1520915493975@mail.yahoo.com> I am very much new to Keycloak. I have a question regarding Keycloak and obtaining an Access Token. My usecase is as below.I have two separate applications set up as 2 different clients in keycloak. Both are using the same LDAP (Active directory) server for authentication which is set up in keycloak as user federation. A user is logged into applicationA using the keycloak login page. Now the user wants to launch applicationB on click of a button on its webpage. On click of the button, applicationA should be able to retrieve an access token from keycloak passing only the username (Not password) and use it to launch applicationB.It should not be asked to login into keycloak again. Once it receives the token it should be able to launch applicationB using the token. ApplicationB should check the validity of the token passed and retrieves the user details from the keycloak server. Is there a way to achieve this? From mposolda at redhat.com Tue Mar 13 11:53:54 2018 From: mposolda at redhat.com (Marek Posolda) Date: Tue, 13 Mar 2018 16:53:54 +0100 Subject: [keycloak-dev] make sending a request object mandatory for certain clients In-Reply-To: References: <0cea416f-6bdb-9eeb-8770-0d9133a05f14@redhat.com> <91dc9ea6-9112-ffa6-9bb9-512f4feef5a9@redhat.com> <02916eba-3638-fb71-0d05-2247f6d8daeb@redhat.com> Message-ID: <18d0de60-4b2c-d2c4-7411-bdacbb9efbbd@redhat.com> I would rather do with single switch instead of introduce 2 as you mentioned earlier. How about the switch "Request object required" with values: - Not required (default) - request_uri or request - request only - request_uri only And add some more details into the corresponding tooltip. Will it work for you? Marek On 12/03/18 08:53, Aron Bustya wrote: > Hi, it turns out we do need to comply with this. > > Another way of putting it on the UI would be to add a switch "Request > object required" (false by default). > And if is set to true, display a dropdown "Request object delivery > method" with options of "any" (default), "by value", "by reference". > > Is it ok if I do this? > > Thanks, > ?ron > > On 9 March 2018 at 13:16, Aron Bustya > wrote: > > I am not entirely sure, to be honest. I also think the signature > should be enogh for security. > > We are implementing this specification: > https://openbanking.atlassian.net/wiki/spaces/DZ/pages/7046134/Open+Banking+Security+Profile+-+Implementer+s+Draft+v1.1.0 > > The only reasoning for the decision is: > "OpenBanking, in conjuction with major IAM vendors, is ruling out > the use of JWT Request objects by reference due a number of > delivery risks and remaining security concerns." > Not very specific. > > I'll check with our architect if we really need to comply with > this, or requiring any kind of request object will be enough. > > Thanks, > ?ron > > On 9 March 2018 at 11:01, Marek Posolda > wrote: > > Ah, really? > > I am curious why you have this requirement? Is it due the > security? I wonder that if request is signed with the private > key of the client, then it's not any difference regarding > security if it's "request" or "request_uri" . It can't happen > that someone will be able to construct request object and > "put" it on specific URI due the fact that he won't be able to > sign it (unless he steal the client RSA key, but that would be > broken security anyway and he will be able to construct > "request" object the exactly same way). > > Thanks, > Marek > > > On 09/03/18 10:32, Aron Bustya wrote: >> Hi Marek, >> >> Thans for the reply. >> In the meantime I found out that we must only accept a >> request object entered directly, and not a request_uri (my >> first implementation handles the two together). >> >> But I'm afraid this makes the configuration more complicated. >> >> I can imagine it with 3 switches: >> -Accept auth. request without request object >> -Accept auth. request with request object included in request >> param >> -Accept auth. request with request object?referenced with >> request_uri >> (All of them true by default.) >> >> Or maybe with a dropdown "Accept auth. request": >> -any (default) >> -with request object included in request paramor referenced >> withrequest_uri >> -with request object included in request param >> -withrequest object?referenced withrequest_uri >> >> Is this too much to add on the UI? >> Do you have a better idea? >> >> Thanks, >> ?ron >> >> >> On 8 March 2018 at 17:23, Marek Posolda > > wrote: >> >> On 08/03/18 15:25, Marek Posolda wrote: >> >> Hi, >> >> sorry to not respond earlier. Your usecase makes >> sense to me and the code you did as well. One minor >> thing, which is missing, is admin console update. I >> think you need to add new switch to the client >> details page. Please add it to same section like >> "Advanced config" where are other things like request >> object signature algorithm etc. >> >> Forgot to mention, that it will be nice if you send PR >> once you do it :) >> >> Thanks, >> Marek >> >> >> Thanks, >> Marek >> >> On 06/03/18 20:13, Aron Bustya wrote: >> >> Hello! >> >> Can I get some reaction to this? (The community >> guidelines say I need to >> ask around before sending pull requests.) >> >> Regards, >> ?ron Bustya >> >> On 2 December 2017 at 04:44, Aron Bustya >> > > wrote: >> >> Hi! >> >> I have a use case where the server must >> accept authorization requests only >> when they contain a signed request object >> (should be configurable per >> client). >> >> I have found a way to make the signing of the >> request object mandatory by >> specifying a 'request.object.signature.alg' >> attribute on the client, but >> this only applies if a request object exists >> in the first place. >> >> I would like to propose a pull request: It >> defines a new client attribute >> 'request.object.required'. If this is set to >> 'true', the client must send a >> request object when initiating an >> authorization request. >> >> Current code can be checked here: >> https://github.com/abustya/ >> keycloak/commit/476912906a3ad0d290220a1f54abee073dba687a >> >> What do you think? >> >> Regards, >> ?ron Bustya >> >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev at lists.jboss.org >> >> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> >> >> >> >> >> > > > From aron.bustya.js at gmail.com Tue Mar 13 14:28:26 2018 From: aron.bustya.js at gmail.com (Aron Bustya) Date: Tue, 13 Mar 2018 19:28:26 +0100 Subject: [keycloak-dev] make sending a request object mandatory for certain clients In-Reply-To: <18d0de60-4b2c-d2c4-7411-bdacbb9efbbd@redhat.com> References: <0cea416f-6bdb-9eeb-8770-0d9133a05f14@redhat.com> <91dc9ea6-9112-ffa6-9bb9-512f4feef5a9@redhat.com> <02916eba-3638-fb71-0d05-2247f6d8daeb@redhat.com> <18d0de60-4b2c-d2c4-7411-bdacbb9efbbd@redhat.com> Message-ID: Yet, it's ok. (If by switch you meant a dropdown list.) On 13 March 2018 at 16:53, Marek Posolda wrote: > I would rather do with single switch instead of introduce 2 as you > mentioned earlier. How about the switch "Request object required" with > values: > - Not required (default) > - request_uri or request > - request only > - request_uri only > > And add some more details into the corresponding tooltip. Will it work for > you? > > Marek > > > On 12/03/18 08:53, Aron Bustya wrote: > > Hi, it turns out we do need to comply with this. > > Another way of putting it on the UI would be to add a switch "Request > object required" (false by default). > And if is set to true, display a dropdown "Request object delivery method" > with options of "any" (default), "by value", "by reference". > > Is it ok if I do this? > > Thanks, > ?ron > > On 9 March 2018 at 13:16, Aron Bustya wrote: > >> I am not entirely sure, to be honest. I also think the signature should >> be enogh for security. >> >> We are implementing this specification: https://openbanking.atlassian. >> net/wiki/spaces/DZ/pages/7046134/Open+Banking+Security+Profi >> le+-+Implementer+s+Draft+v1.1.0 >> The only reasoning for the decision is: >> "OpenBanking, in conjuction with major IAM vendors, is ruling out the use >> of JWT Request objects by reference due a number of delivery risks and >> remaining security concerns." >> Not very specific. >> >> I'll check with our architect if we really need to comply with this, or >> requiring any kind of request object will be enough. >> >> Thanks, >> ?ron >> >> On 9 March 2018 at 11:01, Marek Posolda wrote: >> >>> Ah, really? >>> >>> I am curious why you have this requirement? Is it due the security? I >>> wonder that if request is signed with the private key of the client, then >>> it's not any difference regarding security if it's "request" or >>> "request_uri" . It can't happen that someone will be able to construct >>> request object and "put" it on specific URI due the fact that he won't be >>> able to sign it (unless he steal the client RSA key, but that would be >>> broken security anyway and he will be able to construct "request" object >>> the exactly same way). >>> >>> Thanks, >>> Marek >>> >>> >>> On 09/03/18 10:32, Aron Bustya wrote: >>> >>> Hi Marek, >>> >>> Thans for the reply. >>> In the meantime I found out that we must only accept a request object >>> entered directly, and not a request_uri (my first implementation handles >>> the two together). >>> >>> But I'm afraid this makes the configuration more complicated. >>> >>> I can imagine it with 3 switches: >>> -Accept auth. request without request object >>> -Accept auth. request with request object included in request param >>> -Accept auth. request with request object referenced with request_uri >>> (All of them true by default.) >>> >>> Or maybe with a dropdown "Accept auth. request": >>> -any (default) >>> -with request object included in request param or referenced with >>> request_uri >>> -with request object included in request param >>> -with request object referenced with request_uri >>> >>> Is this too much to add on the UI? >>> Do you have a better idea? >>> >>> Thanks, >>> ?ron >>> >>> >>> On 8 March 2018 at 17:23, Marek Posolda wrote: >>> >>>> On 08/03/18 15:25, Marek Posolda wrote: >>>> >>>>> Hi, >>>>> >>>>> sorry to not respond earlier. Your usecase makes sense to me and the >>>>> code you did as well. One minor thing, which is missing, is admin console >>>>> update. I think you need to add new switch to the client details page. >>>>> Please add it to same section like "Advanced config" where are other things >>>>> like request object signature algorithm etc. >>>>> >>>> Forgot to mention, that it will be nice if you send PR once you do it :) >>>> >>>> Thanks, >>>> Marek >>>> >>>> >>>>> Thanks, >>>>> Marek >>>>> >>>>> On 06/03/18 20:13, Aron Bustya wrote: >>>>> >>>>>> Hello! >>>>>> >>>>>> Can I get some reaction to this? (The community guidelines say I need >>>>>> to >>>>>> ask around before sending pull requests.) >>>>>> >>>>>> Regards, >>>>>> ?ron Bustya >>>>>> >>>>>> On 2 December 2017 at 04:44, Aron Bustya >>>>>> wrote: >>>>>> >>>>>> Hi! >>>>>>> >>>>>>> I have a use case where the server must accept authorization >>>>>>> requests only >>>>>>> when they contain a signed request object (should be configurable per >>>>>>> client). >>>>>>> >>>>>>> I have found a way to make the signing of the request object >>>>>>> mandatory by >>>>>>> specifying a 'request.object.signature.alg' attribute on the client, >>>>>>> but >>>>>>> this only applies if a request object exists in the first place. >>>>>>> >>>>>>> I would like to propose a pull request: It defines a new client >>>>>>> attribute >>>>>>> 'request.object.required'. If this is set to 'true', the client must >>>>>>> send a >>>>>>> request object when initiating an authorization request. >>>>>>> >>>>>>> Current code can be checked here: https://github.com/abustya/ >>>>>>> keycloak/commit/476912906a3ad0d290220a1f54abee073dba687a >>>>>>> >>>>>>> What do you think? >>>>>>> >>>>>>> Regards, >>>>>>> ?ron Bustya >>>>>>> >>>>>>> _______________________________________________ >>>>>> keycloak-dev mailing list >>>>>> keycloak-dev at lists.jboss.org >>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>>>>> >>>>> >>>>> >>>>> >>>> >>> >>> >> > > From mposolda at redhat.com Tue Mar 13 14:44:17 2018 From: mposolda at redhat.com (Marek Posolda) Date: Tue, 13 Mar 2018 19:44:17 +0100 Subject: [keycloak-dev] make sending a request object mandatory for certain clients In-Reply-To: References: <0cea416f-6bdb-9eeb-8770-0d9133a05f14@redhat.com> <91dc9ea6-9112-ffa6-9bb9-512f4feef5a9@redhat.com> <02916eba-3638-fb71-0d05-2247f6d8daeb@redhat.com> <18d0de60-4b2c-d2c4-7411-bdacbb9efbbd@redhat.com> Message-ID: <0b65fca8-0dbe-0b6f-6436-09e577aebbd3@redhat.com> On 13/03/18 19:28, Aron Bustya wrote: > Yet, it's ok. (If by switch you meant a dropdown list.) Ah yes :) Sorry to be unclear. Marek > > On 13 March 2018 at 16:53, Marek Posolda > wrote: > > I would rather do with single switch instead of introduce 2 as you > mentioned earlier. How about the switch "Request object required" > with values: > - Not required (default) > - request_uri or request > - request only > - request_uri only > > And add some more details into the corresponding tooltip. Will it > work for you? > > Marek > > > On 12/03/18 08:53, Aron Bustya wrote: >> Hi, it turns out we do need to comply with this. >> >> Another way of putting it on the UI would be to add a switch >> "Request object required" (false by default). >> And if is set to true, display a dropdown "Request object >> delivery method" with options of "any" (default), "by value", "by >> reference". >> >> Is it ok if I do this? >> >> Thanks, >> ?ron >> >> On 9 March 2018 at 13:16, Aron Bustya > > wrote: >> >> I am not entirely sure, to be honest. I also think the >> signature should be enogh for security. >> >> We are implementing this specification: >> https://openbanking.atlassian.net/wiki/spaces/DZ/pages/7046134/Open+Banking+Security+Profile+-+Implementer+s+Draft+v1.1.0 >> >> The only reasoning for the decision is: >> "OpenBanking, in conjuction with major IAM vendors, is ruling >> out the use of JWT Request objects by reference due a number >> of delivery risks and remaining security concerns." >> Not very specific. >> >> I'll check with our architect if we really need to comply >> with this, or requiring any kind of request object will be >> enough. >> >> Thanks, >> ?ron >> >> On 9 March 2018 at 11:01, Marek Posolda > > wrote: >> >> Ah, really? >> >> I am curious why you have this requirement? Is it due the >> security? I wonder that if request is signed with the >> private key of the client, then it's not any difference >> regarding security if it's "request" or "request_uri" . >> It can't happen that someone will be able to construct >> request object and "put" it on specific URI due the fact >> that he won't be able to sign it (unless he steal the >> client RSA key, but that would be broken security anyway >> and he will be able to construct "request" object the >> exactly same way). >> >> Thanks, >> Marek >> >> >> On 09/03/18 10:32, Aron Bustya wrote: >>> Hi Marek, >>> >>> Thans for the reply. >>> In the meantime I found out that we must only accept a >>> request object entered directly, and not a request_uri >>> (my first implementation handles the two together). >>> >>> But I'm afraid this makes the configuration more >>> complicated. >>> >>> I can imagine it with 3 switches: >>> -Accept auth. request without request object >>> -Accept auth. request with request object included in >>> request param >>> -Accept auth. request with request object?referenced >>> with request_uri >>> (All of them true by default.) >>> >>> Or maybe with a dropdown "Accept auth. request": >>> -any (default) >>> -with request object included in request paramor >>> referenced withrequest_uri >>> -with request object included in request param >>> -withrequest object?referenced withrequest_uri >>> >>> Is this too much to add on the UI? >>> Do you have a better idea? >>> >>> Thanks, >>> ?ron >>> >>> >>> On 8 March 2018 at 17:23, Marek Posolda >>> > wrote: >>> >>> On 08/03/18 15:25, Marek Posolda wrote: >>> >>> Hi, >>> >>> sorry to not respond earlier. Your usecase makes >>> sense to me and the code you did as well. One >>> minor thing, which is missing, is admin console >>> update. I think you need to add new switch to >>> the client details page. Please add it to same >>> section like "Advanced config" where are other >>> things like request object signature algorithm etc. >>> >>> Forgot to mention, that it will be nice if you send >>> PR once you do it :) >>> >>> Thanks, >>> Marek >>> >>> >>> Thanks, >>> Marek >>> >>> On 06/03/18 20:13, Aron Bustya wrote: >>> >>> Hello! >>> >>> Can I get some reaction to this? (The >>> community guidelines say I need to >>> ask around before sending pull requests.) >>> >>> Regards, >>> ?ron Bustya >>> >>> On 2 December 2017 at 04:44, Aron Bustya >>> >> > wrote: >>> >>> Hi! >>> >>> I have a use case where the server must >>> accept authorization requests only >>> when they contain a signed request >>> object (should be configurable per >>> client). >>> >>> I have found a way to make the signing >>> of the request object mandatory by >>> specifying a >>> 'request.object.signature.alg' attribute >>> on the client, but >>> this only applies if a request object >>> exists in the first place. >>> >>> I would like to propose a pull request: >>> It defines a new client attribute >>> 'request.object.required'. If this is >>> set to 'true', the client must send a >>> request object when initiating an >>> authorization request. >>> >>> Current code can be checked here: >>> https://github.com/abustya/ >>> keycloak/commit/476912906a3ad0d290220a1f54abee073dba687a >>> >>> What do you think? >>> >>> Regards, >>> ?ron Bustya >>> >>> _______________________________________________ >>> keycloak-dev mailing list >>> keycloak-dev at lists.jboss.org >>> >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>> >>> >>> >>> >>> >>> >> >> >> > > From mposolda at redhat.com Tue Mar 13 16:18:03 2018 From: mposolda at redhat.com (Marek Posolda) Date: Tue, 13 Mar 2018 21:18:03 +0100 Subject: [keycloak-dev] How is JWK being parsed? In-Reply-To: References: Message-ID: <5e43ce6b-e92b-6919-f049-5c0ca271fe7b@redhat.com> There are some unit tests in our codebase in module "core" . Those may help to debug and understand what you need. Marek On 12/03/18 18:15, Rachael O'Regan wrote: > Hi all, > > I'm trying to figure out how Keycloak is parsing JWK. Am I correct in > thinking the JWSBuilder > > class > is responsible for this? And if so how can I run individual tests to debug > this class? > > Thank you, > From peters at develop4edu.de Tue Mar 13 16:35:51 2018 From: peters at develop4edu.de (Felix Peters) Date: Tue, 13 Mar 2018 20:35:51 +0000 Subject: [keycloak-dev] Maven dependencies for custom ActionToken implementation Message-ID: <1520973350927.66708@develop4edu.de> Hi, i try to implement a custom ActionToken. I want to deploy the Module via wildfly-maven-plugin. This works like expected. No errors when i run "mvn clean install wildfly:deploy". But when i try to instantiate a ActionToken i get the following exception: Uncaught server error: java.lang.NoClassDefFoundError: Failed to link my/package/actiontoken/TestActionToken (Module "deployment.keycloak-actiotokentest-1.0-SNAPSHOT.jar" from Service Module Loader): org/keycloak/authentication/actiontoken/DefaultActionToken In my pom.xml i have this dependencies for Keycloak: 3.4.3.Final org.keycloak keycloak-core provided ${keycloak.version} org.keycloak keycloak-server-spi provided ${keycloak.version} org.keycloak keycloak-server-spi-private provided ${keycloak.version} org.keycloak keycloak-services ${keycloak.version} In the quickstart example (https://github.com/keycloak/keycloak-quickstarts/blob/latest/action-token-authenticator/pom.xml) they have the keycloak-services dependency not in the provided scope. I tries to use this scope and i removed it. But i always get the same error. So what dependencies do i have to define if i want to implement a custom ActionToken? I think it's the keycloak-services, but i can't find details about that. Is the keycloak-services a provided artifact or not? Thanks for your help, Felix From bburke at redhat.com Tue Mar 13 17:15:54 2018 From: bburke at redhat.com (Bill Burke) Date: Tue, 13 Mar 2018 17:15:54 -0400 Subject: [keycloak-dev] we do not support offline tokens Message-ID: Correct me if I'm wrong, but we don't support the concept of an offline token right? Just an offline refresh token? Probably something we will have to support as Kubernetes, Openshift, and many of the social providers have a similar concept of a permanent persisted access token. -- Bill Burke Red Hat From peters at develop4edu.de Wed Mar 14 05:49:19 2018 From: peters at develop4edu.de (Felix Peters) Date: Wed, 14 Mar 2018 09:49:19 +0000 Subject: [keycloak-dev] Maven dependencies for custom ActionToken implementation In-Reply-To: <1520973350927.66708@develop4edu.de> References: <1520973350927.66708@develop4edu.de> Message-ID: <9e1aef39b1894b35b8844aa58ef4ae44@DOX13BE02.hex2013.com> I have an update to this question. When i deploy the module without maven its working with this dependencies in the module.xml: So I think the problem is the combination of wildfly-maven-plugin and the keycloak-services dependency. Maybe maven does not provide the right dependencies for the module? Is there a way to debug which dependencies are defined for my module if I deploy it via wildfly-maven-plugin? Do I need another maven plugin to make it work? At the moment I have the plugins defined in the quickstart repository: org.wildfly.plugins wildfly-maven-plugin 1.1.0.Final false org.jboss.as.plugins jboss-as-maven-plugin 7.4.Final false Cheers, Felix -----Urspr?ngliche Nachricht----- Von: keycloak-dev-bounces at lists.jboss.org Im Auftrag von Felix Peters Gesendet: Dienstag, 13. M?rz 2018 21:36 An: keycloak-dev at lists.jboss.org Betreff: [keycloak-dev] Maven dependencies for custom ActionToken implementation Hi, i try to implement a custom ActionToken. I want to deploy the Module via wildfly-maven-plugin. This works like expected. No errors when i run "mvn clean install wildfly:deploy". But when i try to instantiate a ActionToken i get the following exception: Uncaught server error: java.lang.NoClassDefFoundError: Failed to link my/package/actiontoken/TestActionToken (Module "deployment.keycloak-actiotokentest-1.0-SNAPSHOT.jar" from Service Module Loader): org/keycloak/authentication/actiontoken/DefaultActionToken In my pom.xml i have this dependencies for Keycloak: 3.4.3.Final org.keycloak keycloak-core provided ${keycloak.version} org.keycloak keycloak-server-spi provided ${keycloak.version} org.keycloak keycloak-server-spi-private provided ${keycloak.version} org.keycloak keycloak-services ${keycloak.version} In the quickstart example (https://github.com/keycloak/keycloak-quickstarts/blob/latest/action-token-authenticator/pom.xml) they have the keycloak-services dependency not in the provided scope. I tries to use this scope and i removed it. But i always get the same error. So what dependencies do i have to define if i want to implement a custom ActionToken? I think it's the keycloak-services, but i can't find details about that. Is the keycloak-services a provided artifact or not? Thanks for your help, Felix _______________________________________________ keycloak-dev mailing list keycloak-dev at lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-dev From sthorger at redhat.com Wed Mar 14 08:51:04 2018 From: sthorger at redhat.com (Stian Thorgersen) Date: Wed, 14 Mar 2018 13:51:04 +0100 Subject: [keycloak-dev] we do not support offline tokens In-Reply-To: References: Message-ID: An offline token would just be an access token with a long expiration time right? Isn't that a bit tricky from a security perspective and also from the fact that you can't really invalidate the token? So all services would need to check the token with the token introspection endpoint. Could we fill the same use-case with some sort of reference token instead? A short UUID that can be exchanged for a token using the token exchange service perhaps? On 13 March 2018 at 22:15, Bill Burke wrote: > Correct me if I'm wrong, but we don't support the concept of an > offline token right? Just an offline refresh token? > > Probably something we will have to support as Kubernetes, Openshift, > and many of the social providers have a similar concept of a permanent > persisted access token. > > -- > Bill Burke > Red Hat > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > From Sebastian.Schuster at bosch-si.com Wed Mar 14 09:37:47 2018 From: Sebastian.Schuster at bosch-si.com (Schuster Sebastian (INST/ESY1)) Date: Wed, 14 Mar 2018 13:37:47 +0000 Subject: [keycloak-dev] Client Scope naming Message-ID: Hi, I saw there are activities to replace client templates with client scopes. UMA 2.0 uses the term ?client scope? to determine what the OAuth client wants to do with the granted access (e.g. this could be used to determine the purpose of processing some data for GDPR compliance). Since Keycloak will also support UMA 2.0, I am a little concerned this might lead to some confusion. As you know, there are only two hard problems in computer science: cache invalidation, naming things, and off-by-one errors. ? WDYT? Best regards, Sebastian Mit freundlichen Gr??en / Best regards Dr.-Ing. Sebastian Schuster Engineering and Support (INST/ESY1) Bosch Software Innovations GmbH | Ullsteinstr. 128 | 12109 Berlin | GERMANY | www.bosch-si.com Tel. +49 30 726112-485 | Fax +49 30 726112-100 | Sebastian.Schuster at bosch-si.com Sitz: Berlin, Registergericht: Amtsgericht Charlottenburg; HRB 148411 B Aufsichtsratsvorsitzender: Dr.-Ing. Thorsten L?cke; Gesch?ftsf?hrung: Dr. Stefan Ferber, Michael Hahn From bburke at redhat.com Wed Mar 14 10:21:22 2018 From: bburke at redhat.com (Bill Burke) Date: Wed, 14 Mar 2018 10:21:22 -0400 Subject: [keycloak-dev] we do not support offline tokens In-Reply-To: References: Message-ID: On Wed, Mar 14, 2018 at 8:51 AM, Stian Thorgersen wrote: > An offline token would just be an access token with a long expiration time > right? > > Isn't that a bit tricky from a security perspective and also from the fact > that you can't really invalidate the token? So all services would need to > check the token with the token introspection endpoint. > > Could we fill the same use-case with some sort of reference token instead? A > short UUID that can be exchanged for a token using the token exchange > service perhaps? > What you're saying is current offline access + new reference token would be functionally equivalent? I don't think so. With kub/openshift/social providers, you issue and revoke specific persistent access tokens through an admin UI/CLI, user service UI/CLI, or REST interface. Clients that obtain these tokens just use them to invoke and don't have to refresh them. Services that receive these as bearer tokens, though, are required to invoke on a validation endpoint as they are usually opaque. -- Bill Burke Red Hat From bburke at redhat.com Wed Mar 14 10:53:56 2018 From: bburke at redhat.com (Bill Burke) Date: Wed, 14 Mar 2018 10:53:56 -0400 Subject: [keycloak-dev] kcinit console sso tool In-Reply-To: References: Message-ID: Was just talking to AOS team. Seems that it will fit real nicely as kubernetes has an SPI for plugging in tools like this: https://github.com/kubernetes/website/pull/7648/files?short_path=8198851#diff-81988518a0a2049d5e8b98d3a542e98b On Mon, Mar 12, 2018 at 3:36 PM, Pedro Igor Silva wrote: > Another thing you might consider is talk with Peter about how you can use > Elytron to secure tokens using a credential store. Elytron is a very tinny > library and there is an API for managing/storing credentials in a secure > manner. > > If you are not going to move everything to Go .... > > On Mon, Mar 12, 2018 at 4:15 PM, Bill Burke wrote: >> >> The "resource owner password credentials" grant type isn't really >> implemented as a multi-request flow and would have taken a bit of >> refactoring work. >> >> On Mon, Mar 12, 2018 at 2:36 PM, Pedro Igor Silva >> wrote: >> > Bill, I'm curious about why you are not using resource owner password >> > credentials grant type. Wouldn't be simpler instead of using >> > authorization >> > code ? >> > >> > On Mon, Mar 12, 2018 at 2:59 PM, Bill Burke wrote: >> >> >> >> On Mon, Mar 12, 2018 at 10:16 AM, Stian Thorgersen >> >> >> >> wrote: >> >> > Very cool. A few questions/comments: >> >> > >> >> > * As it's Java based it does make it harder to package/install. >> >> > Compare >> >> > 'oc' >> >> > tool for instance to our 'kcadmin' and 'kcclient' tools. Not sure how >> >> > realistic it would be to write our CLI tools in for instance Go >> >> > though. >> >> > >> >> >> >> Its a pretty simple tool so it could be ported. The only thing that >> >> might be a tiny bit challenging is making sure there's crypto stuff >> >> available in another language to encrypt/decrypt token files. Might >> >> be a nice little project for me to learn Go. >> >> >> >> > * I assume the console display is optional and it basically means >> >> > that >> >> > you >> >> > can only use authenticators that support this rather than all >> >> > authenticators >> >> > require to implement it. >> >> > >> >> >> >> I don't have a switch to launch browser, but, I could as this >> >> functionality is already implemented. Not sure if that would be >> >> portable to Go or another language though. Java has a facility to >> >> automatically launch browser (I think you know that already as you >> >> wrote KeycloakInstalled). >> >> >> >> BTW, what sucks about a browser login is that you have to manually >> >> kill the browser window after you complete the login. >> >> >> >> > * Not sure I fully understand the user experience with the encrypted >> >> > password file. How does this compare to kinit and ssh-agent for >> >> > instance? >> >> > They both allow unlocking automatically through the regular OS login >> >> > I >> >> > believe. For 'kcadmin' and 'kcclient' we don't currently protect the >> >> > tokens >> >> > so we should probably consider aligning these approaches (probably >> >> > even >> >> > getting rid of the auth stuff there in favour of kcinit). >> >> > >> >> >> >> I just read up on kinit and ssh-agent. Have you actually used either >> >> of these before(I haven't)? I don't think they work as you think they >> >> do. >> >> >> >> For instance, ssh-agent is a bit convoluted and requires IPC >> >> communication with a background process using a file-based socket. >> >> The background process holds private keys in memory which must be >> >> unlocked and loaded with a password when you boot your windows manager >> >> or your shell. The socket used must be set as an environment variable >> >> before you can invoke ssh in your shell. I think when you invoke ssh, >> >> it looks for this environment variable and works with the ssh-agent to >> >> establish a connection over the local file socket. >> >> >> >> For kinit, I think to have a global login for the entire machine, it >> >> creates a keytab file which has file permissions readable by any >> >> process started by the user. And the keytab contains the tickets. >> >> This is no different than what we do now for kcadmin. >> >> >> >> The current solution I have is only for creating an sso session for >> >> the current shell and any processes run within the shell would be able >> >> to figure out how to access the encrypted token files. >> >> >> >> >> >> > * Should we consider merging all our CLIs into one CLI? Just 'kc' >> >> > instead of >> >> > 'kcinit', 'kcadmin' and 'kcclient'? If we someone could get this >> >> > stuff >> >> > in Go >> >> > and get native binaries that'd be even easier for users to use. >> >> > >> >> >> >> kcadmin and kcclient should be merged. kcinit should be a separate >> >> small generic reusable utility. >> >> >> >> >> >> > On 12 March 2018 at 14:29, Bill Burke wrote: >> >> >> >> >> >> I'm finally finishing the generic console login tool I've been >> >> >> promising and working on for awhile now. Its an extension of >> >> >> KeycloakInstalled, but it works entirely on the command line and >> >> >> doesn't require a browser. Its all text input and output in your >> >> >> command line console to login. All driven by the server and >> >> >> rendered >> >> >> by the utility. Supports localization just like the browser too. >> >> >> >> >> >> * To enable this a simple challenge-based protocol was implemented. >> >> >> OAuth Code to token flow is required. >> >> >> >> >> >> Authenticator returns 401 with a WWW-Authenticate header with value >> >> >> of >> >> >> >> >> >> X-Text-Form-Challenge callback="{url}" param="username" >> >> >> label="Username: " mask="false" >> >> >> >> >> >> param/label/mask are input parameter definitions that require >> >> >> command >> >> >> line console input and can be repeated for each input parameter you >> >> >> require from the console. Label is what should be outputed to the >> >> >> console. If mask is true, this means it is a password field and >> >> >> should be hidden on input. >> >> >> >> >> >> If the Response contains "text/plain" content, then that should be >> >> >> outputed before command input is asked for. Client should loop and >> >> >> render/ask for input until a 302 response is returned that contains >> >> >> a >> >> >> "code" parameter. Then regular OAuth is used to get the token. >> >> >> >> >> >> * The access and refresh token is stored locally in a password >> >> >> protected file (like ssh does). This file is checked before login is >> >> >> initiated to see if the user is still logged in. >> >> >> >> >> >> * If logged in, and the client has permission, the kcinit tool can >> >> >> also perform token exchange to obtain tokens for other clients. It >> >> >> stores these tokens in password protected files on local disk. >> >> >> >> >> >> * I have extended the OAuth layer on the server to support the OIDC >> >> >> "display" parameter. (It just stores this value in the AuthSession. >> >> >> I'm also in the process to refactor all the built-in Authenticators >> >> >> and Required Actions to support the "display" parameter and use the >> >> >> texts protocol described above if the "display" parameter is >> >> >> "console". >> >> >> >> >> >> * kcinit is implemented via Java and a shell and windows batch >> >> >> scripts. There's also a wrapper template script that can be used to >> >> >> secure existing command line tools. here's example usage with the >> >> >> target app command being `oc`. >> >> >> >> >> >> $ . kcinit >> >> >> >> >> >> Initially you will be prompted for the "local password" that >> >> >> protects >> >> >> token files on local disk. If you do not "source" this script (with >> >> >> a >> >> >> '.' or 'source' command), then you will have to enter in this local >> >> >> password every time you interact with kcinit utility. >> >> >> >> >> >> the kcinit script will prompt for this local password. Once it gets >> >> >> the password value, it will invoke the Java kcinit program: >> >> >> >> >> >> read -sp 'Local password: ' password >> >> >> KC_SESSION_KEY=`java -jar kcinit.jar password $password` >> >> >> >> >> >> The `password` command will generate an AES key from the password >> >> >> that >> >> >> will be used encrypt and decrypt locally stored files. I do it this >> >> >> way so that when the user's shell is exited, they can no longer >> >> >> access >> >> >> stored tokens. >> >> >> >> >> >> Once the user is logged in, they can start using command line >> >> >> utilities that are secured by it. To secure a command line utility >> >> >> the developer must use a wrapper script for each of their command >> >> >> line >> >> >> tools. The wrapper script looks like this >> >> >> >> >> >> - checks to see if KC_SESSION_KEY is set. If not, it will prompt >> >> >> for >> >> >> the local password and generate this key. >> >> >> - It then tries to obtain the token for the app >> >> >> >> >> >> token=`java -jar kcinit.jar token oc` >> >> >> >> >> >> This will perform a token exchange to obtain a token for the `oc` >> >> >> client. If this is not successful, an error message is displayed >> >> >> (i.e. "You are not logged in".) If successful, then the target >> >> >> command line tool is invoked. The tool extracts the "token" >> >> >> environment variable to invoke on its REST services. >> >> >> >> >> >> $path_to_real_command/$0 $@ >> >> >> >> >> >> * There is an install option for kcinit >> >> >> >> >> >> $ kcinit install >> >> >> >> >> >> This will prompt you for auth server url, realm, client, client >> >> >> secret, and the local password to encrypt things. >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> -- >> >> >> Bill Burke >> >> >> Red Hat >> >> >> _______________________________________________ >> >> >> keycloak-dev mailing list >> >> >> keycloak-dev at lists.jboss.org >> >> >> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> >> > >> >> > >> >> >> >> >> >> >> >> -- >> >> Bill Burke >> >> Red Hat >> >> _______________________________________________ >> >> keycloak-dev mailing list >> >> keycloak-dev at lists.jboss.org >> >> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> > >> > >> >> >> >> -- >> Bill Burke >> Red Hat > > -- Bill Burke Red Hat From Sebastian.Schuster at bosch-si.com Wed Mar 14 10:55:36 2018 From: Sebastian.Schuster at bosch-si.com (Schuster Sebastian (INST/ESY1)) Date: Wed, 14 Mar 2018 14:55:36 +0000 Subject: [keycloak-dev] we do not support offline tokens In-Reply-To: References: Message-ID: <64f691b3212f4603b6ec7f15c189cff5@bosch-si.com> I always thought an offline token is a long-living refresh token... Best regards, Sebastian Mit freundlichen Gr??en / Best regards Dr.-Ing. Sebastian Schuster Engineering and Support (INST/ESY1) Bosch?Software Innovations?GmbH | Ullsteinstr. 128 | 12109 Berlin | GERMANY | www.bosch-si.com Tel. +49 30 726112-485 | Fax +49 30 726112-100 | Sebastian.Schuster at bosch-si.com Sitz: Berlin, Registergericht: Amtsgericht Charlottenburg; HRB 148411 B Aufsichtsratsvorsitzender: Dr.-Ing. Thorsten L?cke; Gesch?ftsf?hrung: Dr. Stefan Ferber, Michael Hahn -----Original Message----- From: keycloak-dev-bounces at lists.jboss.org [mailto:keycloak-dev-bounces at lists.jboss.org] On Behalf Of Bill Burke Sent: Mittwoch, 14. M?rz 2018 15:21 To: Stian Thorgersen Cc: keycloak-dev Subject: Re: [keycloak-dev] we do not support offline tokens On Wed, Mar 14, 2018 at 8:51 AM, Stian Thorgersen wrote: > An offline token would just be an access token with a long expiration > time right? > > Isn't that a bit tricky from a security perspective and also from the > fact that you can't really invalidate the token? So all services would > need to check the token with the token introspection endpoint. > > Could we fill the same use-case with some sort of reference token > instead? A short UUID that can be exchanged for a token using the > token exchange service perhaps? > What you're saying is current offline access + new reference token would be functionally equivalent? I don't think so. With kub/openshift/social providers, you issue and revoke specific persistent access tokens through an admin UI/CLI, user service UI/CLI, or REST interface. Clients that obtain these tokens just use them to invoke and don't have to refresh them. Services that receive these as bearer tokens, though, are required to invoke on a validation endpoint as they are usually opaque. -- Bill Burke Red Hat _______________________________________________ keycloak-dev mailing list keycloak-dev at lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-dev From bburke at redhat.com Wed Mar 14 12:02:00 2018 From: bburke at redhat.com (Bill Burke) Date: Wed, 14 Mar 2018 12:02:00 -0400 Subject: [keycloak-dev] we do not support offline tokens In-Reply-To: <64f691b3212f4603b6ec7f15c189cff5@bosch-si.com> References: <64f691b3212f4603b6ec7f15c189cff5@bosch-si.com> Message-ID: On Wed, Mar 14, 2018 at 10:55 AM, Schuster Sebastian (INST/ESY1) wrote: > I always thought an offline token is a long-living refresh token... > > Best regards, > Sebastian > Yes, that's how OIDC thinks of offline tokens and how we've implemented it. But facebook, kubernetes, openshift have the concept of a persistent token that can be used in bearer requests. Bill From Sebastian.Schuster at bosch-si.com Wed Mar 14 12:22:45 2018 From: Sebastian.Schuster at bosch-si.com (Schuster Sebastian (INST/ESY1)) Date: Wed, 14 Mar 2018 16:22:45 +0000 Subject: [keycloak-dev] we do not support offline tokens In-Reply-To: References: <64f691b3212f4603b6ec7f15c189cff5@bosch-si.com> Message-ID: <652ad7bea0574ecdbb68df0edc7beb61@bosch-si.com> But that only really makes sense for reference tokens where you need some kind of reference resolution/introspection anyways because otherwise you miss a mechanism to revoke access, right? Having to introspect a JWT every time it is used for access kind of defeats the purpose of having a self-contained token in the first place... Best regards, Sebastian Mit freundlichen Gr??en / Best regards Dr.-Ing. Sebastian Schuster Engineering and Support (INST/ESY1) Bosch?Software Innovations?GmbH | Ullsteinstr. 128 | 12109 Berlin | GERMANY | www.bosch-si.com Tel. +49 30 726112-485 | Fax +49 30 726112-100 | Sebastian.Schuster at bosch-si.com Sitz: Berlin, Registergericht: Amtsgericht Charlottenburg; HRB 148411 B Aufsichtsratsvorsitzender: Dr.-Ing. Thorsten L?cke; Gesch?ftsf?hrung: Dr. Stefan Ferber, Michael Hahn -----Original Message----- From: Bill Burke [mailto:bburke at redhat.com] Sent: Mittwoch, 14. M?rz 2018 17:02 To: Schuster Sebastian (INST/ESY1) Cc: Stian Thorgersen ; keycloak-dev Subject: Re: [keycloak-dev] we do not support offline tokens On Wed, Mar 14, 2018 at 10:55 AM, Schuster Sebastian (INST/ESY1) wrote: > I always thought an offline token is a long-living refresh token... > > Best regards, > Sebastian > Yes, that's how OIDC thinks of offline tokens and how we've implemented it. But facebook, kubernetes, openshift have the concept of a persistent token that can be used in bearer requests. Bill From psilva at redhat.com Wed Mar 14 12:46:27 2018 From: psilva at redhat.com (Pedro Igor Silva) Date: Wed, 14 Mar 2018 13:46:27 -0300 Subject: [keycloak-dev] we do not support offline tokens In-Reply-To: References: <64f691b3212f4603b6ec7f15c189cff5@bosch-si.com> Message-ID: I think facebook, kube and openshift have different requirements. They can use persistent tokens because they have complete control over their lifetime and they are targeted to be used within their environments. Facebook in particular acts as both AS and resource server. On Wed, Mar 14, 2018 at 1:02 PM, Bill Burke wrote: > On Wed, Mar 14, 2018 at 10:55 AM, Schuster Sebastian (INST/ESY1) > wrote: > > I always thought an offline token is a long-living refresh token... > > > > Best regards, > > Sebastian > > > > Yes, that's how OIDC thinks of offline tokens and how we've > implemented it. But facebook, kubernetes, openshift have the concept > of a persistent token that can be used in bearer requests. > > Bill > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > From mposolda at redhat.com Wed Mar 14 13:46:41 2018 From: mposolda at redhat.com (Marek Posolda) Date: Wed, 14 Mar 2018 18:46:41 +0100 Subject: [keycloak-dev] Initial client scopes PR Message-ID: <7d4da3f5-4e64-e1df-983d-4f14cdcb19d7@redhat.com> Hi, I've finally send PR https://github.com/keycloak/keycloak/pull/5076 for the first iteration of client scopes. I will talk on tomorrow call about the details and still need to write some more automated tests. But I am seing PR now if someone wants to take a look. Summary: - Client Templates were renamed to "Client Scopes". Some things were removed from the client template admin console (EG. Theme setting added recently). Also I've removed some ClientTemplate model properties, which were never used. Client Scope still has list of protocol mappers and list of "Scopes" (Roles scope mappings). - There is new tab "Client Scopes" on client. Here you can assign client scopes to client. Each client has 2 types of client scopes: -- Default client scopes -- Those client scopes are automatically applied when login with the client. Their protocol mappers and "Role scope mappings" are always used. -- Optional client scopes -- Those client scopes are applicable just for OIDC clients. They are used just if they are requested by "scope" parameter during login - Under "Client scopes", there is new tab "Default Client Scopes" . This allows to specify "Realm default client scopes" and "Realm optional client scopes". The scopes configured here will be added as default/optional scopes to new clients. Client can override this (Remove those defaults and add some different client scopes). So it works similarly to Default Roles. - Roles don't have "Scope Param Required" flag anymore. Protocol mappers don't have "Consent required" and "Consent text" anymore. Client scopes don't have "Full scope allowed" flag. But clients still have "Full scope allowed" flag for now and it's still ON by default for newly created clients. - There are few builtin client scopes added to each realm. There are 4 claims scopes defined in OIDC specification and those are added by default: "profile", "email", "address" and "phone" with the protocol mappers corresponding to the claims described in OIDC specification [1]. -- The "profile" and "email" are configured as default scopes and hence are automatically added to new clients. -- The "phone" and "address" are configured as optional scopes by default. -- The clients now doesn't have any protocolMappers added by default when they are created. I've added "profile" and "email" as default scopes due it's most close to the previous default protocolMappers we had. - For SAML, there is "role_list" default client scope, containing just 1 protocol mapper "role list". So both OIDC and SAML clients don't have any protocol mappers by default, it's driven by client scopes now by default. - There is "offline_access" OIDC client scope, which is optional scope by default. This scope contains just "offline_access" realm role. Due the fact, that parameter "Scope Param Required" was removed from RoleModel, the "offline_access" role is now automatically available in tokens for clients with "Full Scope Allowed", even if no offline tokens was requsted. But I don't think it's big issue besides a bit bigger token. Same also already applies for uma_authorization and some other built-in roles. The fact, that offline token is requested is now driven by "offline_access" scope. But user should still have "offline_access" role to be able to receive offline token. Consent changes: - Consent screen now doesn't display protocolMappers (claims) and roles, but instead it displays just client scopes. So by default, the consent screen contains 2 items "User profile" and "Email address", which correspond to the "profile" and "email" OIDC scopes. - There can be still the case, when client has some protocolMappers or role scope mappings defined on itself. So I've added flag "Display On Consent Screen" on clients (It's OFF by default) to specify if some message should be shown on consent screen about claims dedicated directly to client itself. It's useful especially when client doesn't have any client scopes as the consent screen wouldn't be displayed in that case. - During this refactoring, I've tried to do some cleanup we discussed before, so I've removed protocolMappers and roles from clientSession. Instead I've added clientScopes to refresh token. During refreshing token, it's checked that user still has all the consents, which are in the refresh token. So in case that user revoked consents in the meantime, the token refresh will fail. ProtocolMappers and scoped roles are always re-computed from the clientScopes. So if for example another claim was added to scope "profile", it will automatically be applied after refreshed token. I don't see an issue with that. User approved on consent screen scope "profile" and he may not be concerned what claims/scoped roles are in profile. - Migration: In the end I did not change existing clients and did not remove protocolMappers from them and didn't add default/optional client scopes to them. The only exception is "offline_access" profile, which is added as optional to all clients, which had scope to "offline_access" role. Consents are not migrated - again with the only exception being "offline_access" consent, so refreshing offline tokens from previous version still works. The new consent screen is something quite different than previous one, so makes sense to show it to users again when they want to login, even if they approved protocolMappers for the previous version. Sorry for long email and long PR :) More tomorrow... [1] http://openid.net/specs/openid-connect-core-1_0.html#ScopeClaims Marek From psilva at redhat.com Wed Mar 14 14:36:09 2018 From: psilva at redhat.com (Pedro Igor Silva) Date: Wed, 14 Mar 2018 15:36:09 -0300 Subject: [keycloak-dev] Additional methods to Policy Evaluation API Message-ID: Hi, Users have been asking for additional methods in the Evaluation API in order to query the realm for additional information about users such as group membership, roles, etc. The main requirement is to allow query these information not only for the user trying to access a resource but any other user, including owners of resources, from a realm. For that, I've added a new interface [1] from which policies can query these information. I think that would give a lot more flexibility for those writing policies in Keycloak using JS or Drools. The corresponding JIRA is https://issues.jboss.org/browse/KEYCLOAK-6628. [1] https://github.com/keycloak/keycloak/pull/5077/files#diff-136248257141060854b90ccbd9a8645a Regards. Pedro Igor From sthorger at redhat.com Wed Mar 14 15:07:41 2018 From: sthorger at redhat.com (Stian Thorgersen) Date: Wed, 14 Mar 2018 20:07:41 +0100 Subject: [keycloak-dev] we do not support offline tokens In-Reply-To: References: <64f691b3212f4603b6ec7f15c189cff5@bosch-si.com> Message-ID: I think the short tokens issued by the likes of OpenShift is primarily used for authentication, not access. As such it's more a short ID token than an actual access token. I could see us doing something similar with allowing users to generate these short tokens that can be used to authenticate and obtain refresh/access tokens instead of using username/password. On 14 March 2018 at 17:46, Pedro Igor Silva wrote: > I think facebook, kube and openshift have different requirements. They can > use persistent tokens because they have complete control over their > lifetime and they are targeted to be used within their environments. > > Facebook in particular acts as both AS and resource server. > > On Wed, Mar 14, 2018 at 1:02 PM, Bill Burke wrote: > >> On Wed, Mar 14, 2018 at 10:55 AM, Schuster Sebastian (INST/ESY1) >> wrote: >> > I always thought an offline token is a long-living refresh token... >> > >> > Best regards, >> > Sebastian >> > >> >> Yes, that's how OIDC thinks of offline tokens and how we've >> implemented it. But facebook, kubernetes, openshift have the concept >> of a persistent token that can be used in bearer requests. >> >> Bill >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> > > From sthorger at redhat.com Wed Mar 14 15:15:01 2018 From: sthorger at redhat.com (Stian Thorgersen) Date: Wed, 14 Mar 2018 20:15:01 +0100 Subject: [keycloak-dev] kcinit console sso tool In-Reply-To: References: Message-ID: On 12 March 2018 at 18:59, Bill Burke wrote: > On Mon, Mar 12, 2018 at 10:16 AM, Stian Thorgersen > wrote: > > Very cool. A few questions/comments: > > > > * As it's Java based it does make it harder to package/install. Compare > 'oc' > > tool for instance to our 'kcadmin' and 'kcclient' tools. Not sure how > > realistic it would be to write our CLI tools in for instance Go though. > > > > Its a pretty simple tool so it could be ported. The only thing that > might be a tiny bit challenging is making sure there's crypto stuff > available in another language to encrypt/decrypt token files. Might > be a nice little project for me to learn Go. > > > * I assume the console display is optional and it basically means that > you > > can only use authenticators that support this rather than all > authenticators > > require to implement it. > > > > I don't have a switch to launch browser, but, I could as this > functionality is already implemented. Not sure if that would be > portable to Go or another language though. Java has a facility to > automatically launch browser (I think you know that already as you > wrote KeycloakInstalled). > That would be pretty cool, but I wasn't thinking that far. I was just basically thinking that authenticators has to be written to support this, rather than all authenticators have to support this. > > BTW, what sucks about a browser login is that you have to manually > kill the browser window after you complete the login. > > > * Not sure I fully understand the user experience with the encrypted > > password file. How does this compare to kinit and ssh-agent for instance? > > They both allow unlocking automatically through the regular OS login I > > believe. For 'kcadmin' and 'kcclient' we don't currently protect the > tokens > > so we should probably consider aligning these approaches (probably even > > getting rid of the auth stuff there in favour of kcinit). > > > > I just read up on kinit and ssh-agent. Have you actually used either > of these before(I haven't)? I don't think they work as you think they > do. > > For instance, ssh-agent is a bit convoluted and requires IPC > communication with a background process using a file-based socket. > The background process holds private keys in memory which must be > unlocked and loaded with a password when you boot your windows manager > or your shell. The socket used must be set as an environment variable > before you can invoke ssh in your shell. I think when you invoke ssh, > it looks for this environment variable and works with the ssh-agent to > establish a connection over the local file socket. > > For kinit, I think to have a global login for the entire machine, it > creates a keytab file which has file permissions readable by any > process started by the user. And the keytab contains the tickets. > This is no different than what we do now for kcadmin. > > The current solution I have is only for creating an sso session for > the current shell and any processes run within the shell would be able > to figure out how to access the encrypted token files. > I got no clue how they work, but what I meant is the fact that ssh-agent allows you to unlock the keys automatically when you login to your browser. If you have to provide a password to unlock the tokens every time you open a new shell does it actually provide a nicer experience than just doing username/password to login again with resource owner credential grant? Would be cool of kcinit runs a daemon or something that means you at least only need to unlock it once per session on your desktop. Would be even cooler if we somehow could integrate it with the key managers that is unlocked when the user logs in. > > > > * Should we consider merging all our CLIs into one CLI? Just 'kc' > instead of > > 'kcinit', 'kcadmin' and 'kcclient'? If we someone could get this stuff > in Go > > and get native binaries that'd be even easier for users to use. > > > > kcadmin and kcclient should be merged. kcinit should be a separate > small generic reusable utility. > Agree > > > > On 12 March 2018 at 14:29, Bill Burke wrote: > >> > >> I'm finally finishing the generic console login tool I've been > >> promising and working on for awhile now. Its an extension of > >> KeycloakInstalled, but it works entirely on the command line and > >> doesn't require a browser. Its all text input and output in your > >> command line console to login. All driven by the server and rendered > >> by the utility. Supports localization just like the browser too. > >> > >> * To enable this a simple challenge-based protocol was implemented. > >> OAuth Code to token flow is required. > >> > >> Authenticator returns 401 with a WWW-Authenticate header with value of > >> > >> X-Text-Form-Challenge callback="{url}" param="username" > >> label="Username: " mask="false" > >> > >> param/label/mask are input parameter definitions that require command > >> line console input and can be repeated for each input parameter you > >> require from the console. Label is what should be outputed to the > >> console. If mask is true, this means it is a password field and > >> should be hidden on input. > >> > >> If the Response contains "text/plain" content, then that should be > >> outputed before command input is asked for. Client should loop and > >> render/ask for input until a 302 response is returned that contains a > >> "code" parameter. Then regular OAuth is used to get the token. > >> > >> * The access and refresh token is stored locally in a password > >> protected file (like ssh does). This file is checked before login is > >> initiated to see if the user is still logged in. > >> > >> * If logged in, and the client has permission, the kcinit tool can > >> also perform token exchange to obtain tokens for other clients. It > >> stores these tokens in password protected files on local disk. > >> > >> * I have extended the OAuth layer on the server to support the OIDC > >> "display" parameter. (It just stores this value in the AuthSession. > >> I'm also in the process to refactor all the built-in Authenticators > >> and Required Actions to support the "display" parameter and use the > >> texts protocol described above if the "display" parameter is > >> "console". > >> > >> * kcinit is implemented via Java and a shell and windows batch > >> scripts. There's also a wrapper template script that can be used to > >> secure existing command line tools. here's example usage with the > >> target app command being `oc`. > >> > >> $ . kcinit > >> > >> Initially you will be prompted for the "local password" that protects > >> token files on local disk. If you do not "source" this script (with a > >> '.' or 'source' command), then you will have to enter in this local > >> password every time you interact with kcinit utility. > >> > >> the kcinit script will prompt for this local password. Once it gets > >> the password value, it will invoke the Java kcinit program: > >> > >> read -sp 'Local password: ' password > >> KC_SESSION_KEY=`java -jar kcinit.jar password $password` > >> > >> The `password` command will generate an AES key from the password that > >> will be used encrypt and decrypt locally stored files. I do it this > >> way so that when the user's shell is exited, they can no longer access > >> stored tokens. > >> > >> Once the user is logged in, they can start using command line > >> utilities that are secured by it. To secure a command line utility > >> the developer must use a wrapper script for each of their command line > >> tools. The wrapper script looks like this > >> > >> - checks to see if KC_SESSION_KEY is set. If not, it will prompt for > >> the local password and generate this key. > >> - It then tries to obtain the token for the app > >> > >> token=`java -jar kcinit.jar token oc` > >> > >> This will perform a token exchange to obtain a token for the `oc` > >> client. If this is not successful, an error message is displayed > >> (i.e. "You are not logged in".) If successful, then the target > >> command line tool is invoked. The tool extracts the "token" > >> environment variable to invoke on its REST services. > >> > >> $path_to_real_command/$0 $@ > >> > >> * There is an install option for kcinit > >> > >> $ kcinit install > >> > >> This will prompt you for auth server url, realm, client, client > >> secret, and the local password to encrypt things. > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> -- > >> Bill Burke > >> Red Hat > >> _______________________________________________ > >> keycloak-dev mailing list > >> keycloak-dev at lists.jboss.org > >> https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > > > > > > -- > Bill Burke > Red Hat > From mposolda at redhat.com Wed Mar 14 15:48:09 2018 From: mposolda at redhat.com (Marek Posolda) Date: Wed, 14 Mar 2018 20:48:09 +0100 Subject: [keycloak-dev] we do not support offline tokens In-Reply-To: References: Message-ID: On 14/03/18 15:21, Bill Burke wrote: > On Wed, Mar 14, 2018 at 8:51 AM, Stian Thorgersen wrote: >> An offline token would just be an access token with a long expiration time >> right? >> >> Isn't that a bit tricky from a security perspective and also from the fact >> that you can't really invalidate the token? So all services would need to >> check the token with the token introspection endpoint. >> >> Could we fill the same use-case with some sort of reference token instead? A >> short UUID that can be exchanged for a token using the token exchange >> service perhaps? >> > What you're saying is current offline access + new reference token > would be functionally equivalent? I don't think so. With > kub/openshift/social providers, you issue and revoke specific > persistent access tokens through an admin UI/CLI, user service UI/CLI, > or REST interface. Clients that obtain these tokens just use them to > invoke and don't have to refresh them. Services that receive these as > bearer tokens, though, are required to invoke on a validation endpoint > as they are usually opaque. > If we're fine with the limitation, that service always needs to call validation/introspection endpoint with the persistent token, then we can achieve it quite easily. We can have protocolMapper, which will change the expiration of accessToken to 30 days or so (same time like current Offline Idle Timeout). We can ensure that this protocolMapper is used just when requested with some special value of scope parameter like for example: "scope=offline_access persistent_access" . User is able to revoke this token in account management, that's already possible. The refresh won't be there, so user will need to re-authenticate every 30 days, but hopefully that's ok? AFAIK Facebook tokens are also not "infinite", but have some long lifespan like 1 month or so. Marek From mposolda at redhat.com Wed Mar 14 16:03:04 2018 From: mposolda at redhat.com (Marek Posolda) Date: Wed, 14 Mar 2018 21:03:04 +0100 Subject: [keycloak-dev] Client Scope naming In-Reply-To: References: Message-ID: <6109ae10-65be-5c45-8a9e-bd4f79c034bc@redhat.com> That's good question. As you know, we also have "Scope" tab (used to specify scope role mappings of client) and "Authorization scope", which is used when Authorization is enabled :) Marek On 14/03/18 14:37, Schuster Sebastian (INST/ESY1) wrote: > Hi, > > I saw there are activities to replace client templates with client scopes. UMA 2.0 uses the term ?client scope? to determine what the OAuth client wants to do with the granted access (e.g. this could be used to determine the purpose of processing some data for GDPR compliance). Since Keycloak will also support UMA 2.0, I am a little concerned this might lead to some confusion. As you know, there are only two hard problems in computer science: cache invalidation, naming things, and off-by-one errors. ? WDYT? > > Best regards, > Sebastian > > Mit freundlichen Gr??en / Best regards > > Dr.-Ing. Sebastian Schuster > > Engineering and Support (INST/ESY1) > Bosch Software Innovations GmbH | Ullsteinstr. 128 | 12109 Berlin | GERMANY | www.bosch-si.com > Tel. +49 30 726112-485 | Fax +49 30 726112-100 | Sebastian.Schuster at bosch-si.com > > Sitz: Berlin, Registergericht: Amtsgericht Charlottenburg; HRB 148411 B > Aufsichtsratsvorsitzender: Dr.-Ing. Thorsten L?cke; Gesch?ftsf?hrung: Dr. Stefan Ferber, Michael Hahn > > > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev From psilva at redhat.com Wed Mar 14 16:00:44 2018 From: psilva at redhat.com (Pedro Igor Silva) Date: Wed, 14 Mar 2018 17:00:44 -0300 Subject: [keycloak-dev] Client Scope naming In-Reply-To: References: Message-ID: I need to take a closer look on what Marek did around client scopes. So far, scopes were basically associated with roles and protocol mappers and that is not really what we need in UMA 2.0. If scopes now is more abstract and we can remove "authorization scopes" in authz services, I need to take a look ... In fact, I need to review scope parameter in UMA grant type in order to allow clients to push additional scopes other those already added in a ticket. On Wed, Mar 14, 2018 at 10:37 AM, Schuster Sebastian (INST/ESY1) < Sebastian.Schuster at bosch-si.com> wrote: > Hi, > > I saw there are activities to replace client templates with client scopes. > UMA 2.0 uses the term ?client scope? to determine what the OAuth client > wants to do with the granted access (e.g. this could be used to determine > the purpose of processing some data for GDPR compliance). Since Keycloak > will also support UMA 2.0, I am a little concerned this might lead to some > confusion. As you know, there are only two hard problems in computer > science: cache invalidation, naming things, and off-by-one errors. ? WDYT? > > Best regards, > Sebastian > > Mit freundlichen Gr??en / Best regards > > Dr.-Ing. Sebastian Schuster > > Engineering and Support (INST/ESY1) > Bosch Software Innovations GmbH | Ullsteinstr. 128 | 12109 Berlin | > GERMANY | www.bosch-si.com > Tel. +49 30 726112-485 | Fax +49 30 726112-100 | > Sebastian.Schuster at bosch-si.com > > Sitz: Berlin, Registergericht: Amtsgericht Charlottenburg; HRB 148411 B > Aufsichtsratsvorsitzender: Dr.-Ing. Thorsten L?cke; Gesch?ftsf?hrung: Dr. > Stefan Ferber, Michael Hahn > > > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev From bburke at redhat.com Wed Mar 14 22:12:53 2018 From: bburke at redhat.com (Bill Burke) Date: Wed, 14 Mar 2018 22:12:53 -0400 Subject: [keycloak-dev] we do not support offline tokens In-Reply-To: References: <64f691b3212f4603b6ec7f15c189cff5@bosch-si.com> Message-ID: On Wed, Mar 14, 2018 at 3:07 PM, Stian Thorgersen wrote: > I think the short tokens issued by the likes of OpenShift is primarily used > for authentication, not access. As such it's more a short ID token than an > actual access token. > This is just not how it works. Service Account tokens in Openshift/Kubernetes can be used as bearer tokens. Services that receive these bearer tokens call a validation endpoint (token review). The validation endpoint returns a JSON document with user info and group membership. Kubernetes additionally has a Authorization endpoint that can be invoked, but you pass in username, not a token, and the resources you want to access. BTW, this is how many OAuth implementations work. Access tokens are just opaque strings that must be validated and the only way to get information about the user is by invoking on a user info service. The keycloak/openshift integration requires keycloak to invoke on the OpenShift API server. The provider is configured with an Openshift service account token. The configured token is used as a bearer token. THERE IS NO REFRESH...EVER. Makes things really simple for the client. There are a lot of Keycloak users that jack up access token timeouts because they want permanent tokens. Managing token timeouts and refreshes is a pain in the ass. FYI, I'm not just pulling this out of my ass... :) Simo seems to think that this is a blocker for GA for keycloak/openshift integration. > I could see us doing something similar with allowing users to generate these > short tokens that can be used to authenticate and obtain refresh/access > tokens instead of using username/password. > This is just not the same thing, sorry. Useful, but not the same thing. From naftali at vanderloon.nl Thu Mar 15 07:26:41 2018 From: naftali at vanderloon.nl (Naftali van der Loon) Date: Thu, 15 Mar 2018 12:26:41 +0100 Subject: [keycloak-dev] first broker login always shows: "your already logged in" Message-ID: Hi, If i configure a new google broker, it always shows: "your already logged in" It seems to never redirect back to my application. The logging shows the following warning: Not present cache item for key LoginFailureKey [ realmId=mgb. userId=1178a3e9-f20a-4564-b921-22e196b6ab9b If I try to login again from my application, I get an unexpected error. logging shows: ERROR [org.keycloak.broker.oidc.AbstractOAuth2IdentityProvider] (default task-17) Failed to make identity provider oauth callback: org.keycloak.broker.provider.IdentityBrokerException: No access_token from server. at org.keycloak.broker.oidc.OIDCIdentityProvider.verifyAccessToken(OIDCIdentityProvider.java:444) With some more logging I see that a POST request to www.googleapis.com/oauth2/v3/token returns a 401 Unauthorized the following request params were sent: code=4%2FAADq7hCNFYS8Sn5fSaKTO-Z4NFsWp8dt-_rxDFfI9zV5by4zeKLKy9EIw-1S0xD7WZs8O2lIwVQpbYdhv-eRcDc&grant_type=authorization_code&client_secret=**********&redirect_uri=https%3A%2F% 2Fsecure.mydomain.nl %2Fauth%2Frealms%2Fbloxsense%2Fbroker%2Fgoogle%2Fendpoint&client_id= 770468752706-kvjr3kjmi12uokbe30ldpu4lt43k05vm.apps.googleusercontent.com" I tried using stickie sessions in my loadbalancer, there is no difference in behaviour.. This is a HA setup using the helm chart Greetz Naftali From psilva at redhat.com Thu Mar 15 07:39:29 2018 From: psilva at redhat.com (Pedro Igor Silva) Date: Thu, 15 Mar 2018 08:39:29 -0300 Subject: [keycloak-dev] Client Scope naming In-Reply-To: <6109ae10-65be-5c45-8a9e-bd4f79c034bc@redhat.com> References: <6109ae10-65be-5c45-8a9e-bd4f79c034bc@redhat.com> Message-ID: How a scope looks like now after your changes ? Are they just strings referencing a set of one or more roles ? Or they are still roles ? On Wed, Mar 14, 2018 at 5:03 PM, Marek Posolda wrote: > That's good question. As you know, we also have "Scope" tab (used to > specify scope role mappings of client) and "Authorization scope", which > is used when Authorization is enabled :) > > Marek > > On 14/03/18 14:37, Schuster Sebastian (INST/ESY1) wrote: > > Hi, > > > > I saw there are activities to replace client templates with client > scopes. UMA 2.0 uses the term ?client scope? to determine what the OAuth > client wants to do with the granted access (e.g. this could be used to > determine the purpose of processing some data for GDPR compliance). Since > Keycloak will also support UMA 2.0, I am a little concerned this might lead > to some confusion. As you know, there are only two hard problems in > computer science: cache invalidation, naming things, and off-by-one errors. > ? WDYT? > > > > Best regards, > > Sebastian > > > > Mit freundlichen Gr??en / Best regards > > > > Dr.-Ing. Sebastian Schuster > > > > Engineering and Support (INST/ESY1) > > Bosch Software Innovations GmbH | Ullsteinstr. 128 | 12109 Berlin | > GERMANY | www.bosch-si.com > > Tel. +49 30 726112-485 | Fax +49 30 726112-100 | > Sebastian.Schuster at bosch-si.com > > > > Sitz: Berlin, Registergericht: Amtsgericht Charlottenburg; HRB 148411 B > > Aufsichtsratsvorsitzender: Dr.-Ing. Thorsten L?cke; Gesch?ftsf?hrung: > Dr. Stefan Ferber, Michael Hahn > > > > > > > > _______________________________________________ > > keycloak-dev mailing list > > keycloak-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > From Sebastian.Schuster at bosch-si.com Thu Mar 15 08:11:20 2018 From: Sebastian.Schuster at bosch-si.com (Schuster Sebastian (INST/ESY1)) Date: Thu, 15 Mar 2018 12:11:20 +0000 Subject: [keycloak-dev] Client Scope naming In-Reply-To: References: Message-ID: <269bdfbf8f03404b898ceb42a2c45d86@bosch-si.com> I just checked the UMA 2.0 spec again and I found that the term ?client scope? is not used directly. It is just called scope but associated to the client and not the resource server, See section 3.3.1 Client Request to Authorization Server for RPT in : https://docs.kantarainitiative.org/uma/wg/rec-oauth-uma-grant-2.0.html scope OPTIONAL. A string of space-separated values representing requested scopes. For the authorization server to consider any requested scope in its assessment, the client MUST have been pre-registered for the same scope with the authorization server. The client should consult the resource server's API documentation for details about which scopes it can expect the resource server's initial returned permission ticket to represent as part of the authorization assessment (see Section 3.3.4). The resource server has its own set of scopes that is also used assess authorizations, see section 3.3.4 Authorization Assessment and Results Determination. I just fear the term ?scope? is a bit overused? Best regards, Sebastian Mit freundlichen Gr??en / Best regards Dr.-Ing. Sebastian Schuster Engineering and Support (INST/ESY1) Bosch Software Innovations GmbH | Ullsteinstr. 128 | 12109 Berlin | GERMANY | www.bosch-si.com Tel. +49 30 726112-485 | Fax +49 30 726112-100 | Sebastian.Schuster at bosch-si.com Sitz: Berlin, Registergericht: Amtsgericht Charlottenburg; HRB 148411 B Aufsichtsratsvorsitzender: Dr.-Ing. Thorsten L?cke; Gesch?ftsf?hrung: Dr. Stefan Ferber, Michael Hahn From: Pedro Igor Silva [mailto:psilva at redhat.com] Sent: Mittwoch, 14. M?rz 2018 21:01 To: Schuster Sebastian (INST/ESY1) Cc: keycloak-dev Subject: Re: [keycloak-dev] Client Scope naming I need to take a closer look on what Marek did around client scopes. So far, scopes were basically associated with roles and protocol mappers and that is not really what we need in UMA 2.0. If scopes now is more abstract and we can remove "authorization scopes" in authz services, I need to take a look ... In fact, I need to review scope parameter in UMA grant type in order to allow clients to push additional scopes other those already added in a ticket. On Wed, Mar 14, 2018 at 10:37 AM, Schuster Sebastian (INST/ESY1) > wrote: Hi, I saw there are activities to replace client templates with client scopes. UMA 2.0 uses the term ?client scope? to determine what the OAuth client wants to do with the granted access (e.g. this could be used to determine the purpose of processing some data for GDPR compliance). Since Keycloak will also support UMA 2.0, I am a little concerned this might lead to some confusion. As you know, there are only two hard problems in computer science: cache invalidation, naming things, and off-by-one errors. ? WDYT? Best regards, Sebastian Mit freundlichen Gr??en / Best regards Dr.-Ing. Sebastian Schuster Engineering and Support (INST/ESY1) Bosch Software Innovations GmbH | Ullsteinstr. 128 | 12109 Berlin | GERMANY | www.bosch-si.com Tel. +49 30 726112-485 | Fax +49 30 726112-100 | Sebastian.Schuster at bosch-si.com> Sitz: Berlin, Registergericht: Amtsgericht Charlottenburg; HRB 148411 B Aufsichtsratsvorsitzender: Dr.-Ing. Thorsten L?cke; Gesch?ftsf?hrung: Dr. Stefan Ferber, Michael Hahn _______________________________________________ keycloak-dev mailing list keycloak-dev at lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-dev From Sebastian.Schuster at bosch-si.com Thu Mar 15 08:13:17 2018 From: Sebastian.Schuster at bosch-si.com (Schuster Sebastian (INST/ESY1)) Date: Thu, 15 Mar 2018 12:13:17 +0000 Subject: [keycloak-dev] Initial client scopes PR In-Reply-To: <7d4da3f5-4e64-e1df-983d-4f14cdcb19d7@redhat.com> References: <7d4da3f5-4e64-e1df-983d-4f14cdcb19d7@redhat.com> Message-ID: <4e6e7b8cebaf46b6b310df956ce40c94@bosch-si.com> Is the long-term goal to make the "Scopes" tab for clients go away? Because currently it's a bit confusing both are there... Best regards, Sebastian Mit freundlichen Gr??en / Best regards Dr.-Ing. Sebastian Schuster Engineering and Support (INST/ESY1) Bosch?Software Innovations?GmbH | Ullsteinstr. 128 | 12109 Berlin | GERMANY | www.bosch-si.com Tel. +49 30 726112-485 | Fax +49 30 726112-100 | Sebastian.Schuster at bosch-si.com Sitz: Berlin, Registergericht: Amtsgericht Charlottenburg; HRB 148411 B Aufsichtsratsvorsitzender: Dr.-Ing. Thorsten L?cke; Gesch?ftsf?hrung: Dr. Stefan Ferber, Michael Hahn -----Original Message----- From: keycloak-dev-bounces at lists.jboss.org [mailto:keycloak-dev-bounces at lists.jboss.org] On Behalf Of Marek Posolda Sent: Mittwoch, 14. M?rz 2018 18:47 To: keycloak-dev at lists.jboss.org Subject: [keycloak-dev] Initial client scopes PR Hi, I've finally send PR https://github.com/keycloak/keycloak/pull/5076 for the first iteration of client scopes. I will talk on tomorrow call about the details and still need to write some more automated tests. But I am seing PR now if someone wants to take a look. Summary: - Client Templates were renamed to "Client Scopes". Some things were removed from the client template admin console (EG. Theme setting added recently). Also I've removed some ClientTemplate model properties, which were never used. Client Scope still has list of protocol mappers and list of "Scopes" (Roles scope mappings). - There is new tab "Client Scopes" on client. Here you can assign client scopes to client. Each client has 2 types of client scopes: -- Default client scopes -- Those client scopes are automatically applied when login with the client. Their protocol mappers and "Role scope mappings" are always used. -- Optional client scopes -- Those client scopes are applicable just for OIDC clients. They are used just if they are requested by "scope" parameter during login - Under "Client scopes", there is new tab "Default Client Scopes" . This allows to specify "Realm default client scopes" and "Realm optional client scopes". The scopes configured here will be added as default/optional scopes to new clients. Client can override this (Remove those defaults and add some different client scopes). So it works similarly to Default Roles. - Roles don't have "Scope Param Required" flag anymore. Protocol mappers don't have "Consent required" and "Consent text" anymore. Client scopes don't have "Full scope allowed" flag. But clients still have "Full scope allowed" flag for now and it's still ON by default for newly created clients. - There are few builtin client scopes added to each realm. There are 4 claims scopes defined in OIDC specification and those are added by default: "profile", "email", "address" and "phone" with the protocol mappers corresponding to the claims described in OIDC specification [1]. -- The "profile" and "email" are configured as default scopes and hence are automatically added to new clients. -- The "phone" and "address" are configured as optional scopes by default. -- The clients now doesn't have any protocolMappers added by default when they are created. I've added "profile" and "email" as default scopes due it's most close to the previous default protocolMappers we had. - For SAML, there is "role_list" default client scope, containing just 1 protocol mapper "role list". So both OIDC and SAML clients don't have any protocol mappers by default, it's driven by client scopes now by default. - There is "offline_access" OIDC client scope, which is optional scope by default. This scope contains just "offline_access" realm role. Due the fact, that parameter "Scope Param Required" was removed from RoleModel, the "offline_access" role is now automatically available in tokens for clients with "Full Scope Allowed", even if no offline tokens was requsted. But I don't think it's big issue besides a bit bigger token. Same also already applies for uma_authorization and some other built-in roles. The fact, that offline token is requested is now driven by "offline_access" scope. But user should still have "offline_access" role to be able to receive offline token. Consent changes: - Consent screen now doesn't display protocolMappers (claims) and roles, but instead it displays just client scopes. So by default, the consent screen contains 2 items "User profile" and "Email address", which correspond to the "profile" and "email" OIDC scopes. - There can be still the case, when client has some protocolMappers or role scope mappings defined on itself. So I've added flag "Display On Consent Screen" on clients (It's OFF by default) to specify if some message should be shown on consent screen about claims dedicated directly to client itself. It's useful especially when client doesn't have any client scopes as the consent screen wouldn't be displayed in that case. - During this refactoring, I've tried to do some cleanup we discussed before, so I've removed protocolMappers and roles from clientSession. Instead I've added clientScopes to refresh token. During refreshing token, it's checked that user still has all the consents, which are in the refresh token. So in case that user revoked consents in the meantime, the token refresh will fail. ProtocolMappers and scoped roles are always re-computed from the clientScopes. So if for example another claim was added to scope "profile", it will automatically be applied after refreshed token. I don't see an issue with that. User approved on consent screen scope "profile" and he may not be concerned what claims/scoped roles are in profile. - Migration: In the end I did not change existing clients and did not remove protocolMappers from them and didn't add default/optional client scopes to them. The only exception is "offline_access" profile, which is added as optional to all clients, which had scope to "offline_access" role. Consents are not migrated - again with the only exception being "offline_access" consent, so refreshing offline tokens from previous version still works. The new consent screen is something quite different than previous one, so makes sense to show it to users again when they want to login, even if they approved protocolMappers for the previous version. Sorry for long email and long PR :) More tomorrow... [1] http://openid.net/specs/openid-connect-core-1_0.html#ScopeClaims Marek _______________________________________________ keycloak-dev mailing list keycloak-dev at lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-dev From adesbiaux at vente-privee.com Thu Mar 15 08:16:08 2018 From: adesbiaux at vente-privee.com (Adrien DESBIAUX) Date: Thu, 15 Mar 2018 12:16:08 +0000 Subject: [keycloak-dev] Abstract User Adapter Federated Storage & Abstract Idp Authenticator Message-ID: Hi everyone, I would like to get some advices on how to use the "First broker login" flow combined with the Abstract User Adapter Federated Storage. That means the user is not by default in the local Keycloak DB. The users from the user federation are NOT imported into the local DB. Hence the use of the `AbstractUserAdapterFederatedStorage`. In the case of a Facebook login. The default flow is the "First broker login" flow. I did implement a custom Authenticator based on the default "First broker login". So in the `authenticateImpl` function, I would like a user login in with Facebook AND not in the User Federation (external DB) to be created the same way as it would be if it was via username/password. Long story short, I don't want to have `UserModel federatedUser = session.users().addUser(); federatedUser.setEnabled(true);` and `context.setUser(federatedUser);` but just exit success upon successfully user created on the remote storage. I did try to not execute those 2 steps however the auth keep failing with "User with ID not found". By looking at the source code of the `AbstractIdpAuthenticator.java` I found out https://github.com/keycloak/keycloak/blob/ee2d28d589ee62d0e0c0e35dd7bab4308b62faf6/services/src/main/java/org/keycloak/authentication/authenticators/broker/AbstractIdpAuthenticator.java#L129 So that means that if I do not execute the `addUser` and `setEnabled`, I will never be able to register a user from Facebook and complete the auth by using an external user federation? In short, I don't want to store any user locally when the user connect from Facebook, but the Keycloak source code looks like forcing it. Is it correct? I hope I was clear enough in my explanation.... I can provide more details if it is not so clear. Many thanks in advance for your enlightening on this. Regards, From psilva at redhat.com Thu Mar 15 08:21:42 2018 From: psilva at redhat.com (Pedro Igor Silva) Date: Thu, 15 Mar 2018 09:21:42 -0300 Subject: [keycloak-dev] Client Scope naming In-Reply-To: <269bdfbf8f03404b898ceb42a2c45d86@bosch-si.com> References: <269bdfbf8f03404b898ceb42a2c45d86@bosch-si.com> Message-ID: It is a pertinent concern. That scope parameters is something clients can use to ask for additional scopes after receiving a ticket (with can already some scopes defined by the RS). Right now the resource server is responsible for defining these scopes. The thing is that scopes in authz services can be anything and they don't really represent a access context. For instance, scopes can be actions you can perform on a resource, information about a resource, etc. I just checked UMA 2.0 grant type implementation and we are already considering any addition scope defined by the client using the "scope" parameter. On Thu, Mar 15, 2018 at 9:11 AM, Schuster Sebastian (INST/ESY1) < Sebastian.Schuster at bosch-si.com> wrote: > I just checked the UMA 2.0 spec again and I found that the term ?client > scope? is not used directly. It is just called scope but associated to the > client and not the resource server, > > See section 3.3.1 Client Request to Authorization Server for RPT in : > https://docs.kantarainitiative.org/uma/wg/rec-oauth-uma-grant-2.0.html > > > > scope > > OPTIONAL. A string of space-separated values representing requested > scopes. For the authorization server to consider any requested scope in its > assessment, the client MUST have been pre-registered for the same scope > with the authorization server. The client should consult the resource > server's API documentation for details about which scopes it can expect the > resource server's initial returned permission ticket to represent as part > of the authorization assessment (see Section 3.3.4). > > > > The resource server has its own set of scopes that is also used assess > authorizations, see section 3.3.4 Authorization Assessment and Results > Determination. > > > > I just fear the term ?scope? is a bit overused? > > > > Best regards, > > Sebastian > > > > > > Mit freundlichen Gr??en / Best regards > > > *Dr.-Ing. Sebastian Schuster * > Engineering and Support (INST/ESY1) > Bosch Software Innovations GmbH | Ullsteinstr. 128 | 12109 Berlin | > > GERMANY | www.bosch-si.com > Tel. +49 30 726112-485 <+49%2030%20726112485> | Fax +49 30 726112-100 > <+49%2030%20726112100> | Sebastian.Schuster at bosch-si.com > > Sitz: Berlin, Registergericht: Amtsgericht Charlottenburg; HRB 148411 B > Aufsichtsratsvorsitzender: Dr.-Ing. Thorsten L?cke; Gesch?ftsf?hrung: Dr. > Stefan Ferber, Michael Hahn > > > > *From:* Pedro Igor Silva [mailto:psilva at redhat.com] > *Sent:* Mittwoch, 14. M?rz 2018 21:01 > *To:* Schuster Sebastian (INST/ESY1) > *Cc:* keycloak-dev > *Subject:* Re: [keycloak-dev] Client Scope naming > > > > I need to take a closer look on what Marek did around client scopes. So > far, scopes were basically associated with roles and protocol mappers and > that is not really what we need in UMA 2.0. > > > > If scopes now is more abstract and we can remove "authorization scopes" in > authz services, I need to take a look ... > > > > In fact, I need to review scope parameter in UMA grant type in order to > allow clients to push additional scopes other those already added in a > ticket. > > > > On Wed, Mar 14, 2018 at 10:37 AM, Schuster Sebastian (INST/ESY1) < > Sebastian.Schuster at bosch-si.com> wrote: > > Hi, > > I saw there are activities to replace client templates with client scopes. > UMA 2.0 uses the term ?client scope? to determine what the OAuth client > wants to do with the granted access (e.g. this could be used to determine > the purpose of processing some data for GDPR compliance). Since Keycloak > will also support UMA 2.0, I am a little concerned this might lead to some > confusion. As you know, there are only two hard problems in computer > science: cache invalidation, naming things, and off-by-one errors. ? WDYT? > > Best regards, > Sebastian > > Mit freundlichen Gr??en / Best regards > > Dr.-Ing. Sebastian Schuster > > Engineering and Support (INST/ESY1) > Bosch Software Innovations GmbH | Ullsteinstr. 128 | 12109 Berlin | > GERMANY | www.bosch-si.com > Tel. +49 30 726112-485 | Fax +49 30 726112-100 | > Sebastian.Schuster at bosch-si.com > > Sitz: Berlin, Registergericht: Amtsgericht Charlottenburg; HRB 148411 B > Aufsichtsratsvorsitzender: Dr.-Ing. Thorsten L?cke; Gesch?ftsf?hrung: Dr. > Stefan Ferber, Michael Hahn > > > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > From bburke at redhat.com Thu Mar 15 10:41:56 2018 From: bburke at redhat.com (Bill Burke) Date: Thu, 15 Mar 2018 10:41:56 -0400 Subject: [keycloak-dev] kcinit console sso tool In-Reply-To: References: Message-ID: On Wed, Mar 14, 2018 at 3:15 PM, Stian Thorgersen wrote: > > > On 12 March 2018 at 18:59, Bill Burke wrote: >> >> On Mon, Mar 12, 2018 at 10:16 AM, Stian Thorgersen >> wrote: >> > Very cool. A few questions/comments: >> > >> > * As it's Java based it does make it harder to package/install. Compare >> > 'oc' >> > tool for instance to our 'kcadmin' and 'kcclient' tools. Not sure how >> > realistic it would be to write our CLI tools in for instance Go though. >> > >> >> Its a pretty simple tool so it could be ported. The only thing that >> might be a tiny bit challenging is making sure there's crypto stuff >> available in another language to encrypt/decrypt token files. Might >> be a nice little project for me to learn Go. >> >> > * I assume the console display is optional and it basically means that >> > you >> > can only use authenticators that support this rather than all >> > authenticators >> > require to implement it. >> > >> >> I don't have a switch to launch browser, but, I could as this >> functionality is already implemented. Not sure if that would be >> portable to Go or another language though. Java has a facility to >> automatically launch browser (I think you know that already as you >> wrote KeycloakInstalled). > > > That would be pretty cool, but I wasn't thinking that far. I was just > basically thinking that authenticators has to be written to support this, > rather than all authenticators have to support this. Pretty cool? LOL! You implemented the browser stuff! Its not a requirement to support this when writing an authenticator. > > I got no clue how they work, but what I meant is the fact that ssh-agent > allows you to unlock the keys automatically when you login to your browser. > > If you have to provide a password to unlock the tokens every time you open a > new shell does it actually provide a nicer experience than just doing > username/password to login again with resource owner credential grant? > I agree it sucks. I think I'm going to get rid of password protection for now. I researched things a bit last night, and at least for Golang, there is a cross-platform library for storing passwords in the OS's keyring that might be useful. https://github.com/zalando/go-keyring I'll look into that when I port this tool to Go. -- Bill Burke Red Hat From aszczucz at redhat.com Thu Mar 15 10:50:28 2018 From: aszczucz at redhat.com (Alex Szczuczko) Date: Thu, 15 Mar 2018 08:50:28 -0600 Subject: [keycloak-dev] Using Fedora community services to relay GitHub events Message-ID: <152112542832.19829.4198768877335064200@tyrfing> Hi, The "Stable CI for Keycloak PRs" (KEYCLOAK-6176) epic team is developing a bot. This information could be useful for that bot. keycloak-docs-bot (ASzc/dawbrn) is written around webhooks, and I imagine the CI bot is too. However, when I needed to deploy I hit this problem: - Only internet-facing systems can receive webhooks - Internet-facing systems are in limited supply within Red Hat - Almost always these systems can't access the internal network I solved the problem by deploying the bot on a private VPS, but that's less than ideal for many reasons. I don't know how the Stable CI team has solved / plans to solve this, but just yesterday I discovered a better solution. The Fedora community has a message bus called fedmsg[1], based on ZeroMQ. They also have a service[2] that bridges GitHub events to fedmsg. For example, see this[3] live feed of PR open events. Anyone with a Fedora account can register their GitHub repos with github2fedmsg, and anyone can listen to fedmsg. So, we could host all our stuff internally and still get push events by listening to fedmsg! Do you think your bot could benefit from this, Pavel and Bruno? Alex [1] http://fedora-fedmsg.readthedocs.io/en/latest/index.html [2] https://apps.fedoraproject.org/github2fedmsg [3] https://apps.fedoraproject.org/datagrepper/raw?topic=org.fedoraproject.prod.github.pull_request.opened From bruno at abstractj.org Thu Mar 15 11:30:39 2018 From: bruno at abstractj.org (Bruno Oliveira) Date: Thu, 15 Mar 2018 15:30:39 +0000 Subject: [keycloak-dev] Using Fedora community services to relay GitHub events In-Reply-To: <152112542832.19829.4198768877335064200@tyrfing> References: <152112542832.19829.4198768877335064200@tyrfing> Message-ID: TBH I never tried, but it looks interesting. I suggest to file a Jira as spike for R&D in this way the team can discuss, evaluate and prioritize. Thanks for sharing Alex. On Thu, Mar 15, 2018 at 12:01 PM Alex Szczuczko wrote: > Hi, > > The "Stable CI for Keycloak PRs" (KEYCLOAK-6176) epic team is developing > a bot. This information could be useful for that bot. > > keycloak-docs-bot (ASzc/dawbrn) is written around webhooks, and I > imagine the CI bot is too. However, when I needed to deploy I hit this > problem: > > - Only internet-facing systems can receive webhooks > - Internet-facing systems are in limited supply within Red Hat > - Almost always these systems can't access the internal network > > I solved the problem by deploying the bot on a private VPS, but that's > less than ideal for many reasons. I don't know how the Stable CI team > has solved / plans to solve this, but just yesterday I discovered a > better solution. > > The Fedora community has a message bus called fedmsg[1], based on > ZeroMQ. They also have a service[2] that bridges GitHub events to > fedmsg. For example, see this[3] live feed of PR open events. > > Anyone with a Fedora account can register their GitHub repos with > github2fedmsg, and anyone can listen to fedmsg. So, we could host all > our stuff internally and still get push events by listening to fedmsg! > > Do you think your bot could benefit from this, Pavel and Bruno? > > Alex > > [1] http://fedora-fedmsg.readthedocs.io/en/latest/index.html > [2] https://apps.fedoraproject.org/github2fedmsg > [3] > https://apps.fedoraproject.org/datagrepper/raw?topic=org.fedoraproject.prod.github.pull_request.opened > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > From aszczucz at redhat.com Thu Mar 15 17:51:11 2018 From: aszczucz at redhat.com (Alex Szczuczko) Date: Thu, 15 Mar 2018 15:51:11 -0600 Subject: [keycloak-dev] Using Fedora community services to relay GitHub events In-Reply-To: References: <152112542832.19829.4198768877335064200@tyrfing> Message-ID: <152115067138.23247.2645035408336444659@tyrfing> Ok, I've filed it in your backlog: https://issues.jboss.org/browse/KEYCLOAK-6854 Alex Quoting Bruno Oliveira (2018-03-15 09:30:39) > TBH I never tried, but it looks interesting. I suggest to file a Jira as > spike for R&D in this way the team can discuss, evaluate and prioritize. > > Thanks for sharing Alex. From pdrozd at redhat.com Fri Mar 16 02:36:33 2018 From: pdrozd at redhat.com (Pavel Drozd) Date: Fri, 16 Mar 2018 07:36:33 +0100 Subject: [keycloak-dev] Using Fedora community services to relay GitHub events In-Reply-To: <152115067138.23247.2645035408336444659@tyrfing> References: <152112542832.19829.4198768877335064200@tyrfing> <152115067138.23247.2645035408336444659@tyrfing> Message-ID: <5AAB65F1.1050801@redhat.com> Thanks Alex, it seems really interesting... Dne 15.3.2018 v 22:51 Alex Szczuczko napsal(a): > Ok, I've filed it in your backlog: > > https://issues.jboss.org/browse/KEYCLOAK-6854 > > Alex > > Quoting Bruno Oliveira (2018-03-15 09:30:39) >> TBH I never tried, but it looks interesting. I suggest to file a Jira as >> spike for R&D in this way the team can discuss, evaluate and prioritize. >> >> Thanks for sharing Alex. From mposolda at redhat.com Fri Mar 16 03:46:19 2018 From: mposolda at redhat.com (Marek Posolda) Date: Fri, 16 Mar 2018 08:46:19 +0100 Subject: [keycloak-dev] Client Scope naming In-Reply-To: References: <6109ae10-65be-5c45-8a9e-bd4f79c034bc@redhat.com> Message-ID: Scope parameter would reference client scopes. For example scope parameter "openid email profile offline_access" will reference client scopes "email", "profile" and "offline_access" (openid is jsut generic OpenID Connect marker).? And each client scope is set of protocolMappers and/or Role scope mappings. Marek On 15/03/18 12:39, Pedro Igor Silva wrote: > How a scope looks like now after your changes ? Are they just strings > referencing a set of one or more roles ? Or they are still roles ? > > On Wed, Mar 14, 2018 at 5:03 PM, Marek Posolda > wrote: > > That's good question. As you know, we also have "Scope" tab (used to > specify scope role mappings of client) and "Authorization scope", > which > is used when Authorization is enabled :) > > Marek > > On 14/03/18 14:37, Schuster Sebastian (INST/ESY1) wrote: > > Hi, > > > > I saw there are activities to replace client templates with > client scopes. UMA 2.0 uses the term ?client scope? to determine > what the OAuth client wants to do with the granted access (e.g. > this could be used to determine the purpose of processing some > data for GDPR compliance). Since Keycloak will also support UMA > 2.0, I am a little concerned this might lead to some confusion. As > you know, there are only two hard problems in computer science: > cache invalidation, naming things, and off-by-one errors. ? WDYT? > > > > Best regards, > > Sebastian > > > > Mit freundlichen Gr??en / Best regards > > > > Dr.-Ing. Sebastian Schuster > > > > Engineering and Support (INST/ESY1) > > Bosch Software Innovations GmbH | Ullsteinstr. 128 | 12109 > Berlin | GERMANY | www.bosch-si.com > > > > Tel. +49 30 726112-485 | Fax +49 > 30 726112-100 | > Sebastian.Schuster at bosch-si.com > > > > > > Sitz: Berlin, Registergericht: Amtsgericht Charlottenburg; HRB > 148411 B > > Aufsichtsratsvorsitzender: Dr.-Ing. Thorsten L?cke; > Gesch?ftsf?hrung: Dr. Stefan Ferber, Michael Hahn > > > > > > > > _______________________________________________ > > keycloak-dev mailing list > > keycloak-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > From sthorger at redhat.com Fri Mar 16 03:48:14 2018 From: sthorger at redhat.com (Stian Thorgersen) Date: Fri, 16 Mar 2018 08:48:14 +0100 Subject: [keycloak-dev] kcinit console sso tool In-Reply-To: References: Message-ID: On 15 March 2018 at 15:41, Bill Burke wrote: > On Wed, Mar 14, 2018 at 3:15 PM, Stian Thorgersen > wrote: > > > > > > On 12 March 2018 at 18:59, Bill Burke wrote: > >> > >> On Mon, Mar 12, 2018 at 10:16 AM, Stian Thorgersen > > >> wrote: > >> > Very cool. A few questions/comments: > >> > > >> > * As it's Java based it does make it harder to package/install. > Compare > >> > 'oc' > >> > tool for instance to our 'kcadmin' and 'kcclient' tools. Not sure how > >> > realistic it would be to write our CLI tools in for instance Go > though. > >> > > >> > >> Its a pretty simple tool so it could be ported. The only thing that > >> might be a tiny bit challenging is making sure there's crypto stuff > >> available in another language to encrypt/decrypt token files. Might > >> be a nice little project for me to learn Go. > >> > >> > * I assume the console display is optional and it basically means that > >> > you > >> > can only use authenticators that support this rather than all > >> > authenticators > >> > require to implement it. > >> > > >> > >> I don't have a switch to launch browser, but, I could as this > >> functionality is already implemented. Not sure if that would be > >> portable to Go or another language though. Java has a facility to > >> automatically launch browser (I think you know that already as you > >> wrote KeycloakInstalled). > > > > > > That would be pretty cool, but I wasn't thinking that far. I was just > > basically thinking that authenticators has to be written to support this, > > rather than all authenticators have to support this. > > Pretty cool? LOL! You implemented the browser stuff! > What I meant was if there was some fallback where the browser would be opened to continue the flow in case there is an authenticator that doesn't have this, but as you say since you can't close the window automatically it's kinda awkward. > > Its not a requirement to support this when writing an authenticator. > > > > > > I got no clue how they work, but what I meant is the fact that ssh-agent > > allows you to unlock the keys automatically when you login to your > browser. > > > > If you have to provide a password to unlock the tokens every time you > open a > > new shell does it actually provide a nicer experience than just doing > > username/password to login again with resource owner credential grant? > > > > I agree it sucks. I think I'm going to get rid of password protection > for now. I researched things a bit last night, and at least for > Golang, there is a cross-platform library for storing passwords in the > OS's keyring that might be useful. > > https://github.com/zalando/go-keyring > > I'll look into that when I port this tool to Go. > > -- > Bill Burke > Red Hat > From mposolda at redhat.com Fri Mar 16 03:48:29 2018 From: mposolda at redhat.com (Marek Posolda) Date: Fri, 16 Mar 2018 08:48:29 +0100 Subject: [keycloak-dev] Initial client scopes PR In-Reply-To: <4e6e7b8cebaf46b6b310df956ce40c94@bosch-si.com> References: <7d4da3f5-4e64-e1df-983d-4f14cdcb19d7@redhat.com> <4e6e7b8cebaf46b6b310df956ce40c94@bosch-si.com> Message-ID: <5ab0dee4-281a-d8ba-2dea-933d1e2214c8@redhat.com> It's not yet clear... Maybe we can rename tab to "Role Scopes"? Will it be clearer or even more confusing? :) Marek On 15/03/18 13:13, Schuster Sebastian (INST/ESY1) wrote: > Is the long-term goal to make the "Scopes" tab for clients go away? Because currently it's a bit confusing both are there... > > Best regards, > Sebastian > > Mit freundlichen Gr??en / Best regards > > Dr.-Ing. Sebastian Schuster > > Engineering and Support (INST/ESY1) > Bosch?Software Innovations?GmbH | Ullsteinstr. 128 | 12109 Berlin | GERMANY | www.bosch-si.com > Tel. +49 30 726112-485 | Fax +49 30 726112-100 | Sebastian.Schuster at bosch-si.com > > Sitz: Berlin, Registergericht: Amtsgericht Charlottenburg; HRB 148411 B > Aufsichtsratsvorsitzender: Dr.-Ing. Thorsten L?cke; Gesch?ftsf?hrung: Dr. Stefan Ferber, Michael Hahn > > > > > -----Original Message----- > From: keycloak-dev-bounces at lists.jboss.org [mailto:keycloak-dev-bounces at lists.jboss.org] On Behalf Of Marek Posolda > Sent: Mittwoch, 14. M?rz 2018 18:47 > To: keycloak-dev at lists.jboss.org > Subject: [keycloak-dev] Initial client scopes PR > > Hi, > > I've finally send PR https://github.com/keycloak/keycloak/pull/5076 for the first iteration of client scopes. I will talk on tomorrow call about the details and still need to write some more automated tests. But I am seing PR now if someone wants to take a look. > > Summary: > > - Client Templates were renamed to "Client Scopes". Some things were removed from the client template admin console (EG. Theme setting added recently). Also I've removed some ClientTemplate model properties, which were never used. Client Scope still has list of protocol mappers and list of "Scopes" (Roles scope mappings). > > > - There is new tab "Client Scopes" on client. Here you can assign client scopes to client. Each client has 2 types of client scopes: > -- Default client scopes -- Those client scopes are automatically applied when login with the client. Their protocol mappers and "Role scope mappings" are always used. > -- Optional client scopes -- Those client scopes are applicable just for OIDC clients. They are used just if they are requested by "scope" > parameter during login > > > - Under "Client scopes", there is new tab "Default Client Scopes" . This allows to specify "Realm default client scopes" and "Realm optional client scopes". The scopes configured here will be added as default/optional scopes to new clients. Client can override this (Remove those defaults and add some different client scopes). So it works similarly to Default Roles. > > > - Roles don't have "Scope Param Required" flag anymore. Protocol mappers don't have "Consent required" and "Consent text" anymore. Client scopes don't have "Full scope allowed" flag. But clients still have "Full scope allowed" flag for now and it's still ON by default for newly created clients. > > - There are few builtin client scopes added to each realm. There are 4 claims scopes defined in OIDC specification and those are added by > default: "profile", "email", "address" and "phone" with the protocol mappers corresponding to the claims described in OIDC specification [1]. > -- The "profile" and "email" are configured as default scopes and hence are automatically added to new clients. > -- The "phone" and "address" are configured as optional scopes by default. > -- The clients now doesn't have any protocolMappers added by default when they are created. I've added "profile" and "email" as default scopes due it's most close to the previous default protocolMappers we had. > > - For SAML, there is "role_list" default client scope, containing just 1 protocol mapper "role list". So both OIDC and SAML clients don't have any protocol mappers by default, it's driven by client scopes now by default. > > - There is "offline_access" OIDC client scope, which is optional scope by default. This scope contains just "offline_access" realm role. Due the fact, that parameter "Scope Param Required" was removed from RoleModel, the "offline_access" role is now automatically available in tokens for clients with "Full Scope Allowed", even if no offline tokens was requsted. But I don't think it's big issue besides a bit bigger token. Same also already applies for uma_authorization and some other built-in roles. The fact, that offline token is requested is now driven by "offline_access" scope. But user should still have "offline_access" > role to be able to receive offline token. > > Consent changes: > - Consent screen now doesn't display protocolMappers (claims) and roles, but instead it displays just client scopes. So by default, the consent screen contains 2 items "User profile" and "Email address", which correspond to the "profile" and "email" OIDC scopes. > > - There can be still the case, when client has some protocolMappers or role scope mappings defined on itself. So I've added flag "Display On Consent Screen" on clients (It's OFF by default) to specify if some message should be shown on consent screen about claims dedicated directly to client itself. It's useful especially when client doesn't have any client scopes as the consent screen wouldn't be displayed in that case. > > - During this refactoring, I've tried to do some cleanup we discussed before, so I've removed protocolMappers and roles from clientSession. > Instead I've added clientScopes to refresh token. During refreshing token, it's checked that user still has all the consents, which are in the refresh token. So in case that user revoked consents in the meantime, the token refresh will fail. ProtocolMappers and scoped roles are always re-computed from the clientScopes. So if for example another claim was added to scope "profile", it will automatically be applied after refreshed token. I don't see an issue with that. User approved on consent screen scope "profile" and he may not be concerned what claims/scoped roles are in profile. > > - Migration: In the end I did not change existing clients and did not remove protocolMappers from them and didn't add default/optional client scopes to them. The only exception is "offline_access" profile, which is added as optional to all clients, which had scope to "offline_access" > role. Consents are not migrated - again with the only exception being "offline_access" consent, so refreshing offline tokens from previous version still works. The new consent screen is something quite different than previous one, so makes sense to show it to users again when they want to login, even if they approved protocolMappers for the previous version. > > Sorry for long email and long PR :) More tomorrow... > > > [1] http://openid.net/specs/openid-connect-core-1_0.html#ScopeClaims > > Marek > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev From Sebastian.Schuster at bosch-si.com Fri Mar 16 04:15:39 2018 From: Sebastian.Schuster at bosch-si.com (Schuster Sebastian (INST/ESY1)) Date: Fri, 16 Mar 2018 08:15:39 +0000 Subject: [keycloak-dev] Initial client scopes PR In-Reply-To: <5ab0dee4-281a-d8ba-2dea-933d1e2214c8@redhat.com> References: <7d4da3f5-4e64-e1df-983d-4f14cdcb19d7@redhat.com> <4e6e7b8cebaf46b6b310df956ce40c94@bosch-si.com> <5ab0dee4-281a-d8ba-2dea-933d1e2214c8@redhat.com> Message-ID: <1413563e2fde41ab9c47dbad6b6c5596@bosch-si.com> Doesn't the current client scope functionality cover everything that was possible on the scopes tab, except for the ability to simply allow all scopes for a client? Then my proposal would be to add that functionality to the "client scope" tab and call it "scope" tab again, and maybe rename the menu on the left to "scope mappings" or also just "scopes". Best regards, Sebastian Mit freundlichen Gr??en / Best regards Dr.-Ing. Sebastian Schuster Engineering and Support (INST/ESY1) Bosch?Software Innovations?GmbH | Ullsteinstr. 128 | 12109 Berlin | GERMANY | www.bosch-si.com Tel. +49 30 726112-485 | Fax +49 30 726112-100 | Sebastian.Schuster at bosch-si.com Sitz: Berlin, Registergericht: Amtsgericht Charlottenburg; HRB 148411 B Aufsichtsratsvorsitzender: Dr.-Ing. Thorsten L?cke; Gesch?ftsf?hrung: Dr. Stefan Ferber, Michael Hahn -----Original Message----- From: Marek Posolda [mailto:mposolda at redhat.com] Sent: Freitag, 16. M?rz 2018 08:48 To: Schuster Sebastian (INST/ESY1) ; keycloak-dev at lists.jboss.org Subject: Re: [keycloak-dev] Initial client scopes PR It's not yet clear... Maybe we can rename tab to "Role Scopes"? Will it be clearer or even more confusing? :) Marek On 15/03/18 13:13, Schuster Sebastian (INST/ESY1) wrote: > Is the long-term goal to make the "Scopes" tab for clients go away? Because currently it's a bit confusing both are there... > > Best regards, > Sebastian > > Mit freundlichen Gr??en / Best regards > > Dr.-Ing. Sebastian Schuster > > Engineering and Support (INST/ESY1) > Bosch?Software Innovations?GmbH | Ullsteinstr. 128 | 12109 Berlin | > GERMANY | www.bosch-si.com Tel. +49 30 726112-485 | Fax +49 30 > 726112-100 | Sebastian.Schuster at bosch-si.com > > Sitz: Berlin, Registergericht: Amtsgericht Charlottenburg; HRB 148411 > B > Aufsichtsratsvorsitzender: Dr.-Ing. Thorsten L?cke; Gesch?ftsf?hrung: > Dr. Stefan Ferber, Michael Hahn > > > > > -----Original Message----- > From: keycloak-dev-bounces at lists.jboss.org > [mailto:keycloak-dev-bounces at lists.jboss.org] On Behalf Of Marek > Posolda > Sent: Mittwoch, 14. M?rz 2018 18:47 > To: keycloak-dev at lists.jboss.org > Subject: [keycloak-dev] Initial client scopes PR > > Hi, > > I've finally send PR https://github.com/keycloak/keycloak/pull/5076 for the first iteration of client scopes. I will talk on tomorrow call about the details and still need to write some more automated tests. But I am seing PR now if someone wants to take a look. > > Summary: > > - Client Templates were renamed to "Client Scopes". Some things were removed from the client template admin console (EG. Theme setting added recently). Also I've removed some ClientTemplate model properties, which were never used. Client Scope still has list of protocol mappers and list of "Scopes" (Roles scope mappings). > > > - There is new tab "Client Scopes" on client. Here you can assign client scopes to client. Each client has 2 types of client scopes: > -- Default client scopes -- Those client scopes are automatically applied when login with the client. Their protocol mappers and "Role scope mappings" are always used. > -- Optional client scopes -- Those client scopes are applicable just for OIDC clients. They are used just if they are requested by "scope" > parameter during login > > > - Under "Client scopes", there is new tab "Default Client Scopes" . This allows to specify "Realm default client scopes" and "Realm optional client scopes". The scopes configured here will be added as default/optional scopes to new clients. Client can override this (Remove those defaults and add some different client scopes). So it works similarly to Default Roles. > > > - Roles don't have "Scope Param Required" flag anymore. Protocol mappers don't have "Consent required" and "Consent text" anymore. Client scopes don't have "Full scope allowed" flag. But clients still have "Full scope allowed" flag for now and it's still ON by default for newly created clients. > > - There are few builtin client scopes added to each realm. There are 4 > claims scopes defined in OIDC specification and those are added by > default: "profile", "email", "address" and "phone" with the protocol mappers corresponding to the claims described in OIDC specification [1]. > -- The "profile" and "email" are configured as default scopes and hence are automatically added to new clients. > -- The "phone" and "address" are configured as optional scopes by default. > -- The clients now doesn't have any protocolMappers added by default when they are created. I've added "profile" and "email" as default scopes due it's most close to the previous default protocolMappers we had. > > - For SAML, there is "role_list" default client scope, containing just 1 protocol mapper "role list". So both OIDC and SAML clients don't have any protocol mappers by default, it's driven by client scopes now by default. > > - There is "offline_access" OIDC client scope, which is optional scope by default. This scope contains just "offline_access" realm role. Due the fact, that parameter "Scope Param Required" was removed from RoleModel, the "offline_access" role is now automatically available in tokens for clients with "Full Scope Allowed", even if no offline tokens was requsted. But I don't think it's big issue besides a bit bigger token. Same also already applies for uma_authorization and some other built-in roles. The fact, that offline token is requested is now driven by "offline_access" scope. But user should still have "offline_access" > role to be able to receive offline token. > > Consent changes: > - Consent screen now doesn't display protocolMappers (claims) and roles, but instead it displays just client scopes. So by default, the consent screen contains 2 items "User profile" and "Email address", which correspond to the "profile" and "email" OIDC scopes. > > - There can be still the case, when client has some protocolMappers or role scope mappings defined on itself. So I've added flag "Display On Consent Screen" on clients (It's OFF by default) to specify if some message should be shown on consent screen about claims dedicated directly to client itself. It's useful especially when client doesn't have any client scopes as the consent screen wouldn't be displayed in that case. > > - During this refactoring, I've tried to do some cleanup we discussed before, so I've removed protocolMappers and roles from clientSession. > Instead I've added clientScopes to refresh token. During refreshing token, it's checked that user still has all the consents, which are in the refresh token. So in case that user revoked consents in the meantime, the token refresh will fail. ProtocolMappers and scoped roles are always re-computed from the clientScopes. So if for example another claim was added to scope "profile", it will automatically be applied after refreshed token. I don't see an issue with that. User approved on consent screen scope "profile" and he may not be concerned what claims/scoped roles are in profile. > > - Migration: In the end I did not change existing clients and did not remove protocolMappers from them and didn't add default/optional client scopes to them. The only exception is "offline_access" profile, which is added as optional to all clients, which had scope to "offline_access" > role. Consents are not migrated - again with the only exception being "offline_access" consent, so refreshing offline tokens from previous version still works. The new consent screen is something quite different than previous one, so makes sense to show it to users again when they want to login, even if they approved protocolMappers for the previous version. > > Sorry for long email and long PR :) More tomorrow... > > > [1] http://openid.net/specs/openid-connect-core-1_0.html#ScopeClaims > > Marek > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev From adr_gonzalez at yahoo.fr Fri Mar 16 04:24:11 2018 From: adr_gonzalez at yahoo.fr (Adrian Gonzalez) Date: Fri, 16 Mar 2018 08:24:11 +0000 (UTC) Subject: [keycloak-dev] KEYCLOAK-4509: OIDC IDP initiated login References: <913790288.2428684.1521188651382.ref@mail.yahoo.com> Message-ID: <913790288.2428684.1521188651382@mail.yahoo.com> Hello, I would like to raise a thread on OIDC IDP initiated login (or OIDC third party initiated login). KC supports only SAML Clients for IDP Initiated login (http://www.keycloak.org/docs/latest/server_admin/index.html#idp-initiated-login).When I have an OIDC app, I cannot use this feature.The need has been raised in?KEYCLOAK-4509. I created an ugly PR to implement this feature, my use case is described in [1].In this implementation, I : - configured?IDP initiated SAML between KC and external IDP- and hacked the code to test if the destination app was OIDC. If it was OIDC, then KC makes a plain redirect to the RP app (see also [1]).This allows SAML initiated IDP and conversion to OIDC app. We could implement that by relying on OIDC 3rd party initiated login.See? [3]?on how this *could* work.This would allow OIDC third party initiated IDP for OIDC app (but this isn't enough for having SAML initiated IDP for an OIDC app - perhaps there's a solution for handling both OIDC 3rd party ). wdyt ? Cheers,Adrian [1] https://github.com/keycloak/keycloak/pull/4965#issuecomment-373578277.[2]?http://openid.net/specs/openid-connect-core-1_0.html#ThirdPartyInitiatedLogin[3]?https://github.com/keycloak/keycloak/pull/4965#issuecomment-373580906[4]?https://issues.jboss.org/browse/KEYCLOAK-4509 ? | | Garanti sans virus. www.avg.com | From mposolda at redhat.com Fri Mar 16 04:24:38 2018 From: mposolda at redhat.com (Marek Posolda) Date: Fri, 16 Mar 2018 09:24:38 +0100 Subject: [keycloak-dev] Abstract User Adapter Federated Storage & Abstract Idp Authenticator In-Reply-To: References: Message-ID: <11b1d2b6-fae3-c227-7dcb-73a6497fb4b7@redhat.com> On 15/03/18 13:16, Adrien DESBIAUX wrote: > Hi everyone, > > I would like to get some advices on how to use the "First broker login" flow combined with the Abstract User Adapter Federated Storage. > > That means the user is not by default in the local Keycloak DB. > The users from the user federation are NOT imported into the local DB. > Hence the use of the `AbstractUserAdapterFederatedStorage`. > > In the case of a Facebook login. The default flow is the "First broker login" flow. > I did implement a custom Authenticator based on the default "First broker login". > > So in the `authenticateImpl` function, I would like a user login in with Facebook AND not in the User Federation (external DB) to be created the same way as it would be if it was via username/password. > Long story short, I don't want to have `UserModel federatedUser = session.users().addUser(); federatedUser.setEnabled(true);` and `context.setUser(federatedUser);` but just exit success upon successfully user created on the remote storage. > I did try to not execute those 2 steps however the auth keep failing with "User with ID not found". > > By looking at the source code of the `AbstractIdpAuthenticator.java` I found out https://github.com/keycloak/keycloak/blob/ee2d28d589ee62d0e0c0e35dd7bab4308b62faf6/services/src/main/java/org/keycloak/authentication/authenticators/broker/AbstractIdpAuthenticator.java#L129 > > So that means that if I do not execute the `addUser` and `setEnabled`, I will never be able to register a user from Facebook and complete the auth by using an external user federation? > > In short, I don't want to store any user locally when the user connect from Facebook, but the Keycloak source code looks like forcing it. > Is it correct? Yes, at this moment :( We have some JIRAs to improve this. But I think that with using of some custom authenticators and custom user federated storage, you can already achieve it. For example in the source you pointed (AbstractIdpAuthenticator) there is this: UserModel existingUser = session.users().getUserById(duplication.getExistingUserId(), realm); if (!existingUser.isEnabled()) { throw new AuthenticationFlowException("User with ID '" + existingUserId + "', username '" + existingUser.getUsername() + "' disabled.", AuthenticationFlowError.USER_DISABLED); } If you implement your userStorage in a way, that "existingUser.isEnabled" will return true for the previously "added" users, you should be fine. It's maybe just about some tweaks needed. From what you mentioned, you are maybe not so far from make it working... Marek > > I hope I was clear enough in my explanation.... > I can provide more details if it is not so clear. > > Many thanks in advance for your enlightening on this. > > Regards, > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev From Sebastian.Schuster at bosch-si.com Fri Mar 16 04:51:05 2018 From: Sebastian.Schuster at bosch-si.com (Schuster Sebastian (INST/ESY1)) Date: Fri, 16 Mar 2018 08:51:05 +0000 Subject: [keycloak-dev] we do not support offline tokens In-Reply-To: References: <64f691b3212f4603b6ec7f15c189cff5@bosch-si.com> Message-ID: <94c7ca4f47bb400184c789354749d5ba@bosch-si.com> Gives bearer (limited) access...does not expire...sounds like an API Key to me. It is simpler but you also lose some of the benefits: it needs to be resolved, the resource server might have to cache resolution information for efficiency reasons. So this is just another tradeoff one can make... Btw. are there any plans to also support reference tokens (expiring or non-expiring)? They do have some advantages when it comes to security/privacy... Best regards, Sebastian P.S.: Is handling token lifetimes or refresh tokens really such an issue? Any decent OAuth2 library should be able to handle this properly... Mit freundlichen Gr??en / Best regards Dr.-Ing. Sebastian Schuster Engineering and Support (INST/ESY1) Bosch?Software Innovations?GmbH | Ullsteinstr. 128 | 12109 Berlin | GERMANY | www.bosch-si.com Tel. +49 30 726112-485 | Fax +49 30 726112-100 | Sebastian.Schuster at bosch-si.com Sitz: Berlin, Registergericht: Amtsgericht Charlottenburg; HRB 148411 B Aufsichtsratsvorsitzender: Dr.-Ing. Thorsten L?cke; Gesch?ftsf?hrung: Dr. Stefan Ferber, Michael Hahn -----Original Message----- From: Bill Burke [mailto:bburke at redhat.com] Sent: Donnerstag, 15. M?rz 2018 03:13 To: Stian Thorgersen Cc: Pedro Igor Silva ; Schuster Sebastian (INST/ESY1) ; keycloak-dev Subject: Re: [keycloak-dev] we do not support offline tokens On Wed, Mar 14, 2018 at 3:07 PM, Stian Thorgersen wrote: > I think the short tokens issued by the likes of OpenShift is primarily > used for authentication, not access. As such it's more a short ID > token than an actual access token. > This is just not how it works. Service Account tokens in Openshift/Kubernetes can be used as bearer tokens. Services that receive these bearer tokens call a validation endpoint (token review). The validation endpoint returns a JSON document with user info and group membership. Kubernetes additionally has a Authorization endpoint that can be invoked, but you pass in username, not a token, and the resources you want to access. BTW, this is how many OAuth implementations work. Access tokens are just opaque strings that must be validated and the only way to get information about the user is by invoking on a user info service. The keycloak/openshift integration requires keycloak to invoke on the OpenShift API server. The provider is configured with an Openshift service account token. The configured token is used as a bearer token. THERE IS NO REFRESH...EVER. Makes things really simple for the client. There are a lot of Keycloak users that jack up access token timeouts because they want permanent tokens. Managing token timeouts and refreshes is a pain in the ass. FYI, I'm not just pulling this out of my ass... :) Simo seems to think that this is a blocker for GA for keycloak/openshift integration. > I could see us doing something similar with allowing users to generate > these short tokens that can be used to authenticate and obtain > refresh/access tokens instead of using username/password. > This is just not the same thing, sorry. Useful, but not the same thing. From bburke at redhat.com Fri Mar 16 07:03:50 2018 From: bburke at redhat.com (Bill Burke) Date: Fri, 16 Mar 2018 07:03:50 -0400 Subject: [keycloak-dev] we do not support offline tokens In-Reply-To: <94c7ca4f47bb400184c789354749d5ba@bosch-si.com> References: <64f691b3212f4603b6ec7f15c189cff5@bosch-si.com> <94c7ca4f47bb400184c789354749d5ba@bosch-si.com> Message-ID: On Fri, Mar 16, 2018 at 4:51 AM, Schuster Sebastian (INST/ESY1) wrote: > P.S.: Is handling token lifetimes or refresh tokens really such an issue? Any decent OAuth2 library should be able to handle this properly... > IMO, depends on the HTTP client framework too, not just the oauth one. I like things ridiculously simple though. -- Bill Burke Red Hat From sthorger at redhat.com Fri Mar 16 07:57:01 2018 From: sthorger at redhat.com (Stian Thorgersen) Date: Fri, 16 Mar 2018 12:57:01 +0100 Subject: [keycloak-dev] Using Fedora community services to relay GitHub events In-Reply-To: <5AAB65F1.1050801@redhat.com> References: <152112542832.19829.4198768877335064200@tyrfing> <152115067138.23247.2645035408336444659@tyrfing> <5AAB65F1.1050801@redhat.com> Message-ID: Pavel/Bruno - I thought the bot already had webhooks and that we already had a working prototype? On 16 March 2018 at 07:36, Pavel Drozd wrote: > Thanks Alex, it seems really interesting... > > Dne 15.3.2018 v 22:51 Alex Szczuczko napsal(a): > > Ok, I've filed it in your backlog: > > > > https://issues.jboss.org/browse/KEYCLOAK-6854 > > > > Alex > > > > Quoting Bruno Oliveira (2018-03-15 09:30:39) > >> TBH I never tried, but it looks interesting. I suggest to file a Jira as > >> spike for R&D in this way the team can discuss, evaluate and prioritize. > >> > >> Thanks for sharing Alex. > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > From psilva at redhat.com Fri Mar 16 08:24:52 2018 From: psilva at redhat.com (Pedro Igor Silva) Date: Fri, 16 Mar 2018 09:24:52 -0300 Subject: [keycloak-dev] Client Scope naming In-Reply-To: References: <6109ae10-65be-5c45-8a9e-bd4f79c034bc@redhat.com> Message-ID: That is what I was thinking. In authz services, scopes are not related with roles or protocol mappers. They are just a string representing something you can perform/access in a protected resource. Use client scopes to represent such concept and remove "authz scopes" tab is a bit overkill, I think. Currently, if I have a Localization API and a scope that grants access based on a "device.localization" scope, I would need to create a role/mapper and associate it with a client scope, right ? On Fri, Mar 16, 2018 at 4:46 AM, Marek Posolda wrote: > Scope parameter would reference client scopes. For example scope parameter > "openid email profile offline_access" will reference client scopes "email", > "profile" and "offline_access" (openid is jsut generic OpenID Connect > marker). And each client scope is set of protocolMappers and/or Role scope > mappings. > > Marek > > > On 15/03/18 12:39, Pedro Igor Silva wrote: > > How a scope looks like now after your changes ? Are they just strings > referencing a set of one or more roles ? Or they are still roles ? > > On Wed, Mar 14, 2018 at 5:03 PM, Marek Posolda > wrote: > >> That's good question. As you know, we also have "Scope" tab (used to >> specify scope role mappings of client) and "Authorization scope", which >> is used when Authorization is enabled :) >> >> Marek >> >> On 14/03/18 14:37, Schuster Sebastian (INST/ESY1) wrote: >> > Hi, >> > >> > I saw there are activities to replace client templates with client >> scopes. UMA 2.0 uses the term ?client scope? to determine what the OAuth >> client wants to do with the granted access (e.g. this could be used to >> determine the purpose of processing some data for GDPR compliance). Since >> Keycloak will also support UMA 2.0, I am a little concerned this might lead >> to some confusion. As you know, there are only two hard problems in >> computer science: cache invalidation, naming things, and off-by-one errors. >> ? WDYT? >> > >> > Best regards, >> > Sebastian >> > >> > Mit freundlichen Gr??en / Best regards >> > >> > Dr.-Ing. Sebastian Schuster >> > >> > Engineering and Support (INST/ESY1) >> > Bosch Software Innovations GmbH | Ullsteinstr. 128 | 12109 Berlin | >> GERMANY | www.bosch-si.com >> > Tel. +49 30 726112-485 <%2B49%2030%20726112-485> | Fax +49 30 >> 726112-100 <%2B49%2030%20726112-100> | Sebastian.Schuster at bosch-si.com >> >> > >> > Sitz: Berlin, Registergericht: Amtsgericht Charlottenburg; HRB 148411 B >> > Aufsichtsratsvorsitzender: Dr.-Ing. Thorsten L?cke; Gesch?ftsf?hrung: >> Dr. Stefan Ferber, Michael Hahn >> > >> > >> > >> > _______________________________________________ >> > keycloak-dev mailing list >> > keycloak-dev at lists.jboss.org >> > https://lists.jboss.org/mailman/listinfo/keycloak-dev >> >> >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> > > > From sthorger at redhat.com Fri Mar 16 08:50:37 2018 From: sthorger at redhat.com (Stian Thorgersen) Date: Fri, 16 Mar 2018 13:50:37 +0100 Subject: [keycloak-dev] KEYCLOAK-4509: OIDC IDP initiated login In-Reply-To: <913790288.2428684.1521188651382@mail.yahoo.com> References: <913790288.2428684.1521188651382.ref@mail.yahoo.com> <913790288.2428684.1521188651382@mail.yahoo.com> Message-ID: [Adding some info from the PR] OIDC IdP initiated login is something I assume there are specifications for already. So rather than doing a home-grown solution we should use that. There's some mention in OIDC specs about third-party initiated logins ( https://openid.net/specs/openid-connect-core-1_0.html#ThirdPartyInitiatedLogin). I've not looked at it much, but it seems to cover this use-case. On 16 March 2018 at 09:24, Adrian Gonzalez wrote: > Hello, > I would like to raise a thread on OIDC IDP initiated login (or OIDC third > party initiated login). > KC supports only SAML Clients for IDP Initiated login ( > http://www.keycloak.org/docs/latest/server_admin/index. > html#idp-initiated-login).When I have an OIDC app, I cannot use this > feature.The need has been raised in KEYCLOAK-4509. > > I created an ugly PR to implement this feature, my use case is described > in [1].In this implementation, I : > - configured IDP initiated SAML between KC and external IDP- and hacked > the code to test if the destination app was OIDC. If it was OIDC, then KC > makes a plain redirect to the RP app (see also [1]).This allows SAML > initiated IDP and conversion to OIDC app. > We could implement that by relying on OIDC 3rd party initiated login.See > [3] on how this *could* work.This would allow OIDC third party initiated > IDP for OIDC app (but this isn't enough for having SAML initiated IDP for > an OIDC app - perhaps there's a solution for handling both OIDC 3rd party ). > wdyt ? > Cheers,Adrian > > > [1] https://github.com/keycloak/keycloak/pull/4965# > issuecomment-373578277.[2] http://openid.net/specs/openid- > connect-core-1_0.html#ThirdPartyInitiatedLogin[3] ht > tps://github.com/keycloak/keycloak/pull/4965#issuecomment-373580906[4] > https://issues.jboss.org/browse/KEYCLOAK-4509 > > > > > > > | | Garanti sans virus. www.avg.com | > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev From mposolda at redhat.com Fri Mar 16 09:12:59 2018 From: mposolda at redhat.com (Marek Posolda) Date: Fri, 16 Mar 2018 14:12:59 +0100 Subject: [keycloak-dev] Client Scope naming In-Reply-To: References: <6109ae10-65be-5c45-8a9e-bd4f79c034bc@redhat.com> Message-ID: <976022cb-b0ed-51e0-6754-955efee6675a@redhat.com> On 16/03/18 13:24, Pedro Igor Silva wrote: > That is what I was thinking. In authz services, scopes are not related > with roles or protocol mappers. They are just a string representing > something you can perform/access in a protected resource. Use client > scopes to represent such concept and remove "authz scopes" tab is a > bit overkill, I think. > > Currently, if I have a Localization API and a scope that grants access > based on a "device.localization"? scope, I would need to create a > role/mapper and associate it with a client scope, right ? You mean that you have support for "device.localization" value of OAuth scope parameter? Yes, you would need to create clientScope and associate role "device.localization" with it. With client scopes support, the scope parameter doesn't reference single role, but single client scope. Marek > > On Fri, Mar 16, 2018 at 4:46 AM, Marek Posolda > wrote: > > Scope parameter would reference client scopes. For example scope > parameter "openid email profile offline_access" will reference > client scopes "email", "profile" and "offline_access" (openid is > jsut generic OpenID Connect marker).? And each client scope is set > of protocolMappers and/or Role scope mappings. > > Marek > > > On 15/03/18 12:39, Pedro Igor Silva wrote: >> How a scope looks like now after your changes ? Are they just >> strings referencing a set of one or more roles ? Or they are >> still roles ? >> >> On Wed, Mar 14, 2018 at 5:03 PM, Marek Posolda >> > wrote: >> >> That's good question. As you know, we also have "Scope" tab >> (used to >> specify scope role mappings of client) and "Authorization >> scope", which >> is used when Authorization is enabled :) >> >> Marek >> >> On 14/03/18 14:37, Schuster Sebastian (INST/ESY1) wrote: >> > Hi, >> > >> > I saw there are activities to replace client templates with >> client scopes. UMA 2.0 uses the term ?client scope? to >> determine what the OAuth client wants to do with the granted >> access (e.g. this could be used to determine the purpose of >> processing some data for GDPR compliance). Since Keycloak >> will also support UMA 2.0, I am a little concerned this might >> lead to some confusion. As you know, there are only two hard >> problems in computer science: cache invalidation, naming >> things, and off-by-one errors. ? WDYT? >> > >> > Best regards, >> > Sebastian >> > >> > Mit freundlichen Gr??en / Best regards >> > >> > Dr.-Ing. Sebastian Schuster >> > >> > Engineering and Support (INST/ESY1) >> > Bosch Software Innovations GmbH | Ullsteinstr. 128 | 12109 >> Berlin | GERMANY | www.bosch-si.com >> > > >> > Tel. +49 30 726112-485 | Fax >> +49 30 726112-100 | >> Sebastian.Schuster at bosch-si.com >> > > >> > >> > Sitz: Berlin, Registergericht: Amtsgericht Charlottenburg; >> HRB 148411 B >> > Aufsichtsratsvorsitzender: Dr.-Ing. Thorsten L?cke; >> Gesch?ftsf?hrung: Dr. Stefan Ferber, Michael Hahn >> > >> > >> > >> > _______________________________________________ >> > keycloak-dev mailing list >> > keycloak-dev at lists.jboss.org >> >> > https://lists.jboss.org/mailman/listinfo/keycloak-dev >> >> >> >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev at lists.jboss.org >> >> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> >> >> > > From mposolda at redhat.com Fri Mar 16 09:19:22 2018 From: mposolda at redhat.com (Marek Posolda) Date: Fri, 16 Mar 2018 14:19:22 +0100 Subject: [keycloak-dev] Initial client scopes PR In-Reply-To: <1413563e2fde41ab9c47dbad6b6c5596@bosch-si.com> References: <7d4da3f5-4e64-e1df-983d-4f14cdcb19d7@redhat.com> <4e6e7b8cebaf46b6b310df956ce40c94@bosch-si.com> <5ab0dee4-281a-d8ba-2dea-933d1e2214c8@redhat.com> <1413563e2fde41ab9c47dbad6b6c5596@bosch-si.com> Message-ID: <56117e61-37eb-6906-d146-a6a9c9663aca@redhat.com> On 16/03/18 09:15, Schuster Sebastian (INST/ESY1) wrote: > Doesn't the current client scope functionality cover everything that was possible on the scopes tab, except for the ability to simply allow all scopes for a client? Not sure what you mean. I am probably lost in what "scope" you are talking about :) Client scope (new thing, which is not yet in Keycloak master) or "Role scope mappings" (functionality which is under "Scopes" tab of client or clientTemplate in current master?) But at least for now with my PR applied, clients still have "Scope" tab on themselves as it's still possible to grant "Role scope mappings" directly to client. But clients will also inherit "Role scope mappings" from all client scopes, which are assigned to them. Marek > Then my proposal would be to add that functionality to the "client scope" tab and call it "scope" tab again, and maybe rename the menu on the left to "scope mappings" > or also just "scopes". > > Best regards, > Sebastian > > > Mit freundlichen Gr??en / Best regards > > Dr.-Ing. Sebastian Schuster > > Engineering and Support (INST/ESY1) > Bosch?Software Innovations?GmbH | Ullsteinstr. 128 | 12109 Berlin | GERMANY | www.bosch-si.com > Tel. +49 30 726112-485 | Fax +49 30 726112-100 | Sebastian.Schuster at bosch-si.com > > Sitz: Berlin, Registergericht: Amtsgericht Charlottenburg; HRB 148411 B > Aufsichtsratsvorsitzender: Dr.-Ing. Thorsten L?cke; Gesch?ftsf?hrung: Dr. Stefan Ferber, Michael Hahn > > > > > -----Original Message----- > From: Marek Posolda [mailto:mposolda at redhat.com] > Sent: Freitag, 16. M?rz 2018 08:48 > To: Schuster Sebastian (INST/ESY1) ; keycloak-dev at lists.jboss.org > Subject: Re: [keycloak-dev] Initial client scopes PR > > It's not yet clear... Maybe we can rename tab to "Role Scopes"? Will it be clearer or even more confusing? :) > > Marek > > On 15/03/18 13:13, Schuster Sebastian (INST/ESY1) wrote: >> Is the long-term goal to make the "Scopes" tab for clients go away? Because currently it's a bit confusing both are there... >> >> Best regards, >> Sebastian >> >> Mit freundlichen Gr??en / Best regards >> >> Dr.-Ing. Sebastian Schuster >> >> Engineering and Support (INST/ESY1) >> Bosch?Software Innovations?GmbH | Ullsteinstr. 128 | 12109 Berlin | >> GERMANY | www.bosch-si.com Tel. +49 30 726112-485 | Fax +49 30 >> 726112-100 | Sebastian.Schuster at bosch-si.com >> >> Sitz: Berlin, Registergericht: Amtsgericht Charlottenburg; HRB 148411 >> B >> Aufsichtsratsvorsitzender: Dr.-Ing. Thorsten L?cke; Gesch?ftsf?hrung: >> Dr. Stefan Ferber, Michael Hahn >> >> >> >> >> -----Original Message----- >> From: keycloak-dev-bounces at lists.jboss.org >> [mailto:keycloak-dev-bounces at lists.jboss.org] On Behalf Of Marek >> Posolda >> Sent: Mittwoch, 14. M?rz 2018 18:47 >> To: keycloak-dev at lists.jboss.org >> Subject: [keycloak-dev] Initial client scopes PR >> >> Hi, >> >> I've finally send PR https://github.com/keycloak/keycloak/pull/5076 for the first iteration of client scopes. I will talk on tomorrow call about the details and still need to write some more automated tests. But I am seing PR now if someone wants to take a look. >> >> Summary: >> >> - Client Templates were renamed to "Client Scopes". Some things were removed from the client template admin console (EG. Theme setting added recently). Also I've removed some ClientTemplate model properties, which were never used. Client Scope still has list of protocol mappers and list of "Scopes" (Roles scope mappings). >> >> >> - There is new tab "Client Scopes" on client. Here you can assign client scopes to client. Each client has 2 types of client scopes: >> -- Default client scopes -- Those client scopes are automatically applied when login with the client. Their protocol mappers and "Role scope mappings" are always used. >> -- Optional client scopes -- Those client scopes are applicable just for OIDC clients. They are used just if they are requested by "scope" >> parameter during login >> >> >> - Under "Client scopes", there is new tab "Default Client Scopes" . This allows to specify "Realm default client scopes" and "Realm optional client scopes". The scopes configured here will be added as default/optional scopes to new clients. Client can override this (Remove those defaults and add some different client scopes). So it works similarly to Default Roles. >> >> >> - Roles don't have "Scope Param Required" flag anymore. Protocol mappers don't have "Consent required" and "Consent text" anymore. Client scopes don't have "Full scope allowed" flag. But clients still have "Full scope allowed" flag for now and it's still ON by default for newly created clients. >> >> - There are few builtin client scopes added to each realm. There are 4 >> claims scopes defined in OIDC specification and those are added by >> default: "profile", "email", "address" and "phone" with the protocol mappers corresponding to the claims described in OIDC specification [1]. >> -- The "profile" and "email" are configured as default scopes and hence are automatically added to new clients. >> -- The "phone" and "address" are configured as optional scopes by default. >> -- The clients now doesn't have any protocolMappers added by default when they are created. I've added "profile" and "email" as default scopes due it's most close to the previous default protocolMappers we had. >> >> - For SAML, there is "role_list" default client scope, containing just 1 protocol mapper "role list". So both OIDC and SAML clients don't have any protocol mappers by default, it's driven by client scopes now by default. >> >> - There is "offline_access" OIDC client scope, which is optional scope by default. This scope contains just "offline_access" realm role. Due the fact, that parameter "Scope Param Required" was removed from RoleModel, the "offline_access" role is now automatically available in tokens for clients with "Full Scope Allowed", even if no offline tokens was requsted. But I don't think it's big issue besides a bit bigger token. Same also already applies for uma_authorization and some other built-in roles. The fact, that offline token is requested is now driven by "offline_access" scope. But user should still have "offline_access" >> role to be able to receive offline token. >> >> Consent changes: >> - Consent screen now doesn't display protocolMappers (claims) and roles, but instead it displays just client scopes. So by default, the consent screen contains 2 items "User profile" and "Email address", which correspond to the "profile" and "email" OIDC scopes. >> >> - There can be still the case, when client has some protocolMappers or role scope mappings defined on itself. So I've added flag "Display On Consent Screen" on clients (It's OFF by default) to specify if some message should be shown on consent screen about claims dedicated directly to client itself. It's useful especially when client doesn't have any client scopes as the consent screen wouldn't be displayed in that case. >> >> - During this refactoring, I've tried to do some cleanup we discussed before, so I've removed protocolMappers and roles from clientSession. >> Instead I've added clientScopes to refresh token. During refreshing token, it's checked that user still has all the consents, which are in the refresh token. So in case that user revoked consents in the meantime, the token refresh will fail. ProtocolMappers and scoped roles are always re-computed from the clientScopes. So if for example another claim was added to scope "profile", it will automatically be applied after refreshed token. I don't see an issue with that. User approved on consent screen scope "profile" and he may not be concerned what claims/scoped roles are in profile. >> >> - Migration: In the end I did not change existing clients and did not remove protocolMappers from them and didn't add default/optional client scopes to them. The only exception is "offline_access" profile, which is added as optional to all clients, which had scope to "offline_access" >> role. Consents are not migrated - again with the only exception being "offline_access" consent, so refreshing offline tokens from previous version still works. The new consent screen is something quite different than previous one, so makes sense to show it to users again when they want to login, even if they approved protocolMappers for the previous version. >> >> Sorry for long email and long PR :) More tomorrow... >> >> >> [1] http://openid.net/specs/openid-connect-core-1_0.html#ScopeClaims >> >> Marek >> >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev > From psilva at redhat.com Fri Mar 16 09:27:39 2018 From: psilva at redhat.com (Pedro Igor Silva) Date: Fri, 16 Mar 2018 10:27:39 -0300 Subject: [keycloak-dev] Client Scope naming In-Reply-To: <976022cb-b0ed-51e0-6754-955efee6675a@redhat.com> References: <6109ae10-65be-5c45-8a9e-bd4f79c034bc@redhat.com> <976022cb-b0ed-51e0-6754-955efee6675a@redhat.com> Message-ID: We already had discussions a long time ago about it. I do think that scopes are a first class citizen when doing OIDC and OAuth2, not RBAC. We are too role-based ... Thinking it simple, as an admin user I may want to: * Create a scope "device.localization" with consent required for a client As a client: * Ask for "device.localization" scope when obtaining tokens from AS As a resource server: * Check if scope "device.localization" is granted by introspecting the token. For instance, checking a scope claim within a token. See, no role mapping, no scope -> role mapping, etc. User just consented to grant "device.localization" scope. On Fri, Mar 16, 2018 at 10:12 AM, Marek Posolda wrote: > On 16/03/18 13:24, Pedro Igor Silva wrote: > > That is what I was thinking. In authz services, scopes are not related > with roles or protocol mappers. They are just a string representing > something you can perform/access in a protected resource. Use client scopes > to represent such concept and remove "authz scopes" tab is a bit overkill, > I think. > > Currently, if I have a Localization API and a scope that grants access > based on a "device.localization" scope, I would need to create a > role/mapper and associate it with a client scope, right ? > > You mean that you have support for "device.localization" value of OAuth > scope parameter? Yes, you would need to create clientScope and associate > role "device.localization" with it. With client scopes support, the scope > parameter doesn't reference single role, but single client scope. > > Marek > > > On Fri, Mar 16, 2018 at 4:46 AM, Marek Posolda > wrote: > >> Scope parameter would reference client scopes. For example scope >> parameter "openid email profile offline_access" will reference client >> scopes "email", "profile" and "offline_access" (openid is jsut generic >> OpenID Connect marker). And each client scope is set of protocolMappers >> and/or Role scope mappings. >> >> Marek >> >> >> On 15/03/18 12:39, Pedro Igor Silva wrote: >> >> How a scope looks like now after your changes ? Are they just strings >> referencing a set of one or more roles ? Or they are still roles ? >> >> On Wed, Mar 14, 2018 at 5:03 PM, Marek Posolda >> wrote: >> >>> That's good question. As you know, we also have "Scope" tab (used to >>> specify scope role mappings of client) and "Authorization scope", which >>> is used when Authorization is enabled :) >>> >>> Marek >>> >>> On 14/03/18 14:37, Schuster Sebastian (INST/ESY1) wrote: >>> > Hi, >>> > >>> > I saw there are activities to replace client templates with client >>> scopes. UMA 2.0 uses the term ?client scope? to determine what the OAuth >>> client wants to do with the granted access (e.g. this could be used to >>> determine the purpose of processing some data for GDPR compliance). Since >>> Keycloak will also support UMA 2.0, I am a little concerned this might lead >>> to some confusion. As you know, there are only two hard problems in >>> computer science: cache invalidation, naming things, and off-by-one errors. >>> ? WDYT? >>> > >>> > Best regards, >>> > Sebastian >>> > >>> > Mit freundlichen Gr??en / Best regards >>> > >>> > Dr.-Ing. Sebastian Schuster >>> > >>> > Engineering and Support (INST/ESY1) >>> > Bosch Software Innovations GmbH | Ullsteinstr. 128 | 12109 Berlin | >>> GERMANY >>> >>> | www.bosch-si.com >>> > Tel. +49 30 726112-485 | Fax +49 30 726112-100 | >>> Sebastian.Schuster at bosch-si.com >>> > >>> > Sitz: Berlin, Registergericht: Amtsgericht Charlottenburg; HRB 148411 B >>> > Aufsichtsratsvorsitzender: Dr.-Ing. Thorsten L?cke; Gesch?ftsf?hrung: >>> Dr. Stefan Ferber, Michael Hahn >>> > >>> > >>> > >>> > _______________________________________________ >>> > keycloak-dev mailing list >>> > keycloak-dev at lists.jboss.org >>> > https://lists.jboss.org/mailman/listinfo/keycloak-dev >>> >>> >>> _______________________________________________ >>> keycloak-dev mailing list >>> keycloak-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>> >> >> >> > > From adesbiaux at vente-privee.com Fri Mar 16 09:38:43 2018 From: adesbiaux at vente-privee.com (Adrien DESBIAUX) Date: Fri, 16 Mar 2018 13:38:43 +0000 Subject: [keycloak-dev] Abstract User Adapter Federated Storage & Abstract Idp Authenticator In-Reply-To: <11b1d2b6-fae3-c227-7dcb-73a6497fb4b7@redhat.com> References: , <11b1d2b6-fae3-c227-7dcb-73a6497fb4b7@redhat.com> Message-ID: Many thanks for you reply Marek. Will have a second look at it. Cheers! ________________________________ From: Marek Posolda Sent: Friday, March 16, 2018 9:24:38 AM To: Adrien DESBIAUX; keycloak-dev at lists.jboss.org Subject: Re: [keycloak-dev] Abstract User Adapter Federated Storage & Abstract Idp Authenticator On 15/03/18 13:16, Adrien DESBIAUX wrote: Hi everyone, I would like to get some advices on how to use the "First broker login" flow combined with the Abstract User Adapter Federated Storage. That means the user is not by default in the local Keycloak DB. The users from the user federation are NOT imported into the local DB. Hence the use of the `AbstractUserAdapterFederatedStorage`. In the case of a Facebook login. The default flow is the "First broker login" flow. I did implement a custom Authenticator based on the default "First broker login". So in the `authenticateImpl` function, I would like a user login in with Facebook AND not in the User Federation (external DB) to be created the same way as it would be if it was via username/password. Long story short, I don't want to have `UserModel federatedUser = session.users().addUser(); federatedUser.setEnabled(true);` and `context.setUser(federatedUser);` but just exit success upon successfully user created on the remote storage. I did try to not execute those 2 steps however the auth keep failing with "User with ID not found". By looking at the source code of the `AbstractIdpAuthenticator.java` I found out https://github.com/keycloak/keycloak/blob/ee2d28d589ee62d0e0c0e35dd7bab4308b62faf6/services/src/main/java/org/keycloak/authentication/authenticators/broker/AbstractIdpAuthenticator.java#L129 So that means that if I do not execute the `addUser` and `setEnabled`, I will never be able to register a user from Facebook and complete the auth by using an external user federation? In short, I don't want to store any user locally when the user connect from Facebook, but the Keycloak source code looks like forcing it. Is it correct? Yes, at this moment :( We have some JIRAs to improve this. But I think that with using of some custom authenticators and custom user federated storage, you can already achieve it. For example in the source you pointed (AbstractIdpAuthenticator) there is this: UserModel existingUser = session.users().getUserById(duplication.getExistingUserId(), realm); if (!existingUser.isEnabled()) { throw new AuthenticationFlowException("User with ID '" + existingUserId + "', username '" + existingUser.getUsername() + "' disabled.", AuthenticationFlowError.USER_DISABLED); } If you implement your userStorage in a way, that "existingUser.isEnabled" will return true for the previously "added" users, you should be fine. It's maybe just about some tweaks needed. From what you mentioned, you are maybe not so far from make it working... Marek I hope I was clear enough in my explanation.... I can provide more details if it is not so clear. Many thanks in advance for your enlightening on this. Regards, _______________________________________________ keycloak-dev mailing list keycloak-dev at lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-dev From bruno at abstractj.org Fri Mar 16 10:13:26 2018 From: bruno at abstractj.org (Bruno Oliveira) Date: Fri, 16 Mar 2018 14:13:26 +0000 Subject: [keycloak-dev] Using Fedora community services to relay GitHub events In-Reply-To: References: <152112542832.19829.4198768877335064200@tyrfing> <152115067138.23247.2645035408336444659@tyrfing> <5AAB65F1.1050801@redhat.com> Message-ID: Yep, we do. You can check this out here: https://github.com/keycloak/keycloak-bot. Now we are dealing with the challenges of deploying it into our internal infrastructure. On Fri, Mar 16, 2018 at 8:57 AM Stian Thorgersen wrote: > Pavel/Bruno - I thought the bot already had webhooks and that we already > had a working prototype? > > On 16 March 2018 at 07:36, Pavel Drozd wrote: > > > Thanks Alex, it seems really interesting... > > > > Dne 15.3.2018 v 22:51 Alex Szczuczko napsal(a): > > > Ok, I've filed it in your backlog: > > > > > > https://issues.jboss.org/browse/KEYCLOAK-6854 > > > > > > Alex > > > > > > Quoting Bruno Oliveira (2018-03-15 09:30:39) > > >> TBH I never tried, but it looks interesting. I suggest to file a Jira > as > > >> spike for R&D in this way the team can discuss, evaluate and > prioritize. > > >> > > >> Thanks for sharing Alex. > > > > _______________________________________________ > > keycloak-dev mailing list > > keycloak-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > From psilva at redhat.com Fri Mar 16 13:58:47 2018 From: psilva at redhat.com (Pedro Igor Silva) Date: Fri, 16 Mar 2018 14:58:47 -0300 Subject: [keycloak-dev] Resource Attributes Message-ID: Hi All, People have being asking this for some time and I've sent a PR with the necessary changes that allow users to define attributes to resources. This is another important improvement to our policy evaluation engine given that policies are now able to come up with a decision based on attributes associated with a resource. The implementation [1] is pretty much similar to what we have for user attributes. Please let me know if you have any consideration at this regard. [1] https://github.com/keycloak/keycloak/pull/5079 Regards. Pedro Igor From adr_gonzalez at yahoo.fr Fri Mar 16 19:47:58 2018 From: adr_gonzalez at yahoo.fr (Adrian Gonzalez) Date: Fri, 16 Mar 2018 23:47:58 +0000 (UTC) Subject: [keycloak-dev] KEYCLOAK-4509: OIDC IDP initiated login In-Reply-To: References: <913790288.2428684.1521188651382.ref@mail.yahoo.com> <913790288.2428684.1521188651382@mail.yahoo.com> Message-ID: <524201798.3090889.1521244078569@mail.yahoo.com> Hi Stan, Looking a bit more OIDC 3rd party initiated login, I think we can have these 2 scenarii: = Scenario 1? I want to initiate login from a 3rd party to a sample OIDC RP which uses KC as Authorization Server.Solution: In this case, all 3rd implementation burden is for my OIDC RP app [1]. -> nothing to do on KC side for this scenario. = Scenario 2 I configure KC as a OIDC RP for an external IDP (i.e. Okta) *and* I want to do a idp (okta) initiated flow to KC which ultimately will foward to a sample OIDC RP using KC as AS (and okta as idp). This is the scenario of my PR: I add the sample OIDC RP in okta dashboard (previously I configured SAML initiated IDP for that), and when I click on this link I want to be automatically loggedin the sample OIDC RP. Solution 1: Using OIDC 3rd party initiated login, we could implement this flow in the following way:- in KC, we add a initiate_login_uri to the sample OIDC RP- in KC, any oidc idp will be associated with a initiate_login_uri with a uri fragment for every OIDC RP (i.e. http://localhost:8080/auth/realms/realm1/broker/okta/endpoint/clients/sampleapp/initiate_login_uri)- in Okta dashboard, we can perhaps integrate OIDC 3rd party initiated login with a link like: http://localhost:8080/auth/realms/realm1/broker/okta/endpoint/clients/sampleapp/initiate_login_uri?iss=https://okta.com&target_link_uri=http://sampleapp.comThis means, when we click on this link in okta dashboard (we're already logged to okta):1. okta initiates OIDC 3rd party login with KC,?2. KC initiates OIDC authentication flow with okta and gets valid id_token from okta3. KC detects from the URL that it needs to initiate a 3rd party login to sampleapp using target_link_uri=http://sampleapp.com, and initiates such login4. sampleapp initiates OIDC authentication flow with KC5. sample app gets valid AT, IT from KC Solution 2: But perhaps, this use case can already be done using functionnality available in KC, if we set the dashboard URL in okta to something like:http://sampleapp.com?kc_idp_hint=okta&iss=http://localhost:8080/auth/realms/realm1&&target_link_uri=http://sampleapp.comThen sampleapp just needs to handle 3rd party initiated login *and* propagate the kc_idp_hint to KC when starting the authentication flow. Not sure if Okta allows adding such URL in the dashboard (I don't have anymore access to Okta). Looking at okta docs [2], I would say no. I'm very sorry, those are just some thoughts and I cannot check if solution 1 or 2 would work with Okta (no more access and not very much time now) Cheers,Adrian [1] mod_auth_openidc RP lib seems to handle this 3rd party initiated login inhttps://github.com/zmartzone/mod_auth_openidc/blob/master/src/mod_auth_openidc.cmy sample OIDC RP would need to do something similar [2] Docs for okta dashboardhttps://support.okta.com/help/Documentation/Knowledge_Article/The-Applications-Page-1093995619 https://support.okta.com/help/Documentation/Knowledge_Article/Using-the-App-Integration-Wizard-1111708899 De?: Stian Thorgersen ??: Adrian Gonzalez Cc?: Keycloak-dev Envoy? le : Vendredi 16 mars 2018 13h50 Objet?: Re: [keycloak-dev] KEYCLOAK-4509: OIDC IDP initiated login [Adding some info from the PR] OIDC IdP initiated login is something I assume there are specifications for already. So rather than doing a home-grown solution we should use that. There's some mention in OIDC specs about third-party initiated logins (https://openid.net/specs/openid-connect-core-1_0.html#ThirdPartyInitiatedLogin). I've not looked at it much, but it seems to cover this use-case. On 16 March 2018 at 09:24, Adrian Gonzalez wrote: Hello, I would like to raise a thread on OIDC IDP initiated login (or OIDC third party initiated login). KC supports only SAML Clients for IDP Initiated login (http://www.keycloak.org/docs/ latest/server_admin/index. html#idp-initiated-login).When I have an OIDC app, I cannot use this feature.The need has been raised in?KEYCLOAK-4509. I created an ugly PR to implement this feature, my use case is described in [1].In this implementation, I : - configured?IDP initiated SAML between KC and external IDP- and hacked the code to test if the destination app was OIDC. If it was OIDC, then KC makes a plain redirect to the RP app (see also [1]).This allows SAML initiated IDP and conversion to OIDC app. We could implement that by relying on OIDC 3rd party initiated login.See? [3]?on how this *could* work.This would allow OIDC third party initiated IDP for OIDC app (but this isn't enough for having SAML initiated IDP for an OIDC app - perhaps there's a solution for handling both OIDC 3rd party ). wdyt ? Cheers,Adrian [1] https://github.com/keycloak/ keycloak/pull/4965# issuecomment-373578277.[2]?htt p://openid.net/specs/openid- connect-core-1_0.html# ThirdPartyInitiatedLogin[3]?ht tps://github.com/keycloak/ keycloak/pull/4965# issuecomment-373580906[4]?http s://issues.jboss.org/browse/ KEYCLOAK-4509 ? |? | Garanti sans virus. www.avg.com? | ______________________________ _________________ keycloak-dev mailing list keycloak-dev at lists.jboss.org https://lists.jboss.org/ mailman/listinfo/keycloak-dev From mmihaylovich at outlook.com Sat Mar 17 14:06:03 2018 From: mmihaylovich at outlook.com (=?koi8-r?B?5CDtycjBycw=?=) Date: Sat, 17 Mar 2018 18:06:03 +0000 Subject: [keycloak-dev] Spring Security adapter Message-ID: Hello, I'm going to use Spring Session to substitute container specific session managment and clustering session purposes. KeycloakSecurityContext also will be stored in HTTP session. It means that KeycloakPrincipal with KeycloakSecurityContext wil be serialized and deserialized between requests. In this case I faced with the following situation: After successfull authentication 2018-02-14 01:02:52.672 DEBUG 14424 --- [nio-8080-exec-6] f.KeycloakAuthenticationProcessingFilter : Auth outcome: AUTHENTICATED 2018-02-14 01:02:52.672 DEBUG 14424 --- [nio-8080-exec-6] o.s.s.authentication.ProviderManager? ? ?: Authentication attempt using org.keycloak.adapters.springsecurity.authentication.KeycloakAuthenticationProvider 2018-02-14 01:02:52.672 DEBUG 14424 --- [nio-8080-exec-6] f.KeycloakAuthenticationProcessingFilter : Authentication success. Updating SecurityContextHolder to contain: org.keycloak.adapters.springsecurity.token.KeycloakAuthenticationToken at b78d8e87: Principal: user1; Credentials: [PROTECTED]; Authenticated: true; Details: org.keycloak.adapters.springsecurity.account.SimpleKeycloakAccount at 1906910f; Granted Authorities: ROLE_user, ROLE_uma_authorization -?KeycloakSecurityContextRequestFilter clear?SecurityContextHolder . 2018-02-14 01:02:52.715 DEBUG 14424 --- [nio-8080-exec-7] o.s.security.web.FilterChainProxy? ? ? ? : /customers at position 11 of 15 in additional filter chain; firing Filter: 'KeycloakSecurityContextRequestFilter' 2018-02-14 01:02:52.715 DEBUG 14424 --- [nio-8080-exec-7] o.s.security.web.FilterChainProxy? ? ? ? : /customers at position 12 of 15 in additional filter chain; firing Filter: 'AnonymousAuthenticationFilter' 2018-02-14 01:02:52.716 DEBUG 14424 --- [nio-8080-exec-7] o.s.s.w.a.AnonymousAuthenticationFilter? : Populated SecurityContextHolder with anonymous token: 'org.springframework.security.authentication.AnonymousAuthenticationToken at 6fabe8e0: Principal: anonymousUser; Credentials: [PROTECTED]; Authenticated: true; Details: org.springframework.security.web.authentication.WebAuthenticationDetails at fffe9938: RemoteIpAddress: 0:0:0:0:0:0:0:1; SessionId: 06690a32-ab3f-48d6-8776-de16f5d1ad05; Granted Authorities: ROLE_ANONYMOUS' As a result I had infinite loop of redirection between my webapp and Keycloak server. After some investigation I have found why it happend. When KeycloakSecurityContextRequestFilter check refreshableSecurityContext.isActive() refreshableSecurityContext do not contain KeycloakDeployment ( = null). Thus refreshableSecurityContext.isActive() always false. public boolean isActive() { return token != null && this.token.isActive() && deployment!=null && this.token.getIssuedAt() > deployment.getNotBefore(); } The cause of this situation that RefreshableKeycloakSecurityContext created via deserialization and deployment not reassigned. I have patch to fix it if you agree with that issue. From mposolda at redhat.com Mon Mar 19 04:22:03 2018 From: mposolda at redhat.com (Marek Posolda) Date: Mon, 19 Mar 2018 09:22:03 +0100 Subject: [keycloak-dev] Client Scope naming In-Reply-To: References: <6109ae10-65be-5c45-8a9e-bd4f79c034bc@redhat.com> <976022cb-b0ed-51e0-6754-955efee6675a@redhat.com> Message-ID: <56ee4c0a-2661-c4db-5844-8aef0afba7c9@redhat.com> Yes, and this (almost) all should be possible now with new client scopes stuff I did. It won't be a problem to have "device.localization" client scope, which doesn't have any roles or protocolMappers. And require this client scope to be present on consent screen. Only thing, which is not directly available OOTB from what you mentioned, is the: Check if scope "device.localization" is granted by introspecting the token. For instance, checking a scope claim within a token. For now, I've just added client scopes to refresh token, but that one is opaque to the adapter. I did not add anything to access token or ID token. The "scope" claim is not defined on OIDC or OAuth2, so we don't have it in our tokens. Do you know if it's defined in some other specification? We can do our extension and add some stuff into access token similarly like we did for roles, but not sure we want that? Marek On 16/03/18 14:27, Pedro Igor Silva wrote: > We already had discussions a long time ago about it. I do think that > scopes are a first class citizen when doing OIDC and OAuth2, not RBAC. > We are too role-based ... > > Thinking it simple, as an admin user I may want to: > > * Create a scope "device.localization" with consent required for a client > > As a client: > > * Ask for "device.localization" scope when obtaining tokens from AS > > As a resource server: > > * Check if scope "device.localization" is granted by introspecting the > token. For instance, checking a scope claim within a token. > > See, no role mapping, no scope -> role mapping, etc. User just > consented to grant "device.localization" scope. > > On Fri, Mar 16, 2018 at 10:12 AM, Marek Posolda > wrote: > > On 16/03/18 13:24, Pedro Igor Silva wrote: >> That is what I was thinking. In authz services, scopes are not >> related with roles or protocol mappers. They are just a string >> representing something you can perform/access in a protected >> resource. Use client scopes to represent such concept and remove >> "authz scopes" tab is a bit overkill, I think. >> >> Currently, if I have a Localization API and a scope that grants >> access based on a "device.localization"? scope, I would need to >> create a role/mapper and associate it with a client scope, right ? > You mean that you have support for "device.localization" value of > OAuth scope parameter? Yes, you would need to create clientScope > and associate role "device.localization" with it. With client > scopes support, the scope parameter doesn't reference single role, > but single client scope. > > Marek > >> >> On Fri, Mar 16, 2018 at 4:46 AM, Marek Posolda >> > wrote: >> >> Scope parameter would reference client scopes. For example >> scope parameter "openid email profile offline_access" will >> reference client scopes "email", "profile" and >> "offline_access" (openid is jsut generic OpenID Connect >> marker).? And each client scope is set of protocolMappers >> and/or Role scope mappings. >> >> Marek >> >> >> On 15/03/18 12:39, Pedro Igor Silva wrote: >>> How a scope looks like now after your changes ? Are they >>> just strings referencing a set of one or more roles ? Or >>> they are still roles ? >>> >>> On Wed, Mar 14, 2018 at 5:03 PM, Marek Posolda >>> > wrote: >>> >>> That's good question. As you know, we also have "Scope" >>> tab (used to >>> specify scope role mappings of client) and >>> "Authorization scope", which >>> is used when Authorization is enabled :) >>> >>> Marek >>> >>> On 14/03/18 14:37, Schuster Sebastian (INST/ESY1) wrote: >>> > Hi, >>> > >>> > I saw there are activities to replace client templates >>> with client scopes. UMA 2.0 uses the term ?client scope? >>> to determine what the OAuth client wants to do with the >>> granted access (e.g. this could be used to determine the >>> purpose of processing some data for GDPR compliance). >>> Since Keycloak will also support UMA 2.0, I am a little >>> concerned this might lead to some confusion. As you >>> know, there are only two hard problems in computer >>> science: cache invalidation, naming things, and >>> off-by-one errors. ? WDYT? >>> > >>> > Best regards, >>> > Sebastian >>> > >>> > Mit freundlichen Gr??en / Best regards >>> > >>> > Dr.-Ing. Sebastian Schuster >>> > >>> > Engineering and Support (INST/ESY1) >>> > Bosch Software Innovations GmbH | Ullsteinstr. 128 | >>> 12109 Berlin | GERMANY >>> >>> | www.bosch-si.com >>> >> > >>> > Tel. +49 30 726112-485 | >>> Fax +49 30 726112-100 | >>> Sebastian.Schuster at bosch-si.com >>> >> > >>> > >>> > Sitz: Berlin, Registergericht: Amtsgericht >>> Charlottenburg; HRB 148411 B >>> > Aufsichtsratsvorsitzender: Dr.-Ing. Thorsten L?cke; >>> Gesch?ftsf?hrung: Dr. Stefan Ferber, Michael Hahn >>> > >>> > >>> > >>> > _______________________________________________ >>> > keycloak-dev mailing list >>> > keycloak-dev at lists.jboss.org >>> >>> > https://lists.jboss.org/mailman/listinfo/keycloak-dev >>> >>> >>> >>> _______________________________________________ >>> keycloak-dev mailing list >>> keycloak-dev at lists.jboss.org >>> >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>> >>> >>> >> >> > > From mposolda at redhat.com Mon Mar 19 04:25:34 2018 From: mposolda at redhat.com (Marek Posolda) Date: Mon, 19 Mar 2018 09:25:34 +0100 Subject: [keycloak-dev] Initial client scopes PR In-Reply-To: <5aa8bf6eb44445e899fa8a6471542583@bosch-si.com> References: <7d4da3f5-4e64-e1df-983d-4f14cdcb19d7@redhat.com> <4e6e7b8cebaf46b6b310df956ce40c94@bosch-si.com> <5ab0dee4-281a-d8ba-2dea-933d1e2214c8@redhat.com> <1413563e2fde41ab9c47dbad6b6c5596@bosch-si.com> <56117e61-37eb-6906-d146-a6a9c9663aca@redhat.com> <5aa8bf6eb44445e899fa8a6471542583@bosch-si.com> Message-ID: On 16/03/18 14:30, Schuster Sebastian (INST/ESY1) wrote: > What I meant was with the old functionality "role scope mappings" you could control which roles a client could get using a 1:1 mapping from scope to role and then 1:n with composite roles OR you could disable controlling this by simply allowing full scopes for a client. > With the new functionality "client scopes" you can control which roles AND other mapped claims a client can get using an explicit 1:n mapping BUT you cannot simply allow all scopes for a client, right? There is still "Full Scope Allowed" tab on the client. This wasn't removed in my PR. Marek > That?s why I thought it could make sense to just add that switch to the new "client scopes" tab and remove the current "scope" tab completely, at least in the long run... > > Best regards, > Sebastian > > Mit freundlichen Gr??en / Best regards > > Dr.-Ing. Sebastian Schuster > > Engineering and Support (INST/ESY1) > Bosch?Software Innovations?GmbH | Ullsteinstr. 128 | 12109 Berlin | GERMANY | www.bosch-si.com > Tel. +49 30 726112-485 | Fax +49 30 726112-100 | Sebastian.Schuster at bosch-si.com > > Sitz: Berlin, Registergericht: Amtsgericht Charlottenburg; HRB 148411 B > Aufsichtsratsvorsitzender: Dr.-Ing. Thorsten L?cke; Gesch?ftsf?hrung: Dr. Stefan Ferber, Michael Hahn > > > > > -----Original Message----- > From: Marek Posolda [mailto:mposolda at redhat.com] > Sent: Freitag, 16. M?rz 2018 14:19 > To: Schuster Sebastian (INST/ESY1) ; keycloak-dev at lists.jboss.org > Subject: Re: [keycloak-dev] Initial client scopes PR > > On 16/03/18 09:15, Schuster Sebastian (INST/ESY1) wrote: >> Doesn't the current client scope functionality cover everything that was possible on the scopes tab, except for the ability to simply allow all scopes for a client? > Not sure what you mean. I am probably lost in what "scope" you are talking about :) Client scope (new thing, which is not yet in Keycloak > master) or "Role scope mappings" (functionality which is under "Scopes" > tab of client or clientTemplate in current master?) > > But at least for now with my PR applied, clients still have "Scope" tab on themselves as it's still possible to grant "Role scope mappings" > directly to client. But clients will also inherit "Role scope mappings" > from all client scopes, which are assigned to them. > > Marek >> Then my proposal would be to add that functionality to the "client scope" tab and call it "scope" tab again, and maybe rename the menu on the left to "scope mappings" >> or also just "scopes". >> >> Best regards, >> Sebastian >> >> >> Mit freundlichen Gr??en / Best regards >> >> Dr.-Ing. Sebastian Schuster >> >> Engineering and Support (INST/ESY1) >> Bosch?Software Innovations?GmbH | Ullsteinstr. 128 | 12109 Berlin | >> GERMANY | www.bosch-si.com Tel. +49 30 726112-485 | Fax +49 30 >> 726112-100 | Sebastian.Schuster at bosch-si.com >> >> Sitz: Berlin, Registergericht: Amtsgericht Charlottenburg; HRB 148411 >> B >> Aufsichtsratsvorsitzender: Dr.-Ing. Thorsten L?cke; Gesch?ftsf?hrung: >> Dr. Stefan Ferber, Michael Hahn >> >> >> >> >> -----Original Message----- >> From: Marek Posolda [mailto:mposolda at redhat.com] >> Sent: Freitag, 16. M?rz 2018 08:48 >> To: Schuster Sebastian (INST/ESY1) ; >> keycloak-dev at lists.jboss.org >> Subject: Re: [keycloak-dev] Initial client scopes PR >> >> It's not yet clear... Maybe we can rename tab to "Role Scopes"? Will >> it be clearer or even more confusing? :) >> >> Marek >> >> On 15/03/18 13:13, Schuster Sebastian (INST/ESY1) wrote: >>> Is the long-term goal to make the "Scopes" tab for clients go away? Because currently it's a bit confusing both are there... >>> >>> Best regards, >>> Sebastian >>> >>> Mit freundlichen Gr??en / Best regards >>> >>> Dr.-Ing. Sebastian Schuster >>> >>> Engineering and Support (INST/ESY1) >>> Bosch?Software Innovations?GmbH | Ullsteinstr. 128 | 12109 Berlin | >>> GERMANY | www.bosch-si.com Tel. +49 30 726112-485 | Fax +49 30 >>> 726112-100 | Sebastian.Schuster at bosch-si.com >>> >>> Sitz: Berlin, Registergericht: Amtsgericht Charlottenburg; HRB 148411 >>> B >>> Aufsichtsratsvorsitzender: Dr.-Ing. Thorsten L?cke; Gesch?ftsf?hrung: >>> Dr. Stefan Ferber, Michael Hahn >>> >>> >>> >>> >>> -----Original Message----- >>> From: keycloak-dev-bounces at lists.jboss.org >>> [mailto:keycloak-dev-bounces at lists.jboss.org] On Behalf Of Marek >>> Posolda >>> Sent: Mittwoch, 14. M?rz 2018 18:47 >>> To: keycloak-dev at lists.jboss.org >>> Subject: [keycloak-dev] Initial client scopes PR >>> >>> Hi, >>> >>> I've finally send PR https://github.com/keycloak/keycloak/pull/5076 for the first iteration of client scopes. I will talk on tomorrow call about the details and still need to write some more automated tests. But I am seing PR now if someone wants to take a look. >>> >>> Summary: >>> >>> - Client Templates were renamed to "Client Scopes". Some things were removed from the client template admin console (EG. Theme setting added recently). Also I've removed some ClientTemplate model properties, which were never used. Client Scope still has list of protocol mappers and list of "Scopes" (Roles scope mappings). >>> >>> >>> - There is new tab "Client Scopes" on client. Here you can assign client scopes to client. Each client has 2 types of client scopes: >>> -- Default client scopes -- Those client scopes are automatically applied when login with the client. Their protocol mappers and "Role scope mappings" are always used. >>> -- Optional client scopes -- Those client scopes are applicable just for OIDC clients. They are used just if they are requested by "scope" >>> parameter during login >>> >>> >>> - Under "Client scopes", there is new tab "Default Client Scopes" . This allows to specify "Realm default client scopes" and "Realm optional client scopes". The scopes configured here will be added as default/optional scopes to new clients. Client can override this (Remove those defaults and add some different client scopes). So it works similarly to Default Roles. >>> >>> >>> - Roles don't have "Scope Param Required" flag anymore. Protocol mappers don't have "Consent required" and "Consent text" anymore. Client scopes don't have "Full scope allowed" flag. But clients still have "Full scope allowed" flag for now and it's still ON by default for newly created clients. >>> >>> - There are few builtin client scopes added to each realm. There are >>> 4 claims scopes defined in OIDC specification and those are added by >>> default: "profile", "email", "address" and "phone" with the protocol mappers corresponding to the claims described in OIDC specification [1]. >>> -- The "profile" and "email" are configured as default scopes and hence are automatically added to new clients. >>> -- The "phone" and "address" are configured as optional scopes by default. >>> -- The clients now doesn't have any protocolMappers added by default when they are created. I've added "profile" and "email" as default scopes due it's most close to the previous default protocolMappers we had. >>> >>> - For SAML, there is "role_list" default client scope, containing just 1 protocol mapper "role list". So both OIDC and SAML clients don't have any protocol mappers by default, it's driven by client scopes now by default. >>> >>> - There is "offline_access" OIDC client scope, which is optional scope by default. This scope contains just "offline_access" realm role. Due the fact, that parameter "Scope Param Required" was removed from RoleModel, the "offline_access" role is now automatically available in tokens for clients with "Full Scope Allowed", even if no offline tokens was requsted. But I don't think it's big issue besides a bit bigger token. Same also already applies for uma_authorization and some other built-in roles. The fact, that offline token is requested is now driven by "offline_access" scope. But user should still have "offline_access" >>> role to be able to receive offline token. >>> >>> Consent changes: >>> - Consent screen now doesn't display protocolMappers (claims) and roles, but instead it displays just client scopes. So by default, the consent screen contains 2 items "User profile" and "Email address", which correspond to the "profile" and "email" OIDC scopes. >>> >>> - There can be still the case, when client has some protocolMappers or role scope mappings defined on itself. So I've added flag "Display On Consent Screen" on clients (It's OFF by default) to specify if some message should be shown on consent screen about claims dedicated directly to client itself. It's useful especially when client doesn't have any client scopes as the consent screen wouldn't be displayed in that case. >>> >>> - During this refactoring, I've tried to do some cleanup we discussed before, so I've removed protocolMappers and roles from clientSession. >>> Instead I've added clientScopes to refresh token. During refreshing token, it's checked that user still has all the consents, which are in the refresh token. So in case that user revoked consents in the meantime, the token refresh will fail. ProtocolMappers and scoped roles are always re-computed from the clientScopes. So if for example another claim was added to scope "profile", it will automatically be applied after refreshed token. I don't see an issue with that. User approved on consent screen scope "profile" and he may not be concerned what claims/scoped roles are in profile. >>> >>> - Migration: In the end I did not change existing clients and did not remove protocolMappers from them and didn't add default/optional client scopes to them. The only exception is "offline_access" profile, which is added as optional to all clients, which had scope to "offline_access" >>> role. Consents are not migrated - again with the only exception being "offline_access" consent, so refreshing offline tokens from previous version still works. The new consent screen is something quite different than previous one, so makes sense to show it to users again when they want to login, even if they approved protocolMappers for the previous version. >>> >>> Sorry for long email and long PR :) More tomorrow... >>> >>> >>> [1] http://openid.net/specs/openid-connect-core-1_0.html#ScopeClaims >>> >>> Marek >>> >>> _______________________________________________ >>> keycloak-dev mailing list >>> keycloak-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev From psilva at redhat.com Mon Mar 19 08:18:41 2018 From: psilva at redhat.com (Pedro Igor Silva) Date: Mon, 19 Mar 2018 09:18:41 -0300 Subject: [keycloak-dev] Client Scope naming In-Reply-To: <56ee4c0a-2661-c4db-5844-8aef0afba7c9@redhat.com> References: <6109ae10-65be-5c45-8a9e-bd4f79c034bc@redhat.com> <976022cb-b0ed-51e0-6754-955efee6675a@redhat.com> <56ee4c0a-2661-c4db-5844-8aef0afba7c9@redhat.com> Message-ID: OAuth2 does not define any format for access tokens - as you know they are opaque - so you can push whatever you want into it, use it as a reference, etc. But if you look https://tools.ietf.org/html/rfc7662 you'll see that token introspection response includes a "scope" claim. The main point I'm trying to make here is that access tokens usually represent user consent. Consent is not the same thing as a role granted to an user. So I may want to build my REST API without any role mapping but based on user consent to specific scopes. Where these scopes grant access to different parts of my API. But I think that should also be possible with your changes. We would just need to have a mapper that adds to an access token the scopes granted by the user to a client. Or maybe make this information also available via introspection endpoint (which I think we are missing). On Mon, Mar 19, 2018 at 5:22 AM, Marek Posolda wrote: > Yes, and this (almost) all should be possible now with new client scopes > stuff I did. It won't be a problem to have "device.localization" client > scope, which doesn't have any roles or protocolMappers. And require this > client scope to be present on consent screen. > > Only thing, which is not directly available OOTB from what you mentioned, > is the: Check if scope "device.localization" is granted by introspecting > the token. For instance, checking a scope claim within a token. > > For now, I've just added client scopes to refresh token, but that one is > opaque to the adapter. I did not add anything to access token or ID token. > The "scope" claim is not defined on OIDC or OAuth2, so we don't have it in > our tokens. Do you know if it's defined in some other specification? We can > do our extension and add some stuff into access token similarly like we did > for roles, but not sure we want that? > > Marek > > > On 16/03/18 14:27, Pedro Igor Silva wrote: > > We already had discussions a long time ago about it. I do think that > scopes are a first class citizen when doing OIDC and OAuth2, not RBAC. We > are too role-based ... > > Thinking it simple, as an admin user I may want to: > > * Create a scope "device.localization" with consent required for a client > > As a client: > > * Ask for "device.localization" scope when obtaining tokens from AS > > As a resource server: > > * Check if scope "device.localization" is granted by introspecting the > token. For instance, checking a scope claim within a token. > > See, no role mapping, no scope -> role mapping, etc. User just consented > to grant "device.localization" scope. > > On Fri, Mar 16, 2018 at 10:12 AM, Marek Posolda > wrote: > >> On 16/03/18 13:24, Pedro Igor Silva wrote: >> >> That is what I was thinking. In authz services, scopes are not related >> with roles or protocol mappers. They are just a string representing >> something you can perform/access in a protected resource. Use client scopes >> to represent such concept and remove "authz scopes" tab is a bit overkill, >> I think. >> >> Currently, if I have a Localization API and a scope that grants access >> based on a "device.localization" scope, I would need to create a >> role/mapper and associate it with a client scope, right ? >> >> You mean that you have support for "device.localization" value of OAuth >> scope parameter? Yes, you would need to create clientScope and associate >> role "device.localization" with it. With client scopes support, the scope >> parameter doesn't reference single role, but single client scope. >> >> Marek >> >> >> On Fri, Mar 16, 2018 at 4:46 AM, Marek Posolda >> wrote: >> >>> Scope parameter would reference client scopes. For example scope >>> parameter "openid email profile offline_access" will reference client >>> scopes "email", "profile" and "offline_access" (openid is jsut generic >>> OpenID Connect marker). And each client scope is set of protocolMappers >>> and/or Role scope mappings. >>> >>> Marek >>> >>> >>> On 15/03/18 12:39, Pedro Igor Silva wrote: >>> >>> How a scope looks like now after your changes ? Are they just strings >>> referencing a set of one or more roles ? Or they are still roles ? >>> >>> On Wed, Mar 14, 2018 at 5:03 PM, Marek Posolda >>> wrote: >>> >>>> That's good question. As you know, we also have "Scope" tab (used to >>>> specify scope role mappings of client) and "Authorization scope", which >>>> is used when Authorization is enabled :) >>>> >>>> Marek >>>> >>>> On 14/03/18 14:37, Schuster Sebastian (INST/ESY1) wrote: >>>> > Hi, >>>> > >>>> > I saw there are activities to replace client templates with client >>>> scopes. UMA 2.0 uses the term ?client scope? to determine what the OAuth >>>> client wants to do with the granted access (e.g. this could be used to >>>> determine the purpose of processing some data for GDPR compliance). Since >>>> Keycloak will also support UMA 2.0, I am a little concerned this might lead >>>> to some confusion. As you know, there are only two hard problems in >>>> computer science: cache invalidation, naming things, and off-by-one errors. >>>> ? WDYT? >>>> > >>>> > Best regards, >>>> > Sebastian >>>> > >>>> > Mit freundlichen Gr??en / Best regards >>>> > >>>> > Dr.-Ing. Sebastian Schuster >>>> > >>>> > Engineering and Support (INST/ESY1) >>>> > Bosch Software Innovations GmbH | Ullsteinstr. 128 | 12109 Berlin | >>>> GERMANY >>>> >>>> | www.bosch-si.com >>>> > Tel. +49 30 726112-485 <%2B49%2030%20726112-485> | Fax +49 30 >>>> 726112-100 <%2B49%2030%20726112-100> | Sebastian.Schuster at bosch-si.com >>>> >>>> > >>>> > Sitz: Berlin, Registergericht: Amtsgericht Charlottenburg; HRB 148411 >>>> B >>>> > Aufsichtsratsvorsitzender: Dr.-Ing. Thorsten L?cke; Gesch?ftsf?hrung: >>>> Dr. Stefan Ferber, Michael Hahn >>>> > >>>> > >>>> > >>>> > _______________________________________________ >>>> > keycloak-dev mailing list >>>> > keycloak-dev at lists.jboss.org >>>> > https://lists.jboss.org/mailman/listinfo/keycloak-dev >>>> >>>> >>>> _______________________________________________ >>>> keycloak-dev mailing list >>>> keycloak-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>>> >>> >>> >>> >> >> > > From Sebastian.Schuster at bosch-si.com Mon Mar 19 08:33:57 2018 From: Sebastian.Schuster at bosch-si.com (Schuster Sebastian (INST/ESY1)) Date: Mon, 19 Mar 2018 12:33:57 +0000 Subject: [keycloak-dev] Client Scope naming In-Reply-To: References: <6109ae10-65be-5c45-8a9e-bd4f79c034bc@redhat.com> <976022cb-b0ed-51e0-6754-955efee6675a@redhat.com> <56ee4c0a-2661-c4db-5844-8aef0afba7c9@redhat.com> Message-ID: If you support scopes you definitely need some claims in the token that represent the granted scopes. Otherwise as a resource server you could only do token introspection to retrieve the scopes and having to do this always defeats the purpose of self-contained tokens. The fact that Keycloak supports defining custom mappings of scopes to roles (and now arbitrary claims with token mappers) is just fine, I think. Btw. access tokens and scopes is not always user consent, see client credentials grant? Best regards, Sebastian Mit freundlichen Gr??en / Best regards Dr.-Ing. Sebastian Schuster Engineering and Support (INST/ESY1) Bosch Software Innovations GmbH | Ullsteinstr. 128 | 12109 Berlin | GERMANY | www.bosch-si.com Tel. +49 30 726112-485 | Fax +49 30 726112-100 | Sebastian.Schuster at bosch-si.com Sitz: Berlin, Registergericht: Amtsgericht Charlottenburg; HRB 148411 B Aufsichtsratsvorsitzender: Dr.-Ing. Thorsten L?cke; Gesch?ftsf?hrung: Dr. Stefan Ferber, Michael Hahn From: Pedro Igor Silva [mailto:psilva at redhat.com] Sent: Montag, 19. M?rz 2018 13:19 To: Marek Posolda Cc: Schuster Sebastian (INST/ESY1) ; keycloak-dev Subject: Re: [keycloak-dev] Client Scope naming OAuth2 does not define any format for access tokens - as you know they are opaque - so you can push whatever you want into it, use it as a reference, etc. But if you look https://tools.ietf.org/html/rfc7662 you'll see that token introspection response includes a "scope" claim. The main point I'm trying to make here is that access tokens usually represent user consent. Consent is not the same thing as a role granted to an user. So I may want to build my REST API without any role mapping but based on user consent to specific scopes. Where these scopes grant access to different parts of my API. But I think that should also be possible with your changes. We would just need to have a mapper that adds to an access token the scopes granted by the user to a client. Or maybe make this information also available via introspection endpoint (which I think we are missing). On Mon, Mar 19, 2018 at 5:22 AM, Marek Posolda > wrote: Yes, and this (almost) all should be possible now with new client scopes stuff I did. It won't be a problem to have "device.localization" client scope, which doesn't have any roles or protocolMappers. And require this client scope to be present on consent screen. Only thing, which is not directly available OOTB from what you mentioned, is the: Check if scope "device.localization" is granted by introspecting the token. For instance, checking a scope claim within a token. For now, I've just added client scopes to refresh token, but that one is opaque to the adapter. I did not add anything to access token or ID token. The "scope" claim is not defined on OIDC or OAuth2, so we don't have it in our tokens. Do you know if it's defined in some other specification? We can do our extension and add some stuff into access token similarly like we did for roles, but not sure we want that? Marek On 16/03/18 14:27, Pedro Igor Silva wrote: We already had discussions a long time ago about it. I do think that scopes are a first class citizen when doing OIDC and OAuth2, not RBAC. We are too role-based ... Thinking it simple, as an admin user I may want to: * Create a scope "device.localization" with consent required for a client As a client: * Ask for "device.localization" scope when obtaining tokens from AS As a resource server: * Check if scope "device.localization" is granted by introspecting the token. For instance, checking a scope claim within a token. See, no role mapping, no scope -> role mapping, etc. User just consented to grant "device.localization" scope. On Fri, Mar 16, 2018 at 10:12 AM, Marek Posolda > wrote: On 16/03/18 13:24, Pedro Igor Silva wrote: That is what I was thinking. In authz services, scopes are not related with roles or protocol mappers. They are just a string representing something you can perform/access in a protected resource. Use client scopes to represent such concept and remove "authz scopes" tab is a bit overkill, I think. Currently, if I have a Localization API and a scope that grants access based on a "device.localization" scope, I would need to create a role/mapper and associate it with a client scope, right ? You mean that you have support for "device.localization" value of OAuth scope parameter? Yes, you would need to create clientScope and associate role "device.localization" with it. With client scopes support, the scope parameter doesn't reference single role, but single client scope. Marek On Fri, Mar 16, 2018 at 4:46 AM, Marek Posolda > wrote: Scope parameter would reference client scopes. For example scope parameter "openid email profile offline_access" will reference client scopes "email", "profile" and "offline_access" (openid is jsut generic OpenID Connect marker). And each client scope is set of protocolMappers and/or Role scope mappings. Marek On 15/03/18 12:39, Pedro Igor Silva wrote: How a scope looks like now after your changes ? Are they just strings referencing a set of one or more roles ? Or they are still roles ? On Wed, Mar 14, 2018 at 5:03 PM, Marek Posolda > wrote: That's good question. As you know, we also have "Scope" tab (used to specify scope role mappings of client) and "Authorization scope", which is used when Authorization is enabled :) Marek On 14/03/18 14:37, Schuster Sebastian (INST/ESY1) wrote: > Hi, > > I saw there are activities to replace client templates with client scopes. UMA 2.0 uses the term ?client scope? to determine what the OAuth client wants to do with the granted access (e.g. this could be used to determine the purpose of processing some data for GDPR compliance). Since Keycloak will also support UMA 2.0, I am a little concerned this might lead to some confusion. As you know, there are only two hard problems in computer science: cache invalidation, naming things, and off-by-one errors. ? WDYT? > > Best regards, > Sebastian > > Mit freundlichen Gr??en / Best regards > > Dr.-Ing. Sebastian Schuster > > Engineering and Support (INST/ESY1) > Bosch Software Innovations GmbH | Ullsteinstr. 128 | 12109 Berlin | GERMANY | www.bosch-si.com > Tel. +49 30 726112-485 | Fax +49 30 726112-100 | Sebastian.Schuster at bosch-si.com> > > Sitz: Berlin, Registergericht: Amtsgericht Charlottenburg; HRB 148411 B > Aufsichtsratsvorsitzender: Dr.-Ing. Thorsten L?cke; Gesch?ftsf?hrung: Dr. Stefan Ferber, Michael Hahn > > > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev _______________________________________________ keycloak-dev mailing list keycloak-dev at lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-dev From psilva at redhat.com Mon Mar 19 08:59:33 2018 From: psilva at redhat.com (Pedro Igor Silva) Date: Mon, 19 Mar 2018 09:59:33 -0300 Subject: [keycloak-dev] Client Scope naming In-Reply-To: References: <6109ae10-65be-5c45-8a9e-bd4f79c034bc@redhat.com> <976022cb-b0ed-51e0-6754-955efee6675a@redhat.com> <56ee4c0a-2661-c4db-5844-8aef0afba7c9@redhat.com> Message-ID: On Mon, Mar 19, 2018 at 9:33 AM, Schuster Sebastian (INST/ESY1) < Sebastian.Schuster at bosch-si.com> wrote: > If you support scopes you definitely need some claims in the token that > represent the granted scopes. Otherwise as a resource server you could only > do token introspection to retrieve the scopes and having to do this always > defeats the purpose of self-contained tokens. The fact that Keycloak > supports defining custom mappings of scopes to roles (and now arbitrary > claims with token mappers) is just fine, I think. > > > > Btw. access tokens and scopes is not always user consent, see client > credentials grant? > Yeah, that is why I said usually. My initial idea was discuss cases where scopes are *not* limited to the protected resources under the control of the client. > > > Best regards, > > Sebastian > > > > Mit freundlichen Gr??en / Best regards > > > *Dr.-Ing. Sebastian Schuster * > Engineering and Support (INST/ESY1) > Bosch Software Innovations GmbH | Ullsteinstr. 128 | 12109 Berlin | > > GERMANY | www.bosch-si.com > Tel. +49 30 726112-485 <+49%2030%20726112485> | Fax +49 30 726112-100 > <+49%2030%20726112100> | Sebastian.Schuster at bosch-si.com > > Sitz: Berlin, Registergericht: Amtsgericht Charlottenburg; HRB 148411 B > Aufsichtsratsvorsitzender: Dr.-Ing. Thorsten L?cke; Gesch?ftsf?hrung: Dr. > Stefan Ferber, Michael Hahn > > > > *From:* Pedro Igor Silva [mailto:psilva at redhat.com] > *Sent:* Montag, 19. M?rz 2018 13:19 > *To:* Marek Posolda > *Cc:* Schuster Sebastian (INST/ESY1) ; > keycloak-dev > *Subject:* Re: [keycloak-dev] Client Scope naming > > > > OAuth2 does not define any format for access tokens - as you know they are > opaque - so you can push whatever you want into it, use it as a reference, > etc. But if you look https://tools.ietf.org/html/rfc7662 you'll see that > token introspection response includes a "scope" claim. > > > > The main point I'm trying to make here is that access tokens usually > represent user consent. Consent is not the same thing as a role granted to > an user. So I may want to build my REST API without any role mapping but > based on user consent to specific scopes. Where these scopes grant access > to different parts of my API. > > > > But I think that should also be possible with your changes. We would just > need to have a mapper that adds to an access token the scopes granted by > the user to a client. Or maybe make this information also available via > introspection endpoint (which I think we are missing). > > > > On Mon, Mar 19, 2018 at 5:22 AM, Marek Posolda > wrote: > > Yes, and this (almost) all should be possible now with new client scopes > stuff I did. It won't be a problem to have "device.localization" client > scope, which doesn't have any roles or protocolMappers. And require this > client scope to be present on consent screen. > > Only thing, which is not directly available OOTB from what you mentioned, > is the: Check if scope "device.localization" is granted by introspecting > the token. For instance, checking a scope claim within a token. > > For now, I've just added client scopes to refresh token, but that one is > opaque to the adapter. I did not add anything to access token or ID token. > The "scope" claim is not defined on OIDC or OAuth2, so we don't have it in > our tokens. Do you know if it's defined in some other specification? We can > do our extension and add some stuff into access token similarly like we did > for roles, but not sure we want that? > > Marek > > > > On 16/03/18 14:27, Pedro Igor Silva wrote: > > We already had discussions a long time ago about it. I do think that > scopes are a first class citizen when doing OIDC and OAuth2, not RBAC. We > are too role-based ... > > > > Thinking it simple, as an admin user I may want to: > > > > * Create a scope "device.localization" with consent required for a client > > > > As a client: > > > > * Ask for "device.localization" scope when obtaining tokens from AS > > > > As a resource server: > > > > * Check if scope "device.localization" is granted by introspecting the > token. For instance, checking a scope claim within a token. > > > > See, no role mapping, no scope -> role mapping, etc. User just consented > to grant "device.localization" scope. > > > > On Fri, Mar 16, 2018 at 10:12 AM, Marek Posolda > wrote: > > On 16/03/18 13:24, Pedro Igor Silva wrote: > > That is what I was thinking. In authz services, scopes are not related > with roles or protocol mappers. They are just a string representing > something you can perform/access in a protected resource. Use client scopes > to represent such concept and remove "authz scopes" tab is a bit overkill, > I think. > > > > Currently, if I have a Localization API and a scope that grants access > based on a "device.localization" scope, I would need to create a > role/mapper and associate it with a client scope, right ? > > You mean that you have support for "device.localization" value of OAuth > scope parameter? Yes, you would need to create clientScope and associate > role "device.localization" with it. With client scopes support, the scope > parameter doesn't reference single role, but single client scope. > > Marek > > > > > > On Fri, Mar 16, 2018 at 4:46 AM, Marek Posolda > wrote: > > Scope parameter would reference client scopes. For example scope parameter > "openid email profile offline_access" will reference client scopes "email", > "profile" and "offline_access" (openid is jsut generic OpenID Connect > marker). And each client scope is set of protocolMappers and/or Role scope > mappings. > > Marek > > > > On 15/03/18 12:39, Pedro Igor Silva wrote: > > How a scope looks like now after your changes ? Are they just strings > referencing a set of one or more roles ? Or they are still roles ? > > > > On Wed, Mar 14, 2018 at 5:03 PM, Marek Posolda > wrote: > > That's good question. As you know, we also have "Scope" tab (used to > specify scope role mappings of client) and "Authorization scope", which > is used when Authorization is enabled :) > > Marek > > > On 14/03/18 14:37, Schuster Sebastian (INST/ESY1) wrote: > > Hi, > > > > I saw there are activities to replace client templates with client > scopes. UMA 2.0 uses the term ?client scope? to determine what the OAuth > client wants to do with the granted access (e.g. this could be used to > determine the purpose of processing some data for GDPR compliance). Since > Keycloak will also support UMA 2.0, I am a little concerned this might lead > to some confusion. As you know, there are only two hard problems in > computer science: cache invalidation, naming things, and off-by-one errors. > ? WDYT? > > > > Best regards, > > Sebastian > > > > Mit freundlichen Gr??en / Best regards > > > > Dr.-Ing. Sebastian Schuster > > > > Engineering and Support (INST/ESY1) > > Bosch Software Innovations GmbH | Ullsteinstr. 128 | 12109 Berlin | > GERMANY > > | www.bosch-si.com > > Tel. +49 30 726112-485 | Fax +49 30 726112-100 | > Sebastian.Schuster at bosch-si.com > > > > Sitz: Berlin, Registergericht: Amtsgericht Charlottenburg; HRB 148411 B > > Aufsichtsratsvorsitzender: Dr.-Ing. Thorsten L?cke; Gesch?ftsf?hrung: > Dr. Stefan Ferber, Michael Hahn > > > > > > > > _______________________________________________ > > keycloak-dev mailing list > > keycloak-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > > > > > > > > > > > > > From mposolda at redhat.com Mon Mar 19 13:31:10 2018 From: mposolda at redhat.com (Marek Posolda) Date: Mon, 19 Mar 2018 18:31:10 +0100 Subject: [keycloak-dev] Client Scope naming In-Reply-To: References: <6109ae10-65be-5c45-8a9e-bd4f79c034bc@redhat.com> <976022cb-b0ed-51e0-6754-955efee6675a@redhat.com> <56ee4c0a-2661-c4db-5844-8aef0afba7c9@redhat.com> Message-ID: <58fc88ad-acab-e580-25f4-7849798173cd@redhat.com> I see. I think you guys have very good points. I've created JIRA https://issues.jboss.org/browse/KEYCLOAK-6883 to make sure that we return "scope" in the access token. With my PR, the "scope" is already returned in the TokenResponse as defined in the OAuth2 [1] . But Introspection endpoint doesn't return "scope" because access token doesn't yet have scope in my PR. I've just added scope information to the refresh token, but I didn't add scope claim directly. I've added "client-scopes" claim to the refresh token with the list of UUIDs referencing used client scopes. I did this just because: a) refreshToken is opaque to the application and just Keycloak needs to be able to read it and decode used client scopes from it. b) referencing by UUID is in theory bit safer instead of referencing by scope names. I was just thinking about corner case when admin deletes scope "foo" and then re-create scope "foo" again, it would be something different then what user granted, even if it's same name. Hence I used reference by UUID. But this is probably just corner case, which won't happen in practice. When thinking more about it, it seems that none of the points (a) and (b) justifies this unecessary complication with using "client-scopes" rather then just "scope". It will be just easier if both access token and refreshToken contains "scope" claim in the OAuth2 format. WDYT? [1] https://tools.ietf.org/html/rfc6749#section-5.1 Marek On 19/03/18 13:59, Pedro Igor Silva wrote: > > > On Mon, Mar 19, 2018 at 9:33 AM, Schuster Sebastian (INST/ESY1) > > wrote: > > If you support scopes you definitely need some claims in the token > that represent the granted scopes. Otherwise as a resource server > you could only do token introspection to retrieve the scopes and > having to do this always defeats the purpose of self-contained > tokens. The fact that Keycloak supports defining custom mappings > of scopes to roles (and now arbitrary claims with token mappers) > is just fine, I think. > > Btw. access tokens and scopes is not always user consent, see > client credentials grant? > > > Yeah, that is why I said usually. My initial idea was discuss cases > where scopes are *not* limited to the protected resources under the > control of the client. > > Best regards, > > Sebastian > > Mit freundlichen Gr??en / Best regards > > *Dr.-Ing. Sebastian Schuster > * > Engineering and Support (INST/ESY1) > Bosch?Software Innovations?GmbH | Ullsteinstr. 128 | 12109 Berlin > | > GERMANY > | www.bosch-si.com > Tel. +49 30 726112-485 | Fax +49 30 > 726112-100 | > Sebastian.Schuster at bosch-si.com > > > Sitz: Berlin, Registergericht: Amtsgericht Charlottenburg; HRB > 148411 B > Aufsichtsratsvorsitzender: Dr.-Ing. Thorsten L?cke; > Gesch?ftsf?hrung: Dr. Stefan Ferber, Michael Hahn > > > > *From:*Pedro Igor Silva [mailto:psilva at redhat.com > ] > *Sent:* Montag, 19. M?rz 2018 13:19 > *To:* Marek Posolda > > *Cc:* Schuster Sebastian (INST/ESY1) > >; keycloak-dev > > > *Subject:* Re: [keycloak-dev] Client Scope naming > > OAuth2 does not define any format for access tokens - as you know > they are opaque - so you can push whatever you want into it, use > it as a reference, etc. But if you look > https://tools.ietf.org/html/rfc7662 > you'll see that token > introspection response includes a "scope" claim. > > The main point I'm trying to make here is that access tokens > usually represent user consent. Consent is not the same thing as a > role granted to an user. So I may want to build my REST API > without any role mapping but based on user consent to specific > scopes. Where these scopes grant access to different parts of my API. > > But I think that should also be possible with your changes. We > would just need to have a mapper that adds to an access token the > scopes granted by the user to a client. Or maybe make this > information also available via introspection endpoint (which I > think we are missing). > > On Mon, Mar 19, 2018 at 5:22 AM, Marek Posolda > > wrote: > > Yes, and this (almost) all should be possible now with new > client scopes stuff I did. It won't be a problem to have > "device.localization" client scope, which doesn't have any > roles or protocolMappers. And require this client scope to be > present on consent screen. > > Only thing, which is not directly available OOTB from what you > mentioned, is the: Check if scope "device.localization" is > granted by introspecting the token. For instance, checking a > scope claim within a token. > > For now, I've just added client scopes to refresh token, but > that one is opaque to the adapter. I did not add anything to > access token or ID token. The "scope" claim is not defined on > OIDC or OAuth2, so we don't have it in our tokens. Do you know > if it's defined in some other specification? We can do our > extension and add some stuff into access token similarly like > we did for roles, but not sure we want that? > > Marek > > > > On 16/03/18 14:27, Pedro Igor Silva wrote: > > We already had discussions a long time ago about it. I do > think that scopes are a first class citizen when doing > OIDC and OAuth2, not RBAC. We are too role-based ... > > Thinking it simple, as an admin user I may want to: > > * Create a scope "device.localization" with consent > required for a client > > As a client: > > * Ask for "device.localization" scope when obtaining > tokens from AS > > As a resource server: > > * Check if scope "device.localization" is granted by > introspecting the token. For instance, checking a scope > claim within a token. > > See, no role mapping, no scope -> role mapping, etc. User > just consented to grant "device.localization" scope. > > On Fri, Mar 16, 2018 at 10:12 AM, Marek Posolda > > wrote: > > On 16/03/18 13:24, Pedro Igor Silva wrote: > > That is what I was thinking. In authz services, > scopes are not related with roles or protocol > mappers. They are just a string representing > something you can perform/access in a protected > resource. Use client scopes to represent such > concept and remove "authz scopes" tab is a bit > overkill, I think. > > Currently, if I have a Localization API and a > scope that grants access based on a > "device.localization" scope, I would need to > create a role/mapper and associate it with a > client scope, right ? > > You mean that you have support for > "device.localization" value of OAuth scope parameter? > Yes, you would need to create clientScope and > associate role "device.localization" with it. With > client scopes support, the scope parameter doesn't > reference single role, but single client scope. > > Marek > > > > On Fri, Mar 16, 2018 at 4:46 AM, Marek Posolda > > > wrote: > > Scope parameter would reference client scopes. > For example scope parameter "openid email > profile offline_access" will reference client > scopes "email", "profile" and "offline_access" > (openid is jsut generic OpenID Connect > marker).? And each client scope is set of > protocolMappers and/or Role scope mappings. > > Marek > > > > On 15/03/18 12:39, Pedro Igor Silva wrote: > > How a scope looks like now after your > changes ? Are they just strings > referencing a set of one or more roles ? > Or they are still roles ? > > On Wed, Mar 14, 2018 at 5:03 PM, Marek > Posolda > wrote: > > That's good question. As you know, we > also have "Scope" tab (used to > specify scope role mappings of client) > and "Authorization scope", which > is used when Authorization is enabled :) > > Marek > > > On 14/03/18 14:37, Schuster Sebastian > (INST/ESY1) wrote: > > Hi, > > > > I saw there are activities to > replace client templates with client > scopes. UMA 2.0 uses the term ?client > scope? to determine what the OAuth > client wants to do with the granted > access (e.g. this could be used to > determine the purpose of processing > some data for GDPR compliance). Since > Keycloak will also support UMA 2.0, I > am a little concerned this might lead > to some confusion. As you know, there > are only two hard problems in computer > science: cache invalidation, naming > things, and off-by-one errors. ? WDYT? > > > > Best regards, > > Sebastian > > > > Mit freundlichen Gr??en / Best regards > > > > Dr.-Ing. Sebastian Schuster > > > > Engineering and Support (INST/ESY1) > > Bosch Software Innovations GmbH | > Ullsteinstr. 128 | 12109 Berlin | > GERMANY > > | www.bosch-si.com > > > > Tel. +49 30 726112-485 > | Fax > +49 30 726112-100 > | > Sebastian.Schuster at bosch-si.com > > > > > > Sitz: Berlin, Registergericht: > Amtsgericht Charlottenburg; HRB 148411 B > > Aufsichtsratsvorsitzender: Dr.-Ing. > Thorsten L?cke; Gesch?ftsf?hrung: Dr. > Stefan Ferber, Michael Hahn > > > > > > > > > _______________________________________________ > > keycloak-dev mailing list > > keycloak-dev at lists.jboss.org > > > > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > From psilva at redhat.com Mon Mar 19 15:08:16 2018 From: psilva at redhat.com (Pedro Igor Silva) Date: Mon, 19 Mar 2018 16:08:16 -0300 Subject: [keycloak-dev] Client Scope naming In-Reply-To: <58fc88ad-acab-e580-25f4-7849798173cd@redhat.com> References: <6109ae10-65be-5c45-8a9e-bd4f79c034bc@redhat.com> <976022cb-b0ed-51e0-6754-955efee6675a@redhat.com> <56ee4c0a-2661-c4db-5844-8aef0afba7c9@redhat.com> <58fc88ad-acab-e580-25f4-7849798173cd@redhat.com> Message-ID: +1 On Mon, Mar 19, 2018 at 2:31 PM, Marek Posolda wrote: > I see. I think you guys have very good points. I've created JIRA > https://issues.jboss.org/browse/KEYCLOAK-6883 to make sure that we return > "scope" in the access token. > > With my PR, the "scope" is already returned in the TokenResponse as > defined in the OAuth2 [1] . But Introspection endpoint doesn't return > "scope" because access token doesn't yet have scope in my PR. > > I've just added scope information to the refresh token, but I didn't add > scope claim directly. I've added "client-scopes" claim to the refresh token > with the list of UUIDs referencing used client scopes. I did this just > because: > a) refreshToken is opaque to the application and just Keycloak needs to be > able to read it and decode used client scopes from it. > b) referencing by UUID is in theory bit safer instead of referencing by > scope names. I was just thinking about corner case when admin deletes scope > "foo" and then re-create scope "foo" again, it would be something different > then what user granted, even if it's same name. Hence I used reference by > UUID. But this is probably just corner case, which won't happen in > practice. > > When thinking more about it, it seems that none of the points (a) and (b) > justifies this unecessary complication with using "client-scopes" rather > then just "scope". It will be just easier if both access token and > refreshToken contains "scope" claim in the OAuth2 format. WDYT? > > [1] https://tools.ietf.org/html/rfc6749#section-5.1 > > Marek > > > On 19/03/18 13:59, Pedro Igor Silva wrote: > > > > On Mon, Mar 19, 2018 at 9:33 AM, Schuster Sebastian (INST/ESY1) < > Sebastian.Schuster at bosch-si.com> wrote: > >> If you support scopes you definitely need some claims in the token that >> represent the granted scopes. Otherwise as a resource server you could only >> do token introspection to retrieve the scopes and having to do this always >> defeats the purpose of self-contained tokens. The fact that Keycloak >> supports defining custom mappings of scopes to roles (and now arbitrary >> claims with token mappers) is just fine, I think. >> >> >> >> Btw. access tokens and scopes is not always user consent, see client >> credentials grant? >> > > Yeah, that is why I said usually. My initial idea was discuss cases where > scopes are *not* limited to the protected resources under the control of > the client. > > >> >> >> Best regards, >> >> Sebastian >> >> >> >> Mit freundlichen Gr??en / Best regards >> >> >> *Dr.-Ing. Sebastian Schuster * >> Engineering and Support (INST/ESY1) >> Bosch Software Innovations GmbH | Ullsteinstr. 128 | 12109 Berlin | >> >> GERMANY | www.bosch-si.com >> Tel. +49 30 726112-485 <+49%2030%20726112485> | Fax +49 30 726112-100 >> <+49%2030%20726112100> | Sebastian.Schuster at bosch-si.com >> >> Sitz: Berlin, Registergericht: Amtsgericht Charlottenburg; HRB 148411 B >> Aufsichtsratsvorsitzender: Dr.-Ing. Thorsten L?cke; Gesch?ftsf?hrung: >> Dr. Stefan Ferber, Michael Hahn >> >> >> >> *From:* Pedro Igor Silva [mailto:psilva at redhat.com] >> *Sent:* Montag, 19. M?rz 2018 13:19 >> *To:* Marek Posolda >> *Cc:* Schuster Sebastian (INST/ESY1) ; >> keycloak-dev >> *Subject:* Re: [keycloak-dev] Client Scope naming >> >> >> >> OAuth2 does not define any format for access tokens - as you know they >> are opaque - so you can push whatever you want into it, use it as a >> reference, etc. But if you look https://tools.ietf.org/html/rfc7662 >> you'll see that token introspection response includes a "scope" claim. >> >> >> >> The main point I'm trying to make here is that access tokens usually >> represent user consent. Consent is not the same thing as a role granted to >> an user. So I may want to build my REST API without any role mapping but >> based on user consent to specific scopes. Where these scopes grant access >> to different parts of my API. >> >> >> >> But I think that should also be possible with your changes. We would just >> need to have a mapper that adds to an access token the scopes granted by >> the user to a client. Or maybe make this information also available via >> introspection endpoint (which I think we are missing). >> >> >> >> On Mon, Mar 19, 2018 at 5:22 AM, Marek Posolda >> wrote: >> >> Yes, and this (almost) all should be possible now with new client scopes >> stuff I did. It won't be a problem to have "device.localization" client >> scope, which doesn't have any roles or protocolMappers. And require this >> client scope to be present on consent screen. >> >> Only thing, which is not directly available OOTB from what you mentioned, >> is the: Check if scope "device.localization" is granted by introspecting >> the token. For instance, checking a scope claim within a token. >> >> For now, I've just added client scopes to refresh token, but that one is >> opaque to the adapter. I did not add anything to access token or ID token. >> The "scope" claim is not defined on OIDC or OAuth2, so we don't have it in >> our tokens. Do you know if it's defined in some other specification? We can >> do our extension and add some stuff into access token similarly like we did >> for roles, but not sure we want that? >> >> Marek >> >> >> >> On 16/03/18 14:27, Pedro Igor Silva wrote: >> >> We already had discussions a long time ago about it. I do think that >> scopes are a first class citizen when doing OIDC and OAuth2, not RBAC. We >> are too role-based ... >> >> >> >> Thinking it simple, as an admin user I may want to: >> >> >> >> * Create a scope "device.localization" with consent required for a client >> >> >> >> As a client: >> >> >> >> * Ask for "device.localization" scope when obtaining tokens from AS >> >> >> >> As a resource server: >> >> >> >> * Check if scope "device.localization" is granted by introspecting the >> token. For instance, checking a scope claim within a token. >> >> >> >> See, no role mapping, no scope -> role mapping, etc. User just consented >> to grant "device.localization" scope. >> >> >> >> On Fri, Mar 16, 2018 at 10:12 AM, Marek Posolda >> wrote: >> >> On 16/03/18 13:24, Pedro Igor Silva wrote: >> >> That is what I was thinking. In authz services, scopes are not related >> with roles or protocol mappers. They are just a string representing >> something you can perform/access in a protected resource. Use client scopes >> to represent such concept and remove "authz scopes" tab is a bit overkill, >> I think. >> >> >> >> Currently, if I have a Localization API and a scope that grants access >> based on a "device.localization" scope, I would need to create a >> role/mapper and associate it with a client scope, right ? >> >> You mean that you have support for "device.localization" value of OAuth >> scope parameter? Yes, you would need to create clientScope and associate >> role "device.localization" with it. With client scopes support, the scope >> parameter doesn't reference single role, but single client scope. >> >> Marek >> >> >> >> >> >> On Fri, Mar 16, 2018 at 4:46 AM, Marek Posolda >> wrote: >> >> Scope parameter would reference client scopes. For example scope >> parameter "openid email profile offline_access" will reference client >> scopes "email", "profile" and "offline_access" (openid is jsut generic >> OpenID Connect marker). And each client scope is set of protocolMappers >> and/or Role scope mappings. >> >> Marek >> >> >> >> On 15/03/18 12:39, Pedro Igor Silva wrote: >> >> How a scope looks like now after your changes ? Are they just strings >> referencing a set of one or more roles ? Or they are still roles ? >> >> >> >> On Wed, Mar 14, 2018 at 5:03 PM, Marek Posolda >> wrote: >> >> That's good question. As you know, we also have "Scope" tab (used to >> specify scope role mappings of client) and "Authorization scope", which >> is used when Authorization is enabled :) >> >> Marek >> >> >> On 14/03/18 14:37, Schuster Sebastian (INST/ESY1) wrote: >> > Hi, >> > >> > I saw there are activities to replace client templates with client >> scopes. UMA 2.0 uses the term ?client scope? to determine what the OAuth >> client wants to do with the granted access (e.g. this could be used to >> determine the purpose of processing some data for GDPR compliance). Since >> Keycloak will also support UMA 2.0, I am a little concerned this might lead >> to some confusion. As you know, there are only two hard problems in >> computer science: cache invalidation, naming things, and off-by-one errors. >> ? WDYT? >> > >> > Best regards, >> > Sebastian >> > >> > Mit freundlichen Gr??en / Best regards >> > >> > Dr.-Ing. Sebastian Schuster >> > >> > Engineering and Support (INST/ESY1) >> > Bosch Software Innovations GmbH | Ullsteinstr. 128 | 12109 Berlin | >> GERMANY >> >> | www.bosch-si.com >> > Tel. +49 30 726112-485 <%2B49%2030%20726112-485> | Fax +49 30 >> 726112-100 | Sebastian.Schuster at bosch-si.com> sch-si.com> >> > >> > Sitz: Berlin, Registergericht: Amtsgericht Charlottenburg; HRB 148411 B >> > Aufsichtsratsvorsitzender: Dr.-Ing. Thorsten L?cke; Gesch?ftsf?hrung: >> Dr. Stefan Ferber, Michael Hahn >> > >> > >> > >> > _______________________________________________ >> > keycloak-dev mailing list >> > keycloak-dev at lists.jboss.org >> > https://lists.jboss.org/mailman/listinfo/keycloak-dev >> >> >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> > > > From nirmal_131 at yahoo.com Mon Mar 19 21:31:40 2018 From: nirmal_131 at yahoo.com (nirmal a) Date: Tue, 20 Mar 2018 01:31:40 +0000 (UTC) Subject: [keycloak-dev] keycloak userinfo References: <2130634267.35081.1521509500614.ref@mail.yahoo.com> Message-ID: <2130634267.35081.1521509500614@mail.yahoo.com> Is it possible to get the user details from the KEYCLOAK_IDENTITY cookie.?I tried the following curl command but was getting an error. curl -d "access_token=$KEYCLOAK_IDENTITY" -H "Content-Type: application/x-www-form-urlencoded"? -X POST "http://localhost:8180/auth/realms/demo/protocol/openid-connect/userinfo" {? ? "error": "invalid_token",? ? "error_description": "Token invalid: Secret key not set"} Is the token parameter value that is passed incorrect? If so is it possible to get the valid parameter value using the cookies KEYCLOAK_IDENTITY, KEYCLOAK_SESSION, AUTH_SESSION_ID. From donaldquixote at gmail.com Mon Mar 19 22:48:24 2018 From: donaldquixote at gmail.com (Donald Gay) Date: Mon, 19 Mar 2018 21:48:24 -0500 Subject: [keycloak-dev] KEYCLOAK-3210 Temporary Fix Message-ID: We want to use Keycloak on MSSQL, but have concerns with the timeline of proposed fix for https://issues.jboss.org/browse/KEYCLOAK-3210 since it requires significant schema changes. One commenter noted that *"Using Hibernate's native annotation @Nationalized for JPA fields might help here - left for further investigation."* We have run some initial tests using @Nationalized on all fields specified in documentation as supporting unicode characters, and along with setting sendStringParametersAsUnicode=false, this seems to resolve the issue while not impacting unicode support. Any thoughts on implementing this to provide quicker resolution? From my perspective it seems like a desirable change to make regardless of any other efforts to clean up schemas. Thanks From Sebastian.Schuster at bosch-si.com Tue Mar 20 05:56:43 2018 From: Sebastian.Schuster at bosch-si.com (Schuster Sebastian (INST/ESY1)) Date: Tue, 20 Mar 2018 09:56:43 +0000 Subject: [keycloak-dev] Client Scope naming In-Reply-To: <58fc88ad-acab-e580-25f4-7849798173cd@redhat.com> References: <6109ae10-65be-5c45-8a9e-bd4f79c034bc@redhat.com> <976022cb-b0ed-51e0-6754-955efee6675a@redhat.com> <56ee4c0a-2661-c4db-5844-8aef0afba7c9@redhat.com> <58fc88ad-acab-e580-25f4-7849798173cd@redhat.com> Message-ID: <0a29664822124858923a515a1e6c8847@bosch-si.com> +1 Mit freundlichen Gr??en / Best regards Dr.-Ing. Sebastian Schuster Engineering and Support (INST/ESY1) Bosch Software Innovations GmbH | Ullsteinstr. 128 | 12109 Berlin | GERMANY | www.bosch-si.com Tel. +49 30 726112-485 | Fax +49 30 726112-100 | Sebastian.Schuster at bosch-si.com Sitz: Berlin, Registergericht: Amtsgericht Charlottenburg; HRB 148411 B Aufsichtsratsvorsitzender: Dr.-Ing. Thorsten L?cke; Gesch?ftsf?hrung: Dr. Stefan Ferber, Michael Hahn From: Marek Posolda [mailto:mposolda at redhat.com] Sent: Montag, 19. M?rz 2018 18:31 To: Pedro Igor Silva ; Schuster Sebastian (INST/ESY1) Cc: keycloak-dev Subject: Re: [keycloak-dev] Client Scope naming I see. I think you guys have very good points. I've created JIRA https://issues.jboss.org/browse/KEYCLOAK-6883 to make sure that we return "scope" in the access token. With my PR, the "scope" is already returned in the TokenResponse as defined in the OAuth2 [1] . But Introspection endpoint doesn't return "scope" because access token doesn't yet have scope in my PR. I've just added scope information to the refresh token, but I didn't add scope claim directly. I've added "client-scopes" claim to the refresh token with the list of UUIDs referencing used client scopes. I did this just because: a) refreshToken is opaque to the application and just Keycloak needs to be able to read it and decode used client scopes from it. b) referencing by UUID is in theory bit safer instead of referencing by scope names. I was just thinking about corner case when admin deletes scope "foo" and then re-create scope "foo" again, it would be something different then what user granted, even if it's same name. Hence I used reference by UUID. But this is probably just corner case, which won't happen in practice. When thinking more about it, it seems that none of the points (a) and (b) justifies this unecessary complication with using "client-scopes" rather then just "scope". It will be just easier if both access token and refreshToken contains "scope" claim in the OAuth2 format. WDYT? [1] https://tools.ietf.org/html/rfc6749#section-5.1 Marek On 19/03/18 13:59, Pedro Igor Silva wrote: On Mon, Mar 19, 2018 at 9:33 AM, Schuster Sebastian (INST/ESY1) > wrote: If you support scopes you definitely need some claims in the token that represent the granted scopes. Otherwise as a resource server you could only do token introspection to retrieve the scopes and having to do this always defeats the purpose of self-contained tokens. The fact that Keycloak supports defining custom mappings of scopes to roles (and now arbitrary claims with token mappers) is just fine, I think. Btw. access tokens and scopes is not always user consent, see client credentials grant? Yeah, that is why I said usually. My initial idea was discuss cases where scopes are *not* limited to the protected resources under the control of the client. Best regards, Sebastian Mit freundlichen Gr??en / Best regards Dr.-Ing. Sebastian Schuster Engineering and Support (INST/ESY1) Bosch Software Innovations GmbH | Ullsteinstr. 128 | 12109 Berlin | GERMANY | www.bosch-si.com Tel. +49 30 726112-485 | Fax +49 30 726112-100 | Sebastian.Schuster at bosch-si.com Sitz: Berlin, Registergericht: Amtsgericht Charlottenburg; HRB 148411 B Aufsichtsratsvorsitzender: Dr.-Ing. Thorsten L?cke; Gesch?ftsf?hrung: Dr. Stefan Ferber, Michael Hahn From: Pedro Igor Silva [mailto:psilva at redhat.com] Sent: Montag, 19. M?rz 2018 13:19 To: Marek Posolda > Cc: Schuster Sebastian (INST/ESY1) >; keycloak-dev > Subject: Re: [keycloak-dev] Client Scope naming OAuth2 does not define any format for access tokens - as you know they are opaque - so you can push whatever you want into it, use it as a reference, etc. But if you look https://tools.ietf.org/html/rfc7662 you'll see that token introspection response includes a "scope" claim. The main point I'm trying to make here is that access tokens usually represent user consent. Consent is not the same thing as a role granted to an user. So I may want to build my REST API without any role mapping but based on user consent to specific scopes. Where these scopes grant access to different parts of my API. But I think that should also be possible with your changes. We would just need to have a mapper that adds to an access token the scopes granted by the user to a client. Or maybe make this information also available via introspection endpoint (which I think we are missing). On Mon, Mar 19, 2018 at 5:22 AM, Marek Posolda > wrote: Yes, and this (almost) all should be possible now with new client scopes stuff I did. It won't be a problem to have "device.localization" client scope, which doesn't have any roles or protocolMappers. And require this client scope to be present on consent screen. Only thing, which is not directly available OOTB from what you mentioned, is the: Check if scope "device.localization" is granted by introspecting the token. For instance, checking a scope claim within a token. For now, I've just added client scopes to refresh token, but that one is opaque to the adapter. I did not add anything to access token or ID token. The "scope" claim is not defined on OIDC or OAuth2, so we don't have it in our tokens. Do you know if it's defined in some other specification? We can do our extension and add some stuff into access token similarly like we did for roles, but not sure we want that? Marek On 16/03/18 14:27, Pedro Igor Silva wrote: We already had discussions a long time ago about it. I do think that scopes are a first class citizen when doing OIDC and OAuth2, not RBAC. We are too role-based ... Thinking it simple, as an admin user I may want to: * Create a scope "device.localization" with consent required for a client As a client: * Ask for "device.localization" scope when obtaining tokens from AS As a resource server: * Check if scope "device.localization" is granted by introspecting the token. For instance, checking a scope claim within a token. See, no role mapping, no scope -> role mapping, etc. User just consented to grant "device.localization" scope. On Fri, Mar 16, 2018 at 10:12 AM, Marek Posolda > wrote: On 16/03/18 13:24, Pedro Igor Silva wrote: That is what I was thinking. In authz services, scopes are not related with roles or protocol mappers. They are just a string representing something you can perform/access in a protected resource. Use client scopes to represent such concept and remove "authz scopes" tab is a bit overkill, I think. Currently, if I have a Localization API and a scope that grants access based on a "device.localization" scope, I would need to create a role/mapper and associate it with a client scope, right ? You mean that you have support for "device.localization" value of OAuth scope parameter? Yes, you would need to create clientScope and associate role "device.localization" with it. With client scopes support, the scope parameter doesn't reference single role, but single client scope. Marek On Fri, Mar 16, 2018 at 4:46 AM, Marek Posolda > wrote: Scope parameter would reference client scopes. For example scope parameter "openid email profile offline_access" will reference client scopes "email", "profile" and "offline_access" (openid is jsut generic OpenID Connect marker). And each client scope is set of protocolMappers and/or Role scope mappings. Marek On 15/03/18 12:39, Pedro Igor Silva wrote: How a scope looks like now after your changes ? Are they just strings referencing a set of one or more roles ? Or they are still roles ? On Wed, Mar 14, 2018 at 5:03 PM, Marek Posolda > wrote: That's good question. As you know, we also have "Scope" tab (used to specify scope role mappings of client) and "Authorization scope", which is used when Authorization is enabled :) Marek On 14/03/18 14:37, Schuster Sebastian (INST/ESY1) wrote: > Hi, > > I saw there are activities to replace client templates with client scopes. UMA 2.0 uses the term ?client scope? to determine what the OAuth client wants to do with the granted access (e.g. this could be used to determine the purpose of processing some data for GDPR compliance). Since Keycloak will also support UMA 2.0, I am a little concerned this might lead to some confusion. As you know, there are only two hard problems in computer science: cache invalidation, naming things, and off-by-one errors. ? WDYT? > > Best regards, > Sebastian > > Mit freundlichen Gr??en / Best regards > > Dr.-Ing. Sebastian Schuster > > Engineering and Support (INST/ESY1) > Bosch Software Innovations GmbH | Ullsteinstr. 128 | 12109 Berlin | GERMANY | www.bosch-si.com > Tel. +49 30 726112-485 | Fax +49 30 726112-100 | Sebastian.Schuster at bosch-si.com> > > Sitz: Berlin, Registergericht: Amtsgericht Charlottenburg; HRB 148411 B > Aufsichtsratsvorsitzender: Dr.-Ing. Thorsten L?cke; Gesch?ftsf?hrung: Dr. Stefan Ferber, Michael Hahn > > > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev _______________________________________________ keycloak-dev mailing list keycloak-dev at lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-dev From psilva at redhat.com Tue Mar 20 10:48:56 2018 From: psilva at redhat.com (Pedro Igor Silva) Date: Tue, 20 Mar 2018 11:48:56 -0300 Subject: [keycloak-dev] Sharing authorization settings across multiple clients Message-ID: Hi, I was investigating how we could share authorization settings (resources, scopes, and specially policies) across multiple clients. Until now, I was considering using Client Templates for that. But now that Client Templates are gone in favor of Client Scopes, I'm not sure where this functionality fits in. Any suggestion on how we can support this ? IMO, better would be avoid another item on the menu for this. But I can't envision other way to do it .... Regards. Pedro Igor From mposolda at redhat.com Tue Mar 20 12:32:37 2018 From: mposolda at redhat.com (Marek Posolda) Date: Tue, 20 Mar 2018 17:32:37 +0100 Subject: [keycloak-dev] Sharing authorization settings across multiple clients In-Reply-To: References: Message-ID: The difference between clientScopes and clientTemplates is, that client-clientTemplate mapping is 1:1 . But client-clientScope mapping will be 1:N. So in the PR I've removed some configuration things from clientTemplate due the potential conflicts with 1:N mapping. For example if client would inherit from 2 client scopes called "scope1" and "scope2" . And "scope1" would have "Login theme" value "sunrise", but "scope2" would have "Login theme" value "keycloak". Then client wouldn't know if it should use "sunrise" or "keycloak" theme. Those configuration switches just don't fit well to the client scope model. So I removed login theme override from admin console and some switches from clientTemplateModel, which were defacto never supported by admin console and admin REST API and defacto never worked (For example clientTemplate had switches like standardFlowEnabled, implicitFlowEnabled etc.). ProtocolMappers and "Role scope mappings" fit well into the clientScopeModel as they "add" things into the client. Basically client use all protocolMappers defined on itself and on all "parent" client scopes. For resources, authorization scopes and policies, those also "add" things if I understand correctly? Basically client will use all policies declared on himself and on all the parent client scopes. So maybe authorization settings can be also added to client scopes? I am just not sure if it fits into the "optional" scopes as it would mean that some policies (and resources and authorization scopes) will be used based on the value of "scope" parameter. But maybe yes as accessToken and the authorization tokens will have "scope" parameter on it, so the adapter will be able to check what policies were used to issue the token and eventually throw the authorization error if used "scope" is insufficient? The other possibility is to use something different than client scopes. Either revert clientTemplates back (I can still update PR to have both clientTemplates and clientScopes models available and have both in admin console, but it will take few days of work and I won't be able to do that in next few weeks). Or do some other thing for authorization similar to what clientTemplate was before? ATM I think that having resources + authorizationScopes + policies defined on clientScopes would work. But I may miss some contexts. You know more if those authorization settings fit to the clientScope model or not. Marek Dne 20.3.2018 v 15:48 Pedro Igor Silva napsal(a): > Hi, > > I was investigating how we could share authorization settings (resources, > scopes, and specially policies) across multiple clients. > > Until now, I was considering using Client Templates for that. But now that > Client Templates are gone in favor of Client Scopes, I'm not sure where > this functionality fits in. > > Any suggestion on how we can support this ? IMO, better would be avoid > another item on the menu for this. But I can't envision other way to do it > .... > > Regards. > Pedro Igor > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev From subscription at gilles.cornu.name Tue Mar 20 15:03:46 2018 From: subscription at gilles.cornu.name (Gilles Cornu) Date: Tue, 20 Mar 2018 20:03:46 +0100 Subject: [keycloak-dev] [KEYCLOAK-4775] Export of Encryption Key missing in several SAML components Message-ID: Hi, Context: While trying to integrate some SAML Service Provider that requires IdP autoconfiguration (via the /auth/realms/REALM/protocol/saml/descriptor endpoint), I observed that the was not generated in the XML element. While searching for known issue related to this bug, I found that KEYCLOAK-4775 which already report this problem (among several SAML encryption key issues). But this issue was closed and marked as "working as expected", apparently without any change to the code base so far. I added a comment there 5 days ago, but I am not sure if comments on closed tickets are considered/accepted. Questions: How should I proceed to start a new discussion about this issue? Please let me know if you prefer that I file a new JIRA issue, or if you plan to reopen KEYCLOAK-4775. Note: I am interested to implement a bug-fix pull request, although my Java Skills and Knowledge on the Keycloak project are "rather" (aka extremely) scarce and will certainly slow down the process. On the other hand, I "suspect" that this should be quickly fixed by an experimented Keycloak developer... (to be confirmed ;-). In other words: Help offered, Help welcome ;-) Thank you very much to all the Keycloak Development community for this very nice and powerful project (that I'm recently starting to learn/use). Best regards, Gilles Cornu From psilva at redhat.com Tue Mar 20 16:16:27 2018 From: psilva at redhat.com (Pedro Igor Silva) Date: Tue, 20 Mar 2018 17:16:27 -0300 Subject: [keycloak-dev] Sharing authorization settings across multiple clients In-Reply-To: References: Message-ID: On Tue, Mar 20, 2018 at 1:32 PM, Marek Posolda wrote: > The difference between clientScopes and clientTemplates is, that > client-clientTemplate mapping is 1:1 . But client-clientScope mapping will > be 1:N. > > So in the PR I've removed some configuration things from clientTemplate > due the potential conflicts with 1:N mapping. For example if client would > inherit from 2 client scopes called "scope1" and "scope2" . And "scope1" > would have "Login theme" value "sunrise", but "scope2" would have "Login > theme" value "keycloak". Then client wouldn't know if it should use > "sunrise" or "keycloak" theme. > Those configuration switches just don't fit well to the client scope > model. So I removed login theme override from admin console and some > switches from clientTemplateModel, which were defacto never supported by > admin console and admin REST API and defacto never worked (For example > clientTemplate had switches like standardFlowEnabled, implicitFlowEnabled > etc.). > > > ProtocolMappers and "Role scope mappings" fit well into the > clientScopeModel as they "add" things into the client. Basically client use > all protocolMappers defined on itself and on all "parent" client scopes. > > For resources, authorization scopes and policies, those also "add" things > if I understand correctly? Basically client will use all policies declared > on himself and on all the parent client scopes. So maybe authorization > settings can be also added to client scopes? > Yeah, they add things to a client. So a client may have its own resources and policies + the ones inherited by a template/scope. In this particular case, we are basically sharing common settings across multiple clients. There is no need for a scope definition. > > I am just not sure if it fits into the "optional" scopes as it would mean > that some policies (and resources and authorization scopes) will be used > based on the value of "scope" parameter. But maybe yes as accessToken and > the authorization tokens will have "scope" parameter on it, so the adapter > will be able to check what policies were used to issue the token and > eventually throw the authorization error if used "scope" is insufficient? > > The other possibility is to use something different than client scopes. > Either revert clientTemplates back (I can still update PR to have both > clientTemplates and clientScopes models available and have both in admin > console, but it will take few days of work and I won't be able to do that > in next few weeks). Or do some other thing for authorization similar to > what clientTemplate was before? > ATM I think that having resources + authorizationScopes + policies defined > on clientScopes would work. But I may miss some contexts. You know more if > those authorization settings fit to the clientScope model or not. > IMO, my use case does not fit into client scopes, at all. What we need is a place where we can define common settings for multiple clients. In fact, I think this is not only useful for this particular use case but wherever you want to allow users to define common settings for clients within the same realm. Sorry for starting this thread so late. I would say that client templates would fit nice, but let's see what others think about it. Not sure about something specific for authorization settings. However ff we decide for something specific, we should probably move authorization stuff to its own menu item in admin console. But I do see value in client templates as a way to define common settings for clients ... > > Marek > > Dne 20.3.2018 v 15:48 Pedro Igor Silva napsal(a): > >> Hi, >> >> I was investigating how we could share authorization settings (resources, >> scopes, and specially policies) across multiple clients. >> >> Until now, I was considering using Client Templates for that. But now that >> Client Templates are gone in favor of Client Scopes, I'm not sure where >> this functionality fits in. >> >> Any suggestion on how we can support this ? IMO, better would be avoid >> another item on the menu for this. But I can't envision other way to do it >> .... >> >> Regards. >> Pedro Igor >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> > > > From sthorger at redhat.com Tue Mar 20 16:47:03 2018 From: sthorger at redhat.com (Stian Thorgersen) Date: Tue, 20 Mar 2018 21:47:03 +0100 Subject: [keycloak-dev] we do not support offline tokens In-Reply-To: References: <64f691b3212f4603b6ec7f15c189cff5@bosch-si.com> Message-ID: Sounds like something we should add. Would it not just be a matter of allowing overriding the token expiration for specific clients? Perhaps also we should have the option for clients to obtain actually opaque tokens so they are forced to call the token introspection endpoint (or token review endpoint in OpenShift/Kube case). On 15 March 2018 at 03:12, Bill Burke wrote: > On Wed, Mar 14, 2018 at 3:07 PM, Stian Thorgersen > wrote: > > I think the short tokens issued by the likes of OpenShift is primarily > used > > for authentication, not access. As such it's more a short ID token than > an > > actual access token. > > > > This is just not how it works. > > Service Account tokens in Openshift/Kubernetes can be used as bearer > tokens. Services that receive these bearer tokens call a validation > endpoint (token review). The validation endpoint returns a JSON > document with user info and group membership. Kubernetes additionally > has a Authorization endpoint that can be invoked, but you pass in > username, not a token, and the resources you want to access. BTW, > this is how many OAuth implementations work. Access tokens are just > opaque strings that must be validated and the only way to get > information about the user is by invoking on a user info service. > > The keycloak/openshift integration requires keycloak to invoke on the > OpenShift API server. The provider is configured with an Openshift > service account token. The configured token is used as a bearer > token. THERE IS NO REFRESH...EVER. Makes things really simple for > the client. There are a lot of Keycloak users that jack up access > token timeouts because they want permanent tokens. Managing token > timeouts and refreshes is a pain in the ass. > > FYI, I'm not just pulling this out of my ass... :) Simo seems to think > that this is a blocker for GA for keycloak/openshift integration. > > > > I could see us doing something similar with allowing users to generate > these > > short tokens that can be used to authenticate and obtain refresh/access > > tokens instead of using username/password. > > > > This is just not the same thing, sorry. Useful, but not the same thing. > From sthorger at redhat.com Tue Mar 20 16:54:53 2018 From: sthorger at redhat.com (Stian Thorgersen) Date: Tue, 20 Mar 2018 21:54:53 +0100 Subject: [keycloak-dev] Sharing authorization settings across multiple clients In-Reply-To: References: Message-ID: I agree that this doesn't fit into client scope. Perhaps we should have kept client templates and just removed protocol mappers and scope from it. Not sure it has a wider use-cases than authorization services though. So perhaps the best would be to have some sort of authorization services specific thing? On 20 March 2018 at 21:16, Pedro Igor Silva wrote: > On Tue, Mar 20, 2018 at 1:32 PM, Marek Posolda > wrote: > > > The difference between clientScopes and clientTemplates is, that > > client-clientTemplate mapping is 1:1 . But client-clientScope mapping > will > > be 1:N. > > > > So in the PR I've removed some configuration things from clientTemplate > > due the potential conflicts with 1:N mapping. For example if client would > > inherit from 2 client scopes called "scope1" and "scope2" . And "scope1" > > would have "Login theme" value "sunrise", but "scope2" would have "Login > > theme" value "keycloak". Then client wouldn't know if it should use > > "sunrise" or "keycloak" theme. > > > > Those configuration switches just don't fit well to the client scope > > model. So I removed login theme override from admin console and some > > switches from clientTemplateModel, which were defacto never supported by > > admin console and admin REST API and defacto never worked (For example > > clientTemplate had switches like standardFlowEnabled, implicitFlowEnabled > > etc.). > > > > > > ProtocolMappers and "Role scope mappings" fit well into the > > clientScopeModel as they "add" things into the client. Basically client > use > > all protocolMappers defined on itself and on all "parent" client scopes. > > > > For resources, authorization scopes and policies, those also "add" things > > if I understand correctly? Basically client will use all policies > declared > > on himself and on all the parent client scopes. So maybe authorization > > settings can be also added to client scopes? > > > > Yeah, they add things to a client. So a client may have its own resources > and policies + the ones inherited by a template/scope. In this particular > case, we are basically sharing common settings across multiple clients. > There is no need for a scope definition. > > > > > > I am just not sure if it fits into the "optional" scopes as it would mean > > that some policies (and resources and authorization scopes) will be used > > based on the value of "scope" parameter. But maybe yes as accessToken and > > the authorization tokens will have "scope" parameter on it, so the > adapter > > will be able to check what policies were used to issue the token and > > eventually throw the authorization error if used "scope" is insufficient? > > > > The other possibility is to use something different than client scopes. > > Either revert clientTemplates back (I can still update PR to have both > > clientTemplates and clientScopes models available and have both in admin > > console, but it will take few days of work and I won't be able to do that > > in next few weeks). Or do some other thing for authorization similar to > > what clientTemplate was before? > > > > ATM I think that having resources + authorizationScopes + policies > defined > > on clientScopes would work. But I may miss some contexts. You know more > if > > those authorization settings fit to the clientScope model or not. > > > > IMO, my use case does not fit into client scopes, at all. What we need is a > place where we can define common settings for multiple clients. In fact, I > think this is not only useful for this particular use case but wherever you > want to allow users to define common settings for clients within the same > realm. > > Sorry for starting this thread so late. I would say that client templates > would fit nice, but let's see what others think about it. Not sure about > something specific for authorization settings. However ff we decide for > something specific, we should probably move authorization stuff to its own > menu item in admin console. > > But I do see value in client templates as a way to define common settings > for clients ... > > > > > > > Marek > > > > Dne 20.3.2018 v 15:48 Pedro Igor Silva napsal(a): > > > >> Hi, > >> > >> I was investigating how we could share authorization settings > (resources, > >> scopes, and specially policies) across multiple clients. > >> > >> Until now, I was considering using Client Templates for that. But now > that > >> Client Templates are gone in favor of Client Scopes, I'm not sure where > >> this functionality fits in. > >> > >> Any suggestion on how we can support this ? IMO, better would be avoid > >> another item on the menu for this. But I can't envision other way to do > it > >> .... > >> > >> Regards. > >> Pedro Igor > >> _______________________________________________ > >> keycloak-dev mailing list > >> keycloak-dev at lists.jboss.org > >> https://lists.jboss.org/mailman/listinfo/keycloak-dev > >> > > > > > > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > From bburke at redhat.com Tue Mar 20 17:10:32 2018 From: bburke at redhat.com (Bill Burke) Date: Tue, 20 Mar 2018 17:10:32 -0400 Subject: [keycloak-dev] kcinit console sso tool In-Reply-To: References: Message-ID: FYI, I reimplemented this command line tool in Golang. I'll be putting together a screencast to show it in action. https://github.com/keycloak/kcinit I also integrated a maven golang plugin so that Java based tests in the arquillian testsuite can run and test it. I need to send a separate email about that. BTW, this tool fits in real nice with openshift and kubernetes integration. Needed a way for `oc` and `kubectl` to obtain a keycloak token and kcinit is it. On Fri, Mar 16, 2018 at 3:48 AM, Stian Thorgersen wrote: > > > On 15 March 2018 at 15:41, Bill Burke wrote: >> >> On Wed, Mar 14, 2018 at 3:15 PM, Stian Thorgersen >> wrote: >> > >> > >> > On 12 March 2018 at 18:59, Bill Burke wrote: >> >> >> >> On Mon, Mar 12, 2018 at 10:16 AM, Stian Thorgersen >> >> >> >> wrote: >> >> > Very cool. A few questions/comments: >> >> > >> >> > * As it's Java based it does make it harder to package/install. >> >> > Compare >> >> > 'oc' >> >> > tool for instance to our 'kcadmin' and 'kcclient' tools. Not sure how >> >> > realistic it would be to write our CLI tools in for instance Go >> >> > though. >> >> > >> >> >> >> Its a pretty simple tool so it could be ported. The only thing that >> >> might be a tiny bit challenging is making sure there's crypto stuff >> >> available in another language to encrypt/decrypt token files. Might >> >> be a nice little project for me to learn Go. >> >> >> >> > * I assume the console display is optional and it basically means >> >> > that >> >> > you >> >> > can only use authenticators that support this rather than all >> >> > authenticators >> >> > require to implement it. >> >> > >> >> >> >> I don't have a switch to launch browser, but, I could as this >> >> functionality is already implemented. Not sure if that would be >> >> portable to Go or another language though. Java has a facility to >> >> automatically launch browser (I think you know that already as you >> >> wrote KeycloakInstalled). >> > >> > >> > That would be pretty cool, but I wasn't thinking that far. I was just >> > basically thinking that authenticators has to be written to support >> > this, >> > rather than all authenticators have to support this. >> >> Pretty cool? LOL! You implemented the browser stuff! > > > What I meant was if there was some fallback where the browser would be > opened to continue the flow in case there is an authenticator that doesn't > have this, but as you say since you can't close the window automatically > it's kinda awkward. > >> >> >> Its not a requirement to support this when writing an authenticator. >> >> >> > >> > I got no clue how they work, but what I meant is the fact that ssh-agent >> > allows you to unlock the keys automatically when you login to your >> > browser. >> > >> > If you have to provide a password to unlock the tokens every time you >> > open a >> > new shell does it actually provide a nicer experience than just doing >> > username/password to login again with resource owner credential grant? >> > >> >> I agree it sucks. I think I'm going to get rid of password protection >> for now. I researched things a bit last night, and at least for >> Golang, there is a cross-platform library for storing passwords in the >> OS's keyring that might be useful. >> >> https://github.com/zalando/go-keyring >> >> I'll look into that when I port this tool to Go. >> >> -- >> Bill Burke >> Red Hat > > -- Bill Burke Red Hat From bburke at redhat.com Tue Mar 20 17:29:01 2018 From: bburke at redhat.com (Bill Burke) Date: Tue, 20 Mar 2018 17:29:01 -0400 Subject: [keycloak-dev] need feedback on integrating golang with testsuite and distro Message-ID: I have a golang client utility (kcinit) that I need to integrate with tests in our testsuite. Its possible to integrate golang with maven using this maven plugin: https://github.com/raydac/mvn-golang To integrate my tool into the arquillian testsuite, I've pulled in this plugin to pull down and build my golang tool so that it can be executed within a test. The way it works is that the maven plugin will first download the Golang SDK and store it within ~/.mvnGolang. It will also store any source code it pulls down and builds there. It will build a binary that is specific to the platform it is running on so this is perfect for our testsuite. Sound ok? Next question is distribution. "kcinit" is a command line utility. Should I add this to our current client tools directory in the disto or create a separate dis zipt? Ok to include binaries for linux, osx, and windows? This will require the maven plugin to individually cross-compile for each platform. Its not superfast and our distro build will be slower, but we will have one place to pull this stuff together. I will need to eventually create an RPM for this tool so that it can be automatically installed in Fedora/RHEL. -- Bill Burke Red Hat From bburke at redhat.com Tue Mar 20 19:03:34 2018 From: bburke at redhat.com (Bill Burke) Date: Tue, 20 Mar 2018 19:03:34 -0400 Subject: [keycloak-dev] kcinit screencast Message-ID: http://youtu.be/uwkggE25TjM?hd=1 -- Bill Burke Red Hat From Sebastian.Schuster at bosch-si.com Wed Mar 21 03:28:44 2018 From: Sebastian.Schuster at bosch-si.com (Schuster Sebastian (INST/ESY1)) Date: Wed, 21 Mar 2018 07:28:44 +0000 Subject: [keycloak-dev] we do not support offline tokens In-Reply-To: References: <64f691b3212f4603b6ec7f15c189cff5@bosch-si.com> Message-ID: <7033a4636d1146db858f586131689cd5@bosch-si.com> I think supporting opaque tokens would be really great. Our security guys have concerns with self-contained tokens for some cases that might demand doing token signing in an HSM. Using opaque tokens is an alternative to that? Best regards, Sebastian Mit freundlichen Gr??en / Best regards Dr.-Ing. Sebastian Schuster Engineering and Support (INST/ESY1) Bosch Software Innovations GmbH | Ullsteinstr. 128 | 12109 Berlin | GERMANY | www.bosch-si.com Tel. +49 30 726112-485 | Fax +49 30 726112-100 | Sebastian.Schuster at bosch-si.com Sitz: Berlin, Registergericht: Amtsgericht Charlottenburg; HRB 148411 B Aufsichtsratsvorsitzender: Dr.-Ing. Thorsten L?cke; Gesch?ftsf?hrung: Dr. Stefan Ferber, Michael Hahn From: Stian Thorgersen [mailto:sthorger at redhat.com] Sent: Dienstag, 20. M?rz 2018 21:47 To: Bill Burke Cc: Pedro Igor Silva ; Schuster Sebastian (INST/ESY1) ; keycloak-dev Subject: Re: [keycloak-dev] we do not support offline tokens Sounds like something we should add. Would it not just be a matter of allowing overriding the token expiration for specific clients? Perhaps also we should have the option for clients to obtain actually opaque tokens so they are forced to call the token introspection endpoint (or token review endpoint in OpenShift/Kube case). On 15 March 2018 at 03:12, Bill Burke > wrote: On Wed, Mar 14, 2018 at 3:07 PM, Stian Thorgersen > wrote: > I think the short tokens issued by the likes of OpenShift is primarily used > for authentication, not access. As such it's more a short ID token than an > actual access token. > This is just not how it works. Service Account tokens in Openshift/Kubernetes can be used as bearer tokens. Services that receive these bearer tokens call a validation endpoint (token review). The validation endpoint returns a JSON document with user info and group membership. Kubernetes additionally has a Authorization endpoint that can be invoked, but you pass in username, not a token, and the resources you want to access. BTW, this is how many OAuth implementations work. Access tokens are just opaque strings that must be validated and the only way to get information about the user is by invoking on a user info service. The keycloak/openshift integration requires keycloak to invoke on the OpenShift API server. The provider is configured with an Openshift service account token. The configured token is used as a bearer token. THERE IS NO REFRESH...EVER. Makes things really simple for the client. There are a lot of Keycloak users that jack up access token timeouts because they want permanent tokens. Managing token timeouts and refreshes is a pain in the ass. FYI, I'm not just pulling this out of my ass... :) Simo seems to think that this is a blocker for GA for keycloak/openshift integration. > I could see us doing something similar with allowing users to generate these > short tokens that can be used to authenticate and obtain refresh/access > tokens instead of using username/password. > This is just not the same thing, sorry. Useful, but not the same thing. From sblanc at redhat.com Wed Mar 21 04:47:26 2018 From: sblanc at redhat.com (Sebastien Blanc) Date: Wed, 21 Mar 2018 09:47:26 +0100 Subject: [keycloak-dev] kcinit screencast In-Reply-To: References: Message-ID: Really nice ! On Wed, Mar 21, 2018 at 12:03 AM, Bill Burke wrote: > http://youtu.be/uwkggE25TjM?hd=1 > > -- > Bill Burke > Red Hat > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > From hmlnarik at redhat.com Wed Mar 21 07:59:02 2018 From: hmlnarik at redhat.com (Hynek Mlnarik) Date: Wed, 21 Mar 2018 12:59:02 +0100 Subject: [keycloak-dev] KEYCLOAK-3210 Temporary Fix In-Reply-To: References: Message-ID: Hi, could you please submit a pull-request? Thanks --Hynek On Tue, Mar 20, 2018 at 3:48 AM, Donald Gay wrote: > We want to use Keycloak on MSSQL, but have concerns with the timeline of > proposed fix for https://issues.jboss.org/browse/KEYCLOAK-3210 since it > requires significant schema changes. > > One commenter noted that > > *"Using Hibernate's native annotation @Nationalized for JPA fields might > help here - left for further investigation."* > > We have run some initial tests using @Nationalized on all fields specified > in documentation as supporting unicode characters, and along with > setting sendStringParametersAsUnicode=false, > this seems to resolve the issue while not impacting unicode support. > > Any thoughts on implementing this to provide quicker resolution? From my > perspective it seems like a desirable change to make regardless of any > other efforts to clean up schemas. > > Thanks > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > -- --Hynek From psilva at redhat.com Wed Mar 21 08:30:50 2018 From: psilva at redhat.com (Pedro Igor Silva) Date: Wed, 21 Mar 2018 09:30:50 -0300 Subject: [keycloak-dev] Sharing authorization settings across multiple clients In-Reply-To: References: Message-ID: If you also agree we should have a specific thing for authz services, I'm OK with it. In fact, the first version of authorization services had its own menu item in the admin console. Before merging it we found that include it as a tab in Client UI was better. It should not require too much time to move the authorization bits from Client UI to its own menu item in the admin console. Main work will be docs and reviewing quickstarts. Does "Authorization Services" sounds like a good name for this menu item ? On Tue, Mar 20, 2018 at 5:54 PM, Stian Thorgersen wrote: > I agree that this doesn't fit into client scope. > > Perhaps we should have kept client templates and just removed protocol > mappers and scope from it. Not sure it has a wider use-cases than > authorization services though. So perhaps the best would be to have some > sort of authorization services specific thing? > > On 20 March 2018 at 21:16, Pedro Igor Silva wrote: > >> On Tue, Mar 20, 2018 at 1:32 PM, Marek Posolda >> wrote: >> >> > The difference between clientScopes and clientTemplates is, that >> > client-clientTemplate mapping is 1:1 . But client-clientScope mapping >> will >> > be 1:N. >> > >> > So in the PR I've removed some configuration things from clientTemplate >> > due the potential conflicts with 1:N mapping. For example if client >> would >> > inherit from 2 client scopes called "scope1" and "scope2" . And "scope1" >> > would have "Login theme" value "sunrise", but "scope2" would have "Login >> > theme" value "keycloak". Then client wouldn't know if it should use >> > "sunrise" or "keycloak" theme. >> >> >> > Those configuration switches just don't fit well to the client scope >> > model. So I removed login theme override from admin console and some >> > switches from clientTemplateModel, which were defacto never supported by >> > admin console and admin REST API and defacto never worked (For example >> > clientTemplate had switches like standardFlowEnabled, >> implicitFlowEnabled >> > etc.). >> > >> > >> > ProtocolMappers and "Role scope mappings" fit well into the >> > clientScopeModel as they "add" things into the client. Basically client >> use >> > all protocolMappers defined on itself and on all "parent" client scopes. >> > >> > For resources, authorization scopes and policies, those also "add" >> things >> > if I understand correctly? Basically client will use all policies >> declared >> > on himself and on all the parent client scopes. So maybe authorization >> > settings can be also added to client scopes? >> > >> >> Yeah, they add things to a client. So a client may have its own resources >> and policies + the ones inherited by a template/scope. In this particular >> case, we are basically sharing common settings across multiple clients. >> There is no need for a scope definition. >> >> >> > >> > I am just not sure if it fits into the "optional" scopes as it would >> mean >> > that some policies (and resources and authorization scopes) will be used >> > based on the value of "scope" parameter. But maybe yes as accessToken >> and >> > the authorization tokens will have "scope" parameter on it, so the >> adapter >> > will be able to check what policies were used to issue the token and >> > eventually throw the authorization error if used "scope" is >> insufficient? >> > >> > The other possibility is to use something different than client scopes. >> > Either revert clientTemplates back (I can still update PR to have both >> > clientTemplates and clientScopes models available and have both in admin >> > console, but it will take few days of work and I won't be able to do >> that >> > in next few weeks). Or do some other thing for authorization similar to >> > what clientTemplate was before? >> >> >> > ATM I think that having resources + authorizationScopes + policies >> defined >> > on clientScopes would work. But I may miss some contexts. You know more >> if >> > those authorization settings fit to the clientScope model or not. >> > >> >> IMO, my use case does not fit into client scopes, at all. What we need is >> a >> place where we can define common settings for multiple clients. In fact, I >> think this is not only useful for this particular use case but wherever >> you >> want to allow users to define common settings for clients within the same >> realm. >> >> Sorry for starting this thread so late. I would say that client templates >> would fit nice, but let's see what others think about it. Not sure about >> something specific for authorization settings. However ff we decide for >> something specific, we should probably move authorization stuff to its own >> menu item in admin console. >> >> But I do see value in client templates as a way to define common settings >> for clients ... >> >> >> >> > >> > Marek >> > >> > Dne 20.3.2018 v 15:48 Pedro Igor Silva napsal(a): >> > >> >> Hi, >> >> >> >> I was investigating how we could share authorization settings >> (resources, >> >> scopes, and specially policies) across multiple clients. >> >> >> >> Until now, I was considering using Client Templates for that. But now >> that >> >> Client Templates are gone in favor of Client Scopes, I'm not sure where >> >> this functionality fits in. >> >> >> >> Any suggestion on how we can support this ? IMO, better would be avoid >> >> another item on the menu for this. But I can't envision other way to >> do it >> >> .... >> >> >> >> Regards. >> >> Pedro Igor >> >> _______________________________________________ >> >> keycloak-dev mailing list >> >> keycloak-dev at lists.jboss.org >> >> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> >> >> > >> > >> > >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> > > From psilva at redhat.com Wed Mar 21 08:33:58 2018 From: psilva at redhat.com (Pedro Igor Silva) Date: Wed, 21 Mar 2018 09:33:58 -0300 Subject: [keycloak-dev] kcinit console sso tool In-Reply-To: References: Message-ID: Looking forward to use this tool .... On Tue, Mar 20, 2018 at 6:10 PM, Bill Burke wrote: > FYI, I reimplemented this command line tool in Golang. I'll be > putting together a screencast to show it in action. > > https://github.com/keycloak/kcinit > > I also integrated a maven golang plugin so that Java based tests in > the arquillian testsuite can run and test it. I need to send a > separate email about that. > > BTW, this tool fits in real nice with openshift and kubernetes > integration. Needed a way for `oc` and `kubectl` to obtain a keycloak > token and kcinit is it. > > > On Fri, Mar 16, 2018 at 3:48 AM, Stian Thorgersen > wrote: > > > > > > On 15 March 2018 at 15:41, Bill Burke wrote: > >> > >> On Wed, Mar 14, 2018 at 3:15 PM, Stian Thorgersen > >> wrote: > >> > > >> > > >> > On 12 March 2018 at 18:59, Bill Burke wrote: > >> >> > >> >> On Mon, Mar 12, 2018 at 10:16 AM, Stian Thorgersen > >> >> > >> >> wrote: > >> >> > Very cool. A few questions/comments: > >> >> > > >> >> > * As it's Java based it does make it harder to package/install. > >> >> > Compare > >> >> > 'oc' > >> >> > tool for instance to our 'kcadmin' and 'kcclient' tools. Not sure > how > >> >> > realistic it would be to write our CLI tools in for instance Go > >> >> > though. > >> >> > > >> >> > >> >> Its a pretty simple tool so it could be ported. The only thing that > >> >> might be a tiny bit challenging is making sure there's crypto stuff > >> >> available in another language to encrypt/decrypt token files. Might > >> >> be a nice little project for me to learn Go. > >> >> > >> >> > * I assume the console display is optional and it basically means > >> >> > that > >> >> > you > >> >> > can only use authenticators that support this rather than all > >> >> > authenticators > >> >> > require to implement it. > >> >> > > >> >> > >> >> I don't have a switch to launch browser, but, I could as this > >> >> functionality is already implemented. Not sure if that would be > >> >> portable to Go or another language though. Java has a facility to > >> >> automatically launch browser (I think you know that already as you > >> >> wrote KeycloakInstalled). > >> > > >> > > >> > That would be pretty cool, but I wasn't thinking that far. I was just > >> > basically thinking that authenticators has to be written to support > >> > this, > >> > rather than all authenticators have to support this. > >> > >> Pretty cool? LOL! You implemented the browser stuff! > > > > > > What I meant was if there was some fallback where the browser would be > > opened to continue the flow in case there is an authenticator that > doesn't > > have this, but as you say since you can't close the window automatically > > it's kinda awkward. > > > >> > >> > >> Its not a requirement to support this when writing an authenticator. > >> > >> > >> > > >> > I got no clue how they work, but what I meant is the fact that > ssh-agent > >> > allows you to unlock the keys automatically when you login to your > >> > browser. > >> > > >> > If you have to provide a password to unlock the tokens every time you > >> > open a > >> > new shell does it actually provide a nicer experience than just doing > >> > username/password to login again with resource owner credential grant? > >> > > >> > >> I agree it sucks. I think I'm going to get rid of password protection > >> for now. I researched things a bit last night, and at least for > >> Golang, there is a cross-platform library for storing passwords in the > >> OS's keyring that might be useful. > >> > >> https://github.com/zalando/go-keyring > >> > >> I'll look into that when I port this tool to Go. > >> > >> -- > >> Bill Burke > >> Red Hat > > > > > > > > -- > Bill Burke > Red Hat > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > From sthorger at redhat.com Wed Mar 21 09:52:55 2018 From: sthorger at redhat.com (Stian Thorgersen) Date: Wed, 21 Mar 2018 14:52:55 +0100 Subject: [keycloak-dev] need feedback on integrating golang with testsuite and distro In-Reply-To: References: Message-ID: On 20 March 2018 at 22:29, Bill Burke wrote: > I have a golang client utility (kcinit) that I need to integrate with > tests in our testsuite. Its possible to integrate golang with maven > using this maven plugin: > > https://github.com/raydac/mvn-golang > > To integrate my tool into the arquillian testsuite, I've pulled in > this plugin to pull down and build my golang tool so that it can be > executed within a test. The way it works is that the maven plugin > will first download the Golang SDK and store it within ~/.mvnGolang. > It will also store any source code it pulls down and builds there. It > will build a binary that is specific to the platform it is running on > so this is perfect for our testsuite. > > Sound ok? > That works. Would it be best to have a profile for it though? Rather than having it run every time developers build and test we can add a CI job for it that would be ran on PRs. That way it's always tested on PRs, but you don't have to pay the price locally if you haven't touched kinit at all. > > Next question is distribution. "kcinit" is a command line utility. > Should I add this to our current client tools directory in the disto > or create a separate dis zipt? Ok to include binaries for linux, osx, > and windows? This will require the maven plugin to individually > cross-compile for each platform. Its not superfast and our distro > build will be slower, but we will have one place to pull this stuff > together. I will need to eventually create an RPM for this tool so > that it can be automatically installed in Fedora/RHEL. > I'd go with a separate dist. It's a client tool and having to download and extract it from the large server zip would be annoying. Maybe it would be best to have a separate profile here as well? Something like distribution-cli. It can be disabled by default, but enabled when we do releases. I know quite a lot of folks regularly builds the server dist while doing development, myself included. For Keycloak we can definitively include binaries for all. Can the Maven plugin build all binaries on Linux? Or do you need to build it on the individual platforms? If the latter then we have a biggish problem to figure out when releasing Keycloak. Can you start a thread on keycloak-team about how we do it for RH-SSO? I'd rather not discuss that on this list. > > > > > -- > Bill Burke > Red Hat > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > From sthorger at redhat.com Wed Mar 21 10:08:58 2018 From: sthorger at redhat.com (Stian Thorgersen) Date: Wed, 21 Mar 2018 15:08:58 +0100 Subject: [keycloak-dev] kcinit screencast In-Reply-To: References: Message-ID: That's really nice. First time I see oauth done well from the command line. I think it could do with some more newlines in places to space the outputs a bit more apart. Minor thing though. Thinking a bit about the confidential client when invoking the token exchange. As kcinit really is a public client how do you envision folks would use that? Could another option be to use the ID token (or some other special SSO login token) to allow obtaining tokens for different clients? I was thinking something like "kcinit login" obtains the ID token (or the other SSO login token aka something to replace the SSO cookie on web). It could also request an offline session to have the tool connected long term (i.e. for a bot or something). Then next time you want to obtain a token for a specific client it can just pass this SSO login token instead of user creds to retrieve tokens for that app. One question which is relevant if you use token exchange as well as if there's some sort of SSO login token is how do we prevent an application from obtaining a token for another app. App A for instance could just invoke kcinit internally without the user knowing about it to obtain token for App B. On 21 March 2018 at 00:03, Bill Burke wrote: > http://youtu.be/uwkggE25TjM?hd=1 > > -- > Bill Burke > Red Hat > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > From sthorger at redhat.com Wed Mar 21 10:13:23 2018 From: sthorger at redhat.com (Stian Thorgersen) Date: Wed, 21 Mar 2018 15:13:23 +0100 Subject: [keycloak-dev] Sharing authorization settings across multiple clients In-Reply-To: References: Message-ID: Having a separate entry for authz might make a lot of sense. To take that to the extreme you could then share everything between clients right? Resources, policies, you name it. On 21 March 2018 at 13:30, Pedro Igor Silva wrote: > If you also agree we should have a specific thing for authz services, I'm > OK with it. > > In fact, the first version of authorization services had its own menu item > in the admin console. Before merging it we found that include it as a tab > in Client UI was better. > > It should not require too much time to move the authorization bits from > Client UI to its own menu item in the admin console. Main work will be docs > and reviewing quickstarts. Does "Authorization Services" sounds like a good > name for this menu item ? > > > > On Tue, Mar 20, 2018 at 5:54 PM, Stian Thorgersen > wrote: > >> I agree that this doesn't fit into client scope. >> >> Perhaps we should have kept client templates and just removed protocol >> mappers and scope from it. Not sure it has a wider use-cases than >> authorization services though. So perhaps the best would be to have some >> sort of authorization services specific thing? >> >> On 20 March 2018 at 21:16, Pedro Igor Silva wrote: >> >>> On Tue, Mar 20, 2018 at 1:32 PM, Marek Posolda >>> wrote: >>> >>> > The difference between clientScopes and clientTemplates is, that >>> > client-clientTemplate mapping is 1:1 . But client-clientScope mapping >>> will >>> > be 1:N. >>> > >>> > So in the PR I've removed some configuration things from clientTemplate >>> > due the potential conflicts with 1:N mapping. For example if client >>> would >>> > inherit from 2 client scopes called "scope1" and "scope2" . And >>> "scope1" >>> > would have "Login theme" value "sunrise", but "scope2" would have >>> "Login >>> > theme" value "keycloak". Then client wouldn't know if it should use >>> > "sunrise" or "keycloak" theme. >>> >>> >>> > Those configuration switches just don't fit well to the client scope >>> > model. So I removed login theme override from admin console and some >>> > switches from clientTemplateModel, which were defacto never supported >>> by >>> > admin console and admin REST API and defacto never worked (For example >>> > clientTemplate had switches like standardFlowEnabled, >>> implicitFlowEnabled >>> > etc.). >>> > >>> > >>> > ProtocolMappers and "Role scope mappings" fit well into the >>> > clientScopeModel as they "add" things into the client. Basically >>> client use >>> > all protocolMappers defined on itself and on all "parent" client >>> scopes. >>> > >>> > For resources, authorization scopes and policies, those also "add" >>> things >>> > if I understand correctly? Basically client will use all policies >>> declared >>> > on himself and on all the parent client scopes. So maybe authorization >>> > settings can be also added to client scopes? >>> > >>> >>> Yeah, they add things to a client. So a client may have its own resources >>> and policies + the ones inherited by a template/scope. In this particular >>> case, we are basically sharing common settings across multiple clients. >>> There is no need for a scope definition. >>> >>> >>> > >>> > I am just not sure if it fits into the "optional" scopes as it would >>> mean >>> > that some policies (and resources and authorization scopes) will be >>> used >>> > based on the value of "scope" parameter. But maybe yes as accessToken >>> and >>> > the authorization tokens will have "scope" parameter on it, so the >>> adapter >>> > will be able to check what policies were used to issue the token and >>> > eventually throw the authorization error if used "scope" is >>> insufficient? >>> > >>> > The other possibility is to use something different than client scopes. >>> > Either revert clientTemplates back (I can still update PR to have both >>> > clientTemplates and clientScopes models available and have both in >>> admin >>> > console, but it will take few days of work and I won't be able to do >>> that >>> > in next few weeks). Or do some other thing for authorization similar to >>> > what clientTemplate was before? >>> >>> >>> > ATM I think that having resources + authorizationScopes + policies >>> defined >>> > on clientScopes would work. But I may miss some contexts. You know >>> more if >>> > those authorization settings fit to the clientScope model or not. >>> > >>> >>> IMO, my use case does not fit into client scopes, at all. What we need >>> is a >>> place where we can define common settings for multiple clients. In fact, >>> I >>> think this is not only useful for this particular use case but wherever >>> you >>> want to allow users to define common settings for clients within the same >>> realm. >>> >>> Sorry for starting this thread so late. I would say that client templates >>> would fit nice, but let's see what others think about it. Not sure about >>> something specific for authorization settings. However ff we decide for >>> something specific, we should probably move authorization stuff to its >>> own >>> menu item in admin console. >>> >>> But I do see value in client templates as a way to define common settings >>> for clients ... >>> >>> >>> >>> > >>> > Marek >>> > >>> > Dne 20.3.2018 v 15:48 Pedro Igor Silva napsal(a): >>> > >>> >> Hi, >>> >> >>> >> I was investigating how we could share authorization settings >>> (resources, >>> >> scopes, and specially policies) across multiple clients. >>> >> >>> >> Until now, I was considering using Client Templates for that. But now >>> that >>> >> Client Templates are gone in favor of Client Scopes, I'm not sure >>> where >>> >> this functionality fits in. >>> >> >>> >> Any suggestion on how we can support this ? IMO, better would be avoid >>> >> another item on the menu for this. But I can't envision other way to >>> do it >>> >> .... >>> >> >>> >> Regards. >>> >> Pedro Igor >>> >> _______________________________________________ >>> >> keycloak-dev mailing list >>> >> keycloak-dev at lists.jboss.org >>> >> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>> >> >>> > >>> > >>> > >>> _______________________________________________ >>> keycloak-dev mailing list >>> keycloak-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>> >> >> > From psilva at redhat.com Wed Mar 21 10:29:16 2018 From: psilva at redhat.com (Pedro Igor Silva) Date: Wed, 21 Mar 2018 11:29:16 -0300 Subject: [keycloak-dev] kcinit screencast In-Reply-To: References: Message-ID: Great stuff ! How are you handling ID Tokens ? Or "kcinit token" is all about access tokens ? My point is that you may want to get only IDToken for authentication purposes only. Also, is there options to: * introspect a token * refresh * dynamic register a client Regards. Pedro Igor On Tue, Mar 20, 2018 at 8:03 PM, Bill Burke wrote: > http://youtu.be/uwkggE25TjM?hd=1 > > -- > Bill Burke > Red Hat > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > From psilva at redhat.com Wed Mar 21 10:29:35 2018 From: psilva at redhat.com (Pedro Igor Silva) Date: Wed, 21 Mar 2018 11:29:35 -0300 Subject: [keycloak-dev] Sharing authorization settings across multiple clients In-Reply-To: References: Message-ID: That is the idea. On Wed, Mar 21, 2018 at 11:13 AM, Stian Thorgersen wrote: > Having a separate entry for authz might make a lot of sense. To take that > to the extreme you could then share everything between clients right? > Resources, policies, you name it. > > On 21 March 2018 at 13:30, Pedro Igor Silva wrote: > >> If you also agree we should have a specific thing for authz services, I'm >> OK with it. >> >> In fact, the first version of authorization services had its own menu >> item in the admin console. Before merging it we found that include it as a >> tab in Client UI was better. >> >> It should not require too much time to move the authorization bits from >> Client UI to its own menu item in the admin console. Main work will be docs >> and reviewing quickstarts. Does "Authorization Services" sounds like a good >> name for this menu item ? >> >> >> >> On Tue, Mar 20, 2018 at 5:54 PM, Stian Thorgersen >> wrote: >> >>> I agree that this doesn't fit into client scope. >>> >>> Perhaps we should have kept client templates and just removed protocol >>> mappers and scope from it. Not sure it has a wider use-cases than >>> authorization services though. So perhaps the best would be to have some >>> sort of authorization services specific thing? >>> >>> On 20 March 2018 at 21:16, Pedro Igor Silva wrote: >>> >>>> On Tue, Mar 20, 2018 at 1:32 PM, Marek Posolda >>>> wrote: >>>> >>>> > The difference between clientScopes and clientTemplates is, that >>>> > client-clientTemplate mapping is 1:1 . But client-clientScope mapping >>>> will >>>> > be 1:N. >>>> > >>>> > So in the PR I've removed some configuration things from >>>> clientTemplate >>>> > due the potential conflicts with 1:N mapping. For example if client >>>> would >>>> > inherit from 2 client scopes called "scope1" and "scope2" . And >>>> "scope1" >>>> > would have "Login theme" value "sunrise", but "scope2" would have >>>> "Login >>>> > theme" value "keycloak". Then client wouldn't know if it should use >>>> > "sunrise" or "keycloak" theme. >>>> >>>> >>>> > Those configuration switches just don't fit well to the client scope >>>> > model. So I removed login theme override from admin console and some >>>> > switches from clientTemplateModel, which were defacto never supported >>>> by >>>> > admin console and admin REST API and defacto never worked (For example >>>> > clientTemplate had switches like standardFlowEnabled, >>>> implicitFlowEnabled >>>> > etc.). >>>> > >>>> > >>>> > ProtocolMappers and "Role scope mappings" fit well into the >>>> > clientScopeModel as they "add" things into the client. Basically >>>> client use >>>> > all protocolMappers defined on itself and on all "parent" client >>>> scopes. >>>> > >>>> > For resources, authorization scopes and policies, those also "add" >>>> things >>>> > if I understand correctly? Basically client will use all policies >>>> declared >>>> > on himself and on all the parent client scopes. So maybe authorization >>>> > settings can be also added to client scopes? >>>> > >>>> >>>> Yeah, they add things to a client. So a client may have its own >>>> resources >>>> and policies + the ones inherited by a template/scope. In this >>>> particular >>>> case, we are basically sharing common settings across multiple clients. >>>> There is no need for a scope definition. >>>> >>>> >>>> > >>>> > I am just not sure if it fits into the "optional" scopes as it would >>>> mean >>>> > that some policies (and resources and authorization scopes) will be >>>> used >>>> > based on the value of "scope" parameter. But maybe yes as accessToken >>>> and >>>> > the authorization tokens will have "scope" parameter on it, so the >>>> adapter >>>> > will be able to check what policies were used to issue the token and >>>> > eventually throw the authorization error if used "scope" is >>>> insufficient? >>>> > >>>> > The other possibility is to use something different than client >>>> scopes. >>>> > Either revert clientTemplates back (I can still update PR to have both >>>> > clientTemplates and clientScopes models available and have both in >>>> admin >>>> > console, but it will take few days of work and I won't be able to do >>>> that >>>> > in next few weeks). Or do some other thing for authorization similar >>>> to >>>> > what clientTemplate was before? >>>> >>>> >>>> > ATM I think that having resources + authorizationScopes + policies >>>> defined >>>> > on clientScopes would work. But I may miss some contexts. You know >>>> more if >>>> > those authorization settings fit to the clientScope model or not. >>>> > >>>> >>>> IMO, my use case does not fit into client scopes, at all. What we need >>>> is a >>>> place where we can define common settings for multiple clients. In >>>> fact, I >>>> think this is not only useful for this particular use case but wherever >>>> you >>>> want to allow users to define common settings for clients within the >>>> same >>>> realm. >>>> >>>> Sorry for starting this thread so late. I would say that client >>>> templates >>>> would fit nice, but let's see what others think about it. Not sure about >>>> something specific for authorization settings. However ff we decide for >>>> something specific, we should probably move authorization stuff to its >>>> own >>>> menu item in admin console. >>>> >>>> But I do see value in client templates as a way to define common >>>> settings >>>> for clients ... >>>> >>>> >>>> >>>> > >>>> > Marek >>>> > >>>> > Dne 20.3.2018 v 15:48 Pedro Igor Silva napsal(a): >>>> > >>>> >> Hi, >>>> >> >>>> >> I was investigating how we could share authorization settings >>>> (resources, >>>> >> scopes, and specially policies) across multiple clients. >>>> >> >>>> >> Until now, I was considering using Client Templates for that. But >>>> now that >>>> >> Client Templates are gone in favor of Client Scopes, I'm not sure >>>> where >>>> >> this functionality fits in. >>>> >> >>>> >> Any suggestion on how we can support this ? IMO, better would be >>>> avoid >>>> >> another item on the menu for this. But I can't envision other way to >>>> do it >>>> >> .... >>>> >> >>>> >> Regards. >>>> >> Pedro Igor >>>> >> _______________________________________________ >>>> >> keycloak-dev mailing list >>>> >> keycloak-dev at lists.jboss.org >>>> >> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>>> >> >>>> > >>>> > >>>> > >>>> _______________________________________________ >>>> keycloak-dev mailing list >>>> keycloak-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>>> >>> >>> >> > From mposolda at redhat.com Wed Mar 21 15:52:22 2018 From: mposolda at redhat.com (Marek Posolda) Date: Wed, 21 Mar 2018 20:52:22 +0100 Subject: [keycloak-dev] Sharing authorization settings across multiple clients In-Reply-To: References: Message-ID: <4e5e5d6a-55a8-6f8f-2ca5-4e68ad9306e2@redhat.com> Ok, if you think that having authz as first class citizen, then let's go with it. Still, if you want to revert clientTemplate, it's not yet late :) But clientScope PR will need to be re-done to have both clientTemplate and clientScope exists together. Question is, if we have some other similar use-case (some common configuration to be shared between multiple clients). But looks that no? Until now, we used it just for login theme, which was quite a minor thing. Marek Dne 21.3.2018 v 15:29 Pedro Igor Silva napsal(a): > That is the idea. > > On Wed, Mar 21, 2018 at 11:13 AM, Stian Thorgersen > > wrote: > > Having a separate entry for authz might make a lot of sense. To > take that to the extreme you could then share everything between > clients right? Resources, policies, you name it. > > On 21 March 2018 at 13:30, Pedro Igor Silva > wrote: > > If you also agree we should have a specific thing for authz > services, I'm OK with it. > > In fact, the first version of authorization services had its > own menu item in the admin console. Before merging it we found > that include it as a tab in Client UI was better. > > It should not require too much time to move the authorization > bits from Client UI to its own menu item in the admin console. > Main work will be docs and reviewing quickstarts. Does > "Authorization Services" sounds like a good name for this menu > item ? > > > > On Tue, Mar 20, 2018 at 5:54 PM, Stian Thorgersen > > wrote: > > I agree that this doesn't fit into client scope. > > Perhaps we should have kept client templates and just > removed protocol mappers and scope from it. Not sure it > has a wider use-cases than authorization services though. > So perhaps the best would be to have some sort of > authorization services specific thing? > > On 20 March 2018 at 21:16, Pedro Igor Silva > > wrote: > > On Tue, Mar 20, 2018 at 1:32 PM, Marek Posolda > > wrote: > > > The difference between clientScopes and > clientTemplates is, that > > client-clientTemplate mapping is 1:1 . But > client-clientScope mapping will > > be 1:N. > > > > So in the PR I've removed some configuration things > from clientTemplate > > due the potential conflicts with 1:N mapping. For > example if client would > > inherit from 2 client scopes called "scope1" and > "scope2" . And "scope1" > > would have "Login theme" value "sunrise", but > "scope2" would have "Login > > theme" value "keycloak". Then client wouldn't know > if it should use > > "sunrise" or "keycloak" theme. > > > > Those configuration switches just don't fit well to > the client scope > > model. So I removed login theme override from admin > console and some > > switches from clientTemplateModel, which were > defacto never supported by > > admin console and admin REST API and defacto never > worked (For example > > clientTemplate had switches like > standardFlowEnabled, implicitFlowEnabled > > etc.). > > > > > > ProtocolMappers and "Role scope mappings" fit well > into the > > clientScopeModel as they "add" things into the > client. Basically client use > > all protocolMappers defined on itself and on all > "parent" client scopes. > > > > For resources, authorization scopes and policies, > those also "add" things > > if I understand correctly? Basically client will use > all policies declared > > on himself and on all the parent client scopes. So > maybe authorization > > settings can be also added to client scopes? > > > > Yeah, they add things to a client. So a client may > have its own resources > and policies + the ones inherited by a template/scope. > In this particular > case, we are basically sharing common settings across > multiple clients. > There is no need for a scope definition. > > > > > > I am just not sure if it fits into the "optional" > scopes as it would mean > > that some policies (and resources and authorization > scopes) will be used > > based on the value of "scope" parameter. But maybe > yes as accessToken and > > the authorization tokens will have "scope" parameter > on it, so the adapter > > will be able to check what policies were used to > issue the token and > > eventually throw the authorization error if used > "scope" is insufficient? > > > > The other possibility is to use something different > than client scopes. > > Either revert clientTemplates back (I can still > update PR to have both > > clientTemplates and clientScopes models available > and have both in admin > > console, but it will take few days of work and I > won't be able to do that > > in next few weeks). Or do some other thing for > authorization similar to > > what clientTemplate was before? > > > > ATM I think that having resources + > authorizationScopes + policies defined > > on clientScopes would work. But I may miss some > contexts. You know more if > > those authorization settings fit to the clientScope > model or not. > > > > IMO, my use case does not fit into client scopes, at > all. What we need is a > place where we can define common settings for multiple > clients. In fact, I > think this is not only useful for this particular use > case but wherever you > want to allow users to define common settings for > clients within the same > realm. > > Sorry for starting this thread so late. I would say > that client templates > would fit nice, but let's see what others think about > it. Not sure about > something specific for authorization settings. However > ff we decide for > something specific, we should probably move > authorization stuff to its own > menu item in admin console. > > But I do see value in client templates as a way to > define common settings > for clients ... > > > > > > > Marek > > > > Dne 20.3.2018 v 15:48 Pedro Igor Silva napsal(a): > > > >> Hi, > >> > >> I was investigating how we could share > authorization settings (resources, > >> scopes, and specially policies) across multiple > clients. > >> > >> Until now, I was considering using Client Templates > for that. But now that > >> Client Templates are gone in favor of Client > Scopes, I'm not sure where > >> this functionality fits in. > >> > >> Any suggestion on how we can support this ? IMO, > better would be avoid > >> another item on the menu for this. But I can't > envision other way to do it > >> .... > >> > >> Regards. > >> Pedro Igor > >> _______________________________________________ > >> keycloak-dev mailing list > >> keycloak-dev at lists.jboss.org > > >> > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > >> > > > > > > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > > > > From psilva at redhat.com Wed Mar 21 16:26:42 2018 From: psilva at redhat.com (Pedro Igor Silva) Date: Wed, 21 Mar 2018 17:26:42 -0300 Subject: [keycloak-dev] Sharing authorization settings across multiple clients In-Reply-To: <4e5e5d6a-55a8-6f8f-2ca5-4e68ad9306e2@redhat.com> References: <4e5e5d6a-55a8-6f8f-2ca5-4e68ad9306e2@redhat.com> Message-ID: I think we decided in another thread to have a specific menu item for authorization settings. You won't need to change what you did. I've created https://issues.jboss.org/browse/KEYCLOAK-6956. On Wed, Mar 21, 2018 at 4:52 PM, Marek Posolda wrote: > Ok, if you think that having authz as first class citizen, then let's go > with it. > > Still, if you want to revert clientTemplate, it's not yet late :) But > clientScope PR will need to be re-done to have both clientTemplate and > clientScope exists together. Question is, if we have some other similar > use-case (some common configuration to be shared between multiple clients). > But looks that no? Until now, we used it just for login theme, which was > quite a minor thing. > > Marek > > > Dne 21.3.2018 v 15:29 Pedro Igor Silva napsal(a): > > That is the idea. > > On Wed, Mar 21, 2018 at 11:13 AM, Stian Thorgersen > wrote: > >> Having a separate entry for authz might make a lot of sense. To take that >> to the extreme you could then share everything between clients right? >> Resources, policies, you name it. >> >> On 21 March 2018 at 13:30, Pedro Igor Silva wrote: >> >>> If you also agree we should have a specific thing for authz services, >>> I'm OK with it. >>> >>> In fact, the first version of authorization services had its own menu >>> item in the admin console. Before merging it we found that include it as a >>> tab in Client UI was better. >>> >>> It should not require too much time to move the authorization bits from >>> Client UI to its own menu item in the admin console. Main work will be docs >>> and reviewing quickstarts. Does "Authorization Services" sounds like a good >>> name for this menu item ? >>> >>> >>> >>> On Tue, Mar 20, 2018 at 5:54 PM, Stian Thorgersen >>> wrote: >>> >>>> I agree that this doesn't fit into client scope. >>>> >>>> Perhaps we should have kept client templates and just removed protocol >>>> mappers and scope from it. Not sure it has a wider use-cases than >>>> authorization services though. So perhaps the best would be to have some >>>> sort of authorization services specific thing? >>>> >>>> On 20 March 2018 at 21:16, Pedro Igor Silva wrote: >>>> >>>>> On Tue, Mar 20, 2018 at 1:32 PM, Marek Posolda >>>>> wrote: >>>>> >>>>> > The difference between clientScopes and clientTemplates is, that >>>>> > client-clientTemplate mapping is 1:1 . But client-clientScope >>>>> mapping will >>>>> > be 1:N. >>>>> > >>>>> > So in the PR I've removed some configuration things from >>>>> clientTemplate >>>>> > due the potential conflicts with 1:N mapping. For example if client >>>>> would >>>>> > inherit from 2 client scopes called "scope1" and "scope2" . And >>>>> "scope1" >>>>> > would have "Login theme" value "sunrise", but "scope2" would have >>>>> "Login >>>>> > theme" value "keycloak". Then client wouldn't know if it should use >>>>> > "sunrise" or "keycloak" theme. >>>>> >>>>> >>>>> > Those configuration switches just don't fit well to the client scope >>>>> > model. So I removed login theme override from admin console and some >>>>> > switches from clientTemplateModel, which were defacto never >>>>> supported by >>>>> > admin console and admin REST API and defacto never worked (For >>>>> example >>>>> > clientTemplate had switches like standardFlowEnabled, >>>>> implicitFlowEnabled >>>>> > etc.). >>>>> > >>>>> > >>>>> > ProtocolMappers and "Role scope mappings" fit well into the >>>>> > clientScopeModel as they "add" things into the client. Basically >>>>> client use >>>>> > all protocolMappers defined on itself and on all "parent" client >>>>> scopes. >>>>> > >>>>> > For resources, authorization scopes and policies, those also "add" >>>>> things >>>>> > if I understand correctly? Basically client will use all policies >>>>> declared >>>>> > on himself and on all the parent client scopes. So maybe >>>>> authorization >>>>> > settings can be also added to client scopes? >>>>> > >>>>> >>>>> Yeah, they add things to a client. So a client may have its own >>>>> resources >>>>> and policies + the ones inherited by a template/scope. In this >>>>> particular >>>>> case, we are basically sharing common settings across multiple clients. >>>>> There is no need for a scope definition. >>>>> >>>>> >>>>> > >>>>> > I am just not sure if it fits into the "optional" scopes as it would >>>>> mean >>>>> > that some policies (and resources and authorization scopes) will be >>>>> used >>>>> > based on the value of "scope" parameter. But maybe yes as >>>>> accessToken and >>>>> > the authorization tokens will have "scope" parameter on it, so the >>>>> adapter >>>>> > will be able to check what policies were used to issue the token and >>>>> > eventually throw the authorization error if used "scope" is >>>>> insufficient? >>>>> > >>>>> > The other possibility is to use something different than client >>>>> scopes. >>>>> > Either revert clientTemplates back (I can still update PR to have >>>>> both >>>>> > clientTemplates and clientScopes models available and have both in >>>>> admin >>>>> > console, but it will take few days of work and I won't be able to do >>>>> that >>>>> > in next few weeks). Or do some other thing for authorization similar >>>>> to >>>>> > what clientTemplate was before? >>>>> >>>>> >>>>> > ATM I think that having resources + authorizationScopes + policies >>>>> defined >>>>> > on clientScopes would work. But I may miss some contexts. You know >>>>> more if >>>>> > those authorization settings fit to the clientScope model or not. >>>>> > >>>>> >>>>> IMO, my use case does not fit into client scopes, at all. What we need >>>>> is a >>>>> place where we can define common settings for multiple clients. In >>>>> fact, I >>>>> think this is not only useful for this particular use case but >>>>> wherever you >>>>> want to allow users to define common settings for clients within the >>>>> same >>>>> realm. >>>>> >>>>> Sorry for starting this thread so late. I would say that client >>>>> templates >>>>> would fit nice, but let's see what others think about it. Not sure >>>>> about >>>>> something specific for authorization settings. However ff we decide for >>>>> something specific, we should probably move authorization stuff to its >>>>> own >>>>> menu item in admin console. >>>>> >>>>> But I do see value in client templates as a way to define common >>>>> settings >>>>> for clients ... >>>>> >>>>> >>>>> >>>>> > >>>>> > Marek >>>>> > >>>>> > Dne 20.3.2018 v 15:48 Pedro Igor Silva napsal(a): >>>>> > >>>>> >> Hi, >>>>> >> >>>>> >> I was investigating how we could share authorization settings >>>>> (resources, >>>>> >> scopes, and specially policies) across multiple clients. >>>>> >> >>>>> >> Until now, I was considering using Client Templates for that. But >>>>> now that >>>>> >> Client Templates are gone in favor of Client Scopes, I'm not sure >>>>> where >>>>> >> this functionality fits in. >>>>> >> >>>>> >> Any suggestion on how we can support this ? IMO, better would be >>>>> avoid >>>>> >> another item on the menu for this. But I can't envision other way >>>>> to do it >>>>> >> .... >>>>> >> >>>>> >> Regards. >>>>> >> Pedro Igor >>>>> >> _______________________________________________ >>>>> >> keycloak-dev mailing list >>>>> >> keycloak-dev at lists.jboss.org >>>>> >> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>>>> >> >>>>> > >>>>> > >>>>> > >>>>> _______________________________________________ >>>>> keycloak-dev mailing list >>>>> keycloak-dev at lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>>>> >>>> >>>> >>> >> > > From bburke at redhat.com Wed Mar 21 22:45:33 2018 From: bburke at redhat.com (Bill Burke) Date: Wed, 21 Mar 2018 22:45:33 -0400 Subject: [keycloak-dev] kcinit screencast In-Reply-To: References: Message-ID: On Wed, Mar 21, 2018 at 10:08 AM, Stian Thorgersen wrote: > That's really nice. First time I see oauth done well from the command line. > > I think it could do with some more newlines in places to space the outputs a > bit more apart. Minor thing though. > I fixed some of those issues. reading in masked input (password) was eating the newline. > Thinking a bit about the confidential client when invoking the token > exchange. As kcinit really is a public client how do you envision folks > would use that? > That isn't true. kcinit can be a confidential client. A client secret isa 2nd factor credential which grants the machine permission to request a login. I was thinking of the idea of a "device token" that could be used as the client-secret. A client could have many device tokens that could be created/revoked. Then you just create a device token for kcinit for the machine you install it on. Most admins will probably be lazy though and just have a public client or a client secret that is shared by everybody. > Could another option be to use the ID token (or some other special SSO login > token) to allow obtaining tokens for different clients? > What you're describing is token exchange.. :-) 1. kcinit login - obtains an access token from master client 2. kcinit token app - exchanges access token retrieved in step 1 So, the access token received in step one acts as an "ID Token", with the caveat that the realm admin can control which applications you can exchange a token for. > I was thinking something like "kcinit login" obtains the ID token (or the > other SSO login token aka something to replace the SSO cookie on web). It > could also request an offline session to have the tool connected long term > (i.e. for a bot or something). Then next time you want to obtain a token for > a specific client it can just pass this SSO login token instead of user > creds to retrieve tokens for that app. > offline access does the same thing doesn't it? > One question which is relevant if you use token exchange as well as if > there's some sort of SSO login token is how do we prevent an application > from obtaining a token for another app. App A for instance could just invoke > kcinit internally without the user knowing about it to obtain token for App > B. > Do you mean a rogue command line application? Or the remote application? If you mean a remote application, then you don't use a public client for kcinit. If you don't use a public client for kcinit, then the app won't be able to exchange because it won't have permission to.... Hmmm...I wonder if we could have the server generate a key. Stuff a hash from that key into the token. Return the key used within AccessTokenResponse. Then the public client uses this key as a client credential when requesting an exchange. Then rogue remote applications can't impersonate the public client to exchange the token, because it won't have the temporary key. > > > On 21 March 2018 at 00:03, Bill Burke wrote: >> >> http://youtu.be/uwkggE25TjM?hd=1 >> >> -- >> Bill Burke >> Red Hat >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev > > -- Bill Burke Red Hat From bburke at redhat.com Wed Mar 21 23:01:18 2018 From: bburke at redhat.com (Bill Burke) Date: Wed, 21 Mar 2018 23:01:18 -0400 Subject: [keycloak-dev] kcinit screencast In-Reply-To: References: Message-ID: On Wed, Mar 21, 2018 at 10:45 PM, Bill Burke wrote: > On Wed, Mar 21, 2018 at 10:08 AM, Stian Thorgersen wrote: >> That's really nice. First time I see oauth done well from the command line. >> >> I think it could do with some more newlines in places to space the outputs a >> bit more apart. Minor thing though. >> > > I fixed some of those issues. reading in masked input (password) was > eating the newline. > >> Thinking a bit about the confidential client when invoking the token >> exchange. As kcinit really is a public client how do you envision folks >> would use that? >> > > That isn't true. kcinit can be a confidential client. A client > secret isa 2nd factor credential which grants the machine permission > to request a login. I was thinking of the idea of a "device token" > that could be used as the client-secret. A client could have many > device tokens that could be created/revoked. Then you just create a > device token for kcinit for the machine you install it on. > > Most admins will probably be lazy though and just have a public client > or a client secret that is shared by everybody. > >> Could another option be to use the ID token (or some other special SSO login >> token) to allow obtaining tokens for different clients? >> > > What you're describing is token exchange.. :-) > > 1. kcinit login - obtains an access token from master client > 2. kcinit token app - exchanges access token retrieved in step 1 > > So, the access token received in step one acts as an "ID Token", with > the caveat that the realm admin can control which applications you can > exchange a token for. > >> I was thinking something like "kcinit login" obtains the ID token (or the >> other SSO login token aka something to replace the SSO cookie on web). It >> could also request an offline session to have the tool connected long term >> (i.e. for a bot or something). Then next time you want to obtain a token for >> a specific client it can just pass this SSO login token instead of user >> creds to retrieve tokens for that app. >> > > offline access does the same thing doesn't it? > > > >> One question which is relevant if you use token exchange as well as if >> there's some sort of SSO login token is how do we prevent an application >> from obtaining a token for another app. App A for instance could just invoke >> kcinit internally without the user knowing about it to obtain token for App >> B. >> > > Do you mean a rogue command line application? Or the remote > application? If you mean a remote application, then you don't use a > public client for kcinit. If you don't use a public client for > kcinit, then the app won't be able to exchange because it won't have > permission to.... Hmmm...I wonder if we could have the server generate > a key. Stuff a hash from that key into the token. Return the key > used within AccessTokenResponse. Then the public client uses this key > as a client credential when requesting an exchange. Then rogue remote > applications can't impersonate the public client to exchange the > token, because it won't have the temporary key. > Thought of a better idea...Public clients can only exchange a refresh token. The refresh token is used as a client credential. Token exchange endpoint looks at the passed in client_id. it must match the issuedFor claim in the refresh token. -- Bill Burke Red Hat From sthorger at redhat.com Thu Mar 22 00:38:24 2018 From: sthorger at redhat.com (Stian Thorgersen) Date: Thu, 22 Mar 2018 05:38:24 +0100 Subject: [keycloak-dev] kcinit screencast In-Reply-To: References: Message-ID: Better idea than what? The server generated key? Does it still need a confidential client? I think that would be a blocking point as I can't see the admin creating a client per-user that wants to use kcinit. Nor do I think users should have to deal with yet another credential. I don't quite understand why the token exchange service is needed at all. In the web browser we allow SSO logins by a simple cookie. Why not just do something similar for kcinit? It gets a cookie (or some sort of token) that can be used to call direct grant again. Seems so much simpler than using token exchange here. On 22 March 2018 at 04:01, Bill Burke wrote: > On Wed, Mar 21, 2018 at 10:45 PM, Bill Burke wrote: > > On Wed, Mar 21, 2018 at 10:08 AM, Stian Thorgersen > wrote: > >> That's really nice. First time I see oauth done well from the command > line. > >> > >> I think it could do with some more newlines in places to space the > outputs a > >> bit more apart. Minor thing though. > >> > > > > I fixed some of those issues. reading in masked input (password) was > > eating the newline. > > > >> Thinking a bit about the confidential client when invoking the token > >> exchange. As kcinit really is a public client how do you envision folks > >> would use that? > >> > > > > That isn't true. kcinit can be a confidential client. A client > > secret isa 2nd factor credential which grants the machine permission > > to request a login. I was thinking of the idea of a "device token" > > that could be used as the client-secret. A client could have many > > device tokens that could be created/revoked. Then you just create a > > device token for kcinit for the machine you install it on. > > > > Most admins will probably be lazy though and just have a public client > > or a client secret that is shared by everybody. > > > >> Could another option be to use the ID token (or some other special SSO > login > >> token) to allow obtaining tokens for different clients? > >> > > > > What you're describing is token exchange.. :-) > > > > 1. kcinit login - obtains an access token from master client > > 2. kcinit token app - exchanges access token retrieved in step 1 > > > > So, the access token received in step one acts as an "ID Token", with > > the caveat that the realm admin can control which applications you can > > exchange a token for. > > > >> I was thinking something like "kcinit login" obtains the ID token (or > the > >> other SSO login token aka something to replace the SSO cookie on web). > It > >> could also request an offline session to have the tool connected long > term > >> (i.e. for a bot or something). Then next time you want to obtain a > token for > >> a specific client it can just pass this SSO login token instead of user > >> creds to retrieve tokens for that app. > >> > > > > offline access does the same thing doesn't it? > > > > > > > >> One question which is relevant if you use token exchange as well as if > >> there's some sort of SSO login token is how do we prevent an application > >> from obtaining a token for another app. App A for instance could just > invoke > >> kcinit internally without the user knowing about it to obtain token for > App > >> B. > >> > > > > Do you mean a rogue command line application? Or the remote > > application? If you mean a remote application, then you don't use a > > public client for kcinit. If you don't use a public client for > > kcinit, then the app won't be able to exchange because it won't have > > permission to.... Hmmm...I wonder if we could have the server generate > > a key. Stuff a hash from that key into the token. Return the key > > used within AccessTokenResponse. Then the public client uses this key > > as a client credential when requesting an exchange. Then rogue remote > > applications can't impersonate the public client to exchange the > > token, because it won't have the temporary key. > > > > Thought of a better idea...Public clients can only exchange a refresh > token. The refresh token is used as a client credential. Token > exchange endpoint looks at the passed in client_id. it must match the > issuedFor claim in the refresh token. > > > -- > Bill Burke > Red Hat > From bburke at redhat.com Thu Mar 22 01:42:08 2018 From: bburke at redhat.com (Bill Burke) Date: Thu, 22 Mar 2018 01:42:08 -0400 Subject: [keycloak-dev] kcinit screencast In-Reply-To: References: Message-ID: On Thu, Mar 22, 2018 at 12:38 AM, Stian Thorgersen wrote: > Better idea than what? The server generated key? > I'm saying that exchanging with a refresh-token removes the need for a confidential client. > Does it still need a confidential client? I think that would be a blocking > point as I can't see the admin creating a client per-user that wants to use > kcinit. Nor do I think users should have to deal with yet another > credential. > I also don't like the idea of an admin creating a client per-user, hence the previous idea of a persistent "device token". Like for instance with my iTunes app, has a menu item "Authorize this computer". Making purchaes still requires me to enter in my user credentials. The solution can already work with public clients. The "refresh_token" tweak I described just makes things more secure. > I don't quite understand why the token exchange service is needed at all. In > the web browser we allow SSO logins by a simple cookie. Why not just do > something similar for kcinit? It gets a cookie (or some sort of token) that > can be used to call direct grant again. Seems so much simpler than using > token exchange here. > I was originally going to use your idea...You proposed it months ago...BUT... You need to revisit how the browser handles an SSO session... Even if the cookie is set, each confidential client in the SSO sesssion must provide its credentials in the code to token flow to get an access token. Your proposal is NOT the same thing as a browser SSO session. Your proposal basically grants a public client to be able to exchange for any token it wants. I hope you see the security implications of that. Token exchange is only one simple HTTP request, which from a client coding perspective is not more complex than your proposal. There is some complexity in the admin console setup. Currently you can grant permission to a client to be able to exchange any token for any client. OR...You can have more fine grain control and explicitly grant permission for a smaller set. IMO, this is a much better solution than having a "special token" that can get a token to invoke on any service. Wouldn't your proposal require granting permission to the public client to be able to ask for this "special token"? Do you see how similar your proposal is to the existing solution? Also, token exchange is not required at all if the initial token has permissions to invoke on any service already. I know some people are using Keycloak in this way. For instance, with kubernetes+keycloak integration, you just need Keycloak to validate the username string. Kubernetes can grant permission to a username string to adminstrate kubernetes. Hope I'm making sense. Finally, kcinit would need token exchange to be able to bridge to external token architectures. Login with Keycloak, exchange for an OpenStack Keystone token so you can invoke on OpenStack services. Thanks for the feedback. -- Bill Burke Red Hat From sthorger at redhat.com Thu Mar 22 04:24:58 2018 From: sthorger at redhat.com (Stian Thorgersen) Date: Thu, 22 Mar 2018 09:24:58 +0100 Subject: [keycloak-dev] kcinit screencast In-Reply-To: References: Message-ID: On 22 March 2018 at 06:42, Bill Burke wrote: > On Thu, Mar 22, 2018 at 12:38 AM, Stian Thorgersen > wrote: > > Better idea than what? The server generated key? > > > > I'm saying that exchanging with a refresh-token removes the need for a > confidential client. > > > Does it still need a confidential client? I think that would be a > blocking > > point as I can't see the admin creating a client per-user that wants to > use > > kcinit. Nor do I think users should have to deal with yet another > > credential. > > > > I also don't like the idea of an admin creating a client per-user, > hence the previous idea of a persistent "device token". Like for > instance with my iTunes app, has a menu item "Authorize this > computer". Making purchaes still requires me to enter in my user > credentials. > > The solution can already work with public clients. The > "refresh_token" tweak I described just makes things more secure. > > > I don't quite understand why the token exchange service is needed at > all. In > > the web browser we allow SSO logins by a simple cookie. Why not just do > > something similar for kcinit? It gets a cookie (or some sort of token) > that > > can be used to call direct grant again. Seems so much simpler than using > > token exchange here. > > > > I was originally going to use your idea...You proposed it months > ago...BUT... > > You need to revisit how the browser handles an SSO session... Even if > the cookie is set, each confidential client in the SSO sesssion must > provide its credentials in the code to token flow to get an access > token. Your proposal is NOT the same thing as a browser SSO session. > Your proposal basically grants a public client to be able to exchange > for any token it wants. I hope you see the security implications of > that. > I fully understand how the browser handles the SSO session. I don't think you need to educate me on that. What I had in mind was that there would be public clients for each use-case of kcinit. That could be: * kc-admin-cli - to interact with KC admin endpoints * os-cli - to interact with OS endpoints * etc.. That allows folks to use kcinit configured with any of the above clients. Then you simply get your "SSO token" when you do kclogin. After that you can use direct grant to obtain tokens for each of the clients/use-cases for kcinit. To me that is much simpler to setup and doesn't introduce any security impact beyond what we have today (anyone that can obtain an SSO token probably has access to the user credentials anyways). Anyone that has the user credentials can already do this today for all public clients. So there's no additional leak here. It's much simpler to setup as you don't need to have a special kcinit client that is setup to be able to exchange with the other apps. That being said me may just be discussing a mute point here. I would expect most uses of kcinit would be driven through one specific CLI, which should have its own client in Keycloak. The users should probably login to each separately and any SSO between CLIs may not be that useful. > > Token exchange is only one simple HTTP request, which from a client > coding perspective is not more complex than your proposal. There is > some complexity in the admin console setup. Currently you can grant > permission to a client to be able to exchange any token for any > client. OR...You can have more fine grain control and explicitly > grant permission for a smaller set. IMO, this is a much better > solution than having a "special token" that can get a token to invoke > on any service. Wouldn't your proposal require granting permission to > the public client to be able to ask for this "special token"? Do you > see how similar your proposal is to the existing solution? > > Also, token exchange is not required at all if the initial token has > permissions to invoke on any service already. I know some people are > using Keycloak in this way. For instance, with kubernetes+keycloak > integration, you just need Keycloak to validate the username string. > Kubernetes can grant permission to a username string to adminstrate > kubernetes. Hope I'm making sense. > > Finally, kcinit would need token exchange to be able to bridge to > external token architectures. Login with Keycloak, exchange for an > OpenStack Keystone token so you can invoke on OpenStack services. > > Thanks for the feedback. > > -- > Bill Burke > Red Hat > From bburke at redhat.com Thu Mar 22 11:03:10 2018 From: bburke at redhat.com (Bill Burke) Date: Thu, 22 Mar 2018 11:03:10 -0400 Subject: [keycloak-dev] kcinit screencast In-Reply-To: References: Message-ID: On Thu, Mar 22, 2018 at 4:24 AM, Stian Thorgersen wrote: > > > On 22 March 2018 at 06:42, Bill Burke wrote: >> >> On Thu, Mar 22, 2018 at 12:38 AM, Stian Thorgersen >> wrote: >> > Better idea than what? The server generated key? >> > >> >> I'm saying that exchanging with a refresh-token removes the need for a >> confidential client. >> >> > Does it still need a confidential client? I think that would be a >> > blocking >> > point as I can't see the admin creating a client per-user that wants to >> > use >> > kcinit. Nor do I think users should have to deal with yet another >> > credential. >> > >> >> I also don't like the idea of an admin creating a client per-user, >> hence the previous idea of a persistent "device token". Like for >> instance with my iTunes app, has a menu item "Authorize this >> computer". Making purchaes still requires me to enter in my user >> credentials. >> >> The solution can already work with public clients. The >> "refresh_token" tweak I described just makes things more secure. >> >> > I don't quite understand why the token exchange service is needed at >> > all. In >> > the web browser we allow SSO logins by a simple cookie. Why not just do >> > something similar for kcinit? It gets a cookie (or some sort of token) >> > that >> > can be used to call direct grant again. Seems so much simpler than using >> > token exchange here. >> > >> >> I was originally going to use your idea...You proposed it months >> ago...BUT... >> >> You need to revisit how the browser handles an SSO session... Even if >> the cookie is set, each confidential client in the SSO sesssion must >> provide its credentials in the code to token flow to get an access >> token. Your proposal is NOT the same thing as a browser SSO session. >> Your proposal basically grants a public client to be able to exchange >> for any token it wants. I hope you see the security implications of >> that. > > > I fully understand how the browser handles the SSO session. I don't think > you need to educate me on that. > > What I had in mind was that there would be public clients for each use-case > of kcinit. That could be: > > * kc-admin-cli - to interact with KC admin endpoints > * os-cli - to interact with OS endpoints > * etc.. > > That allows folks to use kcinit configured with any of the above clients. > Then you simply get your "SSO token" when you do kclogin. After that you can > use direct grant to obtain tokens for each of the clients/use-cases for > kcinit. To me that is much simpler to setup and doesn't introduce any > security impact beyond what we have today (anyone that can obtain an SSO > token probably has access to the user credentials anyways). > > Anyone that has the user credentials can already do this today for all > public clients. So there's no additional leak here. It's much simpler to > setup as you don't need to have a special kcinit client that is setup to be > able to exchange with the other apps. > This is a good discussion. Here's some things to think about: * Are "SSO Tokens" available by default? Or must you grant a client permission to request an SSO Token? If "SSO Tokens" are on, out of the box, then SSO tokens would only be grantable through direct grant requests. Otherwise, any client would be able to request them through the code to token flow and you have your leak again. If you can't use code to token flow, then you can't give kcinit the option to launch a browser to complete a required action (i.e. the otp config required action which is much easier to set up within a browser). So can we agree that SSO tokens must be enabled individually for each and every client that wants them? Is a token exchange implementation actually more difficult? Not sure. Let's goo down the setup checklist for each. SSO TOKEN CHECKLIST: - create a kcinit client. - Enable "SSO tokens for kcinit client - Register "urn:ietf:wg:oauth:2.0:oob" as valid redirect uri - For each REST API that has an existing confidential or bearer only client * create a new public client for it. * This new public client must have same client scopes, role scopes, and protocol mappers * Alternatively, instead of creating a new public client, we could just modify the existing client to make it public. - Add client scopes, role scopes, and protocol mappers as required for each REST API that does NOT have an existing client TOKEN EXCHANGE CHECKLIST: Checklist for token exchange: - create 'kcinit' client. - Register "urn:ietf:wg:oauth:2.0:oob" as valid redirect uri - Give permission to "kcinit" to exchange for any client OR - For each REST API that has an existing confidential or bearer only client * Give permissiont o "kcinit" to exhcnage for existing client. We could potentially optimize out this step if "kcinit" is already granted a superset of the client and role scopes the target client requires. - Add client scopes, role scopes, and protocol mappers as required for each REST API that does NOT have an existing client COMPARISON: * SSO Tokens require an extra step in kcinit client setup as you have to know to enable SSO Tokens. * SSO Tokens require public clients, token exchange does not * Token exchange is potentially less config steps if you grant permission to kcinit to exchange for any client or kcinit already has a superset of client and role scopes. SSO Tokens still require setting up public clients. * Number of configuration steps will generally be pretty equal for both sso tokens and token exchange implementations as SSO Tokens still require setting up of public clients. * Token exchange option uses existing solutions. SSO Tokens require new architecture. You made me think real hard on this, but I still like token exchange better. Some of this I had already thought out months ago, but some I hadn't. I still think I made the right design decisions. I'm going to modify token exchange so that public clients can only exchange refresh tokens and make some general feature improvements to the client that Pedro thinks are necessary. You think adding a disabled "kcinit" client would be useful too? > That being said me may just be discussing a mute point here. I would expect > most uses of kcinit would be driven through one specific CLI, which should > have its own client in Keycloak. The users should probably login to each > separately and any SSO between CLIs may not be that useful. > Or this is mute because the token generated for "kcinit" could be created with required claims to invoke on variety of backends. -- Bill Burke Red Hat From sthorger at redhat.com Thu Mar 22 15:12:37 2018 From: sthorger at redhat.com (Stian Thorgersen) Date: Thu, 22 Mar 2018 20:12:37 +0100 Subject: [keycloak-dev] kcinit screencast In-Reply-To: References: Message-ID: You've convinced me and I agree that token exchange is the way to go. Thanks for entertaining me ;) On 22 March 2018 at 16:03, Bill Burke wrote: > On Thu, Mar 22, 2018 at 4:24 AM, Stian Thorgersen > wrote: > > > > > > On 22 March 2018 at 06:42, Bill Burke wrote: > >> > >> On Thu, Mar 22, 2018 at 12:38 AM, Stian Thorgersen > > >> wrote: > >> > Better idea than what? The server generated key? > >> > > >> > >> I'm saying that exchanging with a refresh-token removes the need for a > >> confidential client. > >> > >> > Does it still need a confidential client? I think that would be a > >> > blocking > >> > point as I can't see the admin creating a client per-user that wants > to > >> > use > >> > kcinit. Nor do I think users should have to deal with yet another > >> > credential. > >> > > >> > >> I also don't like the idea of an admin creating a client per-user, > >> hence the previous idea of a persistent "device token". Like for > >> instance with my iTunes app, has a menu item "Authorize this > >> computer". Making purchaes still requires me to enter in my user > >> credentials. > >> > >> The solution can already work with public clients. The > >> "refresh_token" tweak I described just makes things more secure. > >> > >> > I don't quite understand why the token exchange service is needed at > >> > all. In > >> > the web browser we allow SSO logins by a simple cookie. Why not just > do > >> > something similar for kcinit? It gets a cookie (or some sort of token) > >> > that > >> > can be used to call direct grant again. Seems so much simpler than > using > >> > token exchange here. > >> > > >> > >> I was originally going to use your idea...You proposed it months > >> ago...BUT... > >> > >> You need to revisit how the browser handles an SSO session... Even if > >> the cookie is set, each confidential client in the SSO sesssion must > >> provide its credentials in the code to token flow to get an access > >> token. Your proposal is NOT the same thing as a browser SSO session. > >> Your proposal basically grants a public client to be able to exchange > >> for any token it wants. I hope you see the security implications of > >> that. > > > > > > I fully understand how the browser handles the SSO session. I don't think > > you need to educate me on that. > > > > What I had in mind was that there would be public clients for each > use-case > > of kcinit. That could be: > > > > * kc-admin-cli - to interact with KC admin endpoints > > * os-cli - to interact with OS endpoints > > * etc.. > > > > That allows folks to use kcinit configured with any of the above clients. > > Then you simply get your "SSO token" when you do kclogin. After that you > can > > use direct grant to obtain tokens for each of the clients/use-cases for > > kcinit. To me that is much simpler to setup and doesn't introduce any > > security impact beyond what we have today (anyone that can obtain an SSO > > token probably has access to the user credentials anyways). > > > > Anyone that has the user credentials can already do this today for all > > public clients. So there's no additional leak here. It's much simpler to > > setup as you don't need to have a special kcinit client that is setup to > be > > able to exchange with the other apps. > > > > This is a good discussion. Here's some things to think about: > > * Are "SSO Tokens" available by default? Or must you grant a client > permission to request an SSO Token? If "SSO Tokens" are on, out of > the box, then SSO tokens would only be grantable through direct grant > requests. Otherwise, any client would be able to request them through > the code to token flow and you have your leak again. If you can't use > code to token flow, then you can't give kcinit the option to launch a > browser to complete a required action (i.e. the otp config required > action which is much easier to set up within a browser). So can we > agree that SSO tokens must be enabled individually for each and every > client that wants them? > > Is a token exchange implementation actually more difficult? Not sure. > Let's goo down the setup checklist for each. > > SSO TOKEN CHECKLIST: > > - create a kcinit client. > - Enable "SSO tokens for kcinit client > - Register "urn:ietf:wg:oauth:2.0:oob" as valid redirect uri > - For each REST API that has an existing confidential or bearer only client > * create a new public client for it. > * This new public client must have same client scopes, role > scopes, and protocol mappers > * Alternatively, instead of creating a new public client, we > could just modify the existing client to make it public. > - Add client scopes, role scopes, and protocol mappers as required for > each REST API that does NOT have an existing client > > TOKEN EXCHANGE CHECKLIST: > > Checklist for token exchange: > - create 'kcinit' client. > - Register "urn:ietf:wg:oauth:2.0:oob" as valid redirect uri > > - Give permission to "kcinit" to exchange for any client > > OR > > - For each REST API that has an existing confidential or bearer only client > * Give permissiont o "kcinit" to exhcnage for existing client. We > could potentially optimize out this step if "kcinit" is already > granted a superset of the client and role scopes the target client > requires. > > - Add client scopes, role scopes, and protocol mappers as required for > each REST API that does NOT have an existing client > > > COMPARISON: > > * SSO Tokens require an extra step in kcinit client setup as you have > to know to enable SSO Tokens. > * SSO Tokens require public clients, token exchange does not > * Token exchange is potentially less config steps if you grant > permission to kcinit to exchange for any client or kcinit already has > a superset of client and role scopes. SSO Tokens still require > setting up public clients. > * Number of configuration steps will generally be pretty equal for > both sso tokens and token exchange implementations as SSO Tokens still > require setting up of public clients. > * Token exchange option uses existing solutions. SSO Tokens require > new architecture. > > You made me think real hard on this, but I still like token exchange > better. Some of this I had already thought out months ago, but some I > hadn't. I still think I made the right design decisions. > > I'm going to modify token exchange so that public clients can only > exchange refresh tokens and make some general feature improvements to > the client that Pedro thinks are necessary. You think adding a > disabled "kcinit" client would be useful too? > +1 A disabled kcinit would be helpful to give folks a quick starting point > > > That being said me may just be discussing a mute point here. I would > expect > > most uses of kcinit would be driven through one specific CLI, which > should > > have its own client in Keycloak. The users should probably login to each > > separately and any SSO between CLIs may not be that useful. > > > > Or this is mute because the token generated for "kcinit" could be > created with required claims to invoke on variety of backends. > True. The default and most used case will most likely be to have a client that has all required claims, then use token exchange for more advanced use-cases. > > -- > Bill Burke > Red Hat > From sthorger at redhat.com Thu Mar 22 16:03:46 2018 From: sthorger at redhat.com (Stian Thorgersen) Date: Thu, 22 Mar 2018 21:03:46 +0100 Subject: [keycloak-dev] Keycloak 4.0.0.Beta1 is out Message-ID: I'm very pleased to announce the first release of Keycloak 4! To download the release go to the Keycloak homepage . HighlightsBrand new login pages The login pages have received a brand new look. They now look much more modern and clean! Themes and Theme Resources It's now possible to hot-deploy themes to Keycloak through a regular provider deployment. We've also added support for theme resources. Theme resources allows adding additional templates and resources without creating a theme. Perfect for custom authenticators that require additional pages added to the authentication flow. We've also added support to override the theme for specific clients. If that doesn't cover your needs, then there's a new Theme Selector SPI that allows you to implement custom logic to select the theme. Native promise support to keycloak.js The JavaScript adapter now supports native promises. Of course it still has support for the old style promises as well. Both can be used interchangeably. Edit links in documentation To make it easier to contribute changes to the documentation we have added links to all sections of the documentation. This brings you straight to the GitHub editor for the relevant AsciiDoctor file. There's also a quick link to report an issue on a specific page that will include the relevant page in the description. HTTPS support on keycloak.org Thanks to GitHub pages and Let's Encrypt there's finally HTTPS on keycloak.org. About time? Loads more.. The full list of resolved issues is available in JIRA . Upgrading Before you upgrade remember to backup your database and check the upgrade guide for anything that may have changed. From ror6ax at gmail.com Fri Mar 23 05:16:07 2018 From: ror6ax at gmail.com (gregory grey) Date: Fri, 23 Mar 2018 10:16:07 +0100 Subject: [keycloak-dev] Looking for tips on NiFi integration Message-ID: Hi guys, I'm interested in adding Apache NiFi a possibility to use Keycloak as authn/authz provider, instead of their inbuilt mechanisms. The interfaces for doing so are quite permissive in design: https://github.com/apache/nifi-registry/blob/master/nifi-registry-security-api/src/main/java/org/apache/nifi/registry/security/authorization/UserGroupProvider.java Could someone of the core developers please recommend the best way to perform such integration? Do you think it should follow some of the protocols of be custom set of API calls? Any ideas are welcome. Thanks. -- http://ror6ax.github.io/ From sthorger at redhat.com Fri Mar 23 07:00:03 2018 From: sthorger at redhat.com (Stian Thorgersen) Date: Fri, 23 Mar 2018 11:00:03 +0000 Subject: [keycloak-dev] Keycloak 4.0.0.Beta1 is out Message-ID: I missed one cool new feature. We also now have support for UMA 2.0 including allowing users to manage resource permissions in the account management console. On Thu, 22 Mar 2018, 21:03 Stian Thorgersen, wrote: > I'm very pleased to announce the first release of Keycloak 4! > > To download the release go to the Keycloak homepage > . > HighlightsBrand new login pages > > The login pages have received a brand new look. They now look much more > modern and clean! > Themes and Theme Resources > > It's now possible to hot-deploy themes to Keycloak through a regular > provider deployment. We've also added support for theme resources. Theme > resources allows adding additional templates and resources without creating > a theme. Perfect for custom authenticators that require additional pages > added to the authentication flow. > > We've also added support to override the theme for specific clients. If > that doesn't cover your needs, then there's a new Theme Selector SPI that > allows you to implement custom logic to select the theme. > Native promise support to keycloak.js > > The JavaScript adapter now supports native promises. Of course it still > has support for the old style promises as well. Both can be used > interchangeably. > Edit links in documentation > > To make it easier to contribute changes to the documentation we have added > links to all sections of the documentation. This brings you straight to the > GitHub editor for the relevant AsciiDoctor file. There's also a quick link > to report an issue on a specific page that will include the relevant page > in the description. > HTTPS support on keycloak.org > > Thanks to GitHub pages and Let's Encrypt there's finally HTTPS on > keycloak.org. About time? > Loads more.. > > The full list of resolved issues is available in JIRA > > . > Upgrading > > Before you upgrade remember to backup your database and check the upgrade > guide for > anything that may have changed. > From simonpayne58 at gmail.com Fri Mar 23 11:33:21 2018 From: simonpayne58 at gmail.com (Simon Payne) Date: Fri, 23 Mar 2018 15:33:21 +0000 Subject: [keycloak-dev] building keycloak and running tests Message-ID: Hi, is there a way of changing the port, other than find and replace, which keycloak runs on for the integration tests? it is currently set to 8081, but we have mcAfee agent listening already. thanks From carlosthe19916 at gmail.com Sun Mar 25 23:25:01 2018 From: carlosthe19916 at gmail.com (Carlos Feria) Date: Sun, 25 Mar 2018 22:25:01 -0500 Subject: [keycloak-dev] Why Authz examples has been removed from 4.0.0.Beta1 Message-ID: Hi There. I wonder why Authz examples has been removed from Keycloak 4.0.0.Beta1 version. I saw this commit here: https://github.com/keycloak/keycloak/commit/35b9fe043caf10287f4f8c835233df68e0a0c046#diff-bfebe34154a0dfd9fc7b447fc9ed74e9 I'd like to know if Keycloak 4 will change the way authz works on Keycloak 3.4.3.Final?. I have have software projects that works in the same way that photoz authz example use to work. Please I'd like to know your answer. Thanks! -- Carlos E. Feria Vila From mposolda at redhat.com Mon Mar 26 02:55:15 2018 From: mposolda at redhat.com (Marek Posolda) Date: Mon, 26 Mar 2018 08:55:15 +0200 Subject: [keycloak-dev] Why Authz examples has been removed from 4.0.0.Beta1 In-Reply-To: References: Message-ID: They've been moved to quickstarts repository AFAIK. See https://github.com/keycloak/keycloak-quickstarts and the "app-authz-*" examples. Marek On 26/03/18 05:25, Carlos Feria wrote: > Hi There. I wonder why Authz examples has been removed from Keycloak > 4.0.0.Beta1 version. > > I saw this commit here: > > https://github.com/keycloak/keycloak/commit/35b9fe043caf10287f4f8c835233df68e0a0c046#diff-bfebe34154a0dfd9fc7b447fc9ed74e9 > > > I'd like to know if Keycloak 4 will change the way authz works on Keycloak > 3.4.3.Final?. I have have software projects that works in the same way that > photoz authz example use to work. > > Please I'd like to know your answer. Thanks! > > From mposolda at redhat.com Mon Mar 26 02:57:05 2018 From: mposolda at redhat.com (Marek Posolda) Date: Mon, 26 Mar 2018 08:57:05 +0200 Subject: [keycloak-dev] building keycloak and running tests In-Reply-To: References: Message-ID: <4011ffe9-a2bc-b376-cb81-0c35a00aa1a7@redhat.com> Not at this moment AFAIK. You may need to run "mvn clean install -DskipTests=true" or run tests on different laptop. BTV. I think that just "testsuite/integration-deprecated" is using port 8081. The main testsuite "testsuite/integration-arquillian" is using 8180. Marek On 23/03/18 16:33, Simon Payne wrote: > Hi, is there a way of changing the port, other than find and replace, which > keycloak runs on for the integration tests? > > it is currently set to 8081, but we have mcAfee agent listening already. > > thanks > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev From psilva at redhat.com Mon Mar 26 07:53:48 2018 From: psilva at redhat.com (Pedro Igor Silva) Date: Mon, 26 Mar 2018 08:53:48 -0300 Subject: [keycloak-dev] Why Authz examples has been removed from 4.0.0.Beta1 In-Reply-To: References: Message-ID: Like Marek said, they were moved to keycloak-quickstarts repository. Regarding photoz example, I messed up with the merges in upstream and Beta1 was released without photoz [1] being merged to keycloak-quickstarts. We'll fix that until next release. If you want to give it a try, please consider the changes in the PR. Sorry for the confusion. [1] https://github.com/keycloak/keycloak-quickstarts/pull/102 Regards. Pedro Igor On Mon, Mar 26, 2018 at 3:55 AM, Marek Posolda wrote: > They've been moved to quickstarts repository AFAIK. See > https://github.com/keycloak/keycloak-quickstarts and the "app-authz-*" > examples. > > Marek > > On 26/03/18 05:25, Carlos Feria wrote: > > Hi There. I wonder why Authz examples has been removed from Keycloak > > 4.0.0.Beta1 version. > > > > I saw this commit here: > > > > https://github.com/keycloak/keycloak/commit/ > 35b9fe043caf10287f4f8c835233df68e0a0c046#diff- > bfebe34154a0dfd9fc7b447fc9ed74e9 > > > > > > I'd like to know if Keycloak 4 will change the way authz works on > Keycloak > > 3.4.3.Final?. I have have software projects that works in the same way > that > > photoz authz example use to work. > > > > Please I'd like to know your answer. Thanks! > > > > > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > From bburke at redhat.com Mon Mar 26 09:51:07 2018 From: bburke at redhat.com (Bill Burke) Date: Mon, 26 Mar 2018 09:51:07 -0400 Subject: [keycloak-dev] need feedback on integrating golang with testsuite and distro In-Reply-To: References: Message-ID: On Wed, Mar 21, 2018 at 9:52 AM, Stian Thorgersen wrote: > > > On 20 March 2018 at 22:29, Bill Burke wrote: >> >> I have a golang client utility (kcinit) that I need to integrate with >> tests in our testsuite. Its possible to integrate golang with maven >> using this maven plugin: >> >> https://github.com/raydac/mvn-golang >> >> To integrate my tool into the arquillian testsuite, I've pulled in >> this plugin to pull down and build my golang tool so that it can be >> executed within a test. The way it works is that the maven plugin >> will first download the Golang SDK and store it within ~/.mvnGolang. >> It will also store any source code it pulls down and builds there. It >> will build a binary that is specific to the platform it is running on >> so this is perfect for our testsuite. >> >> Sound ok? > > > That works. Would it be best to have a profile for it though? Rather than > having it run every time developers build and test we can add a CI job for > it that would be ran on PRs. That way it's always tested on PRs, but you > don't have to pay the price locally if you haven't touched kinit at all. > its not that bad (an extra 10 secs on my network). If somebody complains I'll change it? >> >> >> Next question is distribution. "kcinit" is a command line utility. >> Should I add this to our current client tools directory in the disto >> or create a separate dis zipt? Ok to include binaries for linux, osx, >> and windows? This will require the maven plugin to individually >> cross-compile for each platform. Its not superfast and our distro >> build will be slower, but we will have one place to pull this stuff >> together. I will need to eventually create an RPM for this tool so >> that it can be automatically installed in Fedora/RHEL. > > > I'd go with a separate dist. It's a client tool and having to download and > extract it from the large server zip would be annoying. > Don't really need a dist, per se, just need to build the binaries for common platforms (osx x86, linux x86, and windows x86). Is publishing downloads to community website automated? Will want a separate download for each platform binary. > Maybe it would be best to have a separate profile here as well? Something > like distribution-cli. It can be disabled by default, but enabled when we do > releases. I know quite a lot of folks regularly builds the server dist while > doing development, myself included. > Yes, should definitely do this. cross-platform builds take awhile. > For Keycloak we can definitively include binaries for all. Can the Maven > plugin build all binaries on Linux? Or do you need to build it on the > individual platforms? If the latter then we have a biggish problem to figure > out when releasing Keycloak. > Golang and the maven plugin can build all platform targets on any OS. -- Bill Burke Red Hat From carlosthe19916 at gmail.com Mon Mar 26 09:53:06 2018 From: carlosthe19916 at gmail.com (Carlos Feria) Date: Mon, 26 Mar 2018 08:53:06 -0500 Subject: [keycloak-dev] Why Authz examples has been removed from 4.0.0.Beta1 In-Reply-To: References: Message-ID: Thank you very much for answering. Now I'm without doubts. On Mon, Mar 26, 2018 at 6:53 AM, Pedro Igor Silva wrote: > Like Marek said, they were moved to keycloak-quickstarts repository. > > Regarding photoz example, I messed up with the merges in upstream and > Beta1 was released without photoz [1] being merged to keycloak-quickstarts. > We'll fix that until next release. If you want to give it a try, please > consider the changes in the PR. > > Sorry for the confusion. > > [1] https://github.com/keycloak/keycloak-quickstarts/pull/102 > > Regards. > Pedro Igor > > On Mon, Mar 26, 2018 at 3:55 AM, Marek Posolda > wrote: > >> They've been moved to quickstarts repository AFAIK. See >> https://github.com/keycloak/keycloak-quickstarts and the "app-authz-*" >> examples. >> >> Marek >> >> On 26/03/18 05:25, Carlos Feria wrote: >> > Hi There. I wonder why Authz examples has been removed from Keycloak >> > 4.0.0.Beta1 version. >> > >> > I saw this commit here: >> > >> > https://github.com/keycloak/keycloak/commit/35b9fe043caf1028 >> 7f4f8c835233df68e0a0c046#diff-bfebe34154a0dfd9fc7b447fc9ed74e9 >> > >> > >> > I'd like to know if Keycloak 4 will change the way authz works on >> Keycloak >> > 3.4.3.Final?. I have have software projects that works in the same way >> that >> > photoz authz example use to work. >> > >> > Please I'd like to know your answer. Thanks! >> > >> > >> >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> > > -- Carlos E. Feria Vila From stokito at gmail.com Mon Mar 26 15:55:08 2018 From: stokito at gmail.com (Sergey Ponomarev) Date: Mon, 26 Mar 2018 22:55:08 +0300 Subject: [keycloak-dev] Keycloak repository is too heavy Message-ID: Hello, I wanted to make a small pull request into keycloak but it passed more than a our but I still not even built the project. First of all it was cloned about 4 minutes. No so much, but a long as for me. Then I started build process and it took a long time to download all dependencies which exists on Maven Central. Meanwhile I opened Keycloak project in Intellij and it started to index all files. Finally at some point build failed with OOM :( I checked and found that Keycloak sources contains about 100Mb of built examples and about 300 Mb of node_modules in themes folder. So my proposition is: how about to split mono repository into few smaller? As I see we can easily move examples and themes into separate repos under keycloak organisation on Github. This will decrease network load and simplify project initialization. But we'll still be able to build examples and themes. Sergey Ponomarev From bburke at redhat.com Mon Mar 26 16:19:59 2018 From: bburke at redhat.com (Bill Burke) Date: Mon, 26 Mar 2018 16:19:59 -0400 Subject: [keycloak-dev] Keycloak repository is too heavy In-Reply-To: References: Message-ID: I would vote no for this. Honestly, your pipe sucks and you need a better machine. A clone for me takes about 5-10 seconds. On Mon, Mar 26, 2018 at 3:55 PM, Sergey Ponomarev wrote: > Hello, > > I wanted to make a small pull request into keycloak > but it passed more than a our but I > still not even built the project. > First of all it was cloned about 4 minutes. No so much, but a long as for > me. > Then I started build process and it took a long time to download all > dependencies which exists on Maven Central. Meanwhile I opened Keycloak > project in Intellij and it started to index all files. > Finally at some point build failed with OOM :( > I checked and found that Keycloak sources contains about 100Mb of built > examples and about 300 Mb of node_modules in themes folder. > So my proposition is: how about to split mono repository into few smaller? > As I see we can easily move examples and themes into separate repos under > keycloak organisation on Github. > > This will decrease network load and simplify project initialization. But > we'll still be able to build examples and themes. > > Sergey Ponomarev > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev -- Bill Burke Red Hat From bruno at abstractj.org Mon Mar 26 16:44:11 2018 From: bruno at abstractj.org (Bruno Oliveira) Date: Mon, 26 Mar 2018 20:44:11 +0000 Subject: [keycloak-dev] Keycloak repository is too heavy In-Reply-To: References: Message-ID: -1 On Mon, Mar 26, 2018 at 4:55 PM Sergey Ponomarev wrote: > Hello, > > I wanted to make a small pull request into keycloak > but it passed more than a our but > I > still not even built the project. > First of all it was cloned about 4 minutes. No so much, but a long as for > me. > Then I started build process and it took a long time to download all > dependencies which exists on Maven Central. Meanwhile I opened Keycloak > project in Intellij and it started to index all files. > Finally at some point build failed with OOM :( > I checked and found that Keycloak sources contains about 100Mb of built > examples and about 300 Mb of node_modules in themes folder. > So my proposition is: how about to split mono repository into few smaller? > As I see we can easily move examples and themes into separate repos under > keycloak organisation on Github. > > This will decrease network load and simplify project initialization. But > we'll still be able to build examples and themes. > > Sergey Ponomarev > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > From bburke at redhat.com Mon Mar 26 22:41:46 2018 From: bburke at redhat.com (Bill Burke) Date: Mon, 26 Mar 2018 22:41:46 -0400 Subject: [keycloak-dev] offline access tokens part 2 Message-ID: These are my thoughts for implementing offline access tokens: * offline access tokens MUST be validated. This means that if they are used during bearer token requests, the service must validate the token with the token endpoint. * These tokens MUST be rejected by older keycloak clients as our adapters dont' have support for them. * offline access tokens will not be stored in the database. Instead they will be JWEs or JWS that link to an offline user session. (our current offline access implementation). They will be revokable just like any other offline session and in the same manner. This makes the implementation simple. * There will be 4 modes for configuring clients - client automatically receives offline access tokens (maybe not include a refresh token in this case) - client may request an offline access token - client requires consent before providing an offline access token - client is not allowed to ask for offline access tokens (default) Any other thoughts on this? Maybe this should be implemented in conjunction with a reference token feature too? -- Bill Burke Red Hat From sthorger at redhat.com Tue Mar 27 01:22:31 2018 From: sthorger at redhat.com (Stian Thorgersen) Date: Tue, 27 Mar 2018 07:22:31 +0200 Subject: [keycloak-dev] Keycloak repository is too heavy In-Reply-To: References: Message-ID: The examples are already being moved to https://github.com/keycloak/keycloak-quickstarts, but that will take some time to complete. The themes contain the node_modules as a temporary measure. These should ideally be downloaded from NPM rather than committed to the repository. However, that would make any difference to you as you'd still need to download them to run Keycloak. On 26 March 2018 at 22:44, Bruno Oliveira wrote: > -1 > > On Mon, Mar 26, 2018 at 4:55 PM Sergey Ponomarev > wrote: > > > Hello, > > > > I wanted to make a small pull request into keycloak > > but it passed more than a our > but > > I > > still not even built the project. > > First of all it was cloned about 4 minutes. No so much, but a long as for > > me. > > Then I started build process and it took a long time to download all > > dependencies which exists on Maven Central. Meanwhile I opened Keycloak > > project in Intellij and it started to index all files. > > Finally at some point build failed with OOM :( > > I checked and found that Keycloak sources contains about 100Mb of built > > examples and about 300 Mb of node_modules in themes folder. > > So my proposition is: how about to split mono repository into few > smaller? > > As I see we can easily move examples and themes into separate repos under > > keycloak organisation on Github. > > > > This will decrease network load and simplify project initialization. But > > we'll still be able to build examples and themes. > > > > Sergey Ponomarev > > _______________________________________________ > > keycloak-dev mailing list > > keycloak-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > From sthorger at redhat.com Tue Mar 27 02:08:31 2018 From: sthorger at redhat.com (Stian Thorgersen) Date: Tue, 27 Mar 2018 08:08:31 +0200 Subject: [keycloak-dev] need feedback on integrating golang with testsuite and distro In-Reply-To: References: Message-ID: On 26 March 2018 at 15:51, Bill Burke wrote: > On Wed, Mar 21, 2018 at 9:52 AM, Stian Thorgersen > wrote: > > > > > > On 20 March 2018 at 22:29, Bill Burke wrote: > >> > >> I have a golang client utility (kcinit) that I need to integrate with > >> tests in our testsuite. Its possible to integrate golang with maven > >> using this maven plugin: > >> > >> https://github.com/raydac/mvn-golang > >> > >> To integrate my tool into the arquillian testsuite, I've pulled in > >> this plugin to pull down and build my golang tool so that it can be > >> executed within a test. The way it works is that the maven plugin > >> will first download the Golang SDK and store it within ~/.mvnGolang. > >> It will also store any source code it pulls down and builds there. It > >> will build a binary that is specific to the platform it is running on > >> so this is perfect for our testsuite. > >> > >> Sound ok? > > > > > > That works. Would it be best to have a profile for it though? Rather than > > having it run every time developers build and test we can add a CI job > for > > it that would be ran on PRs. That way it's always tested on PRs, but you > > don't have to pay the price locally if you haven't touched kinit at all. > > > > its not that bad (an extra 10 secs on my network). If somebody > complains I'll change it? > Ok, let's just leave it. > > >> > >> > >> Next question is distribution. "kcinit" is a command line utility. > >> Should I add this to our current client tools directory in the disto > >> or create a separate dis zipt? Ok to include binaries for linux, osx, > >> and windows? This will require the maven plugin to individually > >> cross-compile for each platform. Its not superfast and our distro > >> build will be slower, but we will have one place to pull this stuff > >> together. I will need to eventually create an RPM for this tool so > >> that it can be automatically installed in Fedora/RHEL. > > > > > > I'd go with a separate dist. It's a client tool and having to download > and > > extract it from the large server zip would be annoying. > > > > Don't really need a dist, per se, just need to build the binaries for > common platforms (osx x86, linux x86, and windows x86). > > Is publishing downloads to community website automated? Will want a > separate download for each platform binary. > Yes, the whole build and release of Keycloak is automated with Jenkins jobs. The binaries are just a single file right? So no need to use a ZIP or anything and users can just download kcinit directly for their platform? > > > Maybe it would be best to have a separate profile here as well? Something > > like distribution-cli. It can be disabled by default, but enabled when > we do > > releases. I know quite a lot of folks regularly builds the server dist > while > > doing development, myself included. > > > > Yes, should definitely do this. cross-platform builds take awhile. > > > For Keycloak we can definitively include binaries for all. Can the Maven > > plugin build all binaries on Linux? Or do you need to build it on the > > individual platforms? If the latter then we have a biggish problem to > figure > > out when releasing Keycloak. > > > > Golang and the maven plugin can build all platform targets on any OS. > Makes me think that it may just be simpler to build the dist in the main Keycloak repo. We already have some modules that are already only built as part of jboss-release profile in distribution/pom.xml, so probably just do that. I can update the jobs that upload to downloads.jboss.org and the website if you want. Then you don't have to spend time figuring out that stuff as well. > > > -- > Bill Burke > Red Hat > From mposolda at redhat.com Tue Mar 27 02:53:55 2018 From: mposolda at redhat.com (Marek Posolda) Date: Tue, 27 Mar 2018 08:53:55 +0200 Subject: [keycloak-dev] offline access tokens part 2 In-Reply-To: References: Message-ID: <6833362f-c904-519d-4642-61a79087270d@redhat.com> Dne 27.3.2018 v 04:41 Bill Burke napsal(a): > These are my thoughts for implementing offline access tokens: > > * offline access tokens MUST be validated. This means that if they > are used during bearer token requests, the service must validate the > token with the token endpoint. > * These tokens MUST be rejected by older keycloak clients as our > adapters dont' have support for them. > * offline access tokens will not be stored in the database. Instead > they will be JWEs or JWS that link to an offline user session. (our > current offline access implementation). They will be revokable just > like any other offline session and in the same manner. This makes the > implementation simple. > > * There will be 4 modes for configuring clients > - client automatically receives offline access tokens (maybe not > include a refresh token in this case) > - client may request an offline access token > - client requires consent before providing an offline access token > - client is not allowed to ask for offline access tokens (default) > > Any other thoughts on this? How will client tells that it wants this offline token? Will it be some special value of scope parameter like "scope=persistent_token" ? I can imagine that issuing this token will be handled by protocol mapper? Some protocolMapper implementation, which will change token expiration to 0 (which means infinity) and change token type to something like "persistent" ? Once we have clientScopes in, it will be easily possible to ensure that this protocolMapper is used just if "persistent_token" scope is used as protocolMapper will be just configured on "persistent_token" client scope. However the clientScopes PR will likely need to wait for few weeks or so... Marek > > Maybe this should be implemented in conjunction with a reference token > feature too? > From sthorger at redhat.com Tue Mar 27 03:19:15 2018 From: sthorger at redhat.com (Stian Thorgersen) Date: Tue, 27 Mar 2018 09:19:15 +0200 Subject: [keycloak-dev] offline access tokens part 2 In-Reply-To: References: Message-ID: I would rather have the option to override the expiration of access tokens expiration on a per-client basis. We could allow clients to use the global expiration, a client specific expiration or no expiration at all. When a JWT has no expiration set the client should always use the token introspection endpoint to validate the tokens. Perhaps also combine that with client scopes to make it possible for a client to request one token with longer expiration for a specific use-case. For instance if a client needs to invoke some background process that takes longer than the regular access token. I think that approach will be simpler to implement and also cover more use-cases. On 27 March 2018 at 04:41, Bill Burke wrote: > These are my thoughts for implementing offline access tokens: > > * offline access tokens MUST be validated. This means that if they > are used during bearer token requests, the service must validate the > token with the token endpoint. > * These tokens MUST be rejected by older keycloak clients as our > adapters dont' have support for them. > * offline access tokens will not be stored in the database. Instead > they will be JWEs or JWS that link to an offline user session. (our > current offline access implementation). They will be revokable just > like any other offline session and in the same manner. This makes the > implementation simple. > > * There will be 4 modes for configuring clients > - client automatically receives offline access tokens (maybe not > include a refresh token in this case) > - client may request an offline access token > - client requires consent before providing an offline access token > - client is not allowed to ask for offline access tokens (default) > > Any other thoughts on this? > > Maybe this should be implemented in conjunction with a reference token > feature too? > > -- > Bill Burke > Red Hat > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > From simonpayne58 at gmail.com Tue Mar 27 04:54:05 2018 From: simonpayne58 at gmail.com (Simon Payne) Date: Tue, 27 Mar 2018 09:54:05 +0100 Subject: [keycloak-dev] building keycloak and running tests In-Reply-To: <4011ffe9-a2bc-b376-cb81-0c35a00aa1a7@redhat.com> References: <4011ffe9-a2bc-b376-cb81-0c35a00aa1a7@redhat.com> Message-ID: that works thanks. i did manage to write a script to keytool the alias to something else, which also worked but means i have outstanding changes to commit. i also found that after this i was getting fails on htmlunit tests. i will setup the build job on our jenkins, which has more resource, to see if this improves. do you guys build from the parent every time or build each module separate? thanks On Mon, Mar 26, 2018 at 7:57 AM, Marek Posolda wrote: > Not at this moment AFAIK. You may need to run "mvn clean install > -DskipTests=true" or run tests on different laptop. BTV. I think that just > "testsuite/integration-deprecated" is using port 8081. The main testsuite > "testsuite/integration-arquillian" is using 8180. > > Marek > > > On 23/03/18 16:33, Simon Payne wrote: > >> Hi, is there a way of changing the port, other than find and replace, >> which >> keycloak runs on for the integration tests? >> >> it is currently set to 8081, but we have mcAfee agent listening already. >> >> thanks >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> > > > From bburke at redhat.com Tue Mar 27 10:14:52 2018 From: bburke at redhat.com (Bill Burke) Date: Tue, 27 Mar 2018 10:14:52 -0400 Subject: [keycloak-dev] offline access tokens part 2 In-Reply-To: <6833362f-c904-519d-4642-61a79087270d@redhat.com> References: <6833362f-c904-519d-4642-61a79087270d@redhat.com> Message-ID: On Tue, Mar 27, 2018 at 2:53 AM, Marek Posolda wrote: > Dne 27.3.2018 v 04:41 Bill Burke napsal(a): >> >> These are my thoughts for implementing offline access tokens: >> >> * offline access tokens MUST be validated. This means that if they >> are used during bearer token requests, the service must validate the >> token with the token endpoint. >> * These tokens MUST be rejected by older keycloak clients as our >> adapters dont' have support for them. >> * offline access tokens will not be stored in the database. Instead >> they will be JWEs or JWS that link to an offline user session. (our >> current offline access implementation). They will be revokable just >> like any other offline session and in the same manner. This makes the >> implementation simple. >> >> * There will be 4 modes for configuring clients >> - client automatically receives offline access tokens (maybe not >> include a refresh token in this case) >> - client may request an offline access token >> - client requires consent before providing an offline access token >> - client is not allowed to ask for offline access tokens (default) >> >> Any other thoughts on this? > > How will client tells that it wants this offline token? Will it be some > special value of scope parameter like "scope=persistent_token" ? > Yeah, I think so. > I can imagine that issuing this token will be handled by protocol mapper? > Some protocolMapper implementation, which will change token expiration to 0 > (which means infinity) and change token type to something like "persistent" > ? > > Once we have clientScopes in, it will be easily possible to ensure that this > protocolMapper is used just if "persistent_token" scope is used as > protocolMapper will be just configured on "persistent_token" client scope. > However the clientScopes PR will likely need to wait for few weeks or so... > I don't think it should be implemented as a protocol mapper, or as a regular access token. #1 you'll still need to recognize that the client is requesting an offline access token because you'll need to create an offline user session. #2, We want the offline access token to be as small as possible and for it to contain no information an attacker could use. I would implement it as a JWE that contained a user session id and the scopes the client has been consented for. #3 You don't want to implement it as an access token as you want older Keycloak clients to reject them in bearer token requests. Where protocol mappers would come in is when the client validates the token. In that case an unmarshalled id token or access token would be created with using the client scopes the token was minted for. Question, when you create a client, and specify what scopes its constructed of, can you mark one or more "inherited" scopes as requiring consent? Might be a great way to re-use scopes for clients that require consent. So I think it woudl work like this. I'm making guesses to how Client Scopes was implemented as I don't fully remember your presentation: * We create a built in "persistent-token" scope. This is empty. No protocol mappers, no nothing. * persistent access tokens are JWEs that contain a user session id and scopes client is allowed to access. * When a client is created in the admin console, the "persistent-token" scope is added as a default scope. In this case, this means that the client should automatically get a persistent token. * If the client requires consent, then mark the "persistent-token" scope as requiring consent for that client * persistent tokens are created as a JWE that contains a user session id and scopes the client is allowed to access * When a persistent token is minted, it does the same offline user session logic that "offline access" does. * persisten tokens must be validated with the Keycloak token userinfo or token introspection endpoints depending on the level of information needed. BTW, how long is a "few weeks"? I won't be able to release openshift/kubernetes integration until I can add "allowed groups" to client scopes. Access decisions are entirely group-membership based. If you're interested in more detail, read further: When Openshift and kubernetes validate a token they call a validation endpoint that returns a username and group membership for that user. Never roles. Kub/OS have roles, very specific roles, but access decisions are based on user-role and group-role bindings. What's even more interesting is that users and groups are just strings to Kub/OS. You don't create a user or group, you just specify the username or group string when you create a role binding. The kubernetes integration is actually ridiculously easy and took me like 2 hours. It required just implementing a special validation endpoint for keycloak tokens. Bill From sthorger at redhat.com Tue Mar 27 14:00:45 2018 From: sthorger at redhat.com (Stian Thorgersen) Date: Tue, 27 Mar 2018 20:00:45 +0200 Subject: [keycloak-dev] Wireframes for new consent screen Message-ID: Here's the wireframes for the updated consent screen. Please take a look and comment: https://redhat.invisionapp.com/share/2RGJZNJUBSZ#/screens/287585184_Consent-1 From mposolda at redhat.com Tue Mar 27 14:55:19 2018 From: mposolda at redhat.com (Marek Posolda) Date: Tue, 27 Mar 2018 20:55:19 +0200 Subject: [keycloak-dev] offline access tokens part 2 In-Reply-To: References: <6833362f-c904-519d-4642-61a79087270d@redhat.com> Message-ID: Dne 27.3.2018 v 16:14 Bill Burke napsal(a): > On Tue, Mar 27, 2018 at 2:53 AM, Marek Posolda wrote: >> Dne 27.3.2018 v 04:41 Bill Burke napsal(a): >>> These are my thoughts for implementing offline access tokens: >>> >>> * offline access tokens MUST be validated. This means that if they >>> are used during bearer token requests, the service must validate the >>> token with the token endpoint. >>> * These tokens MUST be rejected by older keycloak clients as our >>> adapters dont' have support for them. >>> * offline access tokens will not be stored in the database. Instead >>> they will be JWEs or JWS that link to an offline user session. (our >>> current offline access implementation). They will be revokable just >>> like any other offline session and in the same manner. This makes the >>> implementation simple. >>> >>> * There will be 4 modes for configuring clients >>> - client automatically receives offline access tokens (maybe not >>> include a refresh token in this case) >>> - client may request an offline access token >>> - client requires consent before providing an offline access token >>> - client is not allowed to ask for offline access tokens (default) >>> >>> Any other thoughts on this? >> How will client tells that it wants this offline token? Will it be some >> special value of scope parameter like "scope=persistent_token" ? >> > Yeah, I think so. > >> I can imagine that issuing this token will be handled by protocol mapper? >> Some protocolMapper implementation, which will change token expiration to 0 >> (which means infinity) and change token type to something like "persistent" >> ? >> >> Once we have clientScopes in, it will be easily possible to ensure that this >> protocolMapper is used just if "persistent_token" scope is used as >> protocolMapper will be just configured on "persistent_token" client scope. >> However the clientScopes PR will likely need to wait for few weeks or so... >> > I don't think it should be implemented as a protocol mapper, or as a > regular access token. #1 you'll still need to recognize that the > client is requesting an offline access token because you'll need to > create an offline user session. #2, We want the offline access token > to be as small as possible and for it to contain no information an > attacker could use. I would implement it as a JWE that contained a > user session id and the scopes the client has been consented for. #3 > You don't want to implement it as an access token as you want older > Keycloak clients to reject them in bearer token requests. Where > protocol mappers would come in is when the client validates the token. > In that case an unmarshalled id token or access token would be created > with using the client scopes the token was minted for. Ok BTV. I've already did some JWE stuff and it's currently used for OAuth code. It's in "core" module and it's already in Keycloak master. We discusssed with Pedro and Sebastian Schuster from community in the other thread, that it will be good to add "scope" as the builtin claim into our access token itself. That way, the refresh tokens and offline tokens (and I believe new persistent token too) will also contain "scope", as they inherit from AccessToken class. JIRA with some more context is https://issues.jboss.org/browse/KEYCLOAK-6883 . This is not yet done in my clientScope PR, but I think it will be quite easy addition. > > Question, when you create a client, and specify what scopes its > constructed of, can you mark one or more "inherited" scopes as > requiring consent? Might be a great way to re-use scopes for clients > that require consent. Yes. If I understand correctly, this shouldn't be a problem. ClientScope has on/off flag "Display On Consent Screen" . The client still has "Consent Required" flag. In case that client is marked as "Consent required", then consent screen will show all the clientScopes marked with "Display On Consent Screen". By default, all clientScopes has "Display On Consent Screen" switched to ON. Note that when client itself doesn't have "Consent Required", the consent screen is never displayed. Same behaviour like in current master. > > > So I think it woudl work like this. I'm making guesses to how Client > Scopes was implemented as I don't fully remember your presentation: > > * We create a built in "persistent-token" scope. This is empty. No > protocol mappers, no nothing. > * persistent access tokens are JWEs that contain a user session id and > scopes client is allowed to access. > * When a client is created in the admin console, the > "persistent-token" scope is added as a default scope. In this case, > this means that the client should automatically get a persistent > token. > * If the client requires consent, then mark the "persistent-token" > scope as requiring consent for that client > > * persistent tokens are created as a JWE that contains a user session > id and scopes the client is allowed to access > * When a persistent token is minted, it does the same offline user > session logic that "offline access" does. > * persisten tokens must be validated with the Keycloak token userinfo > or token introspection endpoints depending on the level of information > needed. I think this workflow should work fine regarding client scopes. > > BTW, how long is a "few weeks"? I won't be able to release > openshift/kubernetes integration until I can add "allowed groups" to > client scopes. Access decisions are entirely group-membership based. > If you're interested in more detail, read further: I've just did rebase of the clientScopes PR with latest master. In theory, it can be merged very soon if it blocks you. What prevents it from merging is: - One failed test in cross-dc after rebase. I've just checked that this is broken in current master and not related to the clientScopes PR. Created: https://issues.jboss.org/browse/KEYCLOAK-7017 - One approved review. It was reviewed only by Vlasta from QA team and he also fixed some issues and broken databases. I think Stian also wanted to review it. You are welcome to review as well. Sorry it's so big PR... - Documentation - It's not documented yet and current documentation contains some references to client templates, which is now outdated. Also some screenshots likely need to be redone... I need to work on summit demo and don't have time to finish docs in next few weeks TBH. IMO It's not a problem if clientScopes PR is merged in master and docs master is outdated for some time. However it will be bad IMO to release Keycloak with the outdated documentation. If next Keycloak beta can be postponed to second half of April, it should be fine. I should be able to spend time on docs before that. I think it will be like a day of work or so. Marek > > When Openshift and kubernetes validate a token they call a validation > endpoint that returns a username and group membership for that user. > Never roles. Kub/OS have roles, very specific roles, but access > decisions are based on user-role and group-role bindings. What's even > more interesting is that users and groups are just strings to Kub/OS. > You don't create a user or group, you just specify the username or > group string when you create a role binding. The kubernetes > integration is actually ridiculously easy and took me like 2 hours. > It required just implementing a special validation endpoint for > keycloak tokens. > > Bill From bburke at redhat.com Tue Mar 27 15:36:07 2018 From: bburke at redhat.com (Bill Burke) Date: Tue, 27 Mar 2018 15:36:07 -0400 Subject: [keycloak-dev] offline access tokens part 2 In-Reply-To: References: <6833362f-c904-519d-4642-61a79087270d@redhat.com> Message-ID: On Tue, Mar 27, 2018 at 2:55 PM, Marek Posolda wrote: > Dne 27.3.2018 v 16:14 Bill Burke napsal(a): > >> On Tue, Mar 27, 2018 at 2:53 AM, Marek Posolda >> wrote: >>> >>> Dne 27.3.2018 v 04:41 Bill Burke napsal(a): >>>> >>>> These are my thoughts for implementing offline access tokens: >>>> >>>> * offline access tokens MUST be validated. This means that if they >>>> are used during bearer token requests, the service must validate the >>>> token with the token endpoint. >>>> * These tokens MUST be rejected by older keycloak clients as our >>>> adapters dont' have support for them. >>>> * offline access tokens will not be stored in the database. Instead >>>> they will be JWEs or JWS that link to an offline user session. (our >>>> current offline access implementation). They will be revokable just >>>> like any other offline session and in the same manner. This makes the >>>> implementation simple. >>>> >>>> * There will be 4 modes for configuring clients >>>> - client automatically receives offline access tokens (maybe not >>>> include a refresh token in this case) >>>> - client may request an offline access token >>>> - client requires consent before providing an offline access token >>>> - client is not allowed to ask for offline access tokens (default) >>>> >>>> Any other thoughts on this? >>> >>> How will client tells that it wants this offline token? Will it be some >>> special value of scope parameter like "scope=persistent_token" ? >>> >> Yeah, I think so. >> >>> I can imagine that issuing this token will be handled by protocol mapper? >>> Some protocolMapper implementation, which will change token expiration to >>> 0 >>> (which means infinity) and change token type to something like >>> "persistent" >>> ? >>> >>> Once we have clientScopes in, it will be easily possible to ensure that >>> this >>> protocolMapper is used just if "persistent_token" scope is used as >>> protocolMapper will be just configured on "persistent_token" client >>> scope. >>> However the clientScopes PR will likely need to wait for few weeks or >>> so... >>> >> I don't think it should be implemented as a protocol mapper, or as a >> regular access token. #1 you'll still need to recognize that the >> client is requesting an offline access token because you'll need to >> create an offline user session. #2, We want the offline access token >> to be as small as possible and for it to contain no information an >> attacker could use. I would implement it as a JWE that contained a >> user session id and the scopes the client has been consented for. #3 >> You don't want to implement it as an access token as you want older >> Keycloak clients to reject them in bearer token requests. Where >> protocol mappers would come in is when the client validates the token. >> In that case an unmarshalled id token or access token would be created >> with using the client scopes the token was minted for. > > Ok > > BTV. I've already did some JWE stuff and it's currently used for OAuth code. > It's in "core" module and it's already in Keycloak master. > > We discusssed with Pedro and Sebastian Schuster from community in the other > thread, that it will be good to add "scope" as the builtin claim into our > access token itself. That way, the refresh tokens and offline tokens (and I > believe new persistent token too) will also contain "scope", as they inherit > from AccessToken class. JIRA with some more context is > https://issues.jboss.org/browse/KEYCLOAK-6883 . This is not yet done in my > clientScope PR, but I think it will be quite easy addition. Yes this is good. Scopes allowed should be in the auth session too. I think I have done that in my Openshift branch as I have to validate requested scopes vs. allowed openshift scopes when validating a token. >> >> >> Question, when you create a client, and specify what scopes its >> constructed of, can you mark one or more "inherited" scopes as >> requiring consent? Might be a great way to re-use scopes for clients >> that require consent. > > Yes. If I understand correctly, this shouldn't be a problem. > > ClientScope has on/off flag "Display On Consent Screen" . The client still > has "Consent Required" flag. In case that client is marked as "Consent > required", then consent screen will show all the clientScopes marked with > "Display On Consent Screen". By default, all clientScopes has "Display On > Consent Screen" switched to ON. > > Note that when client itself doesn't have "Consent Required", the consent > screen is never displayed. Same behaviour like in current master. Might be nice to not require "consent required" on the scope itself, but when you attach it to the client. i.e. Client Foo has scopes A, B by default which don't require consent, but it can also request scope C if the client asks for it and consent is granted. Client Bar has scope C by default and doesn't require consent. Maybe that's something that can be supported later. -- Bill Burke Red Hat From sthorger at redhat.com Wed Mar 28 00:58:04 2018 From: sthorger at redhat.com (Stian Thorgersen) Date: Wed, 28 Mar 2018 06:58:04 +0200 Subject: [keycloak-dev] offline access tokens part 2 In-Reply-To: References: <6833362f-c904-519d-4642-61a79087270d@redhat.com> Message-ID: Since my reply was ignored I'm going to repeat myself. I would rather have the option to override the expiration of access tokens expiration on a per-client basis. We could allow clients to use the global expiration, a client specific expiration or no expiration at all. When a JWT has no expiration set the client should always use the token introspection endpoint to validate the tokens. Perhaps also combine that with client scopes to make it possible for a client to request one token with longer expiration for a specific use-case. For instance if a client needs to invoke some background process that takes longer than the regular access token. I think that approach will be simpler to implement and also cover more use-cases. I don't see the need to have a different scope than what we have today. This should be a config option on the client for the current offline scope. There's no need to introduce a new non-common scope for this stuff. On 27 March 2018 at 21:36, Bill Burke wrote: > On Tue, Mar 27, 2018 at 2:55 PM, Marek Posolda > wrote: > > Dne 27.3.2018 v 16:14 Bill Burke napsal(a): > > > >> On Tue, Mar 27, 2018 at 2:53 AM, Marek Posolda > >> wrote: > >>> > >>> Dne 27.3.2018 v 04:41 Bill Burke napsal(a): > >>>> > >>>> These are my thoughts for implementing offline access tokens: > >>>> > >>>> * offline access tokens MUST be validated. This means that if they > >>>> are used during bearer token requests, the service must validate the > >>>> token with the token endpoint. > >>>> * These tokens MUST be rejected by older keycloak clients as our > >>>> adapters dont' have support for them. > >>>> * offline access tokens will not be stored in the database. Instead > >>>> they will be JWEs or JWS that link to an offline user session. (our > >>>> current offline access implementation). They will be revokable just > >>>> like any other offline session and in the same manner. This makes the > >>>> implementation simple. > >>>> > >>>> * There will be 4 modes for configuring clients > >>>> - client automatically receives offline access tokens (maybe not > >>>> include a refresh token in this case) > >>>> - client may request an offline access token > >>>> - client requires consent before providing an offline access token > >>>> - client is not allowed to ask for offline access tokens (default) > >>>> > >>>> Any other thoughts on this? > >>> > >>> How will client tells that it wants this offline token? Will it be some > >>> special value of scope parameter like "scope=persistent_token" ? > >>> > >> Yeah, I think so. > >> > >>> I can imagine that issuing this token will be handled by protocol > mapper? > >>> Some protocolMapper implementation, which will change token expiration > to > >>> 0 > >>> (which means infinity) and change token type to something like > >>> "persistent" > >>> ? > >>> > >>> Once we have clientScopes in, it will be easily possible to ensure that > >>> this > >>> protocolMapper is used just if "persistent_token" scope is used as > >>> protocolMapper will be just configured on "persistent_token" client > >>> scope. > >>> However the clientScopes PR will likely need to wait for few weeks or > >>> so... > >>> > >> I don't think it should be implemented as a protocol mapper, or as a > >> regular access token. #1 you'll still need to recognize that the > >> client is requesting an offline access token because you'll need to > >> create an offline user session. #2, We want the offline access token > >> to be as small as possible and for it to contain no information an > >> attacker could use. I would implement it as a JWE that contained a > >> user session id and the scopes the client has been consented for. #3 > >> You don't want to implement it as an access token as you want older > >> Keycloak clients to reject them in bearer token requests. Where > >> protocol mappers would come in is when the client validates the token. > >> In that case an unmarshalled id token or access token would be created > >> with using the client scopes the token was minted for. > > > > Ok > > > > BTV. I've already did some JWE stuff and it's currently used for OAuth > code. > > It's in "core" module and it's already in Keycloak master. > > > > We discusssed with Pedro and Sebastian Schuster from community in the > other > > thread, that it will be good to add "scope" as the builtin claim into our > > access token itself. That way, the refresh tokens and offline tokens > (and I > > believe new persistent token too) will also contain "scope", as they > inherit > > from AccessToken class. JIRA with some more context is > > https://issues.jboss.org/browse/KEYCLOAK-6883 . This is not yet done in > my > > clientScope PR, but I think it will be quite easy addition. > > Yes this is good. Scopes allowed should be in the auth session too. > I think I have done that in my Openshift branch as I have to validate > requested scopes vs. allowed openshift scopes when validating a token. > > >> > >> > >> Question, when you create a client, and specify what scopes its > >> constructed of, can you mark one or more "inherited" scopes as > >> requiring consent? Might be a great way to re-use scopes for clients > >> that require consent. > > > > Yes. If I understand correctly, this shouldn't be a problem. > > > > ClientScope has on/off flag "Display On Consent Screen" . The client > still > > has "Consent Required" flag. In case that client is marked as "Consent > > required", then consent screen will show all the clientScopes marked with > > "Display On Consent Screen". By default, all clientScopes has "Display On > > Consent Screen" switched to ON. > > > > Note that when client itself doesn't have "Consent Required", the consent > > screen is never displayed. Same behaviour like in current master. > > Might be nice to not require "consent required" on the scope itself, > but when you attach it to the client. > > i.e. Client Foo has scopes A, B by default which don't require > consent, but it can also request scope C if the client asks for it and > consent is granted. > Client Bar has scope C by default and doesn't require consent. Maybe > that's something that can be supported later. > > > -- > Bill Burke > Red Hat > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > From mposolda at redhat.com Wed Mar 28 02:58:59 2018 From: mposolda at redhat.com (Marek Posolda) Date: Wed, 28 Mar 2018 08:58:59 +0200 Subject: [keycloak-dev] offline access tokens part 2 In-Reply-To: References: <6833362f-c904-519d-4642-61a79087270d@redhat.com> Message-ID: Dne 27.3.2018 v 21:36 Bill Burke napsal(a): > Might be nice to not require "consent required" on the scope itself, > but when you attach it to the client. > > i.e. Client Foo has scopes A, B by default which don't require > consent, but it can also request scope C if the client asks for it and > consent is granted. > Client Bar has scope C by default and doesn't require consent. Maybe > that's something that can be supported later. I see. So the flag is not on clientScope itself, but on the "binding" between client and clientScope. I agree that it's something to be supported later. Will likely require some model changes as currently there is no separate model for "binding" between client and clientScope. Created https://issues.jboss.org/browse/KEYCLOAK-7018 . I think it will be useful for some other scenarios, for example possibility to check/uncheck some clientScopes on consent screen: https://issues.jboss.org/browse/KEYCLOAK-7019 . Marek From bburke at redhat.com Wed Mar 28 10:24:35 2018 From: bburke at redhat.com (Bill Burke) Date: Wed, 28 Mar 2018 10:24:35 -0400 Subject: [keycloak-dev] offline access tokens part 2 In-Reply-To: References: <6833362f-c904-519d-4642-61a79087270d@redhat.com> Message-ID: On Wed, Mar 28, 2018 at 12:58 AM, Stian Thorgersen wrote: > Since my reply was ignored I'm going to repeat myself. > > I would rather have the option to override the expiration of access tokens > expiration on a per-client basis. We could allow clients to use the global > expiration, a client specific expiration or no expiration at all. When a JWT > has no expiration set the client should always use the token introspection > endpoint to validate the tokens. > > Perhaps also combine that with client scopes to make it possible for a > client to request one token with longer expiration for a specific use-case. > For instance if a client needs to invoke some background process that takes > longer than the regular access token. > > I think that approach will be simpler to implement and also cover more > use-cases. > > I don't see the need to have a different scope than what we have today. This > should be a config option on the client for the current offline scope. > There's no need to introduce a new non-common scope for this stuff. > FYI, didn't ignore you. I replied to Marek's email first, got distracted before I could read and reply to yours. I think this is a reference token vs. non-reference token debate. Let's first talk about offline access tokens. In thinking further on your suggestion, what about instead of per client expiration, shouldn't we instead have an "offline access token timeout"? Access tokens created for offline access should have this timeout, maybe default to "offline idle" timeout? One thing we have to be sure of is that these offline access tokens are valid across server restarts. In retrospect, I mixed up offline access and the idea of a reference token. I think whether an access token is a reference token or not is orthogonal to whether it is offline or not. Reference tokens must always be validated. Non-reference tokens can be used as bearer tokens without validation. I think we should have a global switch on what the access token type should be by default, then allow clients to override. You should also be able to separately configure whether a reference token should be used or not for offline and non-offline access. In the future we might even want to offer one-time reference tokens that can only be validated once. FYI: all tokens in Kubernetes and Openshift are reference tokens (and offline). Reference tokens require validation and shouldn't be excepted ever for bearer token requests unless validated. Using expiration time to determine the token type is not a good solution. Other than just being a hack, you remove the ability to have any expiration on the token. I really prefer that reference tokens be completely opaque to the client. A JWE IMO. -- Bill Burke Red Hat