From tonnis at autonomic.ai Fri Sep 1 14:27:03 2017 From: tonnis at autonomic.ai (Tonnis Wildeboer) Date: Fri, 1 Sep 2017 11:27:03 -0700 Subject: [keycloak-dev] Questions about Standalone HA Message-ID: <4e472081-6959-bb70-6b73-e86191732aa6@autonomic.ai> Hello, I posted similar questions on keycloak-user, but it doesn't seem to be the right audience. Please redirect me if these are not appropriate for this group. *Background:* I am running Keycloak in a kubernetes cluster with a shared postgres (RDS) db. Everything is hosted on AWS. The Keycloak instances are deployed using Helm. I have read the clustering and caching documentation and from that it seems that the appropriate clustering mode in this scenario would be "Standalone Clustered Mode". Therefore, I am using the "jboss/keycloak-ha-postgres" Docker image. Since I am using the nginx Ingress controller I have the prescribedPROXY_ADDRESS_FORWARDING=true environment variable. Upon inspection of the Docker image, however, I noticed that the $JBOSS_HOME/standalone/configuration/standalone-ha.xml file in that image does not have the proxy-address-forwarding="${env.PROXY_ADDRESS_FORWARDING}" attribute in the element. I also noticed that the jboss-dockerfiles/keycloak-server base image has a sed command to add this to the standalone.xml file but not to the standalone-ha.xml file. (Also, for the benefit of others interested in this configuration, I have configured session affinity in the Ingress to avoid the default round-robin routing, which causes infinite redirects to Keycloak, bouncing between instances.) Of the examples I have found via Google searches, I have not found examples of deploying Keycloak this way, which is surprising. I have seen examples with a single instance using the standalone postgres image, but not standalone-ha ("Standalone Clustered"). *So here are my questions:* 1. Why doesn't the base jboss-dockerfiles/keycloak-server image also modify the standalone-ha.xml file too, in the same way it modifies the standalone.xml file: (https://github.com/jboss-dockerfiles/keycloak/blob/0a54ccaccd5e27e75105b904708ac4ccd80df5c5/server/Dockerfile#L23-L25)? 2. I assume the discovery of the nodes between one another (for the sake of the shared caches) is accomplished through multicast as long as they are on the same subnet. Correct? 3. What should I be looking for in the logs to see whether the peer node discovery is happening? What logging level do I need to see this? 4. If the nodes (pods) are in different AWS VPCs and there is no explicit routing set up between them such that they cannot discover one another, but they do share the same postgres instance, is there any harm in this? I would assume that each node would take responsibility for being the cache owner, and that is not a problem. 5. Is there any other documentation, etc that I should be looking at? Thank you, --Tonnis From tonnis at autonomic.ai Fri Sep 1 14:59:18 2017 From: tonnis at autonomic.ai (Tonnis Wildeboer) Date: Fri, 1 Sep 2017 11:59:18 -0700 Subject: [keycloak-dev] server-ha-postgres/Dockerfile issue for building past versions? Message-ID: <95e88e93-f2e3-a93b-fef3-51bd37c24837@autonomic.ai> Hello, I was examining the Dockerfile for server-ha-postgres (2.5.5.Final) and noticed that it is based on jboss/keycloak-postgres:/*latest.*/ Seems to me this will be an issue for those attempting to build the 2.5.5.Final image from scratch as well as any future versions that are not "latest", since this line of the Dockerfile has not changed since then . i.e. The base image version referenced in this Dockerfile should be revved with each new version, correct? --Tonnis From john.d.ament at gmail.com Fri Sep 1 16:38:17 2017 From: john.d.ament at gmail.com (John D. Ament) Date: Fri, 01 Sep 2017 20:38:17 +0000 Subject: [keycloak-dev] Questions about Standalone HA In-Reply-To: <4e472081-6959-bb70-6b73-e86191732aa6@autonomic.ai> References: <4e472081-6959-bb70-6b73-e86191732aa6@autonomic.ai> Message-ID: Tonnis, Some comments in line. On Fri, Sep 1, 2017 at 4:10 PM Tonnis Wildeboer wrote: > Hello, > > I posted similar questions on keycloak-user, but it doesn't seem to be > the right audience. Please redirect me if these are not appropriate for > this group. > > *Background:* > > I am running Keycloak in a kubernetes cluster with a shared postgres > (RDS) db. Everything is hosted on AWS. The Keycloak instances are > deployed using Helm. > > I have read the clustering and caching documentation and from that it > seems that the appropriate clustering mode in this scenario would be > "Standalone Clustered Mode". Therefore, I am using the > "jboss/keycloak-ha-postgres" Docker image. Since I am using the nginx > Ingress controller I have the prescribedPROXY_ADDRESS_FORWARDING=true > environment variable. Upon inspection of the Docker image, however, I > noticed that the $JBOSS_HOME/standalone/configuration/standalone-ha.xml > file in that image does not have the > proxy-address-forwarding="${env.PROXY_ADDRESS_FORWARDING}" attribute in > the element. I also noticed that the > jboss-dockerfiles/keycloak-server base image has a sed command to add > this to the standalone.xml file but not to the standalone-ha.xml file. > > (Also, for the benefit of others interested in this configuration, I > have configured session affinity in the Ingress to avoid the default > round-robin routing, which causes infinite redirects to Keycloak, > bouncing between instances.) > > This is probably your first sign of an issue. This indicates that your nodes aren't talking to one another, session affinity is not actually required (I have an AWS deployment today that works fine) > Of the examples I have found via Google searches, I have not found > examples of deploying Keycloak this way, which is surprising. I have > seen examples with a single instance using the standalone postgres > image, but not standalone-ha ("Standalone Clustered"). > > *So here are my questions:* > > 1. Why doesn't the base jboss-dockerfiles/keycloak-server image also > modify the standalone-ha.xml file too, in the same way it modifies > the standalone.xml file: > ( > https://github.com/jboss-dockerfiles/keycloak/blob/0a54ccaccd5e27e75105b904708ac4ccd80df5c5/server/Dockerfile#L23-L25 > )? > Probably because the docker use case has only considered simple development. For what its worth, I don't deploy any prebuilt docker containers, everything I deploy is a customized image in some way. > 2. I assume the discovery of the nodes between one another (for the > sake of the shared caches) is accomplished through multicast as long > as they are on the same subnet. Correct? > Normally, yes. However, in AWS multicast doesn't work (even when in the same VPC/subnet). To work around this, you can leverage JDBC_PING in jgroups. https://developer.jboss.org/wiki/JDBCPING > 3. What should I be looking for in the logs to see whether the peer > node discovery is happening? What logging level do I need to see this? > You'll see log messages from jgroups indicating that the cluster is alive and a peer was discovered. I turned this up very high to give more information. > 4. If the nodes (pods) are in different AWS VPCs and there is no > explicit routing set up between them such that they cannot discover > one another, but they do share the same postgres instance, is there > any harm in this? I would assume that each node would take > responsibility for being the cache owner, and that is not a problem. > If your cache isn't replicating, users will lose sessions frequently. > 5. Is there any other documentation, etc that I should be looking at? > > The link I put above, and probably the existing clustering docs which you may have already reviewed. > > Thank you, > > --Tonnis > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > From tonnis at autonomic.ai Fri Sep 1 18:53:19 2017 From: tonnis at autonomic.ai (Tonnis Wildeboer) Date: Fri, 1 Sep 2017 15:53:19 -0700 Subject: [keycloak-dev] Questions about Standalone HA In-Reply-To: References: <4e472081-6959-bb70-6b73-e86191732aa6@autonomic.ai> Message-ID: <3f8f5521-4fdf-7254-957b-d18e66b4b726@autonomic.ai> Thank you John. Super helpful. Following up on your responses: If I choose to use a simple standalone (as opposed to a standalone-ha) configuration for all the nodes in AWS (whether in the same VPC or not) /and/ have session affinity configured in the load balancer, am I giving up a lot? I wonder because in this case none of the nodes are relying on a shared cache but the traffic from any given client is always routed to the same instance (as long as it is alive). I realize that depending on the affinity algorithm, there is the potential for uneven load balancing, and also, if any node goes down, its clients will lose their sessions. Just trying form a correct mental model and understand the trade-offs. Meanwhile, I will look into JDBC_PING in jgroups... Thanks again, --Tonnis On 09/01/2017 01:38 PM, John D. Ament wrote: > Tonnis, > > Some comments in line. > > On Fri, Sep 1, 2017 at 4:10 PM Tonnis Wildeboer > wrote: > > Hello, > > I posted similar questions on keycloak-user, but it doesn't seem to be > the right audience. Please redirect me if these are not > appropriate for > this group. > > *Background:* > > I am running Keycloak in a kubernetes cluster with a shared postgres > (RDS) db. Everything is hosted on AWS. The Keycloak instances are > deployed using Helm. > > I have read the clustering and caching documentation and from that it > seems that the appropriate clustering mode in this scenario would be > "Standalone Clustered Mode". Therefore, I am using the > "jboss/keycloak-ha-postgres" Docker image. Since I am using the nginx > Ingress controller I have the prescribedPROXY_ADDRESS_FORWARDING=true > environment variable. Upon inspection of the Docker image, however, I > noticed that the > $JBOSS_HOME/standalone/configuration/standalone-ha.xml > file in that image does not have the > proxy-address-forwarding="${env.PROXY_ADDRESS_FORWARDING}" > attribute in > the element. I also noticed that the > jboss-dockerfiles/keycloak-server base image has a sed command to add > this to the standalone.xml file but not to the standalone-ha.xml file. > > (Also, for the benefit of others interested in this configuration, I > have configured session affinity in the Ingress to avoid the default > round-robin routing, which causes infinite redirects to Keycloak, > bouncing between instances.) > > > This is probably your first sign of an issue. This indicates that > your nodes aren't talking to one another, session affinity is not > actually required (I have an AWS deployment today that works fine) > > Of the examples I have found via Google searches, I have not found > examples of deploying Keycloak this way, which is surprising. I have > seen examples with a single instance using the standalone postgres > image, but not standalone-ha ("Standalone Clustered"). > > *So here are my questions:* > > 1. Why doesn't the base jboss-dockerfiles/keycloak-server image also > modify the standalone-ha.xml file too, in the same way it modifies > the standalone.xml file: > > (https://github.com/jboss-dockerfiles/keycloak/blob/0a54ccaccd5e27e75105b904708ac4ccd80df5c5/server/Dockerfile#L23-L25)? > > > Probably because the docker use case has only considered simple > development. For what its worth, I don't deploy any prebuilt docker > containers, everything I deploy is a customized image in some way. > > 2. I assume the discovery of the nodes between one another (for the > sake of the shared caches) is accomplished through multicast > as long > as they are on the same subnet. Correct? > > > Normally, yes. However, in AWS multicast doesn't work (even when in > the same VPC/subnet). To work around this, you can leverage JDBC_PING > in jgroups. https://developer.jboss.org/wiki/JDBCPING > > 3. What should I be looking for in the logs to see whether the peer > node discovery is happening? What logging level do I need to > see this? > > > You'll see log messages from jgroups indicating that the cluster is > alive and a peer was discovered. I turned this up very high to give > more information. > > 4. If the nodes (pods) are in different AWS VPCs and there is no > explicit routing set up between them such that they cannot > discover > one another, but they do share the same postgres instance, is > there > any harm in this? I would assume that each node would take > responsibility for being the cache owner, and that is not a > problem. > > > If your cache isn't replicating, users will lose sessions frequently. > > 5. Is there any other documentation, etc that I should be looking at? > > > The link I put above, and probably the existing clustering docs which > you may have already reviewed. > > > Thank you, > > --Tonnis > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > From cpitman at redhat.com Fri Sep 1 20:28:05 2017 From: cpitman at redhat.com (Chris Pitman) Date: Fri, 1 Sep 2017 20:28:05 -0400 Subject: [keycloak-dev] Questions about Standalone HA In-Reply-To: <3f8f5521-4fdf-7254-957b-d18e66b4b726@autonomic.ai> References: <4e472081-6959-bb70-6b73-e86191732aa6@autonomic.ai> <3f8f5521-4fdf-7254-957b-d18e66b4b726@autonomic.ai> Message-ID: Since you are deploying in Kubernetes, the easier option is probably KUBE_PING. That will use a service for discovery, looking up which pods exist. On Fri, Sep 1, 2017 at 6:53 PM, Tonnis Wildeboer wrote: > Thank you John. Super helpful. Following up on your responses: > > If I choose to use a simple standalone (as opposed to a standalone-ha) > configuration for all the nodes in AWS (whether in the same VPC or not) > /and/ have session affinity configured in the load balancer, am I giving > up a lot? I wonder because in this case none of the nodes are relying on > a shared cache but the traffic from any given client is always routed to > the same instance (as long as it is alive). I realize that depending on > the affinity algorithm, there is the potential for uneven load > balancing, and also, if any node goes down, its clients will lose their > sessions. Just trying form a correct mental model and understand the > trade-offs. > > Meanwhile, I will look into JDBC_PING in jgroups... > > Thanks again, > > --Tonnis > > On 09/01/2017 01:38 PM, John D. Ament wrote: > > Tonnis, > > > > Some comments in line. > > > > On Fri, Sep 1, 2017 at 4:10 PM Tonnis Wildeboer > > wrote: > > > > Hello, > > > > I posted similar questions on keycloak-user, but it doesn't seem to > be > > the right audience. Please redirect me if these are not > > appropriate for > > this group. > > > > *Background:* > > > > I am running Keycloak in a kubernetes cluster with a shared postgres > > (RDS) db. Everything is hosted on AWS. The Keycloak instances are > > deployed using Helm. > > > > I have read the clustering and caching documentation and from that it > > seems that the appropriate clustering mode in this scenario would be > > "Standalone Clustered Mode". Therefore, I am using the > > "jboss/keycloak-ha-postgres" Docker image. Since I am using the nginx > > Ingress controller I have the prescribedPROXY_ADDRESS_ > FORWARDING=true > > environment variable. Upon inspection of the Docker image, however, I > > noticed that the > > $JBOSS_HOME/standalone/configuration/standalone-ha.xml > > file in that image does not have the > > proxy-address-forwarding="${env.PROXY_ADDRESS_FORWARDING}" > > attribute in > > the element. I also noticed that the > > jboss-dockerfiles/keycloak-server base image has a sed command to > add > > this to the standalone.xml file but not to the standalone-ha.xml > file. > > > > (Also, for the benefit of others interested in this configuration, I > > have configured session affinity in the Ingress to avoid the default > > round-robin routing, which causes infinite redirects to Keycloak, > > bouncing between instances.) > > > > > > This is probably your first sign of an issue. This indicates that > > your nodes aren't talking to one another, session affinity is not > > actually required (I have an AWS deployment today that works fine) > > > > Of the examples I have found via Google searches, I have not found > > examples of deploying Keycloak this way, which is surprising. I have > > seen examples with a single instance using the standalone postgres > > image, but not standalone-ha ("Standalone Clustered"). > > > > *So here are my questions:* > > > > 1. Why doesn't the base jboss-dockerfiles/keycloak-server image > also > > modify the standalone-ha.xml file too, in the same way it > modifies > > the standalone.xml file: > > > > (https://github.com/jboss-dockerfiles/keycloak/blob/ > 0a54ccaccd5e27e75105b904708ac4ccd80df5c5/server/Dockerfile#L23-L25)? > > > > > > Probably because the docker use case has only considered simple > > development. For what its worth, I don't deploy any prebuilt docker > > containers, everything I deploy is a customized image in some way. > > > > 2. I assume the discovery of the nodes between one another (for the > > sake of the shared caches) is accomplished through multicast > > as long > > as they are on the same subnet. Correct? > > > > > > Normally, yes. However, in AWS multicast doesn't work (even when in > > the same VPC/subnet). To work around this, you can leverage JDBC_PING > > in jgroups. https://developer.jboss.org/wiki/JDBCPING > > > > 3. What should I be looking for in the logs to see whether the peer > > node discovery is happening? What logging level do I need to > > see this? > > > > > > You'll see log messages from jgroups indicating that the cluster is > > alive and a peer was discovered. I turned this up very high to give > > more information. > > > > 4. If the nodes (pods) are in different AWS VPCs and there is no > > explicit routing set up between them such that they cannot > > discover > > one another, but they do share the same postgres instance, is > > there > > any harm in this? I would assume that each node would take > > responsibility for being the cache owner, and that is not a > > problem. > > > > > > If your cache isn't replicating, users will lose sessions frequently. > > > > 5. Is there any other documentation, etc that I should be looking > at? > > > > > > The link I put above, and probably the existing clustering docs which > > you may have already reviewed. > > > > > > Thank you, > > > > --Tonnis > > _______________________________________________ > > 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 > -- Chris Pitman Senior Architect, Red Hat Consulting From tonnis at autonomic.ai Fri Sep 1 20:47:21 2017 From: tonnis at autonomic.ai (Tonnis Wildeboer) Date: Fri, 1 Sep 2017 17:47:21 -0700 Subject: [keycloak-dev] Questions about Standalone HA In-Reply-To: References: <4e472081-6959-bb70-6b73-e86191732aa6@autonomic.ai> <3f8f5521-4fdf-7254-957b-d18e66b4b726@autonomic.ai> Message-ID: Yes! Makes total sense. I think we will use that. (I have not been exposed to jgroups before this.) Thanks very much. (Still curious about my question, though.) --Tonnis On Sep 1, 2017 17:28, "Chris Pitman" wrote: Since you are deploying in Kubernetes, the easier option is probably KUBE_PING. That will use a service for discovery, looking up which pods exist. On Fri, Sep 1, 2017 at 6:53 PM, Tonnis Wildeboer wrote: > Thank you John. Super helpful. Following up on your responses: > > If I choose to use a simple standalone (as opposed to a standalone-ha) > configuration for all the nodes in AWS (whether in the same VPC or not) > /and/ have session affinity configured in the load balancer, am I giving > > up a lot? I wonder because in this case none of the nodes are relying on > a shared cache but the traffic from any given client is always routed to > the same instance (as long as it is alive). I realize that depending on > the affinity algorithm, there is the potential for uneven load > balancing, and also, if any node goes down, its clients will lose their > sessions. Just trying form a correct mental model and understand the > trade-offs. > > Meanwhile, I will look into JDBC_PING in jgroups... > > Thanks again, > > --Tonnis > > On 09/01/2017 01:38 PM, John D. Ament wrote: > > Tonnis, > > > > Some comments in line. > > > > On Fri, Sep 1, 2017 at 4:10 PM Tonnis Wildeboer > > wrote: > > > > Hello, > > > > I posted similar questions on keycloak-user, but it doesn't seem to > be > > the right audience. Please redirect me if these are not > > appropriate for > > this group. > > > > *Background:* > > > > I am running Keycloak in a kubernetes cluster with a shared postgres > > (RDS) db. Everything is hosted on AWS. The Keycloak instances are > > deployed using Helm. > > > > I have read the clustering and caching documentation and from that it > > seems that the appropriate clustering mode in this scenario would be > > "Standalone Clustered Mode". Therefore, I am using the > > "jboss/keycloak-ha-postgres" Docker image. Since I am using the nginx > > Ingress controller I have the prescribedPROXY_ADDRESS_FORWAR > DING=true > > environment variable. Upon inspection of the Docker image, however, I > > noticed that the > > $JBOSS_HOME/standalone/configuration/standalone-ha.xml > > file in that image does not have the > > proxy-address-forwarding="${env.PROXY_ADDRESS_FORWARDING}" > > attribute in > > the element. I also noticed that the > > jboss-dockerfiles/keycloak-server base image has a sed command to > add > > this to the standalone.xml file but not to the standalone-ha.xml > file. > > > > (Also, for the benefit of others interested in this configuration, I > > have configured session affinity in the Ingress to avoid the default > > round-robin routing, which causes infinite redirects to Keycloak, > > bouncing between instances.) > > > > > > This is probably your first sign of an issue. This indicates that > > your nodes aren't talking to one another, session affinity is not > > actually required (I have an AWS deployment today that works fine) > > > > Of the examples I have found via Google searches, I have not found > > examples of deploying Keycloak this way, which is surprising. I have > > seen examples with a single instance using the standalone postgres > > image, but not standalone-ha ("Standalone Clustered"). > > > > *So here are my questions:* > > > > 1. Why doesn't the base jboss-dockerfiles/keycloak-server image > also > > modify the standalone-ha.xml file too, in the same way it > modifies > > the standalone.xml file: > > > > (https://github.com/jboss-dockerfiles/keycloak/blob/0a54cca > ccd5e27e75105b904708ac4ccd80df5c5/server/Dockerfile#L23-L25)? > > > > > > Probably because the docker use case has only considered simple > > development. For what its worth, I don't deploy any prebuilt docker > > containers, everything I deploy is a customized image in some way. > > > > 2. I assume the discovery of the nodes between one another (for the > > sake of the shared caches) is accomplished through multicast > > as long > > as they are on the same subnet. Correct? > > > > > > Normally, yes. However, in AWS multicast doesn't work (even when in > > the same VPC/subnet). To work around this, you can leverage JDBC_PING > > in jgroups. https://developer.jboss.org/wiki/JDBCPING > > > > 3. What should I be looking for in the logs to see whether the peer > > node discovery is happening? What logging level do I need to > > see this? > > > > > > You'll see log messages from jgroups indicating that the cluster is > > alive and a peer was discovered. I turned this up very high to give > > more information. > > > > 4. If the nodes (pods) are in different AWS VPCs and there is no > > explicit routing set up between them such that they cannot > > discover > > one another, but they do share the same postgres instance, is > > there > > any harm in this? I would assume that each node would take > > responsibility for being the cache owner, and that is not a > > problem. > > > > > > If your cache isn't replicating, users will lose sessions frequently. > > > > 5. Is there any other documentation, etc that I should be looking > at? > > > > > > The link I put above, and probably the existing clustering docs which > > you may have already reviewed. > > > > > > Thank you, > > > > --Tonnis > > _______________________________________________ > > 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 > -- Chris Pitman Senior Architect, Red Hat Consulting From sthorger at redhat.com Mon Sep 4 02:27:18 2017 From: sthorger at redhat.com (Stian Thorgersen) Date: Mon, 4 Sep 2017 08:27:18 +0200 Subject: [keycloak-dev] server-ha-postgres/Dockerfile issue for building past versions? In-Reply-To: <95e88e93-f2e3-a93b-fef3-51bd37c24837@autonomic.ai> References: <95e88e93-f2e3-a93b-fef3-51bd37c24837@autonomic.ai> Message-ID: Indeed, seems that particular image isn't updated. Feel free to create a JIRA for it. On 1 September 2017 at 20:59, Tonnis Wildeboer wrote: > Hello, > > I was examining the Dockerfile for server-ha-postgres (2.5.5.Final) and > noticed that it is based on jboss/keycloak-postgres:/*latest.*/ > 5.Final/server-ha-postgres/Dockerfile#L1> > Seems to me this will be an issue for those attempting to build the > 2.5.5.Final image from scratch as well as any future versions that are > not "latest", since this line of the Dockerfile has not changed since > then > master/server-ha-postgres/Dockerfile#L1>. > i.e. The base image version referenced in this Dockerfile should be > revved with each new version, correct? > > --Tonnis > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > From sthorger at redhat.com Mon Sep 4 14:16:00 2017 From: sthorger at redhat.com (Stian Thorgersen) Date: Mon, 4 Sep 2017 20:16:00 +0200 Subject: [keycloak-dev] Proposal for merging user accounts in Keycloak In-Reply-To: References: Message-ID: Maybe it would be even simpler to rely on required actions for user2 account in both cases. When user1 requests merge a "merge" required action would be added to user2. When user2 then logs in next time (or clicks link in email) the following flow would happen: * User2 completes authentication * Merge required action would be shown. There would be a accept or a reject button on the page * If accept is clicked the account would be merged and the session invalidated * If reject is clicked the required action would be removed and the regular login would continue That would make the flows much simpler in account console and all it would have to do is to have an option to request merge. I'm still slightly worried about it being an option available to all users all the time. Maybe there could as well as the merge option for the realm be an option to select what users can initiate a merge? Select a role, or users belonging to a group or something? On 30 August 2017 at 10:46, Thomas Darimont wrote: > Hello Stian, > > thanks for the great feedback! > > Yes merging accounts can be quite complex as it can have many side effects. > My PoC implementation is very basic and just demonstrates the idea. A > complete > implementation would of course span multiple areas. > > I agree with you that there should be a dedicated realm option "Allow > Account Merge" to enable this feature. > I've seen the mockups of the new account UI in JIRA - looking forward to > see it in action. > > Some notes about the integrations you mentioned: > > Admin Console: > I agree that this could be integrated quite easily to support the > following workflow: > 1. Open the user details of a user in the "users" section. > 2. Click on (new) Merge tab. > The merge tab shows two sections: > - "User selection" where the admin can select exactly one user. > - "Merge options" where the admin can configure how the merge is performed. > 3. Select User > 4. Select Merge Options > Options could include checkboxes with descriptions, e.g. > "Merge Profile", "Merge Roles", "Merge Group Memberships", "Merge > federation links", > "Merge user attributes" > Perhaps one could also indicate whether or not values can be overridden > (User Profile: etc.) > 5. Perform the merge by clicking "Merge" > > User Account: > I think the need to be able merge user accounts arises quite often in > legacy integration > scenarios, e.g. when multiple big and partially overlapping user bases > from multiple > applications are consolidated into one. > Therefore I think it should be an operation that's available as > self-service to users as well, > users usually know their user accounts for different systems. This helps > to keep support efforts small. > > I like your idea of a two phase user merge, first let user1 request to > merge with user2. > User2 needs to approve the merge. If user2 accepts his user information > will be > merged into user1 and user2 will be removed. > > I agree that the user to be merged needs to go through the complete > authentication flow > in order to proof account ownership. > > I think this could be done as follows: > In the account client there would be a new page "Merge Accounts". > On the "Merge Accounts" page there would be sections like "Request Account > Merge", > "Pending Account Merge" and potentially "Approved Account Merges". > > In "Request Account Merge" the currently logged in user could enter the > username of the > user to merge with and request the merge via a "Request Merge" button. > > The "Pending Account Merge" section could show the recently "Account Merge > Request" > with some additional information about the user who send the merge > request > (username, e-mail, firstname, lastname) and some metadata datetime, > IP-Address?, etc. > Here the user has now the option to "Cancel" or "Accept" the "Account > Merge request". > > The "Approved Merge Requests" is optional and could just show a list of > accepted "Account merge requests". > > Example workflow (happy path) for merging the user account user2 into the > leading user account user1. > > User1 > 1. User1 logs into the the account application and goes to the "Merge > Accounts". > 2. User1 would then select a user (user2) and click on "Request Merge". > This would register a "Account Merge Request" for the user2. > If user2 has an email address configured he would be notified via email > with a link > to the "Merge Account" page. > If the user doesn't have an email there could be a RequiredAction added to > user2 to send > the user to the "Merge Account" page on next browser login. > > User2 > 1. User2 logs into the the account application and goes to the "Merge > Accounts", > either by clicking on the link in the email or redirected by the > required action. > 2. The user sees the pending Account Merge request and clicks on "Accept". > 3. A confirmation prompt is shown to the user indicating that this > operation is > irreversible and that his account will be removed after the merge with the > account of user1. > 4. User confirms the merge and is logged out. > > Now user1 can re-login and (potentially) sees the merged user information > of user2, e.g by > visiting the "Merge Account" page and see the "Approved" merge request in > the "Approved Merge Requests" > section. > > This workflow would go through the complete authentication flow for both > users including all custom authenticators. > > As shown in my PoC, accepting a merge fires an ACCOUNT_MERGED event to > notify other other parties about > the merge. When user federation is involved it might be a bit more tricky, > as the merge operation > might need to be propagated through the federation provider explicitly. > > Cheers, > Thomas > > 2017-08-30 8:50 GMT+02:00 Stian Thorgersen : > >> Would be nice to have, but I'm worried about how complex it would end up >> being. It would have to leverage regular login pages and flows as otherwise >> it'd just be way to complex. We're also working on a new account management >> console that is HTML5 and uses new account management REST endpoints. Then >> I could see complications if the user has identity brokering links and also >> if the user is pulled in from an external user federation store. Would also >> need to be available to admins to be a complete feature. >> >> In the admin console the flow would probably be relatively simple, just >> open a user, click on merge tab, find the user and click merge. Might want >> to have some options on how to consolidate the two users there as well. >> >> In user account management console I'm not really sure. It seems that it >> would really be a feature that is not that commonly used, so wonder if it's >> best just left to admins? If available to users it should definitively be >> an option that has to be enabled for the realm. The user shouldn't be able >> to list users, but would have to provide details about the other account. >> That should just request the merge. To complete the merge the user should >> have to login as the other user and approve the merge. Afterwards the user >> would be logged out and able to login as the merged user. >> >> As this is a pretty big thing to add I would first want to make sure >> there's no-one that objects to it and as usual the PR would have to be >> implemented in a generic way (not just the way you want it ;)) and come >> complete with all tests and documentations. >> >> On 29 August 2017 at 15:53, Thomas Darimont < >> thomas.darimont at googlemail.com> wrote: >> >>> As a quick follow up, I implemented a working PoC for merging user >>> accounts >>> in the following branch: >>> https://github.com/thomasdarimont/keycloak/tree/issue/KEYCLO >>> AK-XXX-merge-user-accounts >>> >>> Cheers, >>> Thomas >>> >>> 2017-08-29 2:10 GMT+02:00 Thomas Darimont >> m>: >>> >>> > When integrating multiple legacy systems one often finds that a >>> particular >>> > user >>> > has multiple user accounts. In such scenarios it would be helpful if >>> users >>> > could consolidate their user accounts themselves by merging some of >>> them >>> > into one. >>> > >>> > Currently Keycloak doesn't have an official way to merge two existing >>> user >>> > accounts. >>> > >>> > Since I'm currently facing this in a project I thought a bit about how >>> > this could >>> > be solved in Keycloak. >>> > >>> > Keycloak could provide a dedicated "merge" sub-page in the account >>> > application, >>> > e.g. account/merge. There a authenticated user1 could select the >>> account >>> > he likes >>> > to merge with and verify the ownership of this account. >>> > >>> > If the ownership could be verified successfully the user1 would be >>> asked >>> > for a >>> > final merge confirmation. If the user1 confirms the merge then the >>> > selected user >>> > account (user2) would be merged into the currently logged-in user >>> account >>> > (user1). >>> > >>> > Some logic would then need to decide how to merge the selected user2 >>> into >>> > the >>> > currently logged-in user1, e.g. by assining roles and / or consents and >>> > potentially >>> > copy over some user profile values. >>> > >>> > The account for user2 would then either be marked as merged or deleted. >>> > Login with >>> > user2 is no longer possible from this point on. >>> > >>> > This could be supported by a dedicated "user account merge" SPI that >>> could >>> > decide >>> > whether two accounts can be merged, how the merge is performed and what >>> > user information >>> > will be merged. This would enable great flexibility and help quite a >>> lot >>> > to >>> > ease integration of legacy systems. >>> > >>> > Finally after a successful merge a USER_ACCOUNT_MERGED event with some >>> > metadata >>> > (about user1, user2 etc.) would be fired to notify other systems about >>> the >>> > user account merger. >>> > >>> > Here are the steps in some more detail: >>> > >>> > # Authentication >>> > 0) Unauthenticated user1 goes to the /account/merge page and gets >>> > redirected >>> > to the login page. >>> > >>> > 1) User1 authenticates and gets redirected back to /account/merge >>> > >>> > # Account Selection / Verification >>> > 2) User1 selects an account to merge with, e.g. user2 and verfies >>> ownership >>> > E.g. by showing an embedded login form and ask for Username + Password >>> + >>> > 2nd Factor >>> > if present >>> > >>> > # Merge >>> > 3) Merge the user account >>> > 3.0) Ask user whether accounts should be merged (account of user1 will >>> > become >>> > the remaining / leading account). This is irreversible! >>> > 3.1) Avoid account modification for user2 during merge, e.g. deactivate >>> > the >>> > old user (user2) >>> > 3.2) Record some information about the merged user >>> > Perhaphs via user attributes or maintain an explicit list of merged >>> users. >>> > >>> > # Decide what should be merged >>> > A built-in logic and / or the user decides what should be merged. >>> > 3.4) User Profile information (e.g. complete incomplete fields? >>> > E.g. firstname, lastname, mobile, etc.) >>> > 3.5) Grant all roles of user2 to user1 >>> > 3.6) Grant all consents of user2 to user1 >>> > 3.7) Grant all group memberships of user2 to user1 >>> > Credentials of user2 would be ignored. >>> > >>> > # Conclude the merge >>> > 4) Mark user2 as merged or delete user 2 >>> > Delete user2 or rename user2 and change email to be able to use that >>> > information for user1. >>> > 4.1) Propagate user account merge as event >>> > Propagate a USER_ACCOUNT_MERGED event via the EventListener >>> infrastructure. >>> > The event should contain at least the userId of user1, and the userId >>> of >>> > user2 and >>> > tells which is now the leading account. This enables downstream >>> systems to >>> > get notified >>> > about the account merge. >>> > >>> > WDYT? >>> > >>> > Cheers, >>> > Thomas >>> > >>> _______________________________________________ >>> keycloak-dev mailing list >>> keycloak-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>> >> >> > From ray at decampo.org Mon Sep 4 14:36:37 2017 From: ray at decampo.org (Raymond DeCampo) Date: Mon, 4 Sep 2017 14:36:37 -0400 Subject: [keycloak-dev] Promise wrapper for javascript adapter Message-ID: Hello all, I create a wrapper around the javascript adapter which uses ES6 native Promises. (https://github.com/RayDeCampo/keycloak-promise). If you are interested, I can re-package it for inclusion in Keycloak and create a pull request on GitHub. If you have a different process for contributions, let me know. If you are not interested, no hard feelings. Thanks, Ray From sthorger at redhat.com Tue Sep 5 06:18:36 2017 From: sthorger at redhat.com (Stian Thorgersen) Date: Tue, 5 Sep 2017 12:18:36 +0200 Subject: [keycloak-dev] Promise wrapper for javascript adapter In-Reply-To: References: Message-ID: I don't know much about ES6 native Promises. Can you give me some details about it? What browser support it? What are the benefits of using that instead of our howegrown approach? Etc. On 4 September 2017 at 20:36, Raymond DeCampo wrote: > Hello all, > > I create a wrapper around the javascript adapter which uses ES6 native > Promises. (https://github.com/RayDeCampo/keycloak-promise). > > If you are interested, I can re-package it for inclusion in Keycloak and > create a pull request on GitHub. If you have a different process for > contributions, let me know. > > If you are not interested, no hard feelings. > > Thanks, > Ray > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > From ray at decampo.org Tue Sep 5 08:58:26 2017 From: ray at decampo.org (Raymond DeCampo) Date: Tue, 5 Sep 2017 08:58:26 -0400 Subject: [keycloak-dev] Promise wrapper for javascript adapter In-Reply-To: References: Message-ID: First, if I were to integrate Promise support into the Keycloak, I would be leaving the current javascript adapter as is. This would be an extension in a separate javascript file so that only developers who are interested would get the Promise interface. Existing code using the current adapter would be unaffected. The new code would be a wrapper around the existing code so that maintenance would only be required if the javascript adapter API changes. In terms of browser support, caniuse.com[1] indicates that Promise has broad support; only IE 11 and Opera Mini fail to support Promise. However polyfills are available to provide support. As far as the advantages, the main ones as I see it are: 1) using the standard promise API makes it easier for developers new to the library; 2) using the standard promise API makes the library more interoperable with other libraries; and 3) ES6 Promise objects are chainable making sequences of asynchronous calls cleaner to code. I think the MDN page on Using Promises[2] probably makes a better argument for than I'll be able to here. But the main thrust is that chaining makes it so it is not necessary to have so many nested functions. For example, suppose I am writing a javascript client for a REST API protected by Keycloak. Since the built-in fetch() method returns a Promise with ES6 Promises I can write: // assume authz.updateToken() returns an ES6 Promise authz.updateToken(5).then((token) => { return fetch(this.ENDPOINT, { redirect: 'error', headers: { "Authorization": "Bearer " + token } }); }).then((response) => { showResult(response.text()); }).catch((error) => { displayError(error); }); } Since everything is standard, any JS developer would understand the code. Since both libraries use Promise, I can chain the promises without nesting functions. And since both libraries use Promise, I can use catch() at the end for unified error handling whether the error comes from the Keycloak adapter or from the call to fetch(). [1] http://caniuse.com/#search=Promise [2] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Guide/Using_promises On Tue, Sep 5, 2017 at 6:18 AM, Stian Thorgersen wrote: > I don't know much about ES6 native Promises. Can you give me some details > about it? What browser support it? What are the benefits of using that > instead of our howegrown approach? Etc. > > On 4 September 2017 at 20:36, Raymond DeCampo wrote: > >> Hello all, >> >> I create a wrapper around the javascript adapter which uses ES6 native >> Promises. (https://github.com/RayDeCampo/keycloak-promise). >> >> If you are interested, I can re-package it for inclusion in Keycloak and >> create a pull request on GitHub. If you have a different process for >> contributions, let me know. >> >> If you are not interested, no hard feelings. >> >> Thanks, >> Ray >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> > > From thomas.darimont at googlemail.com Tue Sep 5 10:15:45 2017 From: thomas.darimont at googlemail.com (Thomas Darimont) Date: Tue, 5 Sep 2017 16:15:45 +0200 Subject: [keycloak-dev] Role based Segregation of Duties in Keycloak Message-ID: Hello, for a use case I need to support segregation of duties across multiple applications. > Segregation of Duties (SoD) is a mechanisms that prevents accumulating of too > much power in the hands of a single person. It places a constraints on assignments > of entitlements to users. For example SoD may prevent a single user to create a > request and also approve it. Have you already considered adding this feature? In the context of Keycloak this would mean to specify that two roles are mutually exclusive determined based on the overall effective roles of a user - the same may to service accounts. Issue is here: https://issues.jboss.org/browse/KEYCLOAK-3307 Some thoughts about adding that to Keycloak. Support for ?Segregation of Duties? (SoD) for a realm could be controlled with an on/off switch. If SoD is enabled an administrator can select a set of roles which are then treated as mutually exclusive to the given role when creating or updating a role. Mutually exclusive roles could be stored as a pair of role1:role2 (with their ids) in a table like e.g. keycloak_roles_mutex or keycloak_roles_sod. If role1 is mutually exclusive to role2 then role2 is mutually exclusive to role1. - Creating / Updating a Role with SoD When creating a new or editing an existing role (role1), an administrator could configure SoD by specifying a list of roles that are mutually exclusive to the current role (e.g. role2) -> perhaps called ?Segregation of Duty Roles? - Validating a role assignment with SoD When assigning a role to a user, keycloak would check if the given role combined with any effective role of a user matches a registered pair in the keycloak_roles_mutex table. If this is the case the assignment would be rejected with an error, perhaps indicating which roles cause the conflict. Otherwise the role can be assigned. Same would apply to roles added to groups when a user wants to join a group. - Special Case: Updating a Role with SoD When configuring SoD for an existing role it might happen that there exists already a user role mapping with an then invalid configuration. In that case an SoD cannot be enabled for the given role until the conflicting role mappings are cleared. Until Keycloak provides a way to inspect granted and effective roles assigned to a user in more detail users would need to fall back to database queries to find all conflicting user role mappings. - Removing a Role with SoD configuration When a role is removed and it had SoD roles configured those mappings must be removed as well. Thoughts? Cheers, Thomas From tonnis at autonomic.ai Tue Sep 5 13:05:24 2017 From: tonnis at autonomic.ai (Tonnis Wildeboer) Date: Tue, 5 Sep 2017 10:05:24 -0700 Subject: [keycloak-dev] server-ha-postgres/Dockerfile issue for building past versions? In-Reply-To: References: <95e88e93-f2e3-a93b-fef3-51bd37c24837@autonomic.ai> Message-ID: <3054dd32-598e-fad3-c45e-b50f3b4a14cf@autonomic.ai> Done: https://issues.jboss.org/browse/KEYCLOAK-5407 On 09/03/2017 11:27 PM, Stian Thorgersen wrote: > Indeed, seems that particular image isn't updated. Feel free to create > a JIRA for it. > > On 1 September 2017 at 20:59, Tonnis Wildeboer > wrote: > > Hello, > > I was examining the Dockerfile for server-ha-postgres > (2.5.5.Final) and > noticed that it is based on jboss/keycloak-postgres:/*latest.*/ > > > Seems to me this will be an issue for those attempting to build the > 2.5.5.Final image from scratch as well as any future versions that are > not "latest", since this line of the Dockerfile has not changed since > then > >. > i.e. The base image version referenced in this Dockerfile should be > revved with each new version, correct? > > --Tonnis > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > From sthorger at redhat.com Tue Sep 5 13:35:23 2017 From: sthorger at redhat.com (Stian Thorgersen) Date: Tue, 5 Sep 2017 19:35:23 +0200 Subject: [keycloak-dev] server-ha-postgres/Dockerfile issue for building past versions? In-Reply-To: <3054dd32-598e-fad3-c45e-b50f3b4a14cf@autonomic.ai> References: <95e88e93-f2e3-a93b-fef3-51bd37c24837@autonomic.ai> <3054dd32-598e-fad3-c45e-b50f3b4a14cf@autonomic.ai> Message-ID: Thanks. I'll get this sorted for the next release. On 5 September 2017 at 19:05, Tonnis Wildeboer wrote: > Done: https://issues.jboss.org/browse/KEYCLOAK-5407 > > > On 09/03/2017 11:27 PM, Stian Thorgersen wrote: > > Indeed, seems that particular image isn't updated. Feel free to create a > JIRA for it. > > On 1 September 2017 at 20:59, Tonnis Wildeboer > wrote: > >> Hello, >> >> I was examining the Dockerfile for server-ha-postgres (2.5.5.Final) and >> noticed that it is based on jboss/keycloak-postgres:/*latest.*/ >> > Final/server-ha-postgres/Dockerfile#L1> >> Seems to me this will be an issue for those attempting to build the >> 2.5.5.Final image from scratch as well as any future versions that are >> not "latest", since this line of the Dockerfile has not changed since >> then >> > server-ha-postgres/Dockerfile#L1>. >> i.e. The base image version referenced in this Dockerfile should be >> revved with each new version, correct? >> >> --Tonnis >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> > > > From wadahiro at gmail.com Thu Sep 7 11:19:13 2017 From: wadahiro at gmail.com (Hiroyuki Wada) Date: Fri, 8 Sep 2017 00:19:13 +0900 Subject: [keycloak-dev] keycloak-documentation translation Message-ID: Hello, We have a plan to translate keycloak-documentation to Japanese for the community at our company. Because there is no place to manage the translation resources in keycloak-documentation repository, we are planning to put the resources into own repository and publish the built documents to our corporate site. Do you have any concerns? Of course, we can contribute it if there are any plans to translate it officially. Best Regards, -- Hiroyuki Wada, Nomura Research Institute, Ltd. From bburke at redhat.com Thu Sep 7 11:34:20 2017 From: bburke at redhat.com (Bill Burke) Date: Thu, 7 Sep 2017 11:34:20 -0400 Subject: [keycloak-dev] master build failing on Tomcat 6 Message-ID: Tomcat 6 test is failing on my box. I pulled fresh copy of master and removed org/keycloak from .m2. So I don't think its anything local on my machine: java.lang.NoSuchMethodError: org.apache.tomcat.util.descriptor.DigesterFactory.newDigester(ZZLorg/apache/tomcat/util/digester/RuleSet;Z)Lorg/apache/tomcat/util/digester/Digester; at org.apache.catalina.startup.ContextConfig.createWebXmlDigester(ContextConfig.java:527) at org.apache.catalina.startup.ContextConfig.init(ContextConfig.java:1015) at org.apache.catalina.startup.ContextConfig.lifecycleEvent(ContextConfig.java:276) at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:142) at org.apache.catalina.core.StandardContext.init(StandardContext.java:5703) at org.apache.catalina.core.StandardContext.start(StandardContext.java:4453) at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1057) at org.apache.catalina.core.StandardHost.start(StandardHost.java:822) at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1057) at org.apache.catalina.core.StandardEngine.start(StandardEngine.java:463) at org.apache.catalina.startup.Embedded.start(Embedded.java:825) at org.keycloak.testsuite.TomcatServer.start(TomcatServer.java:122) at org.keycloak.testsuite.TomcatTest.initTomcat(TomcatTest.java:66) -- Bill Burke Red Hat From bburke at redhat.com Thu Sep 7 13:25:11 2017 From: bburke at redhat.com (Bill Burke) Date: Thu, 7 Sep 2017 13:25:11 -0400 Subject: [keycloak-dev] keycloak-documentation translation In-Reply-To: References: Message-ID: That's great! Thank you. We can certainly link to it on our website. We don't have the resources to translate it, even in product. On Thu, Sep 7, 2017 at 11:19 AM, Hiroyuki Wada wrote: > Hello, > > We have a plan to translate keycloak-documentation to Japanese for the > community at our company. > Because there is no place to manage the translation resources in > keycloak-documentation repository, > we are planning to put the resources into own repository and publish > the built documents to our corporate site. > Do you have any concerns? > Of course, we can contribute it if there are any plans to translate it > officially. > > Best Regards, > > -- > Hiroyuki Wada, > Nomura Research Institute, Ltd. > _______________________________________________ > 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 Fri Sep 8 09:32:02 2017 From: bburke at redhat.com (Bill Burke) Date: Fri, 8 Sep 2017 09:32:02 -0400 Subject: [keycloak-dev] anybody seeing master build failures? Message-ID: Anybody else seeing this? Tomcat 6 test is failing on my box. I pulled fresh copy of master and removed org/keycloak from .m2. So I don't think its anything local on my machine: java.lang.NoSuchMethodError: org.apache.tomcat.util.descriptor.DigesterFactory.newDigester(ZZLorg/apache/tomcat/util/digester/RuleSet;Z)Lorg/apache/tomcat/util/digester/Digester; at org.apache.catalina.startup.ContextConfig.createWebXmlDigester(ContextConfig.java:527) at org.apache.catalina.startup.ContextConfig.init(ContextConfig.java:1015) at org.apache.catalina.startup.ContextConfig.lifecycleEvent(ContextConfig.java:276) at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:142) at org.apache.catalina.core.StandardContext.init(StandardContext.java:5703) at org.apache.catalina.core.StandardContext.start(StandardContext.java:4453) at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1057) at org.apache.catalina.core.StandardHost.start(StandardHost.java:822) at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1057) at org.apache.catalina.core.StandardEngine.start(StandardEngine.java:463) at org.apache.catalina.startup.Embedded.start(Embedded.java:825) at org.keycloak.testsuite.TomcatServer.start(TomcatServer.java:122) at org.keycloak.testsuite.TomcatTest.initTomcat(TomcatTest.java:66) -- Bill Burke Red Hat From psilva at redhat.com Fri Sep 8 11:00:04 2017 From: psilva at redhat.com (Pedro Igor Silva) Date: Fri, 8 Sep 2017 12:00:04 -0300 Subject: [keycloak-dev] anybody seeing master build failures? In-Reply-To: References: Message-ID: Same issue here. It seems there is a conflict with io.undertow.jastow:jastow dependency. On Fri, Sep 8, 2017 at 10:32 AM, Bill Burke wrote: > Anybody else seeing this? > > Tomcat 6 test is failing on my box. I pulled fresh copy of master and > removed org/keycloak from .m2. So I don't think its anything local on > my machine: > > java.lang.NoSuchMethodError: > org.apache.tomcat.util.descriptor.DigesterFactory. > newDigester(ZZLorg/apache/tomcat/util/digester/RuleSet; > Z)Lorg/apache/tomcat/util/digester/Digester; > > at org.apache.catalina.startup.ContextConfig.createWebXmlDigester( > ContextConfig.java:527) > > at org.apache.catalina.startup.ContextConfig.init(ContextConfig.java:1015) > > at org.apache.catalina.startup.ContextConfig.lifecycleEvent( > ContextConfig.java:276) > > at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent( > LifecycleSupport.java:142) > > at org.apache.catalina.core.StandardContext.init( > StandardContext.java:5703) > > at org.apache.catalina.core.StandardContext.start( > StandardContext.java:4453) > > at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1057) > > at org.apache.catalina.core.StandardHost.start(StandardHost.java:822) > > at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1057) > > at org.apache.catalina.core.StandardEngine.start(StandardEngine.java:463) > > at org.apache.catalina.startup.Embedded.start(Embedded.java:825) > > at org.keycloak.testsuite.TomcatServer.start(TomcatServer.java:122) > > at org.keycloak.testsuite.TomcatTest.initTomcat(TomcatTest.java:66) > > -- > Bill Burke > Red Hat > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > From nielsbne at gmail.com Sun Sep 10 12:14:08 2017 From: nielsbne at gmail.com (Niels Bertram) Date: Mon, 11 Sep 2017 02:14:08 +1000 Subject: [keycloak-dev] Keycloak server automation Message-ID: Hi dev-team, not sure if its of any value but wanted share with you a Jython based automation suite to configure Wildfly and its various subsystems. https://github.com/fareliner/jyboss-cli The library also comes with an Ansible module that can be used to re/configure a Keycloak server idempotent - the Ansible way. https://github.com/fareliner/jyboss-cli/blob/master/module/jboss.py Will publish a fully working Ansible playbook shortly, just wanted to see if there is much interest in this kind of topic. I think it could be very handy to give people a set of starter playbooks or even to use it for creating more complex docker images of Keycloak using ansible-docker. Let me know what you think. Cheers, Niels From bburke at redhat.com Mon Sep 11 10:04:04 2017 From: bburke at redhat.com (Bill Burke) Date: Mon, 11 Sep 2017 10:04:04 -0400 Subject: [keycloak-dev] @Column.updatable=false Message-ID: This popped up in a support request, but we have a number of foreign keys (with indexes) that are never changed, but yet are included in update requests of those tables by Hibernate. It seems that a number of databases (and Hibernate, although don't know if there is a setting for that) will not check to see if the old value equals new value. This can cause concurrency issues (db deadlock). I bet it is a big performance issue too if indexes are updated as well. Should this be bumped to a priority for 3.4.1? I'll create a JIRA if so. -- Bill Burke Red Hat From hmlnarik at redhat.com Mon Sep 11 11:42:06 2017 From: hmlnarik at redhat.com (Hynek Mlnarik) Date: Mon, 11 Sep 2017 17:42:06 +0200 Subject: [keycloak-dev] @Column.updatable=false In-Reply-To: References: Message-ID: The updatable=false causes the column not to be in UPDATE statements which is beneficial for several reasons: * UPDATEs update less columns - thats always positive * Database vendor _might_ (and some do) take advantage of the affected columns list in UPDATE to eliminate even the need to check whether related index needs to be updated instead of checking whether the values match * There _might_ be optimizations on Hibernate side that would help. I'd need to dive more into actual details as I'd rather expect that it would show up if we used Hibernate caching. Yet the performance might actually improve even more by using @DynamicUpdate annotation on JPA entities. The @DynamicUpdate would do the job the Column.updatable does, in a less-prohibitive way, still allowing the updates but only including the changed fields in the result UPDATE. I'd imagine that would be most beneficial on UserEntity. --Hynek On Mon, Sep 11, 2017 at 4:04 PM, Bill Burke wrote: > This popped up in a support request, but we have a number of foreign > keys (with indexes) that are never changed, but yet are included in > update requests of those tables by Hibernate. It seems that a number > of databases (and Hibernate, although don't know if there is a setting > for that) will not check to see if the old value equals new value. > This can cause concurrency issues (db deadlock). I bet it is a big > performance issue too if indexes are updated as well. > > Should this be bumped to a priority for 3.4.1? I'll create a JIRA if so. > > -- > Bill Burke > Red Hat > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev -- --Hynek From bburke at redhat.com Mon Sep 11 12:44:50 2017 From: bburke at redhat.com (Bill Burke) Date: Mon, 11 Sep 2017 12:44:50 -0400 Subject: [keycloak-dev] @Column.updatable=false In-Reply-To: References: Message-ID: Not sure on @DynamicUpdate...That screws with query caching. Not sure of the advantages/disadvantages On Mon, Sep 11, 2017 at 11:42 AM, Hynek Mlnarik wrote: > The updatable=false causes the column not to be in UPDATE statements > which is beneficial for several reasons: > > * UPDATEs update less columns - thats always positive > * Database vendor _might_ (and some do) take advantage of the affected > columns list in UPDATE to eliminate even the need to check whether > related index needs to be updated instead of checking whether the > values match > * There _might_ be optimizations on Hibernate side that would help. > I'd need to dive more into actual details as I'd rather expect that it > would show up if we used Hibernate caching. > > Yet the performance might actually improve even more by using > @DynamicUpdate annotation on JPA entities. The @DynamicUpdate would do > the job the Column.updatable does, in a less-prohibitive way, still > allowing the updates but only including the changed fields in the > result UPDATE. I'd imagine that would be most beneficial on > UserEntity. > > --Hynek > > > On Mon, Sep 11, 2017 at 4:04 PM, Bill Burke wrote: >> This popped up in a support request, but we have a number of foreign >> keys (with indexes) that are never changed, but yet are included in >> update requests of those tables by Hibernate. It seems that a number >> of databases (and Hibernate, although don't know if there is a setting >> for that) will not check to see if the old value equals new value. >> This can cause concurrency issues (db deadlock). I bet it is a big >> performance issue too if indexes are updated as well. >> >> Should this be bumped to a priority for 3.4.1? I'll create a JIRA if so. >> >> -- >> Bill Burke >> Red Hat >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > > -- > > --Hynek -- Bill Burke Red Hat From bburke at redhat.com Mon Sep 11 16:51:03 2017 From: bburke at redhat.com (Bill Burke) Date: Mon, 11 Sep 2017 16:51:03 -0400 Subject: [keycloak-dev] anybody seeing master build failures? In-Reply-To: References: Message-ID: How is this passing in travis? On Fri, Sep 8, 2017 at 11:00 AM, Pedro Igor Silva wrote: > Same issue here. It seems there is a conflict with io.undertow.jastow:jastow > dependency. > > On Fri, Sep 8, 2017 at 10:32 AM, Bill Burke wrote: >> >> Anybody else seeing this? >> >> Tomcat 6 test is failing on my box. I pulled fresh copy of master and >> removed org/keycloak from .m2. So I don't think its anything local on >> my machine: >> >> java.lang.NoSuchMethodError: >> >> org.apache.tomcat.util.descriptor.DigesterFactory.newDigester(ZZLorg/apache/tomcat/util/digester/RuleSet;Z)Lorg/apache/tomcat/util/digester/Digester; >> >> at >> org.apache.catalina.startup.ContextConfig.createWebXmlDigester(ContextConfig.java:527) >> >> at org.apache.catalina.startup.ContextConfig.init(ContextConfig.java:1015) >> >> at >> org.apache.catalina.startup.ContextConfig.lifecycleEvent(ContextConfig.java:276) >> >> at >> org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:142) >> >> at >> org.apache.catalina.core.StandardContext.init(StandardContext.java:5703) >> >> at >> org.apache.catalina.core.StandardContext.start(StandardContext.java:4453) >> >> at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1057) >> >> at org.apache.catalina.core.StandardHost.start(StandardHost.java:822) >> >> at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1057) >> >> at org.apache.catalina.core.StandardEngine.start(StandardEngine.java:463) >> >> at org.apache.catalina.startup.Embedded.start(Embedded.java:825) >> >> at org.keycloak.testsuite.TomcatServer.start(TomcatServer.java:122) >> >> at org.keycloak.testsuite.TomcatTest.initTomcat(TomcatTest.java:66) >> >> -- >> 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 Tue Sep 12 03:42:25 2017 From: mposolda at redhat.com (Marek Posolda) Date: Tue, 12 Sep 2017 09:42:25 +0200 Subject: [keycloak-dev] Improvements on clientSession, code-to-token endpoint and refresh-token endpoint Message-ID: There are few things, which can be improved with current implementation of authenticatedClientSessionModel, codeToToken endpoint and refresh token endpoint. Here is some overview of the current issues: 1. The UserSessionModel currently contains just 1 authenticatedClientSession per client. The issue is, that if there are multiple browser tabs for same client application, they may not have same notes, protocolMappers and roles (for example if we limit the roles based on "scope" parameter, the roles can be different in browser tab1 and tab2 as every tab can have different scope parameter. This is not big issue now, since we don't have proper support for "scope" parameter, but could be in the future..) 2. The authenticatedClientSession is currently needed in code-to-token request. This is a bit of perf issue in cross-dc. The code-to-token request can happen in different DC then authentication. It will be ideal if code-to-token request doesn't need to wait until userSession with attached authenticatedClientSession is replicated from the second DC 3. There is just 1 valid code per authenticatedClientSession tracked in the attached note - in case that 2 user sends 2 concurrent requests to http://localhost:8080/customer-portal, it may happen that there are 2 SSO logins concurrently issued, however just 1 of them will successfully pass the code-to-token request (clientSession note will be overwritten by the second request, so first request will fail in code-to-token request due the different note value) 4. Refresh token is signed by same key like accessToken. This is not ideal for: - performance (RSA is an unecessary overhead. Symmetric cryptography is sufficient) - Security: Refresh tokens and access tokens can be exchanged. Refresh token is JWT visible by application and end user (not direct security threat though) Possible solution proposal: - Move some stuff from authenticatedClientSessionModel to the code parameter and refreshToken itself. - Code will be encrypted JWT containing just clientSession notes. Not the protocolMappers and roles - Refresh token will contain both roles and protocolMappers (roles are here already. The protocolMappers will be new thing on refresh token) - Both code and refreshToken are AES-128 encrypted. Just the keycloak server has the key and can decrypt them. - AuthenticatedClientSessionModel won't contain protocolMappers and roles anymore - Use single-use cache to track whether the particular value of code parameter was already used. I've tried the code to be signed instead of encrypted, but it may have security implications (code would be visible by adapters and end-user). The roles and protocolMappers are not needed in code and keeping them would make the code unecessary big (URL limit is 2000 characters). I've tried to add more details into the Google document: https://docs.google.com/document/d/1C1vFhyGPBOnN3pprw6XPZnK08azyTm-HVIqO9dY3aTY/edit?usp=sharing . Feel free to reply in the document or here in the email. Marek From supittma at redhat.com Tue Sep 12 08:45:30 2017 From: supittma at redhat.com (Summers Pittman) Date: Tue, 12 Sep 2017 08:45:30 -0400 Subject: [keycloak-dev] Authentication with Google Identity Tokens aka Better Android support Message-ID: TL;DR; How do I shove this : https://developers.google.com/identity/sign-in/web/backend-auth into KeyCloak. I've been reading up on how to extend the KeyCloak service and I want to write a (SPI? module? extension?) that let's me sign into my server services using a Google ID Token. This will let me use the Google account on my Android phone without ever having to open a web page. In fact if I only have one Google account on my phone I can automatically log my user into my app without ever having to prompt them. However, I'm not really sure where to start. I've cloned the keycloak repository and have been reviewing the code there and cross referencing with the docs, but I think I need a little more "push" in the right direction. For reference, I've implemented this flow in both Node.js and Java before without much trouble so I should be able to get a PoC up in an afternoon or two once I know where to put the code. Node.js : https://github.com/secondsun/FH-Google-mBaas-Auth/blob/master/lib/auth.js#L47 Java : https://github.com/secondsun/devnexus-site/blob/master/src/main/java/com/devnexus/ting/web/controller/AndroidLoginController.java#L100 Thanks, Summers From rmartinc at redhat.com Tue Sep 12 13:59:55 2017 From: rmartinc at redhat.com (Ricardo Martin Camarero) Date: Tue, 12 Sep 2017 19:59:55 +0200 Subject: [keycloak-dev] Implementations for KEYCLOAK-2209 Message-ID: Hi team, I'm forwarding this email to the list following Stian's recommendation. I needed to learn more about keycloak (how to manage the maven project, how to add a modification, how to test it, and so on and so forth), so I decided to start looking the code and try to help when I have some free time. As I filed an internal RFE because one customer wanted a similar solution than the one specified in KEYCLOAK-2209 I started to implement something. Now I have two possible ideas that are not completely implemented (I haven't done any group use for example). Both ideas have similarities: * I have extended the database to include a REALM_PASSWORD_POLICY_GROUP table that contains more policies associated to the realm. I thought about using an attribute but I decided to extend the database because the current policy attribute is a long string (length 2550). This way in the realm (policies page) now you can configure more than one password policy (default is the current one and you can add new policies that are saved in the new table with a name). * The user has a new attribute that contains the password policy, in this case I have re-used an attribute (I'm not sure about this idea, now I think using a new column would be better but I needed a multiple attribute for option 2). * In both solutions I needed to extend the PasswordPolicyProvider interface to pass the config to the two validate methods: ? PolicyError validate(RealmModel realm, UserModel user, String password, Object config); ? I think there is a bug in this part in current master branch, because regex policy is multiple, and you cannot assign two different regex providers in the same policy (PasswordPolicy stores the configuration in a Map, so you cannot have two different configurations for the same type, if you assign two regex providers they are transformed into one as soon as you save the policy). Now the two implementations: 1) The first idea let us configure to a user one password policy. My branch is this one: ? https://github.com/rmartinc/keycloak/tree/password-policy-groups ? In this solution the user has a combo (only one policy can be assigned to a user) and only one policy is applied to that user. My idea was extending the idea using groups and priorities. Password policies will have a priority, and only one policy will apply to a user (from all the possible policies the one with the higher priority applies). For the moment I only modified keycloak to have a different policy in the user (no priorities or group policies). 2) The second idea follows the description in 2209. The branch is the following: ? https://github.com/rmartinc/keycloak/tree/password-policy-groups-multi ? Here the user can have multiple password policies. The definitive policy is a merge between all the policies applied to the user. To do this I needed to extend the PasswordPolicyProvider interface even more, in order to have a compare method that returns which policy is more restrictive. Extending this idea to groups is just merging more policies. You can test my ideas (I think both of them are working). If you are interested please let me know which idea you think is better (I'm not completely sure, now I think that I prefer option 1, although option 2 is more similar to the RFE description, I think the latter is very confusing). If you like one of them, I'll try to finish the implementation (now there are no tests and some decisions I took maybe are wrong). If you think this is not needed or it's not the time to implement this RFE don't worry, it's ok, I needed to play with keycloak, and that part is done. Regards! From sthorger at redhat.com Tue Sep 12 15:54:05 2017 From: sthorger at redhat.com (Stian Thorgersen) Date: Tue, 12 Sep 2017 21:54:05 +0200 Subject: [keycloak-dev] master build failing on Tomcat 6 In-Reply-To: References: Message-ID: I'm seeing this as well. Anyone sign up to getting this fixed? On 7 September 2017 at 17:34, Bill Burke wrote: > Tomcat 6 test is failing on my box. I pulled fresh copy of master and > removed org/keycloak from .m2. So I don't think its anything local on > my machine: > > java.lang.NoSuchMethodError: > org.apache.tomcat.util.descriptor.DigesterFactory. > newDigester(ZZLorg/apache/tomcat/util/digester/RuleSet; > Z)Lorg/apache/tomcat/util/digester/Digester; > > at org.apache.catalina.startup.ContextConfig.createWebXmlDigester( > ContextConfig.java:527) > > at org.apache.catalina.startup.ContextConfig.init(ContextConfig.java:1015) > > at org.apache.catalina.startup.ContextConfig.lifecycleEvent( > ContextConfig.java:276) > > at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent( > LifecycleSupport.java:142) > > at org.apache.catalina.core.StandardContext.init( > StandardContext.java:5703) > > at org.apache.catalina.core.StandardContext.start( > StandardContext.java:4453) > > at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1057) > > at org.apache.catalina.core.StandardHost.start(StandardHost.java:822) > > at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1057) > > at org.apache.catalina.core.StandardEngine.start(StandardEngine.java:463) > > at org.apache.catalina.startup.Embedded.start(Embedded.java:825) > > at org.keycloak.testsuite.TomcatServer.start(TomcatServer.java:122) > > at org.keycloak.testsuite.TomcatTest.initTomcat(TomcatTest.java:66) > > > > > -- > 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 Tue Sep 12 23:25:10 2017 From: sthorger at redhat.com (Stian Thorgersen) Date: Tue, 12 Sep 2017 20:25:10 -0700 Subject: [keycloak-dev] Authentication with Google Identity Tokens aka Better Android support In-Reply-To: References: Message-ID: Interesting, but maybe not that straightforward to do. Depends on what flow you'd like to use. The ideal would be to use the web redirect flow (authorization code flow). Using the web redirect flow you can still display forms if needed. For instance if the ID token isn't valid and you want to ask for username/password instead, the user needs to update their profile, etc.. Alternative is to use the direct grant (aka resource owner credential grant) flow to simply exchange the ID token retrieved from Google with tokens from Keycloak. In either case this can be done with custom authentication flow and authenticator. Take a look at the server developer guide and our examples for some inspiration there. It may also better fit in with identity brokering, but that would probably require code changes on the Keycloak side rather than just an extension. On 12 September 2017 at 05:45, Summers Pittman wrote: > TL;DR; How do I shove this : > https://developers.google.com/identity/sign-in/web/backend-auth into > KeyCloak. > > I've been reading up on how to extend the KeyCloak service and I want to > write a (SPI? module? extension?) that let's me sign into my server > services using a Google ID Token. This will let me use the Google account > on my Android phone without ever having to open a web page. In fact if I > only have one Google account on my phone I can automatically log my user > into my app without ever having to prompt them. > > However, I'm not really sure where to start. I've cloned the keycloak > repository and have been reviewing the code there and cross referencing > with the docs, but I think I need a little more "push" in the right > direction. > > For reference, I've implemented this flow in both Node.js and Java before > without much trouble so I should be able to get a PoC up in an afternoon or > two once I know where to put the code. > > Node.js : > https://github.com/secondsun/FH-Google-mBaas-Auth/blob/ > master/lib/auth.js#L47 > Java : > https://github.com/secondsun/devnexus-site/blob/master/src/ > main/java/com/devnexus/ting/web/controller/AndroidLoginController.java# > L100 > > Thanks, > > Summers > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > From sthorger at redhat.com Tue Sep 12 23:28:51 2017 From: sthorger at redhat.com (Stian Thorgersen) Date: Tue, 12 Sep 2017 20:28:51 -0700 Subject: [keycloak-dev] Promise wrapper for javascript adapter In-Reply-To: References: Message-ID: I can see how it would be nice. I'm a bit worried that the separate javascript file would simply get out of date and it would also need separate testing. We're already lacking a bit on testing of the JS adapter in the first place and this would be yet another thing to test. Is there a way we could simply have a config option in the current javascript adapter that allows setting what promise to return? That way it's probably just a few lines in keycloak.js where it's creating the promise objects to switch between the two? On 5 September 2017 at 05:58, Raymond DeCampo wrote: > First, if I were to integrate Promise support into the Keycloak, I would > be leaving the current javascript adapter as is. This would be an > extension in a separate javascript file so that only developers who are > interested would get the Promise interface. Existing code using the > current adapter would be unaffected. The new code would be a wrapper > around the existing code so that maintenance would only be required if the > javascript adapter API changes. > > In terms of browser support, caniuse.com[1] indicates that Promise has > broad support; only IE 11 and Opera Mini fail to support Promise. However > polyfills are available to provide support. > > As far as the advantages, the main ones as I see it are: 1) using the > standard promise API makes it easier for developers new to the library; 2) > using the standard promise API makes the library more interoperable with > other libraries; and 3) ES6 Promise objects are chainable making sequences > of asynchronous calls cleaner to code. > > I think the MDN page on Using Promises[2] probably makes a better argument > for than I'll be able to here. But the main thrust is that chaining makes > it so it is not necessary to have so many nested functions. > > For example, suppose I am writing a javascript client for a REST API > protected by Keycloak. Since the built-in fetch() method returns a Promise > with ES6 Promises I can write: > > // assume authz.updateToken() returns an ES6 Promise > authz.updateToken(5).then((token) => { > return fetch(this.ENDPOINT, { > redirect: 'error', > headers: { "Authorization": "Bearer " + token } > }); > }).then((response) => { > showResult(response.text()); > }).catch((error) => { > displayError(error); > }); > } > > Since everything is standard, any JS developer would understand the code. > Since both libraries use Promise, I can chain the promises without nesting > functions. And since both libraries use Promise, I can use catch() at the > end for unified error handling whether the error comes from the Keycloak > adapter or from the call to fetch(). > > > [1] http://caniuse.com/#search=Promise > [2] https://developer.mozilla.org/en-US/docs/Web/JavaScript/ > Guide/Using_promises > > > On Tue, Sep 5, 2017 at 6:18 AM, Stian Thorgersen > wrote: > >> I don't know much about ES6 native Promises. Can you give me some details >> about it? What browser support it? What are the benefits of using that >> instead of our howegrown approach? Etc. >> >> On 4 September 2017 at 20:36, Raymond DeCampo wrote: >> >>> Hello all, >>> >>> I create a wrapper around the javascript adapter which uses ES6 native >>> Promises. (https://github.com/RayDeCampo/keycloak-promise). >>> >>> If you are interested, I can re-package it for inclusion in Keycloak and >>> create a pull request on GitHub. If you have a different process for >>> contributions, let me know. >>> >>> If you are not interested, no hard feelings. >>> >>> Thanks, >>> Ray >>> _______________________________________________ >>> keycloak-dev mailing list >>> keycloak-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>> >> >> > From sthorger at redhat.com Wed Sep 13 02:40:42 2017 From: sthorger at redhat.com (Stian Thorgersen) Date: Wed, 13 Sep 2017 08:40:42 +0200 Subject: [keycloak-dev] Improvements on clientSession, code-to-token endpoint and refresh-token endpoint In-Reply-To: References: Message-ID: I'm going to ignore your email and assume all the details are in the doc. Is that correct? On 12 September 2017 at 09:42, Marek Posolda wrote: > There are few things, which can be improved with current implementation > of authenticatedClientSessionModel, codeToToken endpoint and refresh > token endpoint. > > Here is some overview of the current issues: > > 1. The UserSessionModel currently contains just 1 > authenticatedClientSession per client. > > The issue is, that if there are multiple browser tabs for same client > application, they may not have same notes, protocolMappers and roles > (for example if we limit the roles based on "scope" parameter, the roles > can be different in browser tab1 and tab2 as every tab can have > different scope parameter. This is not big issue now, since we don't > have proper support for "scope" parameter, but could be in the future..) > > 2. The authenticatedClientSession is currently needed in code-to-token > request. This is a bit of perf issue in cross-dc. The code-to-token > request can happen in different DC then authentication. It will be ideal > if code-to-token request doesn't need to wait until userSession with > attached authenticatedClientSession is replicated from the second DC > > 3. There is just 1 valid code per authenticatedClientSession tracked in > the attached note - in case that 2 user sends 2 concurrent requests to > http://localhost:8080/customer-portal, it may happen that there are 2 > SSO logins concurrently issued, however just 1 of them will successfully > pass the code-to-token request (clientSession note will be overwritten > by the second request, so first request will fail in code-to-token > request due the different note value) > > 4. Refresh token is signed by same key like accessToken. This is not > ideal for: > - performance (RSA is an unecessary overhead. Symmetric cryptography is > sufficient) > - Security: Refresh tokens and access tokens can be exchanged. Refresh > token is JWT visible by application and end user (not direct security > threat though) > > > Possible solution proposal: > > - Move some stuff from authenticatedClientSessionModel to the code > parameter and refreshToken itself. > > - Code will be encrypted JWT containing just clientSession notes. Not > the protocolMappers and roles > > - Refresh token will contain both roles and protocolMappers (roles are > here already. The protocolMappers will be new thing on refresh token) > > - Both code and refreshToken are AES-128 encrypted. Just the keycloak > server has the key and can decrypt them. > > - AuthenticatedClientSessionModel won't contain protocolMappers and > roles anymore > > - Use single-use cache to track whether the particular value of code > parameter was already used. > > > I've tried the code to be signed instead of encrypted, but it may have > security implications (code would be visible by adapters and end-user). > The roles and protocolMappers are not needed in code and keeping them > would make the code unecessary big (URL limit is 2000 characters). > > I've tried to add more details into the Google document: > https://docs.google.com/document/d/1C1vFhyGPBOnN3pprw6XPZnK08azyT > m-HVIqO9dY3aTY/edit?usp=sharing > . Feel free to reply in the document or here in the email. > > Marek > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > From ivan at akvo.org Wed Sep 13 06:53:08 2017 From: ivan at akvo.org (=?UTF-8?Q?Iv=c3=a1n_Perdomo?=) Date: Wed, 13 Sep 2017 12:53:08 +0200 Subject: [keycloak-dev] Proposal: Update Dockerfiles to use jboss-cli Message-ID: <264526a2-f0ec-d46d-7d42-7b2fb2bbcb76@akvo.org> Hi all, Thanks to Rub?n [1] we have successfully changed our customization to Keycloak Docker images using jboss-cli and embed-server, instead of XSLT transformations. In the past Stian has suggested that the XSLT was done before embed-server was available [2]. We would like to contribute some of this changes to the base images. Can we log an issue and send a pull request? The proposed changes will be just to remove xlst transformations with jboss-cli commands. [1] https://github.com/baztan106483 [2] https://lists.jboss.org/pipermail/keycloak-user/2016-February/005120.html Thanks, -- Iv?n From ray at decampo.org Wed Sep 13 08:31:22 2017 From: ray at decampo.org (Raymond DeCampo) Date: Wed, 13 Sep 2017 08:31:22 -0400 Subject: [keycloak-dev] Promise wrapper for javascript adapter In-Reply-To: References: Message-ID: I understand the concern about increasing the test surface. However I don't think that introducing a configuration option and having methods that return different objects based on the option will decrease the testing risk. There are places in the keycloak.js where it invokes it's own methods and uses the custom promise object, for example: https://github.com/keycloak/keycloak/blob/b7af96aa4d7daeec6da12ee9326d1c0fdcc4850f/adapters/oidc/js/src/main/resources/keycloak.js#L128-L131 kc.login(options).success(function () { initPromise.setSuccess(); }).error(function () { initPromise.setError(); }); So these places would have to change based on the configuration option and I think it will become a bigger problem. What if instead we add a method on the Keycloak object which returns a wrapper instance using Promises and keep everything in the one keycloak.js file? So clients could do: var keycloak = new Keycloak().promiseWrapper(); keycloak.init().then(function() { ... }); And everything is in the one file? Although let me make one more pitch on the merits of my original suggestion: 1. No changes to keycloak.js => less risk of breaking something that already works 2. The KeycloakPromise implementation delegates to the keycloak.js implementation which means that fixes to keycloak.js automatically propogate. 3. The KeycloakPromise implementation is a wrapper which means it only needs to be changed if there is a change to the keycloak.js API, e.g. a new method or a new argument to a method (but not a new option on an existing argument) 4. I think it will be clearer to document the interfaces for the end user but of course that is a matter of opinion. On Tue, Sep 12, 2017 at 11:28 PM, Stian Thorgersen wrote: > I can see how it would be nice. I'm a bit worried that the separate > javascript file would simply get out of date and it would also need > separate testing. We're already lacking a bit on testing of the JS adapter > in the first place and this would be yet another thing to test. Is there a > way we could simply have a config option in the current javascript adapter > that allows setting what promise to return? That way it's probably just a > few lines in keycloak.js where it's creating the promise objects to switch > between the two? > > On 5 September 2017 at 05:58, Raymond DeCampo wrote: > >> First, if I were to integrate Promise support into the Keycloak, I would >> be leaving the current javascript adapter as is. This would be an >> extension in a separate javascript file so that only developers who are >> interested would get the Promise interface. Existing code using the >> current adapter would be unaffected. The new code would be a wrapper >> around the existing code so that maintenance would only be required if the >> javascript adapter API changes. >> >> In terms of browser support, caniuse.com[1] indicates that Promise has >> broad support; only IE 11 and Opera Mini fail to support Promise. However >> polyfills are available to provide support. >> >> As far as the advantages, the main ones as I see it are: 1) using the >> standard promise API makes it easier for developers new to the library; 2) >> using the standard promise API makes the library more interoperable with >> other libraries; and 3) ES6 Promise objects are chainable making sequences >> of asynchronous calls cleaner to code. >> >> I think the MDN page on Using Promises[2] probably makes a better >> argument for than I'll be able to here. But the main thrust is that >> chaining makes it so it is not necessary to have so many nested functions. >> >> For example, suppose I am writing a javascript client for a REST API >> protected by Keycloak. Since the built-in fetch() method returns a Promise >> with ES6 Promises I can write: >> >> // assume authz.updateToken() returns an ES6 Promise >> authz.updateToken(5).then((token) => { >> return fetch(this.ENDPOINT, { >> redirect: 'error', >> headers: { "Authorization": "Bearer " + token } >> }); >> }).then((response) => { >> showResult(response.text()); >> }).catch((error) => { >> displayError(error); >> }); >> } >> >> Since everything is standard, any JS developer would understand the >> code. Since both libraries use Promise, I can chain the promises without >> nesting functions. And since both libraries use Promise, I can use catch() >> at the end for unified error handling whether the error comes from the >> Keycloak adapter or from the call to fetch(). >> >> >> [1] http://caniuse.com/#search=Promise >> [2] https://developer.mozilla.org/en-US/docs/Web/JavaScript/ >> Guide/Using_promises >> >> >> On Tue, Sep 5, 2017 at 6:18 AM, Stian Thorgersen >> wrote: >> >>> I don't know much about ES6 native Promises. Can you give me some >>> details about it? What browser support it? What are the benefits of using >>> that instead of our howegrown approach? Etc. >>> >>> On 4 September 2017 at 20:36, Raymond DeCampo wrote: >>> >>>> Hello all, >>>> >>>> I create a wrapper around the javascript adapter which uses ES6 native >>>> Promises. (https://github.com/RayDeCampo/keycloak-promise). >>>> >>>> If you are interested, I can re-package it for inclusion in Keycloak and >>>> create a pull request on GitHub. If you have a different process for >>>> contributions, let me know. >>>> >>>> If you are not interested, no hard feelings. >>>> >>>> Thanks, >>>> Ray >>>> _______________________________________________ >>>> keycloak-dev mailing list >>>> keycloak-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>>> >>> >>> >> > From bburke at redhat.com Wed Sep 13 10:52:05 2017 From: bburke at redhat.com (Bill Burke) Date: Wed, 13 Sep 2017 10:52:05 -0400 Subject: [keycloak-dev] direct exchanges Message-ID: We have direct grants where client passes username and creds to obtain a token for that user. We have client credentials grant to get a token for the client itself. What if we had a direct exchange where the client provides user id or username and gets a token for that user? The client does not have to provide user credentials. What is the use case for this? Consider an application that is authenticated via an external mechanism. Consider that this external mechanism does not provide any type of token, it just authenticates a username. This application needs to talk to services secured by Keycloak. So, with this new direct exchange mechanism, the application only needs to have a client account on the Keycloak server to obtain a token for a keycloak user. Another benefit of this is that Keycloak does not need to understand external token formats in order to provide a token to a client that authenticates users by an external mechanism. There's some big security risks for this. If the client's secret is stolen the attacker would be able to mint token for any user. This is somewhat mitigated in two ways: a) If the token is minted for the client, the scope of the token can be limited, i.e. role mappings limited b) if the client is asking for a different audience (a different client) the client can be limited on the audience it can ask for. (we already do this check for client to client token exchange). -- Bill Burke Red Hat From mposolda at redhat.com Wed Sep 13 11:32:52 2017 From: mposolda at redhat.com (Marek Posolda) Date: Wed, 13 Sep 2017 17:32:52 +0200 Subject: [keycloak-dev] Improvements on clientSession, code-to-token endpoint and refresh-token endpoint In-Reply-To: References: Message-ID: Yep, email is just a bit shorter version. BTV. Replied to your comments in the doc. Marek On 13/09/17 08:40, Stian Thorgersen wrote: > I'm going to ignore your email and assume all the details are in the > doc. Is that correct? > > On 12 September 2017 at 09:42, Marek Posolda > wrote: > > There are few things, which can be improved with current > implementation > of authenticatedClientSessionModel, codeToToken endpoint and refresh > token endpoint. > > Here is some overview of the current issues: > > 1. The UserSessionModel currently contains just 1 > authenticatedClientSession per client. > > The issue is, that if there are multiple browser tabs for same client > application, they may not have same notes, protocolMappers and roles > (for example if we limit the roles based on "scope" parameter, the > roles > can be different in browser tab1 and tab2 as every tab can have > different scope parameter. This is not big issue now, since we don't > have proper support for "scope" parameter, but could be in the > future..) > > 2. The authenticatedClientSession is currently needed in code-to-token > request. This is a bit of perf issue in cross-dc. The code-to-token > request can happen in different DC then authentication. It will be > ideal > if code-to-token request doesn't need to wait until userSession with > attached authenticatedClientSession is replicated from the second DC > > 3. There is just 1 valid code per authenticatedClientSession > tracked in > the attached note - in case that 2 user sends 2 concurrent requests to > http://localhost:8080/customer-portal > , it may happen that there > are 2 > SSO logins concurrently issued, however just 1 of them will > successfully > pass the code-to-token request (clientSession note will be overwritten > by the second request, so first request will fail in code-to-token > request due the different note value) > > 4. Refresh token is signed by same key like accessToken. This is not > ideal for: > - performance (RSA is an unecessary overhead. Symmetric > cryptography is > sufficient) > - Security: Refresh tokens and access tokens can be exchanged. Refresh > token is JWT visible by application and end user (not direct security > threat though) > > > Possible solution proposal: > > - Move some stuff from authenticatedClientSessionModel to the code > parameter and refreshToken itself. > > - Code will be encrypted JWT containing just clientSession notes. Not > the protocolMappers and roles > > - Refresh token will contain both roles and protocolMappers (roles are > here already. The protocolMappers will be new thing on refresh token) > > - Both code and refreshToken are AES-128 encrypted. Just the keycloak > server has the key and can decrypt them. > > - AuthenticatedClientSessionModel won't contain protocolMappers and > roles anymore > > - Use single-use cache to track whether the particular value of code > parameter was already used. > > > I've tried the code to be signed instead of encrypted, but it may have > security implications (code would be visible by adapters and > end-user). > The roles and protocolMappers are not needed in code and keeping them > would make the code unecessary big (URL limit is 2000 characters). > > I've tried to add more details into the Google document: > https://docs.google.com/document/d/1C1vFhyGPBOnN3pprw6XPZnK08azyTm-HVIqO9dY3aTY/edit?usp=sharing > > . Feel free to reply in the document or here in the email. > > Marek > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > From glavoie at gmail.com Wed Sep 13 11:45:01 2017 From: glavoie at gmail.com (Gabriel Lavoie) Date: Wed, 13 Sep 2017 11:45:01 -0400 Subject: [keycloak-dev] direct exchanges In-Reply-To: References: Message-ID: Hi Bill, That's definitely something I would like to see appear in Keycloak. Over the years we've had multiple use cases of system to system communication, but authenticated "as" the target user to simplify handling the security on the target endpoints. May happen when you integrate with a 3rd party partner, but want to make the integration seamless to the end-user, as if the 3rd party system was part of your own. Retrieved token may either be used by your own backend, or sent to the user's browser for direct API call on the 3rd party. With those type of integration, your own backend fully trust the 3rd party backend and the other way around, at least for some type or operations or with some restrictions to the endpoints that may be used for integration. The way you describe this seems like a very reasonable approach. I like the use of the /token endpoint with a different grant type, rather than creating a custom endpoint for that purpose. One Login offers such functionality, but using custom API. We also have other partners offering this, but again through custom APIs. We are currently using client credentials authentication for external systems talking to us. We have the client representing our application (Bearer Only) and we create different clients for different external systems so they can authenticate using Client Credentials (system account). When they hit our REST endpoints with the obtained token, we know exactly what external system hit which endpoint and the correct roles are assigned for the operation. With a similar setup, an external system would be able to obtain a token as a realm user instead, to allow its use to hit our REST endpoint. we should be able to know from the token itself which client was used to obtain the token, which user is being impersonated and what are the roles he has access to for the bearer only client. I think your point a) and b) cover that. Regarding stolen client credentials, this is always a concern. We've implemented tooling to allow easy reset of them if we believe it has been stolen. Not worse than using x509 certificates to authenticate an external system and having the private key stolen. Gabriel 2017-09-13 10:52 GMT-04:00 Bill Burke : > We have direct grants where client passes username and creds to obtain > a token for that user. We have client credentials grant to get a > token for the client itself. > > What if we had a direct exchange where the client provides user id or > username and gets a token for that user? The client does not have to > provide user credentials. > > What is the use case for this? Consider an application that is > authenticated via an external mechanism. Consider that this external > mechanism does not provide any type of token, it just authenticates a > username. This application needs to talk to services secured by > Keycloak. So, with this new direct exchange mechanism, the > application only needs to have a client account on the Keycloak server > to obtain a token for a keycloak user. Another benefit of this is > that Keycloak does not need to understand external token formats in > order to provide a token to a client that authenticates users by an > external mechanism. > > There's some big security risks for this. If the client's secret is > stolen the attacker would be able to mint token for any user. This > is somewhat mitigated in two ways: > > a) If the token is minted for the client, the scope of the token can > be limited, i.e. role mappings limited > > b) if the client is asking for a different audience (a different > client) the client can be limited on the audience it can ask for. (we > already do this check for client to client token exchange). > > > > -- > Bill Burke > Red Hat > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > -- Gabriel Lavoie glavoie at gmail.com From sthorger at redhat.com Thu Sep 14 00:51:13 2017 From: sthorger at redhat.com (Stian Thorgersen) Date: Thu, 14 Sep 2017 06:51:13 +0200 Subject: [keycloak-dev] Proposal: Update Dockerfiles to use jboss-cli In-Reply-To: <264526a2-f0ec-d46d-7d42-7b2fb2bbcb76@akvo.org> References: <264526a2-f0ec-d46d-7d42-7b2fb2bbcb76@akvo.org> Message-ID: Absolutely :) On 13 September 2017 at 12:53, Iv?n Perdomo wrote: > > Hi all, > > Thanks to Rub?n [1] we have successfully changed our customization to > Keycloak Docker images using jboss-cli and embed-server, instead of XSLT > transformations. > > In the past Stian has suggested that the XSLT was done before > embed-server was available [2]. > > We would like to contribute some of this changes to the base images. Can > we log an issue and send a pull request? > > The proposed changes will be just to remove xlst transformations with > jboss-cli commands. > > > [1] https://github.com/baztan106483 > [2] > https://lists.jboss.org/pipermail/keycloak-user/2016-February/005120.html > > Thanks, > > -- > Iv?n > _______________________________________________ > 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 Sep 14 03:04:25 2017 From: Sebastian.Schuster at bosch-si.com (Schuster Sebastian (INST/ESY1)) Date: Thu, 14 Sep 2017 07:04:25 +0000 Subject: [keycloak-dev] direct exchanges In-Reply-To: References: Message-ID: <70c731c5f0e14e8ab36f11cff1fe940b@FE-MBX1028.de.bosch.com> While I do understand the reasons for introducing this feature. I am not convinced a custom grant is the best way to do it. Wouldn't it be better to expect that any external mechanism has some way of proving a user has been authenticated and only being able to get an access token in exchange for that proof (e.g. ID Token, Assertion, whatever). That's more in line with the current standardization efforts on token exchange... Best regards, Sebastian Mit freundlichen Gr??en / Best regards Dr.-Ing. Sebastian Schuster Engineering and Support (INST/ESY1) Bosch?Software Innovations?GmbH | Sch?neberger Ufer 89-91 | 10785 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.-Ing. Rainer Kallenbach, 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, 13. September 2017 16:52 To: keycloak-dev Subject: [keycloak-dev] direct exchanges We have direct grants where client passes username and creds to obtain a token for that user. We have client credentials grant to get a token for the client itself. What if we had a direct exchange where the client provides user id or username and gets a token for that user? The client does not have to provide user credentials. What is the use case for this? Consider an application that is authenticated via an external mechanism. Consider that this external mechanism does not provide any type of token, it just authenticates a username. This application needs to talk to services secured by Keycloak. So, with this new direct exchange mechanism, the application only needs to have a client account on the Keycloak server to obtain a token for a keycloak user. Another benefit of this is that Keycloak does not need to understand external token formats in order to provide a token to a client that authenticates users by an external mechanism. There's some big security risks for this. If the client's secret is stolen the attacker would be able to mint token for any user. This is somewhat mitigated in two ways: a) If the token is minted for the client, the scope of the token can be limited, i.e. role mappings limited b) if the client is asking for a different audience (a different client) the client can be limited on the audience it can ask for. (we already do this check for client to client token exchange). -- Bill Burke Red Hat _______________________________________________ keycloak-dev mailing list keycloak-dev at lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-dev From mstrukel at redhat.com Thu Sep 14 04:17:03 2017 From: mstrukel at redhat.com (Marko Strukelj) Date: Thu, 14 Sep 2017 10:17:03 +0200 Subject: [keycloak-dev] master build failing on Tomcat 6 In-Reply-To: References: Message-ID: I got this as well. The problem is with org.wildfly:wildfly-undertow test dependency which pulls in io.undertow.jastow:jastow that contains Tomcat util classes. Hopefully we don't make use of any undertow facility dependent on jastow thus the fix would be to simply exclude the dependency. Testing the following as a fix: Index: pom.xml IDEA additional info: Subsystem: com.intellij.openapi.diff.impl.patch.CharsetEP <+>UTF-8 =================================================================== --- pom.xml (date 1505336045000) +++ pom.xml (revision ) @@ -591,6 +591,12 @@ wildfly-undertow ${wildfly.version} test + + + io.undertow.jastow + jastow + + org.wildfly.core On Tue, Sep 12, 2017 at 9:54 PM, Stian Thorgersen wrote: > I'm seeing this as well. Anyone sign up to getting this fixed? > > On 7 September 2017 at 17:34, Bill Burke wrote: > > > Tomcat 6 test is failing on my box. I pulled fresh copy of master and > > removed org/keycloak from .m2. So I don't think its anything local on > > my machine: > > > > java.lang.NoSuchMethodError: > > org.apache.tomcat.util.descriptor.DigesterFactory. > > newDigester(ZZLorg/apache/tomcat/util/digester/RuleSet; > > Z)Lorg/apache/tomcat/util/digester/Digester; > > > > at org.apache.catalina.startup.ContextConfig.createWebXmlDigester( > > ContextConfig.java:527) > > > > at org.apache.catalina.startup.ContextConfig.init( > ContextConfig.java:1015) > > > > at org.apache.catalina.startup.ContextConfig.lifecycleEvent( > > ContextConfig.java:276) > > > > at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent( > > LifecycleSupport.java:142) > > > > at org.apache.catalina.core.StandardContext.init( > > StandardContext.java:5703) > > > > at org.apache.catalina.core.StandardContext.start( > > StandardContext.java:4453) > > > > at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1057) > > > > at org.apache.catalina.core.StandardHost.start(StandardHost.java:822) > > > > at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1057) > > > > at org.apache.catalina.core.StandardEngine.start( > StandardEngine.java:463) > > > > at org.apache.catalina.startup.Embedded.start(Embedded.java:825) > > > > at org.keycloak.testsuite.TomcatServer.start(TomcatServer.java:122) > > > > at org.keycloak.testsuite.TomcatTest.initTomcat(TomcatTest.java:66) > > > > > > > > > > -- > > Bill Burke > > Red Hat > > _______________________________________________ > > 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 theodore.bohnen at rmb.co.za Thu Sep 14 05:05:25 2017 From: theodore.bohnen at rmb.co.za (Bohnen, Theodore) Date: Thu, 14 Sep 2017 09:05:25 +0000 Subject: [keycloak-dev] Open Authenticator in Mobile App Message-ID: <1505379925923.76428@rmb.co.za> Hi all Feature request: Currently when you use the otp feature, on signup it shows the qr code (derived from a uri generated based on https://github.com/google/google-authenticator/wiki/Key-Uri-Format), and it shows the encoded private key that you can copy and paste to google authenticator. The issues we've experienced is thatkeycloak allows you to choose your otp algorithm, i.e. SHA256, whilst google authenticator uses SHA1. When you scan the qr code it works well, given it adds the algorithm to the uri, and it gets added to google authenticator correctly. The problem is that if you are accessing this via a mobile phone, you cannot scan the qr code and you have to copy the code to google authenticator, which is clunky and doesn't work for certain scenarios. When you do this, you have no way (that I can see) to set which algorithm to use in google authenticator, it just assumes SHA1 and if the algorithm in keycloak is set to any other algorithm, it is added to google authenticator but keycloak says code is invalid. Regardless of the algorithm issue, this is also not a great user experience for a mobile user. The proposed solution is to check if the browser is running on a mobile device, and if so, have an html button that opens the same link that is embedded in the qr code. I'm happy to do a PR for this. Looking forward to your feedback. Theo This e-mail is subject to a disclaimer, available at http://www.rmb.co.za/web/elements.nsf/online/disclaimer-communications.html From ivan at akvo.org Thu Sep 14 06:49:43 2017 From: ivan at akvo.org (=?UTF-8?Q?Iv=c3=a1n_Perdomo?=) Date: Thu, 14 Sep 2017 12:49:43 +0200 Subject: [keycloak-dev] Proposal: Update Dockerfiles to use jboss-cli In-Reply-To: References: <264526a2-f0ec-d46d-7d42-7b2fb2bbcb76@akvo.org> Message-ID: <03cac198-8455-a418-61c7-7ffcb30bb57e@akvo.org> https://issues.jboss.org/browse/KEYCLOAK-5482 We're working on it. On 09/14/2017 06:51 AM, Stian Thorgersen wrote: > Absolutely :) > > On 13 September 2017 at 12:53, Iv?n Perdomo > wrote: > > > Hi all, > > Thanks to Rub?n [1] we have successfully changed our customization to > Keycloak Docker images using jboss-cli and embed-server, instead of XSLT > transformations. > > In the past Stian has suggested that the XSLT was done before > embed-server was available [2]. > > We would like to contribute some of this changes to the base images. Can > we log an issue and send a pull request? > > The proposed changes will be just to remove xlst transformations with > jboss-cli commands. > > > [1] https://github.com/baztan106483 > [2] > https://lists.jboss.org/pipermail/keycloak-user/2016-February/005120.html > > > Thanks, > > -- > Iv?n > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > -- Iv?n From bburke at redhat.com Thu Sep 14 10:56:11 2017 From: bburke at redhat.com (Bill Burke) Date: Thu, 14 Sep 2017 10:56:11 -0400 Subject: [keycloak-dev] direct exchanges In-Reply-To: <70c731c5f0e14e8ab36f11cff1fe940b@FE-MBX1028.de.bosch.com> References: <70c731c5f0e14e8ab36f11cff1fe940b@FE-MBX1028.de.bosch.com> Message-ID: I 100% agree that direct/custom grant is not the best way to do it. The question is, is it something we should provide as an *additional* exchange feature? I think yes. The way I plan to secure it is as follows: * client must be confidential and be secured by a secret or some other mechanism configured for that client * client must have permission to exchange tokens for target client * client must have permission to impersonate users * user must be impersonateable. On Thu, Sep 14, 2017 at 3:04 AM, Schuster Sebastian (INST/ESY1) wrote: > While I do understand the reasons for introducing this feature. I am not convinced a custom grant is the best way to do it. Wouldn't it be better to expect that any external mechanism has some way of proving a user has been authenticated and only being able to get an access token in exchange for that proof (e.g. ID Token, Assertion, whatever). That's more in line with the current standardization efforts on token exchange... > > Best regards, > Sebastian > > Mit freundlichen Gr??en / Best regards > > Dr.-Ing. Sebastian Schuster > > Engineering and Support (INST/ESY1) > Bosch Software Innovations GmbH | Sch?neberger Ufer 89-91 | 10785 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.-Ing. Rainer Kallenbach, 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, 13. September 2017 16:52 > To: keycloak-dev > Subject: [keycloak-dev] direct exchanges > > We have direct grants where client passes username and creds to obtain a token for that user. We have client credentials grant to get a token for the client itself. > > What if we had a direct exchange where the client provides user id or username and gets a token for that user? The client does not have to provide user credentials. > > What is the use case for this? Consider an application that is authenticated via an external mechanism. Consider that this external mechanism does not provide any type of token, it just authenticates a username. This application needs to talk to services secured by Keycloak. So, with this new direct exchange mechanism, the application only needs to have a client account on the Keycloak server > to obtain a token for a keycloak user. Another benefit of this is > that Keycloak does not need to understand external token formats in order to provide a token to a client that authenticates users by an external mechanism. > > There's some big security risks for this. If the client's secret is > stolen the attacker would be able to mint token for any user. This > is somewhat mitigated in two ways: > > a) If the token is minted for the client, the scope of the token can be limited, i.e. role mappings limited > > b) if the client is asking for a different audience (a different > client) the client can be limited on the audience it can ask for. (we already do this check for client to client token exchange). > > > > -- > Bill Burke > Red Hat > _______________________________________________ > 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 -- Bill Burke Red Hat From bburke at redhat.com Thu Sep 14 11:03:19 2017 From: bburke at redhat.com (Bill Burke) Date: Thu, 14 Sep 2017 11:03:19 -0400 Subject: [keycloak-dev] Proposal: Update Dockerfiles to use jboss-cli In-Reply-To: References: <264526a2-f0ec-d46d-7d42-7b2fb2bbcb76@akvo.org> Message-ID: Just a thought, just brainstorming... Maybe all environment variables should be ditched and only jboss-cli should be supported? Users extend the Keycloak image, hardcode the things they want to hardcode via jboss-cli, introduce their own environment variables as parameters to CLI as they see fit. Just seems like a much better option than having to duplicate and document pre-defined environment variables. On Thu, Sep 14, 2017 at 12:51 AM, Stian Thorgersen wrote: > Absolutely :) > > On 13 September 2017 at 12:53, Iv?n Perdomo wrote: > >> >> Hi all, >> >> Thanks to Rub?n [1] we have successfully changed our customization to >> Keycloak Docker images using jboss-cli and embed-server, instead of XSLT >> transformations. >> >> In the past Stian has suggested that the XSLT was done before >> embed-server was available [2]. >> >> We would like to contribute some of this changes to the base images. Can >> we log an issue and send a pull request? >> >> The proposed changes will be just to remove xlst transformations with >> jboss-cli commands. >> >> >> [1] https://github.com/baztan106483 >> [2] >> https://lists.jboss.org/pipermail/keycloak-user/2016-February/005120.html >> >> Thanks, >> >> -- >> Iv?n >> _______________________________________________ >> 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 -- Bill Burke Red Hat From mstrukel at redhat.com Thu Sep 14 12:28:53 2017 From: mstrukel at redhat.com (Marko Strukelj) Date: Thu, 14 Sep 2017 18:28:53 +0200 Subject: [keycloak-dev] Policy around migration-*.cli scripts Message-ID: I was wondering why migration-*.cli scripts contain migrations for keycloak-server subsystem. It makes perfect sense that they are used to adjust configuration of other wildfly subsystems that we don't control. But for keycloak-server I imagine all migration should be performed at runtime by keycloak-server subsystem itself. This way migration is easier to do, it involves fewer modules in our build, fewer files (no /subsystem=keycloak-server entries in migration-*.cli files), and it's testable in a single module. Any reason why not do it that way? Another thing - currently our (de facto) versioning policy for keycloak subsystems is to not increment the version as long as the old syntax/model keeps working, even if we introduce new xml syntax we keep the old version number. In practice that means that if I see an example of subsystem configuration somewhere, and I copy it to the older version of Keycloak (why not, it says it's still version 1.1) that would not work if it contains any later syntax that older version doesn't understand. Older keycloak-server configuration can be copied to newer version of Keycloak without issues. That's simple for us to maintain, and seems to work well enough. Technically we'll only have to increment version if we decide to break backwards compatibility of the configuration - nowhere on our radar ATM. Does anyone see this policy as problematic? - marko From cedric.couralet at gmail.com Fri Sep 15 02:36:09 2017 From: cedric.couralet at gmail.com (=?UTF-8?Q?C=C3=A9dric_Couralet?=) Date: Fri, 15 Sep 2017 08:36:09 +0200 Subject: [keycloak-dev] [KEYCLOAK-4052] implementation Message-ID: Hi, This place is surely better than a comment in JIRA. I really need this issue to be resolved. I tried a fistr patch quickly, which was rejected[1], but is it possible to verify the credential type befoer the password policy check in UserCredentialStoreManager.java or is it the wrong direction? [1]: https://github.com/keycloak/keycloak/pull/4364/files Regards, -- C?dric Couralet From sthorger at redhat.com Fri Sep 15 03:11:03 2017 From: sthorger at redhat.com (Stian Thorgersen) Date: Fri, 15 Sep 2017 09:11:03 +0200 Subject: [keycloak-dev] [KEYCLOAK-4052] implementation In-Reply-To: References: Message-ID: * There needs to be a config option whether or not the password policy should be considered or not * Before trying the password policy you need to check if the credential being update is indeed a password and not a different type * Tests need to be added (update password success, update password rejected due to policy, with/without config password policy check on, updating different types of credentials doesn't break, etc.) On 15 September 2017 at 08:36, C?dric Couralet wrote: > Hi, > > This place is surely better than a comment in JIRA. I really need this > issue to be resolved. I tried a fistr patch quickly, which was > rejected[1], but is it possible to verify the credential type befoer > the password policy check in UserCredentialStoreManager.java or is it > the wrong direction? > > [1]: https://github.com/keycloak/keycloak/pull/4364/files > > > Regards, > > -- > > C?dric Couralet > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev From sthorger at redhat.com Fri Sep 15 03:21:24 2017 From: sthorger at redhat.com (Stian Thorgersen) Date: Fri, 15 Sep 2017 09:21:24 +0200 Subject: [keycloak-dev] master build failing on Tomcat 6 In-Reply-To: References: Message-ID: Awesome Marko, Thanks for sorting this out. I've added a new PR here https://github.com/keycloak/keycloak/pull/4478 with your fix and also adding tomcat6 to what Travis tests so this doesn't happen again. On 14 September 2017 at 10:17, Marko Strukelj wrote: > I got this as well. > > The problem is with org.wildfly:wildfly-undertow test dependency which > pulls in io.undertow.jastow:jastow that contains Tomcat util classes. > > Hopefully we don't make use of any undertow facility dependent on jastow > thus the fix would be to simply exclude the dependency. > > Testing the following as a fix: > > Index: pom.xml > IDEA additional info: > Subsystem: com.intellij.openapi.diff.impl.patch.CharsetEP > <+>UTF-8 > =================================================================== > --- pom.xml (date 1505336045000) > +++ pom.xml (revision ) > @@ -591,6 +591,12 @@ > wildfly-undertow > ${wildfly.version} > test > + > + > + io.undertow.jastow > + jastow > + > + > > > org.wildfly.core > > > On Tue, Sep 12, 2017 at 9:54 PM, Stian Thorgersen > wrote: > >> I'm seeing this as well. Anyone sign up to getting this fixed? >> >> On 7 September 2017 at 17:34, Bill Burke wrote: >> >> > Tomcat 6 test is failing on my box. I pulled fresh copy of master and >> > removed org/keycloak from .m2. So I don't think its anything local on >> > my machine: >> > >> > java.lang.NoSuchMethodError: >> > org.apache.tomcat.util.descriptor.DigesterFactory. >> > newDigester(ZZLorg/apache/tomcat/util/digester/RuleSet; >> > Z)Lorg/apache/tomcat/util/digester/Digester; >> > >> > at org.apache.catalina.startup.ContextConfig.createWebXmlDigester( >> > ContextConfig.java:527) >> > >> > at org.apache.catalina.startup.ContextConfig.init(ContextConfig >> .java:1015) >> > >> > at org.apache.catalina.startup.ContextConfig.lifecycleEvent( >> > ContextConfig.java:276) >> > >> > at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent( >> > LifecycleSupport.java:142) >> > >> > at org.apache.catalina.core.StandardContext.init( >> > StandardContext.java:5703) >> > >> > at org.apache.catalina.core.StandardContext.start( >> > StandardContext.java:4453) >> > >> > at org.apache.catalina.core.ContainerBase.start(ContainerBase. >> java:1057) >> > >> > at org.apache.catalina.core.StandardHost.start(StandardHost.java:822) >> > >> > at org.apache.catalina.core.ContainerBase.start(ContainerBase. >> java:1057) >> > >> > at org.apache.catalina.core.StandardEngine.start(StandardEngine >> .java:463) >> > >> > at org.apache.catalina.startup.Embedded.start(Embedded.java:825) >> > >> > at org.keycloak.testsuite.TomcatServer.start(TomcatServer.java:122) >> > >> > at org.keycloak.testsuite.TomcatTest.initTomcat(TomcatTest.java:66) >> > >> > >> > >> > >> > -- >> > Bill Burke >> > Red Hat >> > _______________________________________________ >> > 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 Sep 15 03:26:38 2017 From: sthorger at redhat.com (Stian Thorgersen) Date: Fri, 15 Sep 2017 09:26:38 +0200 Subject: [keycloak-dev] direct exchanges In-Reply-To: References: <70c731c5f0e14e8ab36f11cff1fe940b@FE-MBX1028.de.bosch.com> Message-ID: I'm not quite following if you are planning this as part of the token exchange services or a new alternative direct grant flow? On 14 September 2017 at 16:56, Bill Burke wrote: > I 100% agree that direct/custom grant is not the best way to do it. > The question is, is it something we should provide as an *additional* > exchange feature? I think yes. The way I plan to secure it is as > follows: > > * client must be confidential and be secured by a secret or some other > mechanism configured for that client > * client must have permission to exchange tokens for target client > * client must have permission to impersonate users > * user must be impersonateable. > > > On Thu, Sep 14, 2017 at 3:04 AM, Schuster Sebastian (INST/ESY1) > wrote: > > While I do understand the reasons for introducing this feature. I am not > convinced a custom grant is the best way to do it. Wouldn't it be better to > expect that any external mechanism has some way of proving a user has been > authenticated and only being able to get an access token in exchange for > that proof (e.g. ID Token, Assertion, whatever). That's more in line with > the current standardization efforts on token exchange... > > > > Best regards, > > Sebastian > > > > Mit freundlichen Gr??en / Best regards > > > > Dr.-Ing. Sebastian Schuster > > > > Engineering and Support (INST/ESY1) > > Bosch Software Innovations GmbH | Sch?neberger Ufer 89-91 | 10785 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.-Ing. Rainer Kallenbach, Michael Hahn > > > > > > > > > > -----Original Message----- > > From: keycloak-dev-bounces at lists.jboss.org [mailto:keycloak-dev-bounces@ > lists.jboss.org] On Behalf Of Bill Burke > > Sent: Mittwoch, 13. September 2017 16:52 > > To: keycloak-dev > > Subject: [keycloak-dev] direct exchanges > > > > We have direct grants where client passes username and creds to obtain a > token for that user. We have client credentials grant to get a token for > the client itself. > > > > What if we had a direct exchange where the client provides user id or > username and gets a token for that user? The client does not have to > provide user credentials. > > > > What is the use case for this? Consider an application that is > authenticated via an external mechanism. Consider that this external > mechanism does not provide any type of token, it just authenticates a > username. This application needs to talk to services secured by Keycloak. > So, with this new direct exchange mechanism, the application only needs to > have a client account on the Keycloak server > > to obtain a token for a keycloak user. Another benefit of this is > > that Keycloak does not need to understand external token formats in > order to provide a token to a client that authenticates users by an > external mechanism. > > > > There's some big security risks for this. If the client's secret is > > stolen the attacker would be able to mint token for any user. This > > is somewhat mitigated in two ways: > > > > a) If the token is minted for the client, the scope of the token can be > limited, i.e. role mappings limited > > > > b) if the client is asking for a different audience (a different > > client) the client can be limited on the audience it can ask for. (we > already do this check for client to client token exchange). > > > > > > > > -- > > Bill Burke > > Red Hat > > _______________________________________________ > > 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 > > > > -- > Bill Burke > Red Hat > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > From martin.hardselius at gmail.com Fri Sep 15 03:40:33 2017 From: martin.hardselius at gmail.com (Martin Hardselius) Date: Fri, 15 Sep 2017 07:40:33 +0000 Subject: [keycloak-dev] Token introspection error for pairwise access token Message-ID: It seems like token introspection for pairwise tokens report access tokens with a pairwise sub as inactive when they're actually active. User lookup is using the sub instead of the session. It's a quick fix. Should I JIRA it and submit a PR? Martin From mposolda at redhat.com Fri Sep 15 04:03:06 2017 From: mposolda at redhat.com (Marek Posolda) Date: Fri, 15 Sep 2017 10:03:06 +0200 Subject: [keycloak-dev] Token introspection error for pairwise access token In-Reply-To: References: Message-ID: +1 for JIRA and PR :) Thanks! Marek On 15/09/17 09:40, Martin Hardselius wrote: > It seems like token introspection for pairwise tokens report access tokens > with a pairwise sub as inactive when they're actually active. User lookup > is using the sub instead of the session. It's a quick fix. Should I JIRA it > and submit a PR? > > 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 Sep 15 04:06:34 2017 From: mposolda at redhat.com (Marek Posolda) Date: Fri, 15 Sep 2017 10:06:34 +0200 Subject: [keycloak-dev] [KEYCLOAK-4052] implementation In-Reply-To: References: Message-ID: +1 for the config option. Maybe should be disabled by default for backwards compatibility? Will be cool if also implementors of custom UserStorage have an easy way to specify whether they want to use Keycloak password policies or not (maybe it's available already, I am not 100 % sure). Marek On 15/09/17 09:11, Stian Thorgersen wrote: > * There needs to be a config option whether or not the password policy > should be considered or not > * Before trying the password policy you need to check if the credential > being update is indeed a password and not a different type > * Tests need to be added (update password success, update password rejected > due to policy, with/without config password policy check on, updating > different types of credentials doesn't break, etc.) > > On 15 September 2017 at 08:36, C?dric Couralet > wrote: > >> Hi, >> >> This place is surely better than a comment in JIRA. I really need this >> issue to be resolved. I tried a fistr patch quickly, which was >> rejected[1], but is it possible to verify the credential type befoer >> the password policy check in UserCredentialStoreManager.java or is it >> the wrong direction? >> >> [1]: https://github.com/keycloak/keycloak/pull/4364/files >> >> >> Regards, >> >> -- >> >> C?dric Couralet >> >> _______________________________________________ >> 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 cedric.couralet at gmail.com Fri Sep 15 04:18:50 2017 From: cedric.couralet at gmail.com (=?UTF-8?Q?C=C3=A9dric_Couralet?=) Date: Fri, 15 Sep 2017 10:18:50 +0200 Subject: [keycloak-dev] [KEYCLOAK-4052] implementation In-Reply-To: References: Message-ID: thank you. What I'm thinking now is : - adding a method in CredentialInputUpdater (veryPasswordPolicy boolean) - using this in updateCredential in UserCredentialStoreManager to check or not the password policy - adding an option in all existing providers provided by default. This would allow custom providers to use or not the Password Policy. What do you think? I'm not sure changing the interface can be done like that, is there some rules to follow? 2017-09-15 10:06 GMT+02:00 Marek Posolda : > +1 for the config option. Maybe should be disabled by default for backwards > compatibility? > > Will be cool if also implementors of custom UserStorage have an easy way to > specify whether they want to use Keycloak password policies or not (maybe > it's available already, I am not 100 % sure). > > Marek > > > On 15/09/17 09:11, Stian Thorgersen wrote: >> >> * There needs to be a config option whether or not the password policy >> should be considered or not >> * Before trying the password policy you need to check if the credential >> being update is indeed a password and not a different type >> * Tests need to be added (update password success, update password >> rejected >> due to policy, with/without config password policy check on, updating >> different types of credentials doesn't break, etc.) >> >> On 15 September 2017 at 08:36, C?dric Couralet >> wrote: >> >>> Hi, >>> >>> This place is surely better than a comment in JIRA. I really need this >>> issue to be resolved. I tried a fistr patch quickly, which was >>> rejected[1], but is it possible to verify the credential type befoer >>> the password policy check in UserCredentialStoreManager.java or is it >>> the wrong direction? >>> >>> [1]: https://github.com/keycloak/keycloak/pull/4364/files >>> >>> >>> Regards, >>> >>> -- >>> >>> C?dric Couralet >>> >>> _______________________________________________ >>> 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 ivan at akvo.org Fri Sep 15 04:49:24 2017 From: ivan at akvo.org (=?UTF-8?Q?Iv=c3=a1n_Perdomo?=) Date: Fri, 15 Sep 2017 10:49:24 +0200 Subject: [keycloak-dev] Proposal: Update Dockerfiles to use jboss-cli In-Reply-To: References: <264526a2-f0ec-d46d-7d42-7b2fb2bbcb76@akvo.org> Message-ID: Hi, There are not that many environment variables, basically Keycloak and Maven version, plus LAUNCH_JBOSS_IN_BACKGROUND for 'graceful shutdown'. The only i one i see that actually modifies behavior is the PROXY_ADDRESS_FORWARDING when the service is behind a reverse proxy. $ grep -rn ENV . ./server/Dockerfile:3:ENV KEYCLOAK_VERSION 3.3.0.CR2 ./server/Dockerfile:6:ENV LAUNCH_JBOSS_IN_BACKGROUND 1 ./server/Dockerfile:7:ENV PROXY_ADDRESS_FORWARDING false ./server/Dockerfile:21:ENV JBOSS_HOME /opt/jboss/keycloak ./server-postgres/Dockerfile:3:ENV POSTGRES_JDBC_VERSION 42.1.4 ./proxy/Dockerfile:3:ENV KEYCLOAK_VERSION 3.2.0.Final ./examples/Dockerfile:3:ENV KEYCLOAK_VERSION 3.3.0.CR2 ./examples/Dockerfile:4:ENV JBOSS_HOME /opt/jboss/keycloak-demo/keycloak ./examples/Dockerfile:5:ENV MAVEN_VERSION 3.3.9 ./examples/Dockerfile:8:ENV LAUNCH_JBOSS_IN_BACKGROUND 1 ./examples/Dockerfile:16:ENV MAVEN_HOME /usr/share/maven ./adapter-wildfly/Dockerfile:3:ENV KEYCLOAK_VERSION 3.3.0.CR2 Cheers, On 09/14/2017 05:03 PM, Bill Burke wrote: > Just a thought, just brainstorming... > > Maybe all environment variables should be ditched and only jboss-cli > should be supported? Users extend the Keycloak image, hardcode the > things they want to hardcode via jboss-cli, introduce their own > environment variables as parameters to CLI as they see fit. Just > seems like a much better option than having to duplicate and document > pre-defined environment variables. > > On Thu, Sep 14, 2017 at 12:51 AM, Stian Thorgersen wrote: >> Absolutely :) >> >> On 13 September 2017 at 12:53, Iv?n Perdomo wrote: >> >>> >>> Hi all, >>> >>> Thanks to Rub?n [1] we have successfully changed our customization to >>> Keycloak Docker images using jboss-cli and embed-server, instead of XSLT >>> transformations. >>> >>> In the past Stian has suggested that the XSLT was done before >>> embed-server was available [2]. >>> >>> We would like to contribute some of this changes to the base images. Can >>> we log an issue and send a pull request? >>> >>> The proposed changes will be just to remove xlst transformations with >>> jboss-cli commands. >>> >>> >>> [1] https://github.com/baztan106483 >>> [2] >>> https://lists.jboss.org/pipermail/keycloak-user/2016-February/005120.html >>> >>> Thanks, >>> >>> -- >>> Iv?n >>> _______________________________________________ >>> 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 > > > -- Iv?n From sthorger at redhat.com Fri Sep 15 05:25:33 2017 From: sthorger at redhat.com (Stian Thorgersen) Date: Fri, 15 Sep 2017 11:25:33 +0200 Subject: [keycloak-dev] [KEYCLOAK-4052] implementation In-Reply-To: References: Message-ID: This particular SPI is fully supported so we can't break backwards compatiblity. Would have to be an option interface if done this way. Alternatively, which may be better is to just let user storage providers deal with it themselves. The built-in LDAP provider could have an option, then other custom implementations can just do what they want (enable always, configurable, disable always, etc..). On 15 September 2017 at 10:18, C?dric Couralet wrote: > thank you. > > What I'm thinking now is : > - adding a method in CredentialInputUpdater (veryPasswordPolicy boolean) > - using this in updateCredential in UserCredentialStoreManager to > check or not the password policy > - adding an option in all existing providers provided by default. > > This would allow custom providers to use or not the Password Policy. > > What do you think? > I'm not sure changing the interface can be done like that, is there > some rules to follow? > > > 2017-09-15 10:06 GMT+02:00 Marek Posolda : > > +1 for the config option. Maybe should be disabled by default for > backwards > > compatibility? > > > > Will be cool if also implementors of custom UserStorage have an easy way > to > > specify whether they want to use Keycloak password policies or not (maybe > > it's available already, I am not 100 % sure). > > > > Marek > > > > > > On 15/09/17 09:11, Stian Thorgersen wrote: > >> > >> * There needs to be a config option whether or not the password policy > >> should be considered or not > >> * Before trying the password policy you need to check if the credential > >> being update is indeed a password and not a different type > >> * Tests need to be added (update password success, update password > >> rejected > >> due to policy, with/without config password policy check on, updating > >> different types of credentials doesn't break, etc.) > >> > >> On 15 September 2017 at 08:36, C?dric Couralet < > cedric.couralet at gmail.com> > >> wrote: > >> > >>> Hi, > >>> > >>> This place is surely better than a comment in JIRA. I really need this > >>> issue to be resolved. I tried a fistr patch quickly, which was > >>> rejected[1], but is it possible to verify the credential type befoer > >>> the password policy check in UserCredentialStoreManager.java or is it > >>> the wrong direction? > >>> > >>> [1]: https://github.com/keycloak/keycloak/pull/4364/files > >>> > >>> > >>> Regards, > >>> > >>> -- > >>> > >>> C?dric Couralet > >>> > >>> _______________________________________________ > >>> 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 Sep 15 05:26:36 2017 From: sthorger at redhat.com (Stian Thorgersen) Date: Fri, 15 Sep 2017 11:26:36 +0200 Subject: [keycloak-dev] Policy around migration-*.cli scripts In-Reply-To: References: Message-ID: Stan knows this stuff better than anyone, but I seem to remember there was some good reasons for this. On 14 September 2017 at 18:28, Marko Strukelj wrote: > I was wondering why migration-*.cli scripts contain migrations for > keycloak-server subsystem. > > It makes perfect sense that they are used to adjust configuration of other > wildfly subsystems that we don't control. But for keycloak-server I imagine > all migration should be performed at runtime by keycloak-server subsystem > itself. This way migration is easier to do, it involves fewer modules in > our build, fewer files (no /subsystem=keycloak-server entries in > migration-*.cli files), and it's testable in a single module. > > Any reason why not do it that way? > > Another thing - currently our (de facto) versioning policy for keycloak > subsystems is to not increment the version as long as the old syntax/model > keeps working, even if we introduce new xml syntax we keep the old version > number. > > In practice that means that if I see an example of subsystem configuration > somewhere, and I copy it to the older version of Keycloak (why not, it says > it's still version 1.1) that would not work if it contains any later syntax > that older version doesn't understand. Older keycloak-server configuration > can be copied to newer version of Keycloak without issues. > > That's simple for us to maintain, and seems to work well enough. > Technically we'll only have to increment version if we decide to break > backwards compatibility of the configuration - nowhere on our radar ATM. > > Does anyone see this policy as problematic? > > - marko > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > From ssilvert at redhat.com Sat Sep 16 18:08:04 2017 From: ssilvert at redhat.com (Stan Silvert) Date: Sat, 16 Sep 2017 18:08:04 -0400 Subject: [keycloak-dev] Policy around migration-*.cli scripts In-Reply-To: References: Message-ID: Marko and I spent a lot of time Friday chatting about it and trying a few things. If anyone wants the gory details I can post the text. We're not finished, but the summary is that we need to: 1) Make sure the migration test is running properly 2) Work with Tomaz Cerar to find out about his latest API improvements for subsystem versioning. 3) Decide if we should start using Tomaz's stuff in the future instead of or in addition to the migration scripts. A big question is how far back do we want to support migration? Right now the migration tool for standalone.xml goes back to 1.8. So we are supporting migration of standalone.xml for anything forward from that. Maybe we don't need to go back that far. I don't think we will ever get rid of the migration scripts entirely. We are (almost) required to use it for non-keycloak subsystems, so it kind of makes sense to have migration for our stuff in the same script. On 9/15/2017 5:26 AM, Stian Thorgersen wrote: > Stan knows this stuff better than anyone, but I seem to remember there was > some good reasons for this. > > On 14 September 2017 at 18:28, Marko Strukelj wrote: > >> I was wondering why migration-*.cli scripts contain migrations for >> keycloak-server subsystem. >> >> It makes perfect sense that they are used to adjust configuration of other >> wildfly subsystems that we don't control. But for keycloak-server I imagine >> all migration should be performed at runtime by keycloak-server subsystem >> itself. This way migration is easier to do, it involves fewer modules in >> our build, fewer files (no /subsystem=keycloak-server entries in >> migration-*.cli files), and it's testable in a single module. >> >> Any reason why not do it that way? >> >> Another thing - currently our (de facto) versioning policy for keycloak >> subsystems is to not increment the version as long as the old syntax/model >> keeps working, even if we introduce new xml syntax we keep the old version >> number. >> >> In practice that means that if I see an example of subsystem configuration >> somewhere, and I copy it to the older version of Keycloak (why not, it says >> it's still version 1.1) that would not work if it contains any later syntax >> that older version doesn't understand. Older keycloak-server configuration >> can be copied to newer version of Keycloak without issues. >> >> That's simple for us to maintain, and seems to work well enough. >> Technically we'll only have to increment version if we decide to break >> backwards compatibility of the configuration - nowhere on our radar ATM. >> >> Does anyone see this policy as problematic? >> >> - marko >> _______________________________________________ >> 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 Sep 18 02:52:48 2017 From: mposolda at redhat.com (Marek Posolda) Date: Mon, 18 Sep 2017 08:52:48 +0200 Subject: [keycloak-dev] Policy around migration-*.cli scripts In-Reply-To: References: Message-ID: <7392c98b-58c1-6d54-cb7f-a98494c5a646@redhat.com> I have one thing partially related to this. There is a JIRA https://issues.jboss.org/browse/KEYCLOAK-5142 . You can see my last comment for details, but in shortcut: I've did some changes in the migration script, which work fine when they are executed in "offline" mode (which is what we describe in the documentation). However test doesn't pass as it tests the migration in "online" mode. IMO it will be good if the test tests the same steps, which is done by our customers. IMO even worse scenario is, if "online" mode works and test passes, but "offline" mode is broken. I wonder if the proposed changes will handle this. It looks to me, that they will? Marek On 17/09/17 00:08, Stan Silvert wrote: > Marko and I spent a lot of time Friday chatting about it and trying a > few things. If anyone wants the gory details I can post the text. > > We're not finished, but the summary is that we need to: > 1) Make sure the migration test is running properly > 2) Work with Tomaz Cerar to find out about his latest API improvements > for subsystem versioning. > 3) Decide if we should start using Tomaz's stuff in the future instead > of or in addition to the migration scripts. > > A big question is how far back do we want to support migration? Right > now the migration tool for standalone.xml goes back to 1.8. So we are > supporting migration of standalone.xml for anything forward from that. > Maybe we don't need to go back that far. > > I don't think we will ever get rid of the migration scripts entirely. > We are (almost) required to use it for non-keycloak subsystems, so it > kind of makes sense to have migration for our stuff in the same script. > > On 9/15/2017 5:26 AM, Stian Thorgersen wrote: >> Stan knows this stuff better than anyone, but I seem to remember there was >> some good reasons for this. >> >> On 14 September 2017 at 18:28, Marko Strukelj wrote: >> >>> I was wondering why migration-*.cli scripts contain migrations for >>> keycloak-server subsystem. >>> >>> It makes perfect sense that they are used to adjust configuration of other >>> wildfly subsystems that we don't control. But for keycloak-server I imagine >>> all migration should be performed at runtime by keycloak-server subsystem >>> itself. This way migration is easier to do, it involves fewer modules in >>> our build, fewer files (no /subsystem=keycloak-server entries in >>> migration-*.cli files), and it's testable in a single module. >>> >>> Any reason why not do it that way? >>> >>> Another thing - currently our (de facto) versioning policy for keycloak >>> subsystems is to not increment the version as long as the old syntax/model >>> keeps working, even if we introduce new xml syntax we keep the old version >>> number. >>> >>> In practice that means that if I see an example of subsystem configuration >>> somewhere, and I copy it to the older version of Keycloak (why not, it says >>> it's still version 1.1) that would not work if it contains any later syntax >>> that older version doesn't understand. Older keycloak-server configuration >>> can be copied to newer version of Keycloak without issues. >>> >>> That's simple for us to maintain, and seems to work well enough. >>> Technically we'll only have to increment version if we decide to break >>> backwards compatibility of the configuration - nowhere on our radar ATM. >>> >>> Does anyone see this policy as problematic? >>> >>> - marko >>> _______________________________________________ >>> 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 > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev From sthorger at redhat.com Mon Sep 18 09:28:32 2017 From: sthorger at redhat.com (Stian Thorgersen) Date: Mon, 18 Sep 2017 15:28:32 +0200 Subject: [keycloak-dev] Policy around migration-*.cli scripts In-Reply-To: References: Message-ID: On 17 September 2017 at 00:08, Stan Silvert wrote: > Marko and I spent a lot of time Friday chatting about it and trying a > few things. If anyone wants the gory details I can post the text. > > We're not finished, but the summary is that we need to: > 1) Make sure the migration test is running properly > 2) Work with Tomaz Cerar to find out about his latest API improvements > for subsystem versioning. > 3) Decide if we should start using Tomaz's stuff in the future instead > of or in addition to the migration scripts. > > A big question is how far back do we want to support migration? Right > now the migration tool for standalone.xml goes back to 1.8. So we are > supporting migration of standalone.xml for anything forward from that. > Maybe we don't need to go back that far. > No need to go back further than 1.9.8 (RH-SSO 7.0) > > I don't think we will ever get rid of the migration scripts entirely. > We are (almost) required to use it for non-keycloak subsystems, so it > kind of makes sense to have migration for our stuff in the same script. > Almost? If we could get rid of it completely would that not make migration simpler for users? > > On 9/15/2017 5:26 AM, Stian Thorgersen wrote: > > Stan knows this stuff better than anyone, but I seem to remember there > was > > some good reasons for this. > > > > On 14 September 2017 at 18:28, Marko Strukelj > wrote: > > > >> I was wondering why migration-*.cli scripts contain migrations for > >> keycloak-server subsystem. > >> > >> It makes perfect sense that they are used to adjust configuration of > other > >> wildfly subsystems that we don't control. But for keycloak-server I > imagine > >> all migration should be performed at runtime by keycloak-server > subsystem > >> itself. This way migration is easier to do, it involves fewer modules in > >> our build, fewer files (no /subsystem=keycloak-server entries in > >> migration-*.cli files), and it's testable in a single module. > >> > >> Any reason why not do it that way? > >> > >> Another thing - currently our (de facto) versioning policy for keycloak > >> subsystems is to not increment the version as long as the old > syntax/model > >> keeps working, even if we introduce new xml syntax we keep the old > version > >> number. > >> > >> In practice that means that if I see an example of subsystem > configuration > >> somewhere, and I copy it to the older version of Keycloak (why not, it > says > >> it's still version 1.1) that would not work if it contains any later > syntax > >> that older version doesn't understand. Older keycloak-server > configuration > >> can be copied to newer version of Keycloak without issues. > >> > >> That's simple for us to maintain, and seems to work well enough. > >> Technically we'll only have to increment version if we decide to break > >> backwards compatibility of the configuration - nowhere on our radar ATM. > >> > >> Does anyone see this policy as problematic? > >> > >> - marko > >> _______________________________________________ > >> 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 > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > From sthorger at redhat.com Mon Sep 18 09:58:34 2017 From: sthorger at redhat.com (Stian Thorgersen) Date: Mon, 18 Sep 2017 15:58:34 +0200 Subject: [keycloak-dev] Implementations for KEYCLOAK-2209 In-Reply-To: References: Message-ID: Reading your email I couldn't figure out how you assign a password policy to a user. I think it would be best if there's an ordered/prioritized list of password policies. Each policy would have a set of conditions on whether or not the policy should be applied to a specific user. Where conditions should include member/not-member of a specific group, has/doesn't have a specific role, a specific attribute key/value or if a user belongs to a specific user fed provider. If none matches the last in the list should be used. I find having more than one policy apply to a specific user just confusing so it should be the first policy that matches for a user that is used. Now with regards to implementation it would make sense to convert password policies to use component storage rather than add additional tables/attributes for password policies. The single string password policy was introduced before we had component storage and it is our plan to eventually convert password policies to use component storage. Component storage is much more flexible and powerful than what we have today for password policies. It allows the provider itself to expose what configuration applies to it. On 12 September 2017 at 19:59, Ricardo Martin Camarero wrote: > Hi team, > > I'm forwarding this email to the list following Stian's recommendation. > > I needed to learn more about keycloak (how to manage the maven project, > how to add a modification, how to test it, and so on and so forth), so I > decided to start looking the code and try to help when I have some free > time. As I filed an internal RFE because one customer wanted a similar > solution than the one specified in KEYCLOAK-2209 I started to implement > something. Now I have two possible ideas that are not completely > implemented (I haven't done any group use for example). Both ideas have > similarities: > > * I have extended the database to include a REALM_PASSWORD_POLICY_GROUP > table that contains more policies associated to the realm. I thought > about using an attribute but I decided to extend the database because > the current policy attribute is a long string (length 2550). This way in > the realm (policies page) now you can configure more than one password > policy (default is the current one and you can add new policies that are > saved in the new table with a name). > > * The user has a new attribute that contains the password policy, in > this case I have re-used an attribute (I'm not sure about this idea, now > I think using a new column would be better but I needed a multiple > attribute for option 2). > > * In both solutions I needed to extend the PasswordPolicyProvider > interface to pass the config to the two validate methods: > > PolicyError validate(RealmModel realm, UserModel user, String > password, Object config); > > I think there is a bug in this part in current master branch, because > regex policy is multiple, and you cannot assign two different regex > providers in the same policy (PasswordPolicy stores the configuration in > a Map, so you cannot have two different configurations > for the same type, if you assign two regex providers they are > transformed into one as soon as you save the policy). > > > Now the two implementations: > > 1) The first idea let us configure to a user one password policy. My > branch is this one: > > https://github.com/rmartinc/keycloak/tree/password-policy-groups > > In this solution the user has a combo (only one policy can be assigned > to a user) and only one policy is applied to that user. My idea was > extending the idea using groups and priorities. Password policies will > have a priority, and only one policy will apply to a user (from all the > possible policies the one with the higher priority applies). For the > moment I only modified keycloak to have a different policy in the user > (no priorities or group policies). > > 2) The second idea follows the description in 2209. The branch is the > following: > > https://github.com/rmartinc/keycloak/tree/password-policy-groups-multi > > Here the user can have multiple password policies. The definitive > policy is a merge between all the policies applied to the user. To do > this I needed to extend the PasswordPolicyProvider interface even more, > in order to have a compare method that returns which policy is more > restrictive. Extending this idea to groups is just merging more policies. > > > You can test my ideas (I think both of them are working). If you are > interested please let me know which idea you think is better (I'm not > completely sure, now I think that I prefer option 1, although option 2 > is more similar to the RFE description, I think the latter is very > confusing). If you like one of them, I'll try to finish the > implementation (now there are no tests and some decisions I took maybe > are wrong). If you think this is not needed or it's not the time to > implement this RFE don't worry, it's ok, I needed to play with keycloak, > and that part is done. > > Regards! > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev From sthorger at redhat.com Mon Sep 18 10:02:07 2017 From: sthorger at redhat.com (Stian Thorgersen) Date: Mon, 18 Sep 2017 16:02:07 +0200 Subject: [keycloak-dev] Promise wrapper for javascript adapter In-Reply-To: References: Message-ID: I don't like the idea of having a wrapper as it needs updating separately when anything changes. If it's a different library I believe it'll just be forgotten about and also be annoying boilerplate to maintain. That's why I'd rather just have it return a different promise object depending on what config option is used. There's not that many places internally where promises objects are used, so we can probably find a reasonable way to do that. That being said I'm wondering if this is actually a case where this is just another way of doing something that won't actually be used. AFAIK no one else have asked for this nor have we seen anyone else comment on this thread. So maybe the best option here is to just leave it as is? On 13 September 2017 at 14:31, Raymond DeCampo wrote: > I understand the concern about increasing the test surface. > > However I don't think that introducing a configuration option and having > methods that return different objects based on the option will decrease the > testing risk. There are places in the keycloak.js where it invokes it's > own methods and uses the custom promise object, for example: > > https://github.com/keycloak/keycloak/blob/b7af96aa4d7daeec6da12ee9326d1c > 0fdcc4850f/adapters/oidc/js/src/main/resources/keycloak.js#L128-L131 > > > kc.login(options).success(function () { > initPromise.setSuccess(); > }).error(function () { > initPromise.setError(); > }); > > > So these places would have to change based on the configuration option and > I think it will become a bigger problem. > > What if instead we add a method on the Keycloak object which returns a > wrapper instance using Promises and keep everything in the one keycloak.js > file? So clients could do: > > var keycloak = new Keycloak().promiseWrapper(); > > keycloak.init().then(function() { ... }); > > > And everything is in the one file? > > > Although let me make one more pitch on the merits of my original > suggestion: > > > 1. No changes to keycloak.js => less risk of breaking something that > already works > 2. The KeycloakPromise implementation delegates to the keycloak.js > implementation which means that fixes to keycloak.js automatically > propogate. > 3. The KeycloakPromise implementation is a wrapper which means it only > needs to be changed if there is a change to the keycloak.js API, e.g. a new > method or a new argument to a method (but not a new option on an existing > argument) > 4. I think it will be clearer to document the interfaces for the end > user but of course that is a matter of opinion. > > > > On Tue, Sep 12, 2017 at 11:28 PM, Stian Thorgersen > wrote: > >> I can see how it would be nice. I'm a bit worried that the separate >> javascript file would simply get out of date and it would also need >> separate testing. We're already lacking a bit on testing of the JS adapter >> in the first place and this would be yet another thing to test. Is there a >> way we could simply have a config option in the current javascript adapter >> that allows setting what promise to return? That way it's probably just a >> few lines in keycloak.js where it's creating the promise objects to switch >> between the two? >> >> On 5 September 2017 at 05:58, Raymond DeCampo wrote: >> >>> First, if I were to integrate Promise support into the Keycloak, I would >>> be leaving the current javascript adapter as is. This would be an >>> extension in a separate javascript file so that only developers who are >>> interested would get the Promise interface. Existing code using the >>> current adapter would be unaffected. The new code would be a wrapper >>> around the existing code so that maintenance would only be required if the >>> javascript adapter API changes. >>> >>> In terms of browser support, caniuse.com[1] indicates that Promise has >>> broad support; only IE 11 and Opera Mini fail to support Promise. However >>> polyfills are available to provide support. >>> >>> As far as the advantages, the main ones as I see it are: 1) using the >>> standard promise API makes it easier for developers new to the library; 2) >>> using the standard promise API makes the library more interoperable with >>> other libraries; and 3) ES6 Promise objects are chainable making sequences >>> of asynchronous calls cleaner to code. >>> >>> I think the MDN page on Using Promises[2] probably makes a better >>> argument for than I'll be able to here. But the main thrust is that >>> chaining makes it so it is not necessary to have so many nested functions. >>> >>> For example, suppose I am writing a javascript client for a REST API >>> protected by Keycloak. Since the built-in fetch() method returns a Promise >>> with ES6 Promises I can write: >>> >>> // assume authz.updateToken() returns an ES6 Promise >>> authz.updateToken(5).then((token) => { >>> return fetch(this.ENDPOINT, { >>> redirect: 'error', >>> headers: { "Authorization": "Bearer " + token } >>> }); >>> }).then((response) => { >>> showResult(response.text()); >>> }).catch((error) => { >>> displayError(error); >>> }); >>> } >>> >>> Since everything is standard, any JS developer would understand the >>> code. Since both libraries use Promise, I can chain the promises without >>> nesting functions. And since both libraries use Promise, I can use catch() >>> at the end for unified error handling whether the error comes from the >>> Keycloak adapter or from the call to fetch(). >>> >>> >>> [1] http://caniuse.com/#search=Promise >>> [2] https://developer.mozilla.org/en-US/docs/Web/JavaScript/ >>> Guide/Using_promises >>> >>> >>> On Tue, Sep 5, 2017 at 6:18 AM, Stian Thorgersen >>> wrote: >>> >>>> I don't know much about ES6 native Promises. Can you give me some >>>> details about it? What browser support it? What are the benefits of using >>>> that instead of our howegrown approach? Etc. >>>> >>>> On 4 September 2017 at 20:36, Raymond DeCampo wrote: >>>> >>>>> Hello all, >>>>> >>>>> I create a wrapper around the javascript adapter which uses ES6 native >>>>> Promises. (https://github.com/RayDeCampo/keycloak-promise). >>>>> >>>>> If you are interested, I can re-package it for inclusion in Keycloak >>>>> and >>>>> create a pull request on GitHub. If you have a different process for >>>>> contributions, let me know. >>>>> >>>>> If you are not interested, no hard feelings. >>>>> >>>>> Thanks, >>>>> Ray >>>>> _______________________________________________ >>>>> keycloak-dev mailing list >>>>> keycloak-dev at lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>>>> >>>> >>>> >>> >> > From bburke at redhat.com Mon Sep 18 11:27:42 2017 From: bburke at redhat.com (Bill Burke) Date: Mon, 18 Sep 2017 11:27:42 -0400 Subject: [keycloak-dev] Where put token exchange docs? Message-ID: Where should I put token exchange docs? Server admin? or Server Dev? Server dev sounds right, correct? -- Bill Burke Red Hat From mstrukel at redhat.com Mon Sep 18 11:57:32 2017 From: mstrukel at redhat.com (Marko Strukelj) Date: Mon, 18 Sep 2017 17:57:32 +0200 Subject: [keycloak-dev] Policy around migration-*.cli scripts In-Reply-To: References: Message-ID: On Mon, Sep 18, 2017 at 3:28 PM, Stian Thorgersen wrote: > On 17 September 2017 at 00:08, Stan Silvert wrote: > > > Marko and I spent a lot of time Friday chatting about it and trying a > > few things. If anyone wants the gory details I can post the text. > > > > We're not finished, but the summary is that we need to: > > 1) Make sure the migration test is running properly > > 2) Work with Tomaz Cerar to find out about his latest API improvements > > for subsystem versioning. > > 3) Decide if we should start using Tomaz's stuff in the future instead > > of or in addition to the migration scripts. > > > > A big question is how far back do we want to support migration? Right > > now the migration tool for standalone.xml goes back to 1.8. So we are > > supporting migration of standalone.xml for anything forward from that. > > Maybe we don't need to go back that far. > > > > No need to go back further than 1.9.8 (RH-SSO 7.0) > > > > > > I don't think we will ever get rid of the migration scripts entirely. > > We are (almost) required to use it for non-keycloak subsystems, so it > > kind of makes sense to have migration for our stuff in the same script. > > > > Almost? If we could get rid of it completely would that not make migration > simpler for users? > The key here is 'for non-keycloak subsystems'. AFAIK these can not be migrated from within keycloak-server subsystem or maybe their model can be affected but would trigger reloads of whole subsystems. I would need to explore that. Even if it worked it would probably only work for standalone, not for domain? The benefit would be - no need to run migration .cli, the 'bad' thing would be - you couldn't take a look in advance what config changes are about to be performed, which is something server admins may place a high value on. From rmartinc at redhat.com Mon Sep 18 11:57:42 2017 From: rmartinc at redhat.com (Ricardo Martin Camarero) Date: Mon, 18 Sep 2017 17:57:42 +0200 Subject: [keycloak-dev] Implementations for KEYCLOAK-2209 In-Reply-To: References: Message-ID: Hi Stian, I'm answering inline... On 09/18/2017 03:58 PM, Stian Thorgersen wrote: > Reading your email I couldn't figure out how you assign a password > policy to a user. The password policy is just assigned using an attribute in the user (like firstname or lastname). The only difference is that in option 1 it is single-valued and in option 2 it is multi-valiued (to test the merge). You can really play with it if you clone my repos and start the the server, create another password policy, create a user and assign a password policy to it (in the details tab). > I think it would be best if there's an ordered/prioritized list of > password policies. Each policy would have a set of conditions on > whether or not the policy should be applied to a specific user. Where > conditions should include member/not-member of a specific group, > has/doesn't have a specific role, a specific attribute key/value or if > a user belongs to a specific user fed provider. If none matches the > last in the list should be used. I find having more than one policy > apply to a specific user just confusing so it should be the first > policy that matches for a user that is used. That is much more complex of what I was thinking and what KEYCLOAK-2209 describes. My idea is much more simple: * The realm has a default password policy (the current one). * The user may have assigned a specific password policy. * Any group may have assigned a specific password policy (this part is not done in the branches). * As a user can result with several password policies assigned (because of the groups): ? Option 1: The policy with the highest priority applies. ? Option 2: Policies are merged (or all of them applied as the enhancement says). As you see my implementation is much more modest than your idea. Your idea can be later achieved with something like dynamic groups (a group that is automatically assigned because of an attribute in the user, because those groups can also have a password policy). > > Now with regards to implementation it would make sense to convert > password policies to use component storage rather than add additional > tables/attributes for password policies. The single string password > policy was introduced before we had component storage and it is our > plan to eventually convert password policies to use component storage. > Component storage is much more flexible and powerful than what we have > today for password policies. It allows the provider itself to expose > what configuration applies to it. No idea about what is the component storage but ok, if you want me to continue with my modest approach I'll take a look to that and I'll move the password policies to component storage. Thanks. > > On 12 September 2017 at 19:59, Ricardo Martin Camarero > > wrote: > > Hi team, > > I'm forwarding this email to the list following Stian's > recommendation. > > I needed to learn more about keycloak (how to manage the maven > project, > how to add a modification, how to test it, and so on and so > forth), so I > decided to start looking the code and try to help when I have some > free > time. As I filed an internal RFE because one customer wanted a similar > solution than the one specified in KEYCLOAK-2209 I started to > implement > something. Now I have two possible ideas that are not completely > implemented (I haven't done any group use for example). Both ideas > have > similarities: > > * I have extended the database to include a > REALM_PASSWORD_POLICY_GROUP > table that contains more policies associated to the realm. I thought > about using an attribute but I decided to extend the database because > the current policy attribute is a long string (length 2550). This > way in > the realm (policies page) now you can configure more than one password > policy (default is the current one and you can add new policies > that are > saved in the new table with a name). > > * The user has a new attribute that contains the password policy, in > this case I have re-used an attribute (I'm not sure about this > idea, now > I think using a new column would be better but I needed a multiple > attribute for option 2). > > * In both solutions I needed to extend the PasswordPolicyProvider > interface to pass the config to the two validate methods: > > ? PolicyError validate(RealmModel realm, UserModel user, String > password, Object config); > > ? I think there is a bug in this part in current master branch, > because > regex policy is multiple, and you cannot assign two different regex > providers in the same policy (PasswordPolicy stores the > configuration in > a Map, so you cannot have two different configurations > for the same type, if you assign two regex providers they are > transformed into one as soon as you save the policy). > > > Now the two implementations: > > 1) The first idea let us configure to a user one password policy. My > branch is this one: > > ? https://github.com/rmartinc/keycloak/tree/password-policy-groups > > > ? In this solution the user has a combo (only one policy can be > assigned > to a user) and only one policy is applied to that user. My idea was > extending the idea using groups and priorities. Password policies will > have a priority, and only one policy will apply to a user (from > all the > possible policies the one with the higher priority applies). For the > moment I only modified keycloak to have a different policy in the user > (no priorities or group policies). > > 2) The second idea follows the description in 2209. The branch is the > following: > > ? > https://github.com/rmartinc/keycloak/tree/password-policy-groups-multi > > > ? Here the user can have multiple password policies. The definitive > policy is a merge between all the policies applied to the user. To do > this I needed to extend the PasswordPolicyProvider interface even > more, > in order to have a compare method that returns which policy is more > restrictive. Extending this idea to groups is just merging more > policies. > > > You can test my ideas (I think both of them are working). If you are > interested please let me know which idea you think is better (I'm not > completely sure, now I think that I prefer option 1, although option 2 > is more similar to the RFE description, I think the latter is very > confusing). If you like one of them, I'll try to finish the > implementation (now there are no tests and some decisions I took maybe > are wrong). If you think this is not needed or it's not the time to > implement this RFE don't worry, it's ok, I needed to play with > keycloak, > and that part is done. > > Regards! > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > -- Ricardo Martin Camarero Software Maintenance Engineer Red Hat From nielsbne at gmail.com Mon Sep 18 12:16:22 2017 From: nielsbne at gmail.com (Niels Bertram) Date: Tue, 19 Sep 2017 02:16:22 +1000 Subject: [keycloak-dev] Promise wrapper for javascript adapter In-Reply-To: References: Message-ID: Hmm ... I was actally looking at the js libraries (browser and node ones) a short while ago and thought the same thing, why not use a A+ compliant promise [1] instead of the custom thingy. It is hard to follow custom logic when basic concepts exist and are understood. Why not implement standard promises in the main library and write a wrapper for the custom promises. Then mark those for deprecation and retire them in a few releases. I think mongoose did this some time back with a pluggable promise interface [2] to escape callback hell. I think this would improve the adoptability of the adapters given lots of folks don't fully understand OIDC and throw things in the too hard basket as soon as they are given the slightest opportunity - real world experience. Cheers Niels [1] https://promisesaplus.com [2] http://mongoosejs.com/docs/promises.html On 18 Sep. 2017 4:44 am, "Stian Thorgersen" wrote: > I don't like the idea of having a wrapper as it needs updating separately > when anything changes. If it's a different library I believe it'll just be > forgotten about and also be annoying boilerplate to maintain. That's why > I'd rather just have it return a different promise object depending on what > config option is used. There's not that many places internally where > promises objects are used, so we can probably find a reasonable way to do > that. > > That being said I'm wondering if this is actually a case where this is just > another way of doing something that won't actually be used. AFAIK no one > else have asked for this nor have we seen anyone else comment on this > thread. So maybe the best option here is to just leave it as is? > > On 13 September 2017 at 14:31, Raymond DeCampo wrote: > > > I understand the concern about increasing the test surface. > > > > However I don't think that introducing a configuration option and having > > methods that return different objects based on the option will decrease > the > > testing risk. There are places in the keycloak.js where it invokes it's > > own methods and uses the custom promise object, for example: > > > > https://github.com/keycloak/keycloak/blob/b7af96aa4d7daeec6da12ee9326d1c > > 0fdcc4850f/adapters/oidc/js/src/main/resources/keycloak.js#L128-L131 > > > > > > kc.login(options).success(function () { > > initPromise.setSuccess(); > > }).error(function () { > > initPromise.setError(); > > }); > > > > > > So these places would have to change based on the configuration option > and > > I think it will become a bigger problem. > > > > What if instead we add a method on the Keycloak object which returns a > > wrapper instance using Promises and keep everything in the one > keycloak.js > > file? So clients could do: > > > > var keycloak = new Keycloak().promiseWrapper(); > > > > keycloak.init().then(function() { ... }); > > > > > > And everything is in the one file? > > > > > > Although let me make one more pitch on the merits of my original > > suggestion: > > > > > > 1. No changes to keycloak.js => less risk of breaking something that > > already works > > 2. The KeycloakPromise implementation delegates to the keycloak.js > > implementation which means that fixes to keycloak.js automatically > > propogate. > > 3. The KeycloakPromise implementation is a wrapper which means it only > > needs to be changed if there is a change to the keycloak.js API, e.g. > a new > > method or a new argument to a method (but not a new option on an > existing > > argument) > > 4. I think it will be clearer to document the interfaces for the end > > user but of course that is a matter of opinion. > > > > > > > > On Tue, Sep 12, 2017 at 11:28 PM, Stian Thorgersen > > wrote: > > > >> I can see how it would be nice. I'm a bit worried that the separate > >> javascript file would simply get out of date and it would also need > >> separate testing. We're already lacking a bit on testing of the JS > adapter > >> in the first place and this would be yet another thing to test. Is > there a > >> way we could simply have a config option in the current javascript > adapter > >> that allows setting what promise to return? That way it's probably just > a > >> few lines in keycloak.js where it's creating the promise objects to > switch > >> between the two? > >> > >> On 5 September 2017 at 05:58, Raymond DeCampo wrote: > >> > >>> First, if I were to integrate Promise support into the Keycloak, I > would > >>> be leaving the current javascript adapter as is. This would be an > >>> extension in a separate javascript file so that only developers who are > >>> interested would get the Promise interface. Existing code using the > >>> current adapter would be unaffected. The new code would be a wrapper > >>> around the existing code so that maintenance would only be required if > the > >>> javascript adapter API changes. > >>> > >>> In terms of browser support, caniuse.com[1] indicates that Promise has > >>> broad support; only IE 11 and Opera Mini fail to support Promise. > However > >>> polyfills are available to provide support. > >>> > >>> As far as the advantages, the main ones as I see it are: 1) using the > >>> standard promise API makes it easier for developers new to the > library; 2) > >>> using the standard promise API makes the library more interoperable > with > >>> other libraries; and 3) ES6 Promise objects are chainable making > sequences > >>> of asynchronous calls cleaner to code. > >>> > >>> I think the MDN page on Using Promises[2] probably makes a better > >>> argument for than I'll be able to here. But the main thrust is that > >>> chaining makes it so it is not necessary to have so many nested > functions. > >>> > >>> For example, suppose I am writing a javascript client for a REST API > >>> protected by Keycloak. Since the built-in fetch() method returns a > Promise > >>> with ES6 Promises I can write: > >>> > >>> // assume authz.updateToken() returns an ES6 Promise > >>> authz.updateToken(5).then((token) => { > >>> return fetch(this.ENDPOINT, { > >>> redirect: 'error', > >>> headers: { "Authorization": "Bearer " + token } > >>> }); > >>> }).then((response) => { > >>> showResult(response.text()); > >>> }).catch((error) => { > >>> displayError(error); > >>> }); > >>> } > >>> > >>> Since everything is standard, any JS developer would understand the > >>> code. Since both libraries use Promise, I can chain the promises > without > >>> nesting functions. And since both libraries use Promise, I can use > catch() > >>> at the end for unified error handling whether the error comes from the > >>> Keycloak adapter or from the call to fetch(). > >>> > >>> > >>> [1] http://caniuse.com/#search=Promise > >>> [2] https://developer.mozilla.org/en-US/docs/Web/JavaScript/ > >>> Guide/Using_promises > >>> > >>> > >>> On Tue, Sep 5, 2017 at 6:18 AM, Stian Thorgersen > >>> wrote: > >>> > >>>> I don't know much about ES6 native Promises. Can you give me some > >>>> details about it? What browser support it? What are the benefits of > using > >>>> that instead of our howegrown approach? Etc. > >>>> > >>>> On 4 September 2017 at 20:36, Raymond DeCampo > wrote: > >>>> > >>>>> Hello all, > >>>>> > >>>>> I create a wrapper around the javascript adapter which uses ES6 > native > >>>>> Promises. (https://github.com/RayDeCampo/keycloak-promise). > >>>>> > >>>>> If you are interested, I can re-package it for inclusion in Keycloak > >>>>> and > >>>>> create a pull request on GitHub. If you have a different process for > >>>>> contributions, let me know. > >>>>> > >>>>> If you are not interested, no hard feelings. > >>>>> > >>>>> Thanks, > >>>>> Ray > >>>>> _______________________________________________ > >>>>> 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 ssilvert at redhat.com Mon Sep 18 12:40:01 2017 From: ssilvert at redhat.com (Stan Silvert) Date: Mon, 18 Sep 2017 12:40:01 -0400 Subject: [keycloak-dev] Policy around migration-*.cli scripts In-Reply-To: References: Message-ID: <75339df4-0a72-7b8a-e2ec-cba8d0fa16d2@redhat.com> On 9/18/2017 9:28 AM, Stian Thorgersen wrote: > > > On 17 September 2017 at 00:08, Stan Silvert > wrote: > > Marko and I spent a lot of time Friday chatting about it and trying a > few things. If anyone wants the gory details I can post the text. > > We're not finished, but the summary is that we need to: > 1) Make sure the migration test is running properly > 2) Work with Tomaz Cerar to find out about his latest API improvements > for subsystem versioning. > 3) Decide if we should start using Tomaz's stuff in the future instead > of or in addition to the migration scripts. > > A big question is how far back do we want to support migration? Right > now the migration tool for standalone.xml goes back to 1.8. So we are > supporting migration of standalone.xml for anything forward from that. > Maybe we don't need to go back that far. > > > No need to go back further than 1.9.8 (RH-SSO 7.0) > > > I don't think we will ever get rid of the migration scripts entirely. > We are (almost) required to use it for non-keycloak subsystems, so it > kind of makes sense to have migration for our stuff in the same > script. > > > Almost? If we could get rid of it completely would that not make > migration simpler for users? I just mean it's technically possible to rewrite parts of non-keycloak subsystems to add keycloak default values. Not something I think we would really want to do. > > > On 9/15/2017 5:26 AM, Stian Thorgersen wrote: > > Stan knows this stuff better than anyone, but I seem to remember > there was > > some good reasons for this. > > > > On 14 September 2017 at 18:28, Marko Strukelj > > wrote: > > > >> I was wondering why migration-*.cli scripts contain migrations for > >> keycloak-server subsystem. > >> > >> It makes perfect sense that they are used to adjust > configuration of other > >> wildfly subsystems that we don't control. But for > keycloak-server I imagine > >> all migration should be performed at runtime by keycloak-server > subsystem > >> itself. This way migration is easier to do, it involves fewer > modules in > >> our build, fewer files (no /subsystem=keycloak-server entries in > >> migration-*.cli files), and it's testable in a single module. > >> > >> Any reason why not do it that way? > >> > >> Another thing - currently our (de facto) versioning policy for > keycloak > >> subsystems is to not increment the version as long as the old > syntax/model > >> keeps working, even if we introduce new xml syntax we keep the > old version > >> number. > >> > >> In practice that means that if I see an example of subsystem > configuration > >> somewhere, and I copy it to the older version of Keycloak (why > not, it says > >> it's still version 1.1) that would not work if it contains any > later syntax > >> that older version doesn't understand. Older keycloak-server > configuration > >> can be copied to newer version of Keycloak without issues. > >> > >> That's simple for us to maintain, and seems to work well enough. > >> Technically we'll only have to increment version if we decide > to break > >> backwards compatibility of the configuration - nowhere on our > radar ATM. > >> > >> Does anyone see this policy as problematic? > >> > >> - marko > >> _______________________________________________ > >> 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 > > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > From ssilvert at redhat.com Mon Sep 18 17:35:34 2017 From: ssilvert at redhat.com (Stan Silvert) Date: Mon, 18 Sep 2017 17:35:34 -0400 Subject: [keycloak-dev] Angular 2 Account Management Message-ID: <1f22c463-94e9-8691-7dd5-e891bc2e4525@redhat.com> The new Angular 2 Account Management Console just got its first commit to master. This console will be extensible, allowing new pages to be added. It will have a better look and feel as it adheres to PatternFly standards. Also, it looks nice on your phone. If you'd like to take a peek, you will need to build keycloak with an "account2" profile ( mvn install -Paccount2 ) Then when you run the server, use this system property: -Dkeycloak.profile.feature.account2=enabled After that, just log in to the admin console and set the account theme to "keycloak-preview" Don't expect full functionality just yet. There is a lot of work to do on the back end with our new account management REST endpoints. Stan From Sebastian.Schuster at bosch-si.com Tue Sep 19 03:02:26 2017 From: Sebastian.Schuster at bosch-si.com (Schuster Sebastian (INST/ESY1)) Date: Tue, 19 Sep 2017 07:02:26 +0000 Subject: [keycloak-dev] Angular 2 Account Management In-Reply-To: <1f22c463-94e9-8691-7dd5-e891bc2e4525@redhat.com> References: <1f22c463-94e9-8691-7dd5-e891bc2e4525@redhat.com> Message-ID: <563a243edea44ee5bb82896dfa3b4f02@FE-MBX1028.de.bosch.com> Hi Stan, Is this supposed to run OOTB or do I need to install anything else manually? I get an error when building complaining about yarn not being there: [ERROR] Failed to execute goal com.github.eirslett:frontend-maven-plugin:1.5:yarn (yarn install keycloak preview) on project keycloak-themes: Failed to run task: 'yarn install --production=false --frozen-lockfile' failed. java.io.IOException: Cannot run program "/home/xyz/repos/keycloak/themes/src/main/resources/theme/keycloak-preview/account/resources/node/yarn/dist/bin/yarn" (in directory "/home/xyz/repos/keycloak/themes/src/main/resources/theme/keycloak-preview/account/resources"): error=2, No such file or directory -> [Help 1] 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.-Ing. Rainer Kallenbach, Michael Hahn -----Original Message----- From: keycloak-dev-bounces at lists.jboss.org [mailto:keycloak-dev-bounces at lists.jboss.org] On Behalf Of Stan Silvert Sent: Montag, 18. September 2017 23:36 To: keycloak-dev Subject: [keycloak-dev] Angular 2 Account Management The new Angular 2 Account Management Console just got its first commit to master. This console will be extensible, allowing new pages to be added. It will have a better look and feel as it adheres to PatternFly standards. Also, it looks nice on your phone. If you'd like to take a peek, you will need to build keycloak with an "account2" profile ( mvn install -Paccount2 ) Then when you run the server, use this system property: -Dkeycloak.profile.feature.account2=enabled After that, just log in to the admin console and set the account theme to "keycloak-preview" Don't expect full functionality just yet. There is a lot of work to do on the back end with our new account management REST endpoints. Stan _______________________________________________ keycloak-dev mailing list keycloak-dev at lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-dev From ssilvert at redhat.com Tue Sep 19 09:15:56 2017 From: ssilvert at redhat.com (Stan Silvert) Date: Tue, 19 Sep 2017 09:15:56 -0400 Subject: [keycloak-dev] Angular 2 Account Management In-Reply-To: <563a243edea44ee5bb82896dfa3b4f02@FE-MBX1028.de.bosch.com> References: <1f22c463-94e9-8691-7dd5-e891bc2e4525@redhat.com> <563a243edea44ee5bb82896dfa3b4f02@FE-MBX1028.de.bosch.com> Message-ID: <683beed9-0c90-a426-4f0a-d0f41cdc724d@redhat.com> On 9/19/2017 3:02 AM, Schuster Sebastian (INST/ESY1) wrote: > Hi Stan, > > Is this supposed to run OOTB or do I need to install anything else manually? I get an error when building complaining about yarn not being there: It should run OOTB as long as you specify -Paccount2 for your profile. But I messed up and left out the part that downloads node.exe and yarn. Didn't notice it because it was already installed on my machine. I'll fix it right away and let you know when you can try again. > > [ERROR] Failed to execute goal com.github.eirslett:frontend-maven-plugin:1.5:yarn (yarn install keycloak preview) on project keycloak-themes: Failed to run task: 'yarn install --production=false --frozen-lockfile' failed. java.io.IOException: Cannot run program "/home/xyz/repos/keycloak/themes/src/main/resources/theme/keycloak-preview/account/resources/node/yarn/dist/bin/yarn" (in directory "/home/xyz/repos/keycloak/themes/src/main/resources/theme/keycloak-preview/account/resources"): error=2, No such file or directory -> [Help 1] > > 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.-Ing. Rainer Kallenbach, Michael Hahn > > > > -----Original Message----- > From: keycloak-dev-bounces at lists.jboss.org [mailto:keycloak-dev-bounces at lists.jboss.org] On Behalf Of Stan Silvert > Sent: Montag, 18. September 2017 23:36 > To: keycloak-dev > Subject: [keycloak-dev] Angular 2 Account Management > > The new Angular 2 Account Management Console just got its first commit to master. This console will be extensible, allowing new pages to be added. It will have a better look and feel as it adheres to PatternFly standards. Also, it looks nice on your phone. > > If you'd like to take a peek, you will need to build keycloak with an "account2" profile ( mvn install -Paccount2 ) > > Then when you run the server, use this system property: > -Dkeycloak.profile.feature.account2=enabled > > After that, just log in to the admin console and set the account theme to "keycloak-preview" > > Don't expect full functionality just yet. There is a lot of work to do on the back end with our new account management REST endpoints. > > Stan > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev From sthorger at redhat.com Tue Sep 19 09:33:16 2017 From: sthorger at redhat.com (Stian Thorgersen) Date: Tue, 19 Sep 2017 15:33:16 +0200 Subject: [keycloak-dev] Where put token exchange docs? In-Reply-To: References: Message-ID: What about the securing apps and services guide? Seems like nothing is the perfect place, but to me that seems the best one. On 18 September 2017 at 17:27, Bill Burke wrote: > Where should I put token exchange docs? Server admin? or Server Dev? > Server dev sounds right, correct? > > -- > Bill Burke > Red Hat > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > From ssilvert at redhat.com Tue Sep 19 10:42:26 2017 From: ssilvert at redhat.com (Stan Silvert) Date: Tue, 19 Sep 2017 10:42:26 -0400 Subject: [keycloak-dev] Angular 2 Account Management In-Reply-To: <683beed9-0c90-a426-4f0a-d0f41cdc724d@redhat.com> References: <1f22c463-94e9-8691-7dd5-e891bc2e4525@redhat.com> <563a243edea44ee5bb82896dfa3b4f02@FE-MBX1028.de.bosch.com> <683beed9-0c90-a426-4f0a-d0f41cdc724d@redhat.com> Message-ID: <3d7b6346-da82-a729-d2ce-b05233ee4cbd@redhat.com> On 9/19/2017 9:15 AM, Stan Silvert wrote: > On 9/19/2017 3:02 AM, Schuster Sebastian (INST/ESY1) wrote: >> Hi Stan, >> >> Is this supposed to run OOTB or do I need to install anything else manually? I get an error when building complaining about yarn not being there: > It should run OOTB as long as you specify -Paccount2 for your profile. > But I messed up and left out the part that downloads node.exe and yarn. > Didn't notice it because it was already installed on my machine. I'll > fix it right away and let you know when you can try again. Just merged the fix. Should work now. Thanks for letting me know about it. >> [ERROR] Failed to execute goal com.github.eirslett:frontend-maven-plugin:1.5:yarn (yarn install keycloak preview) on project keycloak-themes: Failed to run task: 'yarn install --production=false --frozen-lockfile' failed. java.io.IOException: Cannot run program "/home/xyz/repos/keycloak/themes/src/main/resources/theme/keycloak-preview/account/resources/node/yarn/dist/bin/yarn" (in directory "/home/xyz/repos/keycloak/themes/src/main/resources/theme/keycloak-preview/account/resources"): error=2, No such file or directory -> [Help 1] >> >> 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.-Ing. Rainer Kallenbach, Michael Hahn >> >> >> >> -----Original Message----- >> From: keycloak-dev-bounces at lists.jboss.org [mailto:keycloak-dev-bounces at lists.jboss.org] On Behalf Of Stan Silvert >> Sent: Montag, 18. September 2017 23:36 >> To: keycloak-dev >> Subject: [keycloak-dev] Angular 2 Account Management >> >> The new Angular 2 Account Management Console just got its first commit to master. This console will be extensible, allowing new pages to be added. It will have a better look and feel as it adheres to PatternFly standards. Also, it looks nice on your phone. >> >> If you'd like to take a peek, you will need to build keycloak with an "account2" profile ( mvn install -Paccount2 ) >> >> Then when you run the server, use this system property: >> -Dkeycloak.profile.feature.account2=enabled >> >> After that, just log in to the admin console and set the account theme to "keycloak-preview" >> >> Don't expect full functionality just yet. There is a lot of work to do on the back end with our new account management REST endpoints. >> >> Stan >> _______________________________________________ >> 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 Sep 19 16:49:36 2017 From: aron.bustya.js at gmail.com (Aron Bustya) Date: Tue, 19 Sep 2017 22:49:36 +0200 Subject: [keycloak-dev] Claims parameter support Message-ID: Hello! I need the 'claims parameter' support in keycloak that has been thought about in this jira ticket and postponed/rejected: https://issues.jboss.org/browse/KEYCLOAK-3226 The proposed alternatives don't work for me, because I am implementing a specification that explicitly requests data to be passed this way. In addition to the JIRA above we also need to support passing the claims parameter in the signed request object - not just as a separate query param. I've solved the problem for our own use case by writing a ProtocolMapper but some changes were also needed in the keycloak request parser (to support the parsing of json objects from the request object - not just strings). The ProtocolMapper I've written doesn't support the whole claims parameter feature though - it can only add the default value of the claim to the the tokens. I'm now trying to figure out how much of this code could be put back into keycloak, and what needs to be changed to do so. My goal would be to use an 'official' keycloak with cutomization only in Service Providers and configuration. Current code commit is here: https://github.com/abustya/keycloak/commit/41fecf57a982ffdb9 6e210d8bd302d23fa7884da What do you think about the direction of the development, does it make any sense to put some of it back into keycloak? Regards, ?ron Bustya From mposolda at redhat.com Wed Sep 20 03:55:34 2017 From: mposolda at redhat.com (Marek Posolda) Date: Wed, 20 Sep 2017 09:55:34 +0200 Subject: [keycloak-dev] Claims parameter support In-Reply-To: References: Message-ID: <9432de62-9275-14c5-8b8e-6211e151d6c5@redhat.com> Great work! If I see it correctly, there are 2 parts: 1) improvements in request object parsing - I am all for include your improvements. If you can create separate JIRA for current request object limitation, add the test (there are existing tests for request object in OIDCAdvancedRequestParamsTest. Feel free to add new test or change one of existing tests) and create separate PR, it will be nice and will be merged. If I understand correctly, this is the only part, which really blocks you right? (As additional protocolMapper can be deployed to the existing Keycloak instance as separate JAR and doesn't require changes in core keycloak code?) 2) ProtocolMapper for claims - as you pointed, you don't have full support for 'claims' parameter. Still it's better then nothing, so my vote is to include your changes. I am not 100% convinced, maybe someone has different opinion on it (new protocolMapper always adds a bit of additional complexity. However I think it's ok as it's OIDC standard). Maybe one small change, if you can add the "claims" to the AuthzEndpointRequestParser.KNOWN_PARAMS and have separate client note for it as other known OIDC params? Thanks! Marek On 19/09/17 22:49, Aron Bustya wrote: > Hello! > > I need the 'claims parameter' support in keycloak that has been thought > about in this jira ticket and postponed/rejected: > https://issues.jboss.org/browse/KEYCLOAK-3226 > The proposed alternatives don't work for me, because I am implementing a > specification that explicitly requests data to be passed this way. > In addition to the JIRA above we also need to support passing the claims > parameter in the signed request object - not just as a separate query param. > > I've solved the problem for our own use case by writing a ProtocolMapper > but some changes were also needed in the keycloak request parser (to > support the parsing of json objects from the request object - not just > strings). > > The ProtocolMapper I've written doesn't support the whole claims parameter > feature though - it can only add the default value of the claim to the the > tokens. > > I'm now trying to figure out how much of this code could be put back into > keycloak, and what needs to be changed to do so. > My goal would be to use an 'official' keycloak with cutomization only in > Service Providers and configuration. > > Current code commit is here: > https://github.com/abustya/keycloak/commit/41fecf57a982ffdb9 > 6e210d8bd302d23fa7884da > > What do you think about the direction of the development, does it make any > sense to put some of it back into keycloak? > > Regards, > ?ron Bustya > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev From ivan at akvo.org Wed Sep 20 06:35:30 2017 From: ivan at akvo.org (=?UTF-8?Q?Iv=c3=a1n_Perdomo?=) Date: Wed, 20 Sep 2017 12:35:30 +0200 Subject: [keycloak-dev] Proposal: Update Dockerfiles to use jboss-cli In-Reply-To: References: <264526a2-f0ec-d46d-7d42-7b2fb2bbcb76@akvo.org> Message-ID: Hi, PR - https://github.com/jboss-dockerfiles/keycloak/pull/85 In the PR description we linked [1] to a list of .diff files that show the changes introduced. We diffed the distribution standalone[-ha].xml with the contents of the docker images. [1] https://gist.github.com/baztan106483/e67989b15f6429228310ca79bc0110df Cheers, On 09/15/2017 10:49 AM, Iv?n Perdomo wrote: > Hi, > > There are not that many environment variables, basically Keycloak and > Maven version, plus LAUNCH_JBOSS_IN_BACKGROUND for 'graceful shutdown'. > The only i one i see that actually modifies behavior is the > PROXY_ADDRESS_FORWARDING when the service is behind a reverse proxy. > > $ grep -rn ENV . > ./server/Dockerfile:3:ENV KEYCLOAK_VERSION 3.3.0.CR2 > ./server/Dockerfile:6:ENV LAUNCH_JBOSS_IN_BACKGROUND 1 > ./server/Dockerfile:7:ENV PROXY_ADDRESS_FORWARDING false > ./server/Dockerfile:21:ENV JBOSS_HOME /opt/jboss/keycloak > ./server-postgres/Dockerfile:3:ENV POSTGRES_JDBC_VERSION 42.1.4 > ./proxy/Dockerfile:3:ENV KEYCLOAK_VERSION 3.2.0.Final > ./examples/Dockerfile:3:ENV KEYCLOAK_VERSION 3.3.0.CR2 > ./examples/Dockerfile:4:ENV JBOSS_HOME /opt/jboss/keycloak-demo/keycloak > ./examples/Dockerfile:5:ENV MAVEN_VERSION 3.3.9 > ./examples/Dockerfile:8:ENV LAUNCH_JBOSS_IN_BACKGROUND 1 > ./examples/Dockerfile:16:ENV MAVEN_HOME /usr/share/maven > ./adapter-wildfly/Dockerfile:3:ENV KEYCLOAK_VERSION 3.3.0.CR2 > > Cheers, > > > On 09/14/2017 05:03 PM, Bill Burke wrote: >> Just a thought, just brainstorming... >> >> Maybe all environment variables should be ditched and only jboss-cli >> should be supported? Users extend the Keycloak image, hardcode the >> things they want to hardcode via jboss-cli, introduce their own >> environment variables as parameters to CLI as they see fit. Just >> seems like a much better option than having to duplicate and document >> pre-defined environment variables. >> >> On Thu, Sep 14, 2017 at 12:51 AM, Stian Thorgersen wrote: >>> Absolutely :) >>> >>> On 13 September 2017 at 12:53, Iv?n Perdomo wrote: >>> >>>> >>>> Hi all, >>>> >>>> Thanks to Rub?n [1] we have successfully changed our customization to >>>> Keycloak Docker images using jboss-cli and embed-server, instead of XSLT >>>> transformations. >>>> >>>> In the past Stian has suggested that the XSLT was done before >>>> embed-server was available [2]. >>>> >>>> We would like to contribute some of this changes to the base images. Can >>>> we log an issue and send a pull request? >>>> >>>> The proposed changes will be just to remove xlst transformations with >>>> jboss-cli commands. >>>> >>>> >>>> [1] https://github.com/baztan106483 >>>> [2] >>>> https://lists.jboss.org/pipermail/keycloak-user/2016-February/005120.html >>>> >>>> Thanks, >>>> >>>> -- >>>> Iv?n >>>> _______________________________________________ >>>> 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 >> >> >> > -- Iv?n From sthorger at redhat.com Wed Sep 20 08:20:38 2017 From: sthorger at redhat.com (Stian Thorgersen) Date: Wed, 20 Sep 2017 14:20:38 +0200 Subject: [keycloak-dev] Proposal: Update Dockerfiles to use jboss-cli In-Reply-To: References: <264526a2-f0ec-d46d-7d42-7b2fb2bbcb76@akvo.org> Message-ID: Nice one, thanks. I'll take a look next week as I don't have time to review it this week. On 20 September 2017 at 12:35, Iv?n Perdomo wrote: > Hi, > > PR - https://github.com/jboss-dockerfiles/keycloak/pull/85 > > In the PR description we linked [1] to a list of .diff files that show > the changes introduced. We diffed the distribution standalone[-ha].xml > with the contents of the docker images. > > [1] https://gist.github.com/baztan106483/e67989b15f6429228310ca79bc0110df > > Cheers, > > > On 09/15/2017 10:49 AM, Iv?n Perdomo wrote: > > Hi, > > > > There are not that many environment variables, basically Keycloak and > > Maven version, plus LAUNCH_JBOSS_IN_BACKGROUND for 'graceful shutdown'. > > The only i one i see that actually modifies behavior is the > > PROXY_ADDRESS_FORWARDING when the service is behind a reverse proxy. > > > > $ grep -rn ENV . > > ./server/Dockerfile:3:ENV KEYCLOAK_VERSION 3.3.0.CR2 > > ./server/Dockerfile:6:ENV LAUNCH_JBOSS_IN_BACKGROUND 1 > > ./server/Dockerfile:7:ENV PROXY_ADDRESS_FORWARDING false > > ./server/Dockerfile:21:ENV JBOSS_HOME /opt/jboss/keycloak > > ./server-postgres/Dockerfile:3:ENV POSTGRES_JDBC_VERSION 42.1.4 > > ./proxy/Dockerfile:3:ENV KEYCLOAK_VERSION 3.2.0.Final > > ./examples/Dockerfile:3:ENV KEYCLOAK_VERSION 3.3.0.CR2 > > ./examples/Dockerfile:4:ENV JBOSS_HOME /opt/jboss/keycloak-demo/keycloak > > ./examples/Dockerfile:5:ENV MAVEN_VERSION 3.3.9 > > ./examples/Dockerfile:8:ENV LAUNCH_JBOSS_IN_BACKGROUND 1 > > ./examples/Dockerfile:16:ENV MAVEN_HOME /usr/share/maven > > ./adapter-wildfly/Dockerfile:3:ENV KEYCLOAK_VERSION 3.3.0.CR2 > > > > Cheers, > > > > > > On 09/14/2017 05:03 PM, Bill Burke wrote: > >> Just a thought, just brainstorming... > >> > >> Maybe all environment variables should be ditched and only jboss-cli > >> should be supported? Users extend the Keycloak image, hardcode the > >> things they want to hardcode via jboss-cli, introduce their own > >> environment variables as parameters to CLI as they see fit. Just > >> seems like a much better option than having to duplicate and document > >> pre-defined environment variables. > >> > >> On Thu, Sep 14, 2017 at 12:51 AM, Stian Thorgersen > wrote: > >>> Absolutely :) > >>> > >>> On 13 September 2017 at 12:53, Iv?n Perdomo wrote: > >>> > >>>> > >>>> Hi all, > >>>> > >>>> Thanks to Rub?n [1] we have successfully changed our customization to > >>>> Keycloak Docker images using jboss-cli and embed-server, instead of > XSLT > >>>> transformations. > >>>> > >>>> In the past Stian has suggested that the XSLT was done before > >>>> embed-server was available [2]. > >>>> > >>>> We would like to contribute some of this changes to the base images. > Can > >>>> we log an issue and send a pull request? > >>>> > >>>> The proposed changes will be just to remove xlst transformations with > >>>> jboss-cli commands. > >>>> > >>>> > >>>> [1] https://github.com/baztan106483 > >>>> [2] > >>>> https://lists.jboss.org/pipermail/keycloak-user/2016- > February/005120.html > >>>> > >>>> Thanks, > >>>> > >>>> -- > >>>> Iv?n > >>>> _______________________________________________ > >>>> 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 > >> > >> > >> > > > > -- > Iv?n > From bburke at redhat.com Wed Sep 20 09:28:52 2017 From: bburke at redhat.com (Bill Burke) Date: Wed, 20 Sep 2017 09:28:52 -0400 Subject: [keycloak-dev] direct exchanges In-Reply-To: References: <70c731c5f0e14e8ab36f11cff1fe940b@FE-MBX1028.de.bosch.com> Message-ID: Its part of token exchange. It is committed. (and tested). On Fri, Sep 15, 2017 at 3:26 AM, Stian Thorgersen wrote: > I'm not quite following if you are planning this as part of the token > exchange services or a new alternative direct grant flow? > > On 14 September 2017 at 16:56, Bill Burke wrote: >> >> I 100% agree that direct/custom grant is not the best way to do it. >> The question is, is it something we should provide as an *additional* >> exchange feature? I think yes. The way I plan to secure it is as >> follows: >> >> * client must be confidential and be secured by a secret or some other >> mechanism configured for that client >> * client must have permission to exchange tokens for target client >> * client must have permission to impersonate users >> * user must be impersonateable. >> >> >> On Thu, Sep 14, 2017 at 3:04 AM, Schuster Sebastian (INST/ESY1) >> wrote: >> > While I do understand the reasons for introducing this feature. I am not >> > convinced a custom grant is the best way to do it. Wouldn't it be better to >> > expect that any external mechanism has some way of proving a user has been >> > authenticated and only being able to get an access token in exchange for >> > that proof (e.g. ID Token, Assertion, whatever). That's more in line with >> > the current standardization efforts on token exchange... >> > >> > Best regards, >> > Sebastian >> > >> > Mit freundlichen Gr??en / Best regards >> > >> > Dr.-Ing. Sebastian Schuster >> > >> > Engineering and Support (INST/ESY1) >> > Bosch Software Innovations GmbH | Sch?neberger Ufer 89-91 | 10785 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.-Ing. Rainer Kallenbach, 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, 13. September 2017 16:52 >> > To: keycloak-dev >> > Subject: [keycloak-dev] direct exchanges >> > >> > We have direct grants where client passes username and creds to obtain a >> > token for that user. We have client credentials grant to get a token for >> > the client itself. >> > >> > What if we had a direct exchange where the client provides user id or >> > username and gets a token for that user? The client does not have to >> > provide user credentials. >> > >> > What is the use case for this? Consider an application that is >> > authenticated via an external mechanism. Consider that this external >> > mechanism does not provide any type of token, it just authenticates a >> > username. This application needs to talk to services secured by Keycloak. >> > So, with this new direct exchange mechanism, the application only needs to >> > have a client account on the Keycloak server >> > to obtain a token for a keycloak user. Another benefit of this is >> > that Keycloak does not need to understand external token formats in >> > order to provide a token to a client that authenticates users by an external >> > mechanism. >> > >> > There's some big security risks for this. If the client's secret is >> > stolen the attacker would be able to mint token for any user. This >> > is somewhat mitigated in two ways: >> > >> > a) If the token is minted for the client, the scope of the token can be >> > limited, i.e. role mappings limited >> > >> > b) if the client is asking for a different audience (a different >> > client) the client can be limited on the audience it can ask for. (we >> > already do this check for client to client token exchange). >> > >> > >> > >> > -- >> > Bill Burke >> > Red Hat >> > _______________________________________________ >> > 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 >> >> >> >> -- >> 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 Wed Sep 20 11:36:42 2017 From: sthorger at redhat.com (Stian Thorgersen) Date: Wed, 20 Sep 2017 17:36:42 +0200 Subject: [keycloak-dev] Promise wrapper for javascript adapter In-Reply-To: References: Message-ID: +1 If we do promises that would be the only useful way to do it. Standard promises wrapped to become wrapped. Have custom promises as default initially. Deprecate and switch to standard after a while and finally remove completely. On 18 Sep 2017 6:16 pm, "Niels Bertram" wrote: Hmm ... I was actally looking at the js libraries (browser and node ones) a short while ago and thought the same thing, why not use a A+ compliant promise [1] instead of the custom thingy. It is hard to follow custom logic when basic concepts exist and are understood. Why not implement standard promises in the main library and write a wrapper for the custom promises. Then mark those for deprecation and retire them in a few releases. I think mongoose did this some time back with a pluggable promise interface [2] to escape callback hell. I think this would improve the adoptability of the adapters given lots of folks don't fully understand OIDC and throw things in the too hard basket as soon as they are given the slightest opportunity - real world experience. Cheers Niels [1] https://promisesaplus.com [2] http://mongoosejs.com/docs/promises.html On 18 Sep. 2017 4:44 am, "Stian Thorgersen" wrote: > I don't like the idea of having a wrapper as it needs updating separately > when anything changes. If it's a different library I believe it'll just be > forgotten about and also be annoying boilerplate to maintain. That's why > I'd rather just have it return a different promise object depending on what > config option is used. There's not that many places internally where > promises objects are used, so we can probably find a reasonable way to do > that. > > That being said I'm wondering if this is actually a case where this is just > another way of doing something that won't actually be used. AFAIK no one > else have asked for this nor have we seen anyone else comment on this > thread. So maybe the best option here is to just leave it as is? > > On 13 September 2017 at 14:31, Raymond DeCampo wrote: > > > I understand the concern about increasing the test surface. > > > > However I don't think that introducing a configuration option and having > > methods that return different objects based on the option will decrease > the > > testing risk. There are places in the keycloak.js where it invokes it's > > own methods and uses the custom promise object, for example: > > > > https://github.com/keycloak/keycloak/blob/b7af96aa4d7daeec6da12ee9326d1c > > 0fdcc4850f/adapters/oidc/js/src/main/resources/keycloak.js#L128-L131 > > > > > > kc.login(options).success(function () { > > initPromise.setSuccess(); > > }).error(function () { > > initPromise.setError(); > > }); > > > > > > So these places would have to change based on the configuration option > and > > I think it will become a bigger problem. > > > > What if instead we add a method on the Keycloak object which returns a > > wrapper instance using Promises and keep everything in the one > keycloak.js > > file? So clients could do: > > > > var keycloak = new Keycloak().promiseWrapper(); > > > > keycloak.init().then(function() { ... }); > > > > > > And everything is in the one file? > > > > > > Although let me make one more pitch on the merits of my original > > suggestion: > > > > > > 1. No changes to keycloak.js => less risk of breaking something that > > already works > > 2. The KeycloakPromise implementation delegates to the keycloak.js > > > implementation which means that fixes to keycloak.js automatically > > propogate. > > 3. The KeycloakPromise implementation is a wrapper which means it only > > > needs to be changed if there is a change to the keycloak.js API, e.g. > a new > > method or a new argument to a method (but not a new option on an > existing > > argument) > > 4. I think it will be clearer to document the interfaces for the end > > > user but of course that is a matter of opinion. > > > > > > > > On Tue, Sep 12, 2017 at 11:28 PM, Stian Thorgersen > > wrote: > > > >> I can see how it would be nice. I'm a bit worried that the separate > >> javascript file would simply get out of date and it would also need > >> separate testing. We're already lacking a bit on testing of the JS > adapter > >> in the first place and this would be yet another thing to test. Is > there a > >> way we could simply have a config option in the current javascript > adapter > >> that allows setting what promise to return? That way it's probably just > a > >> few lines in keycloak.js where it's creating the promise objects to > switch > >> between the two? > >> > >> On 5 September 2017 at 05:58, Raymond DeCampo wrote: > >> > >>> First, if I were to integrate Promise support into the Keycloak, I > would > >>> be leaving the current javascript adapter as is. This would be an > >>> extension in a separate javascript file so that only developers who are > >>> interested would get the Promise interface. Existing code using the > >>> current adapter would be unaffected. The new code would be a wrapper > >>> around the existing code so that maintenance would only be required if > the > >>> javascript adapter API changes. > >>> > >>> In terms of browser support, caniuse.com[1] indicates that Promise has > >>> broad support; only IE 11 and Opera Mini fail to support Promise. > However > >>> polyfills are available to provide support. > >>> > >>> As far as the advantages, the main ones as I see it are: 1) using the > >>> standard promise API makes it easier for developers new to the > library; 2) > >>> using the standard promise API makes the library more interoperable > with > >>> other libraries; and 3) ES6 Promise objects are chainable making > sequences > >>> of asynchronous calls cleaner to code. > >>> > >>> I think the MDN page on Using Promises[2] probably makes a better > >>> argument for than I'll be able to here. But the main thrust is that > >>> chaining makes it so it is not necessary to have so many nested > functions. > >>> > >>> For example, suppose I am writing a javascript client for a REST API > >>> protected by Keycloak. Since the built-in fetch() method returns a > Promise > >>> with ES6 Promises I can write: > >>> > >>> // assume authz.updateToken() returns an ES6 Promise > >>> authz.updateToken(5).then((token) => { > >>> return fetch(this.ENDPOINT, { > >>> redirect: 'error', > >>> headers: { "Authorization": "Bearer " + token } > >>> }); > >>> }).then((response) => { > >>> showResult(response.text()); > >>> }).catch((error) => { > >>> displayError(error); > >>> }); > >>> } > >>> > >>> Since everything is standard, any JS developer would understand the > >>> code. Since both libraries use Promise, I can chain the promises > without > >>> nesting functions. And since both libraries use Promise, I can use > catch() > >>> at the end for unified error handling whether the error comes from the > >>> Keycloak adapter or from the call to fetch(). > >>> > >>> > >>> [1] http://caniuse.com/#search=Promise > >>> [2] https://developer.mozilla.org/en-US/docs/Web/JavaScript/ > >>> Guide/Using_promises > >>> > >>> > >>> On Tue, Sep 5, 2017 at 6:18 AM, Stian Thorgersen > >>> wrote: > >>> > >>>> I don't know much about ES6 native Promises. Can you give me some > >>>> details about it? What browser support it? What are the benefits of > using > >>>> that instead of our howegrown approach? Etc. > >>>> > >>>> On 4 September 2017 at 20:36, Raymond DeCampo > wrote: > >>>> > >>>>> Hello all, > >>>>> > >>>>> I create a wrapper around the javascript adapter which uses ES6 > native > >>>>> Promises. (https://github.com/RayDeCampo/keycloak-promise). > >>>>> > >>>>> If you are interested, I can re-package it for inclusion in Keycloak > >>>>> and > >>>>> create a pull request on GitHub. If you have a different process for > >>>>> contributions, let me know. > >>>>> > >>>>> If you are not interested, no hard feelings. > >>>>> > >>>>> Thanks, > >>>>> Ray > >>>>> _______________________________________________ > >>>>> 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 thomas.darimont at googlemail.com Thu Sep 21 09:45:19 2017 From: thomas.darimont at googlemail.com (Thomas Darimont) Date: Thu, 21 Sep 2017 15:45:19 +0200 Subject: [keycloak-dev] Passay and PasswordPolicy Message-ID: Hello, I just stumbled upon passay [0] which is comprehensive library for validating passwords against rule based policies and wanted to share my thoughts. Perhaps some of the contained rules [1] might be valuable additions to the existing password policies. One thing I particularly like is the differentiation between positive and negative matching rules which make it quite explicit and easy to express rules. E.g. instead of crafting a regex like "regex('^[^,&]+$')" to prohibit the use of characters like "," and "&", one could simply write: "illegalCharacters(',&')" Perhaps someone could also come up with a PassayPasswordPolicy provider which can be feed with a passay rule file (+ some Keycloak adapters to support Password history, blacklists) to validate a password. Cheers, Thomas [0] http://www.passay.org/ [1] http://www.passay.org/reference/ From bburke at redhat.com Thu Sep 21 16:05:51 2017 From: bburke at redhat.com (Bill Burke) Date: Thu, 21 Sep 2017 16:05:51 -0400 Subject: [keycloak-dev] external token exchange - feedback needed Message-ID: I'm almost done implementing external token exchange where you can provide an external OIDC token and exchange it for a Keycloak one. Need some feedback though. * first broker flow and post broker flows won't be executed. Can't, its a non-browser flow. * mappers are run. * logout will not logout broker session * If duplicate emails exist, abort, 403 * If duplicate username exists, abort, 403. The feedback I need is on duplicates. We might have the case where username is unique across different realms. Should I have a switch that will use existing user? Maybe an additional switch to not create a link? Maybe I should have an exchange flow? -- Bill Burke Red Hat From ray at decampo.org Fri Sep 22 07:44:37 2017 From: ray at decampo.org (Raymond DeCampo) Date: Fri, 22 Sep 2017 07:44:37 -0400 Subject: [keycloak-dev] Promise wrapper for javascript adapter In-Reply-To: References: Message-ID: So the next step is "deprecate and replace with standard"? So you would be looking for a pull request where keycloak.js is modified to return standard native Promises and the existing keycloak.js is moved to something like keycloak-legacy.js? On Wed, Sep 20, 2017 at 11:36 AM, Stian Thorgersen wrote: > +1 If we do promises that would be the only useful way to do it. Standard > promises wrapped to become wrapped. Have custom promises as default > initially. Deprecate and switch to standard after a while and finally > remove completely. > > > On 18 Sep 2017 6:16 pm, "Niels Bertram" wrote: > > Hmm ... I was actally looking at the js libraries (browser and node ones) > a short while ago and thought the same thing, why not use a A+ compliant > promise [1] instead of the custom thingy. It is hard to follow custom logic > when basic concepts exist and are understood. > > Why not implement standard promises in the main library and write a > wrapper for the custom promises. Then mark those for deprecation and retire > them in a few releases. I think mongoose did this some time back with a > pluggable promise interface [2] to escape callback hell. > > I think this would improve the adoptability of the adapters given lots of > folks don't fully understand OIDC and throw things in the too hard basket > as soon as they are given the slightest opportunity - real world > experience. > > Cheers Niels > > [1] https://promisesaplus.com > [2] http://mongoosejs.com/docs/promises.html > > On 18 Sep. 2017 4:44 am, "Stian Thorgersen" wrote: > >> I don't like the idea of having a wrapper as it needs updating separately >> when anything changes. If it's a different library I believe it'll just be >> forgotten about and also be annoying boilerplate to maintain. That's why >> I'd rather just have it return a different promise object depending on >> what >> config option is used. There's not that many places internally where >> promises objects are used, so we can probably find a reasonable way to do >> that. >> >> That being said I'm wondering if this is actually a case where this is >> just >> another way of doing something that won't actually be used. AFAIK no one >> else have asked for this nor have we seen anyone else comment on this >> thread. So maybe the best option here is to just leave it as is? >> >> On 13 September 2017 at 14:31, Raymond DeCampo wrote: >> >> > I understand the concern about increasing the test surface. >> > >> > However I don't think that introducing a configuration option and having >> > methods that return different objects based on the option will decrease >> the >> > testing risk. There are places in the keycloak.js where it invokes it's >> > own methods and uses the custom promise object, for example: >> > >> > https://github.com/keycloak/keycloak/blob/b7af96aa4d7daeec6d >> a12ee9326d1c >> > 0fdcc4850f/adapters/oidc/js/src/main/resources/keycloak.js#L128-L131 >> > >> > >> > kc.login(options).success(function () { >> > initPromise.setSuccess(); >> > }).error(function () { >> > initPromise.setError(); >> > }); >> > >> > >> > So these places would have to change based on the configuration option >> and >> > I think it will become a bigger problem. >> > >> > What if instead we add a method on the Keycloak object which returns a >> > wrapper instance using Promises and keep everything in the one >> keycloak.js >> > file? So clients could do: >> > >> > var keycloak = new Keycloak().promiseWrapper(); >> > >> > keycloak.init().then(function() { ... }); >> > >> > >> > And everything is in the one file? >> > >> > >> > Although let me make one more pitch on the merits of my original >> > suggestion: >> > >> > >> > 1. No changes to keycloak.js => less risk of breaking something that >> > already works >> > 2. The KeycloakPromise implementation delegates to the keycloak.js >> >> > implementation which means that fixes to keycloak.js automatically >> > propogate. >> > 3. The KeycloakPromise implementation is a wrapper which means it >> only >> >> > needs to be changed if there is a change to the keycloak.js API, >> e.g. a new >> > method or a new argument to a method (but not a new option on an >> existing >> > argument) >> > 4. I think it will be clearer to document the interfaces for the end >> >> > user but of course that is a matter of opinion. >> > >> > >> > >> > On Tue, Sep 12, 2017 at 11:28 PM, Stian Thorgersen > > >> > wrote: >> > >> >> I can see how it would be nice. I'm a bit worried that the separate >> >> javascript file would simply get out of date and it would also need >> >> separate testing. We're already lacking a bit on testing of the JS >> adapter >> >> in the first place and this would be yet another thing to test. Is >> there a >> >> way we could simply have a config option in the current javascript >> adapter >> >> that allows setting what promise to return? That way it's probably >> just a >> >> few lines in keycloak.js where it's creating the promise objects to >> switch >> >> between the two? >> >> >> >> On 5 September 2017 at 05:58, Raymond DeCampo wrote: >> >> >> >>> First, if I were to integrate Promise support into the Keycloak, I >> would >> >>> be leaving the current javascript adapter as is. This would be an >> >>> extension in a separate javascript file so that only developers who >> are >> >>> interested would get the Promise interface. Existing code using the >> >>> current adapter would be unaffected. The new code would be a wrapper >> >>> around the existing code so that maintenance would only be required >> if the >> >>> javascript adapter API changes. >> >>> >> >>> In terms of browser support, caniuse.com[1] indicates that Promise >> has >> >>> broad support; only IE 11 and Opera Mini fail to support Promise. >> However >> >>> polyfills are available to provide support. >> >>> >> >>> As far as the advantages, the main ones as I see it are: 1) using the >> >>> standard promise API makes it easier for developers new to the >> library; 2) >> >>> using the standard promise API makes the library more interoperable >> with >> >>> other libraries; and 3) ES6 Promise objects are chainable making >> sequences >> >>> of asynchronous calls cleaner to code. >> >>> >> >>> I think the MDN page on Using Promises[2] probably makes a better >> >>> argument for than I'll be able to here. But the main thrust is that >> >>> chaining makes it so it is not necessary to have so many nested >> functions. >> >>> >> >>> For example, suppose I am writing a javascript client for a REST API >> >>> protected by Keycloak. Since the built-in fetch() method returns a >> Promise >> >>> with ES6 Promises I can write: >> >>> >> >>> // assume authz.updateToken() returns an ES6 Promise >> >>> authz.updateToken(5).then((token) => { >> >>> return fetch(this.ENDPOINT, { >> >>> redirect: 'error', >> >>> headers: { "Authorization": "Bearer " + token } >> >>> }); >> >>> }).then((response) => { >> >>> showResult(response.text()); >> >>> }).catch((error) => { >> >>> displayError(error); >> >>> }); >> >>> } >> >>> >> >>> Since everything is standard, any JS developer would understand the >> >>> code. Since both libraries use Promise, I can chain the promises >> without >> >>> nesting functions. And since both libraries use Promise, I can use >> catch() >> >>> at the end for unified error handling whether the error comes from the >> >>> Keycloak adapter or from the call to fetch(). >> >>> >> >>> >> >>> [1] http://caniuse.com/#search=Promise >> >>> [2] https://developer.mozilla.org/en-US/docs/Web/JavaScript/ >> >>> Guide/Using_promises >> >>> >> >>> >> >>> On Tue, Sep 5, 2017 at 6:18 AM, Stian Thorgersen > > >> >>> wrote: >> >>> >> >>>> I don't know much about ES6 native Promises. Can you give me some >> >>>> details about it? What browser support it? What are the benefits of >> using >> >>>> that instead of our howegrown approach? Etc. >> >>>> >> >>>> On 4 September 2017 at 20:36, Raymond DeCampo >> wrote: >> >>>> >> >>>>> Hello all, >> >>>>> >> >>>>> I create a wrapper around the javascript adapter which uses ES6 >> native >> >>>>> Promises. (https://github.com/RayDeCampo/keycloak-promise). >> >>>>> >> >>>>> If you are interested, I can re-package it for inclusion in Keycloak >> >>>>> and >> >>>>> create a pull request on GitHub. If you have a different process >> for >> >>>>> contributions, let me know. >> >>>>> >> >>>>> If you are not interested, no hard feelings. >> >>>>> >> >>>>> Thanks, >> >>>>> Ray >> >>>>> _______________________________________________ >> >>>>> 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 Fri Sep 22 10:47:42 2017 From: bburke at redhat.com (Bill Burke) Date: Fri, 22 Sep 2017 10:47:42 -0400 Subject: [keycloak-dev] external token exchange - feedback needed In-Reply-To: References: Message-ID: Was thinking about this more... I'll have a switch "Allow Token Exchange" I'll also define an import policy: * EXISTING-ONLY - must match existing account. No link created. No import. * IMPORT - may match existing account. Link is created/updated * IMPORT-ONLY - must not match existing account unless previously linked. Link is created/updated. * UNIQUE_IMPORT - must not match existing account unless previously imported. must create a username that is specific to the provider. Link is created/updated. For all above policies, realm duplicate email policy applies. On Thu, Sep 21, 2017 at 4:05 PM, Bill Burke wrote: > I'm almost done implementing external token exchange where you can > provide an external OIDC token and exchange it for a Keycloak one. > Need some feedback though. > > * first broker flow and post broker flows won't be executed. Can't, > its a non-browser flow. > * mappers are run. > * logout will not logout broker session > * If duplicate emails exist, abort, 403 > * If duplicate username exists, abort, 403. > > The feedback I need is on duplicates. We might have the case where > username is unique across different realms. Should I have a switch > that will use existing user? Maybe an additional switch to not create > a link? Maybe I should have an exchange flow? > > > -- > Bill Burke > Red Hat -- Bill Burke Red Hat From mposolda at redhat.com Fri Sep 22 10:48:47 2017 From: mposolda at redhat.com (Marek Posolda) Date: Fri, 22 Sep 2017 16:48:47 +0200 Subject: [keycloak-dev] external token exchange - feedback needed In-Reply-To: References: Message-ID: Exchange flow provides most flexibility and can provide the other two options automatically in OOTB authenticators though? So my vote is for this. Marek On 21/09/17 22:05, Bill Burke wrote: > I'm almost done implementing external token exchange where you can > provide an external OIDC token and exchange it for a Keycloak one. > Need some feedback though. > > * first broker flow and post broker flows won't be executed. Can't, > its a non-browser flow. > * mappers are run. > * logout will not logout broker session > * If duplicate emails exist, abort, 403 > * If duplicate username exists, abort, 403. > > The feedback I need is on duplicates. We might have the case where > username is unique across different realms. Should I have a switch > that will use existing user? Maybe an additional switch to not create > a link? Maybe I should have an exchange flow? > > From thomas.darimont at googlemail.com Fri Sep 22 15:46:20 2017 From: thomas.darimont at googlemail.com (Thomas Darimont) Date: Fri, 22 Sep 2017 21:46:20 +0200 Subject: [keycloak-dev] Script based OIDC Protocol Mapper Message-ID: Hi, it has been a while since I proposed this feature [0], but I finally managed to get this done [1]. I needed this to be able to dynamically compute a token claim based on user attributes with a javascript expression. When "Script Mapper" is selected in the "Create New Mapper" dialog, then the following script is used as a default value: /** * Available variables: * user - the current user * realm - the current realm * token - the current token * userSession - the current userSession */ //insert your code here... [0] https://issues.jboss.org/browse/KEYCLOAK-3599 [1] https://github.com/keycloak/keycloak/pull/4495 Cheers, Thomas From Sebastian.Schuster at bosch-si.com Mon Sep 25 03:22:15 2017 From: Sebastian.Schuster at bosch-si.com (Schuster Sebastian (INST/ESY1)) Date: Mon, 25 Sep 2017 07:22:15 +0000 Subject: [keycloak-dev] external token exchange - feedback needed In-Reply-To: References: Message-ID: Hi Bill, Your token exchange approach looks good to me. I still have a few questions: What claim is used to do the matching? Is it email if not linked and iss/sub otherwise? What is the difference between IMPORT_ONLY and UNIQUE_IMPORT? What usernames would be created? OIDC standard claims don't seem to contain something that?s useful as a username.. Thanks and 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.-Ing. Rainer Kallenbach, 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: Freitag, 22. September 2017 16:48 To: keycloak-dev Subject: Re: [keycloak-dev] external token exchange - feedback needed Was thinking about this more... I'll have a switch "Allow Token Exchange" I'll also define an import policy: * EXISTING-ONLY - must match existing account. No link created. No import. * IMPORT - may match existing account. Link is created/updated * IMPORT-ONLY - must not match existing account unless previously linked. Link is created/updated. * UNIQUE_IMPORT - must not match existing account unless previously imported. must create a username that is specific to the provider. Link is created/updated. For all above policies, realm duplicate email policy applies. On Thu, Sep 21, 2017 at 4:05 PM, Bill Burke wrote: > I'm almost done implementing external token exchange where you can > provide an external OIDC token and exchange it for a Keycloak one. > Need some feedback though. > > * first broker flow and post broker flows won't be executed. Can't, > its a non-browser flow. > * mappers are run. > * logout will not logout broker session > * If duplicate emails exist, abort, 403 > * If duplicate username exists, abort, 403. > > The feedback I need is on duplicates. We might have the case where > username is unique across different realms. Should I have a switch > that will use existing user? Maybe an additional switch to not create > a link? Maybe I should have an exchange flow? > > > -- > 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 Christian.Kayssner at muthpartners.de Mon Sep 25 05:23:35 2017 From: Christian.Kayssner at muthpartners.de (Christian Kayssner) Date: Mon, 25 Sep 2017 09:23:35 +0000 Subject: [keycloak-dev] Question about a problem with Derivation and/or Deployment and/or (at the end) a 'NoClassDefFoundError'. Message-ID: Hello, I have an problem in the deployment process. For an higher security context I have to intervene in the original username/password functionality. I searched and found the original class 'org.keycloak.authentication.authenticators.browser.UsernamePasswordFormFactory'. For this mail, I reduced the derivation and manipulation to a minimum and choose the 'secret-example' for deployment. The derivated factory class get the name 'org.example.derivations.MyUsernamePasswordFormFactory' and would be activated next to the existing factory in the file 'org.keycloak.examples.authenticator.SecretQuestionAuthenticatorFactory'. I take the secret-question example because it closest to mine. But when I deploy the secret-example I get the 'NoClassDefFoundError' (see below). I checked the java visibilities (nothing private, protected or final). The core class reside in the artefactId 'keycloak-services', and the secret-example pom has a direct dependency entry. Eclipse (the maven-plugin) is satisfied. Therefore I found no reason for this exception. Does anyone have an idea why the *deployment* fails (and which party (Maven, Wildfly or Keycloak) is not amused)? Have I missed note something? Or is a derivation, per se, not desired?? If someone wants to retrace, he/she needs: * a current 64bit linux with approximately 420MB free space with a directory of your choice, * with a running maven environment * and *without* running wildfly/keycloak system. Next, you: * download the demo version in your/this direcory wget -r https://downloads.jboss.org/keycloak/3.2.1.Final/keycloak-demo-3.2.1.Final.tar.gz * expand this archive, tar -xzf keycloak-demo-3.2.1.Final.tar.gz * save the follow patch (all content between and ) file and execute it, patch -p 0 < NameOfYourSavedPatchFile * start the example server and save the terminal-log, keycloak-demo-3.2.1.Final/keycloak/bin/standalone.sh | tee keycloak-demo-3.2.1.Final.log * open a new terminal, * go to the secret example direcory and cd keycloak-demo-3.2.1.Final/examples/providers/authenticator * deploy it. mvn clean install wildfly:deploy * will see the 'NoClassDefFoundError' exception! Best regards Christian Kayssner -- G. Muth Partners GmbH Borsigstra?e 32 D - 65205 Wiesbaden HRB 10196 Amtsgericht Wiesbaden Gesch?ftsf?hrer: Klaus Gockel / Oliver M?chold Tel. : +49(0)6122/5981-0 FAX. : +49(0)6122/5981-50 eMail: christian.kayssner at muthpartners.de www : www.muthpartners.de -- : : : [0m [0m17:39:08,074 INFO [org.jboss.as.repository] (management-handler-thread - 4) WFLYDR0001: Content added at location /path/to/your/own/playground/keycloak-demo-3.2.1.Final/keycloak/standalone/data/content/e4/95f32235bb131df52f479a09827186a3265788/content [0m [0m17:39:08,082 INFO [org.jboss.as.server.deployment] (MSC service thread 1-2) WFLYSRV0027: Starting deployment of "authenticator-required-action-example.jar" (runtime-name: "authenticator-required-action-example.jar") [0m [0m17:39:08,322 INFO [org.keycloak.subsystem.server.extension.KeycloakProviderDeploymentProcessor] (MSC service thread 1-1) Deploying Keycloak provider: authenticator-required-action-example.jar [0m [33m17:39:08,335 WARN [org.jboss.modules] (MSC service thread 1-1) Failed to define class org.example.derivations.MyUsernamePasswordFormFactory in Module "deployment.authenticator-required-action-example.jar:main" from Service Module Loader: java.lang.NoClassDefFoundError: Failed to link org/example/derivations/MyUsernamePasswordFormFactory (Module "deployment.authenticator-required-action-example.jar:main" from Service Module Loader): org/keycloak/authentication/authenticators/browser/UsernamePasswordFormFactory at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) at java.lang.reflect.Constructor.newInstance(Constructor.java:423) at org.jboss.modules.ModuleClassLoader.defineClass(ModuleClassLoader.java:446) at org.jboss.modules.ModuleClassLoader.loadClassLocal(ModuleClassLoader.java:274) at org.jboss.modules.ModuleClassLoader$1.loadClassLocal(ModuleClassLoader.java:78) at org.jboss.modules.Module.loadModuleClass(Module.java:605) at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:190) at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:363) at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:351) at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:93) at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:348) at java.util.ServiceLoader$LazyIterator.nextService(ServiceLoader.java:370) at java.util.ServiceLoader$LazyIterator.next(ServiceLoader.java:404) at java.util.ServiceLoader$1.next(ServiceLoader.java:480) at org.keycloak.provider.DefaultProviderLoader.load(DefaultProviderLoader.java:47) at org.keycloak.provider.ProviderManager.load(ProviderManager.java:93) at org.keycloak.services.DefaultKeycloakSessionFactory.loadFactories(DefaultKeycloakSessionFactory.java:208) at org.keycloak.services.DefaultKeycloakSessionFactory.deploy(DefaultKeycloakSessionFactory.java:114) at org.keycloak.provider.ProviderManagerRegistry.deploy(ProviderManagerRegistry.java:42) at org.keycloak.subsystem.server.extension.KeycloakProviderDeploymentProcessor.deploy(KeycloakProviderDeploymentProcessor.java:54) at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:147) at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) at java.lang.Thread.run(Thread.java:748) [0m [31m17:39:08,336 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-1) MSC000001: Failed to start service jboss.deployment.unit."authenticator-required-action-example.jar".POST_MODULE: org.jboss.msc.service.StartException in service jboss.deployment.unit."authenticator-required-action-example.jar".POST_MODULE: WFLYSRV0153: Failed to process phase POST_MODULE of deployment "authenticator-required-action-example.jar" at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:154) at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) at java.lang.Thread.run(Thread.java:748) Caused by: java.lang.NoClassDefFoundError: Failed to link org/example/derivations/MyUsernamePasswordFormFactory (Module "deployment.authenticator-required-action-example.jar:main" from Service Module Loader): org/keycloak/authentication/authenticators/browser/UsernamePasswordFormFactory at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) at java.lang.reflect.Constructor.newInstance(Constructor.java:423) at org.jboss.modules.ModuleClassLoader.defineClass(ModuleClassLoader.java:446) at org.jboss.modules.ModuleClassLoader.loadClassLocal(ModuleClassLoader.java:274) at org.jboss.modules.ModuleClassLoader$1.loadClassLocal(ModuleClassLoader.java:78) at org.jboss.modules.Module.loadModuleClass(Module.java:605) at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:190) at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:363) at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:351) at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:93) at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:348) at java.util.ServiceLoader$LazyIterator.nextService(ServiceLoader.java:370) at java.util.ServiceLoader$LazyIterator.next(ServiceLoader.java:404) at java.util.ServiceLoader$1.next(ServiceLoader.java:480) at org.keycloak.provider.DefaultProviderLoader.load(DefaultProviderLoader.java:47) at org.keycloak.provider.ProviderManager.load(ProviderManager.java:93) at org.keycloak.services.DefaultKeycloakSessionFactory.loadFactories(DefaultKeycloakSessionFactory.java:208) at org.keycloak.services.DefaultKeycloakSessionFactory.deploy(DefaultKeycloakSessionFactory.java:114) at org.keycloak.provider.ProviderManagerRegistry.deploy(ProviderManagerRegistry.java:42) at org.keycloak.subsystem.server.extension.KeycloakProviderDeploymentProcessor.deploy(KeycloakProviderDeploymentProcessor.java:54) at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:147) ... 5 more [0m [31m17:39:08,339 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 4) WFLYCTL0013: Operation ("add") failed - address: ([("deployment" => "authenticator-required-action-example.jar")]) - failure description: {"WFLYCTL0080: Failed services" => {"jboss.deployment.unit.\"authenticator-required-action-example.jar\".POST_MODULE" => "org.jboss.msc.service.StartException in service jboss.deployment.unit.\"authenticator-required-action-example.jar\".POST_MODULE: WFLYSRV0153: Failed to process phase POST_MODULE of deployment \"authenticator-required-action-example.jar\" Caused by: java.lang.NoClassDefFoundError: Failed to link org/example/derivations/MyUsernamePasswordFormFactory (Module \"deployment.authenticator-required-action-example.jar:main\" from Service Module Loader): org/keycloak/authentication/authenticators/browser/UsernamePasswordFormFactory"}} [0m [31m17:39:08,341 ERROR [org.jboss.as.server] (management-handler-thread - 4) WFLYSRV0021: Deploy of deployment "authenticator-required-action-example.jar" was rolled back with the following failure message: {"WFLYCTL0080: Failed services" => {"jboss.deployment.unit.\"authenticator-required-action-example.jar\".POST_MODULE" => "org.jboss.msc.service.StartException in service jboss.deployment.unit.\"authenticator-required-action-example.jar\".POST_MODULE: WFLYSRV0153: Failed to process phase POST_MODULE of deployment \"authenticator-required-action-example.jar\" Caused by: java.lang.NoClassDefFoundError: Failed to link org/example/derivations/MyUsernamePasswordFormFactory (Module \"deployment.authenticator-required-action-example.jar:main\" from Service Module Loader): org/keycloak/authentication/authenticators/browser/UsernamePasswordFormFactory"}} [0m [0m17:39:08,356 INFO [org.jboss.as.server.deployment] (MSC service thread 1-5) WFLYSRV0028: Stopped deployment authenticator-required-action-example.jar (runtime-name: authenticator-required-action-example.jar) in 14ms [0m [0m17:39:08,357 INFO [org.jboss.as.controller] (management-handler-thread - 4) WFLYCTL0183: Service status report WFLYCTL0186: Services which failed to start: service jboss.deployment.unit."authenticator-required-action-example.jar".POST_MODULE [0m -- diff -Naur keycloak-demo-3.2.1.Final/examples/providers/authenticator/src/main/java/org/example/derivations/MyUsernamePasswordFormFactory.java keycloak-demo-3.2.1.Final-modified/examples/providers/authenticator/src/main/java/org/example/derivations/MyUsernamePasswordFormFactory.java --- keycloak-demo-3.2.1.Final/examples/providers/authenticator/src/main/java/org/example/derivations/MyUsernamePasswordFormFactory.java 1970-01-01 00:00:00.000000000 +0000 +++ keycloak-demo-3.2.1.Final-modified/examples/providers/authenticator/src/main/java/org/example/derivations/MyUsernamePasswordFormFactory.java 2017-09-20 11:37:09.425674263 +0000 @@ -0,0 +1,54 @@ +/* + * Copyright 2016 Red Hat, Inc. and/or its affiliates + * and other contributors as indicated by the @author tags. + * + * Licensed under the Apache License, Version 2.0 (the "License"); + * you may not use this file except in compliance with the License. + * You may obtain a copy of the License at + * + * http://www.apache.org/licenses/LICENSE-2.0 + * + * Unless required by applicable law or agreed to in writing, software + * distributed under the License is distributed on an "AS IS" BASIS, + * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. + * See the License for the specific language governing permissions and + * limitations under the License. + */ + +package org.example.derivations; + +import org.keycloak.authentication.authenticators.browser.UsernamePasswordFormFactory; + +/** + */ +public// +class MyUsernamePasswordFormFactory// + extends UsernamePasswordFormFactory// +{ + public// + static// + final// + String PROVIDER_ID = "my-auth-username-password-form"; + + /** + * {@inheritDoc} + */ + @Override + public// + String getId()// + { + return MyUsernamePasswordFormFactory.PROVIDER_ID; + } + + /** + * {@inheritDoc} + * + * @return The heading for the (browser) page to explain the necessary inputs. + */ + @Override + public// + String getDisplayType()// + { + return "My Username Password Form"; + } +} diff -Naur keycloak-demo-3.2.1.Final/examples/providers/authenticator/src/main/resources/META-INF/services/org.keycloak.authentication.AuthenticatorFactory keycloak-demo-3.2.1.Final-modified/examples/providers/authenticator/src/main/resources/META-INF/services/org.keycloak.authentication.AuthenticatorFactory --- keycloak-demo-3.2.1.Final/examples/providers/authenticator/src/main/resources/META-INF/services/org.keycloak.authentication.AuthenticatorFactory 2017-07-21 11:31:26.000000000 +0000 +++ keycloak-demo-3.2.1.Final-modified/examples/providers/authenticator/src/main/resources/META-INF/services/org.keycloak.authentication.AuthenticatorFactory 2017-09-20 11:43:31.354018042 +0000 @@ -15,4 +15,5 @@ # limitations under the License. # -org.keycloak.examples.authenticator.SecretQuestionAuthenticatorFactory \ No newline at end of file +org.keycloak.examples.authenticator.SecretQuestionAuthenticatorFactory +org.example.derivations.MyUsernamePasswordFormFactory \ No newline at end of file diff -Naur keycloak-demo-3.2.1.Final/keycloak/modules/layers.conf keycloak-demo-3.2.1.Final-modified/keycloak/modules/layers.conf --- keycloak-demo-3.2.1.Final/keycloak/modules/layers.conf 1970-01-01 00:00:00.000000000 +0000 +++ keycloak-demo-3.2.1.Final-modified/keycloak/modules/layers.conf 2017-07-21 09:11:58.000000000 +0000 @@ -0,0 +1 @@ +layers=keycloak \ No newline at end of file From sthorger at redhat.com Mon Sep 25 07:36:41 2017 From: sthorger at redhat.com (Stian Thorgersen) Date: Mon, 25 Sep 2017 13:36:41 +0200 Subject: [keycloak-dev] Promise wrapper for javascript adapter In-Reply-To: References: Message-ID: No, I'd be looking for a PR where keycloak.js uses standard promises internally, but will return a wrapper for the promises that uses the legacy api. There will be a config option that can be enabled to return standard promises instead. After a few releases we make it return standard promises, then finally after a few more releases we remove the legacy wrapper completely. On 22 September 2017 at 13:44, Raymond DeCampo wrote: > So the next step is "deprecate and replace with standard"? So you would > be looking for a pull request where keycloak.js is modified to return > standard native Promises and the existing keycloak.js is moved to something > like keycloak-legacy.js? > > On Wed, Sep 20, 2017 at 11:36 AM, Stian Thorgersen > wrote: > >> +1 If we do promises that would be the only useful way to do it. Standard >> promises wrapped to become wrapped. Have custom promises as default >> initially. Deprecate and switch to standard after a while and finally >> remove completely. >> >> >> On 18 Sep 2017 6:16 pm, "Niels Bertram" wrote: >> >> Hmm ... I was actally looking at the js libraries (browser and node ones) >> a short while ago and thought the same thing, why not use a A+ compliant >> promise [1] instead of the custom thingy. It is hard to follow custom logic >> when basic concepts exist and are understood. >> >> Why not implement standard promises in the main library and write a >> wrapper for the custom promises. Then mark those for deprecation and retire >> them in a few releases. I think mongoose did this some time back with a >> pluggable promise interface [2] to escape callback hell. >> >> I think this would improve the adoptability of the adapters given lots of >> folks don't fully understand OIDC and throw things in the too hard basket >> as soon as they are given the slightest opportunity - real world >> experience. >> >> Cheers Niels >> >> [1] https://promisesaplus.com >> [2] http://mongoosejs.com/docs/promises.html >> >> On 18 Sep. 2017 4:44 am, "Stian Thorgersen" wrote: >> >>> I don't like the idea of having a wrapper as it needs updating separately >>> when anything changes. If it's a different library I believe it'll just >>> be >>> forgotten about and also be annoying boilerplate to maintain. That's why >>> I'd rather just have it return a different promise object depending on >>> what >>> config option is used. There's not that many places internally where >>> promises objects are used, so we can probably find a reasonable way to do >>> that. >>> >>> That being said I'm wondering if this is actually a case where this is >>> just >>> another way of doing something that won't actually be used. AFAIK no one >>> else have asked for this nor have we seen anyone else comment on this >>> thread. So maybe the best option here is to just leave it as is? >>> >>> On 13 September 2017 at 14:31, Raymond DeCampo wrote: >>> >>> > I understand the concern about increasing the test surface. >>> > >>> > However I don't think that introducing a configuration option and >>> having >>> > methods that return different objects based on the option will >>> decrease the >>> > testing risk. There are places in the keycloak.js where it invokes >>> it's >>> > own methods and uses the custom promise object, for example: >>> > >>> > https://github.com/keycloak/keycloak/blob/b7af96aa4d7daeec6d >>> a12ee9326d1c >>> > 0fdcc4850f/adapters/oidc/js/src/main/resources/keycloak.js#L128-L131 >>> > >>> > >>> > kc.login(options).success(function () { >>> > initPromise.setSuccess(); >>> > }).error(function () { >>> > initPromise.setError(); >>> > }); >>> > >>> > >>> > So these places would have to change based on the configuration option >>> and >>> > I think it will become a bigger problem. >>> > >>> > What if instead we add a method on the Keycloak object which returns a >>> > wrapper instance using Promises and keep everything in the one >>> keycloak.js >>> > file? So clients could do: >>> > >>> > var keycloak = new Keycloak().promiseWrapper(); >>> > >>> > keycloak.init().then(function() { ... }); >>> > >>> > >>> > And everything is in the one file? >>> > >>> > >>> > Although let me make one more pitch on the merits of my original >>> > suggestion: >>> > >>> > >>> > 1. No changes to keycloak.js => less risk of breaking something that >>> > already works >>> > 2. The KeycloakPromise implementation delegates to the keycloak.js >>> >>> > implementation which means that fixes to keycloak.js automatically >>> > propogate. >>> > 3. The KeycloakPromise implementation is a wrapper which means it >>> only >>> >>> > needs to be changed if there is a change to the keycloak.js API, >>> e.g. a new >>> > method or a new argument to a method (but not a new option on an >>> existing >>> > argument) >>> > 4. I think it will be clearer to document the interfaces for the end >>> >>> > user but of course that is a matter of opinion. >>> > >>> > >>> > >>> > On Tue, Sep 12, 2017 at 11:28 PM, Stian Thorgersen < >>> sthorger at redhat.com> >>> > wrote: >>> > >>> >> I can see how it would be nice. I'm a bit worried that the separate >>> >> javascript file would simply get out of date and it would also need >>> >> separate testing. We're already lacking a bit on testing of the JS >>> adapter >>> >> in the first place and this would be yet another thing to test. Is >>> there a >>> >> way we could simply have a config option in the current javascript >>> adapter >>> >> that allows setting what promise to return? That way it's probably >>> just a >>> >> few lines in keycloak.js where it's creating the promise objects to >>> switch >>> >> between the two? >>> >> >>> >> On 5 September 2017 at 05:58, Raymond DeCampo >>> wrote: >>> >> >>> >>> First, if I were to integrate Promise support into the Keycloak, I >>> would >>> >>> be leaving the current javascript adapter as is. This would be an >>> >>> extension in a separate javascript file so that only developers who >>> are >>> >>> interested would get the Promise interface. Existing code using the >>> >>> current adapter would be unaffected. The new code would be a wrapper >>> >>> around the existing code so that maintenance would only be required >>> if the >>> >>> javascript adapter API changes. >>> >>> >>> >>> In terms of browser support, caniuse.com[1] indicates that Promise >>> has >>> >>> broad support; only IE 11 and Opera Mini fail to support Promise. >>> However >>> >>> polyfills are available to provide support. >>> >>> >>> >>> As far as the advantages, the main ones as I see it are: 1) using the >>> >>> standard promise API makes it easier for developers new to the >>> library; 2) >>> >>> using the standard promise API makes the library more interoperable >>> with >>> >>> other libraries; and 3) ES6 Promise objects are chainable making >>> sequences >>> >>> of asynchronous calls cleaner to code. >>> >>> >>> >>> I think the MDN page on Using Promises[2] probably makes a better >>> >>> argument for than I'll be able to here. But the main thrust is that >>> >>> chaining makes it so it is not necessary to have so many nested >>> functions. >>> >>> >>> >>> For example, suppose I am writing a javascript client for a REST API >>> >>> protected by Keycloak. Since the built-in fetch() method returns a >>> Promise >>> >>> with ES6 Promises I can write: >>> >>> >>> >>> // assume authz.updateToken() returns an ES6 Promise >>> >>> authz.updateToken(5).then((token) => { >>> >>> return fetch(this.ENDPOINT, { >>> >>> redirect: 'error', >>> >>> headers: { "Authorization": "Bearer " + token } >>> >>> }); >>> >>> }).then((response) => { >>> >>> showResult(response.text()); >>> >>> }).catch((error) => { >>> >>> displayError(error); >>> >>> }); >>> >>> } >>> >>> >>> >>> Since everything is standard, any JS developer would understand the >>> >>> code. Since both libraries use Promise, I can chain the promises >>> without >>> >>> nesting functions. And since both libraries use Promise, I can use >>> catch() >>> >>> at the end for unified error handling whether the error comes from >>> the >>> >>> Keycloak adapter or from the call to fetch(). >>> >>> >>> >>> >>> >>> [1] http://caniuse.com/#search=Promise >>> >>> [2] https://developer.mozilla.org/en-US/docs/Web/JavaScript/ >>> >>> Guide/Using_promises >>> >>> >>> >>> >>> >>> On Tue, Sep 5, 2017 at 6:18 AM, Stian Thorgersen < >>> sthorger at redhat.com> >>> >>> wrote: >>> >>> >>> >>>> I don't know much about ES6 native Promises. Can you give me some >>> >>>> details about it? What browser support it? What are the benefits of >>> using >>> >>>> that instead of our howegrown approach? Etc. >>> >>>> >>> >>>> On 4 September 2017 at 20:36, Raymond DeCampo >>> wrote: >>> >>>> >>> >>>>> Hello all, >>> >>>>> >>> >>>>> I create a wrapper around the javascript adapter which uses ES6 >>> native >>> >>>>> Promises. (https://github.com/RayDeCampo/keycloak-promise). >>> >>>>> >>> >>>>> If you are interested, I can re-package it for inclusion in >>> Keycloak >>> >>>>> and >>> >>>>> create a pull request on GitHub. If you have a different process >>> for >>> >>>>> contributions, let me know. >>> >>>>> >>> >>>>> If you are not interested, no hard feelings. >>> >>>>> >>> >>>>> Thanks, >>> >>>>> Ray >>> >>>>> _______________________________________________ >>> >>>>> 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 Mon Sep 25 07:40:01 2017 From: sthorger at redhat.com (Stian Thorgersen) Date: Mon, 25 Sep 2017 13:40:01 +0200 Subject: [keycloak-dev] Implementations for KEYCLOAK-2209 In-Reply-To: References: Message-ID: On 18 September 2017 at 17:57, Ricardo Martin Camarero wrote: > Hi Stian, > > I'm answering inline... > > > On 09/18/2017 03:58 PM, Stian Thorgersen wrote: > > Reading your email I couldn't figure out how you assign a password > > policy to a user. > > The password policy is just assigned using an attribute in the user > (like firstname or lastname). The only difference is that in option 1 it > is single-valued and in option 2 it is multi-valiued (to test the > merge). You can really play with it if you clone my repos and start the > the server, create another password policy, create a user and assign a > password policy to it (in the details tab). > I'm afraid I don't have time to look into your PR at the moment. Are you saying that what password policy to use is configured per-user based on an attribute? If so I don't think that's a good approach. > > > I think it would be best if there's an ordered/prioritized list of > > password policies. Each policy would have a set of conditions on > > whether or not the policy should be applied to a specific user. Where > > conditions should include member/not-member of a specific group, > > has/doesn't have a specific role, a specific attribute key/value or if > > a user belongs to a specific user fed provider. If none matches the > > last in the list should be used. I find having more than one policy > > apply to a specific user just confusing so it should be the first > > policy that matches for a user that is used. > > That is much more complex of what I was thinking and what KEYCLOAK-2209 > describes. My idea is much more simple: > > * The realm has a default password policy (the current one). > * The user may have assigned a specific password policy. > * Any group may have assigned a specific password policy (this part is > not done in the branches). > * As a user can result with several password policies assigned (because > of the groups): > Option 1: The policy with the highest priority applies. > Option 2: Policies are merged (or all of them applied as the > enhancement says). > > As you see my implementation is much more modest than your idea. Your > idea can be later achieved with something like dynamic groups (a group > that is automatically assigned because of an attribute in the user, > because those groups can also have a password policy). > I'm not really following. What I'm suggesting is that the password policy itself selects what policy to use, not the other way around. > > > > > Now with regards to implementation it would make sense to convert > > password policies to use component storage rather than add additional > > tables/attributes for password policies. The single string password > > policy was introduced before we had component storage and it is our > > plan to eventually convert password policies to use component storage. > > Component storage is much more flexible and powerful than what we have > > today for password policies. It allows the provider itself to expose > > what configuration applies to it. > > No idea about what is the component storage but ok, if you want me to > continue with my modest approach I'll take a look to that and I'll move > the password policies to component storage. > > Thanks. > > > > > On 12 September 2017 at 19:59, Ricardo Martin Camarero > > > wrote: > > > > Hi team, > > > > I'm forwarding this email to the list following Stian's > > recommendation. > > > > I needed to learn more about keycloak (how to manage the maven > > project, > > how to add a modification, how to test it, and so on and so > > forth), so I > > decided to start looking the code and try to help when I have some > > free > > time. As I filed an internal RFE because one customer wanted a > similar > > solution than the one specified in KEYCLOAK-2209 I started to > > implement > > something. Now I have two possible ideas that are not completely > > implemented (I haven't done any group use for example). Both ideas > > have > > similarities: > > > > * I have extended the database to include a > > REALM_PASSWORD_POLICY_GROUP > > table that contains more policies associated to the realm. I thought > > about using an attribute but I decided to extend the database because > > the current policy attribute is a long string (length 2550). This > > way in > > the realm (policies page) now you can configure more than one > password > > policy (default is the current one and you can add new policies > > that are > > saved in the new table with a name). > > > > * The user has a new attribute that contains the password policy, in > > this case I have re-used an attribute (I'm not sure about this > > idea, now > > I think using a new column would be better but I needed a multiple > > attribute for option 2). > > > > * In both solutions I needed to extend the PasswordPolicyProvider > > interface to pass the config to the two validate methods: > > > > PolicyError validate(RealmModel realm, UserModel user, String > > password, Object config); > > > > I think there is a bug in this part in current master branch, > > because > > regex policy is multiple, and you cannot assign two different regex > > providers in the same policy (PasswordPolicy stores the > > configuration in > > a Map, so you cannot have two different > configurations > > for the same type, if you assign two regex providers they are > > transformed into one as soon as you save the policy). > > > > > > Now the two implementations: > > > > 1) The first idea let us configure to a user one password policy. My > > branch is this one: > > > > https://github.com/rmartinc/keycloak/tree/password-policy-groups > > > > > > In this solution the user has a combo (only one policy can be > > assigned > > to a user) and only one policy is applied to that user. My idea was > > extending the idea using groups and priorities. Password policies > will > > have a priority, and only one policy will apply to a user (from > > all the > > possible policies the one with the higher priority applies). For the > > moment I only modified keycloak to have a different policy in the > user > > (no priorities or group policies). > > > > 2) The second idea follows the description in 2209. The branch is the > > following: > > > > > > https://github.com/rmartinc/keycloak/tree/password-policy- > groups-multi > > groups-multi> > > > > Here the user can have multiple password policies. The definitive > > policy is a merge between all the policies applied to the user. To do > > this I needed to extend the PasswordPolicyProvider interface even > > more, > > in order to have a compare method that returns which policy is more > > restrictive. Extending this idea to groups is just merging more > > policies. > > > > > > You can test my ideas (I think both of them are working). If you are > > interested please let me know which idea you think is better (I'm not > > completely sure, now I think that I prefer option 1, although option > 2 > > is more similar to the RFE description, I think the latter is very > > confusing). If you like one of them, I'll try to finish the > > implementation (now there are no tests and some decisions I took > maybe > > are wrong). If you think this is not needed or it's not the time to > > implement this RFE don't worry, it's ok, I needed to play with > > keycloak, > > and that part is done. > > > > Regards! > > > > _______________________________________________ > > keycloak-dev mailing list > > keycloak-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > > > > > > -- > > Ricardo Martin Camarero > > Software Maintenance Engineer > > Red Hat > > > > > > From mstrukel at redhat.com Mon Sep 25 08:20:15 2017 From: mstrukel at redhat.com (Marko Strukelj) Date: Mon, 25 Sep 2017 14:20:15 +0200 Subject: [keycloak-dev] Question about a problem with Derivation and/or Deployment and/or (at the end) a 'NoClassDefFoundError'. In-Reply-To: References: Message-ID: Please use keycloak-user mailing list for questions like this ( https://lists.jboss.org/mailman/listinfo/keycloak-user). It sounds like you should include jboss-deployment-structure.xml in your example and add dependency on module org.keycloak.keycloak-services, and possibly some other keycloak modules as well. On Mon, Sep 25, 2017 at 11:23 AM, Christian Kayssner < Christian.Kayssner at muthpartners.de> wrote: > Hello, > > I have an problem in the deployment process. > > For an higher security context I have to intervene in the original > username/password functionality. > > I searched and found the original class 'org.keycloak.authentication. > authenticators.browser.UsernamePasswordFormFactory'. > For this mail, I reduced the derivation and manipulation to a minimum and > choose the 'secret-example' for deployment. > The derivated factory class get the name 'org.example.derivations.MyUsernamePasswordFormFactory' > and would be activated next to the existing factory in the file > 'org.keycloak.examples.authenticator.SecretQuestionAuthenticatorFactory'. > > I take the secret-question example because it closest to mine. > > But when I deploy the secret-example I get the 'NoClassDefFoundError' (see > below). > > I checked the java visibilities (nothing private, protected or final). > The core class reside in the artefactId 'keycloak-services', and the > secret-example pom has a direct dependency entry. > Eclipse (the maven-plugin) is satisfied. > > Therefore I found no reason for this exception. > > Does anyone have an idea why the *deployment* fails (and which party > (Maven, Wildfly or Keycloak) is not amused)? > Have I missed note something? > Or is a derivation, per se, not desired?? > > > If someone wants to retrace, he/she needs: > * a current 64bit linux with approximately 420MB free space with a > directory of your choice, > * with a running maven environment > * and *without* running wildfly/keycloak system. > > Next, you: > * download the demo version in your/this direcory > wget -r https://downloads.jboss.org/ > keycloak/3.2.1.Final/keycloak-demo-3.2.1.Final.tar.gz > * expand this archive, > tar -xzf keycloak-demo-3.2.1.Final.tar.gz > * save the follow patch (all content between > and ) file and execute it, > patch -p 0 < NameOfYourSavedPatchFile > * start the example server and save the terminal-log, > keycloak-demo-3.2.1.Final/keycloak/bin/standalone.sh | > tee keycloak-demo-3.2.1.Final.log > * open a new terminal, > * go to the secret example direcory and > cd keycloak-demo-3.2.1.Final/examples/providers/ > authenticator > * deploy it. > mvn clean install wildfly:deploy > > * will see the 'NoClassDefFoundError' exception! > > > Best regards > > Christian Kayssner > -- > G. Muth Partners GmbH > Borsigstra?e 32 > D - 65205 Wiesbaden > HRB 10196 Amtsgericht Wiesbaden > Gesch?ftsf?hrer: Klaus Gockel / Oliver M?chold > > Tel. : +49(0)6122/5981-0 > FAX. : +49(0)6122/5981-50 > > eMail: christian.kayssner at muthpartners.de > www : www.muthpartners.de > > > -- > > : > : > : > [0m [0m17:39:08,074 INFO [org.jboss.as.repository] > (management-handler-thread - 4) WFLYDR0001: Content added at location > /path/to/your/own/playground/keycloak-demo-3.2.1.Final/ > keycloak/standalone/data/content/e4/95f32235bb131df52f479a09827186 > a3265788/content > [0m [0m17:39:08,082 INFO [org.jboss.as.server.deployment] (MSC service > thread 1-2) WFLYSRV0027: Starting deployment of "authenticator-required-action-example.jar" > (runtime-name: "authenticator-required-action-example.jar") > [0m [0m17:39:08,322 INFO [org.keycloak.subsystem.server.extension. > KeycloakProviderDeploymentProcessor] (MSC service thread 1-1) Deploying > Keycloak provider: authenticator-required-action-example.jar > [0m [33m17:39:08,335 WARN [org.jboss.modules] (MSC service thread 1-1) > Failed to define class org.example.derivations.MyUsernamePasswordFormFactory > in Module "deployment.authenticator-required-action-example.jar:main" > from Service Module Loader: java.lang.NoClassDefFoundError: Failed to > link org/example/derivations/MyUsernamePasswordFormFactory (Module > "deployment.authenticator-required-action-example.jar:main" from Service > Module Loader): org/keycloak/authentication/authenticators/browser/ > UsernamePasswordFormFactory > at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native > Method) > at sun.reflect.NativeConstructorAccessorImpl.newInstance( > NativeConstructorAccessorImpl.java:62) > at sun.reflect.DelegatingConstructorAccessorImpl.newInstance( > DelegatingConstructorAccessorImpl.java:45) > at java.lang.reflect.Constructor.newInstance(Constructor.java:423) > at org.jboss.modules.ModuleClassLoader.defineClass( > ModuleClassLoader.java:446) > at org.jboss.modules.ModuleClassLoader.loadClassLocal( > ModuleClassLoader.java:274) > at org.jboss.modules.ModuleClassLoader$1.loadClassLocal( > ModuleClassLoader.java:78) > at org.jboss.modules.Module.loadModuleClass(Module.java:605) > at org.jboss.modules.ModuleClassLoader.findClass( > ModuleClassLoader.java:190) > at org.jboss.modules.ConcurrentClassLoader. > performLoadClassUnchecked(ConcurrentClassLoader.java:363) > at org.jboss.modules.ConcurrentClassLoader.performLoadClass( > ConcurrentClassLoader.java:351) > at org.jboss.modules.ConcurrentClassLoader.loadClass( > ConcurrentClassLoader.java:93) > at java.lang.Class.forName0(Native Method) > at java.lang.Class.forName(Class.java:348) > at java.util.ServiceLoader$LazyIterator.nextService( > ServiceLoader.java:370) > at java.util.ServiceLoader$LazyIterator.next( > ServiceLoader.java:404) > at java.util.ServiceLoader$1.next(ServiceLoader.java:480) > at org.keycloak.provider.DefaultProviderLoader.load( > DefaultProviderLoader.java:47) > at org.keycloak.provider.ProviderManager.load( > ProviderManager.java:93) > at org.keycloak.services.DefaultKeycloakSessionFactory. > loadFactories(DefaultKeycloakSessionFactory.java:208) > at org.keycloak.services.DefaultKeycloakSessionFactory.deploy( > DefaultKeycloakSessionFactory.java:114) > at org.keycloak.provider.ProviderManagerRegistry.deploy( > ProviderManagerRegistry.java:42) > at org.keycloak.subsystem.server.extension. > KeycloakProviderDeploymentProcessor.deploy(KeycloakProviderDeploymentProc > essor.java:54) > at org.jboss.as.server.deployment.DeploymentUnitPhaseService. > start(DeploymentUnitPhaseService.java:147) > at org.jboss.msc.service.ServiceControllerImpl$ > StartTask.startService(ServiceControllerImpl.java:1948) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run( > ServiceControllerImpl.java:1881) > at java.util.concurrent.ThreadPoolExecutor.runWorker( > ThreadPoolExecutor.java:1149) > at java.util.concurrent.ThreadPoolExecutor$Worker.run( > ThreadPoolExecutor.java:624) > at java.lang.Thread.run(Thread.java:748) > > [0m [31m17:39:08,336 ERROR [org.jboss.msc.service.fail] (MSC service > thread 1-1) MSC000001: Failed to start service jboss.deployment.unit." > authenticator-required-action-example.jar".POST_MODULE: > org.jboss.msc.service.StartException in service jboss.deployment.unit." > authenticator-required-action-example.jar".POST_MODULE: WFLYSRV0153: > Failed to process phase POST_MODULE of deployment "authenticator-required- > action-example.jar" > at org.jboss.as.server.deployment.DeploymentUnitPhaseService. > start(DeploymentUnitPhaseService.java:154) > at org.jboss.msc.service.ServiceControllerImpl$ > StartTask.startService(ServiceControllerImpl.java:1948) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run( > ServiceControllerImpl.java:1881) > at java.util.concurrent.ThreadPoolExecutor.runWorker( > ThreadPoolExecutor.java:1149) > at java.util.concurrent.ThreadPoolExecutor$Worker.run( > ThreadPoolExecutor.java:624) > at java.lang.Thread.run(Thread.java:748) > Caused by: java.lang.NoClassDefFoundError: Failed to link > org/example/derivations/MyUsernamePasswordFormFactory (Module > "deployment.authenticator-required-action-example.jar:main" from Service > Module Loader): org/keycloak/authentication/authenticators/browser/ > UsernamePasswordFormFactory > at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native > Method) > at sun.reflect.NativeConstructorAccessorImpl.newInstance( > NativeConstructorAccessorImpl.java:62) > at sun.reflect.DelegatingConstructorAccessorImpl.newInstance( > DelegatingConstructorAccessorImpl.java:45) > at java.lang.reflect.Constructor.newInstance(Constructor.java:423) > at org.jboss.modules.ModuleClassLoader.defineClass( > ModuleClassLoader.java:446) > at org.jboss.modules.ModuleClassLoader.loadClassLocal( > ModuleClassLoader.java:274) > at org.jboss.modules.ModuleClassLoader$1.loadClassLocal( > ModuleClassLoader.java:78) > at org.jboss.modules.Module.loadModuleClass(Module.java:605) > at org.jboss.modules.ModuleClassLoader.findClass( > ModuleClassLoader.java:190) > at org.jboss.modules.ConcurrentClassLoader. > performLoadClassUnchecked(ConcurrentClassLoader.java:363) > at org.jboss.modules.ConcurrentClassLoader.performLoadClass( > ConcurrentClassLoader.java:351) > at org.jboss.modules.ConcurrentClassLoader.loadClass( > ConcurrentClassLoader.java:93) > at java.lang.Class.forName0(Native Method) > at java.lang.Class.forName(Class.java:348) > at java.util.ServiceLoader$LazyIterator.nextService( > ServiceLoader.java:370) > at java.util.ServiceLoader$LazyIterator.next( > ServiceLoader.java:404) > at java.util.ServiceLoader$1.next(ServiceLoader.java:480) > at org.keycloak.provider.DefaultProviderLoader.load( > DefaultProviderLoader.java:47) > at org.keycloak.provider.ProviderManager.load( > ProviderManager.java:93) > at org.keycloak.services.DefaultKeycloakSessionFactory. > loadFactories(DefaultKeycloakSessionFactory.java:208) > at org.keycloak.services.DefaultKeycloakSessionFactory.deploy( > DefaultKeycloakSessionFactory.java:114) > at org.keycloak.provider.ProviderManagerRegistry.deploy( > ProviderManagerRegistry.java:42) > at org.keycloak.subsystem.server.extension. > KeycloakProviderDeploymentProcessor.deploy(KeycloakProviderDeploymentProc > essor.java:54) > at org.jboss.as.server.deployment.DeploymentUnitPhaseService. > start(DeploymentUnitPhaseService.java:147) > ... 5 more > > [0m [31m17:39:08,339 ERROR [org.jboss.as.controller.management-operation] > (management-handler-thread - 4) WFLYCTL0013: Operation ("add") failed - > address: ([("deployment" => "authenticator-required-action-example.jar")]) > - failure description: {"WFLYCTL0080: Failed services" => > {"jboss.deployment.unit.\"authenticator-required-action-example.jar\".POST_MODULE" > => "org.jboss.msc.service.StartException in service > jboss.deployment.unit.\"authenticator-required-action-example.jar\".POST_MODULE: > WFLYSRV0153: Failed to process phase POST_MODULE of deployment > \"authenticator-required-action-example.jar\" > Caused by: java.lang.NoClassDefFoundError: Failed to link > org/example/derivations/MyUsernamePasswordFormFactory (Module > \"deployment.authenticator-required-action-example.jar:main\" from > Service Module Loader): org/keycloak/authentication/ > authenticators/browser/UsernamePasswordFormFactory"}} > [0m [31m17:39:08,341 ERROR [org.jboss.as.server] > (management-handler-thread - 4) WFLYSRV0021: Deploy of deployment > "authenticator-required-action-example.jar" was rolled back with the > following failure message: > {"WFLYCTL0080: Failed services" => {"jboss.deployment.unit.\" > authenticator-required-action-example.jar\".POST_MODULE" => > "org.jboss.msc.service.StartException in service jboss.deployment.unit.\" > authenticator-required-action-example.jar\".POST_MODULE: WFLYSRV0153: > Failed to process phase POST_MODULE of deployment \"authenticator-required- > action-example.jar\" > Caused by: java.lang.NoClassDefFoundError: Failed to link > org/example/derivations/MyUsernamePasswordFormFactory (Module > \"deployment.authenticator-required-action-example.jar:main\" from > Service Module Loader): org/keycloak/authentication/ > authenticators/browser/UsernamePasswordFormFactory"}} > [0m [0m17:39:08,356 INFO [org.jboss.as.server.deployment] (MSC service > thread 1-5) WFLYSRV0028: Stopped deployment authenticator-required-action-example.jar > (runtime-name: authenticator-required-action-example.jar) in 14ms > [0m [0m17:39:08,357 INFO [org.jboss.as.controller] > (management-handler-thread - 4) WFLYCTL0183: Service status report > WFLYCTL0186: Services which failed to start: service > jboss.deployment.unit."authenticator-required-action- > example.jar".POST_MODULE > > [0m > > > -- > > diff -Naur keycloak-demo-3.2.1.Final/examples/providers/ > authenticator/src/main/java/org/example/derivations/ > MyUsernamePasswordFormFactory.java keycloak-demo-3.2.1.Final- > modified/examples/providers/authenticator/src/main/java/ > org/example/derivations/MyUsernamePasswordFormFactory.java > --- keycloak-demo-3.2.1.Final/examples/providers/ > authenticator/src/main/java/org/example/derivations/ > MyUsernamePasswordFormFactory.java 1970-01-01 00:00:00.000000000 +0000 > +++ keycloak-demo-3.2.1.Final-modified/examples/providers/ > authenticator/src/main/java/org/example/derivations/ > MyUsernamePasswordFormFactory.java 2017-09-20 11:37:09.425674263 > +0000 > @@ -0,0 +1,54 @@ > +/* > + * Copyright 2016 Red Hat, Inc. and/or its affiliates > + * and other contributors as indicated by the @author tags. > + * > + * Licensed under the Apache License, Version 2.0 (the "License"); > + * you may not use this file except in compliance with the License. > + * You may obtain a copy of the License at > + * > + * http://www.apache.org/licenses/LICENSE-2.0 > + * > + * Unless required by applicable law or agreed to in writing, software > + * distributed under the License is distributed on an "AS IS" BASIS, > + * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or > implied. > + * See the License for the specific language governing permissions and > + * limitations under the License. > + */ > + > +package org.example.derivations; > + > +import org.keycloak.authentication.authenticators.browser. > UsernamePasswordFormFactory; > + > +/** > + */ > +public// > +class MyUsernamePasswordFormFactory// > + extends UsernamePasswordFormFactory// > +{ > + public// > + static// > + final// > + String PROVIDER_ID = "my-auth-username-password-form"; > + > + /** > + * {@inheritDoc} > + */ > + @Override > + public// > + String getId()// > + { > + return MyUsernamePasswordFormFactory.PROVIDER_ID; > + } > + > + /** > + * {@inheritDoc} > + * > + * @return The heading for the (browser) page to explain the > necessary inputs. > + */ > + @Override > + public// > + String getDisplayType()// > + { > + return "My Username Password Form"; > + } > +} > diff -Naur keycloak-demo-3.2.1.Final/examples/providers/ > authenticator/src/main/resources/META-INF/services/ > org.keycloak.authentication.AuthenticatorFactory > keycloak-demo-3.2.1.Final-modified/examples/providers/ > authenticator/src/main/resources/META-INF/services/ > org.keycloak.authentication.AuthenticatorFactory > --- keycloak-demo-3.2.1.Final/examples/providers/authenticator/src/main/ > resources/META-INF/services/org.keycloak.authentication.AuthenticatorFactory > 2017-07-21 11:31:26.000000000 +0000 > +++ keycloak-demo-3.2.1.Final-modified/examples/providers/ > authenticator/src/main/resources/META-INF/services/ > org.keycloak.authentication.AuthenticatorFactory 2017-09-20 > 11:43:31.354018042 +0000 > @@ -15,4 +15,5 @@ > # limitations under the License. > # > > -org.keycloak.examples.authenticator.SecretQuestionAuthenticatorFactory > \ No newline at end of file > +org.keycloak.examples.authenticator.SecretQuestionAuthenticatorFactory > +org.example.derivations.MyUsernamePasswordFormFactory > \ No newline at end of file > diff -Naur keycloak-demo-3.2.1.Final/keycloak/modules/layers.conf > keycloak-demo-3.2.1.Final-modified/keycloak/modules/layers.conf > --- keycloak-demo-3.2.1.Final/keycloak/modules/layers.conf > 1970-01-01 00:00:00.000000000 +0000 > +++ keycloak-demo-3.2.1.Final-modified/keycloak/modules/layers.conf > 2017-07-21 09:11:58.000000000 +0000 > @@ -0,0 +1 @@ > +layers=keycloak > \ No newline at end of file > > > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > From bburke at redhat.com Mon Sep 25 11:11:22 2017 From: bburke at redhat.com (Bill Burke) Date: Mon, 25 Sep 2017 11:11:22 -0400 Subject: [keycloak-dev] rename client templates to scope? Message-ID: This is something for 4.0 Was thinking that we should rename Client Templates to Client Scopes. For oauth, oidc, and token exchange client asks for a specific scope with the "scope" parameter. This "scope" parameter would be the name of a client-id or a client scope (formerly client emplates. Clients will be granted access to scopes in the admin console. Probably through authz services. -- Bill Burke Red Hat From thomas.darimont at googlemail.com Mon Sep 25 13:08:58 2017 From: thomas.darimont at googlemail.com (Thomas Darimont) Date: Mon, 25 Sep 2017 19:08:58 +0200 Subject: [keycloak-dev] Authenticating Desktop Applications with Keycloak and the keycloak-installed adapter In-Reply-To: References: Message-ID: Hello, quick followup... Since there was no documentation for the KeycloakInstalled adapter yet, I just wrote a short section for the manual. https://github.com/keycloak/keycloak-documentation/pull/206 Looking forward to your feedback. Cheers, Thomas 2017-07-25 9:52 GMT+02:00 Thomas Darimont : > Hi Bill, > > that's nice to hear! > Is there already a JIRA issue for that? May I open a pull request and you > take it from there? > > I think the TLS feature was a bit over ambitious - so never mind. The idea > was to optionally allow using > https for connections to 127.0.0.1 + allowing users to pass-in a custom > cert / trust store. > > Note that using 127.0.0.1 instead of localhost might cause some > compatibility problems and should be mentioned in the migration guide. > E.g. users who already use the keycloak-installed adapter probably need to > adapt the allowed redirect > uri pattern in the client configuration in Keycloak (127.0.0.1 instead of > localhost). > > Cheers, > Thomas > > 2017-07-25 0:21 GMT+02:00 Bill Burke : > >> >> >> On 7/18/17 9:42 AM, Thomas Darimont wrote: >> > - Add support for TLS (with custom certificates) for https:// with >> localhost >> >> Hey, I'm incorporating your changes, but one question I have is why do >> you need this? >> >> Bill >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> > > From ray at decampo.org Mon Sep 25 21:33:07 2017 From: ray at decampo.org (Raymond DeCampo) Date: Mon, 25 Sep 2017 21:33:07 -0400 Subject: [keycloak-dev] Promise wrapper for javascript adapter In-Reply-To: References: Message-ID: I think maybe we are making this too complicated. Since this is JS, we could take a native Promise instance and add the methods defined by the existing promise return value. Then it would work using the existing callbacks or using standard Promise methods. Something like: if (typeof Promise === "function") { var promise = new Promise(...); promise.success = function(callback) { ... }; promise.error = function(callback) { ... }; } else { // return existing custom promise object } On Mon, Sep 25, 2017 at 7:36 AM, Stian Thorgersen wrote: > No, I'd be looking for a PR where keycloak.js uses standard promises > internally, but will return a wrapper for the promises that uses the legacy > api. There will be a config option that can be enabled to return standard > promises instead. After a few releases we make it return standard promises, > then finally after a few more releases we remove the legacy wrapper > completely. > > On 22 September 2017 at 13:44, Raymond DeCampo wrote: > >> So the next step is "deprecate and replace with standard"? So you would >> be looking for a pull request where keycloak.js is modified to return >> standard native Promises and the existing keycloak.js is moved to something >> like keycloak-legacy.js? >> >> On Wed, Sep 20, 2017 at 11:36 AM, Stian Thorgersen >> wrote: >> >>> +1 If we do promises that would be the only useful way to do it. >>> Standard promises wrapped to become wrapped. Have custom promises as >>> default initially. Deprecate and switch to standard after a while and >>> finally remove completely. >>> >>> >>> On 18 Sep 2017 6:16 pm, "Niels Bertram" wrote: >>> >>>> No, I'd be looking for a PR where keycloak.js uses standard promises >>>> internally, but will return a wrapper for the promises that uses the legacy >>>> api. There will be a config option that can be enabled to return standard >>>> promises instead. After a few releases we make it return standard promises, >>>> then finally after a few more releases we remove the legacy wrapper >>>> completely. >>>> >>>> On 22 September 2017 at 13:44, Raymond DeCampo wrote: >>>> >>>>> So the next step is "deprecate and replace with standard"? So you >>>>> would be looking for a pull request where keycloak.js is modified to return >>>>> standard native Promises and the existing keycloak.js is moved to something >>>>> like keycloak-legacy.js? >>>>> >>>>> On Wed, Sep 20, 2017 at 11:36 AM, Stian Thorgersen < >>>>> sthorger at redhat.com> wrote: >>>>> >>>>>> +1 If we do promises that would be the only useful way to do it. >>>>>> Standard promises wrapped to become wrapped. Have custom promises as >>>>>> default initially. Deprecate and switch to standard after a while and >>>>>> finally remove completely. >>>>>> >>>>>> >>>>>> On 18 Sep 2017 6:16 pm, "Niels Bertram" wrote: >>>>>> >>>>>> Hmm ... I was actally looking at the js libraries (browser and node >>>>>> ones) a short while ago and thought the same thing, why not use a A+ >>>>>> compliant promise [1] instead of the custom thingy. It is hard to follow >>>>>> custom logic when basic concepts exist and are understood. >>>>>> >>>>>> Why not implement standard promises in the main library and write a >>>>>> wrapper for the custom promises. Then mark those for deprecation and retire >>>>>> them in a few releases. I think mongoose did this some time back with a >>>>>> pluggable promise interface [2] to escape callback hell. >>>>>> >>>>>> I think this would improve the adoptability of the adapters given >>>>>> lots of folks don't fully understand OIDC and throw things in the too hard >>>>>> basket as soon as they are given the slightest opportunity - real world >>>>>> experience. >>>>>> >>>>>> Cheers Niels >>>>>> >>>>>> [1] https://promisesaplus.com >>>>>> [2] http://mongoosejs.com/docs/promises.html >>>>>> >>>>>> On 18 Sep. 2017 4:44 am, "Stian Thorgersen" >>>>>> wrote: >>>>>> >>>>>>> I don't like the idea of having a wrapper as it needs updating >>>>>>> separately >>>>>>> when anything changes. If it's a different library I believe it'll >>>>>>> just be >>>>>>> forgotten about and also be annoying boilerplate to maintain. That's >>>>>>> why >>>>>>> I'd rather just have it return a different promise object depending >>>>>>> on what >>>>>>> config option is used. There's not that many places internally where >>>>>>> promises objects are used, so we can probably find a reasonable way >>>>>>> to do >>>>>>> that. >>>>>>> >>>>>>> That being said I'm wondering if this is actually a case where this >>>>>>> is just >>>>>>> another way of doing something that won't actually be used. AFAIK no >>>>>>> one >>>>>>> else have asked for this nor have we seen anyone else comment on this >>>>>>> thread. So maybe the best option here is to just leave it as is? >>>>>>> >>>>>>> On 13 September 2017 at 14:31, Raymond DeCampo >>>>>>> wrote: >>>>>>> >>>>>>> > I understand the concern about increasing the test surface. >>>>>>> > >>>>>>> > However I don't think that introducing a configuration option and >>>>>>> having >>>>>>> > methods that return different objects based on the option will >>>>>>> decrease the >>>>>>> > testing risk. There are places in the keycloak.js where it >>>>>>> invokes it's >>>>>>> > own methods and uses the custom promise object, for example: >>>>>>> > >>>>>>> > https://github.com/keycloak/keycloak/blob/b7af96aa4d7daeec6d >>>>>>> a12ee9326d1c >>>>>>> > 0fdcc4850f/adapters/oidc/js/src/main/resources/keycloak.js#L >>>>>>> 128-L131 >>>>>>> > >>>>>>> > >>>>>>> > kc.login(options).success(function () { >>>>>>> > initPromise.setSuccess(); >>>>>>> > }).error(function () { >>>>>>> > initPromise.setError(); >>>>>>> > }); >>>>>>> > >>>>>>> > >>>>>>> > So these places would have to change based on the configuration >>>>>>> option and >>>>>>> > I think it will become a bigger problem. >>>>>>> > >>>>>>> > What if instead we add a method on the Keycloak object which >>>>>>> returns a >>>>>>> > wrapper instance using Promises and keep everything in the one >>>>>>> keycloak.js >>>>>>> > file? So clients could do: >>>>>>> > >>>>>>> > var keycloak = new Keycloak().promiseWrapper(); >>>>>>> > >>>>>>> > keycloak.init().then(function() { ... }); >>>>>>> > >>>>>>> > >>>>>>> > And everything is in the one file? >>>>>>> > >>>>>>> > >>>>>>> > Although let me make one more pitch on the merits of my original >>>>>>> > suggestion: >>>>>>> > >>>>>>> > >>>>>>> > 1. No changes to keycloak.js => less risk of breaking something >>>>>>> that >>>>>>> > already works >>>>>>> > 2. The KeycloakPromise implementation delegates to the >>>>>>> keycloak.js >>>>>>> >>>>>>> > implementation which means that fixes to keycloak.js >>>>>>> automatically >>>>>>> > propogate. >>>>>>> > 3. The KeycloakPromise implementation is a wrapper which means >>>>>>> it only >>>>>>> >>>>>>> > needs to be changed if there is a change to the keycloak.js >>>>>>> API, e.g. a new >>>>>>> > method or a new argument to a method (but not a new option on >>>>>>> an existing >>>>>>> > argument) >>>>>>> > 4. I think it will be clearer to document the interfaces for >>>>>>> the end >>>>>>> >>>>>>> > user but of course that is a matter of opinion. >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > On Tue, Sep 12, 2017 at 11:28 PM, Stian Thorgersen < >>>>>>> sthorger at redhat.com> >>>>>>> > wrote: >>>>>>> > >>>>>>> >> I can see how it would be nice. I'm a bit worried that the >>>>>>> separate >>>>>>> >> javascript file would simply get out of date and it would also >>>>>>> need >>>>>>> >> separate testing. We're already lacking a bit on testing of the >>>>>>> JS adapter >>>>>>> >> in the first place and this would be yet another thing to test. >>>>>>> Is there a >>>>>>> >> way we could simply have a config option in the current >>>>>>> javascript adapter >>>>>>> >> that allows setting what promise to return? That way it's >>>>>>> probably just a >>>>>>> >> few lines in keycloak.js where it's creating the promise objects >>>>>>> to switch >>>>>>> >> between the two? >>>>>>> >> >>>>>>> >> On 5 September 2017 at 05:58, Raymond DeCampo >>>>>>> wrote: >>>>>>> >> >>>>>>> >>> First, if I were to integrate Promise support into the Keycloak, >>>>>>> I would >>>>>>> >>> be leaving the current javascript adapter as is. This would be >>>>>>> an >>>>>>> >>> extension in a separate javascript file so that only developers >>>>>>> who are >>>>>>> >>> interested would get the Promise interface. Existing code using >>>>>>> the >>>>>>> >>> current adapter would be unaffected. The new code would be a >>>>>>> wrapper >>>>>>> >>> around the existing code so that maintenance would only be >>>>>>> required if the >>>>>>> >>> javascript adapter API changes. >>>>>>> >>> >>>>>>> >>> In terms of browser support, caniuse.com[1] indicates that >>>>>>> Promise has >>>>>>> >>> broad support; only IE 11 and Opera Mini fail to support >>>>>>> Promise. However >>>>>>> >>> polyfills are available to provide support. >>>>>>> >>> >>>>>>> >>> As far as the advantages, the main ones as I see it are: 1) >>>>>>> using the >>>>>>> >>> standard promise API makes it easier for developers new to the >>>>>>> library; 2) >>>>>>> >>> using the standard promise API makes the library more >>>>>>> interoperable with >>>>>>> >>> other libraries; and 3) ES6 Promise objects are chainable making >>>>>>> sequences >>>>>>> >>> of asynchronous calls cleaner to code. >>>>>>> >>> >>>>>>> >>> I think the MDN page on Using Promises[2] probably makes a better >>>>>>> >>> argument for than I'll be able to here. But the main thrust is >>>>>>> that >>>>>>> >>> chaining makes it so it is not necessary to have so many nested >>>>>>> functions. >>>>>>> >>> >>>>>>> >>> For example, suppose I am writing a javascript client for a REST >>>>>>> API >>>>>>> >>> protected by Keycloak. Since the built-in fetch() method >>>>>>> returns a Promise >>>>>>> >>> with ES6 Promises I can write: >>>>>>> >>> >>>>>>> >>> // assume authz.updateToken() returns an ES6 Promise >>>>>>> >>> authz.updateToken(5).then((token) => { >>>>>>> >>> return fetch(this.ENDPOINT, { >>>>>>> >>> redirect: 'error', >>>>>>> >>> headers: { "Authorization": "Bearer " + token } >>>>>>> >>> }); >>>>>>> >>> }).then((response) => { >>>>>>> >>> showResult(response.text()); >>>>>>> >>> }).catch((error) => { >>>>>>> >>> displayError(error); >>>>>>> >>> }); >>>>>>> >>> } >>>>>>> >>> >>>>>>> >>> Since everything is standard, any JS developer would understand >>>>>>> the >>>>>>> >>> code. Since both libraries use Promise, I can chain the >>>>>>> promises without >>>>>>> >>> nesting functions. And since both libraries use Promise, I can >>>>>>> use catch() >>>>>>> >>> at the end for unified error handling whether the error comes >>>>>>> from the >>>>>>> >>> Keycloak adapter or from the call to fetch(). >>>>>>> >>> >>>>>>> >>> >>>>>>> >>> [1] http://caniuse.com/#search=Promise >>>>>>> >>> [2] https://developer.mozilla.org/en-US/docs/Web/JavaScript/ >>>>>>> >>> Guide/Using_promises >>>>>>> >>> >>>>>>> >>> >>>>>>> >>> On Tue, Sep 5, 2017 at 6:18 AM, Stian Thorgersen < >>>>>>> sthorger at redhat.com> >>>>>>> >>> wrote: >>>>>>> >>> >>>>>>> >>>> I don't know much about ES6 native Promises. Can you give me >>>>>>> some >>>>>>> >>>> details about it? What browser support it? What are the >>>>>>> benefits of using >>>>>>> >>>> that instead of our howegrown approach? Etc. >>>>>>> >>>> >>>>>>> >>>> On 4 September 2017 at 20:36, Raymond DeCampo >>>>>>> wrote: >>>>>>> >>>> >>>>>>> >>>>> Hello all, >>>>>>> >>>>> >>>>>>> >>>>> I create a wrapper around the javascript adapter which uses >>>>>>> ES6 native >>>>>>> >>>>> Promises. (https://github.com/RayDeCampo/keycloak-promise). >>>>>>> >>>>> >>>>>>> >>>>> If you are interested, I can re-package it for inclusion in >>>>>>> Keycloak >>>>>>> >>>>> and >>>>>>> >>>>> create a pull request on GitHub. If you have a different >>>>>>> process for >>>>>>> >>>>> contributions, let me know. >>>>>>> >>>>> >>>>>>> >>>>> If you are not interested, no hard feelings. >>>>>>> >>>>> >>>>>>> >>>>> Thanks, >>>>>>> >>>>> Ray >>>>>>> >>>>> _______________________________________________ >>>>>>> >>>>> 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 Sep 26 03:24:49 2017 From: sthorger at redhat.com (Stian Thorgersen) Date: Tue, 26 Sep 2017 09:24:49 +0200 Subject: [keycloak-dev] rename client templates to scope? In-Reply-To: References: Message-ID: Interesting idea. That might just work and be a nice and easy way to add proper support for OAuth/OIDC scope. On 25 September 2017 at 17:11, Bill Burke wrote: > This is something for 4.0 > > Was thinking that we should rename Client Templates to Client Scopes. > For oauth, oidc, and token exchange client asks for a specific scope > with the "scope" parameter. This "scope" parameter would be the name > of a client-id or a client scope (formerly client emplates. Clients > will be granted access to scopes in the admin console. Probably > through authz services. > > > > -- > 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 Tue Sep 26 03:27:31 2017 From: sthorger at redhat.com (Stian Thorgersen) Date: Tue, 26 Sep 2017 09:27:31 +0200 Subject: [keycloak-dev] Promise wrapper for javascript adapter In-Reply-To: References: Message-ID: Looks good. I reckon that would work and we wouldn't even have to worry about deprecation as that looks like it could just stay like that without any issues. On 26 September 2017 at 03:33, Raymond DeCampo wrote: > I think maybe we are making this too complicated. Since this is JS, we > could take a native Promise instance and add the methods defined by the > existing promise return value. Then it would work using the existing > callbacks or using standard Promise methods. > > Something like: > > if (typeof Promise === "function") { > var promise = new Promise(...); > promise.success = function(callback) { ... }; > promise.error = function(callback) { ... }; > } else { > // return existing custom promise object > } > > > > > On Mon, Sep 25, 2017 at 7:36 AM, Stian Thorgersen > wrote: > >> No, I'd be looking for a PR where keycloak.js uses standard promises >> internally, but will return a wrapper for the promises that uses the legacy >> api. There will be a config option that can be enabled to return standard >> promises instead. After a few releases we make it return standard promises, >> then finally after a few more releases we remove the legacy wrapper >> completely. >> >> On 22 September 2017 at 13:44, Raymond DeCampo wrote: >> >>> So the next step is "deprecate and replace with standard"? So you would >>> be looking for a pull request where keycloak.js is modified to return >>> standard native Promises and the existing keycloak.js is moved to something >>> like keycloak-legacy.js? >>> >>> On Wed, Sep 20, 2017 at 11:36 AM, Stian Thorgersen >>> wrote: >>> >>>> +1 If we do promises that would be the only useful way to do it. >>>> Standard promises wrapped to become wrapped. Have custom promises as >>>> default initially. Deprecate and switch to standard after a while and >>>> finally remove completely. >>>> >>>> >>>> On 18 Sep 2017 6:16 pm, "Niels Bertram" wrote: >>>> >>>>> No, I'd be looking for a PR where keycloak.js uses standard promises >>>>> internally, but will return a wrapper for the promises that uses the legacy >>>>> api. There will be a config option that can be enabled to return standard >>>>> promises instead. After a few releases we make it return standard promises, >>>>> then finally after a few more releases we remove the legacy wrapper >>>>> completely. >>>>> >>>>> On 22 September 2017 at 13:44, Raymond DeCampo >>>>> wrote: >>>>> >>>>>> So the next step is "deprecate and replace with standard"? So you >>>>>> would be looking for a pull request where keycloak.js is modified to return >>>>>> standard native Promises and the existing keycloak.js is moved to something >>>>>> like keycloak-legacy.js? >>>>>> >>>>>> On Wed, Sep 20, 2017 at 11:36 AM, Stian Thorgersen < >>>>>> sthorger at redhat.com> wrote: >>>>>> >>>>>>> +1 If we do promises that would be the only useful way to do it. >>>>>>> Standard promises wrapped to become wrapped. Have custom promises as >>>>>>> default initially. Deprecate and switch to standard after a while and >>>>>>> finally remove completely. >>>>>>> >>>>>>> >>>>>>> On 18 Sep 2017 6:16 pm, "Niels Bertram" wrote: >>>>>>> >>>>>>> Hmm ... I was actally looking at the js libraries (browser and node >>>>>>> ones) a short while ago and thought the same thing, why not use a A+ >>>>>>> compliant promise [1] instead of the custom thingy. It is hard to follow >>>>>>> custom logic when basic concepts exist and are understood. >>>>>>> >>>>>>> Why not implement standard promises in the main library and write a >>>>>>> wrapper for the custom promises. Then mark those for deprecation and retire >>>>>>> them in a few releases. I think mongoose did this some time back with a >>>>>>> pluggable promise interface [2] to escape callback hell. >>>>>>> >>>>>>> I think this would improve the adoptability of the adapters given >>>>>>> lots of folks don't fully understand OIDC and throw things in the too hard >>>>>>> basket as soon as they are given the slightest opportunity - real world >>>>>>> experience. >>>>>>> >>>>>>> Cheers Niels >>>>>>> >>>>>>> [1] https://promisesaplus.com >>>>>>> [2] http://mongoosejs.com/docs/promises.html >>>>>>> >>>>>>> On 18 Sep. 2017 4:44 am, "Stian Thorgersen" >>>>>>> wrote: >>>>>>> >>>>>>>> I don't like the idea of having a wrapper as it needs updating >>>>>>>> separately >>>>>>>> when anything changes. If it's a different library I believe it'll >>>>>>>> just be >>>>>>>> forgotten about and also be annoying boilerplate to maintain. >>>>>>>> That's why >>>>>>>> I'd rather just have it return a different promise object depending >>>>>>>> on what >>>>>>>> config option is used. There's not that many places internally where >>>>>>>> promises objects are used, so we can probably find a reasonable way >>>>>>>> to do >>>>>>>> that. >>>>>>>> >>>>>>>> That being said I'm wondering if this is actually a case where this >>>>>>>> is just >>>>>>>> another way of doing something that won't actually be used. AFAIK >>>>>>>> no one >>>>>>>> else have asked for this nor have we seen anyone else comment on >>>>>>>> this >>>>>>>> thread. So maybe the best option here is to just leave it as is? >>>>>>>> >>>>>>>> On 13 September 2017 at 14:31, Raymond DeCampo >>>>>>>> wrote: >>>>>>>> >>>>>>>> > I understand the concern about increasing the test surface. >>>>>>>> > >>>>>>>> > However I don't think that introducing a configuration option and >>>>>>>> having >>>>>>>> > methods that return different objects based on the option will >>>>>>>> decrease the >>>>>>>> > testing risk. There are places in the keycloak.js where it >>>>>>>> invokes it's >>>>>>>> > own methods and uses the custom promise object, for example: >>>>>>>> > >>>>>>>> > https://github.com/keycloak/keycloak/blob/b7af96aa4d7daeec6d >>>>>>>> a12ee9326d1c >>>>>>>> > 0fdcc4850f/adapters/oidc/js/src/main/resources/keycloak.js#L >>>>>>>> 128-L131 >>>>>>>> > >>>>>>>> > >>>>>>>> > kc.login(options).success(function () { >>>>>>>> > initPromise.setSuccess(); >>>>>>>> > }).error(function () { >>>>>>>> > initPromise.setError(); >>>>>>>> > }); >>>>>>>> > >>>>>>>> > >>>>>>>> > So these places would have to change based on the configuration >>>>>>>> option and >>>>>>>> > I think it will become a bigger problem. >>>>>>>> > >>>>>>>> > What if instead we add a method on the Keycloak object which >>>>>>>> returns a >>>>>>>> > wrapper instance using Promises and keep everything in the one >>>>>>>> keycloak.js >>>>>>>> > file? So clients could do: >>>>>>>> > >>>>>>>> > var keycloak = new Keycloak().promiseWrapper(); >>>>>>>> > >>>>>>>> > keycloak.init().then(function() { ... }); >>>>>>>> > >>>>>>>> > >>>>>>>> > And everything is in the one file? >>>>>>>> > >>>>>>>> > >>>>>>>> > Although let me make one more pitch on the merits of my original >>>>>>>> > suggestion: >>>>>>>> > >>>>>>>> > >>>>>>>> > 1. No changes to keycloak.js => less risk of breaking >>>>>>>> something that >>>>>>>> > already works >>>>>>>> > 2. The KeycloakPromise implementation delegates to the >>>>>>>> keycloak.js >>>>>>>> >>>>>>>> > implementation which means that fixes to keycloak.js >>>>>>>> automatically >>>>>>>> > propogate. >>>>>>>> > 3. The KeycloakPromise implementation is a wrapper which means >>>>>>>> it only >>>>>>>> >>>>>>>> > needs to be changed if there is a change to the keycloak.js >>>>>>>> API, e.g. a new >>>>>>>> > method or a new argument to a method (but not a new option on >>>>>>>> an existing >>>>>>>> > argument) >>>>>>>> > 4. I think it will be clearer to document the interfaces for >>>>>>>> the end >>>>>>>> >>>>>>>> > user but of course that is a matter of opinion. >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > On Tue, Sep 12, 2017 at 11:28 PM, Stian Thorgersen < >>>>>>>> sthorger at redhat.com> >>>>>>>> > wrote: >>>>>>>> > >>>>>>>> >> I can see how it would be nice. I'm a bit worried that the >>>>>>>> separate >>>>>>>> >> javascript file would simply get out of date and it would also >>>>>>>> need >>>>>>>> >> separate testing. We're already lacking a bit on testing of the >>>>>>>> JS adapter >>>>>>>> >> in the first place and this would be yet another thing to test. >>>>>>>> Is there a >>>>>>>> >> way we could simply have a config option in the current >>>>>>>> javascript adapter >>>>>>>> >> that allows setting what promise to return? That way it's >>>>>>>> probably just a >>>>>>>> >> few lines in keycloak.js where it's creating the promise objects >>>>>>>> to switch >>>>>>>> >> between the two? >>>>>>>> >> >>>>>>>> >> On 5 September 2017 at 05:58, Raymond DeCampo >>>>>>>> wrote: >>>>>>>> >> >>>>>>>> >>> First, if I were to integrate Promise support into the >>>>>>>> Keycloak, I would >>>>>>>> >>> be leaving the current javascript adapter as is. This would be >>>>>>>> an >>>>>>>> >>> extension in a separate javascript file so that only developers >>>>>>>> who are >>>>>>>> >>> interested would get the Promise interface. Existing code >>>>>>>> using the >>>>>>>> >>> current adapter would be unaffected. The new code would be a >>>>>>>> wrapper >>>>>>>> >>> around the existing code so that maintenance would only be >>>>>>>> required if the >>>>>>>> >>> javascript adapter API changes. >>>>>>>> >>> >>>>>>>> >>> In terms of browser support, caniuse.com[1] indicates that >>>>>>>> Promise has >>>>>>>> >>> broad support; only IE 11 and Opera Mini fail to support >>>>>>>> Promise. However >>>>>>>> >>> polyfills are available to provide support. >>>>>>>> >>> >>>>>>>> >>> As far as the advantages, the main ones as I see it are: 1) >>>>>>>> using the >>>>>>>> >>> standard promise API makes it easier for developers new to the >>>>>>>> library; 2) >>>>>>>> >>> using the standard promise API makes the library more >>>>>>>> interoperable with >>>>>>>> >>> other libraries; and 3) ES6 Promise objects are chainable >>>>>>>> making sequences >>>>>>>> >>> of asynchronous calls cleaner to code. >>>>>>>> >>> >>>>>>>> >>> I think the MDN page on Using Promises[2] probably makes a >>>>>>>> better >>>>>>>> >>> argument for than I'll be able to here. But the main thrust is >>>>>>>> that >>>>>>>> >>> chaining makes it so it is not necessary to have so many nested >>>>>>>> functions. >>>>>>>> >>> >>>>>>>> >>> For example, suppose I am writing a javascript client for a >>>>>>>> REST API >>>>>>>> >>> protected by Keycloak. Since the built-in fetch() method >>>>>>>> returns a Promise >>>>>>>> >>> with ES6 Promises I can write: >>>>>>>> >>> >>>>>>>> >>> // assume authz.updateToken() returns an ES6 Promise >>>>>>>> >>> authz.updateToken(5).then((token) => { >>>>>>>> >>> return fetch(this.ENDPOINT, { >>>>>>>> >>> redirect: 'error', >>>>>>>> >>> headers: { "Authorization": "Bearer " + token } >>>>>>>> >>> }); >>>>>>>> >>> }).then((response) => { >>>>>>>> >>> showResult(response.text()); >>>>>>>> >>> }).catch((error) => { >>>>>>>> >>> displayError(error); >>>>>>>> >>> }); >>>>>>>> >>> } >>>>>>>> >>> >>>>>>>> >>> Since everything is standard, any JS developer would understand >>>>>>>> the >>>>>>>> >>> code. Since both libraries use Promise, I can chain the >>>>>>>> promises without >>>>>>>> >>> nesting functions. And since both libraries use Promise, I can >>>>>>>> use catch() >>>>>>>> >>> at the end for unified error handling whether the error comes >>>>>>>> from the >>>>>>>> >>> Keycloak adapter or from the call to fetch(). >>>>>>>> >>> >>>>>>>> >>> >>>>>>>> >>> [1] http://caniuse.com/#search=Promise >>>>>>>> >>> [2] https://developer.mozilla.org/en-US/docs/Web/JavaScript/ >>>>>>>> >>> Guide/Using_promises >>>>>>>> >>> >>>>>>>> >>> >>>>>>>> >>> On Tue, Sep 5, 2017 at 6:18 AM, Stian Thorgersen < >>>>>>>> sthorger at redhat.com> >>>>>>>> >>> wrote: >>>>>>>> >>> >>>>>>>> >>>> I don't know much about ES6 native Promises. Can you give me >>>>>>>> some >>>>>>>> >>>> details about it? What browser support it? What are the >>>>>>>> benefits of using >>>>>>>> >>>> that instead of our howegrown approach? Etc. >>>>>>>> >>>> >>>>>>>> >>>> On 4 September 2017 at 20:36, Raymond DeCampo >>>>>>>> wrote: >>>>>>>> >>>> >>>>>>>> >>>>> Hello all, >>>>>>>> >>>>> >>>>>>>> >>>>> I create a wrapper around the javascript adapter which uses >>>>>>>> ES6 native >>>>>>>> >>>>> Promises. (https://github.com/RayDeCampo/keycloak-promise). >>>>>>>> >>>>> >>>>>>>> >>>>> If you are interested, I can re-package it for inclusion in >>>>>>>> Keycloak >>>>>>>> >>>>> and >>>>>>>> >>>>> create a pull request on GitHub. If you have a different >>>>>>>> process for >>>>>>>> >>>>> contributions, let me know. >>>>>>>> >>>>> >>>>>>>> >>>>> If you are not interested, no hard feelings. >>>>>>>> >>>>> >>>>>>>> >>>>> Thanks, >>>>>>>> >>>>> Ray >>>>>>>> >>>>> _______________________________________________ >>>>>>>> >>>>> 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 juandiego83 at gmail.com Tue Sep 26 16:37:16 2017 From: juandiego83 at gmail.com (Juan Diego) Date: Tue, 26 Sep 2017 15:37:16 -0500 Subject: [keycloak-dev] Problems with authorization at creating user with admin rest api Message-ID: Hi I am trying manage users from my java back-end. I just created a user in my master realm, added a client role of myrealm-realm to that user. I added manage-client, manage-users, view-user, view-realm to the assigned roles. But I get this, Caused by: javax.ws.rs.NotAuthorizedException: HTTP 401 Unauthorized So I tried with my main admin user(the one created when I installed), and it logs. And I get status 403. What permission should I add. What am I missing? https://gist.github.com/thomasdarimont/43689aefb37540624e35 Thanks From thomas.darimont at googlemail.com Wed Sep 27 04:45:23 2017 From: thomas.darimont at googlemail.com (Thomas Darimont) Date: Wed, 27 Sep 2017 10:45:23 +0200 Subject: [keycloak-dev] Problems with authorization at creating user with admin rest api In-Reply-To: References: Message-ID: Hello Juan, this is more a question for the keycloak-user mailing list. Apart form that you need to assign the "manage-user" (and potentially view-clients) role for realm-management. Cheers, Thomas 2017-09-26 22:37 GMT+02:00 Juan Diego : > Hi > > I am trying manage users from my java back-end. > > I just created a user in my master realm, added a client role of > myrealm-realm to that user. I added manage-client, manage-users, view-user, > view-realm to the assigned roles. > > But I get this, > > Caused by: javax.ws.rs.NotAuthorizedException: HTTP 401 Unauthorized > > So I tried with my main admin user(the one created when I installed), and > it logs. > > And I get status 403. What permission should I add. What am I missing? > > https://gist.github.com/thomasdarimont/43689aefb37540624e35 > > Thanks > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > From carl-kristian.eriksen at telia.no Wed Sep 27 05:45:57 2017 From: carl-kristian.eriksen at telia.no (carl-kristian.eriksen at telia.no) Date: Wed, 27 Sep 2017 09:45:57 +0000 Subject: [keycloak-dev] KEYCLOAK-5032 - Implementation question Message-ID: <890BFF49-124B-4099-8D3F-4430EAAA6ABF@Telia.no> https://issues.jboss.org/browse/KEYCLOAK-5032 describes two requested query parameters: acr_values and nonce Our requirements are for acr_values and prompt, and I?m working on a pull request for these two. How many pull requests do you want? Should I make sure that (each)PR includes support for one, two or three query parameters Can the ?prompt? parameter be added to KEYCLOAK-5032, or do I need another Jira task for the ?prompt? parameter? Br / mvh Carl Kristian Eriksen t: +47 95147848 VEGA / GDPR / Access Management Infrastructure Telia Norge AS From velias at redhat.com Wed Sep 27 09:20:40 2017 From: velias at redhat.com (Vlastimil Elias) Date: Wed, 27 Sep 2017 15:20:40 +0200 Subject: [keycloak-dev] Allow additional attributes to be pushed into Freemarker templates (login and account themes) by extension developers Message-ID: <7fc947a7-f244-dd28-0e8c-b3d8b19fb063@redhat.com> Hi, I was asked by Stian to post my proposal around https://issues.jboss.org/browse/KEYCLOAK-2671 to be discussed here with wider KC dev team. What we need is to pass some additional attributes into Login and Account freemarker templates as part of our extensions? - eg. to configure client side validations for registration form based on actual authentication session. Other use case we need is selection of Theme based on calling client. There are already Login and Account Form providers which may be customized (they are SPI), only problem is that current Freemarker providers use private fields and methods, so it is hard to customize them (I have to copy complete code which is hardly maintainable during keycloak upgrades). I believe we should resolve the problem by small refactoring of existing FreeMarkerLoginProvider and FreeMarkerAccountProvider providers similar you already done in FreeMarkerEmailTemplateProvider. So things like: * change fields and methods from private to protected to allow use/override in subclasses * refactor some features to protected methods (eg. Template loading from template provider - again, you did it in FreeMarkerEmailTemplateProvider provider already) to allow override in subclasses * add one protected callback method called just before template and attributes are passed to the freemarker engine for the processing - this allow subclass simply add additional attributes to be passed into template Only bigger change (and blocker for one of our important features) is passing of current AuthenticationSessionModel to the LoginFormsProvider instance at all places where the form provider is called. This is really missing now to be able customize GUI based on current client and authentication flow needs. I don't think those are big changes, but they will make life of extension developers much easier. I believe I'm able to provide pull request for this change if no better solution will be found there by experienced KC dev team. Thanks a lot in advance for any comments to my proposal. Vlastimil -- Vlastimil Elias Principal Software Engineer, Middleware Engineering Services Red Hat From juandiego83 at gmail.com Wed Sep 27 10:52:20 2017 From: juandiego83 at gmail.com (Juan Diego) Date: Wed, 27 Sep 2017 09:52:20 -0500 Subject: [keycloak-dev] Problems with authorization at creating user with admin rest api In-Reply-To: References: Message-ID: Ok thanks sorry about that. I think it was versi?n mismatch with my library El 27 sept. 2017 3:45 a. m., "Thomas Darimont" < thomas.darimont at googlemail.com> escribi?: > Hello Juan, > > this is more a question for the keycloak-user mailing list. > > Apart form that you need to assign the "manage-user" (and potentially > view-clients) role for realm-management. > > Cheers, > Thomas > > 2017-09-26 22:37 GMT+02:00 Juan Diego : > >> Hi >> >> I am trying manage users from my java back-end. >> >> I just created a user in my master realm, added a client role of >> myrealm-realm to that user. I added manage-client, manage-users, >> view-user, >> view-realm to the assigned roles. >> >> But I get this, >> >> Caused by: javax.ws.rs.NotAuthorizedException: HTTP 401 Unauthorized >> >> So I tried with my main admin user(the one created when I installed), and >> it logs. >> >> And I get status 403. What permission should I add. What am I missing? >> >> https://gist.github.com/thomasdarimont/43689aefb37540624e35 >> >> Thanks >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> > > From bburke at redhat.com Wed Sep 27 13:38:19 2017 From: bburke at redhat.com (Bill Burke) Date: Wed, 27 Sep 2017 13:38:19 -0400 Subject: [keycloak-dev] rename client templates to scope? In-Reply-To: References: Message-ID: Maybe want to allow client scopes to define their own roles too. Then we have a role namespace as well. Could even think about removing realm roles if we do this. On Tue, Sep 26, 2017 at 3:24 AM, Stian Thorgersen wrote: > Interesting idea. That might just work and be a nice and easy way to add > proper support for OAuth/OIDC scope. > > On 25 September 2017 at 17:11, Bill Burke wrote: >> >> This is something for 4.0 >> >> Was thinking that we should rename Client Templates to Client Scopes. >> For oauth, oidc, and token exchange client asks for a specific scope >> with the "scope" parameter. This "scope" parameter would be the name >> of a client-id or a client scope (formerly client emplates. Clients >> will be granted access to scopes in the admin console. Probably >> through authz services. >> >> >> >> -- >> 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 Thu Sep 28 03:35:27 2017 From: sthorger at redhat.com (Stian Thorgersen) Date: Thu, 28 Sep 2017 09:35:27 +0200 Subject: [keycloak-dev] rename client templates to scope? In-Reply-To: References: Message-ID: Interesting. So client templates could become a very flexible thing that covers many uses. So one single concept could cover: * Templates as today * Scope * Namespaces I like the idea, but the devil is in the details. How would it end up looking. Would it be easy to use. On 27 September 2017 at 19:38, Bill Burke wrote: > Maybe want to allow client scopes to define their own roles too. Then > we have a role namespace as well. Could even think about removing > realm roles if we do this. > > On Tue, Sep 26, 2017 at 3:24 AM, Stian Thorgersen > wrote: > > Interesting idea. That might just work and be a nice and easy way to add > > proper support for OAuth/OIDC scope. > > > > On 25 September 2017 at 17:11, Bill Burke wrote: > >> > >> This is something for 4.0 > >> > >> Was thinking that we should rename Client Templates to Client Scopes. > >> For oauth, oidc, and token exchange client asks for a specific scope > >> with the "scope" parameter. This "scope" parameter would be the name > >> of a client-id or a client scope (formerly client emplates. Clients > >> will be granted access to scopes in the admin console. Probably > >> through authz services. > >> > >> > >> > >> -- > >> 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 thomas.darimont at googlemail.com Thu Sep 28 04:11:41 2017 From: thomas.darimont at googlemail.com (Thomas Darimont) Date: Thu, 28 Sep 2017 10:11:41 +0200 Subject: [keycloak-dev] Incompatiblity of UserRepresentation (and other Reps) between 2.5.5.Final and 3.3.0.CR2 Message-ID: Hello, I just noticed that it isn't possible to create a user with the old keycloak admin client (2.5.5.Final) on the Keycloak Server (3.3.0.CR2). See the exception below. It turns out that the recently introduced field "notBefore" on UserRepresentation in KEYCLOAK-5293 is the cause. Other representations like ClientRepresentation (unknown field "access") and ProviderRepresentation (unknown field "order") have the same problem. How about adding... @JsonIgnoreProperties(ignoreUnknown = true) ... to all representations (org.keycloak.representations.idm.*) to stay backwards compatible for old clients? I gave this a spin locally (by patching the keycloak-core jar) and it is working fine. Cheers, Thomas javax.ws.rs.client.ResponseProcessingException: javax.ws.rs.ProcessingException: com.fasterxml.jackson.databind.exc.UnrecognizedPropertyException: Unrecognized field "notBefore" (class org.keycloak.representations.idm.UserRepresentation), not marked as ignorable (24 known properties: "disableableCredentialTypes", "enabled", "emailVerified", "origin", "self", "applicationRoles", "createdTimestamp", "clientRoles", "groups", "username", "totp", "id", "email", "federationLink", "serviceAccountClientId", "lastName", "clientConsents", "socialLinks", "realmRoles", "attributes", "firstName", "credentials", "requiredActions", "federatedIdentities"]) at [Source: org.apache.http.conn.EofSensorInputStream at 2663e964; line: 1, column: 308] (through reference chain: java.util.ArrayList[0]->org.keycloak.representations.idm.UserRepresentation["notBefore"]) at org.jboss.resteasy.client.jaxrs.internal.ClientInvocation.extractResult(ClientInvocation.java:141) at org.jboss.resteasy.client.jaxrs.internal.proxy.extractors.BodyEntityExtractor.extractEntity(BodyEntityExtractor.java:59) at org.jboss.resteasy.client.jaxrs.internal.proxy.ClientInvoker.invoke(ClientInvoker.java:104) at org.jboss.resteasy.client.jaxrs.internal.proxy.ClientProxy.invoke(ClientProxy.java:64) at com.sun.proxy.$Proxy32.search(Unknown Source) From sthorger at redhat.com Thu Sep 28 06:13:05 2017 From: sthorger at redhat.com (Stian Thorgersen) Date: Thu, 28 Sep 2017 12:13:05 +0200 Subject: [keycloak-dev] Incompatiblity of UserRepresentation (and other Reps) between 2.5.5.Final and 3.3.0.CR2 In-Reply-To: References: Message-ID: Would be good to have backwards compatibility, but: * Adding to reps wouldn't help for admin client 2.5.5, and we're not doing a new release of the admin client for 2.5.x. * Server side shouldn't ignore unknown fields as that could mask issues. For instance a typing error would just result in ignoring rather than an error. On 28 September 2017 at 10:11, Thomas Darimont < thomas.darimont at googlemail.com> wrote: > Hello, > > I just noticed that it isn't possible to create a user with the old > keycloak admin client (2.5.5.Final) > on the Keycloak Server (3.3.0.CR2). See the exception below. > > It turns out that the recently introduced field "notBefore" on > UserRepresentation in KEYCLOAK-5293 is the cause. > Other representations like ClientRepresentation (unknown field "access") > and ProviderRepresentation (unknown field "order") > have the same problem. > > How about adding... @JsonIgnoreProperties(ignoreUnknown = true) ... to all > representations (org.keycloak.representations.idm.*) to stay backwards > compatible for old clients? > > I gave this a spin locally (by patching the keycloak-core jar) and it is > working fine. > > Cheers, > Thomas > > > javax.ws.rs.client.ResponseProcessingException: > javax.ws.rs.ProcessingException: > com.fasterxml.jackson.databind.exc.UnrecognizedPropertyException: > Unrecognized field "notBefore" (class > org.keycloak.representations.idm.UserRepresentation), not marked as > ignorable (24 known properties: "disableableCredentialTypes", "enabled", > "emailVerified", "origin", "self", "applicationRoles", "createdTimestamp", > "clientRoles", "groups", "username", "totp", "id", "email", > "federationLink", "serviceAccountClientId", "lastName", "clientConsents", > "socialLinks", "realmRoles", "attributes", "firstName", "credentials", > "requiredActions", "federatedIdentities"]) > at [Source: org.apache.http.conn.EofSensorInputStream at 2663e964; line: 1, > column: 308] (through reference chain: > java.util.ArrayList[0]->org.keycloak.representations.idm. > UserRepresentation["notBefore"]) > at > org.jboss.resteasy.client.jaxrs.internal.ClientInvocation.extractResult( > ClientInvocation.java:141) > at > org.jboss.resteasy.client.jaxrs.internal.proxy.extractors. > BodyEntityExtractor.extractEntity(BodyEntityExtractor.java:59) > at > org.jboss.resteasy.client.jaxrs.internal.proxy.ClientInvoker.invoke( > ClientInvoker.java:104) > at > org.jboss.resteasy.client.jaxrs.internal.proxy.ClientProxy.invoke( > ClientProxy.java:64) > at com.sun.proxy.$Proxy32.search(Unknown Source) > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > From psilva at redhat.com Thu Sep 28 08:52:46 2017 From: psilva at redhat.com (Pedro Igor Silva) Date: Thu, 28 Sep 2017 09:52:46 -0300 Subject: [keycloak-dev] rename client templates to scope? In-Reply-To: References: Message-ID: I think all these concepts under a single umbrella is confusing. Regarding roles and scopes .... IMO, roles and scopes are separated things. It would be nice if we had a specific area for Scope Mapping, where from there I could create scopes and manage their configuration (consent, param required, etc), associate scopes with roles (and not turn roles into scopes) and associate mappers with scopes. And also push scopes into a separated claim within tokens. On Thu, Sep 28, 2017 at 4:35 AM, Stian Thorgersen wrote: > Interesting. So client templates could become a very flexible thing that > covers many uses. So one single concept could cover: > > * Templates as today > * Scope > * Namespaces > > I like the idea, but the devil is in the details. How would it end up > looking. Would it be easy to use. > > On 27 September 2017 at 19:38, Bill Burke wrote: > > > Maybe want to allow client scopes to define their own roles too. Then > > we have a role namespace as well. Could even think about removing > > realm roles if we do this. > > > > On Tue, Sep 26, 2017 at 3:24 AM, Stian Thorgersen > > wrote: > > > Interesting idea. That might just work and be a nice and easy way to > add > > > proper support for OAuth/OIDC scope. > > > > > > On 25 September 2017 at 17:11, Bill Burke wrote: > > >> > > >> This is something for 4.0 > > >> > > >> Was thinking that we should rename Client Templates to Client Scopes. > > >> For oauth, oidc, and token exchange client asks for a specific scope > > >> with the "scope" parameter. This "scope" parameter would be the name > > >> of a client-id or a client scope (formerly client emplates. Clients > > >> will be granted access to scopes in the admin console. Probably > > >> through authz services. > > >> > > >> > > >> > > >> -- > > >> 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 ksagathi at redhat.com Thu Sep 28 09:05:21 2017 From: ksagathi at redhat.com (Kishan Sagathiya) Date: Thu, 28 Sep 2017 18:35:21 +0530 Subject: [keycloak-dev] regarding expired sessions and token life-span Message-ID: Hi, I am trying to figure out how Keycloak deals with expired sessions and how token lifespan affects Keycloak database size and performance. But I dont understand the directory structure and where to find the relevant code. If someone could give some pointers regarding this that would be great Thanks :) -Kishan Sagathiya From Sebastian.Schuster at bosch-si.com Thu Sep 28 09:38:24 2017 From: Sebastian.Schuster at bosch-si.com (Schuster Sebastian (INST/ESY1)) Date: Thu, 28 Sep 2017 13:38:24 +0000 Subject: [keycloak-dev] rename client templates to scope? In-Reply-To: References: Message-ID: <73f36e62093048738e8376b94fa9540b@FE-MBX1028.de.bosch.com> Although unifying all of this is probably very elegant from a code perspective, I agree with Pedro. For me scopes and roles are two different concepts. Scopes being mainly for the external client/user view. Especially when you look into the direction of GDPR or UMA 2.0 client scopes, they could be a means to describe privacy-relevant information (e.g. what kind of data, the purpose of accessing it, associated descriptions). Latest at that point, still calling this role and managing it the same way as roles will probably be very confusing... 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.-Ing. Rainer Kallenbach, Michael Hahn -----Original Message----- From: keycloak-dev-bounces at lists.jboss.org [mailto:keycloak-dev-bounces at lists.jboss.org] On Behalf Of Pedro Igor Silva Sent: Donnerstag, 28. September 2017 14:53 To: Thorgersen, Stian Cc: keycloak-dev Subject: Re: [keycloak-dev] rename client templates to scope? I think all these concepts under a single umbrella is confusing. Regarding roles and scopes .... IMO, roles and scopes are separated things. It would be nice if we had a specific area for Scope Mapping, where from there I could create scopes and manage their configuration (consent, param required, etc), associate scopes with roles (and not turn roles into scopes) and associate mappers with scopes. And also push scopes into a separated claim within tokens. On Thu, Sep 28, 2017 at 4:35 AM, Stian Thorgersen wrote: > Interesting. So client templates could become a very flexible thing > that covers many uses. So one single concept could cover: > > * Templates as today > * Scope > * Namespaces > > I like the idea, but the devil is in the details. How would it end up > looking. Would it be easy to use. > > On 27 September 2017 at 19:38, Bill Burke wrote: > > > Maybe want to allow client scopes to define their own roles too. > > Then we have a role namespace as well. Could even think about > > removing realm roles if we do this. > > > > On Tue, Sep 26, 2017 at 3:24 AM, Stian Thorgersen > > > > wrote: > > > Interesting idea. That might just work and be a nice and easy way > > > to > add > > > proper support for OAuth/OIDC scope. > > > > > > On 25 September 2017 at 17:11, Bill Burke wrote: > > >> > > >> This is something for 4.0 > > >> > > >> Was thinking that we should rename Client Templates to Client Scopes. > > >> For oauth, oidc, and token exchange client asks for a specific > > >> scope with the "scope" parameter. This "scope" parameter would > > >> be the name of a client-id or a client scope (formerly client > > >> emplates. Clients will be granted access to scopes in the admin > > >> console. Probably through authz services. > > >> > > >> > > >> > > >> -- > > >> 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 > _______________________________________________ keycloak-dev mailing list keycloak-dev at lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-dev From wadahiro at gmail.com Thu Sep 28 10:25:49 2017 From: wadahiro at gmail.com (Hiroyuki Wada) Date: Thu, 28 Sep 2017 23:25:49 +0900 Subject: [keycloak-dev] keycloak-documentation translation In-Reply-To: References: Message-ID: Hello, On Fri, Sep 8, 2017 at 2:25 AM, Bill Burke wrote: > That's great! Thank you. We can certainly link to it on our website. > We don't have the resources to translate it, even in product. Today, we just published Japanese keycloak-documentation site! http://keycloak-documentation.openstandia.jp Currently we finished translating 'Getting Started' guide only. We'll translate other documents as soon as possible. I would be grateful if you could link to this site from official site. Best Regards, -- Hiroyuki Wada, Nomura Research Institute, Ltd. > > On Thu, Sep 7, 2017 at 11:19 AM, Hiroyuki Wada wrote: >> Hello, >> >> We have a plan to translate keycloak-documentation to Japanese for the >> community at our company. >> Because there is no place to manage the translation resources in >> keycloak-documentation repository, >> we are planning to put the resources into own repository and publish >> the built documents to our corporate site. >> Do you have any concerns? >> Of course, we can contribute it if there are any plans to translate it >> officially. >> >> Best Regards, >> >> -- >> Hiroyuki Wada, >> Nomura Research Institute, Ltd. >> _______________________________________________ >> 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 Fri Sep 29 03:12:35 2017 From: sthorger at redhat.com (Stian Thorgersen) Date: Fri, 29 Sep 2017 09:12:35 +0200 Subject: [keycloak-dev] rename client templates to scope? In-Reply-To: <73f36e62093048738e8376b94fa9540b@FE-MBX1028.de.bosch.com> References: <73f36e62093048738e8376b94fa9540b@FE-MBX1028.de.bosch.com> Message-ID: The term "scope" has two meanings within Keycloak. That's confusing. Firstly scope means a "client is allowed to get this role", but then there's the other meaning coming from OAuth which means "client is requesting access to this set of resources". So let's call them "roles scope" for the first and "oauth scope" for the second in this mail to remove confusion around that. With regards to Bill's suggestion I don't find it confusing at all. A "client template" is really only a grouping mechanism for protocol mappers, roles and "role scopes". It's currently only used to allow clients to share this config, but if you think about what properly introducing "oauth scopes" properly would mean to Keycloak it's exactly the same. It's about mapping an "oauth scope" to a group of protocol mappers, roles and "role scopes". Fits perfectly IMO ;) On 28 September 2017 at 15:38, Schuster Sebastian (INST/ESY1) < Sebastian.Schuster at bosch-si.com> wrote: > Although unifying all of this is probably very elegant from a code > perspective, I agree with Pedro. For me scopes and roles are two different > concepts. Scopes being mainly for the external client/user view. Especially > when you look into the direction of GDPR or UMA 2.0 client scopes, they > could be a means to describe privacy-relevant information (e.g. what kind > of data, the purpose of accessing it, associated descriptions). Latest at > that point, still calling this role and managing it the same way as roles > will probably be very confusing... > > 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.-Ing. Rainer Kallenbach, Michael Hahn > > > > -----Original Message----- > From: keycloak-dev-bounces at lists.jboss.org [mailto:keycloak-dev-bounces@ > lists.jboss.org] On Behalf Of Pedro Igor Silva > Sent: Donnerstag, 28. September 2017 14:53 > To: Thorgersen, Stian > Cc: keycloak-dev > Subject: Re: [keycloak-dev] rename client templates to scope? > > I think all these concepts under a single umbrella is confusing. > > Regarding roles and scopes .... > > IMO, roles and scopes are separated things. It would be nice if we had a > specific area for Scope Mapping, where from there I could create scopes and > manage their configuration (consent, param required, etc), associate scopes > with roles (and not turn roles into scopes) and associate mappers with > scopes. > > And also push scopes into a separated claim within tokens. > > > On Thu, Sep 28, 2017 at 4:35 AM, Stian Thorgersen > wrote: > > > Interesting. So client templates could become a very flexible thing > > that covers many uses. So one single concept could cover: > > > > * Templates as today > > * Scope > > * Namespaces > > > > I like the idea, but the devil is in the details. How would it end up > > looking. Would it be easy to use. > > > > On 27 September 2017 at 19:38, Bill Burke wrote: > > > > > Maybe want to allow client scopes to define their own roles too. > > > Then we have a role namespace as well. Could even think about > > > removing realm roles if we do this. > > > > > > On Tue, Sep 26, 2017 at 3:24 AM, Stian Thorgersen > > > > > > wrote: > > > > Interesting idea. That might just work and be a nice and easy way > > > > to > > add > > > > proper support for OAuth/OIDC scope. > > > > > > > > On 25 September 2017 at 17:11, Bill Burke wrote: > > > >> > > > >> This is something for 4.0 > > > >> > > > >> Was thinking that we should rename Client Templates to Client > Scopes. > > > >> For oauth, oidc, and token exchange client asks for a specific > > > >> scope with the "scope" parameter. This "scope" parameter would > > > >> be the name of a client-id or a client scope (formerly client > > > >> emplates. Clients will be granted access to scopes in the admin > > > >> console. Probably through authz services. > > > >> > > > >> > > > >> > > > >> -- > > > >> 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 > > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > From sthorger at redhat.com Fri Sep 29 07:30:36 2017 From: sthorger at redhat.com (Stian Thorgersen) Date: Fri, 29 Sep 2017 13:30:36 +0200 Subject: [keycloak-dev] Allow additional attributes to be pushed into Freemarker templates (login and account themes) by extension developers In-Reply-To: <7fc947a7-f244-dd28-0e8c-b3d8b19fb063@redhat.com> References: <7fc947a7-f244-dd28-0e8c-b3d8b19fb063@redhat.com> Message-ID: Making the required methods protected is a simple way to work around the issue, but bear in mind that the FreeMarker providers are likely to change in the future. Another option could be to introduce an FreeMarkerAttributeProviderSPI, the current freemarker providers would call all available providers to allow them to add additional attributes. Something like: * registerAccountAttribute(FormContext..) * registerLoginAttribute(FormContext..) Where FormContext would have access to KeycloakSession, AuthenticationSession, etc.. Slightly more work, but would be more future proof IMO. On 27 September 2017 at 15:20, Vlastimil Elias wrote: > Hi, > > I was asked by Stian to post my proposal around > https://issues.jboss.org/browse/KEYCLOAK-2671 to be discussed here with > wider KC dev team. > > What we need is to pass some additional attributes into Login and > Account freemarker templates as part of our extensions - eg. to > configure client side validations for registration form based on actual > authentication session. Other use case we need is selection of Theme > based on calling client. > > There are already Login and Account Form providers which may be > customized (they are SPI), only problem is that current Freemarker > providers use private fields and methods, so it is hard to customize > them (I have to copy complete code which is hardly maintainable during > keycloak upgrades). > > I believe we should resolve the problem by small refactoring of existing > FreeMarkerLoginProvider and FreeMarkerAccountProvider providers similar > you already done in FreeMarkerEmailTemplateProvider. So things like: > > * change fields and methods from private to protected to allow > use/override in subclasses > * refactor some features to protected methods (eg. Template loading > from template provider - again, you did it in > FreeMarkerEmailTemplateProvider provider already) to allow override > in subclasses > * add one protected callback method called just before template and > attributes are passed to the freemarker engine for the processing - > this allow subclass simply add additional attributes to be passed > into template > > Only bigger change (and blocker for one of our important features) is > passing of current AuthenticationSessionModel to the LoginFormsProvider > instance at all places where the form provider is called. This is really > missing now to be able customize GUI based on current client and > authentication flow needs. > > I don't think those are big changes, but they will make life of > extension developers much easier. > > I believe I'm able to provide pull request for this change if no better > solution will be found there by experienced KC dev team. > > Thanks a lot in advance for any comments to my proposal. > > Vlastimil > > -- > Vlastimil Elias > Principal Software Engineer, Middleware Engineering Services > 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 Fri Sep 29 07:59:45 2017 From: mposolda at redhat.com (Marek Posolda) Date: Fri, 29 Sep 2017 13:59:45 +0200 Subject: [keycloak-dev] Single-use cache for OAuth code, Code changed to be JWE Message-ID: I've sent PR https://github.com/keycloak/keycloak/pull/4512, which implements first part of https://docs.google.com/document/d/1C1vFhyGPBOnN3pprw6XPZnK08azyTm-HVIqO9dY3aTY/edit Some details: - Partially implemented support for JWE, so we can use encrypted JWT. - OAuth code is changed to be JWT. It's encrypted and integrity-protected with AES128-CBC-HMAC-SHA256 algorithm. Code is encrypted with realm AES key (new symmetric key generated by default for every realm similar to HMAC key) and signed with HMAC key. - I've added support for AES keys, so we now have RSA, HMAC and AES keys. - Code JWT doesn't yet contain much at this moment. There is just unique ID, userSession ID, client UUID and expiration (60 seconds). Next step is to add more into it, especially notes as mentioned in the docs. - Single-use cache is used to track which codes were already used. For now, it's reusing existing "actionTokens" infinispan cache. It's using "putIfAbsent" to add codes into the cache, hence now we are sure that the particular code is really used just once. The previous approach with the note on userSession didn't allow this. I've added new testcase to ConcurrentLoginTest for check that code is used just once. It's passing for cross-dc as well, however we may allow people to save some performance with the small possibility that same code will pass on both datacenters. - Now we also pass the scenario when SSO login with same client is opened on 2 browser tabs concurrently. Also added test to ConcurrentLoginTest and it's passing for cross-dc too. Previously this scenario may not work correctly as the "code" in the clientSession note may be generated concurrently by both requests and one of them will then fail to verify. Next steps: - Continue with the stuff described in the docs https://docs.google.com/document/d/1C1vFhyGPBOnN3pprw6XPZnK08azyTm-HVIqO9dY3aTY/edit (Remove protocolMappers and roles from clientSession etc). - It should be easy to use same stuff for refreshTokens . From what I see, the performance of AES128-CBC-HMAC-SHA256 is much better than RSA and provides the encryption too. Any comments? Marek From wtrocki at redhat.com Fri Sep 29 08:20:25 2017 From: wtrocki at redhat.com (Wojciech Trocki) Date: Fri, 29 Sep 2017 13:20:25 +0100 Subject: [keycloak-dev] Javascript client mobile review Message-ID: Hi I recently made couple integrations with Keycloak on Android and IOS. During testing some problems were found around cordova adapter. Created minor fix to resolve IOS issue I have found: https://github.com/keycloak/keycloak/pull/4514 After reviewing source code I think that it will be good to allow developers to provide their own adapters. This way we will be able to made some tweaks for platforms like nativescript or react native. If you think that's good idea? I can create ticket and contribute to provide this mechanisms. Regards -- WOJCIECH TROCKI Red Hat Mobile IM: wtrocki From bburke at redhat.com Fri Sep 29 09:29:17 2017 From: bburke at redhat.com (Bill Burke) Date: Fri, 29 Sep 2017 09:29:17 -0400 Subject: [keycloak-dev] Allow additional attributes to be pushed into Freemarker templates (login and account themes) by extension developers In-Reply-To: References: <7fc947a7-f244-dd28-0e8c-b3d8b19fb063@redhat.com> Message-ID: LoginFormsProvider has a setAttribute() method. Isn't that enough? We have to let authenticator plugins drive the forms as down the road we might be required to build a SaaS which means our themes need to be secure enough to run in a multi-tenant environment. On Fri, Sep 29, 2017 at 7:30 AM, Stian Thorgersen wrote: > Making the required methods protected is a simple way to work around the > issue, but bear in mind that the FreeMarker providers are likely to change > in the future. > > Another option could be to introduce an FreeMarkerAttributeProviderSPI, the > current freemarker providers would call all available providers to allow > them to add additional attributes. Something like: > > * registerAccountAttribute(FormContext..) > * registerLoginAttribute(FormContext..) > > Where FormContext would have access to KeycloakSession, > AuthenticationSession, etc.. > > Slightly more work, but would be more future proof IMO. > > > On 27 September 2017 at 15:20, Vlastimil Elias wrote: > >> Hi, >> >> I was asked by Stian to post my proposal around >> https://issues.jboss.org/browse/KEYCLOAK-2671 to be discussed here with >> wider KC dev team. >> >> What we need is to pass some additional attributes into Login and >> Account freemarker templates as part of our extensions - eg. to >> configure client side validations for registration form based on actual >> authentication session. Other use case we need is selection of Theme >> based on calling client. >> >> There are already Login and Account Form providers which may be >> customized (they are SPI), only problem is that current Freemarker >> providers use private fields and methods, so it is hard to customize >> them (I have to copy complete code which is hardly maintainable during >> keycloak upgrades). >> >> I believe we should resolve the problem by small refactoring of existing >> FreeMarkerLoginProvider and FreeMarkerAccountProvider providers similar >> you already done in FreeMarkerEmailTemplateProvider. So things like: >> >> * change fields and methods from private to protected to allow >> use/override in subclasses >> * refactor some features to protected methods (eg. Template loading >> from template provider - again, you did it in >> FreeMarkerEmailTemplateProvider provider already) to allow override >> in subclasses >> * add one protected callback method called just before template and >> attributes are passed to the freemarker engine for the processing - >> this allow subclass simply add additional attributes to be passed >> into template >> >> Only bigger change (and blocker for one of our important features) is >> passing of current AuthenticationSessionModel to the LoginFormsProvider >> instance at all places where the form provider is called. This is really >> missing now to be able customize GUI based on current client and >> authentication flow needs. >> >> I don't think those are big changes, but they will make life of >> extension developers much easier. >> >> I believe I'm able to provide pull request for this change if no better >> solution will be found there by experienced KC dev team. >> >> Thanks a lot in advance for any comments to my proposal. >> >> Vlastimil >> >> -- >> Vlastimil Elias >> Principal Software Engineer, Middleware Engineering Services >> Red Hat >> >> _______________________________________________ >> 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 -- Bill Burke Red Hat From bburke at redhat.com Fri Sep 29 09:32:08 2017 From: bburke at redhat.com (Bill Burke) Date: Fri, 29 Sep 2017 09:32:08 -0400 Subject: [keycloak-dev] Single-use cache for OAuth code, Code changed to be JWE In-Reply-To: References: Message-ID: Looks good. Just worry about the size of the code JWT. On Fri, Sep 29, 2017 at 7:59 AM, Marek Posolda wrote: > I've sent PR https://github.com/keycloak/keycloak/pull/4512, which > implements first part of > https://docs.google.com/document/d/1C1vFhyGPBOnN3pprw6XPZnK08azyTm-HVIqO9dY3aTY/edit > > Some details: > - Partially implemented support for JWE, so we can use encrypted JWT. > > - OAuth code is changed to be JWT. It's encrypted and > integrity-protected with AES128-CBC-HMAC-SHA256 algorithm. Code is > encrypted with realm AES key (new symmetric key generated by default for > every realm similar to HMAC key) and signed with HMAC key. > > - I've added support for AES keys, so we now have RSA, HMAC and AES keys. > > - Code JWT doesn't yet contain much at this moment. There is just unique > ID, userSession ID, client UUID and expiration (60 seconds). Next step > is to add more into it, especially notes as mentioned in the docs. > > - Single-use cache is used to track which codes were already used. For > now, it's reusing existing "actionTokens" infinispan cache. It's using > "putIfAbsent" to add codes into the cache, hence now we are sure that > the particular code is really used just once. The previous approach with > the note on userSession didn't allow this. I've added new testcase to > ConcurrentLoginTest for check that code is used just once. It's passing > for cross-dc as well, however we may allow people to save some > performance with the small possibility that same code will pass on both > datacenters. > > - Now we also pass the scenario when SSO login with same client is > opened on 2 browser tabs concurrently. Also added test to > ConcurrentLoginTest and it's passing for cross-dc too. Previously this > scenario may not work correctly as the "code" in the clientSession note > may be generated concurrently by both requests and one of them will then > fail to verify. > > > Next steps: > - Continue with the stuff described in the docs > https://docs.google.com/document/d/1C1vFhyGPBOnN3pprw6XPZnK08azyTm-HVIqO9dY3aTY/edit > (Remove protocolMappers and roles from clientSession etc). > > - It should be easy to use same stuff for refreshTokens . From what I > see, the performance of AES128-CBC-HMAC-SHA256 is much better than RSA > and provides the encryption too. > > Any comments? > > Marek > > _______________________________________________ > 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 Fri Sep 29 09:43:20 2017 From: bburke at redhat.com (Bill Burke) Date: Fri, 29 Sep 2017 09:43:20 -0400 Subject: [keycloak-dev] rename client templates to scope? In-Reply-To: References: <73f36e62093048738e8376b94fa9540b@FE-MBX1028.de.bosch.com> Message-ID: Current client templates do map nicely to OAuth scopes. Where I was unsure was them additionally having a role namespace too. Our consent screen logic is a mess. We loop through every protocol mapper and role stuffed in the token to blurt out a message on the consent screen for each. Its messy, ugly, and not very easy to make it look like you want. If we have Client Scopes, then clients can consolidate mappers and roles into a consent message that covers them all. So community? Anybody interested in implementing? The tough part will be to finally get support for OAuth scopes and also to make sure that all this is backward compatible with Client Templates (migration scripts if needed). On Fri, Sep 29, 2017 at 3:12 AM, Stian Thorgersen wrote: > The term "scope" has two meanings within Keycloak. That's confusing. > Firstly scope means a "client is allowed to get this role", but then > there's the other meaning coming from OAuth which means "client is > requesting access to this set of resources". So let's call them "roles > scope" for the first and "oauth scope" for the second in this mail to > remove confusion around that. > > With regards to Bill's suggestion I don't find it confusing at all. A > "client template" is really only a grouping mechanism for protocol mappers, > roles and "role scopes". It's currently only used to allow clients to share > this config, but if you think about what properly introducing "oauth > scopes" properly would mean to Keycloak it's exactly the same. It's about > mapping an "oauth scope" to a group of protocol mappers, roles and "role > scopes". > > Fits perfectly IMO ;) > > On 28 September 2017 at 15:38, Schuster Sebastian (INST/ESY1) < > Sebastian.Schuster at bosch-si.com> wrote: > >> Although unifying all of this is probably very elegant from a code >> perspective, I agree with Pedro. For me scopes and roles are two different >> concepts. Scopes being mainly for the external client/user view. Especially >> when you look into the direction of GDPR or UMA 2.0 client scopes, they >> could be a means to describe privacy-relevant information (e.g. what kind >> of data, the purpose of accessing it, associated descriptions). Latest at >> that point, still calling this role and managing it the same way as roles >> will probably be very confusing... >> >> 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.-Ing. Rainer Kallenbach, Michael Hahn >> >> >> >> -----Original Message----- >> From: keycloak-dev-bounces at lists.jboss.org [mailto:keycloak-dev-bounces@ >> lists.jboss.org] On Behalf Of Pedro Igor Silva >> Sent: Donnerstag, 28. September 2017 14:53 >> To: Thorgersen, Stian >> Cc: keycloak-dev >> Subject: Re: [keycloak-dev] rename client templates to scope? >> >> I think all these concepts under a single umbrella is confusing. >> >> Regarding roles and scopes .... >> >> IMO, roles and scopes are separated things. It would be nice if we had a >> specific area for Scope Mapping, where from there I could create scopes and >> manage their configuration (consent, param required, etc), associate scopes >> with roles (and not turn roles into scopes) and associate mappers with >> scopes. >> >> And also push scopes into a separated claim within tokens. >> >> >> On Thu, Sep 28, 2017 at 4:35 AM, Stian Thorgersen >> wrote: >> >> > Interesting. So client templates could become a very flexible thing >> > that covers many uses. So one single concept could cover: >> > >> > * Templates as today >> > * Scope >> > * Namespaces >> > >> > I like the idea, but the devil is in the details. How would it end up >> > looking. Would it be easy to use. >> > >> > On 27 September 2017 at 19:38, Bill Burke wrote: >> > >> > > Maybe want to allow client scopes to define their own roles too. >> > > Then we have a role namespace as well. Could even think about >> > > removing realm roles if we do this. >> > > >> > > On Tue, Sep 26, 2017 at 3:24 AM, Stian Thorgersen >> > > >> > > wrote: >> > > > Interesting idea. That might just work and be a nice and easy way >> > > > to >> > add >> > > > proper support for OAuth/OIDC scope. >> > > > >> > > > On 25 September 2017 at 17:11, Bill Burke wrote: >> > > >> >> > > >> This is something for 4.0 >> > > >> >> > > >> Was thinking that we should rename Client Templates to Client >> Scopes. >> > > >> For oauth, oidc, and token exchange client asks for a specific >> > > >> scope with the "scope" parameter. This "scope" parameter would >> > > >> be the name of a client-id or a client scope (formerly client >> > > >> emplates. Clients will be granted access to scopes in the admin >> > > >> console. Probably through authz services. >> > > >> >> > > >> >> > > >> >> > > >> -- >> > > >> 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 >> > >> _______________________________________________ >> 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 -- Bill Burke Red Hat From bburke at redhat.com Fri Sep 29 09:49:26 2017 From: bburke at redhat.com (Bill Burke) Date: Fri, 29 Sep 2017 09:49:26 -0400 Subject: [keycloak-dev] regarding expired sessions and token life-span In-Reply-To: References: Message-ID: TLDR; only offline tokens require database storage. We have regular tokens and offline tokens. We do not store regular tokens in memory or on disk. Instead, we have the concept of a login session (UserSessionModel) which hold metadata about the login. These sessions are stored in memory and within a distributed cache if in a cluster. Access and Refresh tokens are minted, digitally signed and validated and created against metadata within the login session. Offline tokens are very long lived and thus require their login session being persisted in a database. On Thu, Sep 28, 2017 at 9:05 AM, Kishan Sagathiya wrote: > Hi, > I am trying to figure out how Keycloak deals with expired sessions and how > token lifespan affects Keycloak database size and performance. > But I dont understand the directory structure and where to find the > relevant code. > If someone could give some pointers regarding this that would be great > Thanks :) > > -Kishan Sagathiya > _______________________________________________ > 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 Fri Sep 29 09:50:43 2017 From: bburke at redhat.com (Bill Burke) Date: Fri, 29 Sep 2017 09:50:43 -0400 Subject: [keycloak-dev] KEYCLOAK-5032 - Implementation question In-Reply-To: <890BFF49-124B-4099-8D3F-4430EAAA6ABF@Telia.no> References: <890BFF49-124B-4099-8D3F-4430EAAA6ABF@Telia.no> Message-ID: Do you want to continue talking on the PR or here? I had some concerns with your PR. On Wed, Sep 27, 2017 at 5:45 AM, wrote: > https://issues.jboss.org/browse/KEYCLOAK-5032 describes two requested query parameters: acr_values and nonce > > Our requirements are for acr_values and prompt, and I?m working on a pull request for these two. > > How many pull requests do you want? > Should I make sure that (each)PR includes support for one, two or three query parameters > > Can the ?prompt? parameter be added to KEYCLOAK-5032, or do I need another Jira task for the ?prompt? parameter? > > Br / mvh > Carl Kristian Eriksen > t: +47 95147848 > VEGA / GDPR / Access Management Infrastructure > Telia Norge AS > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev -- Bill Burke Red Hat From carl-kristian.eriksen at telia.no Fri Sep 29 10:41:30 2017 From: carl-kristian.eriksen at telia.no (carl-kristian.eriksen at telia.no) Date: Fri, 29 Sep 2017 14:41:30 +0000 Subject: [keycloak-dev] KEYCLOAK-5032 - Implementation question In-Reply-To: References: <890BFF49-124B-4099-8D3F-4430EAAA6ABF@Telia.no> Message-ID: Hi. I?ll follow up on the PR. Br / mvh Carl Kristian Eriksen On 29/09/17 15:50, "Bill Burke" wrote: Do you want to continue talking on the PR or here? I had some concerns with your PR. On Wed, Sep 27, 2017 at 5:45 AM, wrote: > https://issues.jboss.org/browse/KEYCLOAK-5032 describes two requested query parameters: acr_values and nonce > > Our requirements are for acr_values and prompt, and I?m working on a pull request for these two. > > How many pull requests do you want? > Should I make sure that (each)PR includes support for one, two or three query parameters > > Can the ?prompt? parameter be added to KEYCLOAK-5032, or do I need another Jira task for the ?prompt? parameter? > > Br / mvh > Carl Kristian Eriksen > _______________________________________________ > 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 Fri Sep 29 10:54:30 2017 From: mposolda at redhat.com (Marek Posolda) Date: Fri, 29 Sep 2017 16:54:30 +0200 Subject: [keycloak-dev] Single-use cache for OAuth code, Code changed to be JWE In-Reply-To: References: Message-ID: <171a2041-0fb9-8496-5999-dc240f619082@redhat.com> I see. The current size of the code parameter is 351 characters. The size of the JSON payload itself is 178 characters. The size of the code is like: S + E where S is 95 (size of the header, AES initialization vector and MAC) E is size of the encrypted text (approximately payload_size * 1.5) Fortunately we already have limit for custom notes to be 1000 chars at max - https://github.com/keycloak/keycloak/blob/master/services/src/main/java/org/keycloak/protocol/oidc/endpoints/request/AuthzEndpointRequestParser.java#L35-L45 . So I think we should be fine for URL limit of 2000 characters. Still we can improve by: - Use deflate compression - It's supported by JWE specs - Fallback to have notes in clientSession in case of big code param. Then clientSession will be still required in code-to-token endpoint Marek On 29/09/17 15:32, Bill Burke wrote: > Looks good. Just worry about the size of the code JWT. > > On Fri, Sep 29, 2017 at 7:59 AM, Marek Posolda wrote: >> I've sent PR https://github.com/keycloak/keycloak/pull/4512, which >> implements first part of >> https://docs.google.com/document/d/1C1vFhyGPBOnN3pprw6XPZnK08azyTm-HVIqO9dY3aTY/edit >> >> Some details: >> - Partially implemented support for JWE, so we can use encrypted JWT. >> >> - OAuth code is changed to be JWT. It's encrypted and >> integrity-protected with AES128-CBC-HMAC-SHA256 algorithm. Code is >> encrypted with realm AES key (new symmetric key generated by default for >> every realm similar to HMAC key) and signed with HMAC key. >> >> - I've added support for AES keys, so we now have RSA, HMAC and AES keys. >> >> - Code JWT doesn't yet contain much at this moment. There is just unique >> ID, userSession ID, client UUID and expiration (60 seconds). Next step >> is to add more into it, especially notes as mentioned in the docs. >> >> - Single-use cache is used to track which codes were already used. For >> now, it's reusing existing "actionTokens" infinispan cache. It's using >> "putIfAbsent" to add codes into the cache, hence now we are sure that >> the particular code is really used just once. The previous approach with >> the note on userSession didn't allow this. I've added new testcase to >> ConcurrentLoginTest for check that code is used just once. It's passing >> for cross-dc as well, however we may allow people to save some >> performance with the small possibility that same code will pass on both >> datacenters. >> >> - Now we also pass the scenario when SSO login with same client is >> opened on 2 browser tabs concurrently. Also added test to >> ConcurrentLoginTest and it's passing for cross-dc too. Previously this >> scenario may not work correctly as the "code" in the clientSession note >> may be generated concurrently by both requests and one of them will then >> fail to verify. >> >> >> Next steps: >> - Continue with the stuff described in the docs >> https://docs.google.com/document/d/1C1vFhyGPBOnN3pprw6XPZnK08azyTm-HVIqO9dY3aTY/edit >> (Remove protocolMappers and roles from clientSession etc). >> >> - It should be easy to use same stuff for refreshTokens . From what I >> see, the performance of AES128-CBC-HMAC-SHA256 is much better than RSA >> and provides the encryption too. >> >> Any comments? >> >> Marek >> >> _______________________________________________ >> 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 Sat Sep 30 16:32:34 2017 From: aron.bustya.js at gmail.com (Aron Bustya) Date: Sat, 30 Sep 2017 22:32:34 +0200 Subject: [keycloak-dev] Claims parameter support In-Reply-To: <9432de62-9275-14c5-8b8e-6211e151d6c5@redhat.com> References: <9432de62-9275-14c5-8b8e-6211e151d6c5@redhat.com> Message-ID: Hi, Sorry for the long silence. >Maybe one small change, if you can add the "claims" to the AuthzEndpointRequestParser.KNOWN_PARAMS and have separate client note for it as other known OIDC params? This would be good, because the "additional" parameters have a maximum length of 200 characters to be processed. On 20 September 2017 at 09:55, Marek Posolda wrote: > Great work! > > If I see it correctly, there are 2 parts: > > 1) improvements in request object parsing - I am all for include your > improvements. If you can create separate JIRA for current request object > limitation, add the test (there are existing tests for request object in > OIDCAdvancedRequestParamsTest. Feel free to add new test or change one of > existing tests) and create separate PR, it will be nice and will be merged. > If I understand correctly, this is the only part, which really blocks you > right? (As additional protocolMapper can be deployed to the existing > Keycloak instance as separate JAR and doesn't require changes in core > keycloak code?) > > 2) ProtocolMapper for claims - as you pointed, you don't have full support > for 'claims' parameter. Still it's better then nothing, so my vote is to > include your changes. I am not 100% convinced, maybe someone has different > opinion on it (new protocolMapper always adds a bit of additional > complexity. However I think it's ok as it's OIDC standard). Maybe one small > change, if you can add the "claims" to the AuthzEndpointRequestParser.KNOWN_PARAMS > and have separate client note for it as other known OIDC params? > > Thanks! > Marek > > > > On 19/09/17 22:49, Aron Bustya wrote: > > Hello! > > I need the 'claims parameter' support in keycloak that has been thought > about in this jira ticket and postponed/rejected:https://issues.jboss.org/browse/KEYCLOAK-3226 > The proposed alternatives don't work for me, because I am implementing a > specification that explicitly requests data to be passed this way. > In addition to the JIRA above we also need to support passing the claims > parameter in the signed request object - not just as a separate query param. > > I've solved the problem for our own use case by writing a ProtocolMapper > but some changes were also needed in the keycloak request parser (to > support the parsing of json objects from the request object - not just > strings). > > The ProtocolMapper I've written doesn't support the whole claims parameter > feature though - it can only add the default value of the claim to the the > tokens. > > I'm now trying to figure out how much of this code could be put back into > keycloak, and what needs to be changed to do so. > My goal would be to use an 'official' keycloak with cutomization only in > Service Providers and configuration. > > Current code commit is here:https://github.com/abustya/keycloak/commit/41fecf57a982ffdb9 > > 6e210d8bd302d23fa7884da > > What do you think about the direction of the development, does it make any > sense to put some of it back into keycloak? > > Regards, > ?ron Bustya > _______________________________________________ > keycloak-dev mailing listkeycloak-dev at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-dev > > > From sblanc at redhat.com Sat Sep 30 21:39:32 2017 From: sblanc at redhat.com (Sebastien Blanc) Date: Sun, 1 Oct 2017 03:39:32 +0200 Subject: [keycloak-dev] Javascript client mobile review In-Reply-To: References: Message-ID: Hi Wojciech ! Thanks for the PR ! But as you said could you please create a ticket and link the PR to it ? Sebi On Fri, Sep 29, 2017 at 2:20 PM, Wojciech Trocki wrote: > Hi > > I recently made couple integrations with Keycloak on Android and IOS. > During testing some problems were found around cordova adapter. > > Created minor fix to resolve IOS issue I have found: > https://github.com/keycloak/keycloak/pull/4514 > > After reviewing source code I think that it will be good to allow > developers to provide their own adapters. This way we will be able to made > some tweaks for platforms like nativescript or react native. If you think > that's good idea? > > I can create ticket and contribute to provide this mechanisms. > > Regards > > -- > > WOJCIECH TROCKI > > Red Hat Mobile > > IM: wtrocki > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev >