From bburke at redhat.com Mon Aug 1 13:03:05 2016 From: bburke at redhat.com (Bill Burke) Date: Mon, 1 Aug 2016 13:03:05 -0400 Subject: [keycloak-dev] travis maven and quiet mode -q Message-ID: <306e2447-002a-1cde-21e5-9fc21c17fa41@redhat.com> Why are we running in quiet mode? Does the log end up too long and the build fails? From psilva at redhat.com Mon Aug 1 13:12:32 2016 From: psilva at redhat.com (Pedro Igor Silva) Date: Mon, 1 Aug 2016 13:12:32 -0400 (EDT) Subject: [keycloak-dev] travis maven and quiet mode -q In-Reply-To: <306e2447-002a-1cde-21e5-9fc21c17fa41@redhat.com> References: <306e2447-002a-1cde-21e5-9fc21c17fa41@redhat.com> Message-ID: <981975491.22236730.1470071552188.JavaMail.zimbra@redhat.com> I think so. That is what we have discussed on another thread. We could remove quiet mode and see if builds get more stable. Which I think will do ... ----- Original Message ----- From: "Bill Burke" To: "keycloak-dev" Sent: Monday, August 1, 2016 2:03:05 PM Subject: [keycloak-dev] travis maven and quiet mode -q Why are we running in quiet mode? Does the log end up too long and the build fails? _______________________________________________ keycloak-dev mailing list keycloak-dev at lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-dev From psilva at redhat.com Mon Aug 1 15:38:07 2016 From: psilva at redhat.com (Pedro Igor Silva) Date: Mon, 1 Aug 2016 15:38:07 -0400 (EDT) Subject: [keycloak-dev] travis maven and quiet mode -q In-Reply-To: <981975491.22236730.1470071552188.JavaMail.zimbra@redhat.com> References: <306e2447-002a-1cde-21e5-9fc21c17fa41@redhat.com> <981975491.22236730.1470071552188.JavaMail.zimbra@redhat.com> Message-ID: <1195597536.22328581.1470080287173.JavaMail.zimbra@redhat.com> Now Travis is complaining about the log size .... That is probably the reason why quite mode was set. I think we should revert -q. At least we can restart the build and get it working. I can try to look at that later this week and try to find a balance between these two issues (no log and too much log). Wdyt ? ----- Original Message ----- From: "Pedro Igor Silva" To: "Bill Burke" Cc: "keycloak-dev" Sent: Monday, August 1, 2016 2:12:32 PM Subject: Re: [keycloak-dev] travis maven and quiet mode -q I think so. That is what we have discussed on another thread. We could remove quiet mode and see if builds get more stable. Which I think will do ... ----- Original Message ----- From: "Bill Burke" To: "keycloak-dev" Sent: Monday, August 1, 2016 2:03:05 PM Subject: [keycloak-dev] travis maven and quiet mode -q Why are we running in quiet mode? Does the log end up too long and the build fails? _______________________________________________ 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 Mon Aug 1 16:40:10 2016 From: bburke at redhat.com (Bill Burke) Date: Mon, 1 Aug 2016 16:40:10 -0400 Subject: [keycloak-dev] travis maven and quiet mode -q In-Reply-To: <1195597536.22328581.1470080287173.JavaMail.zimbra@redhat.com> References: <306e2447-002a-1cde-21e5-9fc21c17fa41@redhat.com> <981975491.22236730.1470071552188.JavaMail.zimbra@redhat.com> <1195597536.22328581.1470080287173.JavaMail.zimbra@redhat.com> Message-ID: <1a65024b-f02f-9b40-a9c5-659ec3b8ce34@redhat.com> i set it back On 8/1/16 3:38 PM, Pedro Igor Silva wrote: > Now Travis is complaining about the log size .... That is probably the reason why quite mode was set. > > I think we should revert -q. At least we can restart the build and get it working. > > I can try to look at that later this week and try to find a balance between these two issues (no log and too much log). > > Wdyt ? > > > ----- Original Message ----- > From: "Pedro Igor Silva" > To: "Bill Burke" > Cc: "keycloak-dev" > Sent: Monday, August 1, 2016 2:12:32 PM > Subject: Re: [keycloak-dev] travis maven and quiet mode -q > > I think so. That is what we have discussed on another thread. We could remove quiet mode and see if builds get more stable. Which I think will do ... > > ----- Original Message ----- > From: "Bill Burke" > To: "keycloak-dev" > Sent: Monday, August 1, 2016 2:03:05 PM > Subject: [keycloak-dev] travis maven and quiet mode -q > > Why are we running in quiet mode? Does the log end up too long and the > build fails? > > _______________________________________________ > 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 Aug 1 23:58:51 2016 From: mposolda at redhat.com (Marek Posolda) Date: Tue, 2 Aug 2016 05:58:51 +0200 Subject: [keycloak-dev] travis maven and quiet mode -q In-Reply-To: <1a65024b-f02f-9b40-a9c5-659ec3b8ce34@redhat.com> References: <306e2447-002a-1cde-21e5-9fc21c17fa41@redhat.com> <981975491.22236730.1470071552188.JavaMail.zimbra@redhat.com> <1195597536.22328581.1470080287173.JavaMail.zimbra@redhat.com> <1a65024b-f02f-9b40-a9c5-659ec3b8ce34@redhat.com> Message-ID: <57A01A7B.80602@redhat.com> I've tried to find some "balance" between no log and too much log. I've ended with removed quiet mode, but some output filtering with "grep" to avoid very big log file. The command is like this: mvn install -Pdistribution -DskipTests=true -B -V | grep -e "Maven" -e "Java" -e "Building Keycloak" I've pushed this change. Looks like dirty workaround, but seems to work for now :/ It seems the proper solution will be to fix maven to avoid downloading stuff every build. Marek On 01/08/16 22:40, Bill Burke wrote: > i set it back > > > On 8/1/16 3:38 PM, Pedro Igor Silva wrote: >> Now Travis is complaining about the log size .... That is probably the reason why quite mode was set. >> >> I think we should revert -q. At least we can restart the build and get it working. >> >> I can try to look at that later this week and try to find a balance between these two issues (no log and too much log). >> >> Wdyt ? >> >> >> ----- Original Message ----- >> From: "Pedro Igor Silva" >> To: "Bill Burke" >> Cc: "keycloak-dev" >> Sent: Monday, August 1, 2016 2:12:32 PM >> Subject: Re: [keycloak-dev] travis maven and quiet mode -q >> >> I think so. That is what we have discussed on another thread. We could remove quiet mode and see if builds get more stable. Which I think will do ... >> >> ----- Original Message ----- >> From: "Bill Burke" >> To: "keycloak-dev" >> Sent: Monday, August 1, 2016 2:03:05 PM >> Subject: [keycloak-dev] travis maven and quiet mode -q >> >> Why are we running in quiet mode? Does the log end up too long and the >> build fails? >> >> _______________________________________________ >> 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 thomas.darimont at googlemail.com Tue Aug 2 03:53:48 2016 From: thomas.darimont at googlemail.com (Thomas Darimont) Date: Tue, 2 Aug 2016 09:53:48 +0200 Subject: [keycloak-dev] travis maven and quiet mode -q In-Reply-To: <57A01A7B.80602@redhat.com> References: <306e2447-002a-1cde-21e5-9fc21c17fa41@redhat.com> <981975491.22236730.1470071552188.JavaMail.zimbra@redhat.com> <1195597536.22328581.1470080287173.JavaMail.zimbra@redhat.com> <1a65024b-f02f-9b40-a9c5-659ec3b8ce34@redhat.com> <57A01A7B.80602@redhat.com> Message-ID: Hello, FYI - in the Spring Data Builds we configured caching of maven resources in travis to avoid downloading all dependencies everytime https://github.com/spring-projects/spring-data-jpa/blob/master/.travis.yml#L28 So try adding this to .travis.yml cache: directories: - $HOME/.m2 Cheers, Thomas 2016-08-02 5:58 GMT+02:00 Marek Posolda : > I've tried to find some "balance" between no log and too much log. I've > ended with removed quiet mode, but some output filtering with "grep" to > avoid very big log file. The command is like this: > > mvn install -Pdistribution -DskipTests=true -B -V | grep -e "Maven" -e > "Java" -e "Building Keycloak" > > I've pushed this change. Looks like dirty workaround, but seems to work > for now :/ It seems the proper solution will be to fix maven to avoid > downloading stuff every build. > > Marek > > > On 01/08/16 22:40, Bill Burke wrote: > > i set it back > > > > > > On 8/1/16 3:38 PM, Pedro Igor Silva wrote: > >> Now Travis is complaining about the log size .... That is probably the > reason why quite mode was set. > >> > >> I think we should revert -q. At least we can restart the build and get > it working. > >> > >> I can try to look at that later this week and try to find a balance > between these two issues (no log and too much log). > >> > >> Wdyt ? > >> > >> > >> ----- Original Message ----- > >> From: "Pedro Igor Silva" > >> To: "Bill Burke" > >> Cc: "keycloak-dev" > >> Sent: Monday, August 1, 2016 2:12:32 PM > >> Subject: Re: [keycloak-dev] travis maven and quiet mode -q > >> > >> I think so. That is what we have discussed on another thread. We could > remove quiet mode and see if builds get more stable. Which I think will do > ... > >> > >> ----- Original Message ----- > >> From: "Bill Burke" > >> To: "keycloak-dev" > >> Sent: Monday, August 1, 2016 2:03:05 PM > >> Subject: [keycloak-dev] travis maven and quiet mode -q > >> > >> Why are we running in quiet mode? Does the log end up too long and the > >> build fails? > >> > >> _______________________________________________ > >> 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 > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160802/3495209c/attachment-0001.html From mposolda at redhat.com Tue Aug 2 05:02:19 2016 From: mposolda at redhat.com (Marek Posolda) Date: Tue, 2 Aug 2016 11:02:19 +0200 Subject: [keycloak-dev] travis maven and quiet mode -q In-Reply-To: References: <306e2447-002a-1cde-21e5-9fc21c17fa41@redhat.com> <981975491.22236730.1470071552188.JavaMail.zimbra@redhat.com> <1195597536.22328581.1470080287173.JavaMail.zimbra@redhat.com> <1a65024b-f02f-9b40-a9c5-659ec3b8ce34@redhat.com> <57A01A7B.80602@redhat.com> Message-ID: <57A0619B.6090708@redhat.com> +1 from me to use this. Marek On 02/08/16 09:53, Thomas Darimont wrote: > Hello, > > FYI - in the Spring Data Builds we configured caching of maven > resources in travis to avoid downloading all dependencies everytime > https://github.com/spring-projects/spring-data-jpa/blob/master/.travis.yml#L28 > > So try adding this to .travis.yml > > cache: > directories: > - $HOME/.m2 > > Cheers, > Thomas > > 2016-08-02 5:58 GMT+02:00 Marek Posolda >: > > I've tried to find some "balance" between no log and too much log. > I've > ended with removed quiet mode, but some output filtering with > "grep" to > avoid very big log file. The command is like this: > > mvn install -Pdistribution -DskipTests=true -B -V | grep -e "Maven" -e > "Java" -e "Building Keycloak" > > I've pushed this change. Looks like dirty workaround, but seems to > work > for now :/ It seems the proper solution will be to fix maven to avoid > downloading stuff every build. > > Marek > > > On 01/08/16 22:40, Bill Burke wrote: > > i set it back > > > > > > On 8/1/16 3:38 PM, Pedro Igor Silva wrote: > >> Now Travis is complaining about the log size .... That is > probably the reason why quite mode was set. > >> > >> I think we should revert -q. At least we can restart the build > and get it working. > >> > >> I can try to look at that later this week and try to find a > balance between these two issues (no log and too much log). > >> > >> Wdyt ? > >> > >> > >> ----- Original Message ----- > >> From: "Pedro Igor Silva" > > >> To: "Bill Burke" > > >> Cc: "keycloak-dev" > > >> Sent: Monday, August 1, 2016 2:12:32 PM > >> Subject: Re: [keycloak-dev] travis maven and quiet mode -q > >> > >> I think so. That is what we have discussed on another thread. > We could remove quiet mode and see if builds get more stable. > Which I think will do ... > >> > >> ----- Original Message ----- > >> From: "Bill Burke" > > >> To: "keycloak-dev" > > >> Sent: Monday, August 1, 2016 2:03:05 PM > >> Subject: [keycloak-dev] travis maven and quiet mode -q > >> > >> Why are we running in quiet mode? Does the log end up too long > and the > >> build fails? > >> > >> _______________________________________________ > >> 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 > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160802/58387572/attachment.html From martin.hardselius at gmail.com Tue Aug 2 08:13:49 2016 From: martin.hardselius at gmail.com (Martin Hardselius) Date: Tue, 02 Aug 2016 12:13:49 +0000 Subject: [keycloak-dev] Pairwise Subject Identifier Message-ID: Me and my team are working towards getting Keycloak, customized for our needs, into production but we've identified the need for Pairwise Subject Identifiers as we don't want to expose internal user ids. Right now, the only subject_types_supported seems to be "public". Are there any near-future plans to include "pairwise"? Can we pitch in with a PR to make this happen as soon as possible? Links to relevant sections in the spec: http://openid.net/specs/openid-connect-core-1_0.html#SubjectIDTypes http://openid.net/specs/openid-connect-core-1_0.html#PairwiseAlg -- Martin -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160802/56906404/attachment.html From bburke at redhat.com Tue Aug 2 14:47:59 2016 From: bburke at redhat.com (Bill Burke) Date: Tue, 2 Aug 2016 14:47:59 -0400 Subject: [keycloak-dev] How is providers/ directory configured? Message-ID: <1a858ab9-6d3c-9eb7-4402-bbe7ac16fa76@redhat.com> I've been unable to figure out how the providers/ directory is created, implemented, or configured. Hints? It also doesn't seem to deploy anything you have in the jar you add to providers/. I'm trying to deploy JPA with it and it doesn't automatically set up. Anybody know? Or did Stian implement this? Thanks, Bill From bburke at redhat.com Tue Aug 2 14:58:58 2016 From: bburke at redhat.com (Bill Burke) Date: Tue, 2 Aug 2016 14:58:58 -0400 Subject: [keycloak-dev] How is providers/ directory configured? In-Reply-To: <1a858ab9-6d3c-9eb7-4402-bbe7ac16fa76@redhat.com> References: <1a858ab9-6d3c-9eb7-4402-bbe7ac16fa76@redhat.com> Message-ID: Nevermind, figured it out... On 8/2/16 2:47 PM, Bill Burke wrote: > I've been unable to figure out how the providers/ directory is created, > implemented, or configured. Hints? It also doesn't seem to deploy > anything you have in the jar you add to providers/. I'm trying to > deploy JPA with it and it doesn't automatically set up. > > Anybody know? Or did Stian implement this? > > Thanks, > > Bill > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev From bburke at redhat.com Tue Aug 2 18:45:08 2016 From: bburke at redhat.com (Bill Burke) Date: Tue, 2 Aug 2016 18:45:08 -0400 Subject: [keycloak-dev] rehash password if different algorithm? Message-ID: Hey, Ran into something implementing a user federation example. My user federation example stores passwords in plain text. So, I wrote a plain text password hasher. The first time the password is validated, the hashing iterations don't match from the returned UserCredentialValueModel. The user fed provider always returns 0 because its plain text. The CredentialValidation class sees that the hash iterations dont' match with the default realm's hashing iterations, so the password is rehashed. Rehashed with the default realm algorithm. There is a bug here in that the algorithm is not set to the realm's hashing algorithm, so, once a user is validated once, they can never be validated again...at least in this scenario. The bigger question is, how do we handle this scenario where the User Federation Provider does not store passwords in the same format as the realm's password policy? The workaround is to ignore password updates when updateCredentialsDirectly is called. But this seems like a hack. A lot of documentation would need to be in place for this. Bill From wadahiro at gmail.com Tue Aug 2 23:19:00 2016 From: wadahiro at gmail.com (Hiroyuki Wada) Date: Wed, 3 Aug 2016 12:19:00 +0900 Subject: [keycloak-dev] Japanese Localization Message-ID: Hello all, I am translating all base theme messages to Japanaese language now. (I think I can do it by the end of the week.) I'd like to contribute the message resources, How do you think? If it's ok, I'll create a JIRA issue and create a pull request. Regards, -- Hiroyuki Wada wadahiro at gmail.com From thomas.darimont at googlemail.com Wed Aug 3 04:05:07 2016 From: thomas.darimont at googlemail.com (Thomas Darimont) Date: Wed, 3 Aug 2016 10:05:07 +0200 Subject: [keycloak-dev] Japanese Localization In-Reply-To: References: Message-ID: Hello Hiroyuki, I'd say just go ahead and feel free to create a JIRA issue - and reference the issue number in your commit like KEYCLOAK-XXX Add Japanese localization. Try to keep your changes in a single commit in your pull request, this makes it easier to apply (e.g. via cherry-pick) - I listed my workflow for reference below. Once you're done with your PR just add a link to it to the JIRA issue (in the JIRA issue, press "." then type "git" -> which brings you the to the "add git pull request" dialog. If you want an example for a JIRA issue here is a similar ticket for french translation: https://issues.jboss.org/browse/KEYCLOAK-1903 Cheers, Thomas My workflow: I tend to create a separate branch for every JIRA issue, so I do the following (from a checked out master branch) 0) git clone https://github.com/thomasdarimont/keycloak (origin is my keycloak fork) git remote add upstream https://github.com/keycloak/keycloak (upstream is original keycloak) 1) git checkout -b issue/KEYCLOAK-XXX-short-description (this will create and checkout the branch) 2) code... 3) git add . 4) git commit -m (or use a graphical git client like gitg on linux, or gitx on osx) 5) git push -u origin issue/KEYCLOAK-XXX-short-description 6) on your cloned github project you should now see a link for: create pull request for the newly pushed branch - click and the PR is there if I need to change stuff in the PR (before it is merged) I do the following 7) change... 8) git add . 9) git commit --amend (or use a graphical git client like gitg on linux, or gitx on osx) 10) git push -f origin issue/KEYCLOAK-XXX-short-description (this will update your PR as well, but github is smart enough to retain potentially PR comments if those places didn't change) 11) goto 7) if necessary Updating your keycloak fork from original keycloak upstream 1) git checkout master 2) git pull upstream master 3) git push origin master (to update the master branch in your fork if necessary) to update an issue branch to the latest master 1) git checkout issue/KEYCLOAK-XXX-short-description 2) git rebase master (your issue branch is now based on the latest changes from master) 3) git push -f origin issue/KEYCLOAK-XXX-short-description 2016-08-03 5:19 GMT+02:00 Hiroyuki Wada : > Hello all, > > I am translating all base theme messages to Japanaese language now. > (I think I can do it by the end of the week.) > > I'd like to contribute the message resources, How do you think? > If it's ok, I'll create a JIRA issue and create a pull request. > > Regards, > > -- > Hiroyuki Wada > wadahiro at gmail.com > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160803/b4ee7c40/attachment-0001.html From mposolda at redhat.com Wed Aug 3 15:11:39 2016 From: mposolda at redhat.com (Marek Posolda) Date: Wed, 3 Aug 2016 21:11:39 +0200 Subject: [keycloak-dev] rehash password if different algorithm? In-Reply-To: References: Message-ID: <57A241EB.2060206@redhat.com> On 03/08/16 00:45, Bill Burke wrote: > Hey, > > Ran into something implementing a user federation example. My user > federation example stores passwords in plain text. So, I wrote a plain > text password hasher. The first time the password is validated, the > hashing iterations don't match from the returned > UserCredentialValueModel. The user fed provider always returns 0 > because its plain text. The CredentialValidation class sees that the > hash iterations dont' match with the default realm's hashing iterations, > so the password is rehashed. Rehashed with the default realm > algorithm. There is a bug here in that the algorithm is not set to the > realm's hashing algorithm, so, once a user is validated once, they can > never be validated again...at least in this scenario. I assume it works this way, for case that the old passwords are imported from some legacy storage into Keycloak DB. Those passwords might be hashed with some weak algorithm or they might be just in plain-text. So after successful validation of plain-text password is the stored plain-text password dropped and new password credential is created and saved again into Keycloak DB with the official realm algorithm (pbkdf2 + 20000 iterations). > > The bigger question is, how do we handle this scenario where the User > Federation Provider does not store passwords in the same format as the > realm's password policy? The workaround is to ignore password updates > when updateCredentialsDirectly is called. But this seems like a hack. > A lot of documentation would need to be in place for this. I think that some 3rd party federation SPI are able to store the password credential with all the info, but some others are limited. For example if you want to update password to LDAP , you need to send it in plain-text. Not send hash + salt + requested hash algorithm. Same if you want to validate password against LDAP, you need to use plain-text. In other words, credential storage SPI must be able to use UserCredentialModel instead of UserCredentialValueModel. Not sure if credential SPI storage should support both possibilities? Either possibility to store plain-text password or full UserCredentialValueModel or both? And have some switch what exactly it supports? Previously the UserFederationProvider.validCredentials was supposed to always receive password in plain-text. The stuff like CredentialValidation.validPassword was supposed to be invoked just for validating against our JPA or Mongo, but not against 3rd party UserFederationProviders. Marek > > Bill > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160803/a30c1f1c/attachment.html From mposolda at redhat.com Wed Aug 3 16:16:50 2016 From: mposolda at redhat.com (Marek Posolda) Date: Wed, 3 Aug 2016 22:16:50 +0200 Subject: [keycloak-dev] Keycloak 2.1.0.CR1 released Message-ID: <57A25132.9030007@redhat.com> Keycloak 2.1.0.CR1 has just been released. The final release will follow next week if no major issues are reported. Few highlights of this release: * *Password Policy SPI* - Now it's possible to plug your own implementation of password policy. This is useful if available builtin policies are not sufficient for you. * *Jetty 9.3 adapter* - Allow you to secure your applications deployed on Jetty 9.3 server. * *Authorization fixes & improvements* - There are lots of fixes and improvements in authorization services, which were recently added in 2.0 release. It really worth to check this out and eventually provide us some feedback. * *Better OpenID Connect interoperability* - There are lots of minor fixes related to OpenID Connect support. For the full list of issues resolved check out JIRA and to download the release go to the Keycloak homepage . -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160803/0f87be18/attachment.html From bburke at redhat.com Wed Aug 3 19:48:51 2016 From: bburke at redhat.com (Bill Burke) Date: Wed, 3 Aug 2016 19:48:51 -0400 Subject: [keycloak-dev] creating JPA user storage provider difficult Message-ID: I wrote an JPA example for the new User Storage Provider SPI [1]. It was very difficult to figure out how to wire in JPA. I'm going to take a guess that very very few users have actually tried to implement a JPA-based User Federation Provider. They would have run into a ton of hurdles. * Putting just a jar within the "providers/" directory is unusable. JPA classes and other dependencies will not be visible. * So, you have to craft a *CORRECT* module.xml file and know exactly which dependencies to bring in. [2] * javax.persistence.Persistence.createEntityManagerFactory() did not work, so I had to call Hibernate APIs directly. Not only that, but non-simple Hibernate APIs. [3] * When configuring JPA I also had to know what classloader to use so that persistence.xml was visible. * Had to use JpaKeycloakTransaction to enlist EntityManager with keycloak transactions. This means using EJBs is out of the question. This is unacceptable. Keycloak is supposed to be simple and this is extremely difficult. When Keycloak was an exploded WAR you could use every Java EE component type as you could just plop your extensions within META-INF/lib. Classloading was simple as it was all the same classloader. Going forward we need to write an actual deployer for Keycloak extensions that allow you to define Keycloak providers within EE jars, ears, etc. Writing an extension to Keycloak should be as easy as writing a Java EE application. Extension developers should be able to leverage the entire JBoss/Wildfly platform. Minimally, we also need to begin and commit/rollback a UserTransaction within a Keycloak request flow so that transaction EE and Spring component layers can function. Finally, we should just remove the "providers/" directory as I don't think it is very usable for actual extension writing. What I didn't try was adding all jars needed (Hibernate etc.) within the providers directory. Would that have worked? [1] https://github.com/patriot1burke/keycloak/tree/master/examples/providers/user-storage-jpa [2] https://github.com/patriot1burke/keycloak/blob/master/examples/providers/user-storage-jpa/module.xml [3] https://github.com/patriot1burke/keycloak/blob/master/examples/providers/user-storage-jpa/src/main/java/org/keycloak/examples/storage/user/ExampleUserStorageProviderFactory.java#L74 From wadahiro at gmail.com Wed Aug 3 21:46:59 2016 From: wadahiro at gmail.com (Hiroyuki Wada) Date: Thu, 04 Aug 2016 01:46:59 +0000 Subject: [keycloak-dev] Japanese Localization In-Reply-To: References: Message-ID: Thanks. I created a JIRA issue. https://issues.jboss.org/browse/KEYCLOAK-3397 I'll send a pull request later! 2016?8?3?(?) 17:05 Thomas Darimont : > Hello Hiroyuki, > > I'd say just go ahead and feel free to create a JIRA issue - and reference > the issue number in your commit like > KEYCLOAK-XXX Add Japanese localization. > > Try to keep your changes in a single commit in your pull request, this > makes it easier to apply (e.g. via cherry-pick) - I listed my workflow for > reference below. > Once you're done with your PR just add a link to it to the JIRA issue (in > the JIRA issue, press "." then type "git" -> which brings you the to the > "add git pull request" dialog. > > If you want an example for a JIRA issue here is a similar ticket for > french translation: > https://issues.jboss.org/browse/KEYCLOAK-1903 > > Cheers, > Thomas > > My workflow: > I tend to create a separate branch for every JIRA issue, so I do the > following (from a checked out master branch) > 0) git clone https://github.com/thomasdarimont/keycloak > (origin is my keycloak fork) > git remote add upstream https://github.com/keycloak/keycloak > (upstream is original keycloak) > 1) git checkout -b issue/KEYCLOAK-XXX-short-description > (this will create and checkout the branch) > 2) code... > 3) git add . > 4) git commit -m (or use a graphical git client like gitg on linux, or > gitx on osx) > 5) git push -u origin issue/KEYCLOAK-XXX-short-description > 6) on your cloned github project you should now see a link for: create > pull request for the newly pushed branch - click and the PR is there > if I need to change stuff in the PR (before it is merged) I do the > following > 7) change... > 8) git add . > 9) git commit --amend (or use a graphical git client like gitg on linux, > or gitx on osx) > 10) git push -f origin issue/KEYCLOAK-XXX-short-description > (this will update your PR as well, but github is smart enough to retain > potentially PR comments if those places didn't change) > 11) goto 7) if necessary > > Updating your keycloak fork from original keycloak upstream > 1) git checkout master > 2) git pull upstream master > 3) git push origin master > (to update the master branch in your fork if necessary) > > to update an issue branch to the latest master > 1) git checkout issue/KEYCLOAK-XXX-short-description > 2) git rebase master > (your issue branch is now based on the latest changes from master) > 3) git push -f origin issue/KEYCLOAK-XXX-short-description > > 2016-08-03 5:19 GMT+02:00 Hiroyuki Wada : > >> Hello all, >> >> I am translating all base theme messages to Japanaese language now. >> (I think I can do it by the end of the week.) >> >> I'd like to contribute the message resources, How do you think? >> If it's ok, I'll create a JIRA issue and create a pull request. >> >> Regards, >> >> -- >> Hiroyuki Wada >> wadahiro at gmail.com >> > _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160804/13c5de00/attachment.html From mposolda at redhat.com Thu Aug 4 04:00:39 2016 From: mposolda at redhat.com (Marek Posolda) Date: Thu, 4 Aug 2016 10:00:39 +0200 Subject: [keycloak-dev] creating JPA user storage provider difficult In-Reply-To: References: Message-ID: <57A2F627.1030406@redhat.com> On 04/08/16 01:48, Bill Burke wrote: > I wrote an JPA example for the new User Storage Provider SPI [1]. It > was very difficult to figure out how to wire in JPA. I'm going to take > a guess that very very few users have actually tried to implement a > JPA-based User Federation Provider. They would have run into a ton of > hurdles. > > * Putting just a jar within the "providers/" directory is unusable. JPA > classes and other dependencies will not be visible. > > * So, you have to craft a *CORRECT* module.xml file and know exactly > which dependencies to bring in. [2] > > * javax.persistence.Persistence.createEntityManagerFactory() did not > work, so I had to call Hibernate APIs directly. Not only that, but > non-simple Hibernate APIs. [3] > > * When configuring JPA I also had to know what classloader to use so > that persistence.xml was visible. In some recent release, we added JpaEntityProvider SPI. This allows to register your own JPA entities with Keycloak own EntityManager . So in your provider, you don't need to care about the complex stuff like proprietary Hibernate API, classloader or transaction enlisting. We have a docs [1] and example for that [2] [1] https://keycloak.gitbooks.io/server-developer-guide/content/v/2.1/topics/extensions.html [2] https://github.com/patriot1burke/keycloak/tree/master/examples/providers/domain-extension That's much easier, isn't it? Just not sure if it helps with EJB... > > * Had to use JpaKeycloakTransaction to enlist EntityManager with > keycloak transactions. This means using EJBs is out of the question. > > This is unacceptable. Keycloak is supposed to be simple and this is > extremely difficult. When Keycloak was an exploded WAR you could use > every Java EE component type as you could just plop your extensions > within META-INF/lib. Classloading was simple as it was all the same > classloader. > > Going forward we need to write an actual deployer for Keycloak > extensions that allow you to define Keycloak providers within EE jars, > ears, etc. Writing an extension to Keycloak should be as easy as > writing a Java EE application. Extension developers should be able to > leverage the entire JBoss/Wildfly platform. Minimally, we also need to > begin and commit/rollback a UserTransaction within a Keycloak request > flow so that transaction EE and Spring component layers can function. +1 for deployer. Maybe we can try to prototype an example, which uses stuff like EJB and then see what exactly we need to add? For UserTransaction, we can maybe have the KeycloakTransaction implementation, which will delegate to UserTransaction? Then people can optionally enlist it in their provider if they need it : session.getTransactionManager().enlistAfterCompletion(new UserTransactionWrapper()); Then Keycloak will automatically take care of commit/rollback this transaction at end of request. > > Finally, we should just remove the "providers/" directory as I don't > think it is very usable for actual extension writing. What I didn't try > was adding all jars needed (Hibernate etc.) within the providers > directory. Would that have worked? AFAIK yes, it should work if you copy all 3rd party dependencies to "providers" directory. It seems that "providers" directory is useful just for some very easy stuff without much dependencies. Otherwise JBoss modules are a way to go. And if we later have some deployer, we won't need "providers" dir anymore? So +1 for remove. Marek > > > [1] > https://github.com/patriot1burke/keycloak/tree/master/examples/providers/user-storage-jpa > > [2] > https://github.com/patriot1burke/keycloak/blob/master/examples/providers/user-storage-jpa/module.xml > > [3] > https://github.com/patriot1burke/keycloak/blob/master/examples/providers/user-storage-jpa/src/main/java/org/keycloak/examples/storage/user/ExampleUserStorageProviderFactory.java#L74 > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160804/a6fd5fba/attachment-0001.html From mposolda at redhat.com Thu Aug 4 04:02:19 2016 From: mposolda at redhat.com (Marek Posolda) Date: Thu, 4 Aug 2016 10:02:19 +0200 Subject: [keycloak-dev] Japanese Localization In-Reply-To: References: Message-ID: <57A2F68B.6010401@redhat.com> Just a note that we can accept localization PR if you also take care of maintain your locale in future releases. Thanks, Marek On 04/08/16 03:46, Hiroyuki Wada wrote: > Thanks. I created a JIRA issue. > https://issues.jboss.org/browse/KEYCLOAK-3397 > > I'll send a pull request later! > > > 2016?8?3?(?) 17:05 Thomas Darimont >: > > Hello Hiroyuki, > > I'd say just go ahead and feel free to create a JIRA issue - and > reference the issue number in your commit like > KEYCLOAK-XXX Add Japanese localization. > > Try to keep your changes in a single commit in your pull request, > this makes it easier to apply (e.g. via cherry-pick) - I listed my > workflow for reference below. > Once you're done with your PR just add a link to it to the JIRA > issue (in the JIRA issue, press "." then type "git" -> which > brings you the to the "add git pull request" dialog. > > If you want an example for a JIRA issue here is a similar ticket > for french translation: > https://issues.jboss.org/browse/KEYCLOAK-1903 > > Cheers, > Thomas > > My workflow: > I tend to create a separate branch for every JIRA issue, so I do > the following (from a checked out master branch) > 0) git clone https://github.com/thomasdarimont/keycloak > (origin is my keycloak fork) > git remote add upstream https://github.com/keycloak/keycloak > (upstream is original keycloak) > 1) git checkout -b issue/KEYCLOAK-XXX-short-description > (this will create and checkout the branch) > 2) code... > 3) git add . > 4) git commit -m (or use a graphical git client like gitg on > linux, or gitx on osx) > 5) git push -u origin issue/KEYCLOAK-XXX-short-description > 6) on your cloned github project you should now see a link for: > create pull request for the newly pushed branch - click and the PR > is there > if I need to change stuff in the PR (before it is merged) I do the > following > 7) change... > 8) git add . > 9) git commit --amend (or use a graphical git client like gitg on > linux, or gitx on osx) > 10) git push -f origin issue/KEYCLOAK-XXX-short-description > (this will update your PR as well, but github is smart enough to > retain potentially PR comments if those places didn't change) > 11) goto 7) if necessary > > Updating your keycloak fork from original keycloak upstream > 1) git checkout master > 2) git pull upstream master > 3) git push origin master > (to update the master branch in your fork if necessary) > > to update an issue branch to the latest master > 1) git checkout issue/KEYCLOAK-XXX-short-description > 2) git rebase master > (your issue branch is now based on the latest changes from master) > 3) git push -f origin issue/KEYCLOAK-XXX-short-description > > 2016-08-03 5:19 GMT+02:00 Hiroyuki Wada >: > > Hello all, > > I am translating all base theme messages to Japanaese language > now. > (I think I can do it by the end of the week.) > > I'd like to contribute the message resources, How do you think? > If it's ok, I'll create a JIRA issue and create a pull request. > > Regards, > > -- > Hiroyuki Wada > wadahiro at gmail.com > > _______________________________________________ > 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160804/bac81f52/attachment.html From bburke at redhat.com Thu Aug 4 09:10:24 2016 From: bburke at redhat.com (Bill Burke) Date: Thu, 4 Aug 2016 09:10:24 -0400 Subject: [keycloak-dev] creating JPA user storage provider difficult In-Reply-To: <57A2F627.1030406@redhat.com> References: <57A2F627.1030406@redhat.com> Message-ID: <930bef50-376c-0df0-8472-eceaa22eb02c@redhat.com> On 8/4/16 4:00 AM, Marek Posolda wrote: > On 04/08/16 01:48, Bill Burke wrote: >> I wrote an JPA example for the new User Storage Provider SPI [1]. It >> was very difficult to figure out how to wire in JPA. I'm going to take >> a guess that very very few users have actually tried to implement a >> JPA-based User Federation Provider. They would have run into a ton of >> hurdles. >> >> * Putting just a jar within the "providers/" directory is unusable. JPA >> classes and other dependencies will not be visible. >> >> * So, you have to craft a *CORRECT* module.xml file and know exactly >> which dependencies to bring in. [2] >> >> * javax.persistence.Persistence.createEntityManagerFactory() did not >> work, so I had to call Hibernate APIs directly. Not only that, but >> non-simple Hibernate APIs. [3] >> >> * When configuring JPA I also had to know what classloader to use so >> that persistence.xml was visible. > In some recent release, we added JpaEntityProvider SPI. This allows to > register your own JPA entities with Keycloak own EntityManager . So in > your provider, you don't need to care about the complex stuff like > proprietary Hibernate API, classloader or transaction enlisting. > The JpaEntityProvider SPI extends the keycloak persistence unit. Not very useful if you are integrating some other external RDBMs. > We have a docs [1] and example for that [2] > > [1] > https://keycloak.gitbooks.io/server-developer-guide/content/v/2.1/topics/extensions.html > [2] > https://github.com/patriot1burke/keycloak/tree/master/examples/providers/domain-extension > > > That's much easier, isn't it? Just not sure if it helps with EJB... Easier if you don't need any other dependency defined. What if they want to JAX-RS client and a specific provider from Resteasy? As I mentioned in a previous point, its just not as simple as including the modules. Persistence.createEMF() doesn't work as the classloaders all seem confused. >> * Had to use JpaKeycloakTransaction to enlist EntityManager with >> keycloak transactions. This means using EJBs is out of the question. >> >> This is unacceptable. Keycloak is supposed to be simple and this is >> extremely difficult. When Keycloak was an exploded WAR you could use >> every Java EE component type as you could just plop your extensions >> within META-INF/lib. Classloading was simple as it was all the same >> classloader. >> >> Going forward we need to write an actual deployer for Keycloak >> extensions that allow you to define Keycloak providers within EE jars, >> ears, etc. Writing an extension to Keycloak should be as easy as >> writing a Java EE application. Extension developers should be able to >> leverage the entire JBoss/Wildfly platform. Minimally, we also need to >> begin and commit/rollback a UserTransaction within a Keycloak request >> flow so that transaction EE and Spring component layers can function. > +1 for deployer. Maybe we can try to prototype an example, which uses > stuff like EJB and then see what exactly we need to add? > > For UserTransaction, we can maybe have the KeycloakTransaction > implementation, which will delegate to UserTransaction? Then people > can optionally enlist it in their provider if they need it : > > session.getTransactionManager().enlistAfterCompletion(new > UserTransactionWrapper()); > > Then Keycloak will automatically take care of commit/rollback this > transaction at end of request. Why wouldn't they just use UserTransaction? Bill From mposolda at redhat.com Thu Aug 4 09:56:43 2016 From: mposolda at redhat.com (Marek Posolda) Date: Thu, 4 Aug 2016 15:56:43 +0200 Subject: [keycloak-dev] creating JPA user storage provider difficult In-Reply-To: <930bef50-376c-0df0-8472-eceaa22eb02c@redhat.com> References: <57A2F627.1030406@redhat.com> <930bef50-376c-0df0-8472-eceaa22eb02c@redhat.com> Message-ID: <57A3499B.3080402@redhat.com> On 04/08/16 15:10, Bill Burke wrote: > > > On 8/4/16 4:00 AM, Marek Posolda wrote: >> On 04/08/16 01:48, Bill Burke wrote: >>> I wrote an JPA example for the new User Storage Provider SPI [1]. It >>> was very difficult to figure out how to wire in JPA. I'm going to take >>> a guess that very very few users have actually tried to implement a >>> JPA-based User Federation Provider. They would have run into a ton of >>> hurdles. >>> >>> * Putting just a jar within the "providers/" directory is unusable. >>> JPA >>> classes and other dependencies will not be visible. >>> >>> * So, you have to craft a *CORRECT* module.xml file and know exactly >>> which dependencies to bring in. [2] >>> >>> * javax.persistence.Persistence.createEntityManagerFactory() did not >>> work, so I had to call Hibernate APIs directly. Not only that, but >>> non-simple Hibernate APIs. [3] >>> >>> * When configuring JPA I also had to know what classloader to use so >>> that persistence.xml was visible. >> In some recent release, we added JpaEntityProvider SPI. This allows >> to register your own JPA entities with Keycloak own EntityManager . >> So in your provider, you don't need to care about the complex stuff >> like proprietary Hibernate API, classloader or transaction enlisting. >> > > The JpaEntityProvider SPI extends the keycloak persistence unit. Not > very useful if you are integrating some other external RDBMs. yep, true. > >> We have a docs [1] and example for that [2] >> >> [1] >> https://keycloak.gitbooks.io/server-developer-guide/content/v/2.1/topics/extensions.html >> [2] >> https://github.com/patriot1burke/keycloak/tree/master/examples/providers/domain-extension >> >> >> That's much easier, isn't it? Just not sure if it helps with EJB... > > Easier if you don't need any other dependency defined. What if they > want to JAX-RS client and a specific provider from Resteasy? As I > mentioned in a previous point, its just not as simple as including the > modules. Persistence.createEMF() doesn't work as the classloaders all > seem confused. Yep, so we can address this with some sort of "deployer" you proposed, which will have automatically access to JEE APIs, so people won't need to declare dependencies on them anywhere? Still people always need to deal with modules though, if they don't want just JEE, but also some other different 3rd party dependencies... >>> * Had to use JpaKeycloakTransaction to enlist EntityManager with >>> keycloak transactions. This means using EJBs is out of the question. >>> >>> This is unacceptable. Keycloak is supposed to be simple and this is >>> extremely difficult. When Keycloak was an exploded WAR you could use >>> every Java EE component type as you could just plop your extensions >>> within META-INF/lib. Classloading was simple as it was all the same >>> classloader. >>> >>> Going forward we need to write an actual deployer for Keycloak >>> extensions that allow you to define Keycloak providers within EE jars, >>> ears, etc. Writing an extension to Keycloak should be as easy as >>> writing a Java EE application. Extension developers should be able to >>> leverage the entire JBoss/Wildfly platform. Minimally, we also need to >>> begin and commit/rollback a UserTransaction within a Keycloak request >>> flow so that transaction EE and Spring component layers can function. >> +1 for deployer. Maybe we can try to prototype an example, which uses >> stuff like EJB and then see what exactly we need to add? >> >> For UserTransaction, we can maybe have the KeycloakTransaction >> implementation, which will delegate to UserTransaction? Then people >> can optionally enlist it in their provider if they need it : >> >> session.getTransactionManager().enlistAfterCompletion(new >> UserTransactionWrapper()); >> >> Then Keycloak will automatically take care of commit/rollback this >> transaction at end of request. > Why wouldn't they just use UserTransaction? In case that KeycloakTransaction is rolled back, then it calls rollback to all the enlisted delegates. So enlisted UserTransactionWrapper will then call UserTransaction.rollback as well. Unless we're going to rewrite our transaction API to use JTA? That will automatically integrate with JPA and infinispan. If people needs to enlist their own transaction, they need to implement javax.transaction.xa.XAResource. This looks slightly more complicated then implement our KeycloakTransaction, but on the other hand, it's a standard. Marek > > Bill From bburke at redhat.com Thu Aug 4 10:03:53 2016 From: bburke at redhat.com (Bill Burke) Date: Thu, 4 Aug 2016 10:03:53 -0400 Subject: [keycloak-dev] creating JPA user storage provider difficult In-Reply-To: <57A3499B.3080402@redhat.com> References: <57A2F627.1030406@redhat.com> <930bef50-376c-0df0-8472-eceaa22eb02c@redhat.com> <57A3499B.3080402@redhat.com> Message-ID: On 8/4/16 9:56 AM, Marek Posolda wrote: > Yep, so we can address this with some sort of "deployer" you proposed, > which will have automatically access to JEE APIs, so people won't need > to declare dependencies on them anywhere? Still people always need to > deal with modules though, if they don't want just JEE, but also some > other different 3rd party dependencies... True, but at least we can make a keycloak deployer that is consistent with WARs, etc. Meaning, those that are experienced writing WARs in Wildfly and using jboss-deployment-structure.xml will not have to be completely retrained to write a keycloak component. > >>>> * Had to use JpaKeycloakTransaction to enlist EntityManager with >>>> keycloak transactions. This means using EJBs is out of the question. >>>> >>>> This is unacceptable. Keycloak is supposed to be simple and this is >>>> extremely difficult. When Keycloak was an exploded WAR you could use >>>> every Java EE component type as you could just plop your extensions >>>> within META-INF/lib. Classloading was simple as it was all the same >>>> classloader. >>>> >>>> Going forward we need to write an actual deployer for Keycloak >>>> extensions that allow you to define Keycloak providers within EE jars, >>>> ears, etc. Writing an extension to Keycloak should be as easy as >>>> writing a Java EE application. Extension developers should be able to >>>> leverage the entire JBoss/Wildfly platform. Minimally, we also need to >>>> begin and commit/rollback a UserTransaction within a Keycloak request >>>> flow so that transaction EE and Spring component layers can function. >>> +1 for deployer. Maybe we can try to prototype an example, which >>> uses stuff like EJB and then see what exactly we need to add? >>> >>> For UserTransaction, we can maybe have the KeycloakTransaction >>> implementation, which will delegate to UserTransaction? Then people >>> can optionally enlist it in their provider if they need it : >>> >>> session.getTransactionManager().enlistAfterCompletion(new >>> UserTransactionWrapper()); >>> >>> Then Keycloak will automatically take care of commit/rollback this >>> transaction at end of request. >> Why wouldn't they just use UserTransaction? > In case that KeycloakTransaction is rolled back, then it calls > rollback to all the enlisted delegates. So enlisted > UserTransactionWrapper will then call UserTransaction.rollback as well. > > Unless we're going to rewrite our transaction API to use JTA? That > will automatically integrate with JPA and infinispan. If people needs > to enlist their own transaction, they need to implement > javax.transaction.xa.XAResource. This looks slightly more complicated > then implement our KeycloakTransaction, but on the other hand, it's a > standard. > I think we can/should have both. We automatically begin and enlist a UserTransactionWrapper into the KeycloakTransactionManager at the beginning of a request (in our filter that starts a KeycloakSession). If users want something XA then they implement and integration with JTA. If they want something simpler, than use our KeycloakTransactions. Bill From bburke at redhat.com Thu Aug 4 20:30:25 2016 From: bburke at redhat.com (Bill Burke) Date: Thu, 4 Aug 2016 20:30:25 -0400 Subject: [keycloak-dev] combine proxy and keycloak server Message-ID: <2cc29814-7e14-d55d-ec62-4f0b664dee40@redhat.com> I think we should combine Keycloak Proxy with the keycloak server. When creating a client, you would have an option to declare it as a proxied client. This is way better than what we currently have as we woudln't have to do SAML or OIDC so it would be more performant and it would require no additional setup. From wadahiro at gmail.com Thu Aug 4 21:13:08 2016 From: wadahiro at gmail.com (Hiroyuki Wada) Date: Fri, 5 Aug 2016 10:13:08 +0900 Subject: [keycloak-dev] Japanese Localization In-Reply-To: <57A2F68B.6010401@redhat.com> References: <57A2F68B.6010401@redhat.com> Message-ID: > Just a note that we can accept localization PR if you also take care of > maintain your locale in future releases. Yes, I will maintain it. Regards, -- Hiroyuki Wada On Thu, Aug 4, 2016 at 5:02 PM, Marek Posolda wrote: > Just a note that we can accept localization PR if you also take care of > maintain your locale in future releases. > > Thanks, > Marek > > > On 04/08/16 03:46, Hiroyuki Wada wrote: > > Thanks. I created a JIRA issue. > https://issues.jboss.org/browse/KEYCLOAK-3397 > > I'll send a pull request later! > > > 2016?8?3?(?) 17:05 Thomas Darimont : >> >> Hello Hiroyuki, >> >> I'd say just go ahead and feel free to create a JIRA issue - and reference >> the issue number in your commit like >> KEYCLOAK-XXX Add Japanese localization. >> >> Try to keep your changes in a single commit in your pull request, this >> makes it easier to apply (e.g. via cherry-pick) - I listed my workflow for >> reference below. >> Once you're done with your PR just add a link to it to the JIRA issue (in >> the JIRA issue, press "." then type "git" -> which brings you the to the >> "add git pull request" dialog. >> >> If you want an example for a JIRA issue here is a similar ticket for >> french translation: >> https://issues.jboss.org/browse/KEYCLOAK-1903 >> >> Cheers, >> Thomas >> >> My workflow: >> I tend to create a separate branch for every JIRA issue, so I do the >> following (from a checked out master branch) >> 0) git clone https://github.com/thomasdarimont/keycloak >> (origin is my keycloak fork) >> git remote add upstream https://github.com/keycloak/keycloak >> (upstream is original keycloak) >> 1) git checkout -b issue/KEYCLOAK-XXX-short-description >> (this will create and checkout the branch) >> 2) code... >> 3) git add . >> 4) git commit -m (or use a graphical git client like gitg on linux, or >> gitx on osx) >> 5) git push -u origin issue/KEYCLOAK-XXX-short-description >> 6) on your cloned github project you should now see a link for: create >> pull request for the newly pushed branch - click and the PR is there >> if I need to change stuff in the PR (before it is merged) I do the >> following >> 7) change... >> 8) git add . >> 9) git commit --amend (or use a graphical git client like gitg on linux, >> or gitx on osx) >> 10) git push -f origin issue/KEYCLOAK-XXX-short-description >> (this will update your PR as well, but github is smart enough to retain >> potentially PR comments if those places didn't change) >> 11) goto 7) if necessary >> >> Updating your keycloak fork from original keycloak upstream >> 1) git checkout master >> 2) git pull upstream master >> 3) git push origin master >> (to update the master branch in your fork if necessary) >> >> to update an issue branch to the latest master >> 1) git checkout issue/KEYCLOAK-XXX-short-description >> 2) git rebase master >> (your issue branch is now based on the latest changes from master) >> 3) git push -f origin issue/KEYCLOAK-XXX-short-description >> >> 2016-08-03 5:19 GMT+02:00 Hiroyuki Wada : >>> >>> Hello all, >>> >>> I am translating all base theme messages to Japanaese language now. >>> (I think I can do it by the end of the week.) >>> >>> I'd like to contribute the message resources, How do you think? >>> If it's ok, I'll create a JIRA issue and create a pull request. >>> >>> Regards, >>> >>> -- >>> Hiroyuki Wada >>> wadahiro at gmail.com >>> >>> _______________________________________________ >>> 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 swananddhawan at arvindinternet.com Fri Aug 5 02:44:33 2016 From: swananddhawan at arvindinternet.com (swanand dhawan) Date: Fri, 5 Aug 2016 12:14:33 +0530 Subject: [keycloak-dev] Fwd: Getting CLIENT_NOT_FOUND Exception In-Reply-To: References: Message-ID: ---------- Forwarded message ---------- From: swanand dhawan Date: Fri, Aug 5, 2016 at 12:09 PM Subject: Getting CLIENT_NOT_FOUND Exception To: keycloak-dev Cc: Anunay Sinha ?Hello, I am getting the following error frequently in my logs: *ERROR [org.keycloak.authentication.AuthenticationProcessor] (default task-22) Failed client authentication: CLIENT_NOT_FOUND: org.keycloak.authentication.AuthenticationFlowException* I am attaching the log file with the error. Please help in fixing this error. -- Thanks & Regards, ?? Swanand Dhawan -- Thanks & Regards, Swanand Dhawan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160805/dbaf1df3/attachment.html -------------- next part -------------- A non-text attachment was scrubbed... Name: server.log Type: text/x-log Size: 5810 bytes Desc: not available Url : http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160805/dbaf1df3/attachment.bin From Stephen.Merchant at gandlake.com Fri Aug 5 03:51:27 2016 From: Stephen.Merchant at gandlake.com (Stephen Merchant) Date: Fri, 5 Aug 2016 07:51:27 +0000 Subject: [keycloak-dev] Keycloak 2.0.0 with MongoDB Docker : Keycloak Theming Issue. Message-ID: <3DE4BF1BF8EDD84B8F8D61B0A88BD563102217@EXCH01.gandlake.local> Hello, I have been using a local standalone instance of Keycloak Version 2.00 to create some different themes/skins for Keycloak. This task was successful, and I can login to my local Keycloak server instance and use the Administrator web application skinned as required using a wide variety of browsers. I have now ported these "proven" Keycloak scheme configuration files onto a Keycloak Version 2.00 + MongoDB Docker container running on a remote Linux host. (Specifically, locating my scheme configuration files under folder %KEYCLOAK_HOME%/themes). I have found that only a subset of browsers work successfully for this remote Keycloak instance. Both Firefox and IE work fine. Chrome and Opera do not. I get Java script errors (the Chrome example screenshot shown below, but Opera fails in a similar way) . I would be grateful to know if anyone else has encountered this issue, and even better what they did to overcome it? Any help gratefully received, Thanks [cid:image001.jpg at 01D1EEF5.90E01DA0] Stephen Merchant Developer Gandlake Limited Crown Commercial Service Supplier BSI ISO/IEC 27001 certification number IS 585161 Gandlake Limited, a Limited Liability Company registered in England and Wales under number 4667925. Registered Office: Gandlake House, London Road, Newbury, Berkshire. RG14 1LA. VAT Registration Number 809 7164 11 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160805/b6a57df4/attachment-0001.html -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.jpg Type: image/jpeg Size: 221126 bytes Desc: image001.jpg Url : http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160805/b6a57df4/attachment-0001.jpg From thomas.darimont at googlemail.com Fri Aug 5 04:03:04 2016 From: thomas.darimont at googlemail.com (Thomas Darimont) Date: Fri, 5 Aug 2016 10:03:04 +0200 Subject: [keycloak-dev] Keycloak 2.0.0 with MongoDB Docker : Keycloak Theming Issue. In-Reply-To: <3DE4BF1BF8EDD84B8F8D61B0A88BD563102217@EXCH01.gandlake.local> References: <3DE4BF1BF8EDD84B8F8D61B0A88BD563102217@EXCH01.gandlake.local> Message-ID: Hi Stephen, what files are the sytax errors belonging to? I cannot see the script file name in your image (besides the one error in select2.js). Are you using the provided js resources by keycloak, e.g. via scripts=lib/jquery/jquery-1.10.2.js lib/patternfly/js/patternfly.min.js lib/bootstrap/bootstrap.js in your theme properties, or do you roll your own? Cheers, Thomas 2016-08-05 9:51 GMT+02:00 Stephen Merchant : > Hello, > > I have been using a local standalone instance of Keycloak Version 2.00 to > create some different themes/skins for Keycloak. > > > > This task was successful, and I can login to my local Keycloak server > instance and use the Administrator web application skinned as required > using a wide variety of browsers. > > > > I have now ported these ?proven? Keycloak scheme configuration files onto > a Keycloak Version 2.00 + MongoDB Docker container running on a remote > Linux host. (Specifically, locating my scheme configuration files under > folder *%KEYCLOAK_HOME%/themes*). > > > > I have found that only a subset of browsers work successfully for this > remote Keycloak instance. > > > > *Both Firefox and IE work fine.* Chrome and Opera do *not*. I get Java > script errors (the Chrome example screenshot shown below, but Opera fails > in a similar way) . > > > > I would be grateful to know if anyone else has encountered this issue, and > even better what they did to overcome it? > > > > Any help gratefully received, > > Thanks > > > > > > > > > > > > Stephen Merchant > > Developer > > Gandlake Limited > > > Crown Commercial Service Supplier > BSI ISO/IEC 27001 certification number IS 585161 > > > Gandlake Limited, a Limited Liability Company registered in England and > Wales under number 4667925. Registered Office: Gandlake House, London Road, > Newbury, Berkshire. RG14 1LA. VAT Registration Number 809 7164 11 > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160805/0dd03a86/attachment-0001.html -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.jpg Type: image/jpeg Size: 221126 bytes Desc: not available Url : http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160805/0dd03a86/attachment-0001.jpg From mposolda at redhat.com Fri Aug 5 04:36:10 2016 From: mposolda at redhat.com (Marek Posolda) Date: Fri, 5 Aug 2016 10:36:10 +0200 Subject: [keycloak-dev] creating JPA user storage provider difficult In-Reply-To: References: <57A2F627.1030406@redhat.com> <930bef50-376c-0df0-8472-eceaa22eb02c@redhat.com> <57A3499B.3080402@redhat.com> Message-ID: <57A44FFA.8080502@redhat.com> On 04/08/16 16:03, Bill Burke wrote: > > > On 8/4/16 9:56 AM, Marek Posolda wrote: >> Yep, so we can address this with some sort of "deployer" you >> proposed, which will have automatically access to JEE APIs, so people >> won't need to declare dependencies on them anywhere? Still people >> always need to deal with modules though, if they don't want just JEE, >> but also some other different 3rd party dependencies... > True, but at least we can make a keycloak deployer that is consistent > with WARs, etc. Meaning, those that are experienced writing WARs in > Wildfly and using jboss-deployment-structure.xml will not have to be > completely retrained to write a keycloak component. +1 > >> >>>>> * Had to use JpaKeycloakTransaction to enlist EntityManager with >>>>> keycloak transactions. This means using EJBs is out of the question. >>>>> >>>>> This is unacceptable. Keycloak is supposed to be simple and this is >>>>> extremely difficult. When Keycloak was an exploded WAR you could use >>>>> every Java EE component type as you could just plop your extensions >>>>> within META-INF/lib. Classloading was simple as it was all the same >>>>> classloader. >>>>> >>>>> Going forward we need to write an actual deployer for Keycloak >>>>> extensions that allow you to define Keycloak providers within EE >>>>> jars, >>>>> ears, etc. Writing an extension to Keycloak should be as easy as >>>>> writing a Java EE application. Extension developers should be >>>>> able to >>>>> leverage the entire JBoss/Wildfly platform. Minimally, we also >>>>> need to >>>>> begin and commit/rollback a UserTransaction within a Keycloak request >>>>> flow so that transaction EE and Spring component layers can function. >>>> +1 for deployer. Maybe we can try to prototype an example, which >>>> uses stuff like EJB and then see what exactly we need to add? >>>> >>>> For UserTransaction, we can maybe have the KeycloakTransaction >>>> implementation, which will delegate to UserTransaction? Then people >>>> can optionally enlist it in their provider if they need it : >>>> >>>> session.getTransactionManager().enlistAfterCompletion(new >>>> UserTransactionWrapper()); >>>> >>>> Then Keycloak will automatically take care of commit/rollback this >>>> transaction at end of request. >>> Why wouldn't they just use UserTransaction? >> In case that KeycloakTransaction is rolled back, then it calls >> rollback to all the enlisted delegates. So enlisted >> UserTransactionWrapper will then call UserTransaction.rollback as well. >> >> Unless we're going to rewrite our transaction API to use JTA? That >> will automatically integrate with JPA and infinispan. If people needs >> to enlist their own transaction, they need to implement >> javax.transaction.xa.XAResource. This looks slightly more complicated >> then implement our KeycloakTransaction, but on the other hand, it's a >> standard. >> > I think we can/should have both. We automatically begin and enlist a > UserTransactionWrapper into the KeycloakTransactionManager at the > beginning of a request (in our filter that starts a KeycloakSession). > If users want something XA then they implement and integration with > JTA. If they want something simpler, than use our KeycloakTransactions. +1 assuming that automatically enlist UserTransaction in each request won't have any performance (or other) impact. Marek > > Bill From bburke at redhat.com Fri Aug 5 10:38:13 2016 From: bburke at redhat.com (Bill Burke) Date: Fri, 5 Aug 2016 10:38:13 -0400 Subject: [keycloak-dev] combine proxy and keycloak server In-Reply-To: <2cc29814-7e14-d55d-ec62-4f0b664dee40@redhat.com> References: <2cc29814-7e14-d55d-ec62-4f0b664dee40@redhat.com> Message-ID: Bump. I'm going to keep bumping this occasionally to see if somebody in the community wants to take this on. On 8/4/16 8:30 PM, Bill Burke wrote: > I think we should combine Keycloak Proxy with the keycloak server. When > creating a client, you would have an option to declare it as a proxied > client. This is way better than what we currently have as we woudln't > have to do SAML or OIDC so it would be more performant and it would > require no additional setup. > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev From thomas.darimont at googlemail.com Fri Aug 5 11:36:08 2016 From: thomas.darimont at googlemail.com (Thomas Darimont) Date: Fri, 5 Aug 2016 17:36:08 +0200 Subject: [keycloak-dev] combine proxy and keycloak server In-Reply-To: References: <2cc29814-7e14-d55d-ec62-4f0b664dee40@redhat.com> Message-ID: Sounds interesting... could you provide a bit more detail about what you have in mind? Cheers, Thomas 2016-08-05 16:38 GMT+02:00 Bill Burke : > Bump. > > I'm going to keep bumping this occasionally to see if somebody in the > community wants to take this on. > > > On 8/4/16 8:30 PM, Bill Burke wrote: > > I think we should combine Keycloak Proxy with the keycloak server. When > > creating a client, you would have an option to declare it as a proxied > > client. This is way better than what we currently have as we woudln't > > have to do SAML or OIDC so it would be more performant and it would > > require no additional setup. > > > > _______________________________________________ > > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160805/3078bf6f/attachment.html From bburke at redhat.com Fri Aug 5 15:26:14 2016 From: bburke at redhat.com (Bill Burke) Date: Fri, 5 Aug 2016 15:26:14 -0400 Subject: [keycloak-dev] combine proxy and keycloak server In-Reply-To: References: <2cc29814-7e14-d55d-ec62-4f0b664dee40@redhat.com> Message-ID: Yeah, on the Client creation page, instead of oidc or saml, you can pick "proxied". You would specify the URL pattern of incoming requests and the URL pattern to forward HTTP requests and bam, it just works. Set up some virtual host table on demand with Undertow. On 8/5/16 11:36 AM, Thomas Darimont wrote: > Sounds interesting... > > could you provide a bit more detail about what you have in mind? > > Cheers, > Thomas > > 2016-08-05 16:38 GMT+02:00 Bill Burke >: > > Bump. > > I'm going to keep bumping this occasionally to see if somebody in the > community wants to take this on. > > > On 8/4/16 8:30 PM, Bill Burke wrote: > > I think we should combine Keycloak Proxy with the keycloak > server. When > > creating a client, you would have an option to declare it as a > proxied > > client. This is way better than what we currently have as we > woudln't > > have to do SAML or OIDC so it would be more performant and it would > > require no additional setup. > > > > _______________________________________________ > > 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 > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160805/4982c648/attachment.html From bburke at redhat.com Sat Aug 6 11:31:22 2016 From: bburke at redhat.com (Bill Burke) Date: Sat, 6 Aug 2016 11:31:22 -0400 Subject: [keycloak-dev] JTA issues Message-ID: <20197d32-86b3-acab-e10a-70df451cf358@redhat.com> I hooked in JTA on my branch. When KeycloakSessionFactory.create() is executed this happens: * the code will check the JTA TransactionManager to see if a transaction is currently active * If there is an active transaction, it is suspended (TransactionManager.suspend()). A new one is created and associated with the thread TransactionManager.begin() * A wrapper for the JTA transaction is created and registered with the KeycloakTransactionManager * At transaction completion if there was a suspended JTA transaction it is resumed. There are some issues with this though. You have to modify the KeycloakDS declaration and put in a flag jta="false". If you don't do this then you get errors at boot time with Liquibase. So, that change to KeycloakDS is the actual issue here. Migrating apps will have to set the jta flag before they will be able to run with the latest keycloak version. We may be able to specify a warning at boot time. Bill From bburke at redhat.com Sat Aug 6 11:43:29 2016 From: bburke at redhat.com (Bill Burke) Date: Sat, 6 Aug 2016 11:43:29 -0400 Subject: [keycloak-dev] new provider deployer working on branch! Message-ID: I've implemented a Keycloak provider deployer and it works great. I re-implemented the JPA User Storage SPI example. The provider is now a @Stateful EJB and EntityManager access is all managed by @PersistenceContext. The example now looks really simple and elegant rather than the crap I mentioned before. Would not have worked without the JTA integration I did (see previous email). Things left to do: * hot deployment. Pretty sure I can implement this * Make sure things work in WARs and EARs. * Also thinking of defining a @KeycloakProvider annotation that you can use on your ProviderFactories. This would remove the need to specify a META-INF/services file and the annotation could be scanned for at deployment. Would work like this: @KeycloakProvider(UserStorageProviderFactory.class) public class MyProvider ... { } As a side note, one thing I could look into is the ability to use @Inject of a KeycloakSession. Developer could then write entire web applications that are deployed separately and worked with the keycloak API directly. @Inject KeycloakSession would work similarly to @PersistenceContexts EntityManager. KeycloakSessions would be associated with a transaction. This will give us nice integration with Java EE and give a lot of power to developers wanting to extend keycloak. From alexander.schwartz at gmx.net Sat Aug 6 12:30:17 2016 From: alexander.schwartz at gmx.net (Alexander Schwartz) Date: Sat, 6 Aug 2016 18:30:17 +0200 Subject: [keycloak-dev] Keycloak 2.1.0.CR1 released In-Reply-To: <57A25132.9030007@redhat.com> References: <57A25132.9030007@redhat.com> Message-ID: Hello Marek, 2.1.0.CR1 works great with Dropwizard 1.0 (that required the new Jetty 9.3 adapter). https://github.com/ahus1/keycloak-dropwizard-integration I'm looking forward to the release! Best regards Alexander Am 03.08.2016 um 22:16 schrieb Marek Posolda: > > Keycloak 2.1.0.CR1 has just been released. The final release will > follow next week if no major issues are reported. Few highlights of > this release: > > * *Password Policy SPI* - Now it's possible to plug your own > implementation of password policy. This is useful if available > builtin policies are not sufficient for you. > * *Jetty 9.3 adapter* - Allow you to secure your applications > deployed on Jetty 9.3 server. > * *Authorization fixes & improvements* - There are lots of fixes and > improvements in authorization services, which were recently added > in 2.0 release. It really worth to check this out and eventually > provide us some feedback. > * *Better OpenID Connect interoperability* - There are lots of minor > fixes related to OpenID Connect support. > > For the full list of issues resolved check out JIRA > > and to download the release go to the Keycloak homepage > . > > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev -- Alexander Schwartz (alexander.schwartz at gmx.net) http://www.ahus1.de From thomas.darimont at googlemail.com Mon Aug 8 03:58:14 2016 From: thomas.darimont at googlemail.com (Thomas Darimont) Date: Mon, 8 Aug 2016 09:58:14 +0200 Subject: [keycloak-dev] Using provided AccessToken in Keycloak client Message-ID: Hello group, I have the following scenario: 1) A SSO authenticated User1 calls Service1 (confidential client). 2) Service1 extracts access token. 3) Service1 performs a remote call to Service2 passing the access token along. 4) Service2 needs to do something in the name of User1 in Keycloak (e.g. set a user attribute, or create a new users) 5) Service2 uses org.keycloak.admin.client.Keycloak to communicate with Keycloak to perform the requested operation. I want to be able to propagate the access token in Service to service calls and use the 'org.keycloak.admin.client.Keycloak' client with the provided access token to perform an operation in Keycloak. Currently 'org.keycloak.admin.client.Keycloak' only supports client credentials and / or password, which it uses to get an refresh token to renew a potentially timed out access token. As a PoC I slightly adjusted the Keycloak client to allow for externally provided access tokens: https://gist.github.com/thomasdarimont/d82c4478df997556a9d16afb79787459 I think the Keycloak Client should also support "call once" scenarios with a provided access token out of the box. Shall I create a JIRA for this? Cheers, Thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160808/c496db52/attachment.html From mposolda at redhat.com Mon Aug 8 08:31:13 2016 From: mposolda at redhat.com (Marek Posolda) Date: Mon, 8 Aug 2016 14:31:13 +0200 Subject: [keycloak-dev] JTA issues In-Reply-To: <20197d32-86b3-acab-e10a-70df451cf358@redhat.com> References: <20197d32-86b3-acab-e10a-70df451cf358@redhat.com> Message-ID: <57A87B91.8030005@redhat.com> The question is, if we can fix liquibase instead of require people to change DS? Maybe I can try to continue in your branch later this week and look at it? Another possibility: Don't bootstrap JTA automatically at KeycloakSessionFactory.create() but instead do it just in HTTP requests (in KeycloakSessionServletFilter ). Then liquibase bootstrap won't be an issue? Marek On 06/08/16 17:31, Bill Burke wrote: > I hooked in JTA on my branch. When KeycloakSessionFactory.create() is > executed this happens: > > * the code will check the JTA TransactionManager to see if a transaction > is currently active > > * If there is an active transaction, it is suspended > (TransactionManager.suspend()). A new one is created and associated > with the thread TransactionManager.begin() > > * A wrapper for the JTA transaction is created and registered with the > KeycloakTransactionManager > > * At transaction completion if there was a suspended JTA transaction it > is resumed. > > There are some issues with this though. You have to modify the > KeycloakDS declaration and put in a flag jta="false". If > you don't do this then you get errors at boot time with Liquibase. So, > that change to KeycloakDS is the actual issue here. Migrating apps will > have to set the jta flag before they will be able to run with the latest > keycloak version. We may be able to specify a warning at boot time. > > Bill > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev From mposolda at redhat.com Mon Aug 8 08:37:54 2016 From: mposolda at redhat.com (Marek Posolda) Date: Mon, 8 Aug 2016 14:37:54 +0200 Subject: [keycloak-dev] new provider deployer working on branch! In-Reply-To: References: Message-ID: <57A87D22.2030701@redhat.com> Looks cool. Will these annotations be defined in Keycloak or do we integrate with CDI? Marek On 06/08/16 17:43, Bill Burke wrote: > I've implemented a Keycloak provider deployer and it works great. I > re-implemented the JPA User Storage SPI example. The provider is now a > @Stateful EJB and EntityManager access is all managed by > @PersistenceContext. The example now looks really simple and elegant > rather than the crap I mentioned before. Would not have worked without > the JTA integration I did (see previous email). Things left to do: > > * hot deployment. Pretty sure I can implement this > > * Make sure things work in WARs and EARs. > > * Also thinking of defining a @KeycloakProvider annotation that you can > use on your ProviderFactories. This would remove the need to specify a > META-INF/services file and the annotation could be scanned for at > deployment. Would work like this: > > > @KeycloakProvider(UserStorageProviderFactory.class) > > public class MyProvider ... { > > } > > As a side note, one thing I could look into is the ability to use > @Inject of a KeycloakSession. Developer could then write entire web > applications that are deployed separately and worked with the keycloak > API directly. @Inject KeycloakSession would work similarly to > @PersistenceContexts EntityManager. KeycloakSessions would be > associated with a transaction. This will give us nice integration with > Java EE and give a lot of power to developers wanting to extend keycloak. > > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev From mposolda at redhat.com Mon Aug 8 08:42:24 2016 From: mposolda at redhat.com (Marek Posolda) Date: Mon, 8 Aug 2016 14:42:24 +0200 Subject: [keycloak-dev] Using provided AccessToken in Keycloak client In-Reply-To: References: Message-ID: <57A87E30.3040004@redhat.com> +1 to have support for scenario like this. One small disadvantage of your approach is, that service2 will use accessToken, which was issued to service1. It seems that more proper way might be to have service on Keycloak side, that will allow service2 to exchange the service1 token for it's own token. However that will likely require much more work though... Marek On 08/08/16 09:58, Thomas Darimont wrote: > Hello group, > > I have the following scenario: > 1) A SSO authenticated User1 calls Service1 (confidential client). > 2) Service1 extracts access token. > 3) Service1 performs a remote call to Service2 passing the access > token along. > 4) Service2 needs to do something in the name of User1 in Keycloak > (e.g. set a user attribute, or create a new users) > 5) Service2 uses org.keycloak.admin.client.Keycloak to communicate > with Keycloak > to perform the requested operation. > > I want to be able to propagate the access token in > Service to service calls and use the > 'org.keycloak.admin.client.Keycloak' client > with the provided access token to perform an operation in Keycloak. > > Currently 'org.keycloak.admin.client.Keycloak' only supports client > credentials and / or password, > which it uses to get an refresh token to renew a potentially timed out > access token. > > As a PoC I slightly adjusted the Keycloak client to allow for > externally provided access tokens: > https://gist.github.com/thomasdarimont/d82c4478df997556a9d16afb79787459 > > I think the Keycloak Client should also support "call once" scenarios > with a provided access token out of the box. > > Shall I create a JIRA for this? > > Cheers, > Thomas > > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160808/fcbb50b3/attachment.html From mposolda at redhat.com Mon Aug 8 08:44:26 2016 From: mposolda at redhat.com (Marek Posolda) Date: Mon, 8 Aug 2016 14:44:26 +0200 Subject: [keycloak-dev] Fwd: Getting CLIENT_NOT_FOUND Exception In-Reply-To: References: Message-ID: <57A87EAA.8020305@redhat.com> Guess you have incorrectly defined client in keycloak.json configuration file on adapter side? Make sure the "resource" in keycloak.json corresponds to clientID of the particular client from keycloak admin console. Also make sure to copy client credentials correctly. See our examples for more details. Marek On 05/08/16 08:44, swanand dhawan wrote: > > ---------- Forwarded message ---------- > From: *swanand dhawan* > > Date: Fri, Aug 5, 2016 at 12:09 PM > Subject: Getting CLIENT_NOT_FOUND Exception > To: keycloak-dev > > Cc: Anunay Sinha > > > > ?Hello, > > I am getting the following error frequently in my logs: > *ERROR [org.keycloak.authentication.AuthenticationProcessor] (default > task-22) Failed client authentication: CLIENT_NOT_FOUND: > org.keycloak.authentication.AuthenticationFlowException* > > I am attaching the log file with the error. > Please help in fixing this error. > > -- > Thanks & Regards, > ? ? > Swanand Dhawan > > > > -- > Thanks & Regards, > Swanand Dhawan > > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160808/b051fcb6/attachment.html From bburke at redhat.com Mon Aug 8 08:46:08 2016 From: bburke at redhat.com (Bill Burke) Date: Mon, 8 Aug 2016 08:46:08 -0400 Subject: [keycloak-dev] JTA issues In-Reply-To: <57A87B91.8030005@redhat.com> References: <20197d32-86b3-acab-e10a-70df451cf358@redhat.com> <57A87B91.8030005@redhat.com> Message-ID: <779b7fd3-23e8-d551-acac-7c777f1362a1@redhat.com> On 8/8/16 8:31 AM, Marek Posolda wrote: > The question is, if we can fix liquibase instead of require people to > change DS? Maybe I can try to continue in your branch later this week > and look at it? > It's not just liquibase. J > Another possibility: Don't bootstrap JTA automatically at > KeycloakSessionFactory.create() but instead do it just in HTTP > requests (in KeycloakSessionServletFilter ). Then liquibase bootstrap > won't be an issue? > JPA Model will also barf with the same error if a JTA transaction is started as we do local JPA transactions. So we have to have the datasource flag or change how we interact with EntityManagers. Bill From bburke at redhat.com Mon Aug 8 08:47:32 2016 From: bburke at redhat.com (Bill Burke) Date: Mon, 8 Aug 2016 08:47:32 -0400 Subject: [keycloak-dev] new provider deployer working on branch! In-Reply-To: <57A87D22.2030701@redhat.com> References: <57A87D22.2030701@redhat.com> Message-ID: <6e4a1b85-2b93-53b4-a8ad-5167a3ea9e64@redhat.com> I'm not going to do the @KeycloakProvider annotation. Not sure I like having something that won't work without a deployer. As for KeycloakSession injection, that would probably be a CDI thing. On 8/8/16 8:37 AM, Marek Posolda wrote: > Looks cool. Will these annotations be defined in Keycloak or do we > integrate with CDI? > > Marek > > On 06/08/16 17:43, Bill Burke wrote: >> I've implemented a Keycloak provider deployer and it works great. I >> re-implemented the JPA User Storage SPI example. The provider is now a >> @Stateful EJB and EntityManager access is all managed by >> @PersistenceContext. The example now looks really simple and elegant >> rather than the crap I mentioned before. Would not have worked without >> the JTA integration I did (see previous email). Things left to do: >> >> * hot deployment. Pretty sure I can implement this >> >> * Make sure things work in WARs and EARs. >> >> * Also thinking of defining a @KeycloakProvider annotation that you can >> use on your ProviderFactories. This would remove the need to specify a >> META-INF/services file and the annotation could be scanned for at >> deployment. Would work like this: >> >> >> @KeycloakProvider(UserStorageProviderFactory.class) >> >> public class MyProvider ... { >> >> } >> >> As a side note, one thing I could look into is the ability to use >> @Inject of a KeycloakSession. Developer could then write entire web >> applications that are deployed separately and worked with the keycloak >> API directly. @Inject KeycloakSession would work similarly to >> @PersistenceContexts EntityManager. KeycloakSessions would be >> associated with a transaction. This will give us nice integration with >> Java EE and give a lot of power to developers wanting to extend >> keycloak. >> >> >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev > From thomas.darimont at googlemail.com Mon Aug 8 08:52:26 2016 From: thomas.darimont at googlemail.com (Thomas Darimont) Date: Mon, 08 Aug 2016 12:52:26 +0000 Subject: [keycloak-dev] Using provided AccessToken in Keycloak client In-Reply-To: <57A87E30.3040004@redhat.com> References: <57A87E30.3040004@redhat.com> Message-ID: Thanks Marek, Service2 is more or less a service proxy which performs additional authz checks. So service1 can only access the oidc parts of keycloak but service2 has broader access... Benefit is that the action in Keycloak is performed with the Identity information of the initiating service1 user which is then logged accordingly in Keycloak. Is this token exchange backed by a spec? May I create a JIRA and a PR for my little extension? Cheers, Thomas Marek Posolda schrieb am Mo., 8. Aug. 2016, 14:42: > +1 to have support for scenario like this. > > One small disadvantage of your approach is, that service2 will use > accessToken, which was issued to service1. It seems that more proper way > might be to have service on Keycloak side, that will allow service2 to > exchange the service1 token for it's own token. However that will likely > require much more work though... > > Marek > > > On 08/08/16 09:58, Thomas Darimont wrote: > > Hello group, > > I have the following scenario: > 1) A SSO authenticated User1 calls Service1 (confidential client). > 2) Service1 extracts access token. > 3) Service1 performs a remote call to Service2 passing the access token > along. > 4) Service2 needs to do something in the name of User1 in Keycloak (e.g. > set a user attribute, or create a new users) > 5) Service2 uses org.keycloak.admin.client.Keycloak to communicate with > Keycloak > to perform the requested operation. > > I want to be able to propagate the access token in > Service to service calls and use the 'org.keycloak.admin.client.Keycloak' > client > with the provided access token to perform an operation in Keycloak. > > Currently 'org.keycloak.admin.client.Keycloak' only supports client > credentials and / or password, > which it uses to get an refresh token to renew a potentially timed out > access token. > > As a PoC I slightly adjusted the Keycloak client to allow for externally > provided access tokens: > https://gist.github.com/thomasdarimont/d82c4478df997556a9d16afb79787459 > > I think the Keycloak Client should also support "call once" scenarios with > a provided access token out of the box. > > Shall I create a JIRA for this? > > Cheers, > Thomas > > > _______________________________________________ > keycloak-dev mailing listkeycloak-dev at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-dev > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160808/a35ebcc1/attachment.html From bburke at redhat.com Mon Aug 8 17:51:19 2016 From: bburke at redhat.com (Bill Burke) Date: Mon, 8 Aug 2016 17:51:19 -0400 Subject: [keycloak-dev] new deployer in master Message-ID: <6d547a5b-54ca-a0cf-a25d-a313e6871487@redhat.com> Ok, New provider deployer exists in master. You can package components in any type of deployment. i.e. within a EAR or WAR. Hot deploy works as well. The deployers/ directory and deployment-scanner subsystem is now back in the server. Also added JTA transactions. So, now when a KeycloakSession is created a new JTA transaction is associated with the KeycloakTransactionManager. If there was an existing JTA transactionn, that transaction is suspended and resumed after the keycloak session completes. JTA TransactionManager lookup has an SPI now which you can enable/disable in keycloaks-server.json. If no transaciton manager exists i.e. within the testsuite, JTA is not used at all. I'll be documenting all this eventually. Still have some work to do on the new user federation spi before that though. Bill From thomas.darimont at googlemail.com Tue Aug 9 05:06:25 2016 From: thomas.darimont at googlemail.com (Thomas Darimont) Date: Tue, 9 Aug 2016 11:06:25 +0200 Subject: [keycloak-dev] combine proxy and keycloak server In-Reply-To: References: <2cc29814-7e14-d55d-ec62-4f0b664dee40@redhat.com> Message-ID: FYI, I sent some questions to the undertow dev-mailing list regarding dynamic vhost configuration: http://lists.jboss.org/pipermail/undertow-dev/2016-August/001668.html Cheers, Thomas 2016-08-05 21:26 GMT+02:00 Bill Burke : > Yeah, on the Client creation page, instead of oidc or saml, you can pick > "proxied". You would specify the URL pattern of incoming requests and the > URL pattern to forward HTTP requests and bam, it just works. Set up some > virtual host table on demand with Undertow. > > On 8/5/16 11:36 AM, Thomas Darimont wrote: > > Sounds interesting... > > could you provide a bit more detail about what you have in mind? > > Cheers, > Thomas > > 2016-08-05 16:38 GMT+02:00 Bill Burke : > >> Bump. >> >> I'm going to keep bumping this occasionally to see if somebody in the >> community wants to take this on. >> >> >> On 8/4/16 8:30 PM, Bill Burke wrote: >> > I think we should combine Keycloak Proxy with the keycloak server. When >> > creating a client, you would have an option to declare it as a proxied >> > client. This is way better than what we currently have as we woudln't >> > have to do SAML or OIDC so it would be more performant and it would >> > require no additional setup. >> > >> > _______________________________________________ >> > 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 >> > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160809/e3d72668/attachment.html From mposolda at redhat.com Tue Aug 9 08:24:59 2016 From: mposolda at redhat.com (Marek Posolda) Date: Tue, 9 Aug 2016 14:24:59 +0200 Subject: [keycloak-dev] Using provided AccessToken in Keycloak client In-Reply-To: References: <57A87E30.3040004@redhat.com> Message-ID: <57A9CB9B.9060807@redhat.com> There is this specs, but not sure if it's useful exactly for the case like this : https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-05 +1 from me for JIRA and PR for your little extension for now. Marek On 08/08/16 14:52, Thomas Darimont wrote: > > Thanks Marek, > > Service2 is more or less a service proxy which performs additional > authz checks. So service1 can only access the oidc parts of keycloak > but service2 has broader access... > Benefit is that the action in Keycloak is performed with the Identity > information of the initiating service1 user which is then logged > accordingly in Keycloak. > > Is this token exchange backed by a spec? > > May I create a JIRA and a PR for my little extension? > > Cheers, > Thomas > > > Marek Posolda > > schrieb am Mo., 8. Aug. 2016, 14:42: > > +1 to have support for scenario like this. > > One small disadvantage of your approach is, that service2 will use > accessToken, which was issued to service1. It seems that more > proper way might be to have service on Keycloak side, that will > allow service2 to exchange the service1 token for it's own token. > However that will likely require much more work though... > > Marek > > > On 08/08/16 09:58, Thomas Darimont wrote: >> Hello group, >> >> I have the following scenario: >> 1) A SSO authenticated User1 calls Service1 (confidential client). >> 2) Service1 extracts access token. >> 3) Service1 performs a remote call to Service2 passing the access >> token along. >> 4) Service2 needs to do something in the name of User1 in >> Keycloak (e.g. set a user attribute, or create a new users) >> 5) Service2 uses org.keycloak.admin.client.Keycloak to >> communicate with Keycloak >> to perform the requested operation. >> >> I want to be able to propagate the access token in >> Service to service calls and use the >> 'org.keycloak.admin.client.Keycloak' client >> with the provided access token to perform an operation in Keycloak. >> >> Currently 'org.keycloak.admin.client.Keycloak' only supports >> client credentials and / or password, >> which it uses to get an refresh token to renew a potentially >> timed out access token. >> >> As a PoC I slightly adjusted the Keycloak client to allow for >> externally provided access tokens: >> https://gist.github.com/thomasdarimont/d82c4478df997556a9d16afb79787459 >> >> I think the Keycloak Client should also support "call once" >> scenarios with a provided access token out of the box. >> >> Shall I create a JIRA for this? >> >> Cheers, >> Thomas >> >> >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160809/fac779f2/attachment-0001.html From bburke at redhat.com Tue Aug 9 09:15:24 2016 From: bburke at redhat.com (Bill Burke) Date: Tue, 9 Aug 2016 09:15:24 -0400 Subject: [keycloak-dev] new generic component storage Message-ID: I've implemented a new generic component storage, api, REST API, and admin console support. Classes/interfaces are in server-spi org.keycloak.component package and created via methods in RealmModel. It is basically a more generic form of mapper models, UserFederationModel, etc. Components describe themselves and can be generically rendered by the admin console. The storage model is meant to support nested subcomponents (i.e. UserFederationModel and UserFederationMappers). Config now supports a MultivaluedHashmap instead of a flat Map to support list storage. There is a common REST API under the realm that should be usable for all component types. The UserStorage SPI uses this new SPI from top to bottom. We should consider whether we want to migrate other component types to this new model. When you create components to store, you specify a parentId (i.e. Realm, Client, a parent component), a provider type, a provider id, and config. For export, the json model will contain components under Realm and Client where the perspective parentId is Realm and Client. I still want to make this as human consumable as possible so that these components can be defined by humans in json. Bill From srossillo at smartling.com Tue Aug 9 22:38:24 2016 From: srossillo at smartling.com (Scott Rossillo) Date: Tue, 9 Aug 2016 22:38:24 -0400 Subject: [keycloak-dev] Open Node.js Connect Pull Requests Message-ID: <28E75740-404D-420E-8A6B-6C6F6674C15C@smartling.com> Any chance someone can review the two PRs I opened over a week ago on the Keycloak connect Node.js module[0]? Fix for KEYCLOAK-3384 is critical and KEYCLOAK-3387 is also a high priority change but may require some discussion on the approach. Thanks in advance, Scott [0]: https://github.com/keycloak/keycloak-nodejs-connect/pulls Scott Rossillo Senior Software Engineer Smartling, Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160809/8d8f476c/attachment.html From mposolda at redhat.com Wed Aug 10 06:25:13 2016 From: mposolda at redhat.com (Marek Posolda) Date: Wed, 10 Aug 2016 12:25:13 +0200 Subject: [keycloak-dev] Keycloak 2.1.0.Final released Message-ID: <57AB0109.30708@redhat.com> Keycloak 2.1.0.Final has just been released. This release only contains one fix related to Authorization services since 2.1.0.CR1 release. For the list of resolved issues check out JIRA and to download the release go to the Keycloak homepage . Before you upgrade refer to the migration guide -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160810/4159b30b/attachment.html From bruno at abstractj.org Wed Aug 10 10:46:54 2016 From: bruno at abstractj.org (Bruno Oliveira) Date: Wed, 10 Aug 2016 11:46:54 -0300 Subject: [keycloak-dev] Open Node.js Connect Pull Requests In-Reply-To: <28E75740-404D-420E-8A6B-6C6F6674C15C@smartling.com> References: <28E75740-404D-420E-8A6B-6C6F6674C15C@smartling.com> Message-ID: <20160810144654.GA4624@abstractj.org> Thanks for the changes Scott, if they are critical or high priority. I'd appreciate if you could attach some tests in both PRs to reproduce the respective issues. On 2016-08-09, Scott Rossillo wrote: > Any chance someone can review the two PRs I opened over a week ago on the Keycloak connect Node.js module[0]? > > Fix for KEYCLOAK-3384 is critical and KEYCLOAK-3387 is also a high priority change but may require some discussion on the approach. > > Thanks in advance, > Scott > > [0]: https://github.com/keycloak/keycloak-nodejs-connect/pulls > > > Scott Rossillo > Senior Software Engineer > Smartling, Inc. > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev -- abstractj PGP: 0x84DC9914 From petervn1 at yahoo.com Wed Aug 10 11:34:44 2016 From: petervn1 at yahoo.com (Peter Nalyvayko) Date: Wed, 10 Aug 2016 15:34:44 +0000 (UTC) Subject: [keycloak-dev] Need to add a system dependency path to modules\system\layers\base\sun\jdk\main\module.xml References: <1840193122.477088.1470843284348.ref@mail.yahoo.com> Message-ID: <1840193122.477088.1470843284348@mail.yahoo.com> Hi,Can somebody shed some light on what generates the module.xml at the location in the subj? I need to add a missing system dependency path to the aforementioned file, but unsure as to where in the source code tree and to which files the changes are supposed to be applied. Right now the contents of the file look like this: ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ...?? ? ? ? ? ? ? ? ? ? /// <-- Intended changes ? ? ? ? ? ? ? ? ? ? ...? ? ? ? ? ? .... RegardsPeter -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160810/a10dd181/attachment.html From bburke at redhat.com Wed Aug 10 11:35:50 2016 From: bburke at redhat.com (Bill Burke) Date: Wed, 10 Aug 2016 11:35:50 -0400 Subject: [keycloak-dev] rethinking credentials Message-ID: <49425643-9824-9fb7-d3c0-8fea12539f94@redhat.com> The credential API for users needs to change. Here are the types of credentials and how system interacts: 1. Creds stored, gathered, and validated by Keycloak OOTB code. 2. Creds stored in external store, but gathered and validated by Keycloak OOTB code. (i.e. User Storage SPI returns the credentials directly) 3. Creds gathered by built-in Keycloak OOTB code, but stored and validated externally (i.e. LDAP). 4. Creds gathered by custom Authenticators, stored and validated externally. 5. Creds gathered by custom authenticators, stored by keycloak, validated by custom code. There's other combinations as well: a. Keycloak stored User, custom credential store b. User Storage Provider, keycloak stored creds c. User Storage Provider, custom credential store Credentials that are validated by Keycloak are currently cached along with the user. What sucks about this that some credential types require a database update, i.e. HOTP which needs to update a counter. So HOTP invalidates the user cache every single login. We also want to allow custom credential stores to be able to cache themselves along with the user. What's interesting about #4 is that there really doesn't need to be any special SPI. The custom authenticator can lookup the factory and typecast it to any interface it wants to to validate the credential. Since our caching layer is a local-only (invalidation cache), cachable custom externally stored credentials just need a simple. Given all this, gonna put some iterations in on a new credential API. Any other thoughts? From ssilvert at redhat.com Wed Aug 10 12:10:44 2016 From: ssilvert at redhat.com (Stan Silvert) Date: Wed, 10 Aug 2016 12:10:44 -0400 Subject: [keycloak-dev] Need to add a system dependency path to modules\system\layers\base\sun\jdk\main\module.xml In-Reply-To: <1840193122.477088.1470843284348@mail.yahoo.com> References: <1840193122.477088.1470843284348.ref@mail.yahoo.com> <1840193122.477088.1470843284348@mail.yahoo.com> Message-ID: <57AB5204.9090201@redhat.com> File a JIRA against WildFly Core. https://issues.jboss.org/projects/WFCORE If they reject the JIRA, come back to us and we can discuss further. On 8/10/2016 11:34 AM, Peter Nalyvayko wrote: > Hi, > Can somebody shed some light on what generates the module.xml at the > location in the subj? I need to add a missing system dependency path > to the aforementioned file, but unsure as to where in the source code > tree and to which files the changes are supposed to be applied. Right > now the contents of the file look like this: > > > > > > > > > > > ... > /// <-- Intended changes > ... > > .... > > Regards > Peter > > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160810/f16e8e49/attachment-0001.html From pnalyvayko at agi.com Wed Aug 10 12:41:16 2016 From: pnalyvayko at agi.com (Nalyvayko, Peter) Date: Wed, 10 Aug 2016 16:41:16 +0000 Subject: [keycloak-dev] Need to add a system dependency path to modules\system\layers\base\sun\jdk\main\module.xml In-Reply-To: <57AB5204.9090201@redhat.com> References: <1840193122.477088.1470843284348.ref@mail.yahoo.com> <1840193122.477088.1470843284348@mail.yahoo.com>, <57AB5204.9090201@redhat.com> Message-ID: Ok, thanks, done. ________________________________________ From: keycloak-dev-bounces at lists.jboss.org [keycloak-dev-bounces at lists.jboss.org] on behalf of Stan Silvert [ssilvert at redhat.com] Sent: Wednesday, August 10, 2016 12:10 PM To: keycloak-dev at lists.jboss.org Subject: Re: [keycloak-dev] Need to add a system dependency path to modules\system\layers\base\sun\jdk\main\module.xml File a JIRA against WildFly Core. https://issues.jboss.org/projects/WFCORE If they reject the JIRA, come back to us and we can discuss further. On 8/10/2016 11:34 AM, Peter Nalyvayko wrote: Hi, Can somebody shed some light on what generates the module.xml at the location in the subj? I need to add a missing system dependency path to the aforementioned file, but unsure as to where in the source code tree and to which files the changes are supposed to be applied. Right now the contents of the file look like this: ... /// <-- Intended changes ... .... Regards Peter _______________________________________________ keycloak-dev mailing list keycloak-dev at lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-dev From bruno at abstractj.org Wed Aug 10 14:20:24 2016 From: bruno at abstractj.org (Bruno Oliveira) Date: Wed, 10 Aug 2016 15:20:24 -0300 Subject: [keycloak-dev] Removal of UserDataAdapter Message-ID: <20160810182024.GB4624@abstractj.org> Maybe is just my ignorance, but seems like UserDataAdapter[1] is never used. Can we delete it? [1] - https://github.com/keycloak/keycloak/blob/master/server-spi/src/main/java/org/keycloak/storage/changeset/UserDataAdapter.java -- abstractj PGP: 0x84DC9914 From bburke at redhat.com Wed Aug 10 15:15:46 2016 From: bburke at redhat.com (Bill Burke) Date: Wed, 10 Aug 2016 15:15:46 -0400 Subject: [keycloak-dev] Removal of UserDataAdapter In-Reply-To: <20160810182024.GB4624@abstractj.org> References: <20160810182024.GB4624@abstractj.org> Message-ID: <8f9f27bf-a5bd-ce44-f14b-0f68e0d5dc2a@redhat.com> Yes. Everything under changeset can be removed. On 8/10/16 2:20 PM, Bruno Oliveira wrote: > Maybe is just my ignorance, but seems like UserDataAdapter[1] is never > used. Can we delete it? > > [1] - https://github.com/keycloak/keycloak/blob/master/server-spi/src/main/java/org/keycloak/storage/changeset/UserDataAdapter.java > > -- > > abstractj > PGP: 0x84DC9914 > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev From mitya at cargosoft.ru Wed Aug 10 16:45:55 2016 From: mitya at cargosoft.ru (Dmitry Telegin) Date: Wed, 10 Aug 2016 23:45:55 +0300 Subject: [keycloak-dev] new deployer in master In-Reply-To: <6d547a5b-54ca-a0cf-a25d-a313e6871487@redhat.com> References: <6d547a5b-54ca-a0cf-a25d-a313e6871487@redhat.com> Message-ID: <1470861955.4498.3.camel@cargosoft.ru> Hi Bill, great job! Hot [re]deployment of providers was much anticipated. Do you think it could be integrated with Maven and/or jboss-cli? For those extension developers who need to redeploy their providers dozens of times a day that would be priceless. Dmitry > Ok, > > > New provider deployer exists in master.??You can package components in? > > any type of deployment.??i.e. within a EAR or WAR. Hot deploy works as? > > well.??The deployers/ directory and deployment-scanner subsystem is now? > back in the server.??Also added JTA transactions.??So, now when a? > > KeycloakSession is created a new JTA transaction is associated with the? > > KeycloakTransactionManager.??If there was an existing JTA transactionn,? > that transaction is suspended and resumed after the keycloak session? > > completes.??JTA TransactionManager lookup has an SPI now which you can? > enable/disable in keycloaks-server.json.??If no transaciton manager? > exists i.e. within the testsuite, JTA is not used at all. > > > I'll be documenting all this eventually.??Still have some work to do on? > the new user federation spi before that though. > > Bill > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160810/f8af0e66/attachment.html From mitya at cargosoft.ru Wed Aug 10 17:14:09 2016 From: mitya at cargosoft.ru (Dmitry Telegin) Date: Thu, 11 Aug 2016 00:14:09 +0300 Subject: [keycloak-dev] new provider deployer working on branch! In-Reply-To: References: Message-ID: <1470863649.4498.16.camel@cargosoft.ru> Hi, > As a side note, one thing I could look into is the ability to use? > @Inject of a KeycloakSession.??Developer could then write entire web? > > applications that are deployed separately and worked with the keycloak? > API directly.??@Inject KeycloakSession would work similarly to? > @PersistenceContexts EntityManager. > Sounds incredibly cool! From my practice I can say that applications often need to perform queries on an IdM layer; such queries can make an essential part of application's business logic (ex., "retrieve all the members of groups the current user is a member of"). For that, native KeyCloak API seems to be much more convenient than REST. But if I get it right, this will be limited to webapps deployed to the same WildFly instance. Do you think this approach could be nevertheless extended to webapps running in separate JVMs/appservers, or REST is the only option here? Looking forward, as soon as JSR-375 is ready, do you think KeyCloak could adopt it? Dmitry -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160811/8388d11f/attachment.html From bburke at redhat.com Wed Aug 10 18:07:51 2016 From: bburke at redhat.com (Bill Burke) Date: Wed, 10 Aug 2016 18:07:51 -0400 Subject: [keycloak-dev] new deployer in master In-Reply-To: <1470861955.4498.3.camel@cargosoft.ru> References: <6d547a5b-54ca-a0cf-a25d-a313e6871487@redhat.com> <1470861955.4498.3.camel@cargosoft.ru> Message-ID: <4bc3f962-6178-6fdb-5fee-c62712f19d4d@redhat.com> It will work with either maven ( wildfly-maven-plugin) or jboss-cli. Its written as a Wildfly/JBoss deployer, so you can use standard deployment options. Again, also, you can embed providers within EARs and WARs too, really any deployable component. That's what I love about the Wildfly Deployment architecture. On 8/10/16 4:45 PM, Dmitry Telegin wrote: > Hi Bill, great job! Hot [re]deployment of providers was much anticipated. > > Do you think it could be integrated with Maven and/or jboss-cli? For > those extension developers who need to redeploy their providers dozens > of times a day that would be priceless. > > Dmitry > >> Ok, >> >> New provider deployer exists in master. You can package components in >> any type of deployment. i.e. within a EAR or WAR. Hot deploy works as >> well. The deployers/ directory and deployment-scanner subsystem is now >> back in the server. Also added JTA transactions. So, now when a >> KeycloakSession is created a new JTA transaction is associated with the >> KeycloakTransactionManager. If there was an existing JTA transactionn, >> that transaction is suspended and resumed after the keycloak session >> completes. JTA TransactionManager lookup has an SPI now which you can >> enable/disable in keycloaks-server.json. If no transaciton manager >> exists i.e. within the testsuite, JTA is not used at all. >> >> I'll be documenting all this eventually. Still have some work to do on >> the new user federation spi before that though. >> >> Bill >> >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160810/10589991/attachment.html From bburke at redhat.com Wed Aug 10 18:42:02 2016 From: bburke at redhat.com (Bill Burke) Date: Wed, 10 Aug 2016 18:42:02 -0400 Subject: [keycloak-dev] new provider deployer working on branch! In-Reply-To: <1470863649.4498.16.camel@cargosoft.ru> References: <1470863649.4498.16.camel@cargosoft.ru> Message-ID: <1aaaedbf-e912-0964-4c57-d538d8d1a673@redhat.com> On 8/10/16 5:14 PM, Dmitry Telegin wrote: > Hi, > >> As a side note, one thing I could look into is the ability to use >> @Inject of a KeycloakSession. Developer could then write entire web >> applications that are deployed separately and worked with the keycloak >> API directly. @Inject KeycloakSession would work similarly to >> @PersistenceContexts EntityManager. > Sounds incredibly cool! From my practice I can say that applications > often need to perform queries on an IdM layer; such queries can make > an essential part of application's business logic (ex., "retrieve all > the members of groups the current user is a member of"). For that, > native KeyCloak API seems to be much more convenient than REST. > > But if I get it right, this will be limited to webapps deployed to the > same WildFly instance. Do you think this approach could be > nevertheless extended to webapps running in separate JVMs/appservers, > or REST is the only option here? > Will only be able to deploy extensions on the servers Keycloak runs on. Otherwise, REST API would have to be used For very good reason, we are dependent on Wildfly/JBoss for JTA, deployers, management, clustering, caching, etc. It is just way too much effort to make all that infrastructure pluggable. So no way we could provide extensions within a separate JVM or vendor app server. We could eventually allow the Keycloak subsystem to turn off various services, but this subsystem would need to run in the same cluster as the SSO server or you could easily end up with stale caches. > Looking forward, as soon as JSR-375 is ready, do you think KeyCloak > could adopt it? > Just taking a quick look, I would say not for a very long time. Its unclear to me what it is. Is it a JASPIC redo? Or a role-your-own IDP? For the former, EE 8 won't be widely available for years, so whats the point? JASPIC sucks and is implemented different on every platform. As for the former, that is just not a viable direction for any spec to go as every "identity store" has its own peculiarities. What you need is a well defined model and you integrate with that well defined model. Something too generic is useless. Bill From j.kamal at ymail.com Thu Aug 11 08:20:29 2016 From: j.kamal at ymail.com (Kamal Jagadevan) Date: Thu, 11 Aug 2016 12:20:29 +0000 (UTC) Subject: [keycloak-dev] SAML Subsequent login fails with Account disabled error References: <866458232.12507273.1470918029020.JavaMail.yahoo.ref@mail.yahoo.com> Message-ID: <866458232.12507273.1470918029020.JavaMail.yahoo@mail.yahoo.com> Hello,? We are using Keycloak 1.9.2 for our Authentication flow and SAML interactions (not using SAML adapters) and they are working well in DEV/QA instances.But in Integration environment we are seeing a strange issue of ONLY FIRST TIME login works fine. Further login fails with the following error even though user is enabled. "Account is disabled, contact admin."? Is there anything obvious that we have missed please advise. Enabling debug log didnt reveal anything other than fetching entities from db.Any inputs to debug further is also welcome. Setting in Federated Identity -? First login flow is set to First Broker Login flow Settings in First login flow - Disabled Review profile page, rest of the properties was set to default values altering rest of the fields didnt change the behavior. Following are the sequence of steps - With the help of static login URL to Keycloak with suffixed by the KC_IDP_HINT, Keycloak redirects to External IDP - Verified for the SAML request being sent using SAML Tracer. - External IDP login prompts for username and password. - After entering credentials, redirected back to Keycloak for getting token but THROWS error "Account is disabled, contact admin" - Verified the SAML response with Assertion status as success using SAML tracer. - Verified the user is enabled from the Admin console. - Verified the user_entity table for the status. BestKamal -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160811/11c1920a/attachment.html From mposolda at redhat.com Thu Aug 11 10:39:28 2016 From: mposolda at redhat.com (Marek Posolda) Date: Thu, 11 Aug 2016 16:39:28 +0200 Subject: [keycloak-dev] rethinking credentials In-Reply-To: <49425643-9824-9fb7-d3c0-8fea12539f94@redhat.com> References: <49425643-9824-9fb7-d3c0-8fea12539f94@redhat.com> Message-ID: <57AC8E20.3020809@redhat.com> I wonder if we can have UserCredentialValueModel to be more generic store? Currently it has properties applicable just to password or OTP credentials, but it will be better to have something more generic based on key-value pairs though. For caching of credentials, should it be made configurable if credentials are cached or not? Currently the creds from DB are always cached, which can be an issue for someone in theory (For example if someone do heapdump of Java process, he might be able to see the cached credentials). Marek On 10/08/16 17:35, Bill Burke wrote: > The credential API for users needs to change. Here are the types of > credentials and how system interacts: > > 1. Creds stored, gathered, and validated by Keycloak OOTB code. > > 2. Creds stored in external store, but gathered and validated by > Keycloak OOTB code. (i.e. User Storage SPI returns the credentials > directly) > > 3. Creds gathered by built-in Keycloak OOTB code, but stored and > validated externally (i.e. LDAP). > > 4. Creds gathered by custom Authenticators, stored and validated externally. > > 5. Creds gathered by custom authenticators, stored by keycloak, > validated by custom code. > > There's other combinations as well: > > a. Keycloak stored User, custom credential store > > b. User Storage Provider, keycloak stored creds > > c. User Storage Provider, custom credential store > > Credentials that are validated by Keycloak are currently cached along > with the user. What sucks about this that some credential types require > a database update, i.e. HOTP which needs to update a counter. So HOTP > invalidates the user cache every single login. We also want to allow > custom credential stores to be able to cache themselves along with the user. > > What's interesting about #4 is that there really doesn't need to be any > special SPI. The custom authenticator can lookup the factory and > typecast it to any interface it wants to to validate the credential. > Since our caching layer is a local-only (invalidation cache), cachable > custom externally stored credentials just need a simple. > > Given all this, gonna put some iterations in on a new credential API. > Any other thoughts? > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev From mposolda at redhat.com Thu Aug 11 10:57:46 2016 From: mposolda at redhat.com (Marek Posolda) Date: Thu, 11 Aug 2016 16:57:46 +0200 Subject: [keycloak-dev] new generic component storage In-Reply-To: References: Message-ID: <57AC926A.20907@redhat.com> One thing partially related to this: - Can we have the possibility in admin console, so the particular provider can "override" the default template for particular provider type? The generic configuration based on kc-provider-config directive works fine, but in some cases, people may want something more specific for their provider. As an example, we currently have custom template "federated-ldap.html" just for LDAP Federation provider and for all the others, we have "federated-generic.html" . People don't have possibility to easily add their own templates for custom FederationProvider implementation. What I mean is, that if there is FooFederationProviderFactory with ID "foo" and there is template "federated-foo.html", then Keycloak will use this one template instead of "federated-generic.html" . This should work just when people provide their own HTML template and copy into theme, but they won't need to change any builtin Keycloak templates ( app.js and others). Marek On 09/08/16 15:15, Bill Burke wrote: > I've implemented a new generic component storage, api, REST API, and > admin console support. Classes/interfaces are in server-spi > org.keycloak.component package and created via methods in RealmModel. > It is basically a more generic form of mapper models, > UserFederationModel, etc. Components describe themselves and can be > generically rendered by the admin console. The storage model is meant > to support nested subcomponents (i.e. UserFederationModel and > UserFederationMappers). Config now supports a MultivaluedHashmap > instead of a flat Map to support list storage. There is a common REST > API under the realm that should be usable for all component types. The > UserStorage SPI uses this new SPI from top to bottom. > > We should consider whether we want to migrate other component types to > this new model. > > When you create components to store, you specify a parentId (i.e. Realm, > Client, a parent component), a provider type, a provider id, and > config. For export, the json model will contain components under Realm > and Client where the perspective parentId is Realm and Client. I still > want to make this as human consumable as possible so that these > components can be defined by humans in json. > > Bill > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev From mposolda at redhat.com Thu Aug 11 11:15:18 2016 From: mposolda at redhat.com (Marek Posolda) Date: Thu, 11 Aug 2016 17:15:18 +0200 Subject: [keycloak-dev] Pairwise Subject Identifier In-Reply-To: References: Message-ID: <57AC9686.5040807@redhat.com> Sorry for late response. We have JIRA created for that. You can possibly add yourself as a watcher. See https://issues.jboss.org/browse/KEYCLOAK-3422 Maybe an alternative for you is to use protocolMappers. That should allow you to "construct" the token for particular client exactly how you want and also use the different value for "sub" claim. Another possibility is, to handle this on adapter side. We already have an adapter option "principal-attribute", which specifies that application will see the different attribute instead of "sub" as subject. For example when in appllication you call "httpServletRequest.getRemoteUser()" it will return "john" instead of "123456-unique-johns-uuid" . See https://keycloak.gitbooks.io/securing-client-applications-guide/content/v/2.1/topics/oidc/java/java-adapter-config.html Hopefully some of the options can be useful for you? Marek On 02/08/16 14:13, Martin Hardselius wrote: > Me and my team are working towards getting Keycloak, customized for > our needs, into production but we've identified the need for Pairwise > Subject Identifiers as we don't want to expose internal user ids. > > Right now, the only subject_types_supported seems to be "public". Are > there any near-future plans to include "pairwise"? Can we pitch in > with a PR to make this happen as soon as possible? > > Links to relevant sections in the spec: > > http://openid.net/specs/openid-connect-core-1_0.html#SubjectIDTypes > http://openid.net/specs/openid-connect-core-1_0.html#PairwiseAlg > > -- > Martin > > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160811/005911ee/attachment.html From mposolda at redhat.com Thu Aug 11 11:30:34 2016 From: mposolda at redhat.com (Marek Posolda) Date: Thu, 11 Aug 2016 17:30:34 +0200 Subject: [keycloak-dev] Dynamic client registrations without initial-access-token Message-ID: <57AC9A1A.6070304@redhat.com> According to the specification http://openid.net/specs/openid-connect-registration-1_0.html#ClientRegistration there is this: "To support open Dynamic Registration, the Client Registration Endpoint SHOULD accept registration requests without OAuth 2.0 Access Tokens. These requests MAY be rate-limited or otherwise limited to prevent a denial-of-service attack on the Client Registration Endpoint." So it looks we need to have a way to allow dynamic client registrations even without Initial Access Token. Without supporting it, we are not able to move forward with OIDC conformance testsuite with "Dynamic" profile as it seems there is not a way to retrieve initialAccessToken from Keycloak and "inject" it to conformance testsuite. So I've added the possibility to define trusted hosts under "Initial Access Tokens" tab. Client registration requests from those hosts are permitted even without initial-access-token . It's possible to limit the count of registrations for each host similarly like is for "Initial Access Tokens". This approach allows to move forward with OIDC Conformance testsuite with "Dynamic" profile. If you agree and we move forward with this approach, then we should consider to rename "Initial Access Tokens" tab to "Client Registration" or "Dynamic Client Registration" ? As Initial Access Tokens are anyway related just to dynamic client registrations. WDYT? Marek From bburke at redhat.com Thu Aug 11 13:40:24 2016 From: bburke at redhat.com (Bill Burke) Date: Thu, 11 Aug 2016 13:40:24 -0400 Subject: [keycloak-dev] new generic component storage In-Reply-To: <57AC926A.20907@redhat.com> References: <57AC926A.20907@redhat.com> Message-ID: On 8/11/16 10:57 AM, Marek Posolda wrote: > One thing partially related to this: > > - Can we have the possibility in admin console, so the particular > provider can "override" the default template for particular provider > type? The generic configuration based on kc-provider-config directive > works fine, but in some cases, people may want something more specific > for their provider. > I think its just a matter of making sure you order your $routeProvider's appropriately. Break $routeProvider registrations into their own file (routeprovider.js) and you just make sure you include your javascript file before the routeprovider.js. Bill From ayoung at redhat.com Thu Aug 11 13:57:31 2016 From: ayoung at redhat.com (Adam Young) Date: Thu, 11 Aug 2016 13:57:31 -0400 Subject: [keycloak-dev] Proof of concept of Keycloak Federation with OpenStack Message-ID: <4f978467-c4b9-f4a2-3d6f-6903fc976607@redhat.com> Not too much on the KeyCloak side, as that was pretty straightforward. used the Python SP registration tool; Still, thanks for your help getting this far. http://adam.younglogic.com/2016/08/ooo-ha-fed-poc/ From bburke at redhat.com Thu Aug 11 14:21:09 2016 From: bburke at redhat.com (Bill Burke) Date: Thu, 11 Aug 2016 14:21:09 -0400 Subject: [keycloak-dev] Proof of concept of Keycloak Federation with OpenStack In-Reply-To: <4f978467-c4b9-f4a2-3d6f-6903fc976607@redhat.com> References: <4f978467-c4b9-f4a2-3d6f-6903fc976607@redhat.com> Message-ID: Great work! On 8/11/16 1:57 PM, Adam Young wrote: > Not too much on the KeyCloak side, as that was pretty straightforward. > used the Python SP registration tool; > > Still, thanks for your help getting this far. > > http://adam.younglogic.com/2016/08/ooo-ha-fed-poc/ > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev From psilva at redhat.com Thu Aug 11 14:31:05 2016 From: psilva at redhat.com (Pedro Igor Silva) Date: Thu, 11 Aug 2016 14:31:05 -0400 (EDT) Subject: [keycloak-dev] Proof of concept of Keycloak Federation with OpenStack In-Reply-To: References: <4f978467-c4b9-f4a2-3d6f-6903fc976607@redhat.com> Message-ID: <251213242.2635315.1470940265186.JavaMail.zimbra@redhat.com> Awesome ! ----- Original Message ----- From: "Bill Burke" To: keycloak-dev at lists.jboss.org Sent: Thursday, August 11, 2016 3:21:09 PM Subject: Re: [keycloak-dev] Proof of concept of Keycloak Federation with OpenStack Great work! On 8/11/16 1:57 PM, Adam Young wrote: > Not too much on the KeyCloak side, as that was pretty straightforward. > used the Python SP registration tool; > > Still, thanks for your help getting this far. > > http://adam.younglogic.com/2016/08/ooo-ha-fed-poc/ > > _______________________________________________ > 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 bruno at abstractj.org Thu Aug 11 15:12:02 2016 From: bruno at abstractj.org (Bruno Oliveira) Date: Thu, 11 Aug 2016 16:12:02 -0300 Subject: [keycloak-dev] Readonly UserModel Message-ID: <20160811191202.GA9716@abstractj.org> Ahoy, after exploring some ideas I implemented the initial draft[1] for KEYCLOAK-3060[2]. Before submitting any changes, I would like some feedback. - Motivation Disable input fields when read-only federation providers like SSSD or LDAP (read-only mode) are enabled. Another alternative would be just hide sections which people are not supposed to edit. For example: account, OTP and password section. To be honest, I'm 50/50 about it, because hiding sections could be confusing to users. - Pros * Users won't get frustrated trying to update their profile, to later find out that's not possible. * Input fields will truly represent what our user is, into other words, read-only - Cons * UserModel from my perspective is the only possible place to introduce this change[3] (I can be wrong). The drawback is that the change will affect all the implementing classes. - Options 1. If you are fine with the changes here[1]. I could do some clean up, write the proper integration tests and work to get it merged. 2. Do nothing and leave it as is. Thoughts? [1] - https://github.com/abstractj/keycloak/tree/KEYCLOAK-3060 [2] - https://issues.jboss.org/browse/KEYCLOAK-3060 [3] - https://github.com/abstractj/keycloak/blob/af30b4da101fd7f7775e74b93c6da2f611d364ae/server-spi/src/main/java/org/keycloak/models/UserModel.java#L61-L64 -- abstractj PGP: 0x84DC9914 From bburke at redhat.com Thu Aug 11 16:04:55 2016 From: bburke at redhat.com (Bill Burke) Date: Thu, 11 Aug 2016 16:04:55 -0400 Subject: [keycloak-dev] Readonly UserModel In-Reply-To: <20160811191202.GA9716@abstractj.org> References: <20160811191202.GA9716@abstractj.org> Message-ID: <05657bad-dad1-b7a8-4993-3c057198e7b8@redhat.com> IMO, you don't need to put a lot of work into this as UserFederation SPI is going to be deprecated. Here's an example of new UserStorageProvider SPI. Its very similar. https://github.com/keycloak/keycloak/tree/master/examples/providers/user-storage-jpa There will be no more importing of users. If you think about it, what we had before was a persistent cache, which IMO, doesn't make much sense. The biggest reason for imports was it made querying easier, but I think I've got a solution for that implemented, albeit an inefficient one for large role sets. What I think we will need is a common exception i.e. ModelReadOnly or something and have it handled gracefully in the admin console and rest API. On 8/11/16 3:12 PM, Bruno Oliveira wrote: > Ahoy, after exploring some ideas I implemented the initial draft[1] for KEYCLOAK-3060[2]. Before submitting any changes, I would like some feedback. > > - Motivation > > Disable input fields when read-only federation providers like SSSD or LDAP (read-only mode) are enabled. > > Another alternative would be just hide sections which people are not supposed to edit. For example: account, OTP and password section. > > To be honest, I'm 50/50 about it, because hiding sections could be confusing to users. > > - Pros > > * Users won't get frustrated trying to update their profile, to later find out that's not possible. > * Input fields will truly represent what our user is, into other words, read-only > > - Cons > > * UserModel from my perspective is the only possible place to introduce this change[3] (I can be wrong). The drawback is that the change will affect all the implementing classes. > > - Options > > 1. If you are fine with the changes here[1]. I could do some clean up, write the proper integration tests and work to get it merged. > > 2. Do nothing and leave it as is. > > Thoughts? > > > [1] - https://github.com/abstractj/keycloak/tree/KEYCLOAK-3060 > [2] - https://issues.jboss.org/browse/KEYCLOAK-3060 > [3] - https://github.com/abstractj/keycloak/blob/af30b4da101fd7f7775e74b93c6da2f611d364ae/server-spi/src/main/java/org/keycloak/models/UserModel.java#L61-L64 > > -- > > abstractj > PGP: 0x84DC9914 > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev From bruno at abstractj.org Thu Aug 11 16:33:13 2016 From: bruno at abstractj.org (Bruno Oliveira) Date: Thu, 11 Aug 2016 17:33:13 -0300 Subject: [keycloak-dev] Readonly UserModel In-Reply-To: <05657bad-dad1-b7a8-4993-3c057198e7b8@redhat.com> References: <20160811191202.GA9716@abstractj.org> <05657bad-dad1-b7a8-4993-3c057198e7b8@redhat.com> Message-ID: <20160811203313.GC9716@abstractj.org> On 2016-08-11, Bill Burke wrote: > IMO, you don't need to put a lot of work into this as UserFederation SPI > is going to be deprecated. Thanks Bill, will replace it at SSSD federation provider. > > Here's an example of new UserStorageProvider SPI. Its very similar. > > https://github.com/keycloak/keycloak/tree/master/examples/providers/user-storage-jpa > > There will be no more importing of users. If you think about it, what > we had before was a persistent cache, which IMO, doesn't make much > sense. The biggest reason for imports was it made querying easier, but > I think I've got a solution for that implemented, albeit an inefficient > one for large role sets. Should we just put the idea to bed for now? > > What I think we will need is a common exception i.e. ModelReadOnly or > something and have it handled gracefully in the admin console and rest API. Maybe I'm oversimplifying and missing the big picture. But why not have a UserModel with boolean field like "editable"? Something close to what we have today for enabled/disabled users. > > > On 8/11/16 3:12 PM, Bruno Oliveira wrote: > > Ahoy, after exploring some ideas I implemented the initial draft[1] for KEYCLOAK-3060[2]. Before submitting any changes, I would like some feedback. > > > > - Motivation > > > > Disable input fields when read-only federation providers like SSSD or LDAP (read-only mode) are enabled. > > > > Another alternative would be just hide sections which people are not supposed to edit. For example: account, OTP and password section. > > > > To be honest, I'm 50/50 about it, because hiding sections could be confusing to users. > > > > - Pros > > > > * Users won't get frustrated trying to update their profile, to later find out that's not possible. > > * Input fields will truly represent what our user is, into other words, read-only > > > > - Cons > > > > * UserModel from my perspective is the only possible place to introduce this change[3] (I can be wrong). The drawback is that the change will affect all the implementing classes. > > > > - Options > > > > 1. If you are fine with the changes here[1]. I could do some clean up, write the proper integration tests and work to get it merged. > > > > 2. Do nothing and leave it as is. > > > > Thoughts? > > > > > > [1] - https://github.com/abstractj/keycloak/tree/KEYCLOAK-3060 > > [2] - https://issues.jboss.org/browse/KEYCLOAK-3060 > > [3] - https://github.com/abstractj/keycloak/blob/af30b4da101fd7f7775e74b93c6da2f611d364ae/server-spi/src/main/java/org/keycloak/models/UserModel.java#L61-L64 > > > > -- > > > > abstractj > > PGP: 0x84DC9914 > > _______________________________________________ > > 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 -- abstractj PGP: 0x84DC9914 From bburke at redhat.com Thu Aug 11 16:51:12 2016 From: bburke at redhat.com (Bill Burke) Date: Thu, 11 Aug 2016 16:51:12 -0400 Subject: [keycloak-dev] Readonly UserModel In-Reply-To: <20160811203313.GC9716@abstractj.org> References: <20160811191202.GA9716@abstractj.org> <05657bad-dad1-b7a8-4993-3c057198e7b8@redhat.com> <20160811203313.GC9716@abstractj.org> Message-ID: <01e11e6e-05dd-201c-3b5f-5ca7037f21ba@redhat.com> On 8/11/16 4:33 PM, Bruno Oliveira wrote: > On 2016-08-11, Bill Burke wrote: >> IMO, you don't need to put a lot of work into this as UserFederation SPI >> is going to be deprecated. > Thanks Bill, will replace it at SSSD federation provider. I'm currently working on revamping credential storage and validation. Hope to get to documentation right after than. If you look tat the example though, you can pick and choose which interfaces you want to implement. If you just want to make a user available for lookup for login, just implement that interface. If you want admin console support, implement another interface. >> Here's an example of new UserStorageProvider SPI. Its very similar. >> >> https://github.com/keycloak/keycloak/tree/master/examples/providers/user-storage-jpa >> >> There will be no more importing of users. If you think about it, what >> we had before was a persistent cache, which IMO, doesn't make much >> sense. The biggest reason for imports was it made querying easier, but >> I think I've got a solution for that implemented, albeit an inefficient >> one for large role sets. > Should we just put the idea to bed for now? For userFed SPI, yes...but the new stuff needs review. >> What I think we will need is a common exception i.e. ModelReadOnly or >> something and have it handled gracefully in the admin console and rest API. > Maybe I'm oversimplifying and missing the big picture. But why not have a > UserModel with boolean field like "editable"? Something close to what we > have today for enabled/disabled users. Some implementations may only be readonly for certain attributes, properties, and/or credentials. For example, LDAP might be read-only, but the provider may be storing other things within Keycloak. Bill From srossillo at smartling.com Thu Aug 11 17:13:55 2016 From: srossillo at smartling.com (Scott Rossillo) Date: Thu, 11 Aug 2016 17:13:55 -0400 Subject: [keycloak-dev] Readonly UserModel In-Reply-To: <01e11e6e-05dd-201c-3b5f-5ca7037f21ba@redhat.com> References: <20160811191202.GA9716@abstractj.org> <05657bad-dad1-b7a8-4993-3c057198e7b8@redhat.com> <20160811203313.GC9716@abstractj.org> <01e11e6e-05dd-201c-3b5f-5ca7037f21ba@redhat.com> Message-ID: <3A675D7C-4F43-402A-B2CD-88D9B7F51341@smartling.com> Bill, you?re planning to remove user federation support? Did I read that correctly? Scott Rossillo Smartling | Senior Software Engineer srossillo at smartling.com > On Aug 11, 2016, at 4:51 PM, Bill Burke wrote: > > > > On 8/11/16 4:33 PM, Bruno Oliveira wrote: >> On 2016-08-11, Bill Burke wrote: >>> IMO, you don't need to put a lot of work into this as UserFederation SPI >>> is going to be deprecated. >> Thanks Bill, will replace it at SSSD federation provider. > I'm currently working on revamping credential storage and validation. > Hope to get to documentation right after than. If you look tat the > example though, you can pick and choose which interfaces you want to > implement. If you just want to make a user available for lookup for > login, just implement that interface. If you want admin console > support, implement another interface. > >>> Here's an example of new UserStorageProvider SPI. Its very similar. >>> >>> https://github.com/keycloak/keycloak/tree/master/examples/providers/user-storage-jpa >>> >>> There will be no more importing of users. If you think about it, what >>> we had before was a persistent cache, which IMO, doesn't make much >>> sense. The biggest reason for imports was it made querying easier, but >>> I think I've got a solution for that implemented, albeit an inefficient >>> one for large role sets. >> Should we just put the idea to bed for now? > For userFed SPI, yes...but the new stuff needs review. > >>> What I think we will need is a common exception i.e. ModelReadOnly or >>> something and have it handled gracefully in the admin console and rest API. >> Maybe I'm oversimplifying and missing the big picture. But why not have a >> UserModel with boolean field like "editable"? Something close to what we >> have today for enabled/disabled users. > > Some implementations may only be readonly for certain attributes, > properties, and/or credentials. For example, LDAP might be read-only, > but the provider may be storing other things within Keycloak. > > Bill > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160811/6a920144/attachment-0001.html From petervn1 at yahoo.com Fri Aug 12 01:08:11 2016 From: petervn1 at yahoo.com (Peter Nalyvayko) Date: Fri, 12 Aug 2016 05:08:11 +0000 (UTC) Subject: [keycloak-dev] Claims from UserInfo endpoint are not getting mapped by OIDC identity broker References: <1634791415.985171.1470978491849.ref@mail.yahoo.com> Message-ID: <1634791415.985171.1470978491849@mail.yahoo.com> Hello,It seems that there is no way to map the claims returned by the /userinfo endpoint to user attributes.?I set up an OIDC identity broker to enable external identity broker authentication in keycloak. Some of the?relevant information about the user, such as language, locale, etc. are available only by calling the /userinfo point,?so I wanted to map the claims returned by the endpoint to the user attributes using the available mappers.Unfortunately, it seems that the Attribute Mapper can maps ID token or?Access token claims (User Attribute Mapper), and completely ignores the userInfo claims.?Searching through the codebase, I've found that OIDC identity broker calls?AbstractJsonUserAttributeMapper.storeUserProfileForMapper to store the user profilereturned by the call to /userinfo endpoint in the user's context data. However, there seems to be no way?(without modifying the code that is) to map that data to the attributes of the?federated user created by the OIDC identity broker. Am I missing something here or this functionality is not available out of the box for OIDC identity broker? I am using keycloak version 2.1.0? Thank you,--Peter -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160812/5408cad6/attachment.html From martin.hardselius at gmail.com Fri Aug 12 03:57:52 2016 From: martin.hardselius at gmail.com (Martin Hardselius) Date: Fri, 12 Aug 2016 07:57:52 +0000 Subject: [keycloak-dev] Pairwise Subject Identifier In-Reply-To: <57AC9686.5040807@redhat.com> References: <57AC9686.5040807@redhat.com> Message-ID: Thank you for your response. Did not see that ticket before. Great news! I looked into using protocol mappers to achieve this, and while it would work I'm worried that once KEYCLOAK-3422 has been resolved and included in a proper release we would run into migration issues if the method used for calculating "native" pairwise subs is different from what we implement. Clients could loose / be forced to re-register all their users if we decide to switch. The example methods in the spec are just that. Examples. Maybe the method/alg for computing the pairwise sub should be pluggable? -- Martin On Thu, 11 Aug 2016 at 17:15 Marek Posolda wrote: > Sorry for late response. > > We have JIRA created for that. You can possibly add yourself as a watcher. > See https://issues.jboss.org/browse/KEYCLOAK-3422 > > Maybe an alternative for you is to use protocolMappers. That should allow > you to "construct" the token for particular client exactly how you want and > also use the different value for "sub" claim. > > Another possibility is, to handle this on adapter side. We already have an > adapter option "principal-attribute", which specifies that application will > see the different attribute instead of "sub" as subject. For example when > in appllication you call "httpServletRequest.getRemoteUser()" it will > return "john" instead of "123456-unique-johns-uuid" . See > https://keycloak.gitbooks.io/securing-client-applications-guide/content/v/2.1/topics/oidc/java/java-adapter-config.html > > Hopefully some of the options can be useful for you? > > Marek > > > On 02/08/16 14:13, Martin Hardselius wrote: > > Me and my team are working towards getting Keycloak, customized for our > needs, into production but we've identified the need for Pairwise Subject > Identifiers as we don't want to expose internal user ids. > > Right now, the only subject_types_supported seems to be "public". Are > there any near-future plans to include "pairwise"? Can we pitch in with a > PR to make this happen as soon as possible? > > Links to relevant sections in the spec: > > http://openid.net/specs/openid-connect-core-1_0.html#SubjectIDTypes > http://openid.net/specs/openid-connect-core-1_0.html#PairwiseAlg > > -- > Martin > > > _______________________________________________ > keycloak-dev mailing listkeycloak-dev at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-dev > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160812/2b4bb77c/attachment.html From thomas.darimont at googlemail.com Fri Aug 12 04:22:50 2016 From: thomas.darimont at googlemail.com (Thomas Darimont) Date: Fri, 12 Aug 2016 10:22:50 +0200 Subject: [keycloak-dev] FYI OAuth Security Workshop 2016 July 14th and 15th 2016 in Trier / Germany In-Reply-To: References: Message-ID: Hello group, just a quick follow-up from the IETF OAuth Security workshop from last July. The workshop was well attended: security researches and some big names like google, microsoft, facebook, deutsche telekom, ping identity, openid.net were all represented etc. There were some interesting talks about using OAuth in IoT scenarios and how the related standards (cbor, cwt, etc.) can be applied. Another interesting topic was the theory and practice of the recently found IdP Mix-Up attack. Links to the talks (slides / papers) are here [0] (unfortunately they were not recorded). There were also some tools mentioned for checking Identity Providers for well known attacks (PrOfESSOS) [0] as well as OIDC compliance tests (oictest) [2] that can be run locally, it's an easy to setup python app that also runs behind the official conformance testing portal of the openid.net [3] - running it locally might make things easier to test ;-) Btw. I pitched keycloak quite often - folks were really keen to look at it ;-) Cheers, Thomas [0] https://infsec.uni-trier.de/events/osw2016/schedule [1] https://github.com/RUB-NDS/PrOfESSOS [2] https://github.com/rohe/oictest [3] https://openid.net/certification/testing/ 2016-06-22 7:56 GMT+02:00 Stian Thorgersen : > Hi, thanks for letting us now. A summary to the list afterwards would be > appreciated, especially any advice on improving security. > > On 21 June 2016 at 11:04, Thomas Darimont > wrote: > >> Hello group, >> >> just wanted to let you know that there will be an OAuth Security Workshop >> at the >> University of Trier (Germany) in July see: https://infsec.uni-trier.de/ >> events/osw2016 >> >> I learned from one of the organizers that they will also discuss Keycloak >> as >> an OpenID Connect Provider - just wanted to let you guys know. >> >> I'm going to attend this workshop as well. >> >> Cheers, >> Thomas >> >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160812/aa20c831/attachment.html From bburke at redhat.com Fri Aug 12 08:40:39 2016 From: bburke at redhat.com (Bill Burke) Date: Fri, 12 Aug 2016 08:40:39 -0400 Subject: [keycloak-dev] Readonly UserModel In-Reply-To: <3A675D7C-4F43-402A-B2CD-88D9B7F51341@smartling.com> References: <20160811191202.GA9716@abstractj.org> <05657bad-dad1-b7a8-4993-3c057198e7b8@redhat.com> <20160811203313.GC9716@abstractj.org> <01e11e6e-05dd-201c-3b5f-5ca7037f21ba@redhat.com> <3A675D7C-4F43-402A-B2CD-88D9B7F51341@smartling.com> Message-ID: Deprecating and leaving for awhile, not sure how long. Product relies on LDAP plugin so we might have to keep the SPI, just not document or support it. It will be refactored here and there though to streamline the model api. New SPI already exists in parallel with old fed spi in 2.1.0 and in master. On 8/11/16 5:13 PM, Scott Rossillo wrote: > Bill, you?re planning to remove user federation support? Did I read > that correctly? > > Scott Rossillo > Smartling | Senior Software Engineer > srossillo at smartling.com > >> On Aug 11, 2016, at 4:51 PM, Bill Burke > > wrote: >> >> >> >> On 8/11/16 4:33 PM, Bruno Oliveira wrote: >>> On 2016-08-11, Bill Burke wrote: >>>> IMO, you don't need to put a lot of work into this as >>>> UserFederation SPI >>>> is going to be deprecated. >>> Thanks Bill, will replace it at SSSD federation provider. >> I'm currently working on revamping credential storage and validation. >> Hope to get to documentation right after than. If you look tat the >> example though, you can pick and choose which interfaces you want to >> implement. If you just want to make a user available for lookup for >> login, just implement that interface. If you want admin console >> support, implement another interface. >> >>>> Here's an example of new UserStorageProvider SPI. Its very similar. >>>> >>>> https://github.com/keycloak/keycloak/tree/master/examples/providers/user-storage-jpa >>>> >>>> There will be no more importing of users. If you think about it, what >>>> we had before was a persistent cache, which IMO, doesn't make much >>>> sense. The biggest reason for imports was it made querying easier, but >>>> I think I've got a solution for that implemented, albeit an inefficient >>>> one for large role sets. >>> Should we just put the idea to bed for now? >> For userFed SPI, yes...but the new stuff needs review. >> >>>> What I think we will need is a common exception i.e. ModelReadOnly or >>>> something and have it handled gracefully in the admin console and >>>> rest API. >>> Maybe I'm oversimplifying and missing the big picture. But why not >>> have a >>> UserModel with boolean field like "editable"? Something close to what we >>> have today for enabled/disabled users. >> >> Some implementations may only be readonly for certain attributes, >> properties, and/or credentials. For example, LDAP might be read-only, >> but the provider may be storing other things within Keycloak. >> >> Bill >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160812/85901af7/attachment-0001.html From bruno at abstractj.org Fri Aug 12 08:51:24 2016 From: bruno at abstractj.org (Bruno Oliveira) Date: Fri, 12 Aug 2016 09:51:24 -0300 Subject: [keycloak-dev] Readonly UserModel In-Reply-To: <01e11e6e-05dd-201c-3b5f-5ca7037f21ba@redhat.com> References: <20160811191202.GA9716@abstractj.org> <05657bad-dad1-b7a8-4993-3c057198e7b8@redhat.com> <20160811203313.GC9716@abstractj.org> <01e11e6e-05dd-201c-3b5f-5ca7037f21ba@redhat.com> Message-ID: <20160812125124.GA29282@abstractj.org> Thanks for clarifying Bill. On 2016-08-11, Bill Burke wrote: > > > On 8/11/16 4:33 PM, Bruno Oliveira wrote: > > On 2016-08-11, Bill Burke wrote: > > > IMO, you don't need to put a lot of work into this as UserFederation SPI > > > is going to be deprecated. > > Thanks Bill, will replace it at SSSD federation provider. > I'm currently working on revamping credential storage and validation. Hope > to get to documentation right after than. If you look tat the example > though, you can pick and choose which interfaces you want to implement. If > you just want to make a user available for lookup for login, just implement > that interface. If you want admin console support, implement another > interface. > > > > Here's an example of new UserStorageProvider SPI. Its very similar. > > > > > > https://github.com/keycloak/keycloak/tree/master/examples/providers/user-storage-jpa > > > > > > There will be no more importing of users. If you think about it, what > > > we had before was a persistent cache, which IMO, doesn't make much > > > sense. The biggest reason for imports was it made querying easier, but > > > I think I've got a solution for that implemented, albeit an inefficient > > > one for large role sets. > > Should we just put the idea to bed for now? > For userFed SPI, yes...but the new stuff needs review. > > > > What I think we will need is a common exception i.e. ModelReadOnly or > > > something and have it handled gracefully in the admin console and rest API. > > Maybe I'm oversimplifying and missing the big picture. But why not have a > > UserModel with boolean field like "editable"? Something close to what we > > have today for enabled/disabled users. > > Some implementations may only be readonly for certain attributes, > properties, and/or credentials. For example, LDAP might be read-only, but > the provider may be storing other things within Keycloak. > > Bill -- abstractj PGP: 0x84DC9914 From josh.cain at redhat.com Fri Aug 12 09:31:25 2016 From: josh.cain at redhat.com (Josh Cain) Date: Fri, 12 Aug 2016 08:31:25 -0500 Subject: [keycloak-dev] Docker Protocol? Message-ID: Hi All, We want to use Keycloak as the IDP/Token issuer for authentication with a docker registry as per the specification found here: https://docs.docker.com/registry/spec/auth/ I've implemented a Protocol Mapper in Keycloak that successfully uses the IDP to perform a login against a registry/docker client. Is this something that the team is interested in building into the product? If so, I'd be happy to push back upstream. Josh Cain | Software Applications Engineer *Identity and Access Management* *Red Hat* +1 843-737-1735 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160812/d00ba879/attachment.html From bburke at redhat.com Fri Aug 12 10:19:52 2016 From: bburke at redhat.com (Bill Burke) Date: Fri, 12 Aug 2016 10:19:52 -0400 Subject: [keycloak-dev] Docker Protocol? In-Reply-To: References: Message-ID: I would say yes so long as its documented. Ask Stian when he gets back though. On 8/12/16 9:31 AM, Josh Cain wrote: > Hi All, > > We want to use Keycloak as the IDP/Token issuer for authentication > with a docker registry as per the specification found here: > > https://docs.docker.com/registry/spec/auth/ > > I've implemented a Protocol Mapper in Keycloak that successfully uses > the IDP to perform a login against a registry/docker client. Is this > something that the team is interested in building into the product? > If so, I'd be happy to push back upstream. > > Josh Cain | Software Applications Engineer > /Identity and Access Management/ > *Red Hat* > +1 843-737-1735 > > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160812/9a7697bb/attachment.html From mitya at cargosoft.ru Sat Aug 13 10:47:16 2016 From: mitya at cargosoft.ru (Dmitry Telegin) Date: Sat, 13 Aug 2016 17:47:16 +0300 Subject: [keycloak-dev] Preferred storage mechanism for custom settings In-Reply-To: References: <1468323778.4229.4.camel@cargosoft.ru> <1468607337.4292.5.camel@cargosoft.ru> <1468874146.6797.11.camel@cargosoft.ru> Message-ID: <1471099636.5196.11.camel@cargosoft.ru> Hi, (As Stian is on vacation now, I'd appreciate if someone other helps me with this feature.) Please take a look?https://github.com/keycloak/keycloak/compare/2.1.0.F inal...cargosoft:KEYCLOAK-3327 (it has been branched off 2.1.0.Final for the ease of testing, I'll rebase it onto master if needed) o.k.models.RealmModel: added methods (borrowed signatures from jpa.RealmAdapter) o.k.models.jpa.RealmAdapter: added @Override annotations o.k.models.mongo.keycloak.adapters.RealmAdapter: added stubs (throwing? UnsupportedOperationException) o.k.models.cache.infinispan.RealmAdapter: added attributes caching logic o.k.models.cache.infinispan.entities.CachedRealm: added attributes cache (as Map) As for tests, I'm afraid I'll need some guidance. org.keycloak.testsuite.model.ModelTest seems appropriate for that; but it will need support for attributes in RealmRepresentation and RealmManager. Is this the right direction? Dmitry > > > > On 18 July 2016 at 22:35, Dmitry Telegin wrote: > > Stian, > > Here we go:?https://issues.jboss.org/browse/KEYCLOAK-3327 > > > > > > If the fix is somewhat trivial (i.e. a matter of adding fields and getters/setters) I think I could work on a PR as well. > > > > > > > As the attributes are already available in the underlying entities it's just a matter of exposing through RealmModel and add tests for it. > ? > > > > > > BTW, does this mean that all the custom entities provided via Entity SPI are not by default cache-enabled (and won't be synchronized between the nodes in clustered environment)? > > > > > > If so, will it be easy to cache-enable them? Is this just a matter of providing Infinispan adapters similar to existing ones for Realm/User/Role/Client etc.? > > > > > > > > > There's no caching for custom entities. I'd recommend using Hibernate 2nd level cache for it as it's rather tricky to create a custom one. We have our custom one because we need to support Mongo as well as users from different sources (user federation and identity brokering). > ? > > > > > > > > > > > > Ideally, I'd like to see a current domain-extension example augmented with Infinispan cache functionality. I've got some ideas on a detailed walkthrough tutorial for building complete, full- featured KeyCloak extensions (it's a big topic I'll elaborate on a bit later); I think Infinispan-enabled entities could be covered there, too. > > > > > > > No chance we're adding cache for custom entities. It's just to hard to get right. For custom entities you should use Hibernate 2nd level cache. > ? > > Regards, > > Dmitry > > > > ? ??, 18/07/2016 ? 07:39 +0200, Stian Thorgersen ?????: > > > > > > > > > > > > Forgot that attributes are not exposed through RealmModel. You can't access the JPA RealmAdapter directly as you'll break the cache functionality. You can create a JIRA to request attributes added to RealmModel though. > > > > > > On 15 July 2016 at 20:28, Mitya wrote: > > > > Stian, > > > > > > > > > > > > > > > > > > > > In my provider, session.getContext().getRealm() returns an instance of?org.keycloak.models.cache.infinispan.RealmAdapter. But in order to be able to manage attributes, we need an org.keycloak.models.jpa.RealmAdapter. What's the best way to obtain it? > > > > > > > > I've yet come up with the following: > > > > > > > > RealmModel realm = session.getContext().getRealm(); > > > > > > > > > > > > RealmAdapter adapter = (RealmAdapter) session.getProvider(RealmProvider.class).getRealm(realm.getId() ); > > > > > > > > > > > > > Realm attributes should be perfect for that > > > > > > > > > > On 12 July 2016 at 13:42, Mitya wrote: > > > > > > Hi, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I'm developing a KeyCloak extension, and I want some custom (per-realm) parameters to be tuned via the GUI form. Speaking of the storage mechanism for my settings, are realm attributes suitable for that? or should I create a dedicated custom entity instead? > > > > > > > > > > > > Thx, > > > > > > Mitya > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > > > > keycloak-dev mailing list > > > > > > > > > > > > keycloak-dev at lists.jboss.org > > > > > > > > > > > > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160813/3306a3f9/attachment.html From petervn1 at yahoo.com Sat Aug 13 17:35:32 2016 From: petervn1 at yahoo.com (Peter Nalyvayko) Date: Sat, 13 Aug 2016 21:35:32 +0000 (UTC) Subject: [keycloak-dev] Handling X509 client certificates in integration test suite References: <910750890.1831645.1471124132997.ref@mail.yahoo.com> Message-ID: <910750890.1831645.1471124132997@mail.yahoo.com> Hello, Can anyone suggest a way to set up the integration test suite to test mutual SSL? I'd like to configure the embedded keycloak server to request a client certificate, and be able to either automatically select a certificate or programmatically configure the outgoing HTTPS connection with one. Is this something that can be done using the selenium web browser automation?Regards,Peetr -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160813/c9e40694/attachment-0001.html From sthorger at redhat.com Mon Aug 15 06:28:43 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Mon, 15 Aug 2016 12:28:43 +0200 Subject: [keycloak-dev] Read-only attributes for UserFederation providers In-Reply-To: <57925089.7050606@redhat.com> References: <20160722095124.GB27222@abstractj.org> <57925089.7050606@redhat.com> Message-ID: +1 On 22 July 2016 at 18:57, Marek Posolda wrote: > +1 > > Marek > > On 22/07/16 11:51, Bruno Oliveira wrote: > > Good morning, > > > > I was working on this issue[1] this week and thinking about how > > to tell our interface that the federation provider has read-only > > attributes. > > > > For example, today for the LDAPFederationProvider[2], we > > provide server side validations telling our user that they cannot edit > > those attributes. But still, input fields are editable and user > > will only know after hit the submit button. > > > > Not sure if makes sense, but very maybe if we provide a method > > at UserFederation like: > > > > boolean isReadOnly(); //defaults to false or override it and return true > > > > And later expose it to the interface, we could bring the > > text field properties set to read-only. > > > > Does it make any sense? > > > > > > [1] - https://issues.jboss.org/browse/KEYCLOAK-3060 > > [2] - https://github.com/keycloak/keycloak/blob/ > c7a8742a368bd8d76301145b08bb1e4af1b010e9/federation/ldap/ > src/main/java/org/keycloak/federation/ldap/ReadonlyLDAPUserModelDelegate. > java#L38-L64 > > > > -- > > > > abstractj > > PGP: 0x84DC9914 > > _______________________________________________ > > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160815/318ad8eb/attachment.html From sthorger at redhat.com Mon Aug 15 06:32:19 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Mon, 15 Aug 2016 12:32:19 +0200 Subject: [keycloak-dev] changes to KeycloakTransaction and KeycloakTransactionManager API In-Reply-To: <304a9314-cee9-0c20-8cf2-c0016c63e2ba@redhat.com> References: <304a9314-cee9-0c20-8cf2-c0016c63e2ba@redhat.com> Message-ID: I don't have a big problem with it, but I don't see the need to do it. Is it not just a convenience thing to be able to get it directly from the transaction object rather than having to get the separate transaction manager object? On 25 July 2016 at 16:59, Bill Burke wrote: > I want to simplify KeycloakTransaction interface a bit and remove the > getRolbackOnly, setRollbackOnly, and isActive and only have them within > KeycloakTransationManager. I may have to refactor existing components > to handle this. See any issues? All this is the continuous process of > simplying our SPIs to make them easier to implement. > > Bill > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160815/056c85fc/attachment.html From sthorger at redhat.com Mon Aug 15 06:34:07 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Mon, 15 Aug 2016 12:34:07 +0200 Subject: [keycloak-dev] renaming transaction interfaces In-Reply-To: References: Message-ID: KeycloakTransactionSynchronization sounds confusing to me. The renaming of KeycloakTransactionManager as well. Can you elaborate a bit on the reasoning behind this? On 25 July 2016 at 17:29, Bill Burke wrote: > I am also renaming KeycloakTransaction to > KeycloakTransactionSynchronization and KeycloakTransactionManager to > KeycloakTransaction. > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160815/034eea8a/attachment.html From sthorger at redhat.com Mon Aug 15 06:38:00 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Mon, 15 Aug 2016 12:38:00 +0200 Subject: [keycloak-dev] PAM Conversations - Custom login form In-Reply-To: <20160725213319.GA21003@abstractj.org> References: <20160718224830.GA4459@abstractj.org> <20160719090035.GB4459@abstractj.org> <20160720140607.GA24947@abstractj.org> <20160725213319.GA21003@abstractj.org> Message-ID: I've always hated having password+otp in a single field when login to internal SSO. We can do it that way for the FreeIPA integration, but the users wouldn't know what to do if a realm allows both regular KC users and users from as FreeIPA instance. Nor does it work well for installations where otp is not mandatory. On 25 July 2016 at 23:33, Bruno Oliveira wrote: > Hi Bill, > > After giving these ideas a try, I started to think about the FreeIPA > flow and how 2FA validation works. If we provide for the first factor > username + password or username + (password and OTP - in the same field), > credentials will be validated anyways. I was misguided by the second prompt > from sudo, thinking that second factor was mandatory (sorry about that). > > The same happens for the FreeIPA web interface, we just provide username + > password and OTP (if it was configured). > > That said, I believe we don't have to add any extra code, aside of what > we already have for the SSSD Federation provider. I've already > tested it with and without OTP. The only downside of this approach is > the fact that we're not going to have an OTP screen and it has to be > documented in some place. > > Does anyone have objections about leaving the flow as is? > > On 2016-07-20, Bill Burke wrote: > > Just create a different form and new Authenticator. I don't think we > want > > all this logic with Freemarker, do we? The UI is decoupled from > credential > > validation on purpose so that you can move things around, i.e. a Username > > screen, then the next screen is password/OTP input. > > > > Another thing you could do is collect credentials and store them in the > > ClientSessionModel, then once you've collected the credentials, validate > > them all in one go. > > > > On 7/20/16 10:06 AM, Bruno Oliveira wrote: > > > On 2016-07-19, Stian Thorgersen wrote: > > > > Adding Bill.. > > > > > > > > It would probably still be better to use user federation for > verifying > > > > credentials, but we would need some logic on how to determine what > > > > mechanism to use for primary authentication and secondary > authentication. > > > > Bill was talking about adding some conditional flows to the > authentication > > > > maybe that's what we need. > > > > > > > > For now I'd focus on OTP though and then move on to smartcard > afterwards. > > > I can give it a try and workaround, but I'm not sure if worth the > > > effort, assuming that later will be necessary to revisit. > > > > > > If we hardcode/workaround it on Keycloak, user's coming from FreeIPA > > > may have their login denied. Even if we ignore smartcards for now. Why? > > > > > > Depending on the auth types SSSD will show different login prompts. For > > > example: > > > > > > * Password > > > Login prompt - $ Password: > > > > > > * OTP > > > Login prompt -> $ First factor: > > > $ Second factor: > > > Note: Please notice that they are not validated separately > > > > > > * Password + OTP -> $ First factor or password: > > > > > > That's the reason why I would like to make the our login screen > > > dynamic. > > > > > > > On 19 July 2016 at 11:00, Bruno Oliveira > wrote: > > > > > > > > > The problem here is the fact that not necessarily the > > > > > first factor will be a pasword or the second factor an OTP. It > > > > > could be a smartcard for example. That's why I think is a better > idea to > > > > > make it dynamic, because we don't have control over it to tell > > > > > if the second factor will be a smartcard or an OTP for example. > > > > > > > > > > Does it make sense? > > > > > > > > > > On 2016-07-19, Stian Thorgersen wrote: > > > > > > Looks like it's better to keep as is and have user federation > provider > > > > > > validate otp credentials as well. The current OTP authenticator > delegates > > > > > > to user federation provider, so you'd end up with a separate OTP > > > > > > authenticator to do it with PAM. > > > > > > > > > > > > On 19 July 2016 at 00:48, Bruno Oliveira > wrote: > > > > > > > > > > > > > Good morning, > > > > > > > > > > > > > > > > > > > > > Today to authentication against PAM with just simple > username/password > > > > > I > > > > > > > implemented UserFederationProvider and added the proper PAM > login to > > > > > > > validCredentials[1]. This covers the most basic scenario. > > > > > > > > > > > > > > Now I would like to cover a more complex scenario like OTP and > change > > > > > > > the flow a little bit like this: > > > > > > > > > > > > > > 1. User providers her username > > > > > > > 2. The next screen asks to provide how many factor our user > has(For > > > > > > > example: OTP, password). We just don't know, PAM will tell > what's next. > > > > > > > 3. We authenticate against it > > > > > > > > > > > > > > To see in practice against FreeIPA server, I just recorded it > > > > > > > for a practical example[2]. > > > > > > > > > > > > > > What would be the best approach to implement this flow? I was > > > > > considering > > > > > > > to > > > > > > > move my authentication logic out of SSSD federation provider > and > > > > > create a > > > > > > > PAM > > > > > > > authenticator. > > > > > > > > > > > > > > Does it make sense? > > > > > > > > > > > > > > [1] - > > > > > > > > > > > > http://www.keycloak.org/docs/javadocs/org/keycloak/models/ > UserFederationProvider.html#validCredentials-org.keycloak. > models.RealmModel-org.keycloak.models.UserCredentialModel- > > > > > > > [2] - https://asciinema.org/a/atwnfbu0kqfasjl65weyoiz7a > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > > > > > > abstractj > > > > > > > PGP: 0x84DC9914 > > > > > > > _______________________________________________ > > > > > > > keycloak-dev mailing list > > > > > > > keycloak-dev at lists.jboss.org > > > > > > > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > > > > > > > > > > -- > > > > > > > > > > abstractj > > > > > PGP: 0x84DC9914 > > > > > > > > -- > > > > > > abstractj > > > PGP: 0x84DC9914 > > > > -- > > abstractj > PGP: 0x84DC9914 > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160815/1d8f689b/attachment-0001.html From sthorger at redhat.com Mon Aug 15 06:38:48 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Mon, 15 Aug 2016 12:38:48 +0200 Subject: [keycloak-dev] clientRole property to Role representation In-Reply-To: <2091993831.19410065.1469492570137.JavaMail.zimbra@redhat.com> References: <473554518.19409988.1469492465951.JavaMail.zimbra@redhat.com> <2091993831.19410065.1469492570137.JavaMail.zimbra@redhat.com> Message-ID: Why is it needed? I think it's inferred by the way the roles are returned any ways so seems like duplicated details. On 26 July 2016 at 02:22, Pedro Igor Silva wrote: > Hi, > > Do you see any problem if we add a "clientRole" property to > RoleRepresentation ? > > Regards. > Pedro Igor > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160815/c21debd0/attachment.html From sthorger at redhat.com Mon Aug 15 06:39:32 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Mon, 15 Aug 2016 12:39:32 +0200 Subject: [keycloak-dev] How to set default value of a boolean ProviderConfigProperty to true In-Reply-To: References: <20160719091331.GC4459@abstractj.org> Message-ID: Please create a JIRA and we'll look into it. On 22 July 2016 at 02:03, Rashmi Singh wrote: > Please confirm that this is a bug. If yes, can we have this fixed? We > really wanted this feature in our project ASAP. Please let me know what can > be done about this. > > On Thu, Jul 21, 2016 at 7:18 AM, Stian Thorgersen > wrote: > >> Looks like a bug then - Bill any comments? >> >> On 20 July 2016 at 09:12, Rashmi Singh wrote: >> >>> For now, I want the default value to show up in the admin console only >>> when looking at the config of the authenticator. The issue is that the >>> default value I am setting for the properties in authenticatorFactory are >>> not showing up on the admin console when you look at the authenticator -> >>> config. I see the properties displayed there but they dont show the default >>> values I set in the factory class. For booleans, it always show false and >>> for string types, always blank and not what I set. I am not looking for the >>> default values in AuthenticationFlowContext.getAuthenticatorConfig. I >>> am looking for it in the admin console only. I expected this to work but it >>> doesn't. Is it a bug? >>> >>> On Wed, Jul 20, 2016 at 1:04 AM, Stian Thorgersen >>> wrote: >>> >>>> It looks like the default value is only used in the admin console to >>>> show a default value for the option when configuring the authenticator. The >>>> default values are not added to AuthenticationFlowContext.getAuthenticatorConfig >>>> unless the authenticator is first configured through the admin console. It >>>> would be better if it was though so default values would always be >>>> available. Feel free to create an enhancement JIRA issue for it. >>>> >>>> On 19 July 2016 at 16:23, Rashmi Singh wrote: >>>> >>>>> Infact, not only Boolean, it does not seem to work for even properties >>>>> that are STRING_TYPE. I was using 1.9.4 version earlier but now I tried >>>>> with the latest 2.0.0 version too and it does not work on either. What is >>>>> the issue? >>>>> >>>>> On Tue, Jul 19, 2016 at 7:00 AM, Rashmi Singh >>>>> wrote: >>>>> >>>>>> Bruno, I had tried "true" also but that did not work either. Forgot >>>>>> to mention in my original post. I am not sure why true or "true" doesn't >>>>>> work if that's expected. Is there a bug? Does anyone have a clue on this? >>>>>> >>>>>> On Tue, Jul 19, 2016 at 4:13 AM, Bruno Oliveira >>>>>> wrote: >>>>>> >>>>>>> Hi Rashmi, try "true" instead of true. Take a look at this: >>>>>>> https://github.com/keycloak/keycloak/blob/ >>>>>>> f6a718f10a3a3a07a6222bea7d8b58e13712479c/testsuite/ >>>>>>> integration-arquillian/servers/auth-server/services/ >>>>>>> testsuite-providers/src/main/java/org/keycloak/testsuite/federation/ >>>>>>> DummyConfigurableUserFederationProviderFactory.java#L53-L58 >>>>>>> >>>>>>> In theory, should work. >>>>>>> >>>>>>> On 2016-07-18, Rashmi Singh wrote: >>>>>>> > In my AuthenticatorFactory class, I have the following >>>>>>> configuration added: >>>>>>> > >>>>>>> > ProviderConfigProperty property; >>>>>>> > property= new ProviderConfigProperty(); >>>>>>> > property.setName("propname"); >>>>>>> > property.setLabel("Property Name"); >>>>>>> > property.setDefaultValue(true); >>>>>>> > property.setType(ProviderConfigProperty.BOOLEAN_TYPE); >>>>>>> > configProperties.add(identityFirstproperty); >>>>>>> > >>>>>>> > I wanted to keep a default value as true and at first it seemed >>>>>>> like the >>>>>>> > following line would do it: >>>>>>> > >>>>>>> > property.setDefaultValue(true); >>>>>>> > >>>>>>> > But that does not seem to work. The default is still false. How >>>>>>> can I set >>>>>>> > the default to true? >>>>>>> >>>>>>> > _______________________________________________ >>>>>>> > keycloak-dev mailing list >>>>>>> > keycloak-dev at lists.jboss.org >>>>>>> > https://lists.jboss.org/mailman/listinfo/keycloak-dev >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> >>>>>>> abstractj >>>>>>> PGP: 0x84DC9914 >>>>>>> >>>>>> >>>>>> >>>>> >>>>> _______________________________________________ >>>>> keycloak-dev mailing list >>>>> keycloak-dev at lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>>>> >>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160815/90fb8a88/attachment.html From sthorger at redhat.com Mon Aug 15 06:41:17 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Mon, 15 Aug 2016 12:41:17 +0200 Subject: [keycloak-dev] Fwd: Authenticated base on roles In-Reply-To: References: Message-ID: Can you elaborate a bit on your use-case? Why would you have users that are not allowed to authenticate? On 28 July 2016 at 11:01, gambol wrote: > > Hiya > > Assuming you have a realm with x client defined and each have a APP-USER > role. Is there a way to authenticate a user only if the user have the role > associated? ... > > Obviously I can check the check the access token, or place a proxy > in-front which does that for me, but is there a native way of saying ask > for this scope and if you don't have it you are denied > > Best Regards .. > > > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160815/a2ead762/attachment.html From sthorger at redhat.com Mon Aug 15 06:48:12 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Mon, 15 Aug 2016 12:48:12 +0200 Subject: [keycloak-dev] travis seems to be down In-Reply-To: <2135599354.20603917.1469718695315.JavaMail.zimbra@redhat.com> References: <20160727210147.GA3027@abstractj.org> <2011162883.20344066.1469654209191.JavaMail.zimbra@redhat.com> <20160727213744.GA442@abstractj.org> <734242238.20355899.1469660571274.JavaMail.zimbra@redhat.com> <59c046c4-9409-1f13-c63a-6d6744bdd402@redhat.com> <427646040.20364950.1469665193602.JavaMail.zimbra@redhat.com> <20160728014535.GA13976@abstractj.org> <2135599354.20603917.1469718695315.JavaMail.zimbra@redhat.com> Message-ID: My opinion is that i HATE Travis! It's slow and has a tendency to act like a stroppy toddler. Removing -q doesn't work because we then end up generating more log than Travis allows which kills the build as well. We used to have the caching enabled, but it used to result in a lot of issues. Can't quite remember the details though. Maybe we can try it again. There's also travis_wait option that could work ( https://docs.travis-ci.com/user/common-build-problems/#Build-times-out-because-no-output-was-received ). My preference would be to migrate away from Travis and use something more beefy that can run tests quicker. I'll need to figure out someone to look into it though. Any volunteers? On 28 July 2016 at 17:11, Pedro Igor Silva wrote: > Let's see what Stian thinks about it :) For me, it is also an option. > > ----- Original Message ----- > From: "Bruno Oliveira" > To: "Pedro Igor Silva" > Cc: "Bill Burke" , "keycloak-dev" < > keycloak-dev at lists.jboss.org> > Sent: Wednesday, July 27, 2016 10:45:35 PM > Subject: Re: [keycloak-dev] travis seems to be down > > Another alternative, but you might not enjoy it, is :) > > Before start building Keycloak, pre-download all the '.m2' dir with > the dependencies required. Second alternative, is to try some caching[1], > but it may > or may not work. > > [1] - https://docs.travis-ci.com/user/caching/ > > On 2016-07-27, Pedro Igor Silva wrote: > > As Bruno suggested, the problem is probably related with the build > taking too long. If you look at the first command being executed: > > > > mvn install -Pdistribution -DskipTests=true -B -V -q > > > > The -q option tells maven to run in quite mode and only show errors. > Even in my laptop, if I run the command above it takes a bit more time to > show any output (not too long, but more than usual). That may explain that > message from Travis. > > > > Maybe we should remove -q and just log everything. That could make the > builds more stable. > > > > I've forced a new build to your https://github.com/keycloak/ > keycloak/pull/3079 (without changing anything to .travis.yml). Now it is > running. > > > > ----- Original Message ----- > > From: "Bill Burke" > > To: "Pedro Igor Silva" , "Bruno Oliveira" < > bruno at abstractj.org> > > Cc: "keycloak-dev" > > Sent: Wednesday, July 27, 2016 8:53:16 PM > > Subject: Re: [keycloak-dev] travis seems to be down > > > > Wrong... :( I still get this problem. > > > > > > On 7/27/16 7:02 PM, Pedro Igor Silva wrote: > > > I think Travis decided to not mess with Bill :) > > > > > > ----- Original Message ----- > > > From: "Bruno Oliveira" > > > To: "Pedro Igor Silva" > > > Cc: "Bill Burke" , "keycloak-dev" < > keycloak-dev at lists.jboss.org> > > > Sent: Wednesday, July 27, 2016 6:37:44 PM > > > Subject: Re: [keycloak-dev] travis seems to be down > > > > > > Seems like the balance of the Force was established again. > > > > > > On 2016-07-27, Pedro Igor Silva wrote: > > >> Got that error, but now the build was successful. > > >> > > >> ----- Original Message ----- > > >> From: "Bruno Oliveira" > > >> To: "Bill Burke" > > >> Cc: "keycloak-dev" > > >> Sent: Wednesday, July 27, 2016 6:01:47 PM > > >> Subject: Re: [keycloak-dev] travis seems to be down > > >> > > >> Seems like they are fully operational[1]. I believe that this is the > > >> reason: > > >> > > >> "No output has been received in the last 10 minutes, this potentially > indicates a stalled build or something wrong with the build itself." > > >> > > >> Based on my previous experiences, it happens when the build takes too > > >> long. Not really sure if that's the root cause, but I can help > > >> investigating it. > > >> > > >> [1] - https://www.traviscistatus.com/ > > >> > > >> On 2016-07-27, Bill Burke wrote: > > >>> A lot of builds failing in initial setup > > >>> > > >>> > > >>> Bill > > >>> > > >>> _______________________________________________ > > >>> keycloak-dev mailing list > > >>> keycloak-dev at lists.jboss.org > > >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev > > >> -- > > >> > > >> abstractj > > >> PGP: 0x84DC9914 > > >> _______________________________________________ > > >> keycloak-dev mailing list > > >> keycloak-dev at lists.jboss.org > > >> https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > -- > > > > > > abstractj > > > PGP: 0x84DC9914 > > > > -- > > abstractj > PGP: 0x84DC9914 > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160815/5d88c3d3/attachment-0001.html From sthorger at redhat.com Mon Aug 15 06:51:03 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Mon, 15 Aug 2016 12:51:03 +0200 Subject: [keycloak-dev] Preferred storage mechanism for custom settings In-Reply-To: <1471099636.5196.11.camel@cargosoft.ru> References: <1468323778.4229.4.camel@cargosoft.ru> <1468607337.4292.5.camel@cargosoft.ru> <1468874146.6797.11.camel@cargosoft.ru> <1471099636.5196.11.camel@cargosoft.ru> Message-ID: Sounds like you're on the right track. You'd need to implement support for Mongo as well though as we can't accept it otherwise. With regards to tests I'd add to org.keycloak.testsuite.admin.realm.RealmTest which would also make sure attributes work correctly when added through the admin endpoints. On 13 August 2016 at 16:47, Dmitry Telegin wrote: > Hi, > > (As Stian is on vacation now, I'd appreciate if someone other helps me > with this feature.) > > Please take a look https://github.com/keycloak/keycloak/compare/2.1. > 0.Final...cargosoft:KEYCLOAK-3327 > > (it has been branched off 2.1.0.Final for the ease of testing, I'll rebase > it onto master if needed) > > o.k.models.RealmModel: added methods (borrowed signatures from > jpa.RealmAdapter) > o.k.models.jpa.RealmAdapter: added @Override annotations > o.k.models.mongo.keycloak.adapters.RealmAdapter: added stubs (throwing > UnsupportedOperationException) > o.k.models.cache.infinispan.RealmAdapter: added attributes caching logic > o.k.models.cache.infinispan.entities.CachedRealm: added attributes cache > (as Map) > > As for tests, I'm afraid I'll need some guidance. > org.keycloak.testsuite.model.ModelTest seems appropriate for that; but it > will need support for attributes in RealmRepresentation and RealmManager. > Is this the right direction? > > Dmitry > > > > On 18 July 2016 at 22:35, Dmitry Telegin wrote: > > Stian, > > Here we go: https://issues.jboss.org/browse/KEYCLOAK-3327 > > If the fix is somewhat trivial (i.e. a matter of adding fields and > getters/setters) I think I could work on a PR as well. > > > As the attributes are already available in the underlying entities it's > just a matter of exposing through RealmModel and add tests for it. > > > > BTW, does this mean that all the custom entities provided via Entity SPI > are not by default cache-enabled (and won't be synchronized between the > nodes in clustered environment)? > If so, will it be easy to cache-enable them? Is this just a matter of > providing Infinispan adapters similar to existing ones for > Realm/User/Role/Client etc.? > > > There's no caching for custom entities. I'd recommend using Hibernate 2nd > level cache for it as it's rather tricky to create a custom one. We have > our custom one because we need to support Mongo as well as users from > different sources (user federation and identity brokering). > > > > Ideally, I'd like to see a current domain-extension example augmented with > Infinispan cache functionality. I've got some ideas on a detailed > walkthrough tutorial for building complete, full-featured KeyCloak > extensions (it's a big topic I'll elaborate on a bit later); I think > Infinispan-enabled entities could be covered there, too. > > > No chance we're adding cache for custom entities. It's just to hard to get > right. For custom entities you should use Hibernate 2nd level cache. > > > > Regards, > Dmitry > > ? ??, 18/07/2016 ? 07:39 +0200, Stian Thorgersen ?????: > > Forgot that attributes are not exposed through RealmModel. You can't > access the JPA RealmAdapter directly as you'll break the cache > functionality. You can create a JIRA to request attributes added to > RealmModel though. > > On 15 July 2016 at 20:28, Mitya wrote: > > Stian, > > In my provider, session.getContext().getRealm() returns an instance > of org.keycloak.models.cache.infinispan.RealmAdapter. But in order to be > able to manage attributes, we need an org.keycloak.models.jpa.RealmAdapter. > What's the best way to obtain it? > > I've yet come up with the following: > > RealmModel realm = session.getContext().getRealm(); > RealmAdapter adapter = (RealmAdapter) session.getProvider( > RealmProvider.class).getRealm(realm.getId()); > > > Realm attributes should be perfect for that > > On 12 July 2016 at 13:42, Mitya wrote: > > Hi, > > I'm developing a KeyCloak extension, and I want some custom (per-realm) > parameters to be tuned via the GUI form. Speaking of the storage mechanism > for my settings, are realm attributes suitable for that? or should I create > a dedicated custom entity instead? > > Thx, > Mitya > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160815/3f8ee2f0/attachment.html From sthorger at redhat.com Mon Aug 15 06:52:23 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Mon, 15 Aug 2016 12:52:23 +0200 Subject: [keycloak-dev] Handling X509 client certificates in integration test suite In-Reply-To: <910750890.1831645.1471124132997@mail.yahoo.com> References: <910750890.1831645.1471124132997.ref@mail.yahoo.com> <910750890.1831645.1471124132997@mail.yahoo.com> Message-ID: We're migrating away from the old testsuite to the new Arquillian testsuite which I believe has support for running on HTTPS. Pavel can you get someone to add instructions on how to run the Arquillian testsuite with SSL? On 13 August 2016 at 23:35, Peter Nalyvayko wrote: > Hello, > > Can anyone suggest a way to set up the integration test suite to test > mutual SSL? I'd like to configure the embedded keycloak server to request a > client certificate, and be able to either automatically select a > certificate or programmatically configure the outgoing HTTPS connection > with one. Is this something that can be done using the selenium web browser > automation? > Regards, > Peetr > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160815/0b8bb89a/attachment.html From sthorger at redhat.com Mon Aug 15 06:56:23 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Mon, 15 Aug 2016 12:56:23 +0200 Subject: [keycloak-dev] Docker Protocol? In-Reply-To: References: Message-ID: I'm not sure I fully understand. Are you using a Docker client to authenticate with Keycloak? That works with the standard OIDC flows, but it requires some additional claims in the token which you are adding with a protocol mapper? On 12 August 2016 at 15:31, Josh Cain wrote: > Hi All, > > We want to use Keycloak as the IDP/Token issuer for authentication with a > docker registry as per the specification found here: > > https://docs.docker.com/registry/spec/auth/ > > I've implemented a Protocol Mapper in Keycloak that successfully uses the > IDP to perform a login against a registry/docker client. Is this something > that the team is interested in building into the product? If so, I'd be > happy to push back upstream. > > Josh Cain | Software Applications Engineer > *Identity and Access Management* > *Red Hat* > +1 843-737-1735 > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160815/ae93f13f/attachment.html From sthorger at redhat.com Mon Aug 15 07:07:11 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Mon, 15 Aug 2016 13:07:11 +0200 Subject: [keycloak-dev] Claims from UserInfo endpoint are not getting mapped by OIDC identity broker In-Reply-To: <1634791415.985171.1470978491849@mail.yahoo.com> References: <1634791415.985171.1470978491849.ref@mail.yahoo.com> <1634791415.985171.1470978491849@mail.yahoo.com> Message-ID: It should be possible to map claims from the userinfo endpoint, but attributes are only mapped on first login. We don't currently update attributes on subsequent logins. Maybe you are trying with an existing user? On 12 August 2016 at 07:08, Peter Nalyvayko wrote: > Hello, > It seems that there is no way to map the claims returned by the /userinfo > endpoint to user attributes. > I set up an OIDC identity broker to enable external identity broker > authentication in keycloak. Some of the > relevant information about the user, such as language, locale, etc. are > available only by calling the /userinfo point, > so I wanted to map the claims returned by the endpoint to the user > attributes using the available mappers. > Unfortunately, it seems that the Attribute Mapper can maps ID token or > Access token claims (User Attribute Mapper), and completely ignores the > userInfo claims. > Searching through the codebase, I've found that OIDC identity broker calls > AbstractJsonUserAttributeMapper.storeUserProfileForMapper to store the > user profile > returned by the call to /userinfo endpoint in the user's context data. > However, there seems to be no way > (without modifying the code that is) to map that data to the attributes of > the > federated user created by the OIDC identity broker. > > Am I missing something here or this functionality is not available out of > the box for OIDC identity broker? > > I am using keycloak version 2.1.0 > > Thank you, > --Peter > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160815/e4c1feda/attachment-0001.html From sthorger at redhat.com Mon Aug 15 07:11:19 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Mon, 15 Aug 2016 13:11:19 +0200 Subject: [keycloak-dev] Brute force lock out and password reset error In-Reply-To: References: <20160726113453.GC29719@abstractj.org> <20160727121655.GA22977@abstractj.org> <20160728120205.GA27219@abstractj.org> Message-ID: Bruno - I'm not following why it needs to be rate limited. The attacker would have to have access to the users email to be able to click on the reset password link to unlock the account. However, it would be better to only unlock the account once the password has been updated and not when the link is clicked. On 29 July 2016 at 10:44, Joakim L?fgren wrote: > KEYCLOAK-3371 > > On Thu, Jul 28, 2016, 14:02 Bruno Oliveira wrote: > >> Hi Joakim, >> >> What you're suggesting makes sense. I'm just trying to say that in >> order to have it implemented, we should have a rate limit for password >> resets. >> >> Anyways, please file a jira for it. >> >> On 2016-07-28, Joakim L?fgren wrote: >> > Well everything can be automated, yes. >> > >> > I'll explain in more detail. >> > >> > 1. Hacker or myself fails to login 3 times >> > 2. Brute force detection temporarily disables my account >> > 3. I enter my email in the reset password form and submit. >> > 4. An email lands in my inbox >> > 5. Account is still temporarily disabled >> > 6. I prove my identity (or at least access to the email account) and >> click >> > the reset link in the email >> > 7. Account is unlocked and I get a login session and prompted to update >> my >> > password >> > >> > This prevents someone from continuously trying to hack my account and >> thus >> > keeping me locked out of my account. >> > >> > It also provides a better experience for someone who has just forgotten >> his >> > or her password and attempts to login a few too many times. >> > >> > Just waiting for the account to unlock so the password reset works again >> > isn't more secure in my mind. Just more tedious. >> > >> > Thoughts? >> > >> > On Wed, Jul 27, 2016, 14:16 Bruno Oliveira wrote: >> > >> > > On 2016-07-27, Joakim L?fgren wrote: >> > > > Not if you have to click the link in the email for it to be >> unlocked ? >> > > >> > > You know that can be easily automated, right? >> > > >> > > > >> > > > On Tue, Jul 26, 2016, 13:34 Bruno Oliveira >> wrote: >> > > > >> > > > > On 2016-07-26, Joakim L?fgren wrote: >> > > > > > Hey, >> > > > > > >> > > > > > I noticed that if you get your account temporarily locked due >> to the >> > > > > brute >> > > > > > force detection then you cannot reset your password until the >> > > temporary >> > > > > > locked has been lifted. >> > > > > > >> > > > > > Is this behaviour intended ? >> > > > > >> > > > > From what I can tell, this is how it works today and that's >> > > intentional. >> > > > > I think that in order to enable password reset for blocked >> accounts, >> > > > > rate limiting for password reset should be introduced, otherwise, >> an >> > > > > attacker could try it again. >> > > > > >> > > > > > >> > > > > > We've gotten a few users that become confused when they do not >> > > receive a >> > > > > > reset password email, and thus contact us asking for help. >> > > > > > >> > > > > > >> > > > > > Sincerely, >> > > > > > Joakim >> > > > > >> > > > > > _______________________________________________ >> > > > > > keycloak-dev mailing list >> > > > > > keycloak-dev at lists.jboss.org >> > > > > > https://lists.jboss.org/mailman/listinfo/keycloak-dev >> > > > > >> > > > > >> > > > > -- >> > > > > >> > > > > abstractj >> > > > > PGP: 0x84DC9914 >> > > > > >> > > >> > > -- >> > > >> > > abstractj >> > > PGP: 0x84DC9914 >> > > >> >> -- >> >> abstractj >> PGP: 0x84DC9914 >> > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160815/3eb354ac/attachment.html From sthorger at redhat.com Mon Aug 15 07:30:15 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Mon, 15 Aug 2016 13:30:15 +0200 Subject: [keycloak-dev] travis maven and quiet mode -q In-Reply-To: <57A0619B.6090708@redhat.com> References: <306e2447-002a-1cde-21e5-9fc21c17fa41@redhat.com> <981975491.22236730.1470071552188.JavaMail.zimbra@redhat.com> <1195597536.22328581.1470080287173.JavaMail.zimbra@redhat.com> <1a65024b-f02f-9b40-a9c5-659ec3b8ce34@redhat.com> <57A01A7B.80602@redhat.com> <57A0619B.6090708@redhat.com> Message-ID: Enabling cache used to result in a lot of issues. Can't remember what, but we can try to re-enable and see if it works better now. -q was added due to Travis killing the build as the much log was added. Should probably be possible to fix the timeout with travis_wait, see https://docs.travis-ci.com/user/common-build-problems/#Build-times-out-because-no-output-was-received . See the other thread I just responded to though - I'd like to get away from Travis as it's slow as hell! On 2 August 2016 at 11:02, Marek Posolda wrote: > +1 from me to use this. > > Marek > > > On 02/08/16 09:53, Thomas Darimont wrote: > > Hello, > > FYI - in the Spring Data Builds we configured caching of maven resources > in travis to avoid downloading all dependencies everytime > https://github.com/spring-projects/spring-data-jpa/blob/ > master/.travis.yml#L28 > > So try adding this to .travis.yml > > cache: > directories: > - $HOME/.m2 > > Cheers, > Thomas > > 2016-08-02 5:58 GMT+02:00 Marek Posolda : > >> I've tried to find some "balance" between no log and too much log. I've >> ended with removed quiet mode, but some output filtering with "grep" to >> avoid very big log file. The command is like this: >> >> mvn install -Pdistribution -DskipTests=true -B -V | grep -e "Maven" -e >> "Java" -e "Building Keycloak" >> >> I've pushed this change. Looks like dirty workaround, but seems to work >> for now :/ It seems the proper solution will be to fix maven to avoid >> downloading stuff every build. >> >> Marek >> >> >> On 01/08/16 22:40, Bill Burke wrote: >> > i set it back >> > >> > >> > On 8/1/16 3:38 PM, Pedro Igor Silva wrote: >> >> Now Travis is complaining about the log size .... That is probably the >> reason why quite mode was set. >> >> >> >> I think we should revert -q. At least we can restart the build and get >> it working. >> >> >> >> I can try to look at that later this week and try to find a balance >> between these two issues (no log and too much log). >> >> >> >> Wdyt ? >> >> >> >> >> >> ----- Original Message ----- >> >> From: "Pedro Igor Silva" < psilva at redhat.com> >> >> To: "Bill Burke" >> >> Cc: "keycloak-dev" < >> keycloak-dev at lists.jboss.org> >> >> Sent: Monday, August 1, 2016 2:12:32 PM >> >> Subject: Re: [keycloak-dev] travis maven and quiet mode -q >> >> >> >> I think so. That is what we have discussed on another thread. We could >> remove quiet mode and see if builds get more stable. Which I think will do >> ... >> >> >> >> ----- Original Message ----- >> >> From: "Bill Burke" < bburke at redhat.com> >> >> To: "keycloak-dev" < >> keycloak-dev at lists.jboss.org> >> >> Sent: Monday, August 1, 2016 2:03:05 PM >> >> Subject: [keycloak-dev] travis maven and quiet mode -q >> >> >> >> Why are we running in quiet mode? Does the log end up too long and the >> >> build fails? >> >> >> >> _______________________________________________ >> >> 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 >> >> _______________________________________________ >> 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160815/3f5eb087/attachment.html From sthorger at redhat.com Mon Aug 15 07:39:16 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Mon, 15 Aug 2016 13:39:16 +0200 Subject: [keycloak-dev] creating JPA user storage provider difficult In-Reply-To: <57A44FFA.8080502@redhat.com> References: <57A2F627.1030406@redhat.com> <930bef50-376c-0df0-8472-eceaa22eb02c@redhat.com> <57A3499B.3080402@redhat.com> <57A44FFA.8080502@redhat.com> Message-ID: +1 To dropping provider directory as it's not very useful for real providers. Deployer would be awesome, especially if we can leverage jboss-deployment-structure.xml as an alternative to modules and Maven deploy plugin. Sounds like a lot of work though. There's also the issue around not supporting applications deployed directly to Keycloak. For a long time ago I built a server which used regular old JEE session beans as plugins. All you needed to to was to register it globally in JNDI and the server would scan for implementations of specific classes. It was a bit of a pain when it came to life cycle (beans would need to be deployed before the server, etc.). Worked quite well though ;) On 5 August 2016 at 10:36, Marek Posolda wrote: > On 04/08/16 16:03, Bill Burke wrote: > > > > > > On 8/4/16 9:56 AM, Marek Posolda wrote: > >> Yep, so we can address this with some sort of "deployer" you > >> proposed, which will have automatically access to JEE APIs, so people > >> won't need to declare dependencies on them anywhere? Still people > >> always need to deal with modules though, if they don't want just JEE, > >> but also some other different 3rd party dependencies... > > True, but at least we can make a keycloak deployer that is consistent > > with WARs, etc. Meaning, those that are experienced writing WARs in > > Wildfly and using jboss-deployment-structure.xml will not have to be > > completely retrained to write a keycloak component. > +1 > > > >> > >>>>> * Had to use JpaKeycloakTransaction to enlist EntityManager with > >>>>> keycloak transactions. This means using EJBs is out of the question. > >>>>> > >>>>> This is unacceptable. Keycloak is supposed to be simple and this is > >>>>> extremely difficult. When Keycloak was an exploded WAR you could use > >>>>> every Java EE component type as you could just plop your extensions > >>>>> within META-INF/lib. Classloading was simple as it was all the same > >>>>> classloader. > >>>>> > >>>>> Going forward we need to write an actual deployer for Keycloak > >>>>> extensions that allow you to define Keycloak providers within EE > >>>>> jars, > >>>>> ears, etc. Writing an extension to Keycloak should be as easy as > >>>>> writing a Java EE application. Extension developers should be > >>>>> able to > >>>>> leverage the entire JBoss/Wildfly platform. Minimally, we also > >>>>> need to > >>>>> begin and commit/rollback a UserTransaction within a Keycloak request > >>>>> flow so that transaction EE and Spring component layers can function. > >>>> +1 for deployer. Maybe we can try to prototype an example, which > >>>> uses stuff like EJB and then see what exactly we need to add? > >>>> > >>>> For UserTransaction, we can maybe have the KeycloakTransaction > >>>> implementation, which will delegate to UserTransaction? Then people > >>>> can optionally enlist it in their provider if they need it : > >>>> > >>>> session.getTransactionManager().enlistAfterCompletion(new > >>>> UserTransactionWrapper()); > >>>> > >>>> Then Keycloak will automatically take care of commit/rollback this > >>>> transaction at end of request. > >>> Why wouldn't they just use UserTransaction? > >> In case that KeycloakTransaction is rolled back, then it calls > >> rollback to all the enlisted delegates. So enlisted > >> UserTransactionWrapper will then call UserTransaction.rollback as well. > >> > >> Unless we're going to rewrite our transaction API to use JTA? That > >> will automatically integrate with JPA and infinispan. If people needs > >> to enlist their own transaction, they need to implement > >> javax.transaction.xa.XAResource. This looks slightly more complicated > >> then implement our KeycloakTransaction, but on the other hand, it's a > >> standard. > >> > > I think we can/should have both. We automatically begin and enlist a > > UserTransactionWrapper into the KeycloakTransactionManager at the > > beginning of a request (in our filter that starts a KeycloakSession). > > If users want something XA then they implement and integration with > > JTA. If they want something simpler, than use our KeycloakTransactions. > +1 assuming that automatically enlist UserTransaction in each request > won't have any performance (or other) impact. > > Marek > > > > Bill > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160815/50338677/attachment-0001.html From sthorger at redhat.com Mon Aug 15 07:42:21 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Mon, 15 Aug 2016 13:42:21 +0200 Subject: [keycloak-dev] JTA issues In-Reply-To: <779b7fd3-23e8-d551-acac-7c777f1362a1@redhat.com> References: <20197d32-86b3-acab-e10a-70df451cf358@redhat.com> <57A87B91.8030005@redhat.com> <779b7fd3-23e8-d551-acac-7c777f1362a1@redhat.com> Message-ID: There's a proper transaction manager running in WF, maybe we should drop our stuff and use that instead. We can manage the transactions by retrieving the transaction manager from JNDI. On 8 August 2016 at 14:46, Bill Burke wrote: > > > On 8/8/16 8:31 AM, Marek Posolda wrote: > > The question is, if we can fix liquibase instead of require people to > > change DS? Maybe I can try to continue in your branch later this week > > and look at it? > > > > It's not just liquibase. J > > > Another possibility: Don't bootstrap JTA automatically at > > KeycloakSessionFactory.create() but instead do it just in HTTP > > requests (in KeycloakSessionServletFilter ). Then liquibase bootstrap > > won't be an issue? > > > > JPA Model will also barf with the same error if a JTA transaction is > started as we do local JPA transactions. So we have to have the > datasource flag or change how we interact with EntityManagers. > > Bill > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160815/9c7bbba1/attachment.html From sthorger at redhat.com Mon Aug 15 07:44:57 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Mon, 15 Aug 2016 13:44:57 +0200 Subject: [keycloak-dev] combine proxy and keycloak server In-Reply-To: References: <2cc29814-7e14-d55d-ec62-4f0b664dee40@redhat.com> Message-ID: I'm not convinced about this. A lot of complexity for what seems like little benefit. The improvement of not having to do OIDC would probably end up being outweighed by all requests going through Keycloak rather than a separate proxy. On 9 August 2016 at 11:06, Thomas Darimont wrote: > FYI, I sent some questions to the undertow dev-mailing list regarding > dynamic vhost configuration: > http://lists.jboss.org/pipermail/undertow-dev/2016-August/001668.html > > Cheers, > Thomas > > 2016-08-05 21:26 GMT+02:00 Bill Burke : > >> Yeah, on the Client creation page, instead of oidc or saml, you can pick >> "proxied". You would specify the URL pattern of incoming requests and the >> URL pattern to forward HTTP requests and bam, it just works. Set up some >> virtual host table on demand with Undertow. >> >> On 8/5/16 11:36 AM, Thomas Darimont wrote: >> >> Sounds interesting... >> >> could you provide a bit more detail about what you have in mind? >> >> Cheers, >> Thomas >> >> 2016-08-05 16:38 GMT+02:00 Bill Burke : >> >>> Bump. >>> >>> I'm going to keep bumping this occasionally to see if somebody in the >>> community wants to take this on. >>> >>> >>> On 8/4/16 8:30 PM, Bill Burke wrote: >>> > I think we should combine Keycloak Proxy with the keycloak server. >>> When >>> > creating a client, you would have an option to declare it as a proxied >>> > client. This is way better than what we currently have as we woudln't >>> > have to do SAML or OIDC so it would be more performant and it would >>> > require no additional setup. >>> > >>> > _______________________________________________ >>> > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160815/50912625/attachment.html From pnalyvayko at agi.com Mon Aug 15 09:14:24 2016 From: pnalyvayko at agi.com (Nalyvayko, Peter) Date: Mon, 15 Aug 2016 13:14:24 +0000 Subject: [keycloak-dev] Claims from UserInfo endpoint are not getting mapped by OIDC identity broker In-Reply-To: References: <1634791415.985171.1470978491849.ref@mail.yahoo.com> <1634791415.985171.1470978491849@mail.yahoo.com>, Message-ID: Let me try to explain another way. I am referring to java\org\keycloak\broker\oidc\OIDCIdentityProvider.java and java\org\keycloak\broker\oidc\mappers\UserAttributeMapper. As far as I can tell, for every social login provider supported in keycloak, there is a corresponding concrete mapper type derived from AbstractJsonUserAttributeMapper that allows to map the claims about authenticated end-user to user attributes. UserAttributeMapper (associated with KeyCloakIdentityProvider and OIDCIdentityProvider), on the other hand, seems to intentionally ignore the end-user claims returned by the UserInfo endpoint and only maps the claims in ID and Access tokens. The work around is simple enough: implement a new mapper type derived from java\org\keycloak\broker\oidc\AbstractJsonUserAttributeMapper to map the claims returned with the UserInfo OIDC endpoint. ________________________________________ From: keycloak-dev-bounces at lists.jboss.org [keycloak-dev-bounces at lists.jboss.org] on behalf of Stian Thorgersen [sthorger at redhat.com] Sent: Monday, August 15, 2016 7:07 AM To: Peter Nalyvayko Cc: Keycloak-dev Subject: Re: [keycloak-dev] Claims from UserInfo endpoint are not getting mapped by OIDC identity broker It should be possible to map claims from the userinfo endpoint, but attributes are only mapped on first login. We don't currently update attributes on subsequent logins. Maybe you are trying with an existing user? On 12 August 2016 at 07:08, Peter Nalyvayko > wrote: Hello, It seems that there is no way to map the claims returned by the /userinfo endpoint to user attributes. I set up an OIDC identity broker to enable external identity broker authentication in keycloak. Some of the relevant information about the user, such as language, locale, etc. are available only by calling the /userinfo point, so I wanted to map the claims returned by the endpoint to the user attributes using the available mappers. Unfortunately, it seems that the Attribute Mapper can maps ID token or Access token claims (User Attribute Mapper), and completely ignores the userInfo claims. Searching through the codebase, I've found that OIDC identity broker calls AbstractJsonUserAttributeMapper.storeUserProfileForMapper to store the user profile returned by the call to /userinfo endpoint in the user's context data. However, there seems to be no way (without modifying the code that is) to map that data to the attributes of the federated user created by the OIDC identity broker. Am I missing something here or this functionality is not available out of the box for OIDC identity broker? I am using keycloak version 2.1.0 Thank you, --Peter _______________________________________________ keycloak-dev mailing list keycloak-dev at lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-dev From bburke at redhat.com Mon Aug 15 09:29:07 2016 From: bburke at redhat.com (Bill Burke) Date: Mon, 15 Aug 2016 09:29:07 -0400 Subject: [keycloak-dev] renaming transaction interfaces In-Reply-To: References: Message-ID: <380d08ea-1025-6ce0-f101-4bc061ff7f5e@redhat.com> I ended up not doing it. I was trying to simplify things. On 8/15/16 6:34 AM, Stian Thorgersen wrote: > KeycloakTransactionSynchronization sounds confusing to me. The > renaming of KeycloakTransactionManager as well. Can you elaborate a > bit on the reasoning behind this? > > On 25 July 2016 at 17:29, Bill Burke > wrote: > > I am also renaming KeycloakTransaction to > KeycloakTransactionSynchronization and KeycloakTransactionManager to > KeycloakTransaction. > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160815/00dd7225/attachment.html From bruno at abstractj.org Mon Aug 15 09:35:47 2016 From: bruno at abstractj.org (Bruno Oliveira) Date: Mon, 15 Aug 2016 10:35:47 -0300 Subject: [keycloak-dev] PAM Conversations - Custom login form In-Reply-To: References: <20160718224830.GA4459@abstractj.org> <20160719090035.GB4459@abstractj.org> <20160720140607.GA24947@abstractj.org> <20160725213319.GA21003@abstractj.org> Message-ID: <20160815133547.GA5310@abstractj.org> On 2016-08-15, Stian Thorgersen wrote: > I've always hated having password+otp in a single field when login to > internal SSO. We can do it that way for the FreeIPA integration, but the > users wouldn't know what to do if a realm allows both regular KC users and > users from as FreeIPA instance. Nor does it work well for installations > where otp is not mandatory. There are some alternatives for it: 1. Document and leave it as is for the SSSD federation provider. People coming from FreeIPA world are familiar with this. 2. Add a label inside the password field like FreeIPA console does[1] for usability purposes. From my understanding, it would require extending UsernamePassword form and provide a new login interface. 3. Provide new OTP screen for SSSD provider with a single field, "OTP" and QRCode info omitted. Because, all the steps to configure two-factor happen on the FreeIPA side. My suggestion is to stick with 1 for now and iterate over it for improvements. [1] - http://imgur.com/eyk5Ewx > > On 25 July 2016 at 23:33, Bruno Oliveira wrote: > > > Hi Bill, > > > > After giving these ideas a try, I started to think about the FreeIPA > > flow and how 2FA validation works. If we provide for the first factor > > username + password or username + (password and OTP - in the same field), > > credentials will be validated anyways. I was misguided by the second prompt > > from sudo, thinking that second factor was mandatory (sorry about that). > > > > The same happens for the FreeIPA web interface, we just provide username + > > password and OTP (if it was configured). > > > > That said, I believe we don't have to add any extra code, aside of what > > we already have for the SSSD Federation provider. I've already > > tested it with and without OTP. The only downside of this approach is > > the fact that we're not going to have an OTP screen and it has to be > > documented in some place. > > > > Does anyone have objections about leaving the flow as is? > > > > On 2016-07-20, Bill Burke wrote: > > > Just create a different form and new Authenticator. I don't think we > > want > > > all this logic with Freemarker, do we? The UI is decoupled from > > credential > > > validation on purpose so that you can move things around, i.e. a Username > > > screen, then the next screen is password/OTP input. > > > > > > Another thing you could do is collect credentials and store them in the > > > ClientSessionModel, then once you've collected the credentials, validate > > > them all in one go. > > > > > > On 7/20/16 10:06 AM, Bruno Oliveira wrote: > > > > On 2016-07-19, Stian Thorgersen wrote: > > > > > Adding Bill.. > > > > > > > > > > It would probably still be better to use user federation for > > verifying > > > > > credentials, but we would need some logic on how to determine what > > > > > mechanism to use for primary authentication and secondary > > authentication. > > > > > Bill was talking about adding some conditional flows to the > > authentication > > > > > maybe that's what we need. > > > > > > > > > > For now I'd focus on OTP though and then move on to smartcard > > afterwards. > > > > I can give it a try and workaround, but I'm not sure if worth the > > > > effort, assuming that later will be necessary to revisit. > > > > > > > > If we hardcode/workaround it on Keycloak, user's coming from FreeIPA > > > > may have their login denied. Even if we ignore smartcards for now. Why? > > > > > > > > Depending on the auth types SSSD will show different login prompts. For > > > > example: > > > > > > > > * Password > > > > Login prompt - $ Password: > > > > > > > > * OTP > > > > Login prompt -> $ First factor: > > > > $ Second factor: > > > > Note: Please notice that they are not validated separately > > > > > > > > * Password + OTP -> $ First factor or password: > > > > > > > > That's the reason why I would like to make the our login screen > > > > dynamic. > > > > > > > > > On 19 July 2016 at 11:00, Bruno Oliveira > > wrote: > > > > > > > > > > > The problem here is the fact that not necessarily the > > > > > > first factor will be a pasword or the second factor an OTP. It > > > > > > could be a smartcard for example. That's why I think is a better > > idea to > > > > > > make it dynamic, because we don't have control over it to tell > > > > > > if the second factor will be a smartcard or an OTP for example. > > > > > > > > > > > > Does it make sense? > > > > > > > > > > > > On 2016-07-19, Stian Thorgersen wrote: > > > > > > > Looks like it's better to keep as is and have user federation > > provider > > > > > > > validate otp credentials as well. The current OTP authenticator > > delegates > > > > > > > to user federation provider, so you'd end up with a separate OTP > > > > > > > authenticator to do it with PAM. > > > > > > > > > > > > > > On 19 July 2016 at 00:48, Bruno Oliveira > > wrote: > > > > > > > > > > > > > > > Good morning, > > > > > > > > > > > > > > > > > > > > > > > > Today to authentication against PAM with just simple > > username/password > > > > > > I > > > > > > > > implemented UserFederationProvider and added the proper PAM > > login to > > > > > > > > validCredentials[1]. This covers the most basic scenario. > > > > > > > > > > > > > > > > Now I would like to cover a more complex scenario like OTP and > > change > > > > > > > > the flow a little bit like this: > > > > > > > > > > > > > > > > 1. User providers her username > > > > > > > > 2. The next screen asks to provide how many factor our user > > has(For > > > > > > > > example: OTP, password). We just don't know, PAM will tell > > what's next. > > > > > > > > 3. We authenticate against it > > > > > > > > > > > > > > > > To see in practice against FreeIPA server, I just recorded it > > > > > > > > for a practical example[2]. > > > > > > > > > > > > > > > > What would be the best approach to implement this flow? I was > > > > > > considering > > > > > > > > to > > > > > > > > move my authentication logic out of SSSD federation provider > > and > > > > > > create a > > > > > > > > PAM > > > > > > > > authenticator. > > > > > > > > > > > > > > > > Does it make sense? > > > > > > > > > > > > > > > > [1] - > > > > > > > > > > > > > > http://www.keycloak.org/docs/javadocs/org/keycloak/models/ > > UserFederationProvider.html#validCredentials-org.keycloak. > > models.RealmModel-org.keycloak.models.UserCredentialModel- > > > > > > > > [2] - https://asciinema.org/a/atwnfbu0kqfasjl65weyoiz7a > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > > > > > > > > abstractj > > > > > > > > PGP: 0x84DC9914 > > > > > > > > _______________________________________________ > > > > > > > > keycloak-dev mailing list > > > > > > > > keycloak-dev at lists.jboss.org > > > > > > > > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > > > > > > > > > > > > -- > > > > > > > > > > > > abstractj > > > > > > PGP: 0x84DC9914 > > > > > > > > > > -- > > > > > > > > abstractj > > > > PGP: 0x84DC9914 > > > > > > > -- > > > > abstractj > > PGP: 0x84DC9914 > > -- abstractj PGP: 0x84DC9914 From bburke at redhat.com Mon Aug 15 09:38:00 2016 From: bburke at redhat.com (Bill Burke) Date: Mon, 15 Aug 2016 09:38:00 -0400 Subject: [keycloak-dev] combine proxy and keycloak server In-Reply-To: References: <2cc29814-7e14-d55d-ec62-4f0b664dee40@redhat.com> Message-ID: <8c754e69-3a46-fe86-2c61-26ab12840f4a@redhat.com> You should rethink your position, IMO. Its actually a huge benefit in both usability and performance. Usability in that you don't have to configure and run a completely different program/process that is configured completely different than Keycloak. You can configure and manage all clients in one place. Performance is that you get rid of all the redirects that happen with SAML and OIDC. FOr your performance concern, you would just assign only a set of specific nodes that would be your proxy. So, if you had a keycloak cluster of 4 nodes, 2 nodes could be designated solely as proxy nodes, the other 2 for normal SSO. On 8/15/16 7:44 AM, Stian Thorgersen wrote: > I'm not convinced about this. A lot of complexity for what seems like > little benefit. The improvement of not having to do OIDC would > probably end up being outweighed by all requests going through > Keycloak rather than a separate proxy. > > On 9 August 2016 at 11:06, Thomas Darimont > > wrote: > > FYI, I sent some questions to the undertow dev-mailing list > regarding dynamic vhost configuration: > http://lists.jboss.org/pipermail/undertow-dev/2016-August/001668.html > > > Cheers, > Thomas > > 2016-08-05 21:26 GMT+02:00 Bill Burke >: > > Yeah, on the Client creation page, instead of oidc or saml, > you can pick "proxied". You would specify the URL pattern of > incoming requests and the URL pattern to forward HTTP requests > and bam, it just works. Set up some virtual host table on > demand with Undertow. > > > On 8/5/16 11:36 AM, Thomas Darimont wrote: >> Sounds interesting... >> >> could you provide a bit more detail about what you have in mind? >> >> Cheers, >> Thomas >> >> 2016-08-05 16:38 GMT+02:00 Bill Burke > >: >> >> Bump. >> >> I'm going to keep bumping this occasionally to see if >> somebody in the >> community wants to take this on. >> >> >> On 8/4/16 8:30 PM, Bill Burke wrote: >> > I think we should combine Keycloak Proxy with the >> keycloak server. When >> > creating a client, you would have an option to declare >> it as a proxied >> > client. This is way better than what we currently have >> as we woudln't >> > have to do SAML or OIDC so it would be more performant >> and it would >> > require no additional setup. >> > >> > _______________________________________________ >> > 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 > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160815/c07b7c38/attachment.html From bburke at redhat.com Mon Aug 15 09:52:28 2016 From: bburke at redhat.com (Bill Burke) Date: Mon, 15 Aug 2016 09:52:28 -0400 Subject: [keycloak-dev] creating JPA user storage provider difficult In-Reply-To: References: <57A2F627.1030406@redhat.com> <930bef50-376c-0df0-8472-eceaa22eb02c@redhat.com> <57A3499B.3080402@redhat.com> <57A44FFA.8080502@redhat.com> Message-ID: FYI, deployer is now in master if you didn't see the email. It does not support deploying SPIs though. I'm not sure on the implications of supporting that or if it can even work with hot re-deployment. i.e. a different deployment that implements that deployed SPI. On 8/15/16 7:39 AM, Stian Thorgersen wrote: > +1 To dropping provider directory as it's not very useful for real > providers. > > Deployer would be awesome, especially if we can leverage > jboss-deployment-structure.xml as an alternative to modules and Maven > deploy plugin. Sounds like a lot of work though. There's also the > issue around not supporting applications deployed directly to Keycloak. > > For a long time ago I built a server which used regular old JEE > session beans as plugins. All you needed to to was to register it > globally in JNDI and the server would scan for implementations of > specific classes. It was a bit of a pain when it came to life cycle > (beans would need to be deployed before the server, etc.). Worked > quite well though ;) > > On 5 August 2016 at 10:36, Marek Posolda > wrote: > > On 04/08/16 16:03, Bill Burke wrote: > > > > > > On 8/4/16 9:56 AM, Marek Posolda wrote: > >> Yep, so we can address this with some sort of "deployer" you > >> proposed, which will have automatically access to JEE APIs, so > people > >> won't need to declare dependencies on them anywhere? Still people > >> always need to deal with modules though, if they don't want > just JEE, > >> but also some other different 3rd party dependencies... > > True, but at least we can make a keycloak deployer that is > consistent > > with WARs, etc. Meaning, those that are experienced writing WARs in > > Wildfly and using jboss-deployment-structure.xml will not have to be > > completely retrained to write a keycloak component. > +1 > > > >> > >>>>> * Had to use JpaKeycloakTransaction to enlist EntityManager with > >>>>> keycloak transactions. This means using EJBs is out of the > question. > >>>>> > >>>>> This is unacceptable. Keycloak is supposed to be simple and > this is > >>>>> extremely difficult. When Keycloak was an exploded WAR you > could use > >>>>> every Java EE component type as you could just plop your > extensions > >>>>> within META-INF/lib. Classloading was simple as it was all > the same > >>>>> classloader. > >>>>> > >>>>> Going forward we need to write an actual deployer for Keycloak > >>>>> extensions that allow you to define Keycloak providers within EE > >>>>> jars, > >>>>> ears, etc. Writing an extension to Keycloak should be as > easy as > >>>>> writing a Java EE application. Extension developers should be > >>>>> able to > >>>>> leverage the entire JBoss/Wildfly platform. Minimally, we also > >>>>> need to > >>>>> begin and commit/rollback a UserTransaction within a > Keycloak request > >>>>> flow so that transaction EE and Spring component layers can > function. > >>>> +1 for deployer. Maybe we can try to prototype an example, which > >>>> uses stuff like EJB and then see what exactly we need to add? > >>>> > >>>> For UserTransaction, we can maybe have the KeycloakTransaction > >>>> implementation, which will delegate to UserTransaction? Then > people > >>>> can optionally enlist it in their provider if they need it : > >>>> > >>>> session.getTransactionManager().enlistAfterCompletion(new > >>>> UserTransactionWrapper()); > >>>> > >>>> Then Keycloak will automatically take care of commit/rollback > this > >>>> transaction at end of request. > >>> Why wouldn't they just use UserTransaction? > >> In case that KeycloakTransaction is rolled back, then it calls > >> rollback to all the enlisted delegates. So enlisted > >> UserTransactionWrapper will then call UserTransaction.rollback > as well. > >> > >> Unless we're going to rewrite our transaction API to use JTA? That > >> will automatically integrate with JPA and infinispan. If people > needs > >> to enlist their own transaction, they need to implement > >> javax.transaction.xa.XAResource. This looks slightly more > complicated > >> then implement our KeycloakTransaction, but on the other hand, > it's a > >> standard. > >> > > I think we can/should have both. We automatically begin and > enlist a > > UserTransactionWrapper into the KeycloakTransactionManager at the > > beginning of a request (in our filter that starts a > KeycloakSession). > > If users want something XA then they implement and integration with > > JTA. If they want something simpler, than use our > KeycloakTransactions. > +1 assuming that automatically enlist UserTransaction in each request > won't have any performance (or other) impact. > > Marek > > > > Bill > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160815/6b3bebf4/attachment-0001.html From psilva at redhat.com Mon Aug 15 10:04:22 2016 From: psilva at redhat.com (Pedro Igor Silva) Date: Mon, 15 Aug 2016 10:04:22 -0400 (EDT) Subject: [keycloak-dev] combine proxy and keycloak server In-Reply-To: <8c754e69-3a46-fe86-2c61-26ab12840f4a@redhat.com> References: <2cc29814-7e14-d55d-ec62-4f0b664dee40@redhat.com> <8c754e69-3a46-fe86-2c61-26ab12840f4a@redhat.com> Message-ID: <490688863.3956429.1471269862402.JavaMail.zimbra@redhat.com> Don't you think that all that is pretty much related with turning Keycloak as a Web Application Firewall (WAF) ? Now that we also have authz services in, we can do a lot of things at this regard. ----- Original Message ----- From: "Bill Burke" To: stian at redhat.com, "Thomas Darimont" Cc: "keycloak-dev" Sent: Monday, August 15, 2016 10:38:00 AM Subject: Re: [keycloak-dev] combine proxy and keycloak server You should rethink your position, IMO. Its actually a huge benefit in both usability and performance. Usability in that you don't have to configure and run a completely different program/process that is configured completely different than Keycloak. You can configure and manage all clients in one place. Performance is that you get rid of all the redirects that happen with SAML and OIDC. FOr your performance concern, you would just assign only a set of specific nodes that would be your proxy. So, if you had a keycloak cluster of 4 nodes, 2 nodes could be designated solely as proxy nodes, the other 2 for normal SSO. On 8/15/16 7:44 AM, Stian Thorgersen wrote: I'm not convinced about this. A lot of complexity for what seems like little benefit. The improvement of not having to do OIDC would probably end up being outweighed by all requests going through Keycloak rather than a separate proxy. On 9 August 2016 at 11:06, Thomas Darimont < thomas.darimont at googlemail.com > wrote: FYI, I sent some questions to the undertow dev-mailing list regarding dynamic vhost configuration: http://lists.jboss.org/pipermail/undertow-dev/2016-August/001668.html Cheers, Thomas 2016-08-05 21:26 GMT+02:00 Bill Burke < bburke at redhat.com > : Yeah, on the Client creation page, instead of oidc or saml, you can pick "proxied". You would specify the URL pattern of incoming requests and the URL pattern to forward HTTP requests and bam, it just works. Set up some virtual host table on demand with Undertow. On 8/5/16 11:36 AM, Thomas Darimont wrote: Sounds interesting... could you provide a bit more detail about what you have in mind? Cheers, Thomas 2016-08-05 16:38 GMT+02:00 Bill Burke < bburke at redhat.com > : Bump. I'm going to keep bumping this occasionally to see if somebody in the community wants to take this on. On 8/4/16 8:30 PM, Bill Burke wrote: > I think we should combine Keycloak Proxy with the keycloak server. When > creating a client, you would have an option to declare it as a proxied > client. This is way better than what we currently have as we woudln't > have to do SAML or OIDC so it would be more performant and it would > require no additional setup. > > _______________________________________________ > 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 _______________________________________________ keycloak-dev mailing list keycloak-dev at lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-dev From bburke at redhat.com Mon Aug 15 10:09:50 2016 From: bburke at redhat.com (Bill Burke) Date: Mon, 15 Aug 2016 10:09:50 -0400 Subject: [keycloak-dev] combine proxy and keycloak server In-Reply-To: <490688863.3956429.1471269862402.JavaMail.zimbra@redhat.com> References: <2cc29814-7e14-d55d-ec62-4f0b664dee40@redhat.com> <8c754e69-3a46-fe86-2c61-26ab12840f4a@redhat.com> <490688863.3956429.1471269862402.JavaMail.zimbra@redhat.com> Message-ID: Yes. There will be a lot of stuff we can do. On 8/15/16 10:04 AM, Pedro Igor Silva wrote: > Don't you think that all that is pretty much related with turning Keycloak as a Web Application Firewall (WAF) ? Now that we also have authz services in, we can do a lot of things at this regard. > > ----- Original Message ----- > From: "Bill Burke" > To: stian at redhat.com, "Thomas Darimont" > Cc: "keycloak-dev" > Sent: Monday, August 15, 2016 10:38:00 AM > Subject: Re: [keycloak-dev] combine proxy and keycloak server > > > > You should rethink your position, IMO. Its actually a huge benefit in both usability and performance. > > Usability in that you don't have to configure and run a completely different program/process that is configured completely different than Keycloak. You can configure and manage all clients in one place. Performance is that you get rid of all the redirects that happen with SAML and OIDC. FOr your performance concern, you would just assign only a set of specific nodes that would be your proxy. So, if you had a keycloak cluster of 4 nodes, 2 nodes could be designated solely as proxy nodes, the other 2 for normal SSO. > > On 8/15/16 7:44 AM, Stian Thorgersen wrote: > > > > I'm not convinced about this. A lot of complexity for what seems like little benefit. The improvement of not having to do OIDC would probably end up being outweighed by all requests going through Keycloak rather than a separate proxy. > > On 9 August 2016 at 11:06, Thomas Darimont < thomas.darimont at googlemail.com > wrote: > > > > FYI, I sent some questions to the undertow dev-mailing list regarding dynamic vhost configuration: > http://lists.jboss.org/pipermail/undertow-dev/2016-August/001668.html > > Cheers, > Thomas > > 2016-08-05 21:26 GMT+02:00 Bill Burke < bburke at redhat.com > : > > > > > > Yeah, on the Client creation page, instead of oidc or saml, you can pick "proxied". You would specify the URL pattern of incoming requests and the URL pattern to forward HTTP requests and bam, it just works. Set up some virtual host table on demand with Undertow. > > On 8/5/16 11:36 AM, Thomas Darimont wrote: > > > > Sounds interesting... > > could you provide a bit more detail about what you have in mind? > > Cheers, > Thomas > > 2016-08-05 16:38 GMT+02:00 Bill Burke < bburke at redhat.com > : > > > Bump. > > I'm going to keep bumping this occasionally to see if somebody in the > community wants to take this on. > > > On 8/4/16 8:30 PM, Bill Burke wrote: >> I think we should combine Keycloak Proxy with the keycloak server. When >> creating a client, you would have an option to declare it as a proxied >> client. This is way better than what we currently have as we woudln't >> have to do SAML or OIDC so it would be more performant and it would >> require no additional setup. >> >> _______________________________________________ >> 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 > > > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev From josh.cain at redhat.com Mon Aug 15 10:41:10 2016 From: josh.cain at redhat.com (Josh Cain) Date: Mon, 15 Aug 2016 09:41:10 -0500 Subject: [keycloak-dev] Docker Protocol? In-Reply-To: References: Message-ID: Hi Stian, Docker's auth V2 (docs link above) is Oauth-ish, but doesn't seem to conform 100% to the specification. I started by just trying to stand up an OIDC endpoint to talk to docker and Keycloak threw a "Missing parameters: response_type" error. Turns out, Docker sends the GET request like this: /auth/realms/redhat-external/protocol/docker-v2/auth?account=jcain&scope=repository%3Acentos%3Apull&service=docker-registry Not only is the request missing the request_typer paremeter, but Docker uses different nomenclature than the OAuth/OIDC standard. For instance, I would expect the 'service' param to appear as the client_id param to conform to the OAuth spec. Since it uses different nomenclature, I thought it would be a much cleaner implementation to just implement it as its own protocol. Didn't want to muddy up a clean OIDC/OAuth implemention. Are there workarounds to deal with these differences that I'm missing? Josh Cain | Software Applications Engineer *Identity and Access Management* *Red Hat* +1 843-737-1735 On Mon, Aug 15, 2016 at 5:56 AM, Stian Thorgersen wrote: > I'm not sure I fully understand. Are you using a Docker client to > authenticate with Keycloak? That works with the standard OIDC flows, but it > requires some additional claims in the token which you are adding with a > protocol mapper? > > On 12 August 2016 at 15:31, Josh Cain wrote: > >> Hi All, >> >> We want to use Keycloak as the IDP/Token issuer for authentication with a >> docker registry as per the specification found here: >> >> https://docs.docker.com/registry/spec/auth/ >> >> I've implemented a Protocol Mapper in Keycloak that successfully uses the >> IDP to perform a login against a registry/docker client. Is this something >> that the team is interested in building into the product? If so, I'd be >> happy to push back upstream. >> >> Josh Cain | Software Applications Engineer >> *Identity and Access Management* >> *Red Hat* >> +1 843-737-1735 >> >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160815/b067fa85/attachment.html From bburke at redhat.com Mon Aug 15 18:57:46 2016 From: bburke at redhat.com (Bill Burke) Date: Mon, 15 Aug 2016 18:57:46 -0400 Subject: [keycloak-dev] new credential SPI Message-ID: I'm currently working on a new credential SPI that will replace existing methods on UserProvider and UserModel, as well as replacing UserCredentialModel, etc. This is a work in progress where we may see multiple iterations in master. I hope to remain backward compatible, but can't guarentee I won't break existing User Federation Providers. Here's an initial writeup to explain things. Credentials revolve around these 4 events that are initiated by authentication flows, the admin console, and the account service. * Is the user configured for a specific credential type * Is a credential valid * What required actions must be taken for an unconfigured credential type * update a credential How each of these events is resolved will depend on the configuration of the system and these interfaces: public interface CredentialInput { String getType(); } public interface CredentialInputValidator { boolean supportsCredentialType(String credentialType); boolean isConfiguredFor(RealmModel realm, UserModel user, String credentialType); boolean isValid(RealmModel realm, UserModel user, CredentialInput input); } public interface CredentialInputUpdater { boolean supportsCredentialType(String credentialType); Set requiredActionsFor(RealmModel realm, UserModel user, String credentialType); void updateCredential(RealmModel realm, UserModel user, CredentialInput input); } Two different types of components will be able to implement these interfaces. UserStorageProviders (user federation) and CredentialProviders. CredentialProviders are components configured at the realm level. CredentialProviders are responsible for managing one or more types of credential types and are the bridge between CredentialInput and where the credential is stored. UserStorageProvider is always asked first whether it can complete the requested action, then CredentialProviders are queried in order of their priority. Each UserStorageProvider and/or CredentialProvider can implement the OnUserCache callback interface discussed in my previous custom caching email. This allows each credential type to decide whether it will be cached or not along with the user. For example, HOTP cannot be cached. So, for example, there will be a KeycloakMobileOTPProvider. This deals with Google Authenticator and FreeOTP as well as storing these things within Keycloak storage, it also looks at the OTP policy of the realm to determine how to update and store the OTP secret and stuff. There is also a KeycloakPasswordProvider which hooks into Keycloak storage and the PasswordPolicies set up by the realm. When a user is cached, the KeycloakPasswordProvider will add the hashed password to the user cache, the KeycloakMobileOTPProvider will add the OTP secret to cache if its not HOTP and needs to maintain a counter. Let's walk through an authentication flow, specificaly for OTP. 1. Authenticator calls KeycloakSession.users().isConfiguredFor(realm, user, "OTP"). If the user was loaded by a UserStorageProvider and that provider implements the CredentialInputValidator interface, isConfiguredFor() is called on that. If that returns false, each CredentialProvider is iterated on to call isConfiguredFor(). 2. If OTP is required and not configured for the user, the Authenticator then calls KeycloakSession.users().requiredActionsFor(...). Again, UserStorageProvider is queried first, then the CredneitalProviders. The first provider that returns a non-empty set will end the query and the set of required actions will be returned. 3a. Let's say that in this particular example, the generic OTP Requried Action screen is invoked. In that case, this required action provider callsKeycloakSession.users().updateCredential. The first UserStorageProvider or CredentialProvider that can handle this credential type will save the credential. 3b. If OTP is configured for user, the OTP is obtained by the Authenticator and KeycloakSession.users().isValid() method is called. Again, UserStorageProvider first, then each CredentialProvider. Each provider is queried until one returns true or the list is exhausted. FYI, This algorithm allows for multiple OTP authenticators per user. ** Admin console and Account Service UIs ** Like we do for other components, the UserStorageProvider or CredentialProvider can optionally provide a list of ProviderConfigProperties for the admin console and/or account serviceso that it can create a credential for a specific user. There will be separate property lists for admin console and account service. If a specific custom screen is desired, I'm pretty sure we can just allow the develoepr to plug in their own $routeProvider for the admin console. We don't have a pluggable mechanism for the account service yet (or a way to generic render either). This will need to be developed eventually. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160815/99c95996/attachment-0001.html From bburke at redhat.com Mon Aug 15 17:54:22 2016 From: bburke at redhat.com (Bill Burke) Date: Mon, 15 Aug 2016 17:54:22 -0400 Subject: [keycloak-dev] caching custom per-user objects Message-ID: <74df5afb-0e74-a504-0c77-67cef13795d8@redhat.com> I've run into a few places where I need to cache custom things per-user that are evicted along with the user. I also need some fine grain control of things that get cached with a user. Here are the scenarios * UserStorageProvider SPI needs to cache something that doesn't fit with the current UserModel metadata * Certain credential types like HOTP need to be updated per login. We don't want to cache these things, and we do not want to evict users in the cache that use these credential types * It should be possible to cache credentials that are validated by an external provider. For example, password and LDAP. JBoss has supported caching successfully validated credentials since forever. I'm going to expose a new interface via KeycloakSession: UserCache interface UserCache extends UserProvider { boolean isCached(UserModel user); void cacheWith(UserMode userl, Object key, Object value); } I'm also going to add a callback interface interface OnUserCache { void cacheUser(RealmModel realm, UserModel user, Map cache); } I originally thought about having a ProviderEvent for OnUserCache, but this callback needs to be targeted to specific objects rather than everything. i.e. a specific User Storage Provider rather than being sent to every storage provider. Bill From sthorger at redhat.com Tue Aug 16 03:10:37 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Tue, 16 Aug 2016 09:10:37 +0200 Subject: [keycloak-dev] combine proxy and keycloak server In-Reply-To: <8c754e69-3a46-fe86-2c61-26ab12840f4a@redhat.com> References: <2cc29814-7e14-d55d-ec62-4f0b664dee40@redhat.com> <8c754e69-3a46-fe86-2c61-26ab12840f4a@redhat.com> Message-ID: You'll end up with another "protocol" to do this, which is additional maintenance and testing and more importantly a new potential vector for vulnerabilities. Not great IMO. What you are describing around having dedicated nodes for the proxy operations just sounds more complex than having completely separate servers completely. For high performance I'd imagine the proxy would end up with having quite different needs for configuration than the Keycloak server as well. There's also plenty of options around proxies (Apache, nginx, APIMan, 3scale, etc.). I'm not convinced we should even have our own. Sounds like APIMan might actually survive and end up being supported in some form, so that may still be a better option to us rolling our own proxy/gateway. On 15 August 2016 at 15:38, Bill Burke wrote: > You should rethink your position, IMO. Its actually a huge benefit in > both usability and performance. > > Usability in that you don't have to configure and run a completely > different program/process that is configured completely different than > Keycloak. You can configure and manage all clients in one place. > Performance is that you get rid of all the redirects that happen with SAML > and OIDC. FOr your performance concern, you would just assign only a set > of specific nodes that would be your proxy. So, if you had a keycloak > cluster of 4 nodes, 2 nodes could be designated solely as proxy nodes, the > other 2 for normal SSO. > > On 8/15/16 7:44 AM, Stian Thorgersen wrote: > > I'm not convinced about this. A lot of complexity for what seems like > little benefit. The improvement of not having to do OIDC would probably end > up being outweighed by all requests going through Keycloak rather than a > separate proxy. > > On 9 August 2016 at 11:06, Thomas Darimont > wrote: > >> FYI, I sent some questions to the undertow dev-mailing list regarding >> dynamic vhost configuration: >> http://lists.jboss.org/pipermail/undertow-dev/2016-August/001668.html >> >> Cheers, >> Thomas >> >> 2016-08-05 21:26 GMT+02:00 Bill Burke : >> >>> Yeah, on the Client creation page, instead of oidc or saml, you can pick >>> "proxied". You would specify the URL pattern of incoming requests and the >>> URL pattern to forward HTTP requests and bam, it just works. Set up some >>> virtual host table on demand with Undertow. >>> >>> On 8/5/16 11:36 AM, Thomas Darimont wrote: >>> >>> Sounds interesting... >>> >>> could you provide a bit more detail about what you have in mind? >>> >>> Cheers, >>> Thomas >>> >>> 2016-08-05 16:38 GMT+02:00 Bill Burke : >>> >>>> Bump. >>>> >>>> I'm going to keep bumping this occasionally to see if somebody in the >>>> community wants to take this on. >>>> >>>> >>>> On 8/4/16 8:30 PM, Bill Burke wrote: >>>> > I think we should combine Keycloak Proxy with the keycloak server. >>>> When >>>> > creating a client, you would have an option to declare it as a proxied >>>> > client. This is way better than what we currently have as we woudln't >>>> > have to do SAML or OIDC so it would be more performant and it would >>>> > require no additional setup. >>>> > >>>> > _______________________________________________ >>>> > 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 >> > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160816/0a8acb53/attachment.html From sthorger at redhat.com Tue Aug 16 03:12:48 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Tue, 16 Aug 2016 09:12:48 +0200 Subject: [keycloak-dev] PAM Conversations - Custom login form In-Reply-To: <20160815133547.GA5310@abstractj.org> References: <20160718224830.GA4459@abstractj.org> <20160719090035.GB4459@abstractj.org> <20160720140607.GA24947@abstractj.org> <20160725213319.GA21003@abstractj.org> <20160815133547.GA5310@abstractj.org> Message-ID: I'd say option 1 then. Folks can customize the login screen if they want something else. On 15 August 2016 at 15:35, Bruno Oliveira wrote: > On 2016-08-15, Stian Thorgersen wrote: > > I've always hated having password+otp in a single field when login to > > internal SSO. We can do it that way for the FreeIPA integration, but the > > users wouldn't know what to do if a realm allows both regular KC users > and > > users from as FreeIPA instance. Nor does it work well for installations > > where otp is not mandatory. > > There are some alternatives for it: > > 1. Document and leave it as is for the SSSD federation provider. People > coming from FreeIPA world are familiar with this. > > 2. Add a label inside the password field like FreeIPA console does[1] > for usability purposes. From my understanding, it would require > extending UsernamePassword form and provide a new login interface. > > 3. Provide new OTP screen for SSSD provider with a single field, "OTP" > and QRCode info omitted. Because, all the steps to configure two-factor > happen on the FreeIPA side. > > My suggestion is to stick with 1 for now and iterate over it for > improvements. > > > [1] - http://imgur.com/eyk5Ewx > > > > > On 25 July 2016 at 23:33, Bruno Oliveira wrote: > > > > > Hi Bill, > > > > > > After giving these ideas a try, I started to think about the FreeIPA > > > flow and how 2FA validation works. If we provide for the first factor > > > username + password or username + (password and OTP - in the same > field), > > > credentials will be validated anyways. I was misguided by the second > prompt > > > from sudo, thinking that second factor was mandatory (sorry about > that). > > > > > > The same happens for the FreeIPA web interface, we just provide > username + > > > password and OTP (if it was configured). > > > > > > That said, I believe we don't have to add any extra code, aside of what > > > we already have for the SSSD Federation provider. I've already > > > tested it with and without OTP. The only downside of this approach is > > > the fact that we're not going to have an OTP screen and it has to be > > > documented in some place. > > > > > > Does anyone have objections about leaving the flow as is? > > > > > > On 2016-07-20, Bill Burke wrote: > > > > Just create a different form and new Authenticator. I don't think we > > > want > > > > all this logic with Freemarker, do we? The UI is decoupled from > > > credential > > > > validation on purpose so that you can move things around, i.e. a > Username > > > > screen, then the next screen is password/OTP input. > > > > > > > > Another thing you could do is collect credentials and store them in > the > > > > ClientSessionModel, then once you've collected the credentials, > validate > > > > them all in one go. > > > > > > > > On 7/20/16 10:06 AM, Bruno Oliveira wrote: > > > > > On 2016-07-19, Stian Thorgersen wrote: > > > > > > Adding Bill.. > > > > > > > > > > > > It would probably still be better to use user federation for > > > verifying > > > > > > credentials, but we would need some logic on how to determine > what > > > > > > mechanism to use for primary authentication and secondary > > > authentication. > > > > > > Bill was talking about adding some conditional flows to the > > > authentication > > > > > > maybe that's what we need. > > > > > > > > > > > > For now I'd focus on OTP though and then move on to smartcard > > > afterwards. > > > > > I can give it a try and workaround, but I'm not sure if worth the > > > > > effort, assuming that later will be necessary to revisit. > > > > > > > > > > If we hardcode/workaround it on Keycloak, user's coming from > FreeIPA > > > > > may have their login denied. Even if we ignore smartcards for now. > Why? > > > > > > > > > > Depending on the auth types SSSD will show different login > prompts. For > > > > > example: > > > > > > > > > > * Password > > > > > Login prompt - $ Password: > > > > > > > > > > * OTP > > > > > Login prompt -> $ First factor: > > > > > $ Second factor: > > > > > Note: Please notice that they are not validated separately > > > > > > > > > > * Password + OTP -> $ First factor or password: > > > > > > > > > > That's the reason why I would like to make the our login screen > > > > > dynamic. > > > > > > > > > > > On 19 July 2016 at 11:00, Bruno Oliveira > > > wrote: > > > > > > > > > > > > > The problem here is the fact that not necessarily the > > > > > > > first factor will be a pasword or the second factor an OTP. It > > > > > > > could be a smartcard for example. That's why I think is a > better > > > idea to > > > > > > > make it dynamic, because we don't have control over it to tell > > > > > > > if the second factor will be a smartcard or an OTP for example. > > > > > > > > > > > > > > Does it make sense? > > > > > > > > > > > > > > On 2016-07-19, Stian Thorgersen wrote: > > > > > > > > Looks like it's better to keep as is and have user federation > > > provider > > > > > > > > validate otp credentials as well. The current OTP > authenticator > > > delegates > > > > > > > > to user federation provider, so you'd end up with a separate > OTP > > > > > > > > authenticator to do it with PAM. > > > > > > > > > > > > > > > > On 19 July 2016 at 00:48, Bruno Oliveira < > bruno at abstractj.org> > > > wrote: > > > > > > > > > > > > > > > > > Good morning, > > > > > > > > > > > > > > > > > > > > > > > > > > > Today to authentication against PAM with just simple > > > username/password > > > > > > > I > > > > > > > > > implemented UserFederationProvider and added the proper PAM > > > login to > > > > > > > > > validCredentials[1]. This covers the most basic scenario. > > > > > > > > > > > > > > > > > > Now I would like to cover a more complex scenario like OTP > and > > > change > > > > > > > > > the flow a little bit like this: > > > > > > > > > > > > > > > > > > 1. User providers her username > > > > > > > > > 2. The next screen asks to provide how many factor our user > > > has(For > > > > > > > > > example: OTP, password). We just don't know, PAM will tell > > > what's next. > > > > > > > > > 3. We authenticate against it > > > > > > > > > > > > > > > > > > To see in practice against FreeIPA server, I just recorded > it > > > > > > > > > for a practical example[2]. > > > > > > > > > > > > > > > > > > What would be the best approach to implement this flow? I > was > > > > > > > considering > > > > > > > > > to > > > > > > > > > move my authentication logic out of SSSD federation > provider > > > and > > > > > > > create a > > > > > > > > > PAM > > > > > > > > > authenticator. > > > > > > > > > > > > > > > > > > Does it make sense? > > > > > > > > > > > > > > > > > > [1] - > > > > > > > > > > > > > > > > http://www.keycloak.org/docs/javadocs/org/keycloak/models/ > > > UserFederationProvider.html#validCredentials-org.keycloak. > > > models.RealmModel-org.keycloak.models.UserCredentialModel- > > > > > > > > > [2] - https://asciinema.org/a/atwnfbu0kqfasjl65weyoiz7a > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > > > > > > > > > > abstractj > > > > > > > > > PGP: 0x84DC9914 > > > > > > > > > _______________________________________________ > > > > > > > > > keycloak-dev mailing list > > > > > > > > > keycloak-dev at lists.jboss.org > > > > > > > > > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > > > > > > > > > > > > > > -- > > > > > > > > > > > > > > abstractj > > > > > > > PGP: 0x84DC9914 > > > > > > > > > > > > -- > > > > > > > > > > abstractj > > > > > PGP: 0x84DC9914 > > > > > > > > > > -- > > > > > > abstractj > > > PGP: 0x84DC9914 > > > > > -- > > abstractj > PGP: 0x84DC9914 > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160816/3738da22/attachment-0001.html From wadahiro at gmail.com Tue Aug 16 04:53:37 2016 From: wadahiro at gmail.com (Hiroyuki Wada) Date: Tue, 16 Aug 2016 17:53:37 +0900 Subject: [keycloak-dev] Japanese Localization In-Reply-To: References: <57A2F68B.6010401@redhat.com> Message-ID: By the way, I found some minor issues in UI like missing message key during this translation work. Could I create a JIRA issue and send a PR? Regards, -- Hiroyuki Wada On Fri, Aug 5, 2016 at 10:13 AM, Hiroyuki Wada wrote: >> Just a note that we can accept localization PR if you also take care of >> maintain your locale in future releases. > > Yes, I will maintain it. > > Regards, > > -- > Hiroyuki Wada > > > On Thu, Aug 4, 2016 at 5:02 PM, Marek Posolda wrote: >> Just a note that we can accept localization PR if you also take care of >> maintain your locale in future releases. >> >> Thanks, >> Marek >> >> >> On 04/08/16 03:46, Hiroyuki Wada wrote: >> >> Thanks. I created a JIRA issue. >> https://issues.jboss.org/browse/KEYCLOAK-3397 >> >> I'll send a pull request later! >> >> >> 2016?8?3?(?) 17:05 Thomas Darimont : >>> >>> Hello Hiroyuki, >>> >>> I'd say just go ahead and feel free to create a JIRA issue - and reference >>> the issue number in your commit like >>> KEYCLOAK-XXX Add Japanese localization. >>> >>> Try to keep your changes in a single commit in your pull request, this >>> makes it easier to apply (e.g. via cherry-pick) - I listed my workflow for >>> reference below. >>> Once you're done with your PR just add a link to it to the JIRA issue (in >>> the JIRA issue, press "." then type "git" -> which brings you the to the >>> "add git pull request" dialog. >>> >>> If you want an example for a JIRA issue here is a similar ticket for >>> french translation: >>> https://issues.jboss.org/browse/KEYCLOAK-1903 >>> >>> Cheers, >>> Thomas >>> >>> My workflow: >>> I tend to create a separate branch for every JIRA issue, so I do the >>> following (from a checked out master branch) >>> 0) git clone https://github.com/thomasdarimont/keycloak >>> (origin is my keycloak fork) >>> git remote add upstream https://github.com/keycloak/keycloak >>> (upstream is original keycloak) >>> 1) git checkout -b issue/KEYCLOAK-XXX-short-description >>> (this will create and checkout the branch) >>> 2) code... >>> 3) git add . >>> 4) git commit -m (or use a graphical git client like gitg on linux, or >>> gitx on osx) >>> 5) git push -u origin issue/KEYCLOAK-XXX-short-description >>> 6) on your cloned github project you should now see a link for: create >>> pull request for the newly pushed branch - click and the PR is there >>> if I need to change stuff in the PR (before it is merged) I do the >>> following >>> 7) change... >>> 8) git add . >>> 9) git commit --amend (or use a graphical git client like gitg on linux, >>> or gitx on osx) >>> 10) git push -f origin issue/KEYCLOAK-XXX-short-description >>> (this will update your PR as well, but github is smart enough to retain >>> potentially PR comments if those places didn't change) >>> 11) goto 7) if necessary >>> >>> Updating your keycloak fork from original keycloak upstream >>> 1) git checkout master >>> 2) git pull upstream master >>> 3) git push origin master >>> (to update the master branch in your fork if necessary) >>> >>> to update an issue branch to the latest master >>> 1) git checkout issue/KEYCLOAK-XXX-short-description >>> 2) git rebase master >>> (your issue branch is now based on the latest changes from master) >>> 3) git push -f origin issue/KEYCLOAK-XXX-short-description >>> >>> 2016-08-03 5:19 GMT+02:00 Hiroyuki Wada : >>>> >>>> Hello all, >>>> >>>> I am translating all base theme messages to Japanaese language now. >>>> (I think I can do it by the end of the week.) >>>> >>>> I'd like to contribute the message resources, How do you think? >>>> If it's ok, I'll create a JIRA issue and create a pull request. >>>> >>>> Regards, >>>> >>>> -- >>>> Hiroyuki Wada >>>> wadahiro at gmail.com >>>> >>>> _______________________________________________ >>>> 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 Aug 16 05:16:37 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Tue, 16 Aug 2016 11:16:37 +0200 Subject: [keycloak-dev] Japanese Localization In-Reply-To: References: <57A2F68B.6010401@redhat.com> Message-ID: Sure On 16 August 2016 at 10:53, Hiroyuki Wada wrote: > By the way, I found some minor issues in UI like missing message key > during this translation work. > Could I create a JIRA issue and send a PR? > > Regards, > > -- > Hiroyuki Wada > > On Fri, Aug 5, 2016 at 10:13 AM, Hiroyuki Wada wrote: > >> Just a note that we can accept localization PR if you also take care of > >> maintain your locale in future releases. > > > > Yes, I will maintain it. > > > > Regards, > > > > -- > > Hiroyuki Wada > > > > > > On Thu, Aug 4, 2016 at 5:02 PM, Marek Posolda > wrote: > >> Just a note that we can accept localization PR if you also take care of > >> maintain your locale in future releases. > >> > >> Thanks, > >> Marek > >> > >> > >> On 04/08/16 03:46, Hiroyuki Wada wrote: > >> > >> Thanks. I created a JIRA issue. > >> https://issues.jboss.org/browse/KEYCLOAK-3397 > >> > >> I'll send a pull request later! > >> > >> > >> 2016?8?3?(?) 17:05 Thomas Darimont : > >>> > >>> Hello Hiroyuki, > >>> > >>> I'd say just go ahead and feel free to create a JIRA issue - and > reference > >>> the issue number in your commit like > >>> KEYCLOAK-XXX Add Japanese localization. > >>> > >>> Try to keep your changes in a single commit in your pull request, this > >>> makes it easier to apply (e.g. via cherry-pick) - I listed my workflow > for > >>> reference below. > >>> Once you're done with your PR just add a link to it to the JIRA issue > (in > >>> the JIRA issue, press "." then type "git" -> which brings you the to > the > >>> "add git pull request" dialog. > >>> > >>> If you want an example for a JIRA issue here is a similar ticket for > >>> french translation: > >>> https://issues.jboss.org/browse/KEYCLOAK-1903 > >>> > >>> Cheers, > >>> Thomas > >>> > >>> My workflow: > >>> I tend to create a separate branch for every JIRA issue, so I do the > >>> following (from a checked out master branch) > >>> 0) git clone https://github.com/thomasdarimont/keycloak > >>> (origin is my keycloak fork) > >>> git remote add upstream https://github.com/keycloak/keycloak > >>> (upstream is original keycloak) > >>> 1) git checkout -b issue/KEYCLOAK-XXX-short-description > >>> (this will create and checkout the branch) > >>> 2) code... > >>> 3) git add . > >>> 4) git commit -m (or use a graphical git client like gitg on linux, or > >>> gitx on osx) > >>> 5) git push -u origin issue/KEYCLOAK-XXX-short-description > >>> 6) on your cloned github project you should now see a link for: create > >>> pull request for the newly pushed branch - click and the PR is there > >>> if I need to change stuff in the PR (before it is merged) I do the > >>> following > >>> 7) change... > >>> 8) git add . > >>> 9) git commit --amend (or use a graphical git client like gitg on > linux, > >>> or gitx on osx) > >>> 10) git push -f origin issue/KEYCLOAK-XXX-short-description > >>> (this will update your PR as well, but github is smart enough to retain > >>> potentially PR comments if those places didn't change) > >>> 11) goto 7) if necessary > >>> > >>> Updating your keycloak fork from original keycloak upstream > >>> 1) git checkout master > >>> 2) git pull upstream master > >>> 3) git push origin master > >>> (to update the master branch in your fork if necessary) > >>> > >>> to update an issue branch to the latest master > >>> 1) git checkout issue/KEYCLOAK-XXX-short-description > >>> 2) git rebase master > >>> (your issue branch is now based on the latest changes from master) > >>> 3) git push -f origin issue/KEYCLOAK-XXX-short-description > >>> > >>> 2016-08-03 5:19 GMT+02:00 Hiroyuki Wada : > >>>> > >>>> Hello all, > >>>> > >>>> I am translating all base theme messages to Japanaese language now. > >>>> (I think I can do it by the end of the week.) > >>>> > >>>> I'd like to contribute the message resources, How do you think? > >>>> If it's ok, I'll create a JIRA issue and create a pull request. > >>>> > >>>> Regards, > >>>> > >>>> -- > >>>> Hiroyuki Wada > >>>> wadahiro at gmail.com > >>>> > >>>> _______________________________________________ > >>>> 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160816/9f3c413b/attachment.html From sthorger at redhat.com Tue Aug 16 05:19:19 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Tue, 16 Aug 2016 11:19:19 +0200 Subject: [keycloak-dev] Docker Protocol? In-Reply-To: References: Message-ID: I'm not sure we'd like to have a Docker registry specific protocol added directly to Keycloak. Seems like Docker registry should rather get their act together and comply with existing protocols rather than invent their own. We did have an idea of creating some repository for extensions. These would be community maintained, not included in product and wouldn't receive the same level of testing. Maybe that would be a good place for this. With Bills recent deployer work it could be easier to allow users to deploy custom extensions as well. On 15 August 2016 at 16:41, Josh Cain wrote: > Hi Stian, > > Docker's auth V2 (docs link above) is Oauth-ish, but doesn't seem to > conform 100% to the specification. I started by just trying to stand up an > OIDC endpoint to talk to docker and Keycloak threw a "Missing parameters: > response_type" error. Turns out, Docker sends the GET request like this: > > /auth/realms/redhat-external/protocol/docker-v2/auth?account=jcain&scope= > repository%3Acentos%3Apull&service=docker-registry > > Not only is the request missing the request_typer paremeter, but Docker > uses different nomenclature than the OAuth/OIDC standard. For instance, I > would expect the 'service' param to appear as the client_id param to > conform to the OAuth spec. > > Since it uses different nomenclature, I thought it would be a much cleaner > implementation to just implement it as its own protocol. Didn't want to > muddy up a clean OIDC/OAuth implemention. > > Are there workarounds to deal with these differences that I'm missing? > > > Josh Cain | Software Applications Engineer > *Identity and Access Management* > *Red Hat* > +1 843-737-1735 > > On Mon, Aug 15, 2016 at 5:56 AM, Stian Thorgersen > wrote: > >> I'm not sure I fully understand. Are you using a Docker client to >> authenticate with Keycloak? That works with the standard OIDC flows, but it >> requires some additional claims in the token which you are adding with a >> protocol mapper? >> >> On 12 August 2016 at 15:31, Josh Cain wrote: >> >>> Hi All, >>> >>> We want to use Keycloak as the IDP/Token issuer for authentication with >>> a docker registry as per the specification found here: >>> >>> https://docs.docker.com/registry/spec/auth/ >>> >>> I've implemented a Protocol Mapper in Keycloak that successfully uses >>> the IDP to perform a login against a registry/docker client. Is this >>> something that the team is interested in building into the product? If so, >>> I'd be happy to push back upstream. >>> >>> Josh Cain | Software Applications Engineer >>> *Identity and Access Management* >>> *Red Hat* >>> +1 843-737-1735 >>> >>> _______________________________________________ >>> keycloak-dev mailing list >>> keycloak-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160816/44c0412a/attachment-0001.html From wadahiro at gmail.com Tue Aug 16 07:25:45 2016 From: wadahiro at gmail.com (Hiroyuki Wada) Date: Tue, 16 Aug 2016 11:25:45 +0000 Subject: [keycloak-dev] Japanese Localization In-Reply-To: References: <57A2F68B.6010401@redhat.com> Message-ID: I created a JIRA issue. I will send a PR soon. https://issues.jboss.org/browse/KEYCLOAK-3435 2016?8?16?(?) 18:16 Stian Thorgersen : > Sure > > On 16 August 2016 at 10:53, Hiroyuki Wada wrote: > >> By the way, I found some minor issues in UI like missing message key >> during this translation work. >> Could I create a JIRA issue and send a PR? >> >> Regards, >> >> -- >> Hiroyuki Wada >> >> On Fri, Aug 5, 2016 at 10:13 AM, Hiroyuki Wada >> wrote: >> >> Just a note that we can accept localization PR if you also take care of >> >> maintain your locale in future releases. >> > >> > Yes, I will maintain it. >> > >> > Regards, >> > >> > -- >> > Hiroyuki Wada >> > >> > >> > On Thu, Aug 4, 2016 at 5:02 PM, Marek Posolda >> wrote: >> >> Just a note that we can accept localization PR if you also take care of >> >> maintain your locale in future releases. >> >> >> >> Thanks, >> >> Marek >> >> >> >> >> >> On 04/08/16 03:46, Hiroyuki Wada wrote: >> >> >> >> Thanks. I created a JIRA issue. >> >> https://issues.jboss.org/browse/KEYCLOAK-3397 >> >> >> >> I'll send a pull request later! >> >> >> >> >> >> 2016?8?3?(?) 17:05 Thomas Darimont : >> >>> >> >>> Hello Hiroyuki, >> >>> >> >>> I'd say just go ahead and feel free to create a JIRA issue - and >> reference >> >>> the issue number in your commit like >> >>> KEYCLOAK-XXX Add Japanese localization. >> >>> >> >>> Try to keep your changes in a single commit in your pull request, this >> >>> makes it easier to apply (e.g. via cherry-pick) - I listed my >> workflow for >> >>> reference below. >> >>> Once you're done with your PR just add a link to it to the JIRA issue >> (in >> >>> the JIRA issue, press "." then type "git" -> which brings you the to >> the >> >>> "add git pull request" dialog. >> >>> >> >>> If you want an example for a JIRA issue here is a similar ticket for >> >>> french translation: >> >>> https://issues.jboss.org/browse/KEYCLOAK-1903 >> >>> >> >>> Cheers, >> >>> Thomas >> >>> >> >>> My workflow: >> >>> I tend to create a separate branch for every JIRA issue, so I do the >> >>> following (from a checked out master branch) >> >>> 0) git clone https://github.com/thomasdarimont/keycloak >> >>> (origin is my keycloak fork) >> >>> git remote add upstream https://github.com/keycloak/keycloak >> >>> (upstream is original keycloak) >> >>> 1) git checkout -b issue/KEYCLOAK-XXX-short-description >> >>> (this will create and checkout the branch) >> >>> 2) code... >> >>> 3) git add . >> >>> 4) git commit -m (or use a graphical git client like gitg on linux, or >> >>> gitx on osx) >> >>> 5) git push -u origin issue/KEYCLOAK-XXX-short-description >> >>> 6) on your cloned github project you should now see a link for: create >> >>> pull request for the newly pushed branch - click and the PR is there >> >>> if I need to change stuff in the PR (before it is merged) I do the >> >>> following >> >>> 7) change... >> >>> 8) git add . >> >>> 9) git commit --amend (or use a graphical git client like gitg on >> linux, >> >>> or gitx on osx) >> >>> 10) git push -f origin issue/KEYCLOAK-XXX-short-description >> >>> (this will update your PR as well, but github is smart enough to >> retain >> >>> potentially PR comments if those places didn't change) >> >>> 11) goto 7) if necessary >> >>> >> >>> Updating your keycloak fork from original keycloak upstream >> >>> 1) git checkout master >> >>> 2) git pull upstream master >> >>> 3) git push origin master >> >>> (to update the master branch in your fork if necessary) >> >>> >> >>> to update an issue branch to the latest master >> >>> 1) git checkout issue/KEYCLOAK-XXX-short-description >> >>> 2) git rebase master >> >>> (your issue branch is now based on the latest changes from master) >> >>> 3) git push -f origin issue/KEYCLOAK-XXX-short-description >> >>> >> >>> 2016-08-03 5:19 GMT+02:00 Hiroyuki Wada : >> >>>> >> >>>> Hello all, >> >>>> >> >>>> I am translating all base theme messages to Japanaese language now. >> >>>> (I think I can do it by the end of the week.) >> >>>> >> >>>> I'd like to contribute the message resources, How do you think? >> >>>> If it's ok, I'll create a JIRA issue and create a pull request. >> >>>> >> >>>> Regards, >> >>>> >> >>>> -- >> >>>> Hiroyuki Wada >> >>>> wadahiro at gmail.com >> >>>> >> >>>> _______________________________________________ >> >>>> 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 >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160816/00e77ac1/attachment.html From bruno at abstractj.org Tue Aug 16 10:06:32 2016 From: bruno at abstractj.org (Bruno Oliveira) Date: Tue, 16 Aug 2016 11:06:32 -0300 Subject: [keycloak-dev] travis seems to be down In-Reply-To: References: <20160727210147.GA3027@abstractj.org> <2011162883.20344066.1469654209191.JavaMail.zimbra@redhat.com> <20160727213744.GA442@abstractj.org> <734242238.20355899.1469660571274.JavaMail.zimbra@redhat.com> <59c046c4-9409-1f13-c63a-6d6744bdd402@redhat.com> <427646040.20364950.1469665193602.JavaMail.zimbra@redhat.com> <20160728014535.GA13976@abstractj.org> <2135599354.20603917.1469718695315.JavaMail.zimbra@redhat.com> Message-ID: <20160816140632.GB19203@abstractj.org> There are some alternatives that we could try: * https://www.cloudbees.com/partners/platform/red-hat * https://developers.openshift.com/managing-your-applications/continuous-integration.html * Make use of a beefy machine :) * Or host Jenkins in some paid cloud infrastructure If we don't have any volunteers, count me in. On 2016-08-15, Stian Thorgersen wrote: > My opinion is that i HATE Travis! It's slow and has a tendency to act like > a stroppy toddler. > > Removing -q doesn't work because we then end up generating more log than > Travis allows which kills the build as well. > > We used to have the caching enabled, but it used to result in a lot of > issues. Can't quite remember the details though. Maybe we can try it again. > > There's also travis_wait option that could work ( > https://docs.travis-ci.com/user/common-build-problems/#Build-times-out-because-no-output-was-received > ). > > My preference would be to migrate away from Travis and use something more > beefy that can run tests quicker. > > I'll need to figure out someone to look into it though. Any volunteers? > > > > > On 28 July 2016 at 17:11, Pedro Igor Silva wrote: > > > Let's see what Stian thinks about it :) For me, it is also an option. > > > > ----- Original Message ----- > > From: "Bruno Oliveira" > > To: "Pedro Igor Silva" > > Cc: "Bill Burke" , "keycloak-dev" < > > keycloak-dev at lists.jboss.org> > > Sent: Wednesday, July 27, 2016 10:45:35 PM > > Subject: Re: [keycloak-dev] travis seems to be down > > > > Another alternative, but you might not enjoy it, is :) > > > > Before start building Keycloak, pre-download all the '.m2' dir with > > the dependencies required. Second alternative, is to try some caching[1], > > but it may > > or may not work. > > > > [1] - https://docs.travis-ci.com/user/caching/ > > > > On 2016-07-27, Pedro Igor Silva wrote: > > > As Bruno suggested, the problem is probably related with the build > > taking too long. If you look at the first command being executed: > > > > > > mvn install -Pdistribution -DskipTests=true -B -V -q > > > > > > The -q option tells maven to run in quite mode and only show errors. > > Even in my laptop, if I run the command above it takes a bit more time to > > show any output (not too long, but more than usual). That may explain that > > message from Travis. > > > > > > Maybe we should remove -q and just log everything. That could make the > > builds more stable. > > > > > > I've forced a new build to your https://github.com/keycloak/ > > keycloak/pull/3079 (without changing anything to .travis.yml). Now it is > > running. > > > > > > ----- Original Message ----- > > > From: "Bill Burke" > > > To: "Pedro Igor Silva" , "Bruno Oliveira" < > > bruno at abstractj.org> > > > Cc: "keycloak-dev" > > > Sent: Wednesday, July 27, 2016 8:53:16 PM > > > Subject: Re: [keycloak-dev] travis seems to be down > > > > > > Wrong... :( I still get this problem. > > > > > > > > > On 7/27/16 7:02 PM, Pedro Igor Silva wrote: > > > > I think Travis decided to not mess with Bill :) > > > > > > > > ----- Original Message ----- > > > > From: "Bruno Oliveira" > > > > To: "Pedro Igor Silva" > > > > Cc: "Bill Burke" , "keycloak-dev" < > > keycloak-dev at lists.jboss.org> > > > > Sent: Wednesday, July 27, 2016 6:37:44 PM > > > > Subject: Re: [keycloak-dev] travis seems to be down > > > > > > > > Seems like the balance of the Force was established again. > > > > > > > > On 2016-07-27, Pedro Igor Silva wrote: > > > >> Got that error, but now the build was successful. > > > >> > > > >> ----- Original Message ----- > > > >> From: "Bruno Oliveira" > > > >> To: "Bill Burke" > > > >> Cc: "keycloak-dev" > > > >> Sent: Wednesday, July 27, 2016 6:01:47 PM > > > >> Subject: Re: [keycloak-dev] travis seems to be down > > > >> > > > >> Seems like they are fully operational[1]. I believe that this is the > > > >> reason: > > > >> > > > >> "No output has been received in the last 10 minutes, this potentially > > indicates a stalled build or something wrong with the build itself." > > > >> > > > >> Based on my previous experiences, it happens when the build takes too > > > >> long. Not really sure if that's the root cause, but I can help > > > >> investigating it. > > > >> > > > >> [1] - https://www.traviscistatus.com/ > > > >> > > > >> On 2016-07-27, Bill Burke wrote: > > > >>> A lot of builds failing in initial setup > > > >>> > > > >>> > > > >>> Bill > > > >>> > > > >>> _______________________________________________ > > > >>> keycloak-dev mailing list > > > >>> keycloak-dev at lists.jboss.org > > > >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > >> -- > > > >> > > > >> abstractj > > > >> PGP: 0x84DC9914 > > > >> _______________________________________________ > > > >> keycloak-dev mailing list > > > >> keycloak-dev at lists.jboss.org > > > >> https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > > -- > > > > > > > > abstractj > > > > PGP: 0x84DC9914 > > > > > > > -- > > > > abstractj > > PGP: 0x84DC9914 > > _______________________________________________ > > keycloak-dev mailing list > > keycloak-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > -- abstractj PGP: 0x84DC9914 From bruno at abstractj.org Tue Aug 16 10:12:38 2016 From: bruno at abstractj.org (Bruno Oliveira) Date: Tue, 16 Aug 2016 11:12:38 -0300 Subject: [keycloak-dev] rethinking credentials In-Reply-To: <57AC8E20.3020809@redhat.com> References: <49425643-9824-9fb7-d3c0-8fea12539f94@redhat.com> <57AC8E20.3020809@redhat.com> Message-ID: <20160816141238.GC19203@abstractj.org> On 2016-08-11, Marek Posolda wrote: > I wonder if we can have UserCredentialValueModel to be more generic > store? Currently it has properties applicable just to password or OTP > credentials, but it will be better to have something more generic based > on key-value pairs though. +1 that would be fantastic, if possible. > > For caching of credentials, should it be made configurable if > credentials are cached or not? Currently the creds from DB are always > cached, which can be an issue for someone in theory (For example if > someone do heapdump of Java process, he might be able to see the cached > credentials). > > Marek > > On 10/08/16 17:35, Bill Burke wrote: > > The credential API for users needs to change. Here are the types of > > credentials and how system interacts: > > > > 1. Creds stored, gathered, and validated by Keycloak OOTB code. > > > > 2. Creds stored in external store, but gathered and validated by > > Keycloak OOTB code. (i.e. User Storage SPI returns the credentials > > directly) > > > > 3. Creds gathered by built-in Keycloak OOTB code, but stored and > > validated externally (i.e. LDAP). > > > > 4. Creds gathered by custom Authenticators, stored and validated externally. > > > > 5. Creds gathered by custom authenticators, stored by keycloak, > > validated by custom code. > > > > There's other combinations as well: > > > > a. Keycloak stored User, custom credential store > > > > b. User Storage Provider, keycloak stored creds > > > > c. User Storage Provider, custom credential store > > > > Credentials that are validated by Keycloak are currently cached along > > with the user. What sucks about this that some credential types require > > a database update, i.e. HOTP which needs to update a counter. So HOTP > > invalidates the user cache every single login. We also want to allow > > custom credential stores to be able to cache themselves along with the user. > > > > What's interesting about #4 is that there really doesn't need to be any > > special SPI. The custom authenticator can lookup the factory and > > typecast it to any interface it wants to to validate the credential. > > Since our caching layer is a local-only (invalidation cache), cachable > > custom externally stored credentials just need a simple. > > > > Given all this, gonna put some iterations in on a new credential API. > > Any other thoughts? > > > > _______________________________________________ > > 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 -- abstractj PGP: 0x84DC9914 From mitya at cargosoft.ru Tue Aug 16 15:06:23 2016 From: mitya at cargosoft.ru (Dmitry Telegin) Date: Tue, 16 Aug 2016 22:06:23 +0300 Subject: [keycloak-dev] Preferred storage mechanism for custom settings In-Reply-To: References: <1468323778.4229.4.camel@cargosoft.ru> <1468607337.4292.5.camel@cargosoft.ru> <1468874146.6797.11.camel@cargosoft.ru> <1471099636.5196.11.camel@cargosoft.ru> Message-ID: <1471374383.480.4.camel@cargosoft.ru> Hi, I've started implementing attributes for Mongo. I've begun with adding attribute methods to?org.keycloak.models.entities.RealmEntity (base class for MongoRealmEntity), but ended up with the following: java.lang.IllegalArgumentException: Invalid accessor method, must have zero arguments if starts with 'get'. Method: public java.lang.String org.keycloak.models.entities.RealmEntity.getAttribute(java.lang.String) at org.keycloak.models.utils.reflection.MethodPropertyImpl.(MethodPropertyImpl.java:53) at org.keycloak.models.utils.reflection.Properties.createProperty(Properties.java:44) at org.keycloak.models.utils.reflection.PropertyQuery.getResultList(PropertyQuery.java:168) at org.keycloak.models.utils.reflection.PropertyQuery.getWritableResultList(PropertyQuery.java:140) at org.keycloak.connections.mongo.impl.MongoStoreImpl.getEntityInfo(MongoStoreImpl.java:433) at org.keycloak.connections.mongo.impl.MongoStoreImpl.(MongoStoreImpl.java:101) at org.keycloak.connections.mongo.DefaultMongoConnectionFactoryProvider.lazyInit(DefaultMongoConnectionFactoryProvider.java:156) Seems like KeyCloak's query system doesn't like entities with pseudo- getter methods. Any suggestions? Dmitry > > Sounds like you're on the right track. You'd need to implement support for Mongo as well though as we can't accept it otherwise. > > > > With regards to tests I'd add to?org.keycloak.testsuite.admin.realm.RealmTest which would also make sure attributes work correctly when added through the admin endpoints. > > > > On 13 August 2016 at 16:47, Dmitry Telegin wrote: > > Hi, > > > > (As Stian is on vacation now, I'd appreciate if someone other helps me with this feature.) > > > > > > Please take a look?https://github.com/keycloak/keycloak/compare/2.1 .0.Final...cargosoft:KEYCLOAK-3327 > > > > > > (it has been branched off 2.1.0.Final for the ease of testing, I'll rebase it onto master if needed) > > > > > > o.k.models.RealmModel: added methods (borrowed signatures from jpa.RealmAdapter) > > o.k.models.jpa.RealmAdapter: added @Override annotations > > > > o.k.models.mongo.keycloak.adapters.RealmAdapter: added stubs (throwing?UnsupportedOperationException) > > > > o.k.models.cache.infinispan.RealmAdapter: added attributes caching logic > > > > o.k.models.cache.infinispan.entities.CachedRealm: added attributes cache (as Map) > > > > > > > > > > As for tests, I'm afraid I'll need some guidance. org.keycloak.testsuite.model.ModelTest seems appropriate for that; but it will need support for attributes in RealmRepresentation and RealmManager. Is this the right direction? > > > > Dmitry > > > > > > > > > > > > > > On 18 July 2016 at 22:35, Dmitry Telegin wrote: > > > > Stian, > > > > Here we go:?https://issues.jboss.org/browse/KEYCLOAK-3327 > > > > > > > > > > > > If the fix is somewhat trivial (i.e. a matter of adding fields and getters/setters) I think I could work on a PR as well. > > > > > > > > > > > > > > > > > As the attributes are already available in the underlying entities it's just a matter of exposing through RealmModel and add tests for it. > > > ? > > > > > > > > > > > > BTW, does this mean that all the custom entities provided via Entity SPI are not by default cache-enabled (and won't be synchronized between the nodes in clustered environment)? > > > > > > > > > > > > If so, will it be easy to cache-enable them? Is this just a matter of providing Infinispan adapters similar to existing ones for Realm/User/Role/Client etc.? > > > > > > > > > > > > > > > > > > > > > > > There's no caching for custom entities. I'd recommend using Hibernate 2nd level cache for it as it's rather tricky to create a custom one. We have our custom one because we need to support Mongo as well as users from different sources (user federation and identity brokering). > > > ? > > > > > > > > > > > > > > > > > > > > > > > > Ideally, I'd like to see a current domain-extension example augmented with Infinispan cache functionality. I've got some ideas on a detailed walkthrough tutorial for building complete, full-featured KeyCloak extensions (it's a big topic I'll elaborate on a bit later); I think Infinispan-enabled entities could be covered there, too. > > > > > > > > > > > > > > > > > No chance we're adding cache for custom entities. It's just to hard to get right. For custom entities you should use Hibernate 2nd level cache. > > > ? > > > > Regards, > > > > Dmitry > > > > > > > > ? ??, 18/07/2016 ? 07:39 +0200, Stian Thorgersen ?????: > > > > > > > > > > > > > > > > > > > > Forgot that attributes are not exposed through RealmModel. You can't access the JPA RealmAdapter directly as you'll break the cache functionality. You can create a JIRA to request attributes added to RealmModel though. > > > > > > > > > > On 15 July 2016 at 20:28, Mitya wrote: > > > > > > Stian, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > In my provider, session.getContext().getRealm() returns an instance of?org.keycloak.models.cache.infinispan.RealmAdapter. But in order to be able to manage attributes, we need an org.keycloak.models.jpa.RealmAdapter. What's the best way to obtain it? > > > > > > > > > > > > I've yet come up with the following: > > > > > > > > > > > > RealmModel realm = session.getContext().getRealm(); > > > > > > > > > > > > > > > > > > RealmAdapter adapter = (RealmAdapter) session.getProvider(RealmProvider.class).getRealm(realm.get Id()); > > > > > > > > > > > > > > > > > > > Realm attributes should be perfect for that > > > > > > > > > > > > > > > > > > > > > On 12 July 2016 at 13:42, Mitya wrote: > > > > > > > > Hi, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I'm developing a KeyCloak extension, and I want some custom (per-realm) parameters to be tuned via the GUI form. Speaking of the storage mechanism for my settings, are realm attributes suitable for that? or should I create a dedicated custom entity instead? > > > > > > > > > > > > > > > > Thx, > > > > > > > > Mitya > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > > > > > > > > keycloak-dev mailing list > > > > > > > > > > > > > > > > keycloak-dev at lists.jboss.org > > > > > > > > > > > > > > > > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160816/8c2a9763/attachment.html From josh.cain at redhat.com Tue Aug 16 15:24:25 2016 From: josh.cain at redhat.com (Josh Cain) Date: Tue, 16 Aug 2016 14:24:25 -0500 Subject: [keycloak-dev] Docker Protocol? In-Reply-To: References: Message-ID: Couldn't agree more that Docker should use an existing/standards-based auth protocol. Problem is, we need our Keycloak IDP to start talking to docker registries. Since we have a hard requirement to talk to docker registries, our IDP has to speak docker auth. There are already a number of Docker registry authorization servers out there, so there seems to be a need out there in the community as well. We're going to develop one and push it out such that it's publicly accessible in any case, I was just curious as to whether the dev team would want to incorporate this into the product. Josh Cain | Software Applications Engineer *Identity and Access Management* *Red Hat* +1 256-452-0150 On Tue, Aug 16, 2016 at 4:19 AM, Stian Thorgersen wrote: > I'm not sure we'd like to have a Docker registry specific protocol added > directly to Keycloak. Seems like Docker registry should rather get their > act together and comply with existing protocols rather than invent their > own. > > We did have an idea of creating some repository for extensions. These > would be community maintained, not included in product and wouldn't receive > the same level of testing. Maybe that would be a good place for this. With > Bills recent deployer work it could be easier to allow users to deploy > custom extensions as well. > > On 15 August 2016 at 16:41, Josh Cain wrote: > >> Hi Stian, >> >> Docker's auth V2 (docs link above) is Oauth-ish, but doesn't seem to >> conform 100% to the specification. I started by just trying to stand up an >> OIDC endpoint to talk to docker and Keycloak threw a "Missing parameters: >> response_type" error. Turns out, Docker sends the GET request like this: >> >> /auth/realms/redhat-external/protocol/docker-v2/auth?account >> =jcain&scope=repository%3Acentos%3Apull&service=docker-registry >> >> Not only is the request missing the request_typer paremeter, but Docker >> uses different nomenclature than the OAuth/OIDC standard. For instance, I >> would expect the 'service' param to appear as the client_id param to >> conform to the OAuth spec. >> >> Since it uses different nomenclature, I thought it would be a much >> cleaner implementation to just implement it as its own protocol. Didn't >> want to muddy up a clean OIDC/OAuth implemention. >> >> Are there workarounds to deal with these differences that I'm missing? >> >> >> Josh Cain | Software Applications Engineer >> *Identity and Access Management* >> *Red Hat* >> +1 843-737-1735 >> >> On Mon, Aug 15, 2016 at 5:56 AM, Stian Thorgersen >> wrote: >> >>> I'm not sure I fully understand. Are you using a Docker client to >>> authenticate with Keycloak? That works with the standard OIDC flows, but it >>> requires some additional claims in the token which you are adding with a >>> protocol mapper? >>> >>> On 12 August 2016 at 15:31, Josh Cain wrote: >>> >>>> Hi All, >>>> >>>> We want to use Keycloak as the IDP/Token issuer for authentication with >>>> a docker registry as per the specification found here: >>>> >>>> https://docs.docker.com/registry/spec/auth/ >>>> >>>> I've implemented a Protocol Mapper in Keycloak that successfully uses >>>> the IDP to perform a login against a registry/docker client. Is this >>>> something that the team is interested in building into the product? If so, >>>> I'd be happy to push back upstream. >>>> >>>> Josh Cain | Software Applications Engineer >>>> *Identity and Access Management* >>>> *Red Hat* >>>> +1 843-737-1735 >>>> >>>> _______________________________________________ >>>> keycloak-dev mailing list >>>> keycloak-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>>> >>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160816/22673493/attachment-0001.html From bburke at redhat.com Tue Aug 16 16:43:12 2016 From: bburke at redhat.com (Bill Burke) Date: Tue, 16 Aug 2016 16:43:12 -0400 Subject: [keycloak-dev] combine proxy and keycloak server In-Reply-To: References: <2cc29814-7e14-d55d-ec62-4f0b664dee40@redhat.com> <8c754e69-3a46-fe86-2c61-26ab12840f4a@redhat.com> Message-ID: <0317b095-37e6-6912-80f0-2ddc29bebb4b@redhat.com> On 8/16/16 3:10 AM, Stian Thorgersen wrote: > You'll end up with another "protocol" to do this, which is additional > maintenance and testing and more importantly a new potential vector > for vulnerabilities. Not great IMO. > Protocol? You mean like AJP? BTW, making an argument not to have a feature because of maintenance and testing is a really lame reason. Anybody can basically just use that argument for anything they don't like. > What you are describing around having dedicated nodes for the proxy > operations just sounds more complex than having completely separate > servers completely. For high performance I'd imagine the proxy would > end up with having quite different needs for configuration than the > Keycloak server as well. > Not really. You just specify a DNS entry that points to one of your Keycloak nodes that is designated as the proxy. You ahve to do that anyways. As far as config goes, if the proxy needs to be configured differently, we just provide an extra domain.xml profile like we do for the example load-balancer that is described in the docs. > There's also plenty of options around proxies (Apache, nginx, APIMan, > 3scale, etc.). I'm not convinced we should even have our own. Sounds > like APIMan might actually survive and end up being supported in some > form, so that may still be a better option to us rolling our own > proxy/gateway. > Disagree 100%. Right now without a supported proxy we have zero control over how other languages and environments integrate with Keycloak (except Java). We're at the mercy of mod-auth-mellon and mod-auth-openidc the latter of which isn't even maintained by RHT. Both of which we do not have any in house knowledge to make extensions to. The potential to simplify and unify setup and configuration and management is just too huge here to ignore. But, we're arguing over something that nobody has time to work on anyways :) Bill -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160816/9523cf05/attachment.html From bburke at redhat.com Tue Aug 16 16:51:17 2016 From: bburke at redhat.com (Bill Burke) Date: Tue, 16 Aug 2016 16:51:17 -0400 Subject: [keycloak-dev] rethinking credentials In-Reply-To: <20160816141238.GC19203@abstractj.org> References: <49425643-9824-9fb7-d3c0-8fea12539f94@redhat.com> <57AC8E20.3020809@redhat.com> <20160816141238.GC19203@abstractj.org> Message-ID: On 8/16/16 10:12 AM, Bruno Oliveira wrote: > On 2016-08-11, Marek Posolda wrote: >> I wonder if we can have UserCredentialValueModel to be more generic >> store? Currently it has properties applicable just to password or OTP >> credentials, but it will be better to have something more generic based >> on key-value pairs though. > +1 that would be fantastic, if possible. A data model that can store any arbitrary key-value pair would require a join with RDBMs storage. Should we keep something like UsercredValModel, but just add the ability for attributes? Then model the API so that it can avoid joins? There's also the issue of data migration from the old tables to the new. Since this is users we could be talking about tens of thousands of rows. Bill From marc.boorshtein at tremolosecurity.com Tue Aug 16 16:53:48 2016 From: marc.boorshtein at tremolosecurity.com (Marc Boorshtein) Date: Tue, 16 Aug 2016 16:53:48 -0400 Subject: [keycloak-dev] combine proxy and keycloak server In-Reply-To: References: <2cc29814-7e14-d55d-ec62-4f0b664dee40@redhat.com> <8c754e69-3a46-fe86-2c61-26ab12840f4a@redhat.com> Message-ID: > > There's also plenty of options around proxies (Apache, nginx, APIMan, > 3scale, etc.). I'm not convinced we should even have our own. Sounds like > APIMan might actually survive and end up being supported in some form, so > that may still be a better option to us rolling our own proxy/gateway. > For what its worth, OpenUnison could play this role with KC where OpenUnison does the integration with with applications and KC via OIDC or SAML2 (I'm working on a POC right now using KC for authentication, MyVirtualDirectory for multi directory access and OpenUnison/ScaleJS for provisioning/Reverse Proxy) with Kubernetes and its working great. We already have a powerful LastMile system for application integration that lets us integrate with J2EE, LAMP and .NET applications. The integration between OpenUnison and KC took me about 5 minutes. We have source2image that makes the deployment even easier. - Marc Boorshtein CTO Tremolo Security marc.boorshtein at tremolosecurity.com Twitter - @mlbiam / @tremolosecurity From bburke at redhat.com Tue Aug 16 17:07:51 2016 From: bburke at redhat.com (Bill Burke) Date: Tue, 16 Aug 2016 17:07:51 -0400 Subject: [keycloak-dev] combine proxy and keycloak server In-Reply-To: References: <2cc29814-7e14-d55d-ec62-4f0b664dee40@redhat.com> <8c754e69-3a46-fe86-2c61-26ab12840f4a@redhat.com> Message-ID: One of the main reasons for this whole email thread was to provide a way to reduce the number of moving parts that need to be installed and configured. And reduce the number of steps it takes to secure an application. Integration with other things is interesting, but not the goal of what I'm proposing. On 8/16/16 4:53 PM, Marc Boorshtein wrote: >> There's also plenty of options around proxies (Apache, nginx, APIMan, >> 3scale, etc.). I'm not convinced we should even have our own. Sounds like >> APIMan might actually survive and end up being supported in some form, so >> that may still be a better option to us rolling our own proxy/gateway. >> > For what its worth, OpenUnison could play this role with KC where > OpenUnison does the integration with with applications and KC via OIDC > or SAML2 (I'm working on a POC right now using KC for authentication, > MyVirtualDirectory for multi directory access and OpenUnison/ScaleJS > for provisioning/Reverse Proxy) with Kubernetes and its working great. > We already have a powerful LastMile system for application integration > that lets us integrate with J2EE, LAMP and .NET applications. The > integration between OpenUnison and KC took me about 5 minutes. We > have source2image that makes the deployment even easier. > > > - > Marc Boorshtein > CTO Tremolo Security > marc.boorshtein at tremolosecurity.com > Twitter - @mlbiam / @tremolosecurity From marc.boorshtein at tremolosecurity.com Tue Aug 16 17:12:12 2016 From: marc.boorshtein at tremolosecurity.com (Marc Boorshtein) Date: Tue, 16 Aug 2016 17:12:12 -0400 Subject: [keycloak-dev] combine proxy and keycloak server In-Reply-To: References: <2cc29814-7e14-d55d-ec62-4f0b664dee40@redhat.com> <8c754e69-3a46-fe86-2c61-26ab12840f4a@redhat.com> Message-ID: While I can appreciate that logic, OU is a solution that is live and works, open source and is actively being developed. Just food for thought instead of developing a new solution. Thanks Marc On Tuesday, August 16, 2016, Bill Burke wrote: > One of the main reasons for this whole email thread was to provide a way > to reduce the number of moving parts that need to be installed and > configured. And reduce the number of steps it takes to secure an > application. Integration with other things is interesting, but not the > goal of what I'm proposing. > > > -- Marc Boorshtein CTO Tremolo Security marc.boorshtein at tremolosecurity.com (703) 828-4902 Twitter - @mlbiam / @tremolosecurity -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160816/bd7ba291/attachment.html From jdennis at redhat.com Tue Aug 16 18:19:35 2016 From: jdennis at redhat.com (John Dennis) Date: Tue, 16 Aug 2016 18:19:35 -0400 Subject: [keycloak-dev] combine proxy and keycloak server In-Reply-To: <0317b095-37e6-6912-80f0-2ddc29bebb4b@redhat.com> References: <2cc29814-7e14-d55d-ec62-4f0b664dee40@redhat.com> <8c754e69-3a46-fe86-2c61-26ab12840f4a@redhat.com> <0317b095-37e6-6912-80f0-2ddc29bebb4b@redhat.com> Message-ID: <89fc8973-cf94-0854-233c-ae9736ee35f0@redhat.com> On 08/16/2016 04:43 PM, Bill Burke wrote: >> There's also plenty of options around proxies (Apache, nginx, APIMan, >> 3scale, etc.). I'm not convinced we should even have our own. Sounds >> like APIMan might actually survive and end up being supported in some >> form, so that may still be a better option to us rolling our own >> proxy/gateway. >> > Disagree 100%. Right now without a supported proxy we have zero control > over how other languages and environments integrate with Keycloak > (except Java). We're at the mercy of mod-auth-mellon and > mod-auth-openidc the latter of which isn't even maintained by RHT. Both > of which we do not have any in house knowledge to make extensions to. > The potential to simplify and unify setup and configuration and > management is just too huge here to ignore. Correction, Red Hat does support mod_auth_openidc and we do have in-house expertise to modify and extend these packages. In fact we're already made significant contributions to mod_auth_mellon and the lasso SAML library it utilizes. The platform group has deployed Keycloak behind both the Apache and HAproxy proxies and has (started) documenting the process. We also are in the process of writing Ansible and Puppet configuration modules to help deploy Keycloak, I believe in all these scenarios Keycloak is behind a proxy. I wish our two groups had better awareness of each other. -- John From bburke at redhat.com Tue Aug 16 23:03:18 2016 From: bburke at redhat.com (Bill Burke) Date: Tue, 16 Aug 2016 23:03:18 -0400 Subject: [keycloak-dev] combine proxy and keycloak server In-Reply-To: <89fc8973-cf94-0854-233c-ae9736ee35f0@redhat.com> References: <2cc29814-7e14-d55d-ec62-4f0b664dee40@redhat.com> <8c754e69-3a46-fe86-2c61-26ab12840f4a@redhat.com> <0317b095-37e6-6912-80f0-2ddc29bebb4b@redhat.com> <89fc8973-cf94-0854-233c-ae9736ee35f0@redhat.com> Message-ID: <187a5d1b-6ab4-6a0e-6260-bea16d3ec759@redhat.com> On 8/16/16 6:19 PM, John Dennis wrote: > On 08/16/2016 04:43 PM, Bill Burke wrote: >>> There's also plenty of options around proxies (Apache, nginx, APIMan, >>> 3scale, etc.). I'm not convinced we should even have our own. Sounds >>> like APIMan might actually survive and end up being supported in some >>> form, so that may still be a better option to us rolling our own >>> proxy/gateway. >>> >> Disagree 100%. Right now without a supported proxy we have zero control >> over how other languages and environments integrate with Keycloak >> (except Java). We're at the mercy of mod-auth-mellon and >> mod-auth-openidc the latter of which isn't even maintained by RHT. Both >> of which we do not have any in house knowledge to make extensions to. >> The potential to simplify and unify setup and configuration and >> management is just too huge here to ignore. > > Correction, Red Hat does support mod_auth_openidc and we do have > in-house expertise to modify and extend these packages. In fact we're > already made significant contributions to mod_auth_mellon and the > lasso SAML library it utilizes. > > The platform group has deployed Keycloak behind both the Apache and > HAproxy proxies and has (started) documenting the process. We also are in Could you share these docs with us..create better awareness between the two groups, because we already had to document that process from the keycloak end and we're missing the apache end of things: https://keycloak.gitbooks.io/server-installation-and-configuration/content/v/2.1/topics/clustering/load-balancer.html > the process of writing Ansible and Puppet configuration modules to > help deploy Keycloak, I believe in all these scenarios Keycloak is > behind a proxy. > > I wish our two groups had better awareness of each other. > By in-house knowledge, I mean a member of this team that reports to Bolek. Right now we're stuck with vanilla SAML and OIDC and however these mod-auth plugins implement those specs. Are you willing to maintain a fork of these mods with keycloak-specific extensions? For example we're writing an extension to our Java OIDC adapters so that we can have sticky sessions for both the browser redirects and out-of-band code to token requests so we can avoid unnecessary DB hits. I know you guys support mod-auth-mellon, but mod-auth-openidc is managed and run by a commercial competitor: ping identity, which, by itself sucks from a perception perspective. But we're diverging into arguments that were not the focus of the original post. My main focus to reduce the number of things you have to install and configure, make configuration and management consistent, reduce the number of steps to secure an app, and finally reduce the number of network hops for a login. Make security easier and faster for developers which is why Stian and I started the project in the first place. From sthorger at redhat.com Wed Aug 17 02:46:58 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Wed, 17 Aug 2016 08:46:58 +0200 Subject: [keycloak-dev] travis seems to be down In-Reply-To: <20160816140632.GB19203@abstractj.org> References: <20160727210147.GA3027@abstractj.org> <2011162883.20344066.1469654209191.JavaMail.zimbra@redhat.com> <20160727213744.GA442@abstractj.org> <734242238.20355899.1469660571274.JavaMail.zimbra@redhat.com> <59c046c4-9409-1f13-c63a-6d6744bdd402@redhat.com> <427646040.20364950.1469665193602.JavaMail.zimbra@redhat.com> <20160728014535.GA13976@abstractj.org> <2135599354.20603917.1469718695315.JavaMail.zimbra@redhat.com> <20160816140632.GB19203@abstractj.org> Message-ID: I've tweaked the stroppy toddler a bit ( https://github.com/keycloak/keycloak/pull/3147). Ran that PR 5 times and it passed every time, so hopefully it'll make it a bit more stable. Still takes more than 1 hour to complete though. On 16 August 2016 at 16:06, Bruno Oliveira wrote: > There are some alternatives that we could try: > > * https://www.cloudbees.com/partners/platform/red-hat > * https://developers.openshift.com/managing-your-applications/continuous- > integration.html > * Make use of a beefy machine :) > * Or host Jenkins in some paid cloud infrastructure > > If we don't have any volunteers, count me in. > > On 2016-08-15, Stian Thorgersen wrote: > > My opinion is that i HATE Travis! It's slow and has a tendency to act > like > > a stroppy toddler. > > > > Removing -q doesn't work because we then end up generating more log than > > Travis allows which kills the build as well. > > > > We used to have the caching enabled, but it used to result in a lot of > > issues. Can't quite remember the details though. Maybe we can try it > again. > > > > There's also travis_wait option that could work ( > > https://docs.travis-ci.com/user/common-build-problems/# > Build-times-out-because-no-output-was-received > > ). > > > > My preference would be to migrate away from Travis and use something more > > beefy that can run tests quicker. > > > > I'll need to figure out someone to look into it though. Any volunteers? > > > > > > > > > > On 28 July 2016 at 17:11, Pedro Igor Silva wrote: > > > > > Let's see what Stian thinks about it :) For me, it is also an option. > > > > > > ----- Original Message ----- > > > From: "Bruno Oliveira" > > > To: "Pedro Igor Silva" > > > Cc: "Bill Burke" , "keycloak-dev" < > > > keycloak-dev at lists.jboss.org> > > > Sent: Wednesday, July 27, 2016 10:45:35 PM > > > Subject: Re: [keycloak-dev] travis seems to be down > > > > > > Another alternative, but you might not enjoy it, is :) > > > > > > Before start building Keycloak, pre-download all the '.m2' dir with > > > the dependencies required. Second alternative, is to try some > caching[1], > > > but it may > > > or may not work. > > > > > > [1] - https://docs.travis-ci.com/user/caching/ > > > > > > On 2016-07-27, Pedro Igor Silva wrote: > > > > As Bruno suggested, the problem is probably related with the build > > > taking too long. If you look at the first command being executed: > > > > > > > > mvn install -Pdistribution -DskipTests=true -B -V -q > > > > > > > > The -q option tells maven to run in quite mode and only show errors. > > > Even in my laptop, if I run the command above it takes a bit more time > to > > > show any output (not too long, but more than usual). That may explain > that > > > message from Travis. > > > > > > > > Maybe we should remove -q and just log everything. That could make > the > > > builds more stable. > > > > > > > > I've forced a new build to your https://github.com/keycloak/ > > > keycloak/pull/3079 (without changing anything to .travis.yml). Now it > is > > > running. > > > > > > > > ----- Original Message ----- > > > > From: "Bill Burke" > > > > To: "Pedro Igor Silva" , "Bruno Oliveira" < > > > bruno at abstractj.org> > > > > Cc: "keycloak-dev" > > > > Sent: Wednesday, July 27, 2016 8:53:16 PM > > > > Subject: Re: [keycloak-dev] travis seems to be down > > > > > > > > Wrong... :( I still get this problem. > > > > > > > > > > > > On 7/27/16 7:02 PM, Pedro Igor Silva wrote: > > > > > I think Travis decided to not mess with Bill :) > > > > > > > > > > ----- Original Message ----- > > > > > From: "Bruno Oliveira" > > > > > To: "Pedro Igor Silva" > > > > > Cc: "Bill Burke" , "keycloak-dev" < > > > keycloak-dev at lists.jboss.org> > > > > > Sent: Wednesday, July 27, 2016 6:37:44 PM > > > > > Subject: Re: [keycloak-dev] travis seems to be down > > > > > > > > > > Seems like the balance of the Force was established again. > > > > > > > > > > On 2016-07-27, Pedro Igor Silva wrote: > > > > >> Got that error, but now the build was successful. > > > > >> > > > > >> ----- Original Message ----- > > > > >> From: "Bruno Oliveira" > > > > >> To: "Bill Burke" > > > > >> Cc: "keycloak-dev" > > > > >> Sent: Wednesday, July 27, 2016 6:01:47 PM > > > > >> Subject: Re: [keycloak-dev] travis seems to be down > > > > >> > > > > >> Seems like they are fully operational[1]. I believe that this is > the > > > > >> reason: > > > > >> > > > > >> "No output has been received in the last 10 minutes, this > potentially > > > indicates a stalled build or something wrong with the build itself." > > > > >> > > > > >> Based on my previous experiences, it happens when the build takes > too > > > > >> long. Not really sure if that's the root cause, but I can help > > > > >> investigating it. > > > > >> > > > > >> [1] - https://www.traviscistatus.com/ > > > > >> > > > > >> On 2016-07-27, Bill Burke wrote: > > > > >>> A lot of builds failing in initial setup > > > > >>> > > > > >>> > > > > >>> Bill > > > > >>> > > > > >>> _______________________________________________ > > > > >>> keycloak-dev mailing list > > > > >>> keycloak-dev at lists.jboss.org > > > > >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > > >> -- > > > > >> > > > > >> abstractj > > > > >> PGP: 0x84DC9914 > > > > >> _______________________________________________ > > > > >> keycloak-dev mailing list > > > > >> keycloak-dev at lists.jboss.org > > > > >> https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > > > -- > > > > > > > > > > abstractj > > > > > PGP: 0x84DC9914 > > > > > > > > > > -- > > > > > > abstractj > > > PGP: 0x84DC9914 > > > _______________________________________________ > > > keycloak-dev mailing list > > > keycloak-dev at lists.jboss.org > > > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > > > -- > > abstractj > PGP: 0x84DC9914 > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160817/57143a97/attachment.html From sthorger at redhat.com Wed Aug 17 03:08:22 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Wed, 17 Aug 2016 09:08:22 +0200 Subject: [keycloak-dev] combine proxy and keycloak server In-Reply-To: <0317b095-37e6-6912-80f0-2ddc29bebb4b@redhat.com> References: <2cc29814-7e14-d55d-ec62-4f0b664dee40@redhat.com> <8c754e69-3a46-fe86-2c61-26ab12840f4a@redhat.com> <0317b095-37e6-6912-80f0-2ddc29bebb4b@redhat.com> Message-ID: On 16 August 2016 at 22:43, Bill Burke wrote: > > > On 8/16/16 3:10 AM, Stian Thorgersen wrote: > > You'll end up with another "protocol" to do this, which is additional > maintenance and testing and more importantly a new potential vector for > vulnerabilities. Not great IMO. > > > Protocol? You mean like AJP? BTW, making an argument not to have a > feature because of maintenance and testing is a really lame reason. Anybody > can basically just use that argument for anything they don't like. > I thought you where stating it shouldn't use OIDC or SAML. So it'll need to be something else right? IMO we should leverage OIDC and SAML and not come up with yet another way to do the same thing. I'm sorry, but it's not a lame reason at all to argue the time and complexity of implementing and maintaining something. That should always be taken into consideration. Just for argument sake if it took 5 man-years to implement, test and maintain what you are proposing (I'm not saying that it will, but I'm exaggerating to prove a point) and it exposed us to thousands of vulnerabilities (again, I'm exaggerating) would that not be a good enough reason not to do it? > > > What you are describing around having dedicated nodes for the proxy > operations just sounds more complex than having completely separate servers > completely. For high performance I'd imagine the proxy would end up with > having quite different needs for configuration than the Keycloak server as > well. > > Not really. You just specify a DNS entry that points to one of your > Keycloak nodes that is designated as the proxy. You ahve to do that > anyways. > > As far as config goes, if the proxy needs to be configured differently, we > just provide an extra domain.xml profile like we do for the example > load-balancer that is described in the docs. > So you have one group of Keycloak servers acting as a proxy with some special config, then another group of Keycloak servers acting as regular KC servers with yet another config. Then you have different DNS settings depending on what app it is. Etc. etc.. How is that simpler than just using the Keycloak proxy we have today with a separate KC server? A lot of tweaking goes into creating a proxy that works fast and with the minimum latency. Just talk to the APIMan guys. I believe they have much better performance on Vert.x than they have on Undertow as well. > > > There's also plenty of options around proxies (Apache, nginx, APIMan, > 3scale, etc.). I'm not convinced we should even have our own. Sounds like > APIMan might actually survive and end up being supported in some form, so > that may still be a better option to us rolling our own proxy/gateway. > > Disagree 100%. Right now without a supported proxy we have zero control > over how other languages and environments integrate with Keycloak (except > Java). We're at the mercy of mod-auth-mellon and mod-auth-openidc the > latter of which isn't even maintained by RHT. Both of which we do not have > any in house knowledge to make extensions to. The potential to simplify > and unify setup and configuration and management is just too huge here to > ignore. > Apache and nginx as proxies are what folks use and already have in place. Having yet another proxy in the mix doesn't really simplify things IMO. An alternative to making life easier would be to make it easier to use Apache and nginx rather than reinvent the wheel and create our own. > > But, we're arguing over something that nobody has time to work on anyways > :) > Arguing (or discussing...) might end up in it becoming a high priority in which case we would find someone ;) > > > Bill > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160817/406853d1/attachment-0001.html From sthorger at redhat.com Wed Aug 17 03:41:55 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Wed, 17 Aug 2016 09:41:55 +0200 Subject: [keycloak-dev] Docker Protocol? In-Reply-To: References: Message-ID: We could have it included in KC, but disabled by default. Having the ability to enable/disable features is something we need in either case. Especially for product as we'd like to have certain community only features (or tech preview features) disabled by default to make it obvious to customers they are using unsupported features. We'd need to figure out some way to automate testing of it though. We obviously can't manually test with Docker on a regular basis. Do you have any plans around how to test it? On 16 August 2016 at 21:24, Josh Cain wrote: > Couldn't agree more that Docker should use an existing/standards-based > auth protocol. Problem is, we need our Keycloak IDP to start talking to > docker registries. Since we have a hard requirement to talk to docker > registries, our IDP has to speak docker auth. There are already a number > of Docker registry authorization servers out there, so there seems to be a > need out there in the community as well. > > We're going to develop one and push it out such that it's publicly > accessible in any case, I was just curious as to whether the dev team would > want to incorporate this into the product. > > > Josh Cain | Software Applications Engineer > *Identity and Access Management* > *Red Hat* > +1 256-452-0150 > > On Tue, Aug 16, 2016 at 4:19 AM, Stian Thorgersen > wrote: > >> I'm not sure we'd like to have a Docker registry specific protocol added >> directly to Keycloak. Seems like Docker registry should rather get their >> act together and comply with existing protocols rather than invent their >> own. >> >> We did have an idea of creating some repository for extensions. These >> would be community maintained, not included in product and wouldn't receive >> the same level of testing. Maybe that would be a good place for this. With >> Bills recent deployer work it could be easier to allow users to deploy >> custom extensions as well. >> >> On 15 August 2016 at 16:41, Josh Cain wrote: >> >>> Hi Stian, >>> >>> Docker's auth V2 (docs link above) is Oauth-ish, but doesn't seem to >>> conform 100% to the specification. I started by just trying to stand up an >>> OIDC endpoint to talk to docker and Keycloak threw a "Missing parameters: >>> response_type" error. Turns out, Docker sends the GET request like this: >>> >>> /auth/realms/redhat-external/protocol/docker-v2/auth?account >>> =jcain&scope=repository%3Acentos%3Apull&service=docker-registry >>> >>> Not only is the request missing the request_typer paremeter, but Docker >>> uses different nomenclature than the OAuth/OIDC standard. For instance, I >>> would expect the 'service' param to appear as the client_id param to >>> conform to the OAuth spec. >>> >>> Since it uses different nomenclature, I thought it would be a much >>> cleaner implementation to just implement it as its own protocol. Didn't >>> want to muddy up a clean OIDC/OAuth implemention. >>> >>> Are there workarounds to deal with these differences that I'm missing? >>> >>> >>> Josh Cain | Software Applications Engineer >>> *Identity and Access Management* >>> *Red Hat* >>> +1 843-737-1735 >>> >>> On Mon, Aug 15, 2016 at 5:56 AM, Stian Thorgersen >>> wrote: >>> >>>> I'm not sure I fully understand. Are you using a Docker client to >>>> authenticate with Keycloak? That works with the standard OIDC flows, but it >>>> requires some additional claims in the token which you are adding with a >>>> protocol mapper? >>>> >>>> On 12 August 2016 at 15:31, Josh Cain wrote: >>>> >>>>> Hi All, >>>>> >>>>> We want to use Keycloak as the IDP/Token issuer for authentication >>>>> with a docker registry as per the specification found here: >>>>> >>>>> https://docs.docker.com/registry/spec/auth/ >>>>> >>>>> I've implemented a Protocol Mapper in Keycloak that successfully uses >>>>> the IDP to perform a login against a registry/docker client. Is this >>>>> something that the team is interested in building into the product? If so, >>>>> I'd be happy to push back upstream. >>>>> >>>>> Josh Cain | Software Applications Engineer >>>>> *Identity and Access Management* >>>>> *Red Hat* >>>>> +1 843-737-1735 >>>>> >>>>> _______________________________________________ >>>>> keycloak-dev mailing list >>>>> keycloak-dev at lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>>>> >>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160817/29ed2a1c/attachment.html From sthorger at redhat.com Wed Aug 17 03:44:43 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Wed, 17 Aug 2016 09:44:43 +0200 Subject: [keycloak-dev] Preferred storage mechanism for custom settings In-Reply-To: <1471374383.480.4.camel@cargosoft.ru> References: <1468323778.4229.4.camel@cargosoft.ru> <1468607337.4292.5.camel@cargosoft.ru> <1468874146.6797.11.camel@cargosoft.ru> <1471099636.5196.11.camel@cargosoft.ru> <1471374383.480.4.camel@cargosoft.ru> Message-ID: Take a look at ClientAdapter/ClientEntity. The ClientEntity for Mongo just returns the list, while the ClientAdapter does the rest. On 16 August 2016 at 21:06, Dmitry Telegin wrote: > Hi, > > I've started implementing attributes for Mongo. I've begun with adding > attribute methods to org.keycloak.models.entities.RealmEntity (base class > for MongoRealmEntity), but ended up with the following: > > java.lang.IllegalArgumentException: Invalid accessor method, must have zero arguments if starts with 'get'. Method: public java.lang.String org.keycloak.models.entities.RealmEntity.getAttribute(java.lang.String) > > at org.keycloak.models.utils.reflection.MethodPropertyImpl.(MethodPropertyImpl.java:53) > > at org.keycloak.models.utils.reflection.Properties.createProperty(Properties.java:44) > > at org.keycloak.models.utils.reflection.PropertyQuery.getResultList(PropertyQuery.java:168) > > at org.keycloak.models.utils.reflection.PropertyQuery.getWritableResultList(PropertyQuery.java:140) > > at org.keycloak.connections.mongo.impl.MongoStoreImpl.getEntityInfo(MongoStoreImpl.java:433) > > at org.keycloak.connections.mongo.impl.MongoStoreImpl.(MongoStoreImpl.java:101) > > at org.keycloak.connections.mongo.DefaultMongoConnectionFactoryProvider.lazyInit(DefaultMongoConnectionFactoryProvider.java:156) > > > Seems like KeyCloak's query system doesn't like entities with > pseudo-getter methods. Any suggestions? > > Dmitry > > Sounds like you're on the right track. You'd need to implement support for > Mongo as well though as we can't accept it otherwise. > > With regards to tests I'd add to org.keycloak.testsuite.admin.realm.RealmTest > which would also make sure attributes work correctly when added through the > admin endpoints. > > On 13 August 2016 at 16:47, Dmitry Telegin wrote: > > Hi, > > (As Stian is on vacation now, I'd appreciate if someone other helps me > with this feature.) > > Please take a look https://github.com/keycloak/keycloak/compare/2.1.0. > Final...cargosoft:KEYCLOAK-3327 > > (it has been branched off 2.1.0.Final for the ease of testing, I'll rebase > it onto master if needed) > > o.k.models.RealmModel: added methods (borrowed signatures from > jpa.RealmAdapter) > o.k.models.jpa.RealmAdapter: added @Override annotations > o.k.models.mongo.keycloak.adapters.RealmAdapter: added stubs (throwing > UnsupportedOperationException) > o.k.models.cache.infinispan.RealmAdapter: added attributes caching logic > o.k.models.cache.infinispan.entities.CachedRealm: added attributes cache > (as Map) > > As for tests, I'm afraid I'll need some guidance. > org.keycloak.testsuite.model.ModelTest seems appropriate for that; but it > will need support for attributes in RealmRepresentation and RealmManager. > Is this the right direction? > > Dmitry > > > > On 18 July 2016 at 22:35, Dmitry Telegin wrote: > > Stian, > > Here we go: https://issues.jboss.org/browse/KEYCLOAK-3327 > > If the fix is somewhat trivial (i.e. a matter of adding fields and > getters/setters) I think I could work on a PR as well. > > > As the attributes are already available in the underlying entities it's > just a matter of exposing through RealmModel and add tests for it. > > > > BTW, does this mean that all the custom entities provided via Entity SPI > are not by default cache-enabled (and won't be synchronized between the > nodes in clustered environment)? > If so, will it be easy to cache-enable them? Is this just a matter of > providing Infinispan adapters similar to existing ones for > Realm/User/Role/Client etc.? > > > There's no caching for custom entities. I'd recommend using Hibernate 2nd > level cache for it as it's rather tricky to create a custom one. We have > our custom one because we need to support Mongo as well as users from > different sources (user federation and identity brokering). > > > > Ideally, I'd like to see a current domain-extension example augmented with > Infinispan cache functionality. I've got some ideas on a detailed > walkthrough tutorial for building complete, full-featured KeyCloak > extensions (it's a big topic I'll elaborate on a bit later); I think > Infinispan-enabled entities could be covered there, too. > > > No chance we're adding cache for custom entities. It's just to hard to get > right. For custom entities you should use Hibernate 2nd level cache. > > > > Regards, > Dmitry > > ? ??, 18/07/2016 ? 07:39 +0200, Stian Thorgersen ?????: > > Forgot that attributes are not exposed through RealmModel. You can't > access the JPA RealmAdapter directly as you'll break the cache > functionality. You can create a JIRA to request attributes added to > RealmModel though. > > On 15 July 2016 at 20:28, Mitya wrote: > > Stian, > > In my provider, session.getContext().getRealm() returns an instance > of org.keycloak.models.cache.infinispan.RealmAdapter. But in order to be > able to manage attributes, we need an org.keycloak.models.jpa.RealmAdapter. > What's the best way to obtain it? > > I've yet come up with the following: > > RealmModel realm = session.getContext().getRealm(); > RealmAdapter adapter = (RealmAdapter) session.getProvider(RealmProvi > der.class).getRealm(realm.getId()); > > > Realm attributes should be perfect for that > > On 12 July 2016 at 13:42, Mitya wrote: > > Hi, > > I'm developing a KeyCloak extension, and I want some custom (per-realm) > parameters to be tuned via the GUI form. Speaking of the storage mechanism > for my settings, are realm attributes suitable for that? or should I create > a dedicated custom entity instead? > > Thx, > Mitya > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160817/dc6c51c7/attachment-0001.html From bburke at redhat.com Wed Aug 17 08:56:00 2016 From: bburke at redhat.com (Bill Burke) Date: Wed, 17 Aug 2016 08:56:00 -0400 Subject: [keycloak-dev] Docker Protocol? In-Reply-To: References: Message-ID: <7e296080-8b29-d70c-e397-376146f023c7@redhat.com> Can't you just have "enabled": false in keycloak-server.json for that provider? On 8/17/16 3:41 AM, Stian Thorgersen wrote: > We could have it included in KC, but disabled by default. Having the > ability to enable/disable features is something we need in either > case. Especially for product as we'd like to have certain community > only features (or tech preview features) disabled by default to make > it obvious to customers they are using unsupported features. > > We'd need to figure out some way to automate testing of it though. We > obviously can't manually test with Docker on a regular basis. Do you > have any plans around how to test it? > > On 16 August 2016 at 21:24, Josh Cain > wrote: > > Couldn't agree more that Docker should use an > existing/standards-based auth protocol. Problem is, we need our > Keycloak IDP to start talking to docker registries. Since we have > a hard requirement to talk to docker registries, our IDP has to > speak docker auth. There are already a number of Docker registry > authorization servers out there, so there seems to be a need out > there in the community as well. > > We're going to develop one and push it out such that it's publicly > accessible in any case, I was just curious as to whether the dev > team would want to incorporate this into the product. > > > Josh Cain | Software Applications Engineer > /Identity and Access Management/ > *Red Hat* > +1 256-452-0150 > > On Tue, Aug 16, 2016 at 4:19 AM, Stian Thorgersen > > wrote: > > I'm not sure we'd like to have a Docker registry specific > protocol added directly to Keycloak. Seems like Docker > registry should rather get their act together and comply with > existing protocols rather than invent their own. > > We did have an idea of creating some repository for > extensions. These would be community maintained, not included > in product and wouldn't receive the same level of testing. > Maybe that would be a good place for this. With Bills recent > deployer work it could be easier to allow users to deploy > custom extensions as well. > > On 15 August 2016 at 16:41, Josh Cain > wrote: > > Hi Stian, > > Docker's auth V2 (docs link above) is Oauth-ish, but > doesn't seem to conform 100% to the specification. I > started by just trying to stand up an OIDC endpoint to > talk to docker and Keycloak threw a "Missing parameters: > response_type" error. Turns out, Docker sends the GET > request like this: > > /auth/realms/redhat-external/protocol/docker-v2/auth?account=jcain&scope=repository%3Acentos%3Apull&service=docker-registry > > Not only is the request missing the request_typer > paremeter, but Docker uses different nomenclature than the > OAuth/OIDC standard. For instance, I would expect the > 'service' param to appear as the client_id param to > conform to the OAuth spec. > > Since it uses different nomenclature, I thought it would > be a much cleaner implementation to just implement it as > its own protocol. Didn't want to muddy up a clean > OIDC/OAuth implemention. > > Are there workarounds to deal with these differences that > I'm missing? > > > Josh Cain | Software Applications Engineer > /Identity and Access Management/ > *Red Hat* > +1 843-737-1735 > > On Mon, Aug 15, 2016 at 5:56 AM, Stian Thorgersen > > wrote: > > I'm not sure I fully understand. Are you using a > Docker client to authenticate with Keycloak? That > works with the standard OIDC flows, but it requires > some additional claims in the token which you are > adding with a protocol mapper? > > On 12 August 2016 at 15:31, Josh Cain > > > wrote: > > Hi All, > > We want to use Keycloak as the IDP/Token issuer > for authentication with a docker registry as per > the specification found here: > > https://docs.docker.com/registry/spec/auth/ > > > I've implemented a Protocol Mapper in Keycloak > that successfully uses the IDP to perform a login > against a registry/docker client. Is this > something that the team is interested in building > into the product? If so, I'd be happy to push > back upstream. > > Josh Cain | Software Applications Engineer > /Identity and Access Management/ > *Red Hat* > +1 843-737-1735 > > _______________________________________________ > 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160817/16f0252e/attachment.html From martin.hardselius at gmail.com Wed Aug 17 09:59:35 2016 From: martin.hardselius at gmail.com (Martin Hardselius) Date: Wed, 17 Aug 2016 13:59:35 +0000 Subject: [keycloak-dev] Pairwise Subject Identifier In-Reply-To: References: <57AC9686.5040807@redhat.com> Message-ID: I'm going to bump this, as I want to continue the discussion/provide some input. Does it make sense to support more than type of pairwise subject identifier generator? E.g through a PairwiseSubGeneratorSpi? Let's say I want to generate the pairwise sub as a salted hash: sub = SHA-256( sector_identifier || local_sub || salt ) To me, it makes sense to allow for per-client salts. These salts should probably be generated and persisted during client creation. Thoughts? On Fri, 12 Aug 2016 at 09:57 Martin Hardselius wrote: > Thank you for your response. Did not see that ticket before. Great news! > > I looked into using protocol mappers to achieve this, and while it would > work I'm worried that once KEYCLOAK-3422 has been resolved and included in > a proper release we would run into migration issues if the method used for > calculating "native" pairwise subs is different from what we implement. > Clients could loose / be forced to re-register all their users if we decide > to switch. The example methods in the spec are just that. Examples. Maybe > the method/alg for computing the pairwise sub should be pluggable? > > -- > Martin > > On Thu, 11 Aug 2016 at 17:15 Marek Posolda wrote: > >> Sorry for late response. >> >> We have JIRA created for that. You can possibly add yourself as a >> watcher. See https://issues.jboss.org/browse/KEYCLOAK-3422 >> >> Maybe an alternative for you is to use protocolMappers. That should allow >> you to "construct" the token for particular client exactly how you want and >> also use the different value for "sub" claim. >> >> Another possibility is, to handle this on adapter side. We already have >> an adapter option "principal-attribute", which specifies that application >> will see the different attribute instead of "sub" as subject. For example >> when in appllication you call "httpServletRequest.getRemoteUser()" it will >> return "john" instead of "123456-unique-johns-uuid" . See >> https://keycloak.gitbooks.io/securing-client-applications-guide/content/v/2.1/topics/oidc/java/java-adapter-config.html >> >> Hopefully some of the options can be useful for you? >> >> Marek >> >> >> On 02/08/16 14:13, Martin Hardselius wrote: >> >> Me and my team are working towards getting Keycloak, customized for our >> needs, into production but we've identified the need for Pairwise Subject >> Identifiers as we don't want to expose internal user ids. >> >> Right now, the only subject_types_supported seems to be "public". Are >> there any near-future plans to include "pairwise"? Can we pitch in with a >> PR to make this happen as soon as possible? >> >> Links to relevant sections in the spec: >> >> http://openid.net/specs/openid-connect-core-1_0.html#SubjectIDTypes >> http://openid.net/specs/openid-connect-core-1_0.html#PairwiseAlg >> >> -- >> Martin >> >> >> _______________________________________________ >> keycloak-dev mailing listkeycloak-dev at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-dev >> >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160817/1b7ba765/attachment-0001.html From josh.cain at redhat.com Wed Aug 17 10:06:34 2016 From: josh.cain at redhat.com (Josh Cain) Date: Wed, 17 Aug 2016 09:06:34 -0500 Subject: [keycloak-dev] Docker Protocol? In-Reply-To: <7e296080-8b29-d70c-e397-376146f023c7@redhat.com> References: <7e296080-8b29-d70c-e397-376146f023c7@redhat.com> Message-ID: I've been in POC mode lately, so the cursory testing I've done has been limited to manual, high-level tests. I'd be happy to find a way to get some useful integrated test for this. Right now I'm using 3 things to test - a docker client, a docker registry, and the keycloak IDP. Should be able to automate the registry container start and there's a java library for docker clients that we can use. So automated integration testing looks possible, but I've not gone down that road just yet. Would certainly do so if this was going upstream to Keycloak proper. Josh Cain | Software Applications Engineer *Identity and Access Management* *Red Hat* +1 256-452-0150 On Wed, Aug 17, 2016 at 7:56 AM, Bill Burke wrote: > Can't you just have "enabled": false in keycloak-server.json for that > provider? > > On 8/17/16 3:41 AM, Stian Thorgersen wrote: > > We could have it included in KC, but disabled by default. Having the > ability to enable/disable features is something we need in either case. > Especially for product as we'd like to have certain community only features > (or tech preview features) disabled by default to make it obvious to > customers they are using unsupported features. > > We'd need to figure out some way to automate testing of it though. We > obviously can't manually test with Docker on a regular basis. Do you have > any plans around how to test it? > > On 16 August 2016 at 21:24, Josh Cain wrote: > >> Couldn't agree more that Docker should use an existing/standards-based >> auth protocol. Problem is, we need our Keycloak IDP to start talking to >> docker registries. Since we have a hard requirement to talk to docker >> registries, our IDP has to speak docker auth. There are already a number >> of Docker registry authorization servers out there, so there seems to be a >> need out there in the community as well. >> >> We're going to develop one and push it out such that it's publicly >> accessible in any case, I was just curious as to whether the dev team would >> want to incorporate this into the product. >> >> >> Josh Cain | Software Applications Engineer >> *Identity and Access Management* >> *Red Hat* >> +1 256-452-0150 <%2B1%20256-452-0150> >> >> On Tue, Aug 16, 2016 at 4:19 AM, Stian Thorgersen >> wrote: >> >>> I'm not sure we'd like to have a Docker registry specific protocol added >>> directly to Keycloak. Seems like Docker registry should rather get their >>> act together and comply with existing protocols rather than invent their >>> own. >>> >>> We did have an idea of creating some repository for extensions. These >>> would be community maintained, not included in product and wouldn't receive >>> the same level of testing. Maybe that would be a good place for this. With >>> Bills recent deployer work it could be easier to allow users to deploy >>> custom extensions as well. >>> >>> On 15 August 2016 at 16:41, Josh Cain wrote: >>> >>>> Hi Stian, >>>> >>>> Docker's auth V2 (docs link above) is Oauth-ish, but doesn't seem to >>>> conform 100% to the specification. I started by just trying to stand up an >>>> OIDC endpoint to talk to docker and Keycloak threw a "Missing parameters: >>>> response_type" error. Turns out, Docker sends the GET request like this: >>>> >>>> /auth/realms/redhat-external/protocol/docker-v2/auth?account >>>> =jcain&scope=repository%3Acentos%3Apull&service=docker-registry >>>> >>>> Not only is the request missing the request_typer paremeter, but Docker >>>> uses different nomenclature than the OAuth/OIDC standard. For instance, I >>>> would expect the 'service' param to appear as the client_id param to >>>> conform to the OAuth spec. >>>> >>>> Since it uses different nomenclature, I thought it would be a much >>>> cleaner implementation to just implement it as its own protocol. Didn't >>>> want to muddy up a clean OIDC/OAuth implemention. >>>> >>>> Are there workarounds to deal with these differences that I'm missing? >>>> >>>> >>>> Josh Cain | Software Applications Engineer >>>> *Identity and Access Management* >>>> *Red Hat* >>>> +1 843-737-1735 <%2B1%20843-737-1735> >>>> >>>> On Mon, Aug 15, 2016 at 5:56 AM, Stian Thorgersen >>>> wrote: >>>> >>>>> I'm not sure I fully understand. Are you using a Docker client to >>>>> authenticate with Keycloak? That works with the standard OIDC flows, but it >>>>> requires some additional claims in the token which you are adding with a >>>>> protocol mapper? >>>>> >>>>> On 12 August 2016 at 15:31, Josh Cain wrote: >>>>> >>>>>> Hi All, >>>>>> >>>>>> We want to use Keycloak as the IDP/Token issuer for authentication >>>>>> with a docker registry as per the specification found here: >>>>>> >>>>>> https://docs.docker.com/registry/spec/auth/ >>>>>> >>>>>> I've implemented a Protocol Mapper in Keycloak that successfully uses >>>>>> the IDP to perform a login against a registry/docker client. Is this >>>>>> something that the team is interested in building into the product? If so, >>>>>> I'd be happy to push back upstream. >>>>>> >>>>>> Josh Cain | Software Applications Engineer >>>>>> *Identity and Access Management* >>>>>> *Red Hat* >>>>>> +1 843-737-1735 <%2B1%20843-737-1735> >>>>>> >>>>>> _______________________________________________ >>>>>> keycloak-dev mailing list >>>>>> keycloak-dev at lists.jboss.org >>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>>>>> >>>>> >>>>> >>>> >>> >> > > > _______________________________________________ > keycloak-dev mailing listkeycloak-dev at lists.jboss.orghttps://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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160817/59b356fb/attachment.html From ssilvert at redhat.com Wed Aug 17 12:22:49 2016 From: ssilvert at redhat.com (Stan Silvert) Date: Wed, 17 Aug 2016 12:22:49 -0400 Subject: [keycloak-dev] Demo dist broken Message-ID: <57B48F59.5060300@redhat.com> I did a clean build from head. Unzipped demo dist and started up. Got this: 2016-08-17 12:16:08,126 INFO [org.keycloak.services] (ServerService Thread Pool -- 67) KC-SERVICES0001: Loading config from c:\kctemp\keycloak-demo-2.2.0-SNAPSHOT\keycloak\standalone\configuration\keycloak-server.json 2016-08-17 12:16:08,717 INFO [org.jboss.ws.common.management] (MSC service thread 1-1) JBWS022052: Starting JBossWS 5.1.3.Final (Apache CXF 3.1.4) 2016-08-17 12:16:12,615 WARN [org.keycloak.connections.jpa.updater.liquibase.lock.LiquibaseDBLockProvider] (ServerService Thread Pool -- 67) Failed to rollback connection after error: java.sql.SQLException: IJ031021: You cannot rollback during a managed transaction at org.jboss.jca.adapters.jdbc.BaseWrapperManagedConnection.jdbcRollback(BaseWrapperManagedConnection.java:1122) at org.jboss.jca.adapters.jdbc.WrappedConnection.rollback(WrappedConnection.java:863) at org.keycloak.connections.jpa.updater.liquibase.lock.LiquibaseDBLockProvider.safeRollbackConnection(LiquibaseDBLockProvider.java:159) at org.keycloak.connections.jpa.updater.liquibase.lock.LiquibaseDBLockProvider.waitForLock(LiquibaseDBLockProvider.java:109) at org.keycloak.services.resources.KeycloakApplication$1.run(KeycloakApplication.java:104) at org.keycloak.models.utils.KeycloakModelUtils.runJobInTransaction(KeycloakModelUtils.java:287) at org.keycloak.services.resources.KeycloakApplication.(KeycloakApplication.java:97) 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:422) at org.jboss.resteasy.core.ConstructorInjectorImpl.construct(ConstructorInjectorImpl.java:150) at org.jboss.resteasy.spi.ResteasyProviderFactory.createProviderInstance(ResteasyProviderFactory.java:2209) at org.jboss.resteasy.spi.ResteasyDeployment.createApplication(ResteasyDeployment.java:299) at org.jboss.resteasy.spi.ResteasyDeployment.start(ResteasyDeployment.java:240) at org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.init(ServletContainerDispatcher.java:113) at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.init(HttpServletDispatcher.java:36) at io.undertow.servlet.core.LifecyleInterceptorInvocation.proceed(LifecyleInterceptorInvocation.java:117) at org.wildfly.extension.undertow.security.RunAsLifecycleInterceptor.init(RunAsLifecycleInterceptor.java:78) at io.undertow.servlet.core.LifecyleInterceptorInvocation.proceed(LifecyleInterceptorInvocation.java:103) at io.undertow.servlet.core.ManagedServlet$DefaultInstanceStrategy.start(ManagedServlet.java:231) at io.undertow.servlet.core.ManagedServlet.createServlet(ManagedServlet.java:132) at io.undertow.servlet.core.DeploymentManagerImpl.start(DeploymentManagerImpl.java:526) at org.wildfly.extension.undertow.deployment.UndertowDeploymentService.startContext(UndertowDeploymentService.java:101) at org.wildfly.extension.undertow.deployment.UndertowDeploymentService$1.run(UndertowDeploymentService.java:82) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) at java.util.concurrent.FutureTask.run(FutureTask.java:266) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at java.lang.Thread.run(Thread.java:745) at org.jboss.threads.JBossThread.run(JBossThread.java:320) 2016-08-17 12:16:12,623 ERROR [org.jboss.as.txn] (ServerService Thread Pool -- 67) WFLYTX0003: APPLICATION ERROR: transaction still active in request with status 4 2016-08-17 12:16:12,624 WARN [com.arjuna.ats.arjuna] (ServerService Thread Pool -- 67) ARJUNA012077: Abort called on already aborted atomic action 0:ffff0a0a3838:-30eee89c:57b48dc5:b 2016-08-17 12:16:12,625 ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 67) MSC000001: Failed to start service jboss.undertow.deployment.default-server.default-host./auth: org.jboss.msc.service.StartException in service jboss.undertow.deployment.default-server.default-host./auth: java.lang.RuntimeException: RESTEASY003325: Failed to construct public org.keycloak.services.resources.KeycloakApplication(javax.servlet.ServletContext,org.jboss.resteasy.core.Dispatcher) at org.wildfly.extension.undertow.deployment.UndertowDeploymentService$1.run(UndertowDeploymentService.java:85) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) at java.util.concurrent.FutureTask.run(FutureTask.java:266) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at java.lang.Thread.run(Thread.java:745) at org.jboss.threads.JBossThread.run(JBossThread.java:320) Caused by: java.lang.RuntimeException: RESTEASY003325: Failed to construct public org.keycloak.services.resources.KeycloakApplication(javax.servlet.ServletContext,org.jboss.resteasy.core.Dispatcher) at org.jboss.resteasy.core.ConstructorInjectorImpl.construct(ConstructorInjectorImpl.java:162) at org.jboss.resteasy.spi.ResteasyProviderFactory.createProviderInstance(ResteasyProviderFactory.java:2209) at org.jboss.resteasy.spi.ResteasyDeployment.createApplication(ResteasyDeployment.java:299) at org.jboss.resteasy.spi.ResteasyDeployment.start(ResteasyDeployment.java:240) at org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.init(ServletContainerDispatcher.java:113) at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.init(HttpServletDispatcher.java:36) at io.undertow.servlet.core.LifecyleInterceptorInvocation.proceed(LifecyleInterceptorInvocation.java:117) at org.wildfly.extension.undertow.security.RunAsLifecycleInterceptor.init(RunAsLifecycleInterceptor.java:78) at io.undertow.servlet.core.LifecyleInterceptorInvocation.proceed(LifecyleInterceptorInvocation.java:103) at io.undertow.servlet.core.ManagedServlet$DefaultInstanceStrategy.start(ManagedServlet.java:231) at io.undertow.servlet.core.ManagedServlet.createServlet(ManagedServlet.java:132) at io.undertow.servlet.core.DeploymentManagerImpl.start(DeploymentManagerImpl.java:526) at org.wildfly.extension.undertow.deployment.UndertowDeploymentService.startContext(UndertowDeploymentService.java:101) at org.wildfly.extension.undertow.deployment.UndertowDeploymentService$1.run(UndertowDeploymentService.java:82) ... 6 more Caused by: java.lang.IllegalStateException: Failed to retrieve lock at org.keycloak.connections.jpa.updater.liquibase.lock.CustomLockService.acquireLock(CustomLockService.java:157) at org.keycloak.connections.jpa.updater.liquibase.lock.CustomLockService.waitForLock(CustomLockService.java:123) at org.keycloak.connections.jpa.updater.liquibase.lock.LiquibaseDBLockProvider.waitForLock(LiquibaseDBLockProvider.java:99) at org.keycloak.services.resources.KeycloakApplication$1.run(KeycloakApplication.java:104) at org.keycloak.models.utils.KeycloakModelUtils.runJobInTransaction(KeycloakModelUtils.java:287) at org.keycloak.services.resources.KeycloakApplication.(KeycloakApplication.java:97) 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:422) at org.jboss.resteasy.core.ConstructorInjectorImpl.construct(ConstructorInjectorImpl.java:150) ... 19 more Caused by: liquibase.exception.DatabaseException: liquibase.exception.DatabaseException: java.sql.SQLException: IJ031021: You cannot rollback during a managed transaction at liquibase.database.AbstractJdbcDatabase.rollback(AbstractJdbcDatabase.java:1139) at org.keycloak.connections.jpa.updater.liquibase.lock.CustomLockService.acquireLock(CustomLockService.java:152) ... 29 more Caused by: liquibase.exception.DatabaseException: java.sql.SQLException: IJ031021: You cannot rollback during a managed transaction at liquibase.database.jvm.JdbcConnection.rollback(JdbcConnection.java:340) at liquibase.database.AbstractJdbcDatabase.rollback(AbstractJdbcDatabase.java:1137) ... 30 more Caused by: java.sql.SQLException: IJ031021: You cannot rollback during a managed transaction at org.jboss.jca.adapters.jdbc.BaseWrapperManagedConnection.jdbcRollback(BaseWrapperManagedConnection.java:1122) at org.jboss.jca.adapters.jdbc.WrappedConnection.rollback(WrappedConnection.java:863) at liquibase.database.jvm.JdbcConnection.rollback(JdbcConnection.java:337) ... 31 more 2016-08-17 12:16:12,635 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([("deployment" => "keycloak-server.war")]) - failure description: {"WFLYCTL0080: Failed services" => {"jboss.undertow.deployment.default-server.default-host./auth" => "org.jboss.msc.service.StartException in service jboss.undertow.deployment.default-server.default-host./auth: java.lang.RuntimeException: RESTEASY003325: Failed to construct public org.keycloak.services.resources.KeycloakApplication(javax.servlet.ServletContext,org.jboss.resteasy.core.Dispatcher) Caused by: java.lang.RuntimeException: RESTEASY003325: Failed to construct public org.keycloak.services.resources.KeycloakApplication(javax.servlet.ServletContext,org.jboss.resteasy.core.Dispatcher) Caused by: java.lang.IllegalStateException: Failed to retrieve lock Caused by: liquibase.exception.DatabaseException: liquibase.exception.DatabaseException: java.sql.SQLException: IJ031021: You cannot rollback during a managed transaction Caused by: liquibase.exception.DatabaseException: java.sql.SQLException: IJ031021: You cannot rollback during a managed transaction Caused by: java.sql.SQLException: IJ031021: You cannot rollback during a managed transaction"}} 2016-08-17 12:16:12,661 INFO [org.jboss.as.server] (ServerService Thread Pool -- 61) WFLYSRV0010: Deployed "keycloak-server.war" (runtime-name : "keycloak-server.war") 2016-08-17 12:16:12,663 INFO [org.jboss.as.controller] (Controller Boot Thread) WFLYCTL0183: Service status report WFLYCTL0186: Services which failed to start: service jboss.undertow.deployment.default-server.default-host./auth: org.jboss.msc.service.StartException in service jboss.undertow.deployment.default-server.default-host./auth: java.lang.RuntimeException: RESTEASY003325: Failed to construct public org.keycloak.services.resources.KeycloakApplication(javax.servlet.ServletContext,org.jboss.resteasy.core.Dispatcher) 2016-08-17 12:16:12,745 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0060: Http management interface listening on http://127.0.0.1:9990/management 2016-08-17 12:16:12,746 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0051: Admin console listening on http://127.0.0.1:9990 2016-08-17 12:16:12,746 ERROR [org.jboss.as] (Controller Boot Thread) WFLYSRV0026: WildFly Full 10.0.0.Final (WildFly Core 2.0.10.Final) started (with errors) in 24670ms - Started 429 of 785 services (2 services failed or missing dependencies, 513 services are lazy, passive or on-demand) 2016-08-17 12:19:32,948 INFO [org.jboss.as.server] (Thread-2) WFLYSRV0220: Server shutdown has been requested. 2016-08-17 12:19:32,977 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-1) WFLYJCA0010: Unbound data source [java:jboss/datasources/KeycloakDS] 2016-08-17 12:19:32,984 INFO [org.wildfly.extension.undertow] (MSC service thread 1-3) WFLYUT0019: Host default-host stopping 2016-08-17 12:19:32,994 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-8) WFLYJCA0010: Unbound data source [java:jboss/datasources/ExampleDS] 2016-08-17 12:19:32,999 INFO [org.jboss.as.connector.deployers.jdbc] (MSC service thread 1-8) WFLYJCA0019: Stopped Driver service with driver-name = h2 2016-08-17 12:19:33,005 INFO [org.wildfly.extension.undertow] (MSC service thread 1-8) WFLYUT0008: Undertow HTTP listener default suspending 2016-08-17 12:19:33,006 INFO [org.wildfly.extension.undertow] (MSC service thread 1-8) WFLYUT0007: Undertow HTTP listener default stopped, was bound to 127.0.0.1:8080 2016-08-17 12:19:33,007 INFO [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 76) WFLYCLINF0003: Stopped offlineSessions cache from keycloak container 2016-08-17 12:19:33,007 INFO [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 73) WFLYCLINF0003: Stopped sessions cache from keycloak container 2016-08-17 12:19:33,013 INFO [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 77) WFLYCLINF0003: Stopped authorization cache from keycloak container 2016-08-17 12:19:33,014 INFO [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 78) WFLYCLINF0003: Stopped realms cache from keycloak container 2016-08-17 12:19:33,015 INFO [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 74) WFLYCLINF0003: Stopped loginFailures cache from keycloak container 2016-08-17 12:19:33,016 INFO [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 79) WFLYCLINF0003: Stopped work cache from keycloak container 2016-08-17 12:19:33,016 INFO [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 75) WFLYCLINF0003: Stopped users cache from keycloak container 2016-08-17 12:19:33,024 INFO [org.wildfly.extension.undertow] (MSC service thread 1-8) WFLYUT0004: Undertow 1.3.15.Final stopping 2016-08-17 12:19:33,029 INFO [org.hibernate.validator.internal.util.Version] (MSC service thread 1-2) HV000001: Hibernate Validator 5.2.3.Final 2016-08-17 12:19:33,083 INFO [org.jboss.as.server.deployment] (MSC service thread 1-7) WFLYSRV0028: Stopped deployment keycloak-server.war (runtime-name: keycloak-server.war) in 126ms 2016-08-17 12:19:33,086 INFO [org.jboss.as] (MSC service thread 1-6) WFLYSRV0050: WildFly Full 10.0.0.Final (WildFly Core 2.0.10.Final) stopped in 115ms From bburke at redhat.com Wed Aug 17 12:59:16 2016 From: bburke at redhat.com (Bill Burke) Date: Wed, 17 Aug 2016 12:59:16 -0400 Subject: [keycloak-dev] Demo dist broken In-Reply-To: <57B48F59.5060300@redhat.com> References: <57B48F59.5060300@redhat.com> Message-ID: <68e0f8d3-7676-5cab-b285-9b121bce0018@redhat.com> Gotta set jta=false for the datasource. Demo isn't built from server dist? On 8/17/16 12:22 PM, Stan Silvert wrote: > I did a clean build from head. Unzipped demo dist and started up. Got this: > > 2016-08-17 12:16:08,126 INFO [org.keycloak.services] (ServerService > Thread Pool -- 67) KC-SERVICES0001: Loading config from > c:\kctemp\keycloak-demo-2.2.0-SNAPSHOT\keycloak\standalone\configuration\keycloak-server.json > 2016-08-17 12:16:08,717 INFO [org.jboss.ws.common.management] (MSC > service thread 1-1) JBWS022052: Starting JBossWS 5.1.3.Final (Apache CXF > 3.1.4) > 2016-08-17 12:16:12,615 WARN > [org.keycloak.connections.jpa.updater.liquibase.lock.LiquibaseDBLockProvider] > (ServerService Thread Pool -- 67) Failed to rollback connection after > error: java.sql.SQLException: IJ031021: You cannot rollback during a > managed transaction > at > org.jboss.jca.adapters.jdbc.BaseWrapperManagedConnection.jdbcRollback(BaseWrapperManagedConnection.java:1122) > at > org.jboss.jca.adapters.jdbc.WrappedConnection.rollback(WrappedConnection.java:863) > at > org.keycloak.connections.jpa.updater.liquibase.lock.LiquibaseDBLockProvider.safeRollbackConnection(LiquibaseDBLockProvider.java:159) > at > org.keycloak.connections.jpa.updater.liquibase.lock.LiquibaseDBLockProvider.waitForLock(LiquibaseDBLockProvider.java:109) > at > org.keycloak.services.resources.KeycloakApplication$1.run(KeycloakApplication.java:104) > at > org.keycloak.models.utils.KeycloakModelUtils.runJobInTransaction(KeycloakModelUtils.java:287) > at > org.keycloak.services.resources.KeycloakApplication.(KeycloakApplication.java:97) > 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:422) > at > org.jboss.resteasy.core.ConstructorInjectorImpl.construct(ConstructorInjectorImpl.java:150) > at > org.jboss.resteasy.spi.ResteasyProviderFactory.createProviderInstance(ResteasyProviderFactory.java:2209) > at > org.jboss.resteasy.spi.ResteasyDeployment.createApplication(ResteasyDeployment.java:299) > at > org.jboss.resteasy.spi.ResteasyDeployment.start(ResteasyDeployment.java:240) > at > org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.init(ServletContainerDispatcher.java:113) > at > org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.init(HttpServletDispatcher.java:36) > at > io.undertow.servlet.core.LifecyleInterceptorInvocation.proceed(LifecyleInterceptorInvocation.java:117) > at > org.wildfly.extension.undertow.security.RunAsLifecycleInterceptor.init(RunAsLifecycleInterceptor.java:78) > at > io.undertow.servlet.core.LifecyleInterceptorInvocation.proceed(LifecyleInterceptorInvocation.java:103) > at > io.undertow.servlet.core.ManagedServlet$DefaultInstanceStrategy.start(ManagedServlet.java:231) > at > io.undertow.servlet.core.ManagedServlet.createServlet(ManagedServlet.java:132) > at > io.undertow.servlet.core.DeploymentManagerImpl.start(DeploymentManagerImpl.java:526) > at > org.wildfly.extension.undertow.deployment.UndertowDeploymentService.startContext(UndertowDeploymentService.java:101) > at > org.wildfly.extension.undertow.deployment.UndertowDeploymentService$1.run(UndertowDeploymentService.java:82) > at > java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) > at java.util.concurrent.FutureTask.run(FutureTask.java:266) > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at java.lang.Thread.run(Thread.java:745) > at org.jboss.threads.JBossThread.run(JBossThread.java:320) > > 2016-08-17 12:16:12,623 ERROR [org.jboss.as.txn] (ServerService Thread > Pool -- 67) WFLYTX0003: APPLICATION ERROR: transaction still active in > request with status 4 > 2016-08-17 12:16:12,624 WARN [com.arjuna.ats.arjuna] (ServerService > Thread Pool -- 67) ARJUNA012077: Abort called on already aborted atomic > action 0:ffff0a0a3838:-30eee89c:57b48dc5:b > 2016-08-17 12:16:12,625 ERROR [org.jboss.msc.service.fail] > (ServerService Thread Pool -- 67) MSC000001: Failed to start service > jboss.undertow.deployment.default-server.default-host./auth: > org.jboss.msc.service.StartException in service > jboss.undertow.deployment.default-server.default-host./auth: > java.lang.RuntimeException: RESTEASY003325: Failed to construct public > org.keycloak.services.resources.KeycloakApplication(javax.servlet.ServletContext,org.jboss.resteasy.core.Dispatcher) > at > org.wildfly.extension.undertow.deployment.UndertowDeploymentService$1.run(UndertowDeploymentService.java:85) > at > java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) > at java.util.concurrent.FutureTask.run(FutureTask.java:266) > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at java.lang.Thread.run(Thread.java:745) > at org.jboss.threads.JBossThread.run(JBossThread.java:320) > Caused by: java.lang.RuntimeException: RESTEASY003325: Failed to > construct public > org.keycloak.services.resources.KeycloakApplication(javax.servlet.ServletContext,org.jboss.resteasy.core.Dispatcher) > at > org.jboss.resteasy.core.ConstructorInjectorImpl.construct(ConstructorInjectorImpl.java:162) > at > org.jboss.resteasy.spi.ResteasyProviderFactory.createProviderInstance(ResteasyProviderFactory.java:2209) > at > org.jboss.resteasy.spi.ResteasyDeployment.createApplication(ResteasyDeployment.java:299) > at > org.jboss.resteasy.spi.ResteasyDeployment.start(ResteasyDeployment.java:240) > at > org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.init(ServletContainerDispatcher.java:113) > at > org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.init(HttpServletDispatcher.java:36) > at > io.undertow.servlet.core.LifecyleInterceptorInvocation.proceed(LifecyleInterceptorInvocation.java:117) > at > org.wildfly.extension.undertow.security.RunAsLifecycleInterceptor.init(RunAsLifecycleInterceptor.java:78) > at > io.undertow.servlet.core.LifecyleInterceptorInvocation.proceed(LifecyleInterceptorInvocation.java:103) > at > io.undertow.servlet.core.ManagedServlet$DefaultInstanceStrategy.start(ManagedServlet.java:231) > at > io.undertow.servlet.core.ManagedServlet.createServlet(ManagedServlet.java:132) > at > io.undertow.servlet.core.DeploymentManagerImpl.start(DeploymentManagerImpl.java:526) > at > org.wildfly.extension.undertow.deployment.UndertowDeploymentService.startContext(UndertowDeploymentService.java:101) > at > org.wildfly.extension.undertow.deployment.UndertowDeploymentService$1.run(UndertowDeploymentService.java:82) > ... 6 more > Caused by: java.lang.IllegalStateException: Failed to retrieve lock > at > org.keycloak.connections.jpa.updater.liquibase.lock.CustomLockService.acquireLock(CustomLockService.java:157) > at > org.keycloak.connections.jpa.updater.liquibase.lock.CustomLockService.waitForLock(CustomLockService.java:123) > at > org.keycloak.connections.jpa.updater.liquibase.lock.LiquibaseDBLockProvider.waitForLock(LiquibaseDBLockProvider.java:99) > at > org.keycloak.services.resources.KeycloakApplication$1.run(KeycloakApplication.java:104) > at > org.keycloak.models.utils.KeycloakModelUtils.runJobInTransaction(KeycloakModelUtils.java:287) > at > org.keycloak.services.resources.KeycloakApplication.(KeycloakApplication.java:97) > 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:422) > at > org.jboss.resteasy.core.ConstructorInjectorImpl.construct(ConstructorInjectorImpl.java:150) > ... 19 more > Caused by: liquibase.exception.DatabaseException: > liquibase.exception.DatabaseException: java.sql.SQLException: IJ031021: > You cannot rollback during a managed transaction > at > liquibase.database.AbstractJdbcDatabase.rollback(AbstractJdbcDatabase.java:1139) > at > org.keycloak.connections.jpa.updater.liquibase.lock.CustomLockService.acquireLock(CustomLockService.java:152) > ... 29 more > Caused by: liquibase.exception.DatabaseException: java.sql.SQLException: > IJ031021: You cannot rollback during a managed transaction > at > liquibase.database.jvm.JdbcConnection.rollback(JdbcConnection.java:340) > at > liquibase.database.AbstractJdbcDatabase.rollback(AbstractJdbcDatabase.java:1137) > ... 30 more > Caused by: java.sql.SQLException: IJ031021: You cannot rollback during a > managed transaction > at > org.jboss.jca.adapters.jdbc.BaseWrapperManagedConnection.jdbcRollback(BaseWrapperManagedConnection.java:1122) > at > org.jboss.jca.adapters.jdbc.WrappedConnection.rollback(WrappedConnection.java:863) > at > liquibase.database.jvm.JdbcConnection.rollback(JdbcConnection.java:337) > ... 31 more > > 2016-08-17 12:16:12,635 ERROR > [org.jboss.as.controller.management-operation] (Controller Boot Thread) > WFLYCTL0013: Operation ("add") failed - address: ([("deployment" => > "keycloak-server.war")]) - failure description: {"WFLYCTL0080: Failed > services" => > {"jboss.undertow.deployment.default-server.default-host./auth" => > "org.jboss.msc.service.StartException in service > jboss.undertow.deployment.default-server.default-host./auth: > java.lang.RuntimeException: RESTEASY003325: Failed to construct public > org.keycloak.services.resources.KeycloakApplication(javax.servlet.ServletContext,org.jboss.resteasy.core.Dispatcher) > Caused by: java.lang.RuntimeException: RESTEASY003325: Failed to > construct public > org.keycloak.services.resources.KeycloakApplication(javax.servlet.ServletContext,org.jboss.resteasy.core.Dispatcher) > Caused by: java.lang.IllegalStateException: Failed to retrieve lock > Caused by: liquibase.exception.DatabaseException: > liquibase.exception.DatabaseException: java.sql.SQLException: IJ031021: > You cannot rollback during a managed transaction > Caused by: liquibase.exception.DatabaseException: > java.sql.SQLException: IJ031021: You cannot rollback during a managed > transaction > Caused by: java.sql.SQLException: IJ031021: You cannot rollback > during a managed transaction"}} > 2016-08-17 12:16:12,661 INFO [org.jboss.as.server] (ServerService > Thread Pool -- 61) WFLYSRV0010: Deployed "keycloak-server.war" > (runtime-name : "keycloak-server.war") > 2016-08-17 12:16:12,663 INFO [org.jboss.as.controller] (Controller Boot > Thread) WFLYCTL0183: Service status report > WFLYCTL0186: Services which failed to start: service > jboss.undertow.deployment.default-server.default-host./auth: > org.jboss.msc.service.StartException in service > jboss.undertow.deployment.default-server.default-host./auth: > java.lang.RuntimeException: RESTEASY003325: Failed to construct public > org.keycloak.services.resources.KeycloakApplication(javax.servlet.ServletContext,org.jboss.resteasy.core.Dispatcher) > > 2016-08-17 12:16:12,745 INFO [org.jboss.as] (Controller Boot Thread) > WFLYSRV0060: Http management interface listening on > http://127.0.0.1:9990/management > 2016-08-17 12:16:12,746 INFO [org.jboss.as] (Controller Boot Thread) > WFLYSRV0051: Admin console listening on http://127.0.0.1:9990 > 2016-08-17 12:16:12,746 ERROR [org.jboss.as] (Controller Boot Thread) > WFLYSRV0026: WildFly Full 10.0.0.Final (WildFly Core 2.0.10.Final) > started (with errors) in 24670ms - Started 429 of 785 services (2 > services failed or missing dependencies, 513 services are lazy, passive > or on-demand) > 2016-08-17 12:19:32,948 INFO [org.jboss.as.server] (Thread-2) > WFLYSRV0220: Server shutdown has been requested. > 2016-08-17 12:19:32,977 INFO > [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-1) > WFLYJCA0010: Unbound data source [java:jboss/datasources/KeycloakDS] > 2016-08-17 12:19:32,984 INFO [org.wildfly.extension.undertow] (MSC > service thread 1-3) WFLYUT0019: Host default-host stopping > 2016-08-17 12:19:32,994 INFO > [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-8) > WFLYJCA0010: Unbound data source [java:jboss/datasources/ExampleDS] > 2016-08-17 12:19:32,999 INFO [org.jboss.as.connector.deployers.jdbc] > (MSC service thread 1-8) WFLYJCA0019: Stopped Driver service with > driver-name = h2 > 2016-08-17 12:19:33,005 INFO [org.wildfly.extension.undertow] (MSC > service thread 1-8) WFLYUT0008: Undertow HTTP listener default suspending > 2016-08-17 12:19:33,006 INFO [org.wildfly.extension.undertow] (MSC > service thread 1-8) WFLYUT0007: Undertow HTTP listener default stopped, > was bound to 127.0.0.1:8080 > 2016-08-17 12:19:33,007 INFO [org.jboss.as.clustering.infinispan] > (ServerService Thread Pool -- 76) WFLYCLINF0003: Stopped offlineSessions > cache from keycloak container > 2016-08-17 12:19:33,007 INFO [org.jboss.as.clustering.infinispan] > (ServerService Thread Pool -- 73) WFLYCLINF0003: Stopped sessions cache > from keycloak container > 2016-08-17 12:19:33,013 INFO [org.jboss.as.clustering.infinispan] > (ServerService Thread Pool -- 77) WFLYCLINF0003: Stopped authorization > cache from keycloak container > 2016-08-17 12:19:33,014 INFO [org.jboss.as.clustering.infinispan] > (ServerService Thread Pool -- 78) WFLYCLINF0003: Stopped realms cache > from keycloak container > 2016-08-17 12:19:33,015 INFO [org.jboss.as.clustering.infinispan] > (ServerService Thread Pool -- 74) WFLYCLINF0003: Stopped loginFailures > cache from keycloak container > 2016-08-17 12:19:33,016 INFO [org.jboss.as.clustering.infinispan] > (ServerService Thread Pool -- 79) WFLYCLINF0003: Stopped work cache from > keycloak container > 2016-08-17 12:19:33,016 INFO [org.jboss.as.clustering.infinispan] > (ServerService Thread Pool -- 75) WFLYCLINF0003: Stopped users cache > from keycloak container > 2016-08-17 12:19:33,024 INFO [org.wildfly.extension.undertow] (MSC > service thread 1-8) WFLYUT0004: Undertow 1.3.15.Final stopping > 2016-08-17 12:19:33,029 INFO > [org.hibernate.validator.internal.util.Version] (MSC service thread 1-2) > HV000001: Hibernate Validator 5.2.3.Final > 2016-08-17 12:19:33,083 INFO [org.jboss.as.server.deployment] (MSC > service thread 1-7) WFLYSRV0028: Stopped deployment keycloak-server.war > (runtime-name: keycloak-server.war) in 126ms > 2016-08-17 12:19:33,086 INFO [org.jboss.as] (MSC service thread 1-6) > WFLYSRV0050: WildFly Full 10.0.0.Final (WildFly Core 2.0.10.Final) > stopped in 115ms > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev From ssilvert at redhat.com Wed Aug 17 13:07:05 2016 From: ssilvert at redhat.com (Stan Silvert) Date: Wed, 17 Aug 2016 13:07:05 -0400 Subject: [keycloak-dev] Demo dist broken In-Reply-To: <68e0f8d3-7676-5cab-b285-9b121bce0018@redhat.com> References: <57B48F59.5060300@redhat.com> <68e0f8d3-7676-5cab-b285-9b121bce0018@redhat.com> Message-ID: <57B499B9.5000309@redhat.com> On 8/17/2016 12:59 PM, Bill Burke wrote: > Gotta set jta=false for the datasource. Demo isn't built from server dist? No. It is built from the overlay dist using xsl to manipulate standalone.xml. > > > On 8/17/16 12:22 PM, Stan Silvert wrote: >> I did a clean build from head. Unzipped demo dist and started up. Got this: >> >> 2016-08-17 12:16:08,126 INFO [org.keycloak.services] (ServerService >> Thread Pool -- 67) KC-SERVICES0001: Loading config from >> c:\kctemp\keycloak-demo-2.2.0-SNAPSHOT\keycloak\standalone\configuration\keycloak-server.json >> 2016-08-17 12:16:08,717 INFO [org.jboss.ws.common.management] (MSC >> service thread 1-1) JBWS022052: Starting JBossWS 5.1.3.Final (Apache CXF >> 3.1.4) >> 2016-08-17 12:16:12,615 WARN >> [org.keycloak.connections.jpa.updater.liquibase.lock.LiquibaseDBLockProvider] >> (ServerService Thread Pool -- 67) Failed to rollback connection after >> error: java.sql.SQLException: IJ031021: You cannot rollback during a >> managed transaction >> at >> org.jboss.jca.adapters.jdbc.BaseWrapperManagedConnection.jdbcRollback(BaseWrapperManagedConnection.java:1122) >> at >> org.jboss.jca.adapters.jdbc.WrappedConnection.rollback(WrappedConnection.java:863) >> at >> org.keycloak.connections.jpa.updater.liquibase.lock.LiquibaseDBLockProvider.safeRollbackConnection(LiquibaseDBLockProvider.java:159) >> at >> org.keycloak.connections.jpa.updater.liquibase.lock.LiquibaseDBLockProvider.waitForLock(LiquibaseDBLockProvider.java:109) >> at >> org.keycloak.services.resources.KeycloakApplication$1.run(KeycloakApplication.java:104) >> at >> org.keycloak.models.utils.KeycloakModelUtils.runJobInTransaction(KeycloakModelUtils.java:287) >> at >> org.keycloak.services.resources.KeycloakApplication.(KeycloakApplication.java:97) >> 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:422) >> at >> org.jboss.resteasy.core.ConstructorInjectorImpl.construct(ConstructorInjectorImpl.java:150) >> at >> org.jboss.resteasy.spi.ResteasyProviderFactory.createProviderInstance(ResteasyProviderFactory.java:2209) >> at >> org.jboss.resteasy.spi.ResteasyDeployment.createApplication(ResteasyDeployment.java:299) >> at >> org.jboss.resteasy.spi.ResteasyDeployment.start(ResteasyDeployment.java:240) >> at >> org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.init(ServletContainerDispatcher.java:113) >> at >> org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.init(HttpServletDispatcher.java:36) >> at >> io.undertow.servlet.core.LifecyleInterceptorInvocation.proceed(LifecyleInterceptorInvocation.java:117) >> at >> org.wildfly.extension.undertow.security.RunAsLifecycleInterceptor.init(RunAsLifecycleInterceptor.java:78) >> at >> io.undertow.servlet.core.LifecyleInterceptorInvocation.proceed(LifecyleInterceptorInvocation.java:103) >> at >> io.undertow.servlet.core.ManagedServlet$DefaultInstanceStrategy.start(ManagedServlet.java:231) >> at >> io.undertow.servlet.core.ManagedServlet.createServlet(ManagedServlet.java:132) >> at >> io.undertow.servlet.core.DeploymentManagerImpl.start(DeploymentManagerImpl.java:526) >> at >> org.wildfly.extension.undertow.deployment.UndertowDeploymentService.startContext(UndertowDeploymentService.java:101) >> at >> org.wildfly.extension.undertow.deployment.UndertowDeploymentService$1.run(UndertowDeploymentService.java:82) >> at >> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) >> at java.util.concurrent.FutureTask.run(FutureTask.java:266) >> at >> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) >> at >> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) >> at java.lang.Thread.run(Thread.java:745) >> at org.jboss.threads.JBossThread.run(JBossThread.java:320) >> >> 2016-08-17 12:16:12,623 ERROR [org.jboss.as.txn] (ServerService Thread >> Pool -- 67) WFLYTX0003: APPLICATION ERROR: transaction still active in >> request with status 4 >> 2016-08-17 12:16:12,624 WARN [com.arjuna.ats.arjuna] (ServerService >> Thread Pool -- 67) ARJUNA012077: Abort called on already aborted atomic >> action 0:ffff0a0a3838:-30eee89c:57b48dc5:b >> 2016-08-17 12:16:12,625 ERROR [org.jboss.msc.service.fail] >> (ServerService Thread Pool -- 67) MSC000001: Failed to start service >> jboss.undertow.deployment.default-server.default-host./auth: >> org.jboss.msc.service.StartException in service >> jboss.undertow.deployment.default-server.default-host./auth: >> java.lang.RuntimeException: RESTEASY003325: Failed to construct public >> org.keycloak.services.resources.KeycloakApplication(javax.servlet.ServletContext,org.jboss.resteasy.core.Dispatcher) >> at >> org.wildfly.extension.undertow.deployment.UndertowDeploymentService$1.run(UndertowDeploymentService.java:85) >> at >> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) >> at java.util.concurrent.FutureTask.run(FutureTask.java:266) >> at >> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) >> at >> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) >> at java.lang.Thread.run(Thread.java:745) >> at org.jboss.threads.JBossThread.run(JBossThread.java:320) >> Caused by: java.lang.RuntimeException: RESTEASY003325: Failed to >> construct public >> org.keycloak.services.resources.KeycloakApplication(javax.servlet.ServletContext,org.jboss.resteasy.core.Dispatcher) >> at >> org.jboss.resteasy.core.ConstructorInjectorImpl.construct(ConstructorInjectorImpl.java:162) >> at >> org.jboss.resteasy.spi.ResteasyProviderFactory.createProviderInstance(ResteasyProviderFactory.java:2209) >> at >> org.jboss.resteasy.spi.ResteasyDeployment.createApplication(ResteasyDeployment.java:299) >> at >> org.jboss.resteasy.spi.ResteasyDeployment.start(ResteasyDeployment.java:240) >> at >> org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.init(ServletContainerDispatcher.java:113) >> at >> org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.init(HttpServletDispatcher.java:36) >> at >> io.undertow.servlet.core.LifecyleInterceptorInvocation.proceed(LifecyleInterceptorInvocation.java:117) >> at >> org.wildfly.extension.undertow.security.RunAsLifecycleInterceptor.init(RunAsLifecycleInterceptor.java:78) >> at >> io.undertow.servlet.core.LifecyleInterceptorInvocation.proceed(LifecyleInterceptorInvocation.java:103) >> at >> io.undertow.servlet.core.ManagedServlet$DefaultInstanceStrategy.start(ManagedServlet.java:231) >> at >> io.undertow.servlet.core.ManagedServlet.createServlet(ManagedServlet.java:132) >> at >> io.undertow.servlet.core.DeploymentManagerImpl.start(DeploymentManagerImpl.java:526) >> at >> org.wildfly.extension.undertow.deployment.UndertowDeploymentService.startContext(UndertowDeploymentService.java:101) >> at >> org.wildfly.extension.undertow.deployment.UndertowDeploymentService$1.run(UndertowDeploymentService.java:82) >> ... 6 more >> Caused by: java.lang.IllegalStateException: Failed to retrieve lock >> at >> org.keycloak.connections.jpa.updater.liquibase.lock.CustomLockService.acquireLock(CustomLockService.java:157) >> at >> org.keycloak.connections.jpa.updater.liquibase.lock.CustomLockService.waitForLock(CustomLockService.java:123) >> at >> org.keycloak.connections.jpa.updater.liquibase.lock.LiquibaseDBLockProvider.waitForLock(LiquibaseDBLockProvider.java:99) >> at >> org.keycloak.services.resources.KeycloakApplication$1.run(KeycloakApplication.java:104) >> at >> org.keycloak.models.utils.KeycloakModelUtils.runJobInTransaction(KeycloakModelUtils.java:287) >> at >> org.keycloak.services.resources.KeycloakApplication.(KeycloakApplication.java:97) >> 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:422) >> at >> org.jboss.resteasy.core.ConstructorInjectorImpl.construct(ConstructorInjectorImpl.java:150) >> ... 19 more >> Caused by: liquibase.exception.DatabaseException: >> liquibase.exception.DatabaseException: java.sql.SQLException: IJ031021: >> You cannot rollback during a managed transaction >> at >> liquibase.database.AbstractJdbcDatabase.rollback(AbstractJdbcDatabase.java:1139) >> at >> org.keycloak.connections.jpa.updater.liquibase.lock.CustomLockService.acquireLock(CustomLockService.java:152) >> ... 29 more >> Caused by: liquibase.exception.DatabaseException: java.sql.SQLException: >> IJ031021: You cannot rollback during a managed transaction >> at >> liquibase.database.jvm.JdbcConnection.rollback(JdbcConnection.java:340) >> at >> liquibase.database.AbstractJdbcDatabase.rollback(AbstractJdbcDatabase.java:1137) >> ... 30 more >> Caused by: java.sql.SQLException: IJ031021: You cannot rollback during a >> managed transaction >> at >> org.jboss.jca.adapters.jdbc.BaseWrapperManagedConnection.jdbcRollback(BaseWrapperManagedConnection.java:1122) >> at >> org.jboss.jca.adapters.jdbc.WrappedConnection.rollback(WrappedConnection.java:863) >> at >> liquibase.database.jvm.JdbcConnection.rollback(JdbcConnection.java:337) >> ... 31 more >> >> 2016-08-17 12:16:12,635 ERROR >> [org.jboss.as.controller.management-operation] (Controller Boot Thread) >> WFLYCTL0013: Operation ("add") failed - address: ([("deployment" => >> "keycloak-server.war")]) - failure description: {"WFLYCTL0080: Failed >> services" => >> {"jboss.undertow.deployment.default-server.default-host./auth" => >> "org.jboss.msc.service.StartException in service >> jboss.undertow.deployment.default-server.default-host./auth: >> java.lang.RuntimeException: RESTEASY003325: Failed to construct public >> org.keycloak.services.resources.KeycloakApplication(javax.servlet.ServletContext,org.jboss.resteasy.core.Dispatcher) >> Caused by: java.lang.RuntimeException: RESTEASY003325: Failed to >> construct public >> org.keycloak.services.resources.KeycloakApplication(javax.servlet.ServletContext,org.jboss.resteasy.core.Dispatcher) >> Caused by: java.lang.IllegalStateException: Failed to retrieve lock >> Caused by: liquibase.exception.DatabaseException: >> liquibase.exception.DatabaseException: java.sql.SQLException: IJ031021: >> You cannot rollback during a managed transaction >> Caused by: liquibase.exception.DatabaseException: >> java.sql.SQLException: IJ031021: You cannot rollback during a managed >> transaction >> Caused by: java.sql.SQLException: IJ031021: You cannot rollback >> during a managed transaction"}} >> 2016-08-17 12:16:12,661 INFO [org.jboss.as.server] (ServerService >> Thread Pool -- 61) WFLYSRV0010: Deployed "keycloak-server.war" >> (runtime-name : "keycloak-server.war") >> 2016-08-17 12:16:12,663 INFO [org.jboss.as.controller] (Controller Boot >> Thread) WFLYCTL0183: Service status report >> WFLYCTL0186: Services which failed to start: service >> jboss.undertow.deployment.default-server.default-host./auth: >> org.jboss.msc.service.StartException in service >> jboss.undertow.deployment.default-server.default-host./auth: >> java.lang.RuntimeException: RESTEASY003325: Failed to construct public >> org.keycloak.services.resources.KeycloakApplication(javax.servlet.ServletContext,org.jboss.resteasy.core.Dispatcher) >> >> 2016-08-17 12:16:12,745 INFO [org.jboss.as] (Controller Boot Thread) >> WFLYSRV0060: Http management interface listening on >> http://127.0.0.1:9990/management >> 2016-08-17 12:16:12,746 INFO [org.jboss.as] (Controller Boot Thread) >> WFLYSRV0051: Admin console listening on http://127.0.0.1:9990 >> 2016-08-17 12:16:12,746 ERROR [org.jboss.as] (Controller Boot Thread) >> WFLYSRV0026: WildFly Full 10.0.0.Final (WildFly Core 2.0.10.Final) >> started (with errors) in 24670ms - Started 429 of 785 services (2 >> services failed or missing dependencies, 513 services are lazy, passive >> or on-demand) >> 2016-08-17 12:19:32,948 INFO [org.jboss.as.server] (Thread-2) >> WFLYSRV0220: Server shutdown has been requested. >> 2016-08-17 12:19:32,977 INFO >> [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-1) >> WFLYJCA0010: Unbound data source [java:jboss/datasources/KeycloakDS] >> 2016-08-17 12:19:32,984 INFO [org.wildfly.extension.undertow] (MSC >> service thread 1-3) WFLYUT0019: Host default-host stopping >> 2016-08-17 12:19:32,994 INFO >> [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-8) >> WFLYJCA0010: Unbound data source [java:jboss/datasources/ExampleDS] >> 2016-08-17 12:19:32,999 INFO [org.jboss.as.connector.deployers.jdbc] >> (MSC service thread 1-8) WFLYJCA0019: Stopped Driver service with >> driver-name = h2 >> 2016-08-17 12:19:33,005 INFO [org.wildfly.extension.undertow] (MSC >> service thread 1-8) WFLYUT0008: Undertow HTTP listener default suspending >> 2016-08-17 12:19:33,006 INFO [org.wildfly.extension.undertow] (MSC >> service thread 1-8) WFLYUT0007: Undertow HTTP listener default stopped, >> was bound to 127.0.0.1:8080 >> 2016-08-17 12:19:33,007 INFO [org.jboss.as.clustering.infinispan] >> (ServerService Thread Pool -- 76) WFLYCLINF0003: Stopped offlineSessions >> cache from keycloak container >> 2016-08-17 12:19:33,007 INFO [org.jboss.as.clustering.infinispan] >> (ServerService Thread Pool -- 73) WFLYCLINF0003: Stopped sessions cache >> from keycloak container >> 2016-08-17 12:19:33,013 INFO [org.jboss.as.clustering.infinispan] >> (ServerService Thread Pool -- 77) WFLYCLINF0003: Stopped authorization >> cache from keycloak container >> 2016-08-17 12:19:33,014 INFO [org.jboss.as.clustering.infinispan] >> (ServerService Thread Pool -- 78) WFLYCLINF0003: Stopped realms cache >> from keycloak container >> 2016-08-17 12:19:33,015 INFO [org.jboss.as.clustering.infinispan] >> (ServerService Thread Pool -- 74) WFLYCLINF0003: Stopped loginFailures >> cache from keycloak container >> 2016-08-17 12:19:33,016 INFO [org.jboss.as.clustering.infinispan] >> (ServerService Thread Pool -- 79) WFLYCLINF0003: Stopped work cache from >> keycloak container >> 2016-08-17 12:19:33,016 INFO [org.jboss.as.clustering.infinispan] >> (ServerService Thread Pool -- 75) WFLYCLINF0003: Stopped users cache >> from keycloak container >> 2016-08-17 12:19:33,024 INFO [org.wildfly.extension.undertow] (MSC >> service thread 1-8) WFLYUT0004: Undertow 1.3.15.Final stopping >> 2016-08-17 12:19:33,029 INFO >> [org.hibernate.validator.internal.util.Version] (MSC service thread 1-2) >> HV000001: Hibernate Validator 5.2.3.Final >> 2016-08-17 12:19:33,083 INFO [org.jboss.as.server.deployment] (MSC >> service thread 1-7) WFLYSRV0028: Stopped deployment keycloak-server.war >> (runtime-name: keycloak-server.war) in 126ms >> 2016-08-17 12:19:33,086 INFO [org.jboss.as] (MSC service thread 1-6) >> WFLYSRV0050: WildFly Full 10.0.0.Final (WildFly Core 2.0.10.Final) >> stopped in 115ms >> >> _______________________________________________ >> 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 Wed Aug 17 13:14:30 2016 From: ssilvert at redhat.com (Stan Silvert) Date: Wed, 17 Aug 2016 13:14:30 -0400 Subject: [keycloak-dev] Demo dist broken In-Reply-To: <57B499B9.5000309@redhat.com> References: <57B48F59.5060300@redhat.com> <68e0f8d3-7676-5cab-b285-9b121bce0018@redhat.com> <57B499B9.5000309@redhat.com> Message-ID: <57B49B76.5090602@redhat.com> On 8/17/2016 1:07 PM, Stan Silvert wrote: > On 8/17/2016 12:59 PM, Bill Burke wrote: >> Gotta set jta=false for the datasource. Demo isn't built from server dist? I verified that jta=false does fix the problem. If you want, I can take care of fixing the xsl in the work I'm doing for keycloak-server.json migration. I have to change that file anyway. Should be ready to merge soon. > No. It is built from the overlay dist using xsl to manipulate > standalone.xml. >> >> On 8/17/16 12:22 PM, Stan Silvert wrote: >>> I did a clean build from head. Unzipped demo dist and started up. Got this: >>> >>> 2016-08-17 12:16:08,126 INFO [org.keycloak.services] (ServerService >>> Thread Pool -- 67) KC-SERVICES0001: Loading config from >>> c:\kctemp\keycloak-demo-2.2.0-SNAPSHOT\keycloak\standalone\configuration\keycloak-server.json >>> 2016-08-17 12:16:08,717 INFO [org.jboss.ws.common.management] (MSC >>> service thread 1-1) JBWS022052: Starting JBossWS 5.1.3.Final (Apache CXF >>> 3.1.4) >>> 2016-08-17 12:16:12,615 WARN >>> [org.keycloak.connections.jpa.updater.liquibase.lock.LiquibaseDBLockProvider] >>> (ServerService Thread Pool -- 67) Failed to rollback connection after >>> error: java.sql.SQLException: IJ031021: You cannot rollback during a >>> managed transaction >>> at >>> org.jboss.jca.adapters.jdbc.BaseWrapperManagedConnection.jdbcRollback(BaseWrapperManagedConnection.java:1122) >>> at >>> org.jboss.jca.adapters.jdbc.WrappedConnection.rollback(WrappedConnection.java:863) >>> at >>> org.keycloak.connections.jpa.updater.liquibase.lock.LiquibaseDBLockProvider.safeRollbackConnection(LiquibaseDBLockProvider.java:159) >>> at >>> org.keycloak.connections.jpa.updater.liquibase.lock.LiquibaseDBLockProvider.waitForLock(LiquibaseDBLockProvider.java:109) >>> at >>> org.keycloak.services.resources.KeycloakApplication$1.run(KeycloakApplication.java:104) >>> at >>> org.keycloak.models.utils.KeycloakModelUtils.runJobInTransaction(KeycloakModelUtils.java:287) >>> at >>> org.keycloak.services.resources.KeycloakApplication.(KeycloakApplication.java:97) >>> 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:422) >>> at >>> org.jboss.resteasy.core.ConstructorInjectorImpl.construct(ConstructorInjectorImpl.java:150) >>> at >>> org.jboss.resteasy.spi.ResteasyProviderFactory.createProviderInstance(ResteasyProviderFactory.java:2209) >>> at >>> org.jboss.resteasy.spi.ResteasyDeployment.createApplication(ResteasyDeployment.java:299) >>> at >>> org.jboss.resteasy.spi.ResteasyDeployment.start(ResteasyDeployment.java:240) >>> at >>> org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.init(ServletContainerDispatcher.java:113) >>> at >>> org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.init(HttpServletDispatcher.java:36) >>> at >>> io.undertow.servlet.core.LifecyleInterceptorInvocation.proceed(LifecyleInterceptorInvocation.java:117) >>> at >>> org.wildfly.extension.undertow.security.RunAsLifecycleInterceptor.init(RunAsLifecycleInterceptor.java:78) >>> at >>> io.undertow.servlet.core.LifecyleInterceptorInvocation.proceed(LifecyleInterceptorInvocation.java:103) >>> at >>> io.undertow.servlet.core.ManagedServlet$DefaultInstanceStrategy.start(ManagedServlet.java:231) >>> at >>> io.undertow.servlet.core.ManagedServlet.createServlet(ManagedServlet.java:132) >>> at >>> io.undertow.servlet.core.DeploymentManagerImpl.start(DeploymentManagerImpl.java:526) >>> at >>> org.wildfly.extension.undertow.deployment.UndertowDeploymentService.startContext(UndertowDeploymentService.java:101) >>> at >>> org.wildfly.extension.undertow.deployment.UndertowDeploymentService$1.run(UndertowDeploymentService.java:82) >>> at >>> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) >>> at java.util.concurrent.FutureTask.run(FutureTask.java:266) >>> at >>> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) >>> at >>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) >>> at java.lang.Thread.run(Thread.java:745) >>> at org.jboss.threads.JBossThread.run(JBossThread.java:320) >>> >>> 2016-08-17 12:16:12,623 ERROR [org.jboss.as.txn] (ServerService Thread >>> Pool -- 67) WFLYTX0003: APPLICATION ERROR: transaction still active in >>> request with status 4 >>> 2016-08-17 12:16:12,624 WARN [com.arjuna.ats.arjuna] (ServerService >>> Thread Pool -- 67) ARJUNA012077: Abort called on already aborted atomic >>> action 0:ffff0a0a3838:-30eee89c:57b48dc5:b >>> 2016-08-17 12:16:12,625 ERROR [org.jboss.msc.service.fail] >>> (ServerService Thread Pool -- 67) MSC000001: Failed to start service >>> jboss.undertow.deployment.default-server.default-host./auth: >>> org.jboss.msc.service.StartException in service >>> jboss.undertow.deployment.default-server.default-host./auth: >>> java.lang.RuntimeException: RESTEASY003325: Failed to construct public >>> org.keycloak.services.resources.KeycloakApplication(javax.servlet.ServletContext,org.jboss.resteasy.core.Dispatcher) >>> at >>> org.wildfly.extension.undertow.deployment.UndertowDeploymentService$1.run(UndertowDeploymentService.java:85) >>> at >>> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) >>> at java.util.concurrent.FutureTask.run(FutureTask.java:266) >>> at >>> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) >>> at >>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) >>> at java.lang.Thread.run(Thread.java:745) >>> at org.jboss.threads.JBossThread.run(JBossThread.java:320) >>> Caused by: java.lang.RuntimeException: RESTEASY003325: Failed to >>> construct public >>> org.keycloak.services.resources.KeycloakApplication(javax.servlet.ServletContext,org.jboss.resteasy.core.Dispatcher) >>> at >>> org.jboss.resteasy.core.ConstructorInjectorImpl.construct(ConstructorInjectorImpl.java:162) >>> at >>> org.jboss.resteasy.spi.ResteasyProviderFactory.createProviderInstance(ResteasyProviderFactory.java:2209) >>> at >>> org.jboss.resteasy.spi.ResteasyDeployment.createApplication(ResteasyDeployment.java:299) >>> at >>> org.jboss.resteasy.spi.ResteasyDeployment.start(ResteasyDeployment.java:240) >>> at >>> org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.init(ServletContainerDispatcher.java:113) >>> at >>> org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.init(HttpServletDispatcher.java:36) >>> at >>> io.undertow.servlet.core.LifecyleInterceptorInvocation.proceed(LifecyleInterceptorInvocation.java:117) >>> at >>> org.wildfly.extension.undertow.security.RunAsLifecycleInterceptor.init(RunAsLifecycleInterceptor.java:78) >>> at >>> io.undertow.servlet.core.LifecyleInterceptorInvocation.proceed(LifecyleInterceptorInvocation.java:103) >>> at >>> io.undertow.servlet.core.ManagedServlet$DefaultInstanceStrategy.start(ManagedServlet.java:231) >>> at >>> io.undertow.servlet.core.ManagedServlet.createServlet(ManagedServlet.java:132) >>> at >>> io.undertow.servlet.core.DeploymentManagerImpl.start(DeploymentManagerImpl.java:526) >>> at >>> org.wildfly.extension.undertow.deployment.UndertowDeploymentService.startContext(UndertowDeploymentService.java:101) >>> at >>> org.wildfly.extension.undertow.deployment.UndertowDeploymentService$1.run(UndertowDeploymentService.java:82) >>> ... 6 more >>> Caused by: java.lang.IllegalStateException: Failed to retrieve lock >>> at >>> org.keycloak.connections.jpa.updater.liquibase.lock.CustomLockService.acquireLock(CustomLockService.java:157) >>> at >>> org.keycloak.connections.jpa.updater.liquibase.lock.CustomLockService.waitForLock(CustomLockService.java:123) >>> at >>> org.keycloak.connections.jpa.updater.liquibase.lock.LiquibaseDBLockProvider.waitForLock(LiquibaseDBLockProvider.java:99) >>> at >>> org.keycloak.services.resources.KeycloakApplication$1.run(KeycloakApplication.java:104) >>> at >>> org.keycloak.models.utils.KeycloakModelUtils.runJobInTransaction(KeycloakModelUtils.java:287) >>> at >>> org.keycloak.services.resources.KeycloakApplication.(KeycloakApplication.java:97) >>> 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:422) >>> at >>> org.jboss.resteasy.core.ConstructorInjectorImpl.construct(ConstructorInjectorImpl.java:150) >>> ... 19 more >>> Caused by: liquibase.exception.DatabaseException: >>> liquibase.exception.DatabaseException: java.sql.SQLException: IJ031021: >>> You cannot rollback during a managed transaction >>> at >>> liquibase.database.AbstractJdbcDatabase.rollback(AbstractJdbcDatabase.java:1139) >>> at >>> org.keycloak.connections.jpa.updater.liquibase.lock.CustomLockService.acquireLock(CustomLockService.java:152) >>> ... 29 more >>> Caused by: liquibase.exception.DatabaseException: java.sql.SQLException: >>> IJ031021: You cannot rollback during a managed transaction >>> at >>> liquibase.database.jvm.JdbcConnection.rollback(JdbcConnection.java:340) >>> at >>> liquibase.database.AbstractJdbcDatabase.rollback(AbstractJdbcDatabase.java:1137) >>> ... 30 more >>> Caused by: java.sql.SQLException: IJ031021: You cannot rollback during a >>> managed transaction >>> at >>> org.jboss.jca.adapters.jdbc.BaseWrapperManagedConnection.jdbcRollback(BaseWrapperManagedConnection.java:1122) >>> at >>> org.jboss.jca.adapters.jdbc.WrappedConnection.rollback(WrappedConnection.java:863) >>> at >>> liquibase.database.jvm.JdbcConnection.rollback(JdbcConnection.java:337) >>> ... 31 more >>> >>> 2016-08-17 12:16:12,635 ERROR >>> [org.jboss.as.controller.management-operation] (Controller Boot Thread) >>> WFLYCTL0013: Operation ("add") failed - address: ([("deployment" => >>> "keycloak-server.war")]) - failure description: {"WFLYCTL0080: Failed >>> services" => >>> {"jboss.undertow.deployment.default-server.default-host./auth" => >>> "org.jboss.msc.service.StartException in service >>> jboss.undertow.deployment.default-server.default-host./auth: >>> java.lang.RuntimeException: RESTEASY003325: Failed to construct public >>> org.keycloak.services.resources.KeycloakApplication(javax.servlet.ServletContext,org.jboss.resteasy.core.Dispatcher) >>> Caused by: java.lang.RuntimeException: RESTEASY003325: Failed to >>> construct public >>> org.keycloak.services.resources.KeycloakApplication(javax.servlet.ServletContext,org.jboss.resteasy.core.Dispatcher) >>> Caused by: java.lang.IllegalStateException: Failed to retrieve lock >>> Caused by: liquibase.exception.DatabaseException: >>> liquibase.exception.DatabaseException: java.sql.SQLException: IJ031021: >>> You cannot rollback during a managed transaction >>> Caused by: liquibase.exception.DatabaseException: >>> java.sql.SQLException: IJ031021: You cannot rollback during a managed >>> transaction >>> Caused by: java.sql.SQLException: IJ031021: You cannot rollback >>> during a managed transaction"}} >>> 2016-08-17 12:16:12,661 INFO [org.jboss.as.server] (ServerService >>> Thread Pool -- 61) WFLYSRV0010: Deployed "keycloak-server.war" >>> (runtime-name : "keycloak-server.war") >>> 2016-08-17 12:16:12,663 INFO [org.jboss.as.controller] (Controller Boot >>> Thread) WFLYCTL0183: Service status report >>> WFLYCTL0186: Services which failed to start: service >>> jboss.undertow.deployment.default-server.default-host./auth: >>> org.jboss.msc.service.StartException in service >>> jboss.undertow.deployment.default-server.default-host./auth: >>> java.lang.RuntimeException: RESTEASY003325: Failed to construct public >>> org.keycloak.services.resources.KeycloakApplication(javax.servlet.ServletContext,org.jboss.resteasy.core.Dispatcher) >>> >>> 2016-08-17 12:16:12,745 INFO [org.jboss.as] (Controller Boot Thread) >>> WFLYSRV0060: Http management interface listening on >>> http://127.0.0.1:9990/management >>> 2016-08-17 12:16:12,746 INFO [org.jboss.as] (Controller Boot Thread) >>> WFLYSRV0051: Admin console listening on http://127.0.0.1:9990 >>> 2016-08-17 12:16:12,746 ERROR [org.jboss.as] (Controller Boot Thread) >>> WFLYSRV0026: WildFly Full 10.0.0.Final (WildFly Core 2.0.10.Final) >>> started (with errors) in 24670ms - Started 429 of 785 services (2 >>> services failed or missing dependencies, 513 services are lazy, passive >>> or on-demand) >>> 2016-08-17 12:19:32,948 INFO [org.jboss.as.server] (Thread-2) >>> WFLYSRV0220: Server shutdown has been requested. >>> 2016-08-17 12:19:32,977 INFO >>> [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-1) >>> WFLYJCA0010: Unbound data source [java:jboss/datasources/KeycloakDS] >>> 2016-08-17 12:19:32,984 INFO [org.wildfly.extension.undertow] (MSC >>> service thread 1-3) WFLYUT0019: Host default-host stopping >>> 2016-08-17 12:19:32,994 INFO >>> [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-8) >>> WFLYJCA0010: Unbound data source [java:jboss/datasources/ExampleDS] >>> 2016-08-17 12:19:32,999 INFO [org.jboss.as.connector.deployers.jdbc] >>> (MSC service thread 1-8) WFLYJCA0019: Stopped Driver service with >>> driver-name = h2 >>> 2016-08-17 12:19:33,005 INFO [org.wildfly.extension.undertow] (MSC >>> service thread 1-8) WFLYUT0008: Undertow HTTP listener default suspending >>> 2016-08-17 12:19:33,006 INFO [org.wildfly.extension.undertow] (MSC >>> service thread 1-8) WFLYUT0007: Undertow HTTP listener default stopped, >>> was bound to 127.0.0.1:8080 >>> 2016-08-17 12:19:33,007 INFO [org.jboss.as.clustering.infinispan] >>> (ServerService Thread Pool -- 76) WFLYCLINF0003: Stopped offlineSessions >>> cache from keycloak container >>> 2016-08-17 12:19:33,007 INFO [org.jboss.as.clustering.infinispan] >>> (ServerService Thread Pool -- 73) WFLYCLINF0003: Stopped sessions cache >>> from keycloak container >>> 2016-08-17 12:19:33,013 INFO [org.jboss.as.clustering.infinispan] >>> (ServerService Thread Pool -- 77) WFLYCLINF0003: Stopped authorization >>> cache from keycloak container >>> 2016-08-17 12:19:33,014 INFO [org.jboss.as.clustering.infinispan] >>> (ServerService Thread Pool -- 78) WFLYCLINF0003: Stopped realms cache >>> from keycloak container >>> 2016-08-17 12:19:33,015 INFO [org.jboss.as.clustering.infinispan] >>> (ServerService Thread Pool -- 74) WFLYCLINF0003: Stopped loginFailures >>> cache from keycloak container >>> 2016-08-17 12:19:33,016 INFO [org.jboss.as.clustering.infinispan] >>> (ServerService Thread Pool -- 79) WFLYCLINF0003: Stopped work cache from >>> keycloak container >>> 2016-08-17 12:19:33,016 INFO [org.jboss.as.clustering.infinispan] >>> (ServerService Thread Pool -- 75) WFLYCLINF0003: Stopped users cache >>> from keycloak container >>> 2016-08-17 12:19:33,024 INFO [org.wildfly.extension.undertow] (MSC >>> service thread 1-8) WFLYUT0004: Undertow 1.3.15.Final stopping >>> 2016-08-17 12:19:33,029 INFO >>> [org.hibernate.validator.internal.util.Version] (MSC service thread 1-2) >>> HV000001: Hibernate Validator 5.2.3.Final >>> 2016-08-17 12:19:33,083 INFO [org.jboss.as.server.deployment] (MSC >>> service thread 1-7) WFLYSRV0028: Stopped deployment keycloak-server.war >>> (runtime-name: keycloak-server.war) in 126ms >>> 2016-08-17 12:19:33,086 INFO [org.jboss.as] (MSC service thread 1-6) >>> WFLYSRV0050: WildFly Full 10.0.0.Final (WildFly Core 2.0.10.Final) >>> stopped in 115ms >>> >>> _______________________________________________ >>> 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 Wed Aug 17 23:51:50 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Thu, 18 Aug 2016 05:51:50 +0200 Subject: [keycloak-dev] Demo dist broken In-Reply-To: <57B49B76.5090602@redhat.com> References: <57B48F59.5060300@redhat.com> <68e0f8d3-7676-5cab-b285-9b121bce0018@redhat.com> <57B499B9.5000309@redhat.com> <57B49B76.5090602@redhat.com> Message-ID: We should support JTA on the datasource so it's possible to achieve XA transactions if needed. So we shouldn't require jta=false. On 17 August 2016 at 19:14, Stan Silvert wrote: > On 8/17/2016 1:07 PM, Stan Silvert wrote: > > On 8/17/2016 12:59 PM, Bill Burke wrote: > >> Gotta set jta=false for the datasource. Demo isn't built from server > dist? > I verified that jta=false does fix the problem. If you want, I can > take care of fixing the xsl in the work I'm doing for > keycloak-server.json migration. I have to change that file anyway. > Should be ready to merge soon. > > No. It is built from the overlay dist using xsl to manipulate > > standalone.xml. > >> > >> On 8/17/16 12:22 PM, Stan Silvert wrote: > >>> I did a clean build from head. Unzipped demo dist and started up. Got > this: > >>> > >>> 2016-08-17 12:16:08,126 INFO [org.keycloak.services] (ServerService > >>> Thread Pool -- 67) KC-SERVICES0001: Loading config from > >>> c:\kctemp\keycloak-demo-2.2.0-SNAPSHOT\keycloak\standalone\ > configuration\keycloak-server.json > >>> 2016-08-17 12:16:08,717 INFO [org.jboss.ws.common.management] (MSC > >>> service thread 1-1) JBWS022052: Starting JBossWS 5.1.3.Final (Apache > CXF > >>> 3.1.4) > >>> 2016-08-17 12:16:12,615 WARN > >>> [org.keycloak.connections.jpa.updater.liquibase.lock. > LiquibaseDBLockProvider] > >>> (ServerService Thread Pool -- 67) Failed to rollback connection after > >>> error: java.sql.SQLException: IJ031021: You cannot rollback during a > >>> managed transaction > >>> at > >>> org.jboss.jca.adapters.jdbc.BaseWrapperManagedConnection.jdbcRollback( > BaseWrapperManagedConnection.java:1122) > >>> at > >>> org.jboss.jca.adapters.jdbc.WrappedConnection.rollback( > WrappedConnection.java:863) > >>> at > >>> org.keycloak.connections.jpa.updater.liquibase.lock. > LiquibaseDBLockProvider.safeRollbackConnection( > LiquibaseDBLockProvider.java:159) > >>> at > >>> org.keycloak.connections.jpa.updater.liquibase.lock. > LiquibaseDBLockProvider.waitForLock(LiquibaseDBLockProvider.java:109) > >>> at > >>> org.keycloak.services.resources.KeycloakApplication$ > 1.run(KeycloakApplication.java:104) > >>> at > >>> org.keycloak.models.utils.KeycloakModelUtils.runJobInTransaction( > KeycloakModelUtils.java:287) > >>> at > >>> org.keycloak.services.resources.KeycloakApplication. > (KeycloakApplication.java:97) > >>> 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: > 422) > >>> at > >>> org.jboss.resteasy.core.ConstructorInjectorImpl.construct( > ConstructorInjectorImpl.java:150) > >>> at > >>> org.jboss.resteasy.spi.ResteasyProviderFactory.createProviderInstance( > ResteasyProviderFactory.java:2209) > >>> at > >>> org.jboss.resteasy.spi.ResteasyDeployment.createApplication( > ResteasyDeployment.java:299) > >>> at > >>> org.jboss.resteasy.spi.ResteasyDeployment.start( > ResteasyDeployment.java:240) > >>> at > >>> org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher. > init(ServletContainerDispatcher.java:113) > >>> at > >>> org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.init( > HttpServletDispatcher.java:36) > >>> at > >>> io.undertow.servlet.core.LifecyleInterceptorInvocation.proceed( > LifecyleInterceptorInvocation.java:117) > >>> at > >>> org.wildfly.extension.undertow.security.RunAsLifecycleInterceptor. > init(RunAsLifecycleInterceptor.java:78) > >>> at > >>> io.undertow.servlet.core.LifecyleInterceptorInvocation.proceed( > LifecyleInterceptorInvocation.java:103) > >>> at > >>> io.undertow.servlet.core.ManagedServlet$DefaultInstanceStrategy.start( > ManagedServlet.java:231) > >>> at > >>> io.undertow.servlet.core.ManagedServlet.createServlet( > ManagedServlet.java:132) > >>> at > >>> io.undertow.servlet.core.DeploymentManagerImpl.start( > DeploymentManagerImpl.java:526) > >>> at > >>> org.wildfly.extension.undertow.deployment.UndertowDeploymentService. > startContext(UndertowDeploymentService.java:101) > >>> at > >>> org.wildfly.extension.undertow.deployment.UndertowDeploymentService$1. > run(UndertowDeploymentService.java:82) > >>> at > >>> java.util.concurrent.Executors$RunnableAdapter. > call(Executors.java:511) > >>> at java.util.concurrent.FutureTask.run(FutureTask.java:266) > >>> at > >>> java.util.concurrent.ThreadPoolExecutor.runWorker( > ThreadPoolExecutor.java:1142) > >>> at > >>> java.util.concurrent.ThreadPoolExecutor$Worker.run( > ThreadPoolExecutor.java:617) > >>> at java.lang.Thread.run(Thread.java:745) > >>> at org.jboss.threads.JBossThread.run(JBossThread.java:320) > >>> > >>> 2016-08-17 12:16:12,623 ERROR [org.jboss.as.txn] (ServerService Thread > >>> Pool -- 67) WFLYTX0003: APPLICATION ERROR: transaction still active in > >>> request with status 4 > >>> 2016-08-17 12:16:12,624 WARN [com.arjuna.ats.arjuna] (ServerService > >>> Thread Pool -- 67) ARJUNA012077: Abort called on already aborted atomic > >>> action 0:ffff0a0a3838:-30eee89c:57b48dc5:b > >>> 2016-08-17 12:16:12,625 ERROR [org.jboss.msc.service.fail] > >>> (ServerService Thread Pool -- 67) MSC000001: Failed to start service > >>> jboss.undertow.deployment.default-server.default-host./auth: > >>> org.jboss.msc.service.StartException in service > >>> jboss.undertow.deployment.default-server.default-host./auth: > >>> java.lang.RuntimeException: RESTEASY003325: Failed to construct public > >>> org.keycloak.services.resources.KeycloakApplication( > javax.servlet.ServletContext,org.jboss.resteasy.core.Dispatcher) > >>> at > >>> org.wildfly.extension.undertow.deployment.UndertowDeploymentService$1. > run(UndertowDeploymentService.java:85) > >>> at > >>> java.util.concurrent.Executors$RunnableAdapter. > call(Executors.java:511) > >>> at java.util.concurrent.FutureTask.run(FutureTask.java:266) > >>> at > >>> java.util.concurrent.ThreadPoolExecutor.runWorker( > ThreadPoolExecutor.java:1142) > >>> at > >>> java.util.concurrent.ThreadPoolExecutor$Worker.run( > ThreadPoolExecutor.java:617) > >>> at java.lang.Thread.run(Thread.java:745) > >>> at org.jboss.threads.JBossThread.run(JBossThread.java:320) > >>> Caused by: java.lang.RuntimeException: RESTEASY003325: Failed to > >>> construct public > >>> org.keycloak.services.resources.KeycloakApplication( > javax.servlet.ServletContext,org.jboss.resteasy.core.Dispatcher) > >>> at > >>> org.jboss.resteasy.core.ConstructorInjectorImpl.construct( > ConstructorInjectorImpl.java:162) > >>> at > >>> org.jboss.resteasy.spi.ResteasyProviderFactory.createProviderInstance( > ResteasyProviderFactory.java:2209) > >>> at > >>> org.jboss.resteasy.spi.ResteasyDeployment.createApplication( > ResteasyDeployment.java:299) > >>> at > >>> org.jboss.resteasy.spi.ResteasyDeployment.start( > ResteasyDeployment.java:240) > >>> at > >>> org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher. > init(ServletContainerDispatcher.java:113) > >>> at > >>> org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.init( > HttpServletDispatcher.java:36) > >>> at > >>> io.undertow.servlet.core.LifecyleInterceptorInvocation.proceed( > LifecyleInterceptorInvocation.java:117) > >>> at > >>> org.wildfly.extension.undertow.security.RunAsLifecycleInterceptor. > init(RunAsLifecycleInterceptor.java:78) > >>> at > >>> io.undertow.servlet.core.LifecyleInterceptorInvocation.proceed( > LifecyleInterceptorInvocation.java:103) > >>> at > >>> io.undertow.servlet.core.ManagedServlet$DefaultInstanceStrategy.start( > ManagedServlet.java:231) > >>> at > >>> io.undertow.servlet.core.ManagedServlet.createServlet( > ManagedServlet.java:132) > >>> at > >>> io.undertow.servlet.core.DeploymentManagerImpl.start( > DeploymentManagerImpl.java:526) > >>> at > >>> org.wildfly.extension.undertow.deployment.UndertowDeploymentService. > startContext(UndertowDeploymentService.java:101) > >>> at > >>> org.wildfly.extension.undertow.deployment.UndertowDeploymentService$1. > run(UndertowDeploymentService.java:82) > >>> ... 6 more > >>> Caused by: java.lang.IllegalStateException: Failed to retrieve lock > >>> at > >>> org.keycloak.connections.jpa.updater.liquibase.lock. > CustomLockService.acquireLock(CustomLockService.java:157) > >>> at > >>> org.keycloak.connections.jpa.updater.liquibase.lock. > CustomLockService.waitForLock(CustomLockService.java:123) > >>> at > >>> org.keycloak.connections.jpa.updater.liquibase.lock. > LiquibaseDBLockProvider.waitForLock(LiquibaseDBLockProvider.java:99) > >>> at > >>> org.keycloak.services.resources.KeycloakApplication$ > 1.run(KeycloakApplication.java:104) > >>> at > >>> org.keycloak.models.utils.KeycloakModelUtils.runJobInTransaction( > KeycloakModelUtils.java:287) > >>> at > >>> org.keycloak.services.resources.KeycloakApplication. > (KeycloakApplication.java:97) > >>> 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: > 422) > >>> at > >>> org.jboss.resteasy.core.ConstructorInjectorImpl.construct( > ConstructorInjectorImpl.java:150) > >>> ... 19 more > >>> Caused by: liquibase.exception.DatabaseException: > >>> liquibase.exception.DatabaseException: java.sql.SQLException: > IJ031021: > >>> You cannot rollback during a managed transaction > >>> at > >>> liquibase.database.AbstractJdbcDatabase.rollback( > AbstractJdbcDatabase.java:1139) > >>> at > >>> org.keycloak.connections.jpa.updater.liquibase.lock. > CustomLockService.acquireLock(CustomLockService.java:152) > >>> ... 29 more > >>> Caused by: liquibase.exception.DatabaseException: > java.sql.SQLException: > >>> IJ031021: You cannot rollback during a managed transaction > >>> at > >>> liquibase.database.jvm.JdbcConnection.rollback( > JdbcConnection.java:340) > >>> at > >>> liquibase.database.AbstractJdbcDatabase.rollback( > AbstractJdbcDatabase.java:1137) > >>> ... 30 more > >>> Caused by: java.sql.SQLException: IJ031021: You cannot rollback during > a > >>> managed transaction > >>> at > >>> org.jboss.jca.adapters.jdbc.BaseWrapperManagedConnection.jdbcRollback( > BaseWrapperManagedConnection.java:1122) > >>> at > >>> org.jboss.jca.adapters.jdbc.WrappedConnection.rollback( > WrappedConnection.java:863) > >>> at > >>> liquibase.database.jvm.JdbcConnection.rollback( > JdbcConnection.java:337) > >>> ... 31 more > >>> > >>> 2016-08-17 12:16:12,635 ERROR > >>> [org.jboss.as.controller.management-operation] (Controller Boot > Thread) > >>> WFLYCTL0013: Operation ("add") failed - address: ([("deployment" => > >>> "keycloak-server.war")]) - failure description: {"WFLYCTL0080: Failed > >>> services" => > >>> {"jboss.undertow.deployment.default-server.default-host./auth" => > >>> "org.jboss.msc.service.StartException in service > >>> jboss.undertow.deployment.default-server.default-host./auth: > >>> java.lang.RuntimeException: RESTEASY003325: Failed to construct public > >>> org.keycloak.services.resources.KeycloakApplication( > javax.servlet.ServletContext,org.jboss.resteasy.core.Dispatcher) > >>> Caused by: java.lang.RuntimeException: RESTEASY003325: Failed > to > >>> construct public > >>> org.keycloak.services.resources.KeycloakApplication( > javax.servlet.ServletContext,org.jboss.resteasy.core.Dispatcher) > >>> Caused by: java.lang.IllegalStateException: Failed to > retrieve lock > >>> Caused by: liquibase.exception.DatabaseException: > >>> liquibase.exception.DatabaseException: java.sql.SQLException: > IJ031021: > >>> You cannot rollback during a managed transaction > >>> Caused by: liquibase.exception.DatabaseException: > >>> java.sql.SQLException: IJ031021: You cannot rollback during a managed > >>> transaction > >>> Caused by: java.sql.SQLException: IJ031021: You cannot rollback > >>> during a managed transaction"}} > >>> 2016-08-17 12:16:12,661 INFO [org.jboss.as.server] (ServerService > >>> Thread Pool -- 61) WFLYSRV0010: Deployed "keycloak-server.war" > >>> (runtime-name : "keycloak-server.war") > >>> 2016-08-17 12:16:12,663 INFO [org.jboss.as.controller] (Controller > Boot > >>> Thread) WFLYCTL0183: Service status report > >>> WFLYCTL0186: Services which failed to start: service > >>> jboss.undertow.deployment.default-server.default-host./auth: > >>> org.jboss.msc.service.StartException in service > >>> jboss.undertow.deployment.default-server.default-host./auth: > >>> java.lang.RuntimeException: RESTEASY003325: Failed to construct public > >>> org.keycloak.services.resources.KeycloakApplication( > javax.servlet.ServletContext,org.jboss.resteasy.core.Dispatcher) > >>> > >>> 2016-08-17 12:16:12,745 INFO [org.jboss.as] (Controller Boot Thread) > >>> WFLYSRV0060: Http management interface listening on > >>> http://127.0.0.1:9990/management > >>> 2016-08-17 12:16:12,746 INFO [org.jboss.as] (Controller Boot Thread) > >>> WFLYSRV0051: Admin console listening on http://127.0.0.1:9990 > >>> 2016-08-17 12:16:12,746 ERROR [org.jboss.as] (Controller Boot Thread) > >>> WFLYSRV0026: WildFly Full 10.0.0.Final (WildFly Core 2.0.10.Final) > >>> started (with errors) in 24670ms - Started 429 of 785 services (2 > >>> services failed or missing dependencies, 513 services are lazy, passive > >>> or on-demand) > >>> 2016-08-17 12:19:32,948 INFO [org.jboss.as.server] (Thread-2) > >>> WFLYSRV0220: Server shutdown has been requested. > >>> 2016-08-17 12:19:32,977 INFO > >>> [org.jboss.as.connector.subsystems.datasources] (MSC service thread > 1-1) > >>> WFLYJCA0010: Unbound data source [java:jboss/datasources/KeycloakDS] > >>> 2016-08-17 12:19:32,984 INFO [org.wildfly.extension.undertow] (MSC > >>> service thread 1-3) WFLYUT0019: Host default-host stopping > >>> 2016-08-17 12:19:32,994 INFO > >>> [org.jboss.as.connector.subsystems.datasources] (MSC service thread > 1-8) > >>> WFLYJCA0010: Unbound data source [java:jboss/datasources/ExampleDS] > >>> 2016-08-17 12:19:32,999 INFO [org.jboss.as.connector.deployers.jdbc] > >>> (MSC service thread 1-8) WFLYJCA0019: Stopped Driver service with > >>> driver-name = h2 > >>> 2016-08-17 12:19:33,005 INFO [org.wildfly.extension.undertow] (MSC > >>> service thread 1-8) WFLYUT0008: Undertow HTTP listener default > suspending > >>> 2016-08-17 12:19:33,006 INFO [org.wildfly.extension.undertow] (MSC > >>> service thread 1-8) WFLYUT0007: Undertow HTTP listener default stopped, > >>> was bound to 127.0.0.1:8080 > >>> 2016-08-17 12:19:33,007 INFO [org.jboss.as.clustering.infinispan] > >>> (ServerService Thread Pool -- 76) WFLYCLINF0003: Stopped > offlineSessions > >>> cache from keycloak container > >>> 2016-08-17 12:19:33,007 INFO [org.jboss.as.clustering.infinispan] > >>> (ServerService Thread Pool -- 73) WFLYCLINF0003: Stopped sessions cache > >>> from keycloak container > >>> 2016-08-17 12:19:33,013 INFO [org.jboss.as.clustering.infinispan] > >>> (ServerService Thread Pool -- 77) WFLYCLINF0003: Stopped authorization > >>> cache from keycloak container > >>> 2016-08-17 12:19:33,014 INFO [org.jboss.as.clustering.infinispan] > >>> (ServerService Thread Pool -- 78) WFLYCLINF0003: Stopped realms cache > >>> from keycloak container > >>> 2016-08-17 12:19:33,015 INFO [org.jboss.as.clustering.infinispan] > >>> (ServerService Thread Pool -- 74) WFLYCLINF0003: Stopped loginFailures > >>> cache from keycloak container > >>> 2016-08-17 12:19:33,016 INFO [org.jboss.as.clustering.infinispan] > >>> (ServerService Thread Pool -- 79) WFLYCLINF0003: Stopped work cache > from > >>> keycloak container > >>> 2016-08-17 12:19:33,016 INFO [org.jboss.as.clustering.infinispan] > >>> (ServerService Thread Pool -- 75) WFLYCLINF0003: Stopped users cache > >>> from keycloak container > >>> 2016-08-17 12:19:33,024 INFO [org.wildfly.extension.undertow] (MSC > >>> service thread 1-8) WFLYUT0004: Undertow 1.3.15.Final stopping > >>> 2016-08-17 12:19:33,029 INFO > >>> [org.hibernate.validator.internal.util.Version] (MSC service thread > 1-2) > >>> HV000001: Hibernate Validator 5.2.3.Final > >>> 2016-08-17 12:19:33,083 INFO [org.jboss.as.server.deployment] (MSC > >>> service thread 1-7) WFLYSRV0028: Stopped deployment keycloak-server.war > >>> (runtime-name: keycloak-server.war) in 126ms > >>> 2016-08-17 12:19:33,086 INFO [org.jboss.as] (MSC service thread 1-6) > >>> WFLYSRV0050: WildFly Full 10.0.0.Final (WildFly Core 2.0.10.Final) > >>> stopped in 115ms > >>> > >>> _______________________________________________ > >>> 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 > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160818/95256cf4/attachment-0001.html From sthorger at redhat.com Thu Aug 18 00:01:16 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Thu, 18 Aug 2016 06:01:16 +0200 Subject: [keycloak-dev] Docker Protocol? In-Reply-To: <7e296080-8b29-d70c-e397-376146f023c7@redhat.com> References: <7e296080-8b29-d70c-e397-376146f023c7@redhat.com> Message-ID: That would probably do it. I was thinking more about having a "features.json" file or something, but that'd be overkill probably. On 17 August 2016 at 14:56, Bill Burke wrote: > Can't you just have "enabled": false in keycloak-server.json for that > provider? > > On 8/17/16 3:41 AM, Stian Thorgersen wrote: > > We could have it included in KC, but disabled by default. Having the > ability to enable/disable features is something we need in either case. > Especially for product as we'd like to have certain community only features > (or tech preview features) disabled by default to make it obvious to > customers they are using unsupported features. > > We'd need to figure out some way to automate testing of it though. We > obviously can't manually test with Docker on a regular basis. Do you have > any plans around how to test it? > > On 16 August 2016 at 21:24, Josh Cain wrote: > >> Couldn't agree more that Docker should use an existing/standards-based >> auth protocol. Problem is, we need our Keycloak IDP to start talking to >> docker registries. Since we have a hard requirement to talk to docker >> registries, our IDP has to speak docker auth. There are already a number >> of Docker registry authorization servers out there, so there seems to be a >> need out there in the community as well. >> >> We're going to develop one and push it out such that it's publicly >> accessible in any case, I was just curious as to whether the dev team would >> want to incorporate this into the product. >> >> >> Josh Cain | Software Applications Engineer >> *Identity and Access Management* >> *Red Hat* >> +1 256-452-0150 <%2B1%20256-452-0150> >> >> On Tue, Aug 16, 2016 at 4:19 AM, Stian Thorgersen >> wrote: >> >>> I'm not sure we'd like to have a Docker registry specific protocol added >>> directly to Keycloak. Seems like Docker registry should rather get their >>> act together and comply with existing protocols rather than invent their >>> own. >>> >>> We did have an idea of creating some repository for extensions. These >>> would be community maintained, not included in product and wouldn't receive >>> the same level of testing. Maybe that would be a good place for this. With >>> Bills recent deployer work it could be easier to allow users to deploy >>> custom extensions as well. >>> >>> On 15 August 2016 at 16:41, Josh Cain wrote: >>> >>>> Hi Stian, >>>> >>>> Docker's auth V2 (docs link above) is Oauth-ish, but doesn't seem to >>>> conform 100% to the specification. I started by just trying to stand up an >>>> OIDC endpoint to talk to docker and Keycloak threw a "Missing parameters: >>>> response_type" error. Turns out, Docker sends the GET request like this: >>>> >>>> /auth/realms/redhat-external/protocol/docker-v2/auth?account >>>> =jcain&scope=repository%3Acentos%3Apull&service=docker-registry >>>> >>>> Not only is the request missing the request_typer paremeter, but Docker >>>> uses different nomenclature than the OAuth/OIDC standard. For instance, I >>>> would expect the 'service' param to appear as the client_id param to >>>> conform to the OAuth spec. >>>> >>>> Since it uses different nomenclature, I thought it would be a much >>>> cleaner implementation to just implement it as its own protocol. Didn't >>>> want to muddy up a clean OIDC/OAuth implemention. >>>> >>>> Are there workarounds to deal with these differences that I'm missing? >>>> >>>> >>>> Josh Cain | Software Applications Engineer >>>> *Identity and Access Management* >>>> *Red Hat* >>>> +1 843-737-1735 <%2B1%20843-737-1735> >>>> >>>> On Mon, Aug 15, 2016 at 5:56 AM, Stian Thorgersen >>>> wrote: >>>> >>>>> I'm not sure I fully understand. Are you using a Docker client to >>>>> authenticate with Keycloak? That works with the standard OIDC flows, but it >>>>> requires some additional claims in the token which you are adding with a >>>>> protocol mapper? >>>>> >>>>> On 12 August 2016 at 15:31, Josh Cain wrote: >>>>> >>>>>> Hi All, >>>>>> >>>>>> We want to use Keycloak as the IDP/Token issuer for authentication >>>>>> with a docker registry as per the specification found here: >>>>>> >>>>>> https://docs.docker.com/registry/spec/auth/ >>>>>> >>>>>> I've implemented a Protocol Mapper in Keycloak that successfully uses >>>>>> the IDP to perform a login against a registry/docker client. Is this >>>>>> something that the team is interested in building into the product? If so, >>>>>> I'd be happy to push back upstream. >>>>>> >>>>>> Josh Cain | Software Applications Engineer >>>>>> *Identity and Access Management* >>>>>> *Red Hat* >>>>>> +1 843-737-1735 <%2B1%20843-737-1735> >>>>>> >>>>>> _______________________________________________ >>>>>> keycloak-dev mailing list >>>>>> keycloak-dev at lists.jboss.org >>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>>>>> >>>>> >>>>> >>>> >>> >> > > > _______________________________________________ > keycloak-dev mailing listkeycloak-dev at lists.jboss.orghttps://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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160818/902b4ca9/attachment.html From sthorger at redhat.com Thu Aug 18 00:01:58 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Thu, 18 Aug 2016 06:01:58 +0200 Subject: [keycloak-dev] Docker Protocol? In-Reply-To: References: <7e296080-8b29-d70c-e397-376146f023c7@redhat.com> Message-ID: I'm good with including it in community as long as it's disabled by default, documented and tested ;) On 17 August 2016 at 16:06, Josh Cain wrote: > I've been in POC mode lately, so the cursory testing I've done has been > limited to manual, high-level tests. I'd be happy to find a way to get > some useful integrated test for this. > > Right now I'm using 3 things to test - a docker client, a docker registry, > and the keycloak IDP. Should be able to automate the registry container > start and there's a java library for docker clients that we can use. So > automated integration testing looks possible, but I've not gone down that > road just yet. Would certainly do so if this was going upstream to > Keycloak proper. > > > Josh Cain | Software Applications Engineer > *Identity and Access Management* > *Red Hat* > +1 256-452-0150 > > On Wed, Aug 17, 2016 at 7:56 AM, Bill Burke wrote: > >> Can't you just have "enabled": false in keycloak-server.json for that >> provider? >> >> On 8/17/16 3:41 AM, Stian Thorgersen wrote: >> >> We could have it included in KC, but disabled by default. Having the >> ability to enable/disable features is something we need in either case. >> Especially for product as we'd like to have certain community only features >> (or tech preview features) disabled by default to make it obvious to >> customers they are using unsupported features. >> >> We'd need to figure out some way to automate testing of it though. We >> obviously can't manually test with Docker on a regular basis. Do you have >> any plans around how to test it? >> >> On 16 August 2016 at 21:24, Josh Cain wrote: >> >>> Couldn't agree more that Docker should use an existing/standards-based >>> auth protocol. Problem is, we need our Keycloak IDP to start talking to >>> docker registries. Since we have a hard requirement to talk to docker >>> registries, our IDP has to speak docker auth. There are already a number >>> of Docker registry authorization servers out there, so there seems to be a >>> need out there in the community as well. >>> >>> We're going to develop one and push it out such that it's publicly >>> accessible in any case, I was just curious as to whether the dev team would >>> want to incorporate this into the product. >>> >>> >>> Josh Cain | Software Applications Engineer >>> *Identity and Access Management* >>> *Red Hat* >>> +1 256-452-0150 <%2B1%20256-452-0150> >>> >>> On Tue, Aug 16, 2016 at 4:19 AM, Stian Thorgersen >>> wrote: >>> >>>> I'm not sure we'd like to have a Docker registry specific protocol >>>> added directly to Keycloak. Seems like Docker registry should rather get >>>> their act together and comply with existing protocols rather than invent >>>> their own. >>>> >>>> We did have an idea of creating some repository for extensions. These >>>> would be community maintained, not included in product and wouldn't receive >>>> the same level of testing. Maybe that would be a good place for this. With >>>> Bills recent deployer work it could be easier to allow users to deploy >>>> custom extensions as well. >>>> >>>> On 15 August 2016 at 16:41, Josh Cain wrote: >>>> >>>>> Hi Stian, >>>>> >>>>> Docker's auth V2 (docs link above) is Oauth-ish, but doesn't seem to >>>>> conform 100% to the specification. I started by just trying to stand up an >>>>> OIDC endpoint to talk to docker and Keycloak threw a "Missing parameters: >>>>> response_type" error. Turns out, Docker sends the GET request like this: >>>>> >>>>> /auth/realms/redhat-external/protocol/docker-v2/auth?account >>>>> =jcain&scope=repository%3Acentos%3Apull&service=docker-registry >>>>> >>>>> Not only is the request missing the request_typer paremeter, but >>>>> Docker uses different nomenclature than the OAuth/OIDC standard. For >>>>> instance, I would expect the 'service' param to appear as the client_id >>>>> param to conform to the OAuth spec. >>>>> >>>>> Since it uses different nomenclature, I thought it would be a much >>>>> cleaner implementation to just implement it as its own protocol. Didn't >>>>> want to muddy up a clean OIDC/OAuth implemention. >>>>> >>>>> Are there workarounds to deal with these differences that I'm missing? >>>>> >>>>> >>>>> Josh Cain | Software Applications Engineer >>>>> *Identity and Access Management* >>>>> *Red Hat* >>>>> +1 843-737-1735 <%2B1%20843-737-1735> >>>>> >>>>> On Mon, Aug 15, 2016 at 5:56 AM, Stian Thorgersen >>>> > wrote: >>>>> >>>>>> I'm not sure I fully understand. Are you using a Docker client to >>>>>> authenticate with Keycloak? That works with the standard OIDC flows, but it >>>>>> requires some additional claims in the token which you are adding with a >>>>>> protocol mapper? >>>>>> >>>>>> On 12 August 2016 at 15:31, Josh Cain wrote: >>>>>> >>>>>>> Hi All, >>>>>>> >>>>>>> We want to use Keycloak as the IDP/Token issuer for authentication >>>>>>> with a docker registry as per the specification found here: >>>>>>> >>>>>>> https://docs.docker.com/registry/spec/auth/ >>>>>>> >>>>>>> I've implemented a Protocol Mapper in Keycloak that successfully >>>>>>> uses the IDP to perform a login against a registry/docker client. Is this >>>>>>> something that the team is interested in building into the product? If so, >>>>>>> I'd be happy to push back upstream. >>>>>>> >>>>>>> Josh Cain | Software Applications Engineer >>>>>>> *Identity and Access Management* >>>>>>> *Red Hat* >>>>>>> +1 843-737-1735 <%2B1%20843-737-1735> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> keycloak-dev mailing list >>>>>>> keycloak-dev at lists.jboss.org >>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>>>>>> >>>>>> >>>>>> >>>>> >>>> >>> >> >> >> _______________________________________________ >> keycloak-dev mailing listkeycloak-dev at lists.jboss.orghttps://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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160818/3a2850a0/attachment-0001.html From sthorger at redhat.com Thu Aug 18 01:13:57 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Thu, 18 Aug 2016 07:13:57 +0200 Subject: [keycloak-dev] new provider deployer working on branch! In-Reply-To: References: Message-ID: One problem with this approach is that you end up having a separate JDBC connection and transaction even if it uses the same database the Keycloak server uses. Take a look at https://github.com/keycloak/keycloak/tree/master/examples/providers/domain-extension/src/main/java/org/keycloak/examples/domainextension/jpa for example which allows adding custom entities to the main EntityManager. On 6 August 2016 at 17:43, Bill Burke wrote: > I've implemented a Keycloak provider deployer and it works great. I > re-implemented the JPA User Storage SPI example. The provider is now a > @Stateful EJB and EntityManager access is all managed by > @PersistenceContext. The example now looks really simple and elegant > rather than the crap I mentioned before. Would not have worked without > the JTA integration I did (see previous email). Things left to do: > > * hot deployment. Pretty sure I can implement this > > * Make sure things work in WARs and EARs. > > * Also thinking of defining a @KeycloakProvider annotation that you can > use on your ProviderFactories. This would remove the need to specify a > META-INF/services file and the annotation could be scanned for at > deployment. Would work like this: > > > @KeycloakProvider(UserStorageProviderFactory.class) > > public class MyProvider ... { > > } > > As a side note, one thing I could look into is the ability to use > @Inject of a KeycloakSession. Developer could then write entire web > applications that are deployed separately and worked with the keycloak > API directly. @Inject KeycloakSession would work similarly to > @PersistenceContexts EntityManager. KeycloakSessions would be > associated with a transaction. This will give us nice integration with > Java EE and give a lot of power to developers wanting to extend keycloak. > > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160818/3c3bd970/attachment.html From sthorger at redhat.com Thu Aug 18 01:15:40 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Thu, 18 Aug 2016 07:15:40 +0200 Subject: [keycloak-dev] new deployer in master In-Reply-To: <6d547a5b-54ca-a0cf-a25d-a313e6871487@redhat.com> References: <6d547a5b-54ca-a0cf-a25d-a313e6871487@redhat.com> Message-ID: On 8 August 2016 at 23:51, Bill Burke wrote: > Ok, > > New provider deployer exists in master. You can package components in > any type of deployment. i.e. within a EAR or WAR. Hot deploy works as > well. The deployers/ directory and deployment-scanner subsystem is now > back in the server. Also added JTA transactions. So, now when a > KeycloakSession is created a new JTA transaction is associated with the > KeycloakTransactionManager. If there was an existing JTA transactionn, > that transaction is suspended and resumed after the keycloak session > completes. JTA TransactionManager lookup has an SPI now which you can > enable/disable in keycloaks-server.json. If no transaciton manager > exists i.e. within the testsuite, JTA is not used at all. > Why is the existing transaction suspended? Should it not just join the existing transaction? We should also make sure our JPA stores use the same transaction. > > I'll be documenting all this eventually. Still have some work to do on > the new user federation spi before that though. > > Bill > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160818/ff2a10fc/attachment.html From sthorger at redhat.com Thu Aug 18 04:10:04 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Thu, 18 Aug 2016 10:10:04 +0200 Subject: [keycloak-dev] new generic component storage In-Reply-To: References: Message-ID: Sounds great. Do you have an example on how to use it? Or do we need to dig into the code in details? On 9 August 2016 at 15:15, Bill Burke wrote: > I've implemented a new generic component storage, api, REST API, and > admin console support. Classes/interfaces are in server-spi > org.keycloak.component package and created via methods in RealmModel. > It is basically a more generic form of mapper models, > UserFederationModel, etc. Components describe themselves and can be > generically rendered by the admin console. The storage model is meant > to support nested subcomponents (i.e. UserFederationModel and > UserFederationMappers). Config now supports a MultivaluedHashmap > instead of a flat Map to support list storage. There is a common REST > API under the realm that should be usable for all component types. The > UserStorage SPI uses this new SPI from top to bottom. > > We should consider whether we want to migrate other component types to > this new model. > > When you create components to store, you specify a parentId (i.e. Realm, > Client, a parent component), a provider type, a provider id, and > config. For export, the json model will contain components under Realm > and Client where the perspective parentId is Realm and Client. I still > want to make this as human consumable as possible so that these > components can be defined by humans in json. > > Bill > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160818/88a9cecd/attachment.html From sthorger at redhat.com Thu Aug 18 04:17:33 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Thu, 18 Aug 2016 10:17:33 +0200 Subject: [keycloak-dev] Dynamic client registrations without initial-access-token In-Reply-To: <57AC9A1A.6070304@redhat.com> References: <57AC9A1A.6070304@redhat.com> Message-ID: I'm not sure how useful this is, nor do I think it's particularly safe. There's nothing to stop someone sending a request and masking a different IP address. It would have to use mutual SSL to be secure. Or at least use SSL and have a callback (to confirm that request comes from the actual host), but then it's not using the OIDC standard protocol anymore. Let's discuss it in more detail when you're back from PTO. On 11 August 2016 at 17:30, Marek Posolda wrote: > According to the specification > http://openid.net/specs/openid-connect-registration-1_ > 0.html#ClientRegistration > there is this: > > "To support open Dynamic Registration, the Client Registration Endpoint > SHOULD accept registration requests without OAuth 2.0 Access Tokens. > These requests MAY be rate-limited or otherwise limited to prevent a > denial-of-service attack on the Client Registration Endpoint." > > So it looks we need to have a way to allow dynamic client registrations > even without Initial Access Token. Without supporting it, we are not > able to move forward with OIDC conformance testsuite with "Dynamic" > profile as it seems there is not a way to retrieve initialAccessToken > from Keycloak and "inject" it to conformance testsuite. > > So I've added the possibility to define trusted hosts under "Initial > Access Tokens" tab. Client registration requests from those hosts are > permitted even without initial-access-token . It's possible to limit the > count of registrations for each host similarly like is for "Initial > Access Tokens". > > This approach allows to move forward with OIDC Conformance testsuite > with "Dynamic" profile. > > If you agree and we move forward with this approach, then we should > consider to rename "Initial Access Tokens" tab to "Client Registration" > or "Dynamic Client Registration" ? As Initial Access Tokens are anyway > related just to dynamic client registrations. > > WDYT? > > Marek > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160818/68c656bf/attachment.html From sthorger at redhat.com Thu Aug 18 04:45:28 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Thu, 18 Aug 2016 10:45:28 +0200 Subject: [keycloak-dev] Pairwise Subject Identifier In-Reply-To: References: <57AC9686.5040807@redhat.com> Message-ID: Makes sense to make this pluggable. The default should probably SHA-256( sector_identifier || local_sub || salt ). We would love a PR for this, but there's a few bits required: * OIDC clients need option for subject type and sector_identifier_uri. If not set it should default to public so existing clients continue to work. These options can just be set as client attributes so there's no need to update db schema * Admin console update for the above * PairwiseSubGeneratorSpi and default implementation * Generation of salt for clients. This should be done when a client sets subject type to pairwise * Tests and docs I'd say the PairwiseSubGeneratorSpi signature should probably be: * public String getPairwiseSub(UserModel user, ClientModel client) It might even be an option to let the default PairwiseSubGenerator provider create the salt and store it as an attribute on the client, making that part pluggable as well. On 17 August 2016 at 15:59, Martin Hardselius wrote: > I'm going to bump this, as I want to continue the discussion/provide some > input. > > Does it make sense to support more than type of pairwise subject > identifier generator? E.g through a PairwiseSubGeneratorSpi? > > Let's say I want to generate the pairwise sub as a salted hash: sub = > SHA-256( sector_identifier || local_sub || salt ) > To me, it makes sense to allow for per-client salts. These salts should > probably be generated and persisted during client creation. Thoughts? > > On Fri, 12 Aug 2016 at 09:57 Martin Hardselius < > martin.hardselius at gmail.com> wrote: > >> Thank you for your response. Did not see that ticket before. Great news! >> >> I looked into using protocol mappers to achieve this, and while it would >> work I'm worried that once KEYCLOAK-3422 has been resolved and included in >> a proper release we would run into migration issues if the method used for >> calculating "native" pairwise subs is different from what we implement. >> Clients could loose / be forced to re-register all their users if we decide >> to switch. The example methods in the spec are just that. Examples. Maybe >> the method/alg for computing the pairwise sub should be pluggable? >> >> -- >> Martin >> >> On Thu, 11 Aug 2016 at 17:15 Marek Posolda wrote: >> >>> Sorry for late response. >>> >>> We have JIRA created for that. You can possibly add yourself as a >>> watcher. See https://issues.jboss.org/browse/KEYCLOAK-3422 >>> >>> Maybe an alternative for you is to use protocolMappers. That should >>> allow you to "construct" the token for particular client exactly how you >>> want and also use the different value for "sub" claim. >>> >>> Another possibility is, to handle this on adapter side. We already have >>> an adapter option "principal-attribute", which specifies that application >>> will see the different attribute instead of "sub" as subject. For example >>> when in appllication you call "httpServletRequest.getRemoteUser()" it >>> will return "john" instead of "123456-unique-johns-uuid" . See >>> https://keycloak.gitbooks.io/securing-client-applications- >>> guide/content/v/2.1/topics/oidc/java/java-adapter-config.html >>> >>> Hopefully some of the options can be useful for you? >>> >>> Marek >>> >>> >>> On 02/08/16 14:13, Martin Hardselius wrote: >>> >>> Me and my team are working towards getting Keycloak, customized for our >>> needs, into production but we've identified the need for Pairwise Subject >>> Identifiers as we don't want to expose internal user ids. >>> >>> Right now, the only subject_types_supported seems to be "public". Are >>> there any near-future plans to include "pairwise"? Can we pitch in with a >>> PR to make this happen as soon as possible? >>> >>> Links to relevant sections in the spec: >>> >>> http://openid.net/specs/openid-connect-core-1_0.html#SubjectIDTypes >>> http://openid.net/specs/openid-connect-core-1_0.html#PairwiseAlg >>> >>> -- >>> Martin >>> >>> >>> _______________________________________________ >>> keycloak-dev mailing listkeycloak-dev at lists.jboss.orghttps://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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160818/3f14a1ef/attachment-0001.html From sthorger at redhat.com Thu Aug 18 04:46:28 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Thu, 18 Aug 2016 10:46:28 +0200 Subject: [keycloak-dev] Claims from UserInfo endpoint are not getting mapped by OIDC identity broker In-Reply-To: References: <1634791415.985171.1470978491849.ref@mail.yahoo.com> <1634791415.985171.1470978491849@mail.yahoo.com> Message-ID: Can you create a JIRA for this? Even better if you'd like to submit a PR as well (would love it if it came with tests as well). On 15 August 2016 at 15:14, Nalyvayko, Peter wrote: > > Let me try to explain another way. I am referring to > java\org\keycloak\broker\oidc\OIDCIdentityProvider.java and > java\org\keycloak\broker\oidc\mappers\UserAttributeMapper. As far as I > can tell, for every social login > provider supported in keycloak, there is a corresponding concrete mapper > type derived from AbstractJsonUserAttributeMapper > that allows to map the claims about authenticated end-user to user > attributes. > > UserAttributeMapper (associated with KeyCloakIdentityProvider and > OIDCIdentityProvider), on the other hand, > seems to intentionally ignore the end-user claims returned by the UserInfo > endpoint and only maps the claims in ID and Access > tokens. > > The work around is simple enough: implement a new mapper type derived > from java\org\keycloak\broker\oidc\AbstractJsonUserAttributeMapper to > map the claims returned with the > UserInfo OIDC endpoint. > > > ________________________________________ > From: keycloak-dev-bounces at lists.jboss.org [keycloak-dev-bounces at lists. > jboss.org] on behalf of Stian Thorgersen [sthorger at redhat.com] > Sent: Monday, August 15, 2016 7:07 AM > To: Peter Nalyvayko > Cc: Keycloak-dev > Subject: Re: [keycloak-dev] Claims from UserInfo endpoint are not getting > mapped by OIDC identity broker > > It should be possible to map claims from the userinfo endpoint, but > attributes are only mapped on first login. We don't currently update > attributes on subsequent logins. Maybe you are trying with an existing user? > > On 12 August 2016 at 07:08, Peter Nalyvayko ervn1 at yahoo.com>> wrote: > Hello, > It seems that there is no way to map the claims returned by the /userinfo > endpoint to user attributes. > I set up an OIDC identity broker to enable external identity broker > authentication in keycloak. Some of the > relevant information about the user, such as language, locale, etc. are > available only by calling the /userinfo point, > so I wanted to map the claims returned by the endpoint to the user > attributes using the available mappers. > Unfortunately, it seems that the Attribute Mapper can maps ID token or > Access token claims (User Attribute Mapper), and completely ignores the > userInfo claims. > Searching through the codebase, I've found that OIDC identity broker calls > AbstractJsonUserAttributeMapper.storeUserProfileForMapper to store the > user profile > returned by the call to /userinfo endpoint in the user's context data. > However, there seems to be no way > (without modifying the code that is) to map that data to the attributes of > the > federated user created by the OIDC identity broker. > > Am I missing something here or this functionality is not available out of > the box for OIDC identity broker? > > I am using keycloak version 2.1.0 > > Thank you, > --Peter > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160818/fd9bf107/attachment.html From sthorger at redhat.com Thu Aug 18 04:55:39 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Thu, 18 Aug 2016 10:55:39 +0200 Subject: [keycloak-dev] rethinking credentials In-Reply-To: <57AC8E20.3020809@redhat.com> References: <49425643-9824-9fb7-d3c0-8fea12539f94@redhat.com> <57AC8E20.3020809@redhat.com> Message-ID: If someone can do a heapdump are we not screwed anyways? They can for instance get the realm keys and also probably have access to db connection details as well. On 11 August 2016 at 16:39, Marek Posolda wrote: > I wonder if we can have UserCredentialValueModel to be more generic > store? Currently it has properties applicable just to password or OTP > credentials, but it will be better to have something more generic based > on key-value pairs though. > > For caching of credentials, should it be made configurable if > credentials are cached or not? Currently the creds from DB are always > cached, which can be an issue for someone in theory (For example if > someone do heapdump of Java process, he might be able to see the cached > credentials). > > Marek > > On 10/08/16 17:35, Bill Burke wrote: > > The credential API for users needs to change. Here are the types of > > credentials and how system interacts: > > > > 1. Creds stored, gathered, and validated by Keycloak OOTB code. > > > > 2. Creds stored in external store, but gathered and validated by > > Keycloak OOTB code. (i.e. User Storage SPI returns the credentials > > directly) > > > > 3. Creds gathered by built-in Keycloak OOTB code, but stored and > > validated externally (i.e. LDAP). > > > > 4. Creds gathered by custom Authenticators, stored and validated > externally. > > > > 5. Creds gathered by custom authenticators, stored by keycloak, > > validated by custom code. > > > > There's other combinations as well: > > > > a. Keycloak stored User, custom credential store > > > > b. User Storage Provider, keycloak stored creds > > > > c. User Storage Provider, custom credential store > > > > Credentials that are validated by Keycloak are currently cached along > > with the user. What sucks about this that some credential types require > > a database update, i.e. HOTP which needs to update a counter. So HOTP > > invalidates the user cache every single login. We also want to allow > > custom credential stores to be able to cache themselves along with the > user. > > > > What's interesting about #4 is that there really doesn't need to be any > > special SPI. The custom authenticator can lookup the factory and > > typecast it to any interface it wants to to validate the credential. > > Since our caching layer is a local-only (invalidation cache), cachable > > custom externally stored credentials just need a simple. > > > > Given all this, gonna put some iterations in on a new credential API. > > Any other thoughts? > > > > _______________________________________________ > > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160818/08e83a39/attachment.html From sthorger at redhat.com Thu Aug 18 04:57:30 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Thu, 18 Aug 2016 10:57:30 +0200 Subject: [keycloak-dev] rethinking credentials In-Reply-To: <49425643-9824-9fb7-d3c0-8fea12539f94@redhat.com> References: <49425643-9824-9fb7-d3c0-8fea12539f94@redhat.com> Message-ID: We could also enable caching of creds from LDAP with something like: * Verify plain text password against LDAP * If OK store the hashed password in the cache * Next time around we can check against in-mem only On 10 August 2016 at 17:35, Bill Burke wrote: > The credential API for users needs to change. Here are the types of > credentials and how system interacts: > > 1. Creds stored, gathered, and validated by Keycloak OOTB code. > > 2. Creds stored in external store, but gathered and validated by > Keycloak OOTB code. (i.e. User Storage SPI returns the credentials > directly) > > 3. Creds gathered by built-in Keycloak OOTB code, but stored and > validated externally (i.e. LDAP). > > 4. Creds gathered by custom Authenticators, stored and validated > externally. > > 5. Creds gathered by custom authenticators, stored by keycloak, > validated by custom code. > > There's other combinations as well: > > a. Keycloak stored User, custom credential store > > b. User Storage Provider, keycloak stored creds > > c. User Storage Provider, custom credential store > > Credentials that are validated by Keycloak are currently cached along > with the user. What sucks about this that some credential types require > a database update, i.e. HOTP which needs to update a counter. So HOTP > invalidates the user cache every single login. We also want to allow > custom credential stores to be able to cache themselves along with the > user. > > What's interesting about #4 is that there really doesn't need to be any > special SPI. The custom authenticator can lookup the factory and > typecast it to any interface it wants to to validate the credential. > Since our caching layer is a local-only (invalidation cache), cachable > custom externally stored credentials just need a simple. > > Given all this, gonna put some iterations in on a new credential API. > Any other thoughts? > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160818/eb98e1c0/attachment.html From sthorger at redhat.com Thu Aug 18 04:59:12 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Thu, 18 Aug 2016 10:59:12 +0200 Subject: [keycloak-dev] Import users from new User Federation Message-ID: Bill, Are you planing to have an option to allow import of users with the new user federation SPI? I'm not convinced we should completely remove this option. Some use-cases I could imagine: * Allow users to authenticate even if LDAP server is down * Allow migrating users away from LDAP -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160818/7b2eabde/attachment-0001.html From sthorger at redhat.com Thu Aug 18 05:12:30 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Thu, 18 Aug 2016 11:12:30 +0200 Subject: [keycloak-dev] new credential SPI In-Reply-To: References: Message-ID: On 16 August 2016 at 00:57, Bill Burke wrote: > I'm currently working on a new credential SPI that will replace existing > methods on UserProvider and UserModel, as well as replacing > UserCredentialModel, etc. This is a work in progress where we may see > multiple iterations in master. I hope to remain backward compatible, but > can't guarentee I won't break existing User Federation Providers. Here's > an initial writeup to explain things. Credentials revolve around these 4 > events that are initiated by authentication flows, the admin console, and > the account service. > > * Is the user configured for a specific credential type > > * Is a credential valid > > * What required actions must be taken for an unconfigured credential type > > * update a credential > > How each of these events is resolved will depend on the configuration of > the system and these interfaces: > > public interface CredentialInput { > String getType(); > } > > public interface CredentialInputValidator { > boolean supportsCredentialType(String credentialType); > boolean isConfiguredFor(RealmModel realm, UserModel user, String credentialType); > boolean isValid(RealmModel realm, UserModel user, CredentialInput input); > > } > > public interface CredentialInputUpdater { > boolean supportsCredentialType(String credentialType); > Set requiredActionsFor(RealmModel realm, UserModel user, String credentialType); > void updateCredential(RealmModel realm, UserModel user, CredentialInput input); > } > > > Two different types of components will be able to implement these > interfaces. UserStorageProviders (user federation) and > CredentialProviders. CredentialProviders are components configured at the > realm level. CredentialProviders are responsible for managing one or more > types of credential types and are the bridge between CredentialInput and > where the credential is stored. UserStorageProvider is always asked first > whether it can complete the requested action, then CredentialProviders are > queried in order of their priority. > > Each UserStorageProvider and/or CredentialProvider can implement the > OnUserCache callback interface discussed in my previous custom caching > email. This allows each credential type to decide whether it will be > cached or not along with the user. For example, HOTP cannot be cached. > > So, for example, there will be a KeycloakMobileOTPProvider. This deals > with Google Authenticator and FreeOTP as well as storing these things > within Keycloak storage, it also looks at the OTP policy of the realm to > determine how to update and store the OTP secret and stuff. There is also > a KeycloakPasswordProvider which hooks into Keycloak storage and the > PasswordPolicies set up by the realm. When a user is cached, the > KeycloakPasswordProvider will add the hashed password to the user cache, > the KeycloakMobileOTPProvider will add the OTP secret to cache if its not > HOTP and needs to maintain a counter. > > Let's walk through an authentication flow, specificaly for OTP. > > 1. Authenticator calls KeycloakSession.users().isConfiguredFor(realm, > user, "OTP"). If the user was loaded by a UserStorageProvider and that > provider implements the CredentialInputValidator interface, > isConfiguredFor() is called on that. If that returns false, each > CredentialProvider is iterated on to call isConfiguredFor(). > > 2. If OTP is required and not configured for the user, the Authenticator > then calls KeycloakSession.users().requiredActionsFor(...). Again, > UserStorageProvider is queried first, then the CredneitalProviders. The > first provider that returns a non-empty set will end the query and the set > of required actions will be returned. > > 3a. Let's say that in this particular example, the generic OTP Requried > Action screen is invoked. In that case, this required action provider > callsKeycloakSession.users().updateCredential. The first > UserStorageProvider or CredentialProvider that can handle this credential > type will save the credential. > > 3b. If OTP is configured for user, the OTP is obtained by the > Authenticator and KeycloakSession.users().isValid() method is called. > Again, UserStorageProvider first, then each CredentialProvider. Each > provider is queried until one returns true or the list is exhausted. FYI, > This algorithm allows for multiple OTP authenticators per user. > > ** Admin console and Account Service UIs ** > > Like we do for other components, the UserStorageProvider or > CredentialProvider can optionally provide a list of > ProviderConfigProperties for the admin console and/or account serviceso > that it can create a credential for a specific user. There will be > separate property lists for admin console and account service. If a > specific custom screen is desired, I'm pretty sure we can just allow the > develoepr to plug in their own $routeProvider for the admin console. We > don't have a pluggable mechanism for the account service yet (or a way to > generic render either). This will need to be developed eventually. > Extending admin console is fine in community, but would be hard to support. Especially as we would eventually have to move to AngularJS 2.0, which drastically changes things. I also wonder if we should provide an higher level extension to register extensions than having to do $routeProviders etc as that sounds like a fairly low level approach. Do you have any example? Account service should be completely scrapped and replaced with something more modern. The UI needs a complete revamp and it should also be changed to AngularJS and REST service to make it more customizable and extensible. > > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160818/c68b6cb7/attachment.html From martin.hardselius at gmail.com Thu Aug 18 09:09:37 2016 From: martin.hardselius at gmail.com (Martin Hardselius) Date: Thu, 18 Aug 2016 13:09:37 +0000 Subject: [keycloak-dev] Pairwise Subject Identifier In-Reply-To: References: <57AC9686.5040807@redhat.com> Message-ID: Speaking of subject_identifier_uri >From the spec: "When a sector_identifier_uri is provided, the host component of that URL is used as the Sector Identifier for the pairwise identifier calculation. The value of the sector_identifier_uri MUST be a URL using the https scheme that points to a JSON file containing an array of redirect_uri values. The values of the registered redirect_uris MUST be included in the elements of the array." What's your stance on sanity/health checking the sector_identifier_uri? URI validation is one thing, but should we also make a request to the uri in order to validate the response? The spec also mentions that the sector_identifier_uri isn't strictly required if a client has all it's redirect_uris under the same domain. How do we deal with changes to clients if the sector_identifier_uri isn't required for enabling pairwise subs? Example: I create a client, enabling pairwise subs. Valid redirect_uris are [ https://www.mydomain.com/* ]. The sector_identifier would be mydomain. Later on, I update the redirect_uris to [ https://www.mydomain.com/*, https://www.myotherdomain.com/* ] Do we * keep the old sector_identifier, or * reject the update, or * allow the update if a valid subject_identifier_uri is provided at mydomain, or * just allow it and let the client devs deal with the consequences, or * take some other path you can think of ? Having the sector_identifier_uri as a hard requirement seems safer, but it's also means more work implementing a client. Leaving it optional is a lot more scary. On Thu, 18 Aug 2016 at 10:45 Stian Thorgersen wrote: > Makes sense to make this pluggable. The default should probably SHA-256( > sector_identifier || local_sub || salt ). > > We would love a PR for this, but there's a few bits required: > > * OIDC clients need option for subject type and sector_identifier_uri. If > not set it should default to public so existing clients continue to work. > These options can just be set as client attributes so there's no need to > update db schema > * Admin console update for the above > * PairwiseSubGeneratorSpi and default implementation > * Generation of salt for clients. This should be done when a client sets > subject type to pairwise > * Tests and docs > > I'd say the PairwiseSubGeneratorSpi signature should probably be: > > * public String getPairwiseSub(UserModel user, ClientModel client) > > It might even be an option to let the default PairwiseSubGenerator > provider create the salt and store it as an attribute on the client, making > that part pluggable as well. > > On 17 August 2016 at 15:59, Martin Hardselius > wrote: > >> I'm going to bump this, as I want to continue the discussion/provide some >> input. >> >> Does it make sense to support more than type of pairwise subject >> identifier generator? E.g through a PairwiseSubGeneratorSpi? >> >> Let's say I want to generate the pairwise sub as a salted hash: sub = >> SHA-256( sector_identifier || local_sub || salt ) >> To me, it makes sense to allow for per-client salts. These salts should >> probably be generated and persisted during client creation. Thoughts? >> >> On Fri, 12 Aug 2016 at 09:57 Martin Hardselius < >> martin.hardselius at gmail.com> wrote: >> >>> Thank you for your response. Did not see that ticket before. Great news! >>> >>> I looked into using protocol mappers to achieve this, and while it would >>> work I'm worried that once KEYCLOAK-3422 has been resolved and included in >>> a proper release we would run into migration issues if the method used for >>> calculating "native" pairwise subs is different from what we implement. >>> Clients could loose / be forced to re-register all their users if we decide >>> to switch. The example methods in the spec are just that. Examples. Maybe >>> the method/alg for computing the pairwise sub should be pluggable? >>> >>> -- >>> Martin >>> >>> On Thu, 11 Aug 2016 at 17:15 Marek Posolda wrote: >>> >>>> Sorry for late response. >>>> >>>> We have JIRA created for that. You can possibly add yourself as a >>>> watcher. See https://issues.jboss.org/browse/KEYCLOAK-3422 >>>> >>>> Maybe an alternative for you is to use protocolMappers. That should >>>> allow you to "construct" the token for particular client exactly how you >>>> want and also use the different value for "sub" claim. >>>> >>>> Another possibility is, to handle this on adapter side. We already have >>>> an adapter option "principal-attribute", which specifies that application >>>> will see the different attribute instead of "sub" as subject. For example >>>> when in appllication you call "httpServletRequest.getRemoteUser()" it will >>>> return "john" instead of "123456-unique-johns-uuid" . See >>>> https://keycloak.gitbooks.io/securing-client-applications-guide/content/v/2.1/topics/oidc/java/java-adapter-config.html >>>> >>>> Hopefully some of the options can be useful for you? >>>> >>>> Marek >>>> >>>> >>>> On 02/08/16 14:13, Martin Hardselius wrote: >>>> >>>> Me and my team are working towards getting Keycloak, customized for our >>>> needs, into production but we've identified the need for Pairwise Subject >>>> Identifiers as we don't want to expose internal user ids. >>>> >>>> Right now, the only subject_types_supported seems to be "public". Are >>>> there any near-future plans to include "pairwise"? Can we pitch in with a >>>> PR to make this happen as soon as possible? >>>> >>>> Links to relevant sections in the spec: >>>> >>>> http://openid.net/specs/openid-connect-core-1_0.html#SubjectIDTypes >>>> http://openid.net/specs/openid-connect-core-1_0.html#PairwiseAlg >>>> >>>> -- >>>> Martin >>>> >>>> >>>> _______________________________________________ >>>> keycloak-dev mailing listkeycloak-dev at lists.jboss.orghttps://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 >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160818/d11972ad/attachment-0001.html From vmuzikar at redhat.com Thu Aug 18 09:12:44 2016 From: vmuzikar at redhat.com (Vaclav Muzikar) Date: Thu, 18 Aug 2016 15:12:44 +0200 Subject: [keycloak-dev] Internationalization Encoding Message-ID: Hi guys, according to the docs [1] we are supporting different encodings by using a header in the internationalization resource files. I can't seem to get it working. I've used the "# encoding=UTF-8" header (exactly like in the docs) at the beginning of the file and encoded it as UTF-8, of course. Keycloak still apparently represents it as ISO-8859-1, regardless of the header. Am I doing something wrong? :) I'm attaching the testing file. Thanks. V. [1] https://keycloak.gitbooks.io/server-developer-guide/content/v/2.1/topics/themes.html#_internationalization -- V?clav Muzik?? Associate Quality Engineer Keycloak (RH-SSO) Red Hat Czech s.r.o. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160818/a726bc23/attachment.html -------------- next part -------------- A non-text attachment was scrubbed... Name: messages_cs.properties Type: application/octet-stream Size: 106 bytes Desc: not available Url : http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160818/a726bc23/attachment.obj From wadahiro at gmail.com Thu Aug 18 10:39:02 2016 From: wadahiro at gmail.com (Hiroyuki Wada) Date: Thu, 18 Aug 2016 23:39:02 +0900 Subject: [keycloak-dev] Internationalization Encoding In-Reply-To: References: Message-ID: Hello, It looks like the document is wrong. It should be "#encoding: utf-8" as discussed following URL. http://lists.jboss.org/pipermail/keycloak-dev/2016-July/007579.html Regards, -- Hiroyuki Wada wadahiro at gmail.com On Thu, Aug 18, 2016 at 10:12 PM, Vaclav Muzikar wrote: > Hi guys, > according to the docs [1] we are supporting different encodings by using a > header in the internationalization resource files. > I can't seem to get it working. I've used the "# encoding=UTF-8" header > (exactly like in the docs) at the beginning of the file and encoded it as > UTF-8, of course. Keycloak still apparently represents it as ISO-8859-1, > regardless of the header. Am I doing something wrong? :) > I'm attaching the testing file. > > Thanks. > > V. > > [1] > https://keycloak.gitbooks.io/server-developer-guide/content/v/2.1/topics/themes.html#_internationalization > > -- > V?clav Muzik?? > Associate Quality Engineer > Keycloak (RH-SSO) > Red Hat Czech s.r.o. > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev From bburke at redhat.com Thu Aug 18 13:26:39 2016 From: bburke at redhat.com (Bill Burke) Date: Thu, 18 Aug 2016 13:26:39 -0400 Subject: [keycloak-dev] new provider deployer working on branch! In-Reply-To: References: Message-ID: <27cae51c-a754-4eb4-b811-1721503b1cad@redhat.com> On 8/18/16 1:13 AM, Stian Thorgersen wrote: > One problem with this approach is that you end up having a separate > JDBC connection and transaction even if it uses the same database the > Keycloak server uses. > Something we have to fix anyways. Its on my todo list. > Take a look at > https://github.com/keycloak/keycloak/tree/master/examples/providers/domain-extension/src/main/java/org/keycloak/examples/domainextension/jpa > for example which allows adding custom entities to the main EntityManager. > I'm really not a big fan of this extension and this is something I do not want to support for product ever. Bill -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160818/aefb6ed6/attachment.html From vmuzikar at redhat.com Thu Aug 18 13:36:54 2016 From: vmuzikar at redhat.com (Vaclav Muzikar) Date: Thu, 18 Aug 2016 19:36:54 +0200 Subject: [keycloak-dev] Internationalization Encoding In-Reply-To: References: Message-ID: Thanks! That worked. We need to change it in the docs. V. On Thu, Aug 18, 2016 at 4:39 PM, Hiroyuki Wada wrote: > Hello, > > It looks like the document is wrong. > It should be "#encoding: utf-8" as discussed following URL. > > http://lists.jboss.org/pipermail/keycloak-dev/2016-July/007579.html > > Regards, > > -- > Hiroyuki Wada > wadahiro at gmail.com > > On Thu, Aug 18, 2016 at 10:12 PM, Vaclav Muzikar > wrote: > > Hi guys, > > according to the docs [1] we are supporting different encodings by using > a > > header in the internationalization resource files. > > I can't seem to get it working. I've used the "# encoding=UTF-8" header > > (exactly like in the docs) at the beginning of the file and encoded it as > > UTF-8, of course. Keycloak still apparently represents it as ISO-8859-1, > > regardless of the header. Am I doing something wrong? :) > > I'm attaching the testing file. > > > > Thanks. > > > > V. > > > > [1] > > https://keycloak.gitbooks.io/server-developer-guide/ > content/v/2.1/topics/themes.html#_internationalization > > > > -- > > V?clav Muzik?? > > Associate Quality Engineer > > Keycloak (RH-SSO) > > Red Hat Czech s.r.o. > > > > _______________________________________________ > > keycloak-dev mailing list > > keycloak-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/keycloak-dev > -- V?clav Muzik?? Associate Quality Engineer Keycloak (RH-SSO) Red Hat Czech s.r.o. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160818/7b4cce95/attachment.html From bburke at redhat.com Thu Aug 18 13:42:47 2016 From: bburke at redhat.com (Bill Burke) Date: Thu, 18 Aug 2016 13:42:47 -0400 Subject: [keycloak-dev] new deployer in master In-Reply-To: References: <6d547a5b-54ca-a0cf-a25d-a313e6871487@redhat.com> Message-ID: <782429f7-7dcc-1246-7c1b-aba4efbdc2a5@redhat.com> On 8/18/16 1:15 AM, Stian Thorgersen wrote: > > > On 8 August 2016 at 23:51, Bill Burke > wrote: > > Ok, > > New provider deployer exists in master. You can package components in > any type of deployment. i.e. within a EAR or WAR. Hot deploy works as > well. The deployers/ directory and deployment-scanner subsystem > is now > back in the server. Also added JTA transactions. So, now when a > KeycloakSession is created a new JTA transaction is associated > with the > KeycloakTransactionManager. If there was an existing JTA > transactionn, > that transaction is suspended and resumed after the keycloak session > completes. JTA TransactionManager lookup has an SPI now which you can > enable/disable in keycloaks-server.json. If no transaciton manager > exists i.e. within the testsuite, JTA is not used at all. > > > Why is the existing transaction suspended? Should it not just join the > existing transaction? > Let me clear this up, the current JTA transction is suspended if and only if KeycloakTransactionManager.begin() is invoked. All our current usages of KeycloakTransactionManager assume that a brand new "transaction" is started when used. Eventually we can add a new method that assumes the Keycloak Session is being used with a JTA transaction. In this case, KeycloakTransactionManager would be registered with an existing JTA transaction. Bill -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160818/41cab77e/attachment.html From bburke at redhat.com Thu Aug 18 13:44:34 2016 From: bburke at redhat.com (Bill Burke) Date: Thu, 18 Aug 2016 13:44:34 -0400 Subject: [keycloak-dev] new generic component storage In-Reply-To: References: Message-ID: You'd have to look at how UserStorageProvider, specifically UserStorageManager. Its not complete yet. Still need to add validation callbacks which is on my todo list. On 8/18/16 4:10 AM, Stian Thorgersen wrote: > Sounds great. Do you have an example on how to use it? Or do we need > to dig into the code in details? > > On 9 August 2016 at 15:15, Bill Burke > wrote: > > I've implemented a new generic component storage, api, REST API, and > admin console support. Classes/interfaces are in server-spi > org.keycloak.component package and created via methods in RealmModel. > It is basically a more generic form of mapper models, > UserFederationModel, etc. Components describe themselves and can be > generically rendered by the admin console. The storage model is meant > to support nested subcomponents (i.e. UserFederationModel and > UserFederationMappers). Config now supports a MultivaluedHashmap > instead of a flat Map to support list storage. There is a common REST > API under the realm that should be usable for all component > types. The > UserStorage SPI uses this new SPI from top to bottom. > > We should consider whether we want to migrate other component types to > this new model. > > When you create components to store, you specify a parentId (i.e. > Realm, > Client, a parent component), a provider type, a provider id, and > config. For export, the json model will contain components under > Realm > and Client where the perspective parentId is Realm and Client. I > still > want to make this as human consumable as possible so that these > components can be defined by humans in json. > > Bill > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160818/902723a6/attachment-0001.html From bburke at redhat.com Thu Aug 18 14:30:21 2016 From: bburke at redhat.com (Bill Burke) Date: Thu, 18 Aug 2016 14:30:21 -0400 Subject: [keycloak-dev] Import users from new User Federation In-Reply-To: References: Message-ID: <96ca98e1-f758-8e53-fac1-83f528079bc6@redhat.com> On 8/18/16 4:59 AM, Stian Thorgersen wrote: > Bill, > > Are you planing to have an option to allow import of users with the > new user federation SPI? I'm not convinced we should completely remove > this option. > The only callback that does not exist in the new SPI is validateAndProxy(). With the current federation SPI, the developer implements everything themselves for import. There are no synchronization APIs/SPIs either. > Some use-cases I could imagine: > > * Allow users to authenticate even if LDAP server is down Our current LDAP provider will not work if LDAP is down, even with the import :) > * Allow migrating users away from LDAP We can do anything we want for our LDAP implementation. This doesn't mean that the SPI should have special support methods and interfaces for synchronization and import. Bill From bburke at redhat.com Thu Aug 18 15:00:47 2016 From: bburke at redhat.com (Bill Burke) Date: Thu, 18 Aug 2016 15:00:47 -0400 Subject: [keycloak-dev] new credential SPI In-Reply-To: References: Message-ID: <98f70235-18bd-ffe7-01f5-0b4dff9b8f09@redhat.com> On 8/18/16 5:12 AM, Stian Thorgersen wrote: > > > On 16 August 2016 at 00:57, Bill Burke > wrote: > > I'm currently working on a new credential SPI that will replace > existing methods on UserProvider and UserModel, as well as > replacing UserCredentialModel, etc. This is a work in progress > where we may see multiple iterations in master. I hope to remain > backward compatible, but can't guarentee I won't break existing > User Federation Providers. Here's an initial writeup to explain > things. Credentials revolve around these 4 events that are > initiated by authentication flows, the admin console, and the > account service. > > * Is the user configured for a specific credential type > > * Is a credential valid > > * What required actions must be taken for an unconfigured > credential type > > * update a credential > > How each of these events is resolved will depend on the > configuration of the system and these interfaces: > > public interface CredentialInput { > String getType(); > } > > public interface CredentialInputValidator { > boolean supportsCredentialType(String credentialType); > boolean isConfiguredFor(RealmModel realm, UserModel user, String credentialType); > boolean isValid(RealmModel realm, UserModel user, CredentialInput input); > > } > > public interface CredentialInputUpdater { > boolean supportsCredentialType(String credentialType); > Set requiredActionsFor(RealmModel realm, UserModel user, String credentialType); > void updateCredential(RealmModel realm, UserModel user, CredentialInput input); > } > > Two different types of components will be able to implement these > interfaces. UserStorageProviders (user federation) and > CredentialProviders. CredentialProviders are components configured > at the realm level. CredentialProviders are responsible for > managing one or more types of credential types and are the bridge > between CredentialInput and where the credential is stored. > UserStorageProvider is always asked first whether it can complete > the requested action, then CredentialProviders are queried in > order of their priority. > > Each UserStorageProvider and/or CredentialProvider can implement > the OnUserCache callback interface discussed in my previous custom > caching email. This allows each credential type to decide whether > it will be cached or not along with the user. For example, HOTP > cannot be cached. > > So, for example, there will be a KeycloakMobileOTPProvider. This > deals with Google Authenticator and FreeOTP as well as storing > these things within Keycloak storage, it also looks at the OTP > policy of the realm to determine how to update and store the OTP > secret and stuff. There is also a KeycloakPasswordProvider which > hooks into Keycloak storage and the PasswordPolicies set up by the > realm. When a user is cached, the KeycloakPasswordProvider will > add the hashed password to the user cache, the > KeycloakMobileOTPProvider will add the OTP secret to cache if its > not HOTP and needs to maintain a counter. > > Let's walk through an authentication flow, specificaly for OTP. > > 1. Authenticator calls > KeycloakSession.users().isConfiguredFor(realm, user, "OTP"). If > the user was loaded by a UserStorageProvider and that provider > implements the CredentialInputValidator interface, > isConfiguredFor() is called on that. If that returns false, each > CredentialProvider is iterated on to call isConfiguredFor(). > > 2. If OTP is required and not configured for the user, the > Authenticator then calls > KeycloakSession.users().requiredActionsFor(...). Again, > UserStorageProvider is queried first, then the > CredneitalProviders. The first provider that returns a non-empty > set will end the query and the set of required actions will be > returned. > > 3a. Let's say that in this particular example, the generic OTP > Requried Action screen is invoked. In that case, this required > action provider callsKeycloakSession.users().updateCredential. The > first UserStorageProvider or CredentialProvider that can handle > this credential type will save the credential. > > 3b. If OTP is configured for user, the OTP is obtained by the > Authenticator and KeycloakSession.users().isValid() method is > called. Again, UserStorageProvider first, then each > CredentialProvider. Each provider is queried until one returns > true or the list is exhausted. FYI, This algorithm allows for > multiple OTP authenticators per user. > > ** Admin console and Account Service UIs ** > > Like we do for other components, the UserStorageProvider or > CredentialProvider can optionally provide a list of > ProviderConfigProperties for the admin console and/or account > serviceso that it can create a credential for a specific user. > There will be separate property lists for admin console and > account service. If a specific custom screen is desired, I'm > pretty sure we can just allow the develoepr to plug in their own > $routeProvider for the admin console. We don't have a pluggable > mechanism for the account service yet (or a way to generic render > either). This will need to be developed eventually. > > Extending admin console is fine in community, but would be hard to > support. Generic rendering from a metamodel provided by a REST API is something we can and should support. It won't be completely pretty, but should work for most things. If we don't want to support Angular extensions, then the user can just completely punt and have a completely different web app to configure a specific component. > Especially as we would eventually have to move to AngularJS 2.0, which > drastically changes things. Moving to Angular 2 seems daunting. https://angular.io/docs/ts/latest/guide/upgrade.html# > I also wonder if we should provide an higher level extension to > register extensions than having to do $routeProviders etc as that > sounds like a fairly low level approach. Do you have any example? > Look at the old ldap provider for an example of overriding a specific component UI over a fallback generic one. It just has a more specific route than the generic page. > Account service should be completely scrapped and replaced with > something more modern. The UI needs a complete revamp and it should > also be changed to AngularJS and REST service to make it more > customizable and extensible. Again, we can focus on generic rendering for Account Service. Then it will translate quite easily to whatever we do here. Bill -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160818/8b1a13b8/attachment.html From srossillo at smartling.com Thu Aug 18 16:56:31 2016 From: srossillo at smartling.com (Scott Rossillo) Date: Thu, 18 Aug 2016 16:56:31 -0400 Subject: [keycloak-dev] Import users from new User Federation In-Reply-To: <96ca98e1-f758-8e53-fac1-83f528079bc6@redhat.com> References: <96ca98e1-f758-8e53-fac1-83f528079bc6@redhat.com> Message-ID: So there will still be a validate credentials callback, right? Scott Rossillo Smartling | Senior Software Engineer srossillo at smartling.com > On Aug 18, 2016, at 2:30 PM, Bill Burke wrote: > > > On 8/18/16 4:59 AM, Stian Thorgersen wrote: >> Bill, >> >> Are you planing to have an option to allow import of users with the >> new user federation SPI? I'm not convinced we should completely remove >> this option. >> > > The only callback that does not exist in the new SPI is > validateAndProxy(). With the current federation SPI, the developer > implements everything themselves for import. There are no > synchronization APIs/SPIs either. >> Some use-cases I could imagine: >> >> * Allow users to authenticate even if LDAP server is down > Our current LDAP provider will not work if LDAP is down, even with the > import :) > > >> * Allow migrating users away from LDAP > > We can do anything we want for our LDAP implementation. This doesn't > mean that the SPI should have special support methods and interfaces for > synchronization and import. > > Bill > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160818/d8be5455/attachment-0001.html From bburke at redhat.com Thu Aug 18 17:20:36 2016 From: bburke at redhat.com (Bill Burke) Date: Thu, 18 Aug 2016 17:20:36 -0400 Subject: [keycloak-dev] Import users from new User Federation In-Reply-To: References: <96ca98e1-f758-8e53-fac1-83f528079bc6@redhat.com> Message-ID: On 8/18/16 4:56 PM, Scott Rossillo wrote: > So there will still be a validate credentials callback, right? > Yes. From mitya at cargosoft.ru Thu Aug 18 17:34:41 2016 From: mitya at cargosoft.ru (Dmitry Telegin) Date: Fri, 19 Aug 2016 00:34:41 +0300 Subject: [keycloak-dev] Preferred storage mechanism for custom settings In-Reply-To: References: <1468323778.4229.4.camel@cargosoft.ru> <1468607337.4292.5.camel@cargosoft.ru> <1468874146.6797.11.camel@cargosoft.ru> <1471099636.5196.11.camel@cargosoft.ru> <1471374383.480.4.camel@cargosoft.ru> Message-ID: <1471556081.4199.4.camel@cargosoft.ru> Ah, that simple. Please take a look at the PR. Note: in RealmTest::assertRealm, while comparing initial vs. created realm, ?we have to check for inclusion of attributes, not equality (of attribute maps). This is because the JPA realm impl adds a lot of attributes itself, and they're now returned by the endpoint. Dmitry ? ??, 17/08/2016 ? 09:44 +0200, Stian Thorgersen ?????: > > Take a look at ClientAdapter/ClientEntity. The ClientEntity for Mongo just returns the list, while the ClientAdapter does the rest. > > > > On 16 August 2016 at 21:06, Dmitry Telegin wrote: > > Hi, > > > > > > > > I've started implementing attributes for Mongo. I've begun with adding attribute methods to?org.keycloak.models.entities.RealmEntity (base class for MongoRealmEntity), but ended up with the following: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > java.lang.IllegalArgumentException: Invalid accessor method, must have zero arguments if starts with 'get'. Method: public java.lang.String org.keycloak.models.entities.RealmEntity.getAttribute(java.lang.Str ing) at org.keycloak.models.utils.reflection.MethodPropertyImpl.(Meth odPropertyImpl.java:53) at org.keycloak.models.utils.reflection.Properties.createProperty(Prop erties.java:44) at org.keycloak.models.utils.reflection.PropertyQuery.getResultList(Pr opertyQuery.java:168) at org.keycloak.models.utils.reflection.PropertyQuery.getWritableResul tList(PropertyQuery.java:140) at org.keycloak.connections.mongo.impl.MongoStoreImpl.getEntityInfo(Mo ngoStoreImpl.java:433) at org.keycloak.connections.mongo.impl.MongoStoreImpl.(MongoStor eImpl.java:101) at org.keycloak.connections.mongo.DefaultMongoConnectionFactoryProvide r.lazyInit(DefaultMongoConnectionFactoryProvider.java:156) > > > > Seems like KeyCloak's query system doesn't like entities with pseudo-getter methods. Any suggestions? > > > > Dmitry > > > > > > > > Sounds like you're on the right track. You'd need to implement support for Mongo as well though as we can't accept it otherwise. > > > > > > > > > > > > With regards to tests I'd add to?org.keycloak.testsuite.admin.realm.RealmTest which would also make sure attributes work correctly when added through the admin endpoints. > > > > > > > > > > > > On 13 August 2016 at 16:47, Dmitry Telegin wrote: > > > > Hi, > > > > > > > > (As Stian is on vacation now, I'd appreciate if someone other helps me with this feature.) > > > > > > > > > > > > Please take a look?https://github.com/keycloak/keycloak/compare /2.1.0.Final...cargosoft:KEYCLOAK-3327 > > > > > > > > > > > > (it has been branched off 2.1.0.Final for the ease of testing, I'll rebase it onto master if needed) > > > > > > > > > > > > o.k.models.RealmModel: added methods (borrowed signatures from jpa.RealmAdapter) > > > > o.k.models.jpa.RealmAdapter: added @Override annotations > > > > > > > > o.k.models.mongo.keycloak.adapters.RealmAdapter: added stubs (throwing?UnsupportedOperationException) > > > > > > > > o.k.models.cache.infinispan.RealmAdapter: added attributes caching logic > > > > > > > > o.k.models.cache.infinispan.entities.CachedRealm: added attributes cache (as Map) > > > > > > > > > > > > > > > > > > > > > > > > As for tests, I'm afraid I'll need some guidance. org.keycloak.testsuite.model.ModelTest seems appropriate for that; but it will need support for attributes in RealmRepresentation and RealmManager. Is this the right direction? > > > > > > > > Dmitry > > > > > > > > > > > > > > > > > > > > > > > > On 18 July 2016 at 22:35, Dmitry Telegin wrote: > > > > > > Stian, > > > > > > Here we go:?https://issues.jboss.org/browse/KEYCLOAK-3327 > > > > > > > > > > > > > > > > > > > > > > > > If the fix is somewhat trivial (i.e. a matter of adding fields and getters/setters) I think I could work on a PR as well. > > > > > > > > > > > > > > > > > > > > > > > > > > > As the attributes are already available in the underlying entities it's just a matter of exposing through RealmModel and add tests for it. > > > > > ? > > > > > > > > > > > > > > > > > > > > > > > > BTW, does this mean that all the custom entities provided via Entity SPI are not by default cache-enabled (and won't be synchronized between the nodes in clustered environment)? > > > > > > > > > > > > > > > > > > If so, will it be easy to cache-enable them? Is this just a matter of providing Infinispan adapters similar to existing ones for Realm/User/Role/Client etc.? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > There's no caching for custom entities. I'd recommend using Hibernate 2nd level cache for it as it's rather tricky to create a custom one. We have our custom one because we need to support Mongo as well as users from different sources (user federation and identity brokering). > > > > > ? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Ideally, I'd like to see a current domain-extension example augmented with Infinispan cache functionality. I've got some ideas on a detailed walkthrough tutorial for building complete, full-featured KeyCloak extensions (it's a big topic I'll elaborate on a bit later); I think Infinispan- enabled entities could be covered there, too. > > > > > > > > > > > > > > > > > > > > > > > > > > > No chance we're adding cache for custom entities. It's just to hard to get right. For custom entities you should use Hibernate 2nd level cache. > > > > > ? > > > > > > Regards, > > > > > > Dmitry > > > > > > > > > > > > ? ??, 18/07/2016 ? 07:39 +0200, Stian Thorgersen ?????: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Forgot that attributes are not exposed through RealmModel. You can't access the JPA RealmAdapter directly as you'll break the cache functionality. You can create a JIRA to request attributes added to RealmModel though. > > > > > > > > > > > > > > > > > > > > > On 15 July 2016 at 20:28, Mitya wrote: > > > > > > > > Stian, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > In my provider, session.getContext().getRealm() returns an instance of?org.keycloak.models.cache.infinispan.RealmAdapter. But in order to be able to manage attributes, we need an org.keycloak.models.jpa.RealmAdapter. What's the best way to obtain it? > > > > > > > > > > > > > > > > I've yet come up with the following: > > > > > > > > > > > > > > > > RealmModel realm = session.getContext().getRealm(); > > > > > > > > > > > > > > > > > > > > > > > > RealmAdapter adapter = (RealmAdapter) session.getProvider(RealmProvider.class).getRealm(realm .getId()); > > > > > > > > > > > > > > > > > > > > > > > > > Realm attributes should be perfect for that > > > > > > > > > > > > > > > > > > > > > > > > > > > On 12 July 2016 at 13:42, Mitya wrote: > > > > > > > > > > Hi, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I'm developing a KeyCloak extension, and I want some custom (per-realm) parameters to be tuned via the GUI form. Speaking of the storage mechanism for my settings, are realm attributes suitable for that? or should I create a dedicated custom entity instead? > > > > > > > > > > > > > > > > > > > > Thx, > > > > > > > > > > Mitya > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > > > > > > > > > > > > keycloak-dev mailing list > > > > > > > > > > > > > > > > > > > > keycloak-dev at lists.jboss.org > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > https://lists.jboss.org/mailman/listinfo/keycloak-d ev > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160819/6ed0d604/attachment.html From singhrasster at gmail.com Thu Aug 18 22:06:55 2016 From: singhrasster at gmail.com (Rashmi Singh) Date: Thu, 18 Aug 2016 21:06:55 -0500 Subject: [keycloak-dev] Issue with single sign out using salesforce SP with keycloak IDP and also customizing the logout page Message-ID: Hi, I have setup a Salesforce Saml SP in keycloak. So, I basically created a new client from keycloak admin console for salesforce. This is how my SP url looks like: rashmi789-dev-ed.my.salesforce.com I edited the salesforce configuration settings to point it to the keycloak IDP. So, when I access the SP: http://rashmi789-dev-ed.my.salesforce.com I am successfully taken to the keycloak IDP page (where I have configured my Authenticator). I enter my credentials there and am able to login. But, now when I try to logout, I get the following error on the web page: We're sorry ... Invalid Request So, single sign out does not seem to be working for me. What is the issue? Is it a problem with the IDP logout url that I have configured? What I have is: http://rashmiidp.cloud.com:9990/auth/realms/saml-demo/protocol/saml my IDP Login URL is: http://rashmiidp.cloud.com:9990/auth/realms/saml-demo/protocol/saml and that seem to be perfectly fine as I am able to login without any issue. what is the issue with the logout I am seeing above when using a Salesforce SP with keycloak? Please let me know if you need me to provide more details. Also, once this issue is resolved and I am able to logout successfully, could you give some insights on how to customize the logout page? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160818/0a4ab6e3/attachment.html From sthorger at redhat.com Fri Aug 19 02:34:01 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Fri, 19 Aug 2016 08:34:01 +0200 Subject: [keycloak-dev] new provider deployer working on branch! In-Reply-To: <27cae51c-a754-4eb4-b811-1721503b1cad@redhat.com> References: <27cae51c-a754-4eb4-b811-1721503b1cad@redhat.com> Message-ID: On 18 August 2016 at 19:26, Bill Burke wrote: > > > On 8/18/16 1:13 AM, Stian Thorgersen wrote: > > One problem with this approach is that you end up having a separate JDBC > connection and transaction even if it uses the same database the Keycloak > server uses. > > Something we have to fix anyways. Its on my todo list. > > > Take a look at https://github.com/keycloak/keycloak/tree/master/examples/ > providers/domain-extension/src/main/java/org/keycloak/ > examples/domainextension/jpa for example which allows adding custom > entities to the main EntityManager. > > I'm really not a big fan of this extension and this is something I do not > want to support for product ever. > Why, please elaborate? IMO it's a really nice and simple way to add a few extra entities for custom providers. > > > Bill > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160819/a586a2f0/attachment-0001.html From sthorger at redhat.com Fri Aug 19 02:37:24 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Fri, 19 Aug 2016 08:37:24 +0200 Subject: [keycloak-dev] Import users from new User Federation In-Reply-To: <96ca98e1-f758-8e53-fac1-83f528079bc6@redhat.com> References: <96ca98e1-f758-8e53-fac1-83f528079bc6@redhat.com> Message-ID: On 18 August 2016 at 20:30, Bill Burke wrote: > > On 8/18/16 4:59 AM, Stian Thorgersen wrote: > > Bill, > > > > Are you planing to have an option to allow import of users with the > > new user federation SPI? I'm not convinced we should completely remove > > this option. > > > > The only callback that does not exist in the new SPI is > validateAndProxy(). With the current federation SPI, the developer > implements everything themselves for import. There are no > synchronization APIs/SPIs either. > Sounds like we're removing built-in features around synchronization just to make the user have to do everything themselves. > > Some use-cases I could imagine: > > > > * Allow users to authenticate even if LDAP server is down > Our current LDAP provider will not work if LDAP is down, even with the > import :) > Yes, I know. However, the fact that we don't currently support it doesn't mean we shouldn't in the future. > > > > * Allow migrating users away from LDAP > > We can do anything we want for our LDAP implementation. This doesn't > mean that the SPI should have special support methods and interfaces for > synchronization and import. > > Bill > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160819/7ed8145e/attachment.html From sthorger at redhat.com Fri Aug 19 02:38:12 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Fri, 19 Aug 2016 08:38:12 +0200 Subject: [keycloak-dev] Import users from new User Federation In-Reply-To: <96ca98e1-f758-8e53-fac1-83f528079bc6@redhat.com> References: <96ca98e1-f758-8e53-fac1-83f528079bc6@redhat.com> Message-ID: On 18 August 2016 at 20:30, Bill Burke wrote: > > On 8/18/16 4:59 AM, Stian Thorgersen wrote: > > Bill, > > > > Are you planing to have an option to allow import of users with the > > new user federation SPI? I'm not convinced we should completely remove > > this option. > > > > The only callback that does not exist in the new SPI is > validateAndProxy(). With the current federation SPI, the developer > implements everything themselves for import. There are no > synchronization APIs/SPIs either. > > Some use-cases I could imagine: > > > > * Allow users to authenticate even if LDAP server is down > Our current LDAP provider will not work if LDAP is down, even with the > import :) > > > > * Allow migrating users away from LDAP > > We can do anything we want for our LDAP implementation. This doesn't > mean that the SPI should have special support methods and interfaces for > synchronization and import. > I'd say migrating from one provider to the built-in provider (or even a different provider) is something that shouldn't be done by the provider themselves, but rather some sort of migration manager util. > > Bill > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160819/ed0fc477/attachment.html From sthorger at redhat.com Fri Aug 19 02:43:19 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Fri, 19 Aug 2016 08:43:19 +0200 Subject: [keycloak-dev] new credential SPI In-Reply-To: <98f70235-18bd-ffe7-01f5-0b4dff9b8f09@redhat.com> References: <98f70235-18bd-ffe7-01f5-0b4dff9b8f09@redhat.com> Message-ID: On 18 August 2016 at 21:00, Bill Burke wrote: > > > On 8/18/16 5:12 AM, Stian Thorgersen wrote: > > > > On 16 August 2016 at 00:57, Bill Burke wrote: > >> I'm currently working on a new credential SPI that will replace existing >> methods on UserProvider and UserModel, as well as replacing >> UserCredentialModel, etc. This is a work in progress where we may see >> multiple iterations in master. I hope to remain backward compatible, but >> can't guarentee I won't break existing User Federation Providers. Here's >> an initial writeup to explain things. Credentials revolve around these 4 >> events that are initiated by authentication flows, the admin console, and >> the account service. >> >> * Is the user configured for a specific credential type >> >> * Is a credential valid >> >> * What required actions must be taken for an unconfigured credential type >> >> * update a credential >> >> How each of these events is resolved will depend on the configuration of >> the system and these interfaces: >> >> public interface CredentialInput { >> String getType(); >> } >> >> public interface CredentialInputValidator { >> boolean supportsCredentialType(String credentialType); >> boolean isConfiguredFor(RealmModel realm, UserModel user, String credentialType); >> boolean isValid(RealmModel realm, UserModel user, CredentialInput input); >> >> } >> >> public interface CredentialInputUpdater { >> boolean supportsCredentialType(String credentialType); >> Set requiredActionsFor(RealmModel realm, UserModel user, String credentialType); >> void updateCredential(RealmModel realm, UserModel user, CredentialInput input); >> } >> >> >> Two different types of components will be able to implement these >> interfaces. UserStorageProviders (user federation) and >> CredentialProviders. CredentialProviders are components configured at the >> realm level. CredentialProviders are responsible for managing one or more >> types of credential types and are the bridge between CredentialInput and >> where the credential is stored. UserStorageProvider is always asked first >> whether it can complete the requested action, then CredentialProviders are >> queried in order of their priority. >> >> Each UserStorageProvider and/or CredentialProvider can implement the >> OnUserCache callback interface discussed in my previous custom caching >> email. This allows each credential type to decide whether it will be >> cached or not along with the user. For example, HOTP cannot be cached. >> >> So, for example, there will be a KeycloakMobileOTPProvider. This deals >> with Google Authenticator and FreeOTP as well as storing these things >> within Keycloak storage, it also looks at the OTP policy of the realm to >> determine how to update and store the OTP secret and stuff. There is also >> a KeycloakPasswordProvider which hooks into Keycloak storage and the >> PasswordPolicies set up by the realm. When a user is cached, the >> KeycloakPasswordProvider will add the hashed password to the user cache, >> the KeycloakMobileOTPProvider will add the OTP secret to cache if its not >> HOTP and needs to maintain a counter. >> >> Let's walk through an authentication flow, specificaly for OTP. >> >> 1. Authenticator calls KeycloakSession.users().isConfiguredFor(realm, >> user, "OTP"). If the user was loaded by a UserStorageProvider and that >> provider implements the CredentialInputValidator interface, >> isConfiguredFor() is called on that. If that returns false, each >> CredentialProvider is iterated on to call isConfiguredFor(). >> >> 2. If OTP is required and not configured for the user, the Authenticator >> then calls KeycloakSession.users().requiredActionsFor(...). Again, >> UserStorageProvider is queried first, then the CredneitalProviders. The >> first provider that returns a non-empty set will end the query and the set >> of required actions will be returned. >> >> 3a. Let's say that in this particular example, the generic OTP Requried >> Action screen is invoked. In that case, this required action provider >> callsKeycloakSession.users().updateCredential. The first >> UserStorageProvider or CredentialProvider that can handle this credential >> type will save the credential. >> >> 3b. If OTP is configured for user, the OTP is obtained by the >> Authenticator and KeycloakSession.users().isValid() method is called. >> Again, UserStorageProvider first, then each CredentialProvider. Each >> provider is queried until one returns true or the list is exhausted. FYI, >> This algorithm allows for multiple OTP authenticators per user. >> >> ** Admin console and Account Service UIs ** >> >> Like we do for other components, the UserStorageProvider or >> CredentialProvider can optionally provide a list of >> ProviderConfigProperties for the admin console and/or account serviceso >> that it can create a credential for a specific user. There will be >> separate property lists for admin console and account service. If a >> specific custom screen is desired, I'm pretty sure we can just allow the >> develoepr to plug in their own $routeProvider for the admin console. We >> don't have a pluggable mechanism for the account service yet (or a way to >> generic render either). This will need to be developed eventually. >> > Extending admin console is fine in community, but would be hard to > support. > > Generic rendering from a metamodel provided by a REST API is something we > can and should support. It won't be completely pretty, but should work for > most things. If we don't want to support Angular extensions, then the user > can just completely punt and have a completely different web app to > configure a specific component. > I didn't say we shouldn't support extensions to the UI, but we need to consider how to do it. If we tie it to much to Angular 1 specifics than it becomes even harder to migrate to Angular 2. > > > Especially as we would eventually have to move to AngularJS 2.0, which > drastically changes things. > > > Moving to Angular 2 seems daunting. > > https://angular.io/docs/ts/latest/guide/upgrade.html# > Yep, it's a complete rewrite! Sucks. > > > > I also wonder if we should provide an higher level extension to register > extensions than having to do $routeProviders etc as that sounds like a > fairly low level approach. Do you have any example? > > > > Look at the old ldap provider for an example of overriding a specific > component UI over a fallback generic one. It just has a more specific > route than the generic page. > > > Account service should be completely scrapped and replaced with something > more modern. The UI needs a complete revamp and it should also be changed > to AngularJS and REST service to make it more customizable and extensible. > > Again, we can focus on generic rendering for Account Service. Then it > will translate quite easily to whatever we do here. > I don't think generic rendering works for account service as it wants to be more end user friendly. Generic rendering is probably OK for the admin console most of the time, but it's never going to be brilliant for usability. > > > Bill > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160819/2ab082cd/attachment-0001.html From sthorger at redhat.com Fri Aug 19 02:50:07 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Fri, 19 Aug 2016 08:50:07 +0200 Subject: [keycloak-dev] Internationalization Encoding In-Reply-To: References: Message-ID: Done On 18 August 2016 at 19:36, Vaclav Muzikar wrote: > Thanks! That worked. We need to change it in the docs. > > V. > > On Thu, Aug 18, 2016 at 4:39 PM, Hiroyuki Wada wrote: > >> Hello, >> >> It looks like the document is wrong. >> It should be "#encoding: utf-8" as discussed following URL. >> >> http://lists.jboss.org/pipermail/keycloak-dev/2016-July/007579.html >> >> Regards, >> >> -- >> Hiroyuki Wada >> wadahiro at gmail.com >> >> On Thu, Aug 18, 2016 at 10:12 PM, Vaclav Muzikar >> wrote: >> > Hi guys, >> > according to the docs [1] we are supporting different encodings by >> using a >> > header in the internationalization resource files. >> > I can't seem to get it working. I've used the "# encoding=UTF-8" header >> > (exactly like in the docs) at the beginning of the file and encoded it >> as >> > UTF-8, of course. Keycloak still apparently represents it as ISO-8859-1, >> > regardless of the header. Am I doing something wrong? :) >> > I'm attaching the testing file. >> > >> > Thanks. >> > >> > V. >> > >> > [1] >> > https://keycloak.gitbooks.io/server-developer-guide/content/ >> v/2.1/topics/themes.html#_internationalization >> > >> > -- >> > V?clav Muzik?? >> > Associate Quality Engineer >> > Keycloak (RH-SSO) >> > Red Hat Czech s.r.o. >> > >> > _______________________________________________ >> > keycloak-dev mailing list >> > keycloak-dev at lists.jboss.org >> > https://lists.jboss.org/mailman/listinfo/keycloak-dev >> > > > > -- > V?clav Muzik?? > Associate Quality Engineer > Keycloak (RH-SSO) > Red Hat Czech s.r.o. > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160819/ab678a78/attachment.html From jdennis at redhat.com Fri Aug 19 08:52:48 2016 From: jdennis at redhat.com (John Dennis) Date: Fri, 19 Aug 2016 08:52:48 -0400 Subject: [keycloak-dev] Issue with single sign out using salesforce SP with keycloak IDP and also customizing the logout page In-Reply-To: References: Message-ID: On 08/18/2016 10:06 PM, Rashmi Singh wrote: > Hi, > > I have setup a Salesforce Saml SP in keycloak. So, I basically created a > new client from keycloak admin console for salesforce. This is how my SP > url looks like: > > rashmi789-dev-ed.my.salesforce.com > > > I edited the salesforce configuration settings to point it to the > keycloak IDP. So, when I access the SP: > http://rashmi789-dev-ed.my.salesforce.com > > I am successfully taken to the keycloak IDP page (where I have > configured my Authenticator). I enter my credentials there and am able > to login. But, now when I try to logout, I get the following error on > the web page: > > We're sorry ... > Invalid Request Is logout supported on both ends (i.e. SP and IdP)? The definition of support is in the metadata of each entity. Is there a SingleLogoutService binding with a valid location URL in each metadata? The vast majority of SAML problems are directly attributable to the metadata because that is what drives the conversation between the SP and IdP. You have access to both metadata because it was necessary to load the metadata in each party. If the problem is not the absence of SingleLogoutService then I would try tracing the flow. That is easy with the Firefox browser and the SAMLTracer add-on. That will let you see the exchange of messages and identify who the offending party is. > So, single sign out does not seem to be working for me. What is the > issue? Is it a problem with the IDP logout url that I have configured? > What I have is: > > http://rashmiidp.cloud.com:9990/auth/realms/saml-demo/protocol/saml > > > my IDP Login URL is: > http://rashmiidp.cloud.com:9990/auth/realms/saml-demo/protocol/saml > > and that seem to be perfectly fine as I am able to login without any > issue. what is the issue with the logout I am seeing above when using a > Salesforce SP with keycloak? Please let me know if you need me to > provide more details. This suggests the problem is not with the IdP. Keycloak uses the same URL for all services (don't assume this is always the case, it's just one implementation choice). If login to the same URL works a valid LogoutRequest to the same URL should also work, provided of course it a valid SAML Request. Are there any errors in the Keycloak log concerning invalid requests. Once again. using SAMLTracer will help nail down who is generating the error and what the content of the message was that induced it. > Also, once this issue is resolved and I am able to logout successfully, > could you give some insights on how to customize the logout page? > > > > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > -- John From bburke at redhat.com Fri Aug 19 08:57:09 2016 From: bburke at redhat.com (Bill Burke) Date: Fri, 19 Aug 2016 08:57:09 -0400 Subject: [keycloak-dev] new provider deployer working on branch! In-Reply-To: References: <27cae51c-a754-4eb4-b811-1721503b1cad@redhat.com> Message-ID: On 8/19/16 2:34 AM, Stian Thorgersen wrote: > > > On 18 August 2016 at 19:26, Bill Burke > wrote: > > > > On 8/18/16 1:13 AM, Stian Thorgersen wrote: >> One problem with this approach is that you end up having a >> separate JDBC connection and transaction even if it uses the same >> database the Keycloak server uses. >> > Something we have to fix anyways. Its on my todo list. > > > >> Take a look at >> https://github.com/keycloak/keycloak/tree/master/examples/providers/domain-extension/src/main/java/org/keycloak/examples/domainextension/jpa >> >> for example which allows adding custom entities to the main >> EntityManager. >> > I'm really not a big fan of this extension and this is something I > do not want to support for product ever. > > > Why, please elaborate? IMO it's a really nice and simple way to add a > few extra entities for custom providers. Are you going to make our JPA entity classes public? If not, what's the point of this extension? Now that we have real deployers, its now easier to write your own persistence unit. Take a look at the example: https://github.com/keycloak/keycloak/tree/master/examples/providers/user-storage-jpa/src/main/java/org/keycloak/examples/storage/user Coding EJB and JPA is really easy, simple and fast. Also, with this extension, you have the possibility of customers being dependent on our data model and the data model becomes something that needs to be backward compatible. Bill -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160819/6f868c66/attachment.html From sthorger at redhat.com Fri Aug 19 09:04:58 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Fri, 19 Aug 2016 15:04:58 +0200 Subject: [keycloak-dev] new provider deployer working on branch! In-Reply-To: References: <27cae51c-a754-4eb4-b811-1721503b1cad@redhat.com> Message-ID: On 19 August 2016 at 14:57, Bill Burke wrote: > > > On 8/19/16 2:34 AM, Stian Thorgersen wrote: > > > > On 18 August 2016 at 19:26, Bill Burke wrote: > >> >> >> On 8/18/16 1:13 AM, Stian Thorgersen wrote: >> >> One problem with this approach is that you end up having a separate JDBC >> connection and transaction even if it uses the same database the Keycloak >> server uses. >> >> Something we have to fix anyways. Its on my todo list. >> > >> >> Take a look at https://github.com/keycloak/ke >> ycloak/tree/master/examples/providers/domain-extension/src/ >> main/java/org/keycloak/examples/domainextension/jpa for example which >> allows adding custom entities to the main EntityManager. >> >> I'm really not a big fan of this extension and this is something I do not >> want to support for product ever. >> > > Why, please elaborate? IMO it's a really nice and simple way to add a few > extra entities for custom providers. > > Are you going to make our JPA entity classes public? If not, what's the > point of this extension? Now that we have real deployers, its now easier > to write your own persistence unit. Take a look at the example: > Has nothing to do with our entity classes. It allows users to easily register an extra entity in our persistence unit, so same connection and transaction and no need to create a persistence unit at all. It also has support for Liquibase so schema is update the same way as with our stuff. Users would then get the EntityManager from the JpaConnectionProvider and be able to get their custom entities from there. It's simpler than what you have. Doesn't work if folks want a different database and such though. > > https://github.com/keycloak/keycloak/tree/master/examples/ > providers/user-storage-jpa/src/main/java/org/keycloak/ > examples/storage/user > > Coding EJB and JPA is really easy, simple and fast. > For JEE devs yes. > > Also, with this extension, you have the possibility of customers being > dependent on our data model and the data model becomes something that needs > to be backward compatible. > Nah - because our entities is in a private module and they'll get a warning if they include that in their provider. > > Bill > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160819/6be06d44/attachment-0001.html From sthorger at redhat.com Fri Aug 19 09:10:34 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Fri, 19 Aug 2016 15:10:34 +0200 Subject: [keycloak-dev] new provider deployer working on branch! In-Reply-To: References: <27cae51c-a754-4eb4-b811-1721503b1cad@redhat.com> Message-ID: By the way the custom entities thingy can be used with your new deployer as well. It's just a simpler way to add one or two custom entities. On 19 August 2016 at 15:04, Stian Thorgersen wrote: > > > On 19 August 2016 at 14:57, Bill Burke wrote: > >> >> >> On 8/19/16 2:34 AM, Stian Thorgersen wrote: >> >> >> >> On 18 August 2016 at 19:26, Bill Burke wrote: >> >>> >>> >>> On 8/18/16 1:13 AM, Stian Thorgersen wrote: >>> >>> One problem with this approach is that you end up having a separate JDBC >>> connection and transaction even if it uses the same database the Keycloak >>> server uses. >>> >>> Something we have to fix anyways. Its on my todo list. >>> >> >>> >>> Take a look at https://github.com/keycloak/ke >>> ycloak/tree/master/examples/providers/domain-extension/src/m >>> ain/java/org/keycloak/examples/domainextension/jpa for example which >>> allows adding custom entities to the main EntityManager. >>> >>> I'm really not a big fan of this extension and this is something I do >>> not want to support for product ever. >>> >> >> Why, please elaborate? IMO it's a really nice and simple way to add a few >> extra entities for custom providers. >> >> Are you going to make our JPA entity classes public? If not, what's the >> point of this extension? Now that we have real deployers, its now easier >> to write your own persistence unit. Take a look at the example: >> > > Has nothing to do with our entity classes. It allows users to easily > register an extra entity in our persistence unit, so same connection and > transaction and no need to create a persistence unit at all. It also has > support for Liquibase so schema is update the same way as with our stuff. > Users would then get the EntityManager from the JpaConnectionProvider and > be able to get their custom entities from there. > > It's simpler than what you have. Doesn't work if folks want a different > database and such though. > > >> >> https://github.com/keycloak/keycloak/tree/master/examples/pr >> oviders/user-storage-jpa/src/main/java/org/keycloak/examples/storage/user >> >> Coding EJB and JPA is really easy, simple and fast. >> > > For JEE devs yes. > > >> >> Also, with this extension, you have the possibility of customers being >> dependent on our data model and the data model becomes something that needs >> to be backward compatible. >> > > Nah - because our entities is in a private module and they'll get a > warning if they include that in their provider. > > >> >> Bill >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160819/98e3e629/attachment.html From bburke at redhat.com Fri Aug 19 09:52:16 2016 From: bburke at redhat.com (Bill Burke) Date: Fri, 19 Aug 2016 09:52:16 -0400 Subject: [keycloak-dev] Import users from new User Federation In-Reply-To: References: <96ca98e1-f758-8e53-fac1-83f528079bc6@redhat.com> Message-ID: <1d491ec6-14d8-f1f8-3dbe-ad6b5c482f66@redhat.com> On 8/19/16 2:37 AM, Stian Thorgersen wrote: > > > On 18 August 2016 at 20:30, Bill Burke > wrote: > > > On 8/18/16 4:59 AM, Stian Thorgersen wrote: > > Bill, > > > > Are you planing to have an option to allow import of users with the > > new user federation SPI? I'm not convinced we should completely > remove > > this option. > > > > The only callback that does not exist in the new SPI is > validateAndProxy(). With the current federation SPI, the developer > implements everything themselves for import. There are no > synchronization APIs/SPIs either. > > > Sounds like we're removing built-in features around synchronization > just to make the user have to do everything themselves. I think you misinterpreted me, The old User Federation SPI forces the developer to write all the import code themselves. The old User Federation SPI does not have any synchronization callbacks, methods or interfaces other than validateAndProxy(), the logic of which the user has to write themselves too. > > Some use-cases I could imagine: > > > > * Allow users to authenticate even if LDAP server is down > Our current LDAP provider will not work if LDAP is down, even with the > import :) > > > Yes, I know. However, the fact that we don't currently support it > doesn't mean we shouldn't in the future. If the user can only be authenticated via LDAP, an offline mode is not possible. In other words, if LDAP does not expose the password of a user (so it can be imported), then offline mode is not possible. It would only be possible if the user has logged in at least once, then the validated password could be imported. So, do you still think we should support import/offline mode given all this? Bill -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160819/e39c9c2a/attachment.html From bburke at redhat.com Fri Aug 19 09:59:50 2016 From: bburke at redhat.com (Bill Burke) Date: Fri, 19 Aug 2016 09:59:50 -0400 Subject: [keycloak-dev] Import users from new User Federation In-Reply-To: References: <96ca98e1-f758-8e53-fac1-83f528079bc6@redhat.com> Message-ID: On 8/19/16 2:38 AM, Stian Thorgersen wrote: > > > On 18 August 2016 at 20:30, Bill Burke > wrote: > > > On 8/18/16 4:59 AM, Stian Thorgersen wrote: > > Bill, > > > > Are you planing to have an option to allow import of users with the > > new user federation SPI? I'm not convinced we should completely > remove > > this option. > > > > The only callback that does not exist in the new SPI is > validateAndProxy(). With the current federation SPI, the developer > implements everything themselves for import. There are no > synchronization APIs/SPIs either. > > Some use-cases I could imagine: > > > > * Allow users to authenticate even if LDAP server is down > Our current LDAP provider will not work if LDAP is down, even with the > import :) > > > > * Allow migrating users away from LDAP > > We can do anything we want for our LDAP implementation. This doesn't > mean that the SPI should have special support methods and > interfaces for > synchronization and import. > > > I'd say migrating from one provider to the built-in provider (or even > a different provider) is something that shouldn't be done by the > provider themselves, but rather some sort of migration manager util. Are you just talking about LDAP? Then yes, our LDAP adapter could support it. Read my previous email though...Unless LDAP exposes passwords and other credentials so that they could be migrated, I'm not sure how an import would be done. If you're talking about any arbitrary provider, I'm not sure what we could offer for migration manager utils as we will have no idea how the data is stored. Bill -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160819/8d511f52/attachment.html From bburke at redhat.com Fri Aug 19 10:13:43 2016 From: bburke at redhat.com (Bill Burke) Date: Fri, 19 Aug 2016 10:13:43 -0400 Subject: [keycloak-dev] new provider deployer working on branch! In-Reply-To: References: <27cae51c-a754-4eb4-b811-1721503b1cad@redhat.com> Message-ID: <3569c4f1-4471-9143-0147-180b2f650c2b@redhat.com> On 8/19/16 9:04 AM, Stian Thorgersen wrote: > > > On 19 August 2016 at 14:57, Bill Burke > wrote: > > > > On 8/19/16 2:34 AM, Stian Thorgersen wrote: >> >> >> On 18 August 2016 at 19:26, Bill Burke > > wrote: >> >> >> >> On 8/18/16 1:13 AM, Stian Thorgersen wrote: >>> One problem with this approach is that you end up having a >>> separate JDBC connection and transaction even if it uses the >>> same database the Keycloak server uses. >>> >> Something we have to fix anyways. Its on my todo list. >> >> >> >>> Take a look at >>> https://github.com/keycloak/keycloak/tree/master/examples/providers/domain-extension/src/main/java/org/keycloak/examples/domainextension/jpa >>> >>> for example which allows adding custom entities to the main >>> EntityManager. >>> >> I'm really not a big fan of this extension and this is >> something I do not want to support for product ever. >> >> >> Why, please elaborate? IMO it's a really nice and simple way to >> add a few extra entities for custom providers. > Are you going to make our JPA entity classes public? If not, > what's the point of this extension? Now that we have real > deployers, its now easier to write your own persistence unit. > Take a look at the example: > > > Has nothing to do with our entity classes. It allows users to easily > register an extra entity in our persistence unit, so same connection > and transaction and no need to create a persistence unit at all. It > also has support for Liquibase so schema is update the same way as > with our stuff. Users would then get the EntityManager from the > JpaConnectionProvider and be able to get their custom entities from there. > > It's simpler than what you have. Doesn't work if folks want a > different database and such though. I disagree. Its not simpler than using standard EJB/JPA. @PersistenceContext EntityManager em; is simpler than EntityManager em = KeycloakSession.getProvider(JpaConnectionProvider.class); You do have a point about liquibase, but then, we would also have to support Liquibase forever too... This should only be a community feature not a product one. Bill -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160819/ddd2bc91/attachment-0001.html From bburke at redhat.com Fri Aug 19 10:21:34 2016 From: bburke at redhat.com (Bill Burke) Date: Fri, 19 Aug 2016 10:21:34 -0400 Subject: [keycloak-dev] new provider deployer working on branch! In-Reply-To: <3569c4f1-4471-9143-0147-180b2f650c2b@redhat.com> References: <27cae51c-a754-4eb4-b811-1721503b1cad@redhat.com> <3569c4f1-4471-9143-0147-180b2f650c2b@redhat.com> Message-ID: <75e7ef98-af01-186a-9b83-815a06fbcd3a@redhat.com> On 8/19/16 10:13 AM, Bill Burke wrote: > > > > On 8/19/16 9:04 AM, Stian Thorgersen wrote: >> >> >> On 19 August 2016 at 14:57, Bill Burke > > wrote: >> >> >> >> On 8/19/16 2:34 AM, Stian Thorgersen wrote: >>> >>> >>> On 18 August 2016 at 19:26, Bill Burke >> > wrote: >>> >>> >>> >>> On 8/18/16 1:13 AM, Stian Thorgersen wrote: >>>> One problem with this approach is that you end up having a >>>> separate JDBC connection and transaction even if it uses >>>> the same database the Keycloak server uses. >>>> >>> Something we have to fix anyways. Its on my todo list. >>> >>> >>> >>>> Take a look at >>>> https://github.com/keycloak/keycloak/tree/master/examples/providers/domain-extension/src/main/java/org/keycloak/examples/domainextension/jpa >>>> >>>> for example which allows adding custom entities to the main >>>> EntityManager. >>>> >>> I'm really not a big fan of this extension and this is >>> something I do not want to support for product ever. >>> >>> >>> Why, please elaborate? IMO it's a really nice and simple way to >>> add a few extra entities for custom providers. >> Are you going to make our JPA entity classes public? If not, >> what's the point of this extension? Now that we have real >> deployers, its now easier to write your own persistence unit. >> Take a look at the example: >> >> >> Has nothing to do with our entity classes. It allows users to easily >> register an extra entity in our persistence unit, so same connection >> and transaction and no need to create a persistence unit at all. It >> also has support for Liquibase so schema is update the same way as >> with our stuff. Users would then get the EntityManager from the >> JpaConnectionProvider and be able to get their custom entities from >> there. >> >> It's simpler than what you have. Doesn't work if folks want a >> different database and such though. > I disagree. Its not simpler than using standard EJB/JPA. > > @PersistenceContext EntityManager em; > > is simpler than > > EntityManager em = > KeycloakSession.getProvider(JpaConnectionProvider.class); > Another reason standard EJB/JPA is simpler is that JpaConnectinProvider *requires* the developer to know and write liquibase XML for their new entities. This is a real pain in the ass. Standard JPA, the schema can be created/updated automatically. Bill -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160819/50cbd16e/attachment.html From ssilvert at redhat.com Fri Aug 19 11:55:02 2016 From: ssilvert at redhat.com (Stan Silvert) Date: Fri, 19 Aug 2016 11:55:02 -0400 Subject: [keycloak-dev] new credential SPI In-Reply-To: References: <98f70235-18bd-ffe7-01f5-0b4dff9b8f09@redhat.com> Message-ID: <57B72BD6.90301@redhat.com> On 8/19/2016 2:43 AM, Stian Thorgersen wrote: > > > On 18 August 2016 at 21:00, Bill Burke > wrote: > > > > On 8/18/16 5:12 AM, Stian Thorgersen wrote: >> >> >> On 16 August 2016 at 00:57, Bill Burke > > wrote: >> >> I'm currently working on a new credential SPI that will >> replace existing methods on UserProvider and UserModel, as >> well as replacing UserCredentialModel, etc. This is a work in >> progress where we may see multiple iterations in master. I >> hope to remain backward compatible, but can't guarentee I >> won't break existing User Federation Providers. Here's an >> initial writeup to explain things. Credentials revolve around >> these 4 events that are initiated by authentication flows, >> the admin console, and the account service. >> >> * Is the user configured for a specific credential type >> >> * Is a credential valid >> >> * What required actions must be taken for an unconfigured >> credential type >> >> * update a credential >> >> How each of these events is resolved will depend on the >> configuration of the system and these interfaces: >> >> public interfaceCredentialInput { >> String getType(); >> } >> >> public interfaceCredentialInputValidator { >> booleansupportsCredentialType(String credentialType); >> booleanisConfiguredFor(RealmModel realm, UserModel user, String credentialType); >> booleanisValid(RealmModel realm, UserModel user, CredentialInput input); >> >> } >> >> public interfaceCredentialInputUpdater { >> booleansupportsCredentialType(String credentialType); >> Set requiredActionsFor(RealmModel realm, UserModel user, String credentialType); >> voidupdateCredential(RealmModel realm, UserModel user, CredentialInput input); >> } >> >> Two different types of components will be able to implement >> these interfaces. UserStorageProviders (user federation) and >> CredentialProviders. CredentialProviders are components >> configured at the realm level. CredentialProviders are >> responsible for managing one or more types of credential >> types and are the bridge between CredentialInput and where >> the credential is stored. UserStorageProvider is always asked >> first whether it can complete the requested action, then >> CredentialProviders are queried in order of their priority. >> >> Each UserStorageProvider and/or CredentialProvider can >> implement the OnUserCache callback interface discussed in my >> previous custom caching email. This allows each credential >> type to decide whether it will be cached or not along with >> the user. For example, HOTP cannot be cached. >> >> So, for example, there will be a KeycloakMobileOTPProvider. >> This deals with Google Authenticator and FreeOTP as well as >> storing these things within Keycloak storage, it also looks >> at the OTP policy of the realm to determine how to update and >> store the OTP secret and stuff. There is also a >> KeycloakPasswordProvider which hooks into Keycloak storage >> and the PasswordPolicies set up by the realm. When a user is >> cached, the KeycloakPasswordProvider will add the hashed >> password to the user cache, the KeycloakMobileOTPProvider >> will add the OTP secret to cache if its not HOTP and needs >> to maintain a counter. >> >> Let's walk through an authentication flow, specificaly for OTP. >> >> 1. Authenticator calls >> KeycloakSession.users().isConfiguredFor(realm, user, "OTP"). >> If the user was loaded by a UserStorageProvider and that >> provider implements the CredentialInputValidator interface, >> isConfiguredFor() is called on that. If that returns false, >> each CredentialProvider is iterated on to call isConfiguredFor(). >> >> 2. If OTP is required and not configured for the user, the >> Authenticator then calls >> KeycloakSession.users().requiredActionsFor(...). Again, >> UserStorageProvider is queried first, then the >> CredneitalProviders. The first provider that returns a >> non-empty set will end the query and the set of required >> actions will be returned. >> >> 3a. Let's say that in this particular example, the generic >> OTP Requried Action screen is invoked. In that case, this >> required action provider >> callsKeycloakSession.users().updateCredential. The first >> UserStorageProvider or CredentialProvider that can handle >> this credential type will save the credential. >> >> 3b. If OTP is configured for user, the OTP is obtained by the >> Authenticator and KeycloakSession.users().isValid() method is >> called. Again, UserStorageProvider first, then each >> CredentialProvider. Each provider is queried until one >> returns true or the list is exhausted. FYI, This algorithm >> allows for multiple OTP authenticators per user. >> >> ** Admin console and Account Service UIs ** >> >> Like we do for other components, the UserStorageProvider or >> CredentialProvider can optionally provide a list of >> ProviderConfigProperties for the admin console and/or account >> serviceso that it can create a credential for a specific >> user. There will be separate property lists for admin >> console and account service. If a specific custom screen is >> desired, I'm pretty sure we can just allow the develoepr to >> plug in their own $routeProvider for the admin console. We >> don't have a pluggable mechanism for the account service yet >> (or a way to generic render either). This will need to be >> developed eventually. >> >> Extending admin console is fine in community, but would be hard >> to support. > Generic rendering from a metamodel provided by a REST API is > something we can and should support. It won't be completely > pretty, but should work for most things. If we don't want to > support Angular extensions, then the user can just completely punt > and have a completely different web app to configure a specific > component. > > > I didn't say we shouldn't support extensions to the UI, but we need to > consider how to do it. If we tie it to much to Angular 1 specifics > than it becomes even harder to migrate to Angular 2. > > > >> Especially as we would eventually have to move to AngularJS 2.0, >> which drastically changes things. > > Moving to Angular 2 seems daunting. > > https://angular.io/docs/ts/latest/guide/upgrade.html# > > > > Yep, it's a complete rewrite! Sucks. Bill, you may not be aware that I'm coming to Boston next month to attend the Angular conference. There are sessions on migrating, so at least I should be able to get on the right track and make an educated assessment of the suckiness. > > > > >> I also wonder if we should provide an higher level extension to >> register extensions than having to do $routeProviders etc as that >> sounds like a fairly low level approach. Do you have any example? >> > > > Look at the old ldap provider for an example of overriding a > specific component UI over a fallback generic one. It just has a > more specific route than the generic page. > > > >> Account service should be completely scrapped and replaced with >> something more modern. The UI needs a complete revamp and it >> should also be changed to AngularJS and REST service to make it >> more customizable and extensible. > Again, we can focus on generic rendering for Account Service. > Then it will translate quite easily to whatever we do here. > > > I don't think generic rendering works for account service as it wants > to be more end user friendly. Generic rendering is probably OK for the > admin console most of the time, but it's never going to be brilliant > for usability. I've done quite a bit of work with generic rendering. The richness and usability of the resulting UI tends to be a function of the richness of the metadata that generates it. In other words, the more you describe what you are rendering the better you can render it. We'll just have to see how much work we want to put into it. > > > > Bill > > > > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160819/f12eaca5/attachment-0001.html From mitya at cargosoft.ru Fri Aug 19 20:12:36 2016 From: mitya at cargosoft.ru (Dmitry Telegin) Date: Sat, 20 Aug 2016 03:12:36 +0300 Subject: [keycloak-dev] Securing realm resources with custom admin roles Message-ID: <1471651956.28663.68.camel@cargosoft.ru> Hi, While developing a complex production-grade KeyCloak extension I've faced the following problem. Let's say the extension provides several custom realm resources plus the relevant parts of admin console GUI. A user should be able to access this functionality only if he/she has corresponding roles: one role for read-only access, another one for full operation. The "domain-extension" example does solve the similar problem, but in a very simplistic way: the user is only checked against the built-in "admin" role. A real-world example would likely feature at least two custom roles, different from the built-in ones. Implementing this with the current KeyCloak version turned out to be a rather complex problem. To demonstrate it, I've created the following example. Throughout the example, two custom roles are used, "view-hello" and "manage-hello": https://github.com/dteleguin/custom-admin-roles The problem could be broken down into three parts: 1. Creating roles. Imagine the instructions: "After you have installed the extension, please go to Clients, select the master-realm client, add view-hello and manage-hello roles, then go to Roles, select admin, add the above roles to it. Repeat for each and every realm you've already created, but this time also with the realm-management client and realm-admin role. Don't forget to do the same for every new realm you add" - this is totally unacceptable if we are speaking of high quality software. In the example, this is fully automated (see HelloResourceProviderFactory::postInit). Adding roles to the newly created realms has become possible with the recent introduction of RealmPostCreateEvent. 2. Client-side authorization. The GUI elements in the admin console should be shown only to the users having corresponding roles. There is the global "access" AngularJS object, instantiated by GlobalCtrl and used everywhere in the admin console; it would be quite natural to use the same semantics for custom roles. In the example, AngularJS decorator mechanism is used to augment the "access" object with additional getters, reflecting custom role grants. Unfortunately, by some reason decorating GlobalCtrl directly doesn't work, so we have to decorate all the controllers (as "$controller") and then select GlobalCtrl. I'm not sure if it's a KeyCloak or AngularJS issue, since there's not much information on the net about using decorators with GlobalCtrl. 3. Server-side authorization, i.e. checking user roles in service methods of realm REST resources. This is particularly cumbersome, and imposes an ugly restriction on resource methods - all of them are required to have @Context HttpHeaders in the argument list. Otherwise it would be impossible to extract a JWS token and to deduce a realm to authorize against. The only workaround I see is to move all the service methods into a sub-resource, so that processing HttpHeaders and auth setup could be done once, while instantiating sub-resource (like this is done in o.k.services.resources.admin.AdminRoot). This is especially frustrating because any custom realm resource is a sub-resource by default, so there is no reason why it couldn't obtain a HttpHeaders object from its parent resource upon construction. Conclusion: a simple and natural requirement for an extension, which is to have custom admin roles, turns into a lot of boilerplate code, most of which is present in either form in KeyCloak. Could this functionality be simply exposed to extensions? Ideally, this should be a one-liner for extension authors, since the only information needed is the name of the role(s). I could see it like this: - an extension declares the roles. Considering possible introduction of @KeyloakProvider annotation, this could be an annotation parameter, or a separate annotation; - KeyCloak takes responsibility for creating roles in both existing and newly added realms; - GlobalCtrl augments the "access" object with the relevant getters; - upon creation, realm resources receive an?o.k.services.resources.admin.AdminAuth-like object, which could be further decorated, or used as is. What do you think? Dmitry -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160820/662fd257/attachment.html From singhrasster at gmail.com Sun Aug 21 21:35:56 2016 From: singhrasster at gmail.com (Rashmi Singh) Date: Sun, 21 Aug 2016 20:35:56 -0500 Subject: [keycloak-dev] Customize logout page on keycloak Message-ID: I would like to customize the logout page for the IDP on keycloak. Could you provide some insights/pointers on how to do this? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160821/9b0d2050/attachment.html From sthorger at redhat.com Mon Aug 22 03:38:20 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Mon, 22 Aug 2016 09:38:20 +0200 Subject: [keycloak-dev] Pairwise Subject Identifier In-Reply-To: References: <57AC9686.5040807@redhat.com> Message-ID: We need to follow the spec and verify that sector_identifier_uri points to a URL that contains the corresponding URIs. As an enhancement we could support wildcards in the JSON returned by sector_identifier_uri. For example if it returns: [ https://www.mydomain.com/*, https://www.myotherdomain.com/* ] A client with the redirect uri 'https://www.myotherdomain.com/myapp' would work On 18 August 2016 at 15:09, Martin Hardselius wrote: > Speaking of subject_identifier_uri > > From the spec: > > "When a sector_identifier_uri is provided, the host component of that URL > is used as the Sector Identifier for the pairwise identifier calculation. > The value of the sector_identifier_uri MUST be a URL using the https scheme > that points to a JSON file containing an array of redirect_uri values. > The values of the registered redirect_uris MUST be included in the > elements of the array." > > What's your stance on sanity/health checking the sector_identifier_uri? > URI validation is one thing, but should we also make a request to the uri > in order to validate the response? > > The spec also mentions that the sector_identifier_uri isn't strictly > required if a client has all it's redirect_uris under the same domain. How > do we deal with changes to clients if the sector_identifier_uri isn't > required for enabling pairwise subs? > > Example: > > I create a client, enabling pairwise subs. Valid redirect_uris are [ > https://www.mydomain.com/* ]. The sector_identifier would be mydomain. > > Later on, I update the redirect_uris to [ https://www.mydomain.com/*, > https://www.myotherdomain.com/* ] Do we > > * keep the old sector_identifier, or > * reject the update, or > * allow the update if a valid subject_identifier_uri is provided at > mydomain, or > * just allow it and let the client devs deal with the consequences, or > * take some other path you can think of ? > > Having the sector_identifier_uri as a hard requirement seems safer, but > it's also means more work implementing a client. Leaving it optional is a > lot more scary. > > > On Thu, 18 Aug 2016 at 10:45 Stian Thorgersen wrote: > >> Makes sense to make this pluggable. The default should probably SHA-256( >> sector_identifier || local_sub || salt ). >> >> We would love a PR for this, but there's a few bits required: >> >> * OIDC clients need option for subject type and sector_identifier_uri. If >> not set it should default to public so existing clients continue to work. >> These options can just be set as client attributes so there's no need to >> update db schema >> * Admin console update for the above >> * PairwiseSubGeneratorSpi and default implementation >> * Generation of salt for clients. This should be done when a client sets >> subject type to pairwise >> * Tests and docs >> >> I'd say the PairwiseSubGeneratorSpi signature should probably be: >> >> * public String getPairwiseSub(UserModel user, ClientModel client) >> >> It might even be an option to let the default PairwiseSubGenerator >> provider create the salt and store it as an attribute on the client, making >> that part pluggable as well. >> >> On 17 August 2016 at 15:59, Martin Hardselius < >> martin.hardselius at gmail.com> wrote: >> >>> I'm going to bump this, as I want to continue the discussion/provide >>> some input. >>> >>> Does it make sense to support more than type of pairwise subject >>> identifier generator? E.g through a PairwiseSubGeneratorSpi? >>> >>> Let's say I want to generate the pairwise sub as a salted hash: sub = >>> SHA-256( sector_identifier || local_sub || salt ) >>> To me, it makes sense to allow for per-client salts. These salts should >>> probably be generated and persisted during client creation. Thoughts? >>> >>> On Fri, 12 Aug 2016 at 09:57 Martin Hardselius < >>> martin.hardselius at gmail.com> wrote: >>> >>>> Thank you for your response. Did not see that ticket before. Great news! >>>> >>>> I looked into using protocol mappers to achieve this, and while it >>>> would work I'm worried that once KEYCLOAK-3422 has been resolved and >>>> included in a proper release we would run into migration issues if the >>>> method used for calculating "native" pairwise subs is different from what >>>> we implement. Clients could loose / be forced to re-register all their >>>> users if we decide to switch. The example methods in the spec are just >>>> that. Examples. Maybe the method/alg for computing the pairwise sub should >>>> be pluggable? >>>> >>>> -- >>>> Martin >>>> >>>> On Thu, 11 Aug 2016 at 17:15 Marek Posolda wrote: >>>> >>>>> Sorry for late response. >>>>> >>>>> We have JIRA created for that. You can possibly add yourself as a >>>>> watcher. See https://issues.jboss.org/browse/KEYCLOAK-3422 >>>>> >>>>> Maybe an alternative for you is to use protocolMappers. That should >>>>> allow you to "construct" the token for particular client exactly how you >>>>> want and also use the different value for "sub" claim. >>>>> >>>>> Another possibility is, to handle this on adapter side. We already >>>>> have an adapter option "principal-attribute", which specifies that >>>>> application will see the different attribute instead of "sub" as subject. >>>>> For example when in appllication you call "httpServletRequest.getRemoteUser()" >>>>> it will return "john" instead of "123456-unique-johns-uuid" . See >>>>> https://keycloak.gitbooks.io/securing-client-applications- >>>>> guide/content/v/2.1/topics/oidc/java/java-adapter-config.html >>>>> >>>>> Hopefully some of the options can be useful for you? >>>>> >>>>> Marek >>>>> >>>>> >>>>> On 02/08/16 14:13, Martin Hardselius wrote: >>>>> >>>>> Me and my team are working towards getting Keycloak, customized for >>>>> our needs, into production but we've identified the need for Pairwise >>>>> Subject Identifiers as we don't want to expose internal user ids. >>>>> >>>>> Right now, the only subject_types_supported seems to be "public". Are >>>>> there any near-future plans to include "pairwise"? Can we pitch in with a >>>>> PR to make this happen as soon as possible? >>>>> >>>>> Links to relevant sections in the spec: >>>>> >>>>> http://openid.net/specs/openid-connect-core-1_0.html#SubjectIDTypes >>>>> http://openid.net/specs/openid-connect-core-1_0.html#PairwiseAlg >>>>> >>>>> -- >>>>> Martin >>>>> >>>>> >>>>> _______________________________________________ >>>>> keycloak-dev mailing listkeycloak-dev at lists.jboss.orghttps://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 >>> >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160822/1aa544c5/attachment-0001.html From martin.hardselius at gmail.com Mon Aug 22 03:58:37 2016 From: martin.hardselius at gmail.com (Martin Hardselius) Date: Mon, 22 Aug 2016 07:58:37 +0000 Subject: [keycloak-dev] Pairwise Subject Identifier In-Reply-To: References: <57AC9686.5040807@redhat.com> Message-ID: Sounds fair enough. What about the case where you don't provide a sector_identifier_uri, set up a single redirect uri on myhost and then later go on to change that redirect uri to something on myotherhost? That would change the sector_identifier and subsequently all the user subs. Do we protect against such "mistakes" or do we warn people (in the docs and/or admin gui) that it's not a good idea to do that? On Mon, 22 Aug 2016 at 09:38 Stian Thorgersen wrote: > We need to follow the spec and verify that sector_identifier_uri points to > a URL that contains the corresponding URIs. As an enhancement we could > support wildcards in the JSON returned by sector_identifier_uri. For > example if it returns: > > [ https://www.mydomain.com/*, https://www.myotherdomain.com/* ] > > A client with the redirect uri 'https://www.myotherdomain.com/myapp' > would work > > On 18 August 2016 at 15:09, Martin Hardselius > wrote: > >> Speaking of subject_identifier_uri >> >> From the spec: >> >> "When a sector_identifier_uri is provided, the host component of that >> URL is used as the Sector Identifier for the pairwise identifier >> calculation. The value of the sector_identifier_uri MUST be a URL using >> the https scheme that points to a JSON file containing an array of >> redirect_uri values. The values of the registered redirect_uris MUST be >> included in the elements of the array." >> >> What's your stance on sanity/health checking the sector_identifier_uri? >> URI validation is one thing, but should we also make a request to the uri >> in order to validate the response? >> >> The spec also mentions that the sector_identifier_uri isn't strictly >> required if a client has all it's redirect_uris under the same domain. How >> do we deal with changes to clients if the sector_identifier_uri isn't >> required for enabling pairwise subs? >> >> Example: >> >> I create a client, enabling pairwise subs. Valid redirect_uris are [ >> https://www.mydomain.com/* ]. The sector_identifier would be mydomain. >> >> Later on, I update the redirect_uris to [ https://www.mydomain.com/*, >> https://www.myotherdomain.com/* ] Do we >> >> * keep the old sector_identifier, or >> * reject the update, or >> * allow the update if a valid subject_identifier_uri is provided at >> mydomain, or >> * just allow it and let the client devs deal with the consequences, or >> * take some other path you can think of ? >> >> Having the sector_identifier_uri as a hard requirement seems safer, but >> it's also means more work implementing a client. Leaving it optional is a >> lot more scary. >> >> >> On Thu, 18 Aug 2016 at 10:45 Stian Thorgersen >> wrote: >> >>> Makes sense to make this pluggable. The default should probably SHA-256( >>> sector_identifier || local_sub || salt ). >>> >>> We would love a PR for this, but there's a few bits required: >>> >>> * OIDC clients need option for subject type and sector_identifier_uri. >>> If not set it should default to public so existing clients continue to >>> work. These options can just be set as client attributes so there's no need >>> to update db schema >>> * Admin console update for the above >>> * PairwiseSubGeneratorSpi and default implementation >>> * Generation of salt for clients. This should be done when a client sets >>> subject type to pairwise >>> * Tests and docs >>> >>> I'd say the PairwiseSubGeneratorSpi signature should probably be: >>> >>> * public String getPairwiseSub(UserModel user, ClientModel client) >>> >>> It might even be an option to let the default PairwiseSubGenerator >>> provider create the salt and store it as an attribute on the client, making >>> that part pluggable as well. >>> >>> On 17 August 2016 at 15:59, Martin Hardselius < >>> martin.hardselius at gmail.com> wrote: >>> >>>> I'm going to bump this, as I want to continue the discussion/provide >>>> some input. >>>> >>>> Does it make sense to support more than type of pairwise subject >>>> identifier generator? E.g through a PairwiseSubGeneratorSpi? >>>> >>>> Let's say I want to generate the pairwise sub as a salted hash: sub = >>>> SHA-256( sector_identifier || local_sub || salt ) >>>> To me, it makes sense to allow for per-client salts. These salts should >>>> probably be generated and persisted during client creation. Thoughts? >>>> >>>> On Fri, 12 Aug 2016 at 09:57 Martin Hardselius < >>>> martin.hardselius at gmail.com> wrote: >>>> >>>>> Thank you for your response. Did not see that ticket before. Great >>>>> news! >>>>> >>>>> I looked into using protocol mappers to achieve this, and while it >>>>> would work I'm worried that once KEYCLOAK-3422 has been resolved and >>>>> included in a proper release we would run into migration issues if the >>>>> method used for calculating "native" pairwise subs is different from what >>>>> we implement. Clients could loose / be forced to re-register all their >>>>> users if we decide to switch. The example methods in the spec are just >>>>> that. Examples. Maybe the method/alg for computing the pairwise sub should >>>>> be pluggable? >>>>> >>>>> -- >>>>> Martin >>>>> >>>>> On Thu, 11 Aug 2016 at 17:15 Marek Posolda >>>>> wrote: >>>>> >>>>>> Sorry for late response. >>>>>> >>>>>> We have JIRA created for that. You can possibly add yourself as a >>>>>> watcher. See https://issues.jboss.org/browse/KEYCLOAK-3422 >>>>>> >>>>>> Maybe an alternative for you is to use protocolMappers. That should >>>>>> allow you to "construct" the token for particular client exactly how you >>>>>> want and also use the different value for "sub" claim. >>>>>> >>>>>> Another possibility is, to handle this on adapter side. We already >>>>>> have an adapter option "principal-attribute", which specifies that >>>>>> application will see the different attribute instead of "sub" as subject. >>>>>> For example when in appllication you call >>>>>> "httpServletRequest.getRemoteUser()" it will return "john" instead of >>>>>> "123456-unique-johns-uuid" . See >>>>>> https://keycloak.gitbooks.io/securing-client-applications-guide/content/v/2.1/topics/oidc/java/java-adapter-config.html >>>>>> >>>>>> Hopefully some of the options can be useful for you? >>>>>> >>>>>> Marek >>>>>> >>>>>> >>>>>> On 02/08/16 14:13, Martin Hardselius wrote: >>>>>> >>>>>> Me and my team are working towards getting Keycloak, customized for >>>>>> our needs, into production but we've identified the need for Pairwise >>>>>> Subject Identifiers as we don't want to expose internal user ids. >>>>>> >>>>>> Right now, the only subject_types_supported seems to be "public". Are >>>>>> there any near-future plans to include "pairwise"? Can we pitch in with a >>>>>> PR to make this happen as soon as possible? >>>>>> >>>>>> Links to relevant sections in the spec: >>>>>> >>>>>> http://openid.net/specs/openid-connect-core-1_0.html#SubjectIDTypes >>>>>> http://openid.net/specs/openid-connect-core-1_0.html#PairwiseAlg >>>>>> >>>>>> -- >>>>>> Martin >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> keycloak-dev mailing listkeycloak-dev at lists.jboss.orghttps://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 >>>> >>> >>> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160822/ee573410/attachment.html From ramunask at gmail.com Mon Aug 22 04:14:08 2016 From: ramunask at gmail.com (Ramunas) Date: Mon, 22 Aug 2016 11:14:08 +0300 Subject: [keycloak-dev] Keycloak Lithuanian translation Message-ID: Hi, I would like translate Keycloak to Lithuanian. Should I create JIRA issue https://issues.jboss.org/browse/KEYCLOAK myself? -- Regards Ram?nas Kraujutis -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160822/768fad89/attachment.html From sthorger at redhat.com Mon Aug 22 04:34:14 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Mon, 22 Aug 2016 10:34:14 +0200 Subject: [keycloak-dev] Support for manual database initialization/migration Message-ID: I've added support to manually initialize and migrate the database schema. The property 'databaseSchema' was removed and instead I added 'initializeEmpty' and 'migrationStrategy'. 'initializeEmpty' allows specifying if an empty database should be initialized or not. 'migrationStrategy' has support for update, validate and manual. Manual will write all changes required to the database to a file that can then be manually ran on the database. Manual also works in combination with initializeEmpty=false to allow manually initializing the database. I also made a change to the server startup and if there is an exception thrown during server startup it will cause the server to exit. This makes it simpler to verify if a server started successfully or not. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160822/bac405b0/attachment-0001.html From sthorger at redhat.com Mon Aug 22 04:42:24 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Mon, 22 Aug 2016 10:42:24 +0200 Subject: [keycloak-dev] Pairwise Subject Identifier In-Reply-To: References: <57AC9686.5040807@redhat.com> Message-ID: IMO it's sufficient to document the algorithm to create the sub, which should make it clear that the origin in the redirect uri will affect the sub. One client could also have multiple redirect uris with different origins so could get different sub's generated depending on the redirect uri used. On 22 August 2016 at 09:58, Martin Hardselius wrote: > Sounds fair enough. > > What about the case where you don't provide a sector_identifier_uri, set > up a single redirect uri on myhost and then later go on to change that > redirect uri to something on myotherhost? That would change the > sector_identifier and subsequently all the user subs. Do we protect against > such "mistakes" or do we warn people (in the docs and/or admin gui) that > it's not a good idea to do that? > > On Mon, 22 Aug 2016 at 09:38 Stian Thorgersen wrote: > >> We need to follow the spec and verify that sector_identifier_uri points >> to a URL that contains the corresponding URIs. As an enhancement we could >> support wildcards in the JSON returned by sector_identifier_uri. For >> example if it returns: >> >> [ https://www.mydomain.com/*, https://www.myotherdomain.com/* ] >> >> A client with the redirect uri 'https://www.myotherdomain.com/myapp' >> would work >> >> On 18 August 2016 at 15:09, Martin Hardselius < >> martin.hardselius at gmail.com> wrote: >> >>> Speaking of subject_identifier_uri >>> >>> From the spec: >>> >>> "When a sector_identifier_uri is provided, the host component of that >>> URL is used as the Sector Identifier for the pairwise identifier >>> calculation. The value of the sector_identifier_uri MUST be a URL using >>> the https scheme that points to a JSON file containing an array of >>> redirect_uri values. The values of the registered redirect_uris MUST be >>> included in the elements of the array." >>> >>> What's your stance on sanity/health checking the sector_identifier_uri? >>> URI validation is one thing, but should we also make a request to the uri >>> in order to validate the response? >>> >>> The spec also mentions that the sector_identifier_uri isn't strictly >>> required if a client has all it's redirect_uris under the same domain. How >>> do we deal with changes to clients if the sector_identifier_uri isn't >>> required for enabling pairwise subs? >>> >>> Example: >>> >>> I create a client, enabling pairwise subs. Valid redirect_uris are [ >>> https://www.mydomain.com/* ]. The sector_identifier would be mydomain. >>> >>> Later on, I update the redirect_uris to [ https://www.mydomain.com/*, >>> https://www.myotherdomain.com/* ] Do we >>> >>> * keep the old sector_identifier, or >>> * reject the update, or >>> * allow the update if a valid subject_identifier_uri is provided at >>> mydomain, or >>> * just allow it and let the client devs deal with the consequences, or >>> * take some other path you can think of ? >>> >>> Having the sector_identifier_uri as a hard requirement seems safer, but >>> it's also means more work implementing a client. Leaving it optional is a >>> lot more scary. >>> >>> >>> On Thu, 18 Aug 2016 at 10:45 Stian Thorgersen >>> wrote: >>> >>>> Makes sense to make this pluggable. The default should >>>> probably SHA-256( sector_identifier || local_sub || salt ). >>>> >>>> We would love a PR for this, but there's a few bits required: >>>> >>>> * OIDC clients need option for subject type and sector_identifier_uri. >>>> If not set it should default to public so existing clients continue to >>>> work. These options can just be set as client attributes so there's no need >>>> to update db schema >>>> * Admin console update for the above >>>> * PairwiseSubGeneratorSpi and default implementation >>>> * Generation of salt for clients. This should be done when a client >>>> sets subject type to pairwise >>>> * Tests and docs >>>> >>>> I'd say the PairwiseSubGeneratorSpi signature should probably be: >>>> >>>> * public String getPairwiseSub(UserModel user, ClientModel client) >>>> >>>> It might even be an option to let the default PairwiseSubGenerator >>>> provider create the salt and store it as an attribute on the client, making >>>> that part pluggable as well. >>>> >>>> On 17 August 2016 at 15:59, Martin Hardselius < >>>> martin.hardselius at gmail.com> wrote: >>>> >>>>> I'm going to bump this, as I want to continue the discussion/provide >>>>> some input. >>>>> >>>>> Does it make sense to support more than type of pairwise subject >>>>> identifier generator? E.g through a PairwiseSubGeneratorSpi? >>>>> >>>>> Let's say I want to generate the pairwise sub as a salted hash: sub = >>>>> SHA-256( sector_identifier || local_sub || salt ) >>>>> To me, it makes sense to allow for per-client salts. These salts >>>>> should probably be generated and persisted during client creation. Thoughts? >>>>> >>>>> On Fri, 12 Aug 2016 at 09:57 Martin Hardselius < >>>>> martin.hardselius at gmail.com> wrote: >>>>> >>>>>> Thank you for your response. Did not see that ticket before. Great >>>>>> news! >>>>>> >>>>>> I looked into using protocol mappers to achieve this, and while it >>>>>> would work I'm worried that once KEYCLOAK-3422 has been resolved and >>>>>> included in a proper release we would run into migration issues if the >>>>>> method used for calculating "native" pairwise subs is different from what >>>>>> we implement. Clients could loose / be forced to re-register all their >>>>>> users if we decide to switch. The example methods in the spec are just >>>>>> that. Examples. Maybe the method/alg for computing the pairwise sub should >>>>>> be pluggable? >>>>>> >>>>>> -- >>>>>> Martin >>>>>> >>>>>> On Thu, 11 Aug 2016 at 17:15 Marek Posolda >>>>>> wrote: >>>>>> >>>>>>> Sorry for late response. >>>>>>> >>>>>>> We have JIRA created for that. You can possibly add yourself as a >>>>>>> watcher. See https://issues.jboss.org/browse/KEYCLOAK-3422 >>>>>>> >>>>>>> Maybe an alternative for you is to use protocolMappers. That should >>>>>>> allow you to "construct" the token for particular client exactly how you >>>>>>> want and also use the different value for "sub" claim. >>>>>>> >>>>>>> Another possibility is, to handle this on adapter side. We already >>>>>>> have an adapter option "principal-attribute", which specifies that >>>>>>> application will see the different attribute instead of "sub" as subject. >>>>>>> For example when in appllication you call "httpServletRequest.getRemoteUser()" >>>>>>> it will return "john" instead of "123456-unique-johns-uuid" . See >>>>>>> https://keycloak.gitbooks.io/securing-client-applications- >>>>>>> guide/content/v/2.1/topics/oidc/java/java-adapter-config.html >>>>>>> >>>>>>> Hopefully some of the options can be useful for you? >>>>>>> >>>>>>> Marek >>>>>>> >>>>>>> >>>>>>> On 02/08/16 14:13, Martin Hardselius wrote: >>>>>>> >>>>>>> Me and my team are working towards getting Keycloak, customized for >>>>>>> our needs, into production but we've identified the need for Pairwise >>>>>>> Subject Identifiers as we don't want to expose internal user ids. >>>>>>> >>>>>>> Right now, the only subject_types_supported seems to be "public". >>>>>>> Are there any near-future plans to include "pairwise"? Can we pitch in with >>>>>>> a PR to make this happen as soon as possible? >>>>>>> >>>>>>> Links to relevant sections in the spec: >>>>>>> >>>>>>> http://openid.net/specs/openid-connect-core-1_0.html#SubjectIDTypes >>>>>>> http://openid.net/specs/openid-connect-core-1_0.html#PairwiseAlg >>>>>>> >>>>>>> -- >>>>>>> Martin >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> keycloak-dev mailing listkeycloak-dev at lists.jboss.orghttps://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 >>>>> >>>> >>>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160822/ce723cc2/attachment.html From bruno at abstractj.org Mon Aug 22 07:57:08 2016 From: bruno at abstractj.org (Bruno Oliveira) Date: Mon, 22 Aug 2016 08:57:08 -0300 Subject: [keycloak-dev] Keycloak Lithuanian translation In-Reply-To: References: Message-ID: <20160822115708.GA8834@abstractj.org> Are you planning to maintain it? On 2016-08-22, Ramunas wrote: > Hi, > > I would like translate Keycloak to Lithuanian. Should I create JIRA issue > https://issues.jboss.org/browse/KEYCLOAK myself? > > -- > Regards > Ram?nas Kraujutis > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev -- abstractj PGP: 0x84DC9914 From bruno at abstractj.org Mon Aug 22 08:00:18 2016 From: bruno at abstractj.org (Bruno Oliveira) Date: Mon, 22 Aug 2016 09:00:18 -0300 Subject: [keycloak-dev] Customize logout page on keycloak In-Reply-To: References: Message-ID: <20160822120018.GB8834@abstractj.org> Please, look at the docs[1]. [1] - https://keycloak.gitbooks.io/server-developer-guide/ On 2016-08-21, Rashmi Singh wrote: > I would like to customize the logout page for the IDP on keycloak. Could > you provide some insights/pointers on how to do this? > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev -- abstractj PGP: 0x84DC9914 From martin.hardselius at gmail.com Mon Aug 22 08:16:49 2016 From: martin.hardselius at gmail.com (Martin Hardselius) Date: Mon, 22 Aug 2016 12:16:49 +0000 Subject: [keycloak-dev] Pairwise Subject Identifier In-Reply-To: References: <57AC9686.5040807@redhat.com> Message-ID: "IMO it's sufficient to document the algorithm to create the sub, which should make it clear that the origin in the redirect uri will affect the sub." Reasonable. :) "One client could also have multiple redirect uris with different origins so could get different sub's generated depending on the redirect uri used." That case is probably caught by [...] If there are multiple hostnames in the registered redirect_uris, the Client MUST register a sector_identifier_uri. [...] On Mon, 22 Aug 2016 at 10:42 Stian Thorgersen wrote: > IMO it's sufficient to document the algorithm to create the sub, which > should make it clear that the origin in the redirect uri will affect the > sub. One client could also have multiple redirect uris with different > origins so could get different sub's generated depending on the redirect > uri used. > > On 22 August 2016 at 09:58, Martin Hardselius > wrote: > >> Sounds fair enough. >> >> What about the case where you don't provide a sector_identifier_uri, set >> up a single redirect uri on myhost and then later go on to change that >> redirect uri to something on myotherhost? That would change the >> sector_identifier and subsequently all the user subs. Do we protect against >> such "mistakes" or do we warn people (in the docs and/or admin gui) that >> it's not a good idea to do that? >> >> On Mon, 22 Aug 2016 at 09:38 Stian Thorgersen >> wrote: >> >>> We need to follow the spec and verify that sector_identifier_uri points >>> to a URL that contains the corresponding URIs. As an enhancement we could >>> support wildcards in the JSON returned by sector_identifier_uri. For >>> example if it returns: >>> >>> [ https://www.mydomain.com/*, https://www.myotherdomain.com/* ] >>> >>> A client with the redirect uri 'https://www.myotherdomain.com/myapp' >>> would work >>> >>> On 18 August 2016 at 15:09, Martin Hardselius < >>> martin.hardselius at gmail.com> wrote: >>> >>>> Speaking of subject_identifier_uri >>>> >>>> From the spec: >>>> >>>> "When a sector_identifier_uri is provided, the host component of that >>>> URL is used as the Sector Identifier for the pairwise identifier >>>> calculation. The value of the sector_identifier_uri MUST be a URL >>>> using the https scheme that points to a JSON file containing an array >>>> of redirect_uri values. The values of the registered redirect_uris MUST >>>> be included in the elements of the array." >>>> >>>> What's your stance on sanity/health checking the sector_identifier_uri? >>>> URI validation is one thing, but should we also make a request to the uri >>>> in order to validate the response? >>>> >>>> The spec also mentions that the sector_identifier_uri isn't strictly >>>> required if a client has all it's redirect_uris under the same domain. How >>>> do we deal with changes to clients if the sector_identifier_uri isn't >>>> required for enabling pairwise subs? >>>> >>>> Example: >>>> >>>> I create a client, enabling pairwise subs. Valid redirect_uris are [ >>>> https://www.mydomain.com/* ]. The sector_identifier would be mydomain. >>>> >>>> Later on, I update the redirect_uris to [ https://www.mydomain.com/*, >>>> https://www.myotherdomain.com/* ] Do we >>>> >>>> * keep the old sector_identifier, or >>>> * reject the update, or >>>> * allow the update if a valid subject_identifier_uri is provided at >>>> mydomain, or >>>> * just allow it and let the client devs deal with the consequences, or >>>> * take some other path you can think of ? >>>> >>>> Having the sector_identifier_uri as a hard requirement seems safer, but >>>> it's also means more work implementing a client. Leaving it optional is a >>>> lot more scary. >>>> >>>> >>>> On Thu, 18 Aug 2016 at 10:45 Stian Thorgersen >>>> wrote: >>>> >>>>> Makes sense to make this pluggable. The default should >>>>> probably SHA-256( sector_identifier || local_sub || salt ). >>>>> >>>>> We would love a PR for this, but there's a few bits required: >>>>> >>>>> * OIDC clients need option for subject type and sector_identifier_uri. >>>>> If not set it should default to public so existing clients continue to >>>>> work. These options can just be set as client attributes so there's no need >>>>> to update db schema >>>>> * Admin console update for the above >>>>> * PairwiseSubGeneratorSpi and default implementation >>>>> * Generation of salt for clients. This should be done when a client >>>>> sets subject type to pairwise >>>>> * Tests and docs >>>>> >>>>> I'd say the PairwiseSubGeneratorSpi signature should probably be: >>>>> >>>>> * public String getPairwiseSub(UserModel user, ClientModel client) >>>>> >>>>> It might even be an option to let the default PairwiseSubGenerator >>>>> provider create the salt and store it as an attribute on the client, making >>>>> that part pluggable as well. >>>>> >>>>> On 17 August 2016 at 15:59, Martin Hardselius < >>>>> martin.hardselius at gmail.com> wrote: >>>>> >>>>>> I'm going to bump this, as I want to continue the discussion/provide >>>>>> some input. >>>>>> >>>>>> Does it make sense to support more than type of pairwise subject >>>>>> identifier generator? E.g through a PairwiseSubGeneratorSpi? >>>>>> >>>>>> Let's say I want to generate the pairwise sub as a salted hash: sub = >>>>>> SHA-256( sector_identifier || local_sub || salt ) >>>>>> To me, it makes sense to allow for per-client salts. These salts >>>>>> should probably be generated and persisted during client creation. Thoughts? >>>>>> >>>>>> On Fri, 12 Aug 2016 at 09:57 Martin Hardselius < >>>>>> martin.hardselius at gmail.com> wrote: >>>>>> >>>>>>> Thank you for your response. Did not see that ticket before. Great >>>>>>> news! >>>>>>> >>>>>>> I looked into using protocol mappers to achieve this, and while it >>>>>>> would work I'm worried that once KEYCLOAK-3422 has been resolved and >>>>>>> included in a proper release we would run into migration issues if the >>>>>>> method used for calculating "native" pairwise subs is different from what >>>>>>> we implement. Clients could loose / be forced to re-register all their >>>>>>> users if we decide to switch. The example methods in the spec are just >>>>>>> that. Examples. Maybe the method/alg for computing the pairwise sub should >>>>>>> be pluggable? >>>>>>> >>>>>>> -- >>>>>>> Martin >>>>>>> >>>>>>> On Thu, 11 Aug 2016 at 17:15 Marek Posolda >>>>>>> wrote: >>>>>>> >>>>>>>> Sorry for late response. >>>>>>>> >>>>>>>> We have JIRA created for that. You can possibly add yourself as a >>>>>>>> watcher. See https://issues.jboss.org/browse/KEYCLOAK-3422 >>>>>>>> >>>>>>>> Maybe an alternative for you is to use protocolMappers. That should >>>>>>>> allow you to "construct" the token for particular client exactly how you >>>>>>>> want and also use the different value for "sub" claim. >>>>>>>> >>>>>>>> Another possibility is, to handle this on adapter side. We already >>>>>>>> have an adapter option "principal-attribute", which specifies that >>>>>>>> application will see the different attribute instead of "sub" as subject. >>>>>>>> For example when in appllication you call >>>>>>>> "httpServletRequest.getRemoteUser()" it will return "john" instead of >>>>>>>> "123456-unique-johns-uuid" . See >>>>>>>> https://keycloak.gitbooks.io/securing-client-applications-guide/content/v/2.1/topics/oidc/java/java-adapter-config.html >>>>>>>> >>>>>>>> Hopefully some of the options can be useful for you? >>>>>>>> >>>>>>>> Marek >>>>>>>> >>>>>>>> >>>>>>>> On 02/08/16 14:13, Martin Hardselius wrote: >>>>>>>> >>>>>>>> Me and my team are working towards getting Keycloak, customized for >>>>>>>> our needs, into production but we've identified the need for Pairwise >>>>>>>> Subject Identifiers as we don't want to expose internal user ids. >>>>>>>> >>>>>>>> Right now, the only subject_types_supported seems to be "public". >>>>>>>> Are there any near-future plans to include "pairwise"? Can we pitch in with >>>>>>>> a PR to make this happen as soon as possible? >>>>>>>> >>>>>>>> Links to relevant sections in the spec: >>>>>>>> >>>>>>>> http://openid.net/specs/openid-connect-core-1_0.html#SubjectIDTypes >>>>>>>> http://openid.net/specs/openid-connect-core-1_0.html#PairwiseAlg >>>>>>>> >>>>>>>> -- >>>>>>>> Martin >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> keycloak-dev mailing listkeycloak-dev at lists.jboss.orghttps://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 >>>>>> >>>>> >>>>> >>> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160822/3b59b189/attachment.html From ramunask at gmail.com Mon Aug 22 08:28:26 2016 From: ramunask at gmail.com (Ramunas) Date: Mon, 22 Aug 2016 15:28:26 +0300 Subject: [keycloak-dev] Keycloak Lithuanian translation In-Reply-To: <20160822115708.GA8834@abstractj.org> References: <20160822115708.GA8834@abstractj.org> Message-ID: Yes, I am planning to maintain it. On Mon, Aug 22, 2016 at 2:57 PM, Bruno Oliveira wrote: > Are you planning to maintain it? > > On 2016-08-22, Ramunas wrote: > > Hi, > > > > I would like translate Keycloak to Lithuanian. Should I create JIRA issue > > https://issues.jboss.org/browse/KEYCLOAK myself? > > > > -- > > Regards > > Ram?nas Kraujutis > > > _______________________________________________ > > keycloak-dev mailing list > > keycloak-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > -- > > abstractj > PGP: 0x84DC9914 > -- Regards Ram?nas Kraujutis -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160822/210ff049/attachment-0001.html From sthorger at redhat.com Mon Aug 22 08:51:53 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Mon, 22 Aug 2016 14:51:53 +0200 Subject: [keycloak-dev] Pairwise Subject Identifier In-Reply-To: References: <57AC9686.5040807@redhat.com> Message-ID: On 22 August 2016 at 14:16, Martin Hardselius wrote: > "IMO it's sufficient to document the algorithm to create the sub, which > should make it clear that the origin in the redirect uri will affect the > sub." > > Reasonable. :) > > "One client could also have multiple redirect uris with different origins > so could get different sub's generated depending on the redirect uri used." > > That case is probably caught by > [...] If there are multiple hostnames in the registered redirect_uris, > the Client MUST register a sector_identifier_uri. [...] > Yes, but I meant from a documentation perspective. It should be clear from the documentation that is the case. > > On Mon, 22 Aug 2016 at 10:42 Stian Thorgersen wrote: > >> IMO it's sufficient to document the algorithm to create the sub, which >> should make it clear that the origin in the redirect uri will affect the >> sub. One client could also have multiple redirect uris with different >> origins so could get different sub's generated depending on the redirect >> uri used. >> >> On 22 August 2016 at 09:58, Martin Hardselius < >> martin.hardselius at gmail.com> wrote: >> >>> Sounds fair enough. >>> >>> What about the case where you don't provide a sector_identifier_uri, set >>> up a single redirect uri on myhost and then later go on to change that >>> redirect uri to something on myotherhost? That would change the >>> sector_identifier and subsequently all the user subs. Do we protect against >>> such "mistakes" or do we warn people (in the docs and/or admin gui) that >>> it's not a good idea to do that? >>> >>> On Mon, 22 Aug 2016 at 09:38 Stian Thorgersen >>> wrote: >>> >>>> We need to follow the spec and verify that sector_identifier_uri points >>>> to a URL that contains the corresponding URIs. As an enhancement we could >>>> support wildcards in the JSON returned by sector_identifier_uri. For >>>> example if it returns: >>>> >>>> [ https://www.mydomain.com/*, https://www.myotherdomain.com/* ] >>>> >>>> A client with the redirect uri 'https://www.myotherdomain.com/myapp' >>>> would work >>>> >>>> On 18 August 2016 at 15:09, Martin Hardselius < >>>> martin.hardselius at gmail.com> wrote: >>>> >>>>> Speaking of subject_identifier_uri >>>>> >>>>> From the spec: >>>>> >>>>> "When a sector_identifier_uri is provided, the host component of that >>>>> URL is used as the Sector Identifier for the pairwise identifier >>>>> calculation. The value of the sector_identifier_uri MUST be a URL >>>>> using the https scheme that points to a JSON file containing an array >>>>> of redirect_uri values. The values of the registered redirect_uris MUST >>>>> be included in the elements of the array." >>>>> >>>>> What's your stance on sanity/health checking the >>>>> sector_identifier_uri? URI validation is one thing, but should we also make >>>>> a request to the uri in order to validate the response? >>>>> >>>>> The spec also mentions that the sector_identifier_uri isn't strictly >>>>> required if a client has all it's redirect_uris under the same domain. How >>>>> do we deal with changes to clients if the sector_identifier_uri isn't >>>>> required for enabling pairwise subs? >>>>> >>>>> Example: >>>>> >>>>> I create a client, enabling pairwise subs. Valid redirect_uris are [ >>>>> https://www.mydomain.com/* ]. The sector_identifier would be mydomain. >>>>> >>>>> Later on, I update the redirect_uris to [ https://www.mydomain.com/*, >>>>> https://www.myotherdomain.com/* ] Do we >>>>> >>>>> * keep the old sector_identifier, or >>>>> * reject the update, or >>>>> * allow the update if a valid subject_identifier_uri is provided at >>>>> mydomain, or >>>>> * just allow it and let the client devs deal with the consequences, or >>>>> * take some other path you can think of ? >>>>> >>>>> Having the sector_identifier_uri as a hard requirement seems safer, >>>>> but it's also means more work implementing a client. Leaving it optional is >>>>> a lot more scary. >>>>> >>>>> >>>>> On Thu, 18 Aug 2016 at 10:45 Stian Thorgersen >>>>> wrote: >>>>> >>>>>> Makes sense to make this pluggable. The default should >>>>>> probably SHA-256( sector_identifier || local_sub || salt ). >>>>>> >>>>>> We would love a PR for this, but there's a few bits required: >>>>>> >>>>>> * OIDC clients need option for subject type and >>>>>> sector_identifier_uri. If not set it should default to public so existing >>>>>> clients continue to work. These options can just be set as client >>>>>> attributes so there's no need to update db schema >>>>>> * Admin console update for the above >>>>>> * PairwiseSubGeneratorSpi and default implementation >>>>>> * Generation of salt for clients. This should be done when a client >>>>>> sets subject type to pairwise >>>>>> * Tests and docs >>>>>> >>>>>> I'd say the PairwiseSubGeneratorSpi signature should probably be: >>>>>> >>>>>> * public String getPairwiseSub(UserModel user, ClientModel client) >>>>>> >>>>>> It might even be an option to let the default PairwiseSubGenerator >>>>>> provider create the salt and store it as an attribute on the client, making >>>>>> that part pluggable as well. >>>>>> >>>>>> On 17 August 2016 at 15:59, Martin Hardselius < >>>>>> martin.hardselius at gmail.com> wrote: >>>>>> >>>>>>> I'm going to bump this, as I want to continue the discussion/provide >>>>>>> some input. >>>>>>> >>>>>>> Does it make sense to support more than type of pairwise subject >>>>>>> identifier generator? E.g through a PairwiseSubGeneratorSpi? >>>>>>> >>>>>>> Let's say I want to generate the pairwise sub as a salted hash: sub >>>>>>> = SHA-256( sector_identifier || local_sub || salt ) >>>>>>> To me, it makes sense to allow for per-client salts. These salts >>>>>>> should probably be generated and persisted during client creation. Thoughts? >>>>>>> >>>>>>> On Fri, 12 Aug 2016 at 09:57 Martin Hardselius < >>>>>>> martin.hardselius at gmail.com> wrote: >>>>>>> >>>>>>>> Thank you for your response. Did not see that ticket before. Great >>>>>>>> news! >>>>>>>> >>>>>>>> I looked into using protocol mappers to achieve this, and while it >>>>>>>> would work I'm worried that once KEYCLOAK-3422 has been resolved and >>>>>>>> included in a proper release we would run into migration issues if the >>>>>>>> method used for calculating "native" pairwise subs is different from what >>>>>>>> we implement. Clients could loose / be forced to re-register all their >>>>>>>> users if we decide to switch. The example methods in the spec are just >>>>>>>> that. Examples. Maybe the method/alg for computing the pairwise sub should >>>>>>>> be pluggable? >>>>>>>> >>>>>>>> -- >>>>>>>> Martin >>>>>>>> >>>>>>>> On Thu, 11 Aug 2016 at 17:15 Marek Posolda >>>>>>>> wrote: >>>>>>>> >>>>>>>>> Sorry for late response. >>>>>>>>> >>>>>>>>> We have JIRA created for that. You can possibly add yourself as a >>>>>>>>> watcher. See https://issues.jboss.org/browse/KEYCLOAK-3422 >>>>>>>>> >>>>>>>>> Maybe an alternative for you is to use protocolMappers. That >>>>>>>>> should allow you to "construct" the token for particular client exactly how >>>>>>>>> you want and also use the different value for "sub" claim. >>>>>>>>> >>>>>>>>> Another possibility is, to handle this on adapter side. We already >>>>>>>>> have an adapter option "principal-attribute", which specifies that >>>>>>>>> application will see the different attribute instead of "sub" as subject. >>>>>>>>> For example when in appllication you call "httpServletRequest.getRemoteUser()" >>>>>>>>> it will return "john" instead of "123456-unique-johns-uuid" . See >>>>>>>>> https://keycloak.gitbooks.io/securing-client-applications- >>>>>>>>> guide/content/v/2.1/topics/oidc/java/java-adapter-config.html >>>>>>>>> >>>>>>>>> Hopefully some of the options can be useful for you? >>>>>>>>> >>>>>>>>> Marek >>>>>>>>> >>>>>>>>> >>>>>>>>> On 02/08/16 14:13, Martin Hardselius wrote: >>>>>>>>> >>>>>>>>> Me and my team are working towards getting Keycloak, customized >>>>>>>>> for our needs, into production but we've identified the need for Pairwise >>>>>>>>> Subject Identifiers as we don't want to expose internal user ids. >>>>>>>>> >>>>>>>>> Right now, the only subject_types_supported seems to be "public". >>>>>>>>> Are there any near-future plans to include "pairwise"? Can we pitch in with >>>>>>>>> a PR to make this happen as soon as possible? >>>>>>>>> >>>>>>>>> Links to relevant sections in the spec: >>>>>>>>> >>>>>>>>> http://openid.net/specs/openid-connect-core-1_0.html# >>>>>>>>> SubjectIDTypes >>>>>>>>> http://openid.net/specs/openid-connect-core-1_0.html#PairwiseAlg >>>>>>>>> >>>>>>>>> -- >>>>>>>>> Martin >>>>>>>>> >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> keycloak-dev mailing listkeycloak-dev at lists.jboss.orghttps://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 >>>>>>> >>>>>> >>>>>> >>>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160822/796fb146/attachment.html From bruno at abstractj.org Mon Aug 22 09:18:43 2016 From: bruno at abstractj.org (Bruno Oliveira) Date: Mon, 22 Aug 2016 10:18:43 -0300 Subject: [keycloak-dev] Keycloak Lithuanian translation In-Reply-To: References: <20160822115708.GA8834@abstractj.org> Message-ID: <20160822131843.GA18580@abstractj.org> Unless the others disagree, I'd say go for it. On 2016-08-22, Ramunas wrote: > Yes, I am planning to maintain it. > > On Mon, Aug 22, 2016 at 2:57 PM, Bruno Oliveira wrote: > > > Are you planning to maintain it? > > > > On 2016-08-22, Ramunas wrote: > > > Hi, > > > > > > I would like translate Keycloak to Lithuanian. Should I create JIRA issue > > > https://issues.jboss.org/browse/KEYCLOAK myself? > > > > > > -- > > > Regards > > > Ram?nas Kraujutis > > > > > _______________________________________________ > > > keycloak-dev mailing list > > > keycloak-dev at lists.jboss.org > > > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > > > > -- > > > > abstractj > > PGP: 0x84DC9914 > > > > > > -- > Regards > Ram?nas Kraujutis -- abstractj PGP: 0x84DC9914 From martin.hardselius at gmail.com Mon Aug 22 09:50:44 2016 From: martin.hardselius at gmail.com (Martin Hardselius) Date: Mon, 22 Aug 2016 13:50:44 +0000 Subject: [keycloak-dev] Pairwise Subject Identifier In-Reply-To: References: <57AC9686.5040807@redhat.com> Message-ID: Ok, thanks for the clarification. Where would it make sense to put the PairwiseSubGeneratorSpi? Which package, that is? On Mon, 22 Aug 2016 at 14:51 Stian Thorgersen wrote: > On 22 August 2016 at 14:16, Martin Hardselius > wrote: > >> "IMO it's sufficient to document the algorithm to create the sub, which >> should make it clear that the origin in the redirect uri will affect the >> sub." >> >> Reasonable. :) >> >> "One client could also have multiple redirect uris with different origins >> so could get different sub's generated depending on the redirect uri used." >> >> That case is probably caught by >> [...] If there are multiple hostnames in the registered redirect_uris, >> the Client MUST register a sector_identifier_uri. [...] >> > > Yes, but I meant from a documentation perspective. It should be clear from > the documentation that is the case. > > >> >> On Mon, 22 Aug 2016 at 10:42 Stian Thorgersen >> wrote: >> >>> IMO it's sufficient to document the algorithm to create the sub, which >>> should make it clear that the origin in the redirect uri will affect the >>> sub. One client could also have multiple redirect uris with different >>> origins so could get different sub's generated depending on the redirect >>> uri used. >>> >>> On 22 August 2016 at 09:58, Martin Hardselius < >>> martin.hardselius at gmail.com> wrote: >>> >>>> Sounds fair enough. >>>> >>>> What about the case where you don't provide a sector_identifier_uri, >>>> set up a single redirect uri on myhost and then later go on to change that >>>> redirect uri to something on myotherhost? That would change the >>>> sector_identifier and subsequently all the user subs. Do we protect against >>>> such "mistakes" or do we warn people (in the docs and/or admin gui) that >>>> it's not a good idea to do that? >>>> >>>> On Mon, 22 Aug 2016 at 09:38 Stian Thorgersen >>>> wrote: >>>> >>>>> We need to follow the spec and verify that sector_identifier_uri >>>>> points to a URL that contains the corresponding URIs. As an enhancement we >>>>> could support wildcards in the JSON returned by sector_identifier_uri. For >>>>> example if it returns: >>>>> >>>>> [ https://www.mydomain.com/*, https://www.myotherdomain.com/* ] >>>>> >>>>> A client with the redirect uri 'https://www.myotherdomain.com/myapp' >>>>> would work >>>>> >>>>> On 18 August 2016 at 15:09, Martin Hardselius < >>>>> martin.hardselius at gmail.com> wrote: >>>>> >>>>>> Speaking of subject_identifier_uri >>>>>> >>>>>> From the spec: >>>>>> >>>>>> "When a sector_identifier_uri is provided, the host component of >>>>>> that URL is used as the Sector Identifier for the pairwise identifier >>>>>> calculation. The value of the sector_identifier_uri MUST be a URL >>>>>> using the https scheme that points to a JSON file containing an >>>>>> array of redirect_uri values. The values of the registered >>>>>> redirect_uris MUST be included in the elements of the array." >>>>>> >>>>>> What's your stance on sanity/health checking the >>>>>> sector_identifier_uri? URI validation is one thing, but should we also make >>>>>> a request to the uri in order to validate the response? >>>>>> >>>>>> The spec also mentions that the sector_identifier_uri isn't strictly >>>>>> required if a client has all it's redirect_uris under the same domain. How >>>>>> do we deal with changes to clients if the sector_identifier_uri isn't >>>>>> required for enabling pairwise subs? >>>>>> >>>>>> Example: >>>>>> >>>>>> I create a client, enabling pairwise subs. Valid redirect_uris are [ >>>>>> https://www.mydomain.com/* ]. The sector_identifier would be >>>>>> mydomain. >>>>>> >>>>>> Later on, I update the redirect_uris to [ https://www.mydomain.com/*, >>>>>> https://www.myotherdomain.com/* ] Do we >>>>>> >>>>>> * keep the old sector_identifier, or >>>>>> * reject the update, or >>>>>> * allow the update if a valid subject_identifier_uri is provided at >>>>>> mydomain, or >>>>>> * just allow it and let the client devs deal with the consequences, or >>>>>> * take some other path you can think of ? >>>>>> >>>>>> Having the sector_identifier_uri as a hard requirement seems safer, >>>>>> but it's also means more work implementing a client. Leaving it optional is >>>>>> a lot more scary. >>>>>> >>>>>> >>>>>> On Thu, 18 Aug 2016 at 10:45 Stian Thorgersen >>>>>> wrote: >>>>>> >>>>>>> Makes sense to make this pluggable. The default should >>>>>>> probably SHA-256( sector_identifier || local_sub || salt ). >>>>>>> >>>>>>> We would love a PR for this, but there's a few bits required: >>>>>>> >>>>>>> * OIDC clients need option for subject type and >>>>>>> sector_identifier_uri. If not set it should default to public so existing >>>>>>> clients continue to work. These options can just be set as client >>>>>>> attributes so there's no need to update db schema >>>>>>> * Admin console update for the above >>>>>>> * PairwiseSubGeneratorSpi and default implementation >>>>>>> * Generation of salt for clients. This should be done when a client >>>>>>> sets subject type to pairwise >>>>>>> * Tests and docs >>>>>>> >>>>>>> I'd say the PairwiseSubGeneratorSpi signature should probably be: >>>>>>> >>>>>>> * public String getPairwiseSub(UserModel user, ClientModel client) >>>>>>> >>>>>>> It might even be an option to let the default PairwiseSubGenerator >>>>>>> provider create the salt and store it as an attribute on the client, making >>>>>>> that part pluggable as well. >>>>>>> >>>>>>> On 17 August 2016 at 15:59, Martin Hardselius < >>>>>>> martin.hardselius at gmail.com> wrote: >>>>>>> >>>>>>>> I'm going to bump this, as I want to continue the >>>>>>>> discussion/provide some input. >>>>>>>> >>>>>>>> Does it make sense to support more than type of pairwise subject >>>>>>>> identifier generator? E.g through a PairwiseSubGeneratorSpi? >>>>>>>> >>>>>>>> Let's say I want to generate the pairwise sub as a salted hash: sub >>>>>>>> = SHA-256( sector_identifier || local_sub || salt ) >>>>>>>> To me, it makes sense to allow for per-client salts. These salts >>>>>>>> should probably be generated and persisted during client creation. Thoughts? >>>>>>>> >>>>>>>> On Fri, 12 Aug 2016 at 09:57 Martin Hardselius < >>>>>>>> martin.hardselius at gmail.com> wrote: >>>>>>>> >>>>>>>>> Thank you for your response. Did not see that ticket before. Great >>>>>>>>> news! >>>>>>>>> >>>>>>>>> I looked into using protocol mappers to achieve this, and while it >>>>>>>>> would work I'm worried that once KEYCLOAK-3422 has been resolved and >>>>>>>>> included in a proper release we would run into migration issues if the >>>>>>>>> method used for calculating "native" pairwise subs is different from what >>>>>>>>> we implement. Clients could loose / be forced to re-register all their >>>>>>>>> users if we decide to switch. The example methods in the spec are just >>>>>>>>> that. Examples. Maybe the method/alg for computing the pairwise sub should >>>>>>>>> be pluggable? >>>>>>>>> >>>>>>>>> -- >>>>>>>>> Martin >>>>>>>>> >>>>>>>>> On Thu, 11 Aug 2016 at 17:15 Marek Posolda >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>>> Sorry for late response. >>>>>>>>>> >>>>>>>>>> We have JIRA created for that. You can possibly add yourself as a >>>>>>>>>> watcher. See https://issues.jboss.org/browse/KEYCLOAK-3422 >>>>>>>>>> >>>>>>>>>> Maybe an alternative for you is to use protocolMappers. That >>>>>>>>>> should allow you to "construct" the token for particular client exactly how >>>>>>>>>> you want and also use the different value for "sub" claim. >>>>>>>>>> >>>>>>>>>> Another possibility is, to handle this on adapter side. We >>>>>>>>>> already have an adapter option "principal-attribute", which specifies that >>>>>>>>>> application will see the different attribute instead of "sub" as subject. >>>>>>>>>> For example when in appllication you call >>>>>>>>>> "httpServletRequest.getRemoteUser()" it will return "john" instead of >>>>>>>>>> "123456-unique-johns-uuid" . See >>>>>>>>>> https://keycloak.gitbooks.io/securing-client-applications-guide/content/v/2.1/topics/oidc/java/java-adapter-config.html >>>>>>>>>> >>>>>>>>>> Hopefully some of the options can be useful for you? >>>>>>>>>> >>>>>>>>>> Marek >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 02/08/16 14:13, Martin Hardselius wrote: >>>>>>>>>> >>>>>>>>>> Me and my team are working towards getting Keycloak, customized >>>>>>>>>> for our needs, into production but we've identified the need for Pairwise >>>>>>>>>> Subject Identifiers as we don't want to expose internal user ids. >>>>>>>>>> >>>>>>>>>> Right now, the only subject_types_supported seems to be "public". >>>>>>>>>> Are there any near-future plans to include "pairwise"? Can we pitch in with >>>>>>>>>> a PR to make this happen as soon as possible? >>>>>>>>>> >>>>>>>>>> Links to relevant sections in the spec: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> http://openid.net/specs/openid-connect-core-1_0.html#SubjectIDTypes >>>>>>>>>> http://openid.net/specs/openid-connect-core-1_0.html#PairwiseAlg >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> Martin >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> keycloak-dev mailing listkeycloak-dev at lists.jboss.orghttps://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 >>>>>>>> >>>>>>> >>>>>>> >>>>> >>> -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160822/7c87dc43/attachment-0001.html From mposolda at redhat.com Mon Aug 22 12:19:12 2016 From: mposolda at redhat.com (Marek Posolda) Date: Mon, 22 Aug 2016 18:19:12 +0200 Subject: [keycloak-dev] travis seems to be down In-Reply-To: References: <20160727210147.GA3027@abstractj.org> <2011162883.20344066.1469654209191.JavaMail.zimbra@redhat.com> <20160727213744.GA442@abstractj.org> <734242238.20355899.1469660571274.JavaMail.zimbra@redhat.com> <59c046c4-9409-1f13-c63a-6d6744bdd402@redhat.com> <427646040.20364950.1469665193602.JavaMail.zimbra@redhat.com> <20160728014535.GA13976@abstractj.org> <2135599354.20603917.1469718695315.JavaMail.zimbra@redhat.com> <20160816140632.GB19203@abstractj.org> Message-ID: <57BB2600.2020900@redhat.com> This looks better then my workaround of having long bash command to log "something" every 10 seconds. That worked fine as well, but didn't really look pretty :-) BTV. instead of looking at another alternative for Travis, we can maybe spend the time to tune our testsuite? We have already JIRA for it https://issues.jboss.org/browse/KEYCLOAK-3123 . The advantage is, that it will help with the speed of build on our laptops too, not just with the speed of CI. I've personally ended to always run the build with "-DskipTests=true" on my laptop as it takes forever to build with tests. Marek On 17/08/16 08:46, Stian Thorgersen wrote: > I've tweaked the stroppy toddler a bit > (https://github.com/keycloak/keycloak/pull/3147). Ran that PR 5 times > and it passed every time, so hopefully it'll make it a bit more > stable. Still takes more than 1 hour to complete though. > > On 16 August 2016 at 16:06, Bruno Oliveira > wrote: > > There are some alternatives that we could try: > > * https://www.cloudbees.com/partners/platform/red-hat > > * > https://developers.openshift.com/managing-your-applications/continuous-integration.html > > * Make use of a beefy machine :) > * Or host Jenkins in some paid cloud infrastructure > > If we don't have any volunteers, count me in. > > On 2016-08-15, Stian Thorgersen wrote: > > My opinion is that i HATE Travis! It's slow and has a tendency > to act like > > a stroppy toddler. > > > > Removing -q doesn't work because we then end up generating more > log than > > Travis allows which kills the build as well. > > > > We used to have the caching enabled, but it used to result in a > lot of > > issues. Can't quite remember the details though. Maybe we can > try it again. > > > > There's also travis_wait option that could work ( > > > https://docs.travis-ci.com/user/common-build-problems/#Build-times-out-because-no-output-was-received > > > ). > > > > My preference would be to migrate away from Travis and use > something more > > beefy that can run tests quicker. > > > > I'll need to figure out someone to look into it though. Any > volunteers? > > > > > > > > > > On 28 July 2016 at 17:11, Pedro Igor Silva > wrote: > > > > > Let's see what Stian thinks about it :) For me, it is also an > option. > > > > > > ----- Original Message ----- > > > From: "Bruno Oliveira" > > > > To: "Pedro Igor Silva" > > > > Cc: "Bill Burke" >, "keycloak-dev" < > > > keycloak-dev at lists.jboss.org > > > > > Sent: Wednesday, July 27, 2016 10:45:35 PM > > > Subject: Re: [keycloak-dev] travis seems to be down > > > > > > Another alternative, but you might not enjoy it, is :) > > > > > > Before start building Keycloak, pre-download all the '.m2' dir > with > > > the dependencies required. Second alternative, is to try some > caching[1], > > > but it may > > > or may not work. > > > > > > [1] - https://docs.travis-ci.com/user/caching/ > > > > > > > On 2016-07-27, Pedro Igor Silva wrote: > > > > As Bruno suggested, the problem is probably related with the > build > > > taking too long. If you look at the first command being executed: > > > > > > > > mvn install -Pdistribution -DskipTests=true -B -V -q > > > > > > > > The -q option tells maven to run in quite mode and only show > errors. > > > Even in my laptop, if I run the command above it takes a bit > more time to > > > show any output (not too long, but more than usual). That may > explain that > > > message from Travis. > > > > > > > > Maybe we should remove -q and just log everything. That > could make the > > > builds more stable. > > > > > > > > I've forced a new build to your https://github.com/keycloak/ > > > keycloak/pull/3079 (without changing anything to .travis.yml). > Now it is > > > running. > > > > > > > > ----- Original Message ----- > > > > From: "Bill Burke" > > > > > To: "Pedro Igor Silva" >, "Bruno Oliveira" < > > > bruno at abstractj.org > > > > > Cc: "keycloak-dev" > > > > > Sent: Wednesday, July 27, 2016 8:53:16 PM > > > > Subject: Re: [keycloak-dev] travis seems to be down > > > > > > > > Wrong... :( I still get this problem. > > > > > > > > > > > > On 7/27/16 7:02 PM, Pedro Igor Silva wrote: > > > > > I think Travis decided to not mess with Bill :) > > > > > > > > > > ----- Original Message ----- > > > > > From: "Bruno Oliveira" > > > > > > To: "Pedro Igor Silva" > > > > > > Cc: "Bill Burke" >, "keycloak-dev" < > > > keycloak-dev at lists.jboss.org > > > > > > > Sent: Wednesday, July 27, 2016 6:37:44 PM > > > > > Subject: Re: [keycloak-dev] travis seems to be down > > > > > > > > > > Seems like the balance of the Force was established again. > > > > > > > > > > On 2016-07-27, Pedro Igor Silva wrote: > > > > >> Got that error, but now the build was successful. > > > > >> > > > > >> ----- Original Message ----- > > > > >> From: "Bruno Oliveira" > > > > > >> To: "Bill Burke" > > > > > >> Cc: "keycloak-dev" > > > > > >> Sent: Wednesday, July 27, 2016 6:01:47 PM > > > > >> Subject: Re: [keycloak-dev] travis seems to be down > > > > >> > > > > >> Seems like they are fully operational[1]. I believe that > this is the > > > > >> reason: > > > > >> > > > > >> "No output has been received in the last 10 minutes, this > potentially > > > indicates a stalled build or something wrong with the build > itself." > > > > >> > > > > >> Based on my previous experiences, it happens when the > build takes too > > > > >> long. Not really sure if that's the root cause, but I can > help > > > > >> investigating it. > > > > >> > > > > >> [1] - https://www.traviscistatus.com/ > > > > > >> > > > > >> On 2016-07-27, Bill Burke wrote: > > > > >>> A lot of builds failing in initial setup > > > > >>> > > > > >>> > > > > >>> Bill > > > > >>> > > > > >>> _______________________________________________ > > > > >>> keycloak-dev mailing list > > > > >>> keycloak-dev at lists.jboss.org > > > > > >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > > > >> -- > > > > >> > > > > >> abstractj > > > > >> PGP: 0x84DC9914 > > > > >> _______________________________________________ > > > > >> keycloak-dev mailing list > > > > >> keycloak-dev at lists.jboss.org > > > > > >> https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > > > > -- > > > > > > > > > > abstractj > > > > > PGP: 0x84DC9914 > > > > > > > > > > -- > > > > > > abstractj > > > PGP: 0x84DC9914 > > > _______________________________________________ > > > keycloak-dev mailing list > > > keycloak-dev at lists.jboss.org > > > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > > > > -- > > abstractj > PGP: 0x84DC9914 > > > > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160822/1fa9da1a/attachment.html From mposolda at redhat.com Mon Aug 22 16:40:04 2016 From: mposolda at redhat.com (Marek Posolda) Date: Mon, 22 Aug 2016 22:40:04 +0200 Subject: [keycloak-dev] Pairwise Subject Identifier In-Reply-To: References: <57AC9686.5040807@redhat.com> Message-ID: <57BB6324.2030403@redhat.com> The question is, should we really introduce another SPI for that? Doesn't it mean uneccessary complexity? Also add the new options directly to the client for the feature, which is likely interesting just for quite limited amount of people? IMO it's fine if this is implemented as protocolMapper? Few thoughts: - We can have abstract superclass like AbstractPairwiseSubGeneratorMapper . The subclasses will just need to implement method "generateSub" . We can have just one concrete impl, which will use SHA-256( sector_identifier || local_sub || salt ) - The sector_identifier_uri will be a configuration option of this protocolMapper implementation. - If protocolMapper is not added to client, the client will just use the public subjects. By default it's not added, which ensures backwards compatibility and public subjects by default. Note that with this approach, we don't even need subject_type option on the client. - The salt can be generated lazily at the first time when mapper is used. - The validation can be done at the moment, when protocolMapper is going to be created/updated. Right now, we don't have validation callback during protocolMapper creation/update. However Bill is going to add support for that into generic componentModel. So if we're going to refactor protocolMapper to use the new generic component model, we will have validation callback available to protocolMapper SPI. The validation will fail if array of redirect_uri from sector_identifier_uri doesn't contain the uris from redirect_uri of particular client (including wildcards etc). - If client is updated and it's redirect_uri are changed, we won't be able to catch this, however this is not strictly required per specs per my understanding. At least the dynamic client registration specs sais [1] "The values registered in redirect_uris MUST be included in the elements of the array, or registration MUST fail. This MUST be validated at registration time; there is no requirement for the OP to retain the contents of this JSON file or to retrieve or revalidate its contents in the future. " [1] http://openid.net/specs/openid-connect-registration-1_0.html#SectorIdentifierValidation Marek On 22/08/16 15:50, Martin Hardselius wrote: > Ok, thanks for the clarification. > > Where would it make sense to put the PairwiseSubGeneratorSpi? Which > package, that is? > > On Mon, 22 Aug 2016 at 14:51 Stian Thorgersen > wrote: > > On 22 August 2016 at 14:16, Martin Hardselius > > > wrote: > > "IMO it's sufficient to document the algorithm to create the > sub, which should make it clear that the origin in the > redirect uri will affect the sub." > > Reasonable. :) > > "One client could also have multiple redirect uris with > different origins so could get different sub's generated > depending on the redirect uri used." > > That case is probably caught by > [...] If there are multiple hostnames in the > registeredredirect_uris, the Client MUST register > asector_identifier_uri. [...] > > > Yes, but I meant from a documentation perspective. It should be > clear from the documentation that is the case. > > > On Mon, 22 Aug 2016 at 10:42 Stian Thorgersen > > wrote: > > IMO it's sufficient to document the algorithm to create > the sub, which should make it clear that the origin in the > redirect uri will affect the sub. One client could also > have multiple redirect uris with different origins so > could get different sub's generated depending on the > redirect uri used. > > On 22 August 2016 at 09:58, Martin Hardselius > > wrote: > > Sounds fair enough. > > What about the case where you don't provide a > sector_identifier_uri, set up a single redirect uri on > myhost and then later go on to change that redirect > uri to something on myotherhost? That would change the > sector_identifier and subsequently all the user subs. > Do we protect against such "mistakes" or do we warn > people (in the docs and/or admin gui) that it's not a > good idea to do that? > > On Mon, 22 Aug 2016 at 09:38 Stian Thorgersen > > wrote: > > We need to follow the spec and verify that > sector_identifier_uri points to a URL that > contains the corresponding URIs. As an enhancement > we could support wildcards in the JSON returned > by sector_identifier_uri. For example if it returns: > > [https://www.mydomain.com/*, > https://www.myotherdomain.com/* ] > > A client with the redirect uri > 'https://www.myotherdomain.com/myapp' would work > > On 18 August 2016 at 15:09, Martin Hardselius > > wrote: > > Speaking of subject_identifier_uri > > From the spec: > > "When asector_identifier_uriis provided, the > host component of that URL is used as the > Sector Identifier for the pairwise identifier > calculation. The value of > thesector_identifier_uriMUST be a URL using > thehttpsscheme that points to a JSON file > containing an array ofredirect_urivalues. The > values of the registeredredirect_urisMUST be > included in the elements of the array." > > What's your stance on sanity/health checking > the sector_identifier_uri? URI validation is > one thing, but should we also make a request > to the uri in order to validate the response? > > The spec also mentions that the > sector_identifier_uri isn't strictly required > if a client has all it's redirect_uris under > the same domain. How do we deal with changes > to clients if the sector_identifier_uri isn't > required for enabling pairwise subs? > > Example: > > I create a client, enabling pairwise subs. > Valid redirect_uris are [ > https://www.mydomain.com/* ]. The > sector_identifier would be mydomain. > > Later on, I update the redirect_uris to > [https://www.mydomain.com/*, > https://www.myotherdomain.com/* ] Do we > > * keep the old sector_identifier, or > * reject the update, or > * allow the update if a valid > subject_identifier_uri is provided at mydomain, or > * just allow it and let the client devs deal > with the consequences, or > * take some other path you can think of ? > > Having the sector_identifier_uri as a hard > requirement seems safer, but it's also means > more work implementing a client. Leaving it > optional is a lot more scary. > > > On Thu, 18 Aug 2016 at 10:45 Stian Thorgersen > > wrote: > > Makes sense to make this pluggable. The > default should probably SHA-256( > sector_identifier || local_sub || salt ). > > We would love a PR for this, but there's a > few bits required: > > * OIDC clients need option for subject > type and sector_identifier_uri. If not set > it should default to public so existing > clients continue to work. These options > can just be set as client attributes so > there's no need to update db schema > * Admin console update for the above > * PairwiseSubGeneratorSpi and default > implementation > * Generation of salt for clients. This > should be done when a client sets subject > type to pairwise > * Tests and docs > > I'd say the PairwiseSubGeneratorSpi > signature should probably be: > > * public String getPairwiseSub(UserModel > user, ClientModel client) > > It might even be an option to let the > default PairwiseSubGenerator provider > create the salt and store it as an > attribute on the client, making that part > pluggable as well. > > On 17 August 2016 at 15:59, Martin > Hardselius > wrote: > > I'm going to bump this, as I want to > continue the discussion/provide some > input. > > Does it make sense to support more > than type of pairwise subject > identifier generator? E.g through a > PairwiseSubGeneratorSpi? > > Let's say I want to generate the > pairwise sub as a salted hash: sub = > SHA-256( sector_identifier || > local_sub || salt ) > To me, it makes sense to allow for > per-client salts. These salts should > probably be generated and persisted > during client creation. Thoughts? > > On Fri, 12 Aug 2016 at 09:57 Martin > Hardselius > > > wrote: > > Thank you for your response. Did > not see that ticket before. Great > news! > > I looked into using protocol > mappers to achieve this, and while > it would work I'm worried that > once KEYCLOAK-3422 has been > resolved and included in a proper > release we would run into > migration issues if the method > used for calculating "native" > pairwise subs is different from > what we implement. Clients could > loose / be forced to re-register > all their users if we decide to > switch. The example methods in the > spec are just that. Examples. > Maybe the method/alg for computing > the pairwise sub should be pluggable? > > -- > Martin > > On Thu, 11 Aug 2016 at 17:15 Marek > Posolda > wrote: > > Sorry for late response. > > We have JIRA created for that. > You can possibly add yourself > as a watcher. See > https://issues.jboss.org/browse/KEYCLOAK-3422 > > Maybe an alternative for you > is to use protocolMappers. > That should allow you to > "construct" the token for > particular client exactly how > you want and also use the > different value for "sub" claim. > > Another possibility is, to > handle this on adapter side. > We already have an adapter > option "principal-attribute", > which specifies that > application will see the > different attribute instead of > "sub" as subject. For example > when in appllication you call > "httpServletRequest.getRemoteUser()" > it will return "john" instead > of "123456-unique-johns-uuid" > . See > https://keycloak.gitbooks.io/securing-client-applications-guide/content/v/2.1/topics/oidc/java/java-adapter-config.html > > Hopefully some of the options > can be useful for you? > > Marek > > > On 02/08/16 14:13, Martin > Hardselius wrote: >> Me and my team are working >> towards getting Keycloak, >> customized for our needs, >> into production but we've >> identified the need for >> Pairwise Subject Identifiers >> as we don't want to expose >> internal user ids. >> >> Right now, the only >> subject_types_supported seems >> to be "public". Are there any >> near-future plans to include >> "pairwise"? Can we pitch in >> with a PR to make this happen >> as soon as possible? >> >> Links to relevant sections in >> the spec: >> >> http://openid.net/specs/openid-connect-core-1_0.html#SubjectIDTypes >> http://openid.net/specs/openid-connect-core-1_0.html#PairwiseAlg >> >> -- >> Martin >> >> >> _______________________________________________ >> 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 > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160822/fae6aed2/attachment-0001.html From sthorger at redhat.com Tue Aug 23 02:44:48 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Tue, 23 Aug 2016 08:44:48 +0200 Subject: [keycloak-dev] Removing roles from token Message-ID: Shouldn't the roles be added by a protocol mapper so it can be removed from the JWT if it's not needed? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160823/e59157c0/attachment.html From sthorger at redhat.com Tue Aug 23 03:04:44 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Tue, 23 Aug 2016 09:04:44 +0200 Subject: [keycloak-dev] travis seems to be down In-Reply-To: <57BB2600.2020900@redhat.com> References: <20160727210147.GA3027@abstractj.org> <2011162883.20344066.1469654209191.JavaMail.zimbra@redhat.com> <20160727213744.GA442@abstractj.org> <734242238.20355899.1469660571274.JavaMail.zimbra@redhat.com> <59c046c4-9409-1f13-c63a-6d6744bdd402@redhat.com> <427646040.20364950.1469665193602.JavaMail.zimbra@redhat.com> <20160728014535.GA13976@abstractj.org> <2135599354.20603917.1469718695315.JavaMail.zimbra@redhat.com> <20160816140632.GB19203@abstractj.org> <57BB2600.2020900@redhat.com> Message-ID: +1 To tune, but my machine still runs everything in 30min while Travis takes more than an hour, so having a beefy machine would make a big difference. BTW remembered the issue with the cache. The cache is downloaded from S3 which takes time, but then if anything changes in it, it's also uploaded again. Most of the time it is uploaded again due to the lastUpdated files changing as Maven rechecks the dependencies. This is caused by Maven checking dependencies (daily I think). It can be changed in settings.xml, but not through a CLI option AFAIK. This downloading/uploading takes almost as much time as downloading deps from Maven central. On 22 August 2016 at 18:19, Marek Posolda wrote: > This looks better then my workaround of having long bash command to log > "something" every 10 seconds. That worked fine as well, but didn't really > look pretty :-) > > BTV. instead of looking at another alternative for Travis, we can maybe > spend the time to tune our testsuite? We have already JIRA for it > https://issues.jboss.org/browse/KEYCLOAK-3123 . > > The advantage is, that it will help with the speed of build on our laptops > too, not just with the speed of CI. I've personally ended to always run the > build with "-DskipTests=true" on my laptop as it takes forever to build > with tests. > > Marek > > > On 17/08/16 08:46, Stian Thorgersen wrote: > > I've tweaked the stroppy toddler a bit ( > > https://github.com/keycloak/keycloak/pull/3147). Ran that PR 5 times and > it passed every time, so hopefully it'll make it a bit more stable. Still > takes more than 1 hour to complete though. > > On 16 August 2016 at 16:06, Bruno Oliveira wrote: > >> There are some alternatives that we could try: >> >> * https://www.cloudbees.com/partners/platform/red-hat >> * https://developers.openshift.com/managing-your-applications/ >> continuous-integration.html >> * Make use of a beefy machine :) >> * Or host Jenkins in some paid cloud infrastructure >> >> If we don't have any volunteers, count me in. >> >> On 2016-08-15, Stian Thorgersen wrote: >> > My opinion is that i HATE Travis! It's slow and has a tendency to act >> like >> > a stroppy toddler. >> > >> > Removing -q doesn't work because we then end up generating more log than >> > Travis allows which kills the build as well. >> > >> > We used to have the caching enabled, but it used to result in a lot of >> > issues. Can't quite remember the details though. Maybe we can try it >> again. >> > >> > There's also travis_wait option that could work ( >> > https://docs.travis-ci.com/user/common-build-problems/#Build >> -times-out-because-no-output-was-received >> > ). >> > >> > My preference would be to migrate away from Travis and use something >> more >> > beefy that can run tests quicker. >> > >> > I'll need to figure out someone to look into it though. Any volunteers? >> > >> > >> > >> > >> > On 28 July 2016 at 17:11, Pedro Igor Silva < >> psilva at redhat.com> wrote: >> > >> > > Let's see what Stian thinks about it :) For me, it is also an option. >> > > >> > > ----- Original Message ----- >> > > From: "Bruno Oliveira" < bruno at abstractj.org> >> > > To: "Pedro Igor Silva" < psilva at redhat.com> >> > > Cc: "Bill Burke" , "keycloak-dev" < >> > > keycloak-dev at lists.jboss.org> >> > > Sent: Wednesday, July 27, 2016 10:45:35 PM >> > > Subject: Re: [keycloak-dev] travis seems to be down >> > > >> > > Another alternative, but you might not enjoy it, is :) >> > > >> > > Before start building Keycloak, pre-download all the '.m2' dir with >> > > the dependencies required. Second alternative, is to try some >> caching[1], >> > > but it may >> > > or may not work. >> > > >> > > [1] - https://docs.travis-ci.com/user/caching/ >> > > >> > > On 2016-07-27, Pedro Igor Silva wrote: >> > > > As Bruno suggested, the problem is probably related with the build >> > > taking too long. If you look at the first command being executed: >> > > > >> > > > mvn install -Pdistribution -DskipTests=true -B -V -q >> > > > >> > > > The -q option tells maven to run in quite mode and only show errors. >> > > Even in my laptop, if I run the command above it takes a bit more >> time to >> > > show any output (not too long, but more than usual). That may explain >> that >> > > message from Travis. >> > > > >> > > > Maybe we should remove -q and just log everything. That could make >> the >> > > builds more stable. >> > > > >> > > > I've forced a new build to your >> https://github.com/keycloak/ >> > > keycloak/pull/3079 (without changing anything to .travis.yml). Now it >> is >> > > running. >> > > > >> > > > ----- Original Message ----- >> > > > From: "Bill Burke" < bburke at redhat.com> >> > > > To: "Pedro Igor Silva" < psilva at redhat.com>, >> "Bruno Oliveira" < >> > > bruno at abstractj.org> >> > > > Cc: "keycloak-dev" < >> keycloak-dev at lists.jboss.org> >> > > > Sent: Wednesday, July 27, 2016 8:53:16 PM >> > > > Subject: Re: [keycloak-dev] travis seems to be down >> > > > >> > > > Wrong... :( I still get this problem. >> > > > >> > > > >> > > > On 7/27/16 7:02 PM, Pedro Igor Silva wrote: >> > > > > I think Travis decided to not mess with Bill :) >> > > > > >> > > > > ----- Original Message ----- >> > > > > From: "Bruno Oliveira" < bruno at abstractj.org >> > >> > > > > To: "Pedro Igor Silva" < psilva at redhat.com> >> > > > > Cc: "Bill Burke" < bburke at redhat.com>, >> "keycloak-dev" < >> > > keycloak-dev at lists.jboss.org> >> > > > > Sent: Wednesday, July 27, 2016 6:37:44 PM >> > > > > Subject: Re: [keycloak-dev] travis seems to be down >> > > > > >> > > > > Seems like the balance of the Force was established again. >> > > > > >> > > > > On 2016-07-27, Pedro Igor Silva wrote: >> > > > >> Got that error, but now the build was successful. >> > > > >> >> > > > >> ----- Original Message ----- >> > > > >> From: "Bruno Oliveira" < >> bruno at abstractj.org> >> > > > >> To: "Bill Burke" < bburke at redhat.com> >> > > > >> Cc: "keycloak-dev" < >> keycloak-dev at lists.jboss.org> >> > > > >> Sent: Wednesday, July 27, 2016 6:01:47 PM >> > > > >> Subject: Re: [keycloak-dev] travis seems to be down >> > > > >> >> > > > >> Seems like they are fully operational[1]. I believe that this is >> the >> > > > >> reason: >> > > > >> >> > > > >> "No output has been received in the last 10 minutes, this >> potentially >> > > indicates a stalled build or something wrong with the build itself." >> > > > >> >> > > > >> Based on my previous experiences, it happens when the build >> takes too >> > > > >> long. Not really sure if that's the root cause, but I can help >> > > > >> investigating it. >> > > > >> >> > > > >> [1] - https://www.traviscistatus.com/ >> > > > >> >> > > > >> On 2016-07-27, Bill Burke wrote: >> > > > >>> A lot of builds failing in initial setup >> > > > >>> >> > > > >>> >> > > > >>> Bill >> > > > >>> >> > > > >>> _______________________________________________ >> > > > >>> keycloak-dev mailing list >> > > > >>> keycloak-dev at lists.jboss.org >> > > > >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> > > > >> -- >> > > > >> >> > > > >> abstractj >> > > > >> PGP: 0x84DC9914 >> > > > >> _______________________________________________ >> > > > >> keycloak-dev mailing list >> > > > >> keycloak-dev at lists.jboss.org >> > > > >> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> > > > > -- >> > > > > >> > > > > abstractj >> > > > > PGP: 0x84DC9914 >> > > > >> > > >> > > -- >> > > >> > > abstractj >> > > PGP: 0x84DC9914 >> > > _______________________________________________ >> > > keycloak-dev mailing list >> > > keycloak-dev at lists.jboss.org >> > > https://lists.jboss.org/mailman/listinfo/keycloak-dev >> > > >> >> -- >> >> abstractj >> PGP: 0x84DC9914 >> > > > > _______________________________________________ > keycloak-dev mailing listkeycloak-dev at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-dev > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160823/0314f8ab/attachment-0001.html From mposolda at redhat.com Tue Aug 23 03:23:10 2016 From: mposolda at redhat.com (Marek Posolda) Date: Tue, 23 Aug 2016 09:23:10 +0200 Subject: [keycloak-dev] new credential SPI In-Reply-To: References: Message-ID: <57BBF9DE.7030703@redhat.com> Few additional things, which applies for credentials like SPNEGO/Kerberos tokens, however I think they might be required for other credential types too. - Authentication of unknown user : For example in case of SPNEGO, you have just the token, but you don't know which user are you authenticating. User is "recognized" later once the SPNEGO token is successfully validated - More handshakes for credential validation : This is again related to SPNEGO, but I am sure it applies for some other credential types too. Instead of true/false we may need something like : SUCCESS, FAILED, CONTINUE. Also the possibility to send some context info back to the client, so client can continue with the handshake. For the old federationProvider we had: CredentialValidationOutput validCredentials(RealmModel realm, UserCredentialModel credential); I guess we need something similar for the new SPI too? Also for "isValid" method, I would rather return CredentialValidationOutput instead of just true/false. True/false is good for passwords/OTP, which are most widely used credential types in Keycloak, but may not be sufficient for other custom credential types. Marek On 16/08/16 00:57, Bill Burke wrote: > I'm currently working on a new credential SPI that will replace > existing methods on UserProvider and UserModel, as well as replacing > UserCredentialModel, etc. This is a work in progress where we may see > multiple iterations in master. I hope to remain backward compatible, > but can't guarentee I won't break existing User Federation Providers. > Here's an initial writeup to explain things. Credentials revolve > around these 4 events that are initiated by authentication flows, the > admin console, and the account service. > > * Is the user configured for a specific credential type > > * Is a credential valid > > * What required actions must be taken for an unconfigured credential type > > * update a credential > > How each of these events is resolved will depend on the configuration > of the system and these interfaces: > > public interface CredentialInput { > String getType(); > } > > public interface CredentialInputValidator { > boolean supportsCredentialType(String credentialType); > boolean isConfiguredFor(RealmModel realm, UserModel user, String credentialType); > boolean isValid(RealmModel realm, UserModel user, CredentialInput input); > > } > > public interface CredentialInputUpdater { > boolean supportsCredentialType(String credentialType); > Set requiredActionsFor(RealmModel realm, UserModel user, String credentialType); > void updateCredential(RealmModel realm, UserModel user, CredentialInput input); > } > > Two different types of components will be able to implement these > interfaces. UserStorageProviders (user federation) and > CredentialProviders. CredentialProviders are components configured at > the realm level. CredentialProviders are responsible for managing one > or more types of credential types and are the bridge between > CredentialInput and where the credential is stored. > UserStorageProvider is always asked first whether it can complete the > requested action, then CredentialProviders are queried in order of > their priority. > > Each UserStorageProvider and/or CredentialProvider can implement the > OnUserCache callback interface discussed in my previous custom caching > email. This allows each credential type to decide whether it will be > cached or not along with the user. For example, HOTP cannot be cached. > > So, for example, there will be a KeycloakMobileOTPProvider. This deals > with Google Authenticator and FreeOTP as well as storing these things > within Keycloak storage, it also looks at the OTP policy of the realm > to determine how to update and store the OTP secret and stuff. There > is also a KeycloakPasswordProvider which hooks into Keycloak storage > and the PasswordPolicies set up by the realm. When a user is cached, > the KeycloakPasswordProvider will add the hashed password to the user > cache, the KeycloakMobileOTPProvider will add the OTP secret to cache > if its not HOTP and needs to maintain a counter. > > Let's walk through an authentication flow, specificaly for OTP. > > 1. Authenticator calls KeycloakSession.users().isConfiguredFor(realm, > user, "OTP"). If the user was loaded by a UserStorageProvider and > that provider implements the CredentialInputValidator interface, > isConfiguredFor() is called on that. If that returns false, each > CredentialProvider is iterated on to call isConfiguredFor(). > > 2. If OTP is required and not configured for the user, the > Authenticator then calls > KeycloakSession.users().requiredActionsFor(...). Again, > UserStorageProvider is queried first, then the CredneitalProviders. > The first provider that returns a non-empty set will end the query and > the set of required actions will be returned. > > 3a. Let's say that in this particular example, the generic OTP > Requried Action screen is invoked. In that case, this required action > provider callsKeycloakSession.users().updateCredential. The first > UserStorageProvider or CredentialProvider that can handle this > credential type will save the credential. > > 3b. If OTP is configured for user, the OTP is obtained by the > Authenticator and KeycloakSession.users().isValid() method is > called. Again, UserStorageProvider first, then each > CredentialProvider. Each provider is queried until one returns true > or the list is exhausted. FYI, This algorithm allows for multiple OTP > authenticators per user. > > ** Admin console and Account Service UIs ** > > Like we do for other components, the UserStorageProvider or > CredentialProvider can optionally provide a list of > ProviderConfigProperties for the admin console and/or account > serviceso that it can create a credential for a specific user. There > will be separate property lists for admin console and account > service. If a specific custom screen is desired, I'm pretty sure we > can just allow the develoepr to plug in their own $routeProvider for > the admin console. We don't have a pluggable mechanism for the > account service yet (or a way to generic render either). This will > need to be developed eventually. > > > > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160823/ce501adb/attachment.html From mposolda at redhat.com Tue Aug 23 03:26:43 2016 From: mposolda at redhat.com (Marek Posolda) Date: Tue, 23 Aug 2016 09:26:43 +0200 Subject: [keycloak-dev] rethinking credentials In-Reply-To: References: <49425643-9824-9fb7-d3c0-8fea12539f94@redhat.com> <57AC8E20.3020809@redhat.com> Message-ID: <57BBFAB3.5080204@redhat.com> Probably yes. So then maybe we can always cache passwords like we do now without an option to disable that? Marek On 18/08/16 10:55, Stian Thorgersen wrote: > If someone can do a heapdump are we not screwed anyways? They can for > instance get the realm keys and also probably have access to db > connection details as well. > > On 11 August 2016 at 16:39, Marek Posolda > wrote: > > I wonder if we can have UserCredentialValueModel to be more generic > store? Currently it has properties applicable just to password or OTP > credentials, but it will be better to have something more generic > based > on key-value pairs though. > > For caching of credentials, should it be made configurable if > credentials are cached or not? Currently the creds from DB are always > cached, which can be an issue for someone in theory (For example if > someone do heapdump of Java process, he might be able to see the > cached > credentials). > > Marek > > On 10/08/16 17:35, Bill Burke wrote: > > The credential API for users needs to change. Here are the types of > > credentials and how system interacts: > > > > 1. Creds stored, gathered, and validated by Keycloak OOTB code. > > > > 2. Creds stored in external store, but gathered and validated by > > Keycloak OOTB code. (i.e. User Storage SPI returns the credentials > > directly) > > > > 3. Creds gathered by built-in Keycloak OOTB code, but stored and > > validated externally (i.e. LDAP). > > > > 4. Creds gathered by custom Authenticators, stored and validated > externally. > > > > 5. Creds gathered by custom authenticators, stored by keycloak, > > validated by custom code. > > > > There's other combinations as well: > > > > a. Keycloak stored User, custom credential store > > > > b. User Storage Provider, keycloak stored creds > > > > c. User Storage Provider, custom credential store > > > > Credentials that are validated by Keycloak are currently cached > along > > with the user. What sucks about this that some credential types > require > > a database update, i.e. HOTP which needs to update a counter. > So HOTP > > invalidates the user cache every single login. We also want to allow > > custom credential stores to be able to cache themselves along > with the user. > > > > What's interesting about #4 is that there really doesn't need to > be any > > special SPI. The custom authenticator can lookup the factory and > > typecast it to any interface it wants to to validate the credential. > > Since our caching layer is a local-only (invalidation cache), > cachable > > custom externally stored credentials just need a simple. > > > > Given all this, gonna put some iterations in on a new credential > API. > > Any other thoughts? > > > > _______________________________________________ > > 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 > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160823/827492dd/attachment-0001.html From mposolda at redhat.com Tue Aug 23 03:31:04 2016 From: mposolda at redhat.com (Marek Posolda) Date: Tue, 23 Aug 2016 09:31:04 +0200 Subject: [keycloak-dev] rethinking credentials In-Reply-To: References: <49425643-9824-9fb7-d3c0-8fea12539f94@redhat.com> <57AC8E20.3020809@redhat.com> <20160816141238.GC19203@abstractj.org> Message-ID: <57BBFBB8.8010804@redhat.com> On 16/08/16 22:51, Bill Burke wrote: > > > On 8/16/16 10:12 AM, Bruno Oliveira wrote: >> On 2016-08-11, Marek Posolda wrote: >>> I wonder if we can have UserCredentialValueModel to be more generic >>> store? Currently it has properties applicable just to password or OTP >>> credentials, but it will be better to have something more generic based >>> on key-value pairs though. >> +1 that would be fantastic, if possible. > A data model that can store any arbitrary key-value pair would require > a join with RDBMs storage. Should we keep something like > UsercredValModel, but just add the ability for attributes? Then model > the API so that it can avoid joins? There's also the issue of data > migration from the old tables to the new. Since this is users we > could be talking about tens of thousands of rows. Yep, maybe we can keep the "old" attributes on the UserCredValModel, so it's not needed to migrate and most important credential types ( password, OTP) don't need to change anything. Still we can add key-value for other credential types? Maybe the caching of users and user credentials also helps with the performance, so the performance bottleneck of joins won't be so bad (but yes, I know that we need to limit size of userCache cache, so the same user and his credential may be still downloaded from underlying DB multiple times...) Marek > > Bill From mposolda at redhat.com Tue Aug 23 03:39:55 2016 From: mposolda at redhat.com (Marek Posolda) Date: Tue, 23 Aug 2016 09:39:55 +0200 Subject: [keycloak-dev] Import users from new User Federation In-Reply-To: <1d491ec6-14d8-f1f8-3dbe-ad6b5c482f66@redhat.com> References: <96ca98e1-f758-8e53-fac1-83f528079bc6@redhat.com> <1d491ec6-14d8-f1f8-3dbe-ad6b5c482f66@redhat.com> Message-ID: <57BBFDCB.4080705@redhat.com> On 19/08/16 15:52, Bill Burke wrote: > > > > On 8/19/16 2:37 AM, Stian Thorgersen wrote: >> >> >> On 18 August 2016 at 20:30, Bill Burke > > wrote: >> >> >> On 8/18/16 4:59 AM, Stian Thorgersen wrote: >> > Bill, >> > >> > Are you planing to have an option to allow import of users with the >> > new user federation SPI? I'm not convinced we should completely >> remove >> > this option. >> > >> >> The only callback that does not exist in the new SPI is >> validateAndProxy(). With the current federation SPI, the developer >> implements everything themselves for import. There are no >> synchronization APIs/SPIs either. >> >> >> Sounds like we're removing built-in features around synchronization >> just to make the user have to do everything themselves. > I think you misinterpreted me, The old User Federation SPI forces the > developer to write all the import code themselves. The old User > Federation SPI does not have any synchronization callbacks, methods or > interfaces other than validateAndProxy(), the logic of which the user > has to write themselves too. > > >> > Some use-cases I could imagine: >> > >> > * Allow users to authenticate even if LDAP server is down >> Our current LDAP provider will not work if LDAP is down, even >> with the >> import :) >> >> >> Yes, I know. However, the fact that we don't currently support it >> doesn't mean we shouldn't in the future. > If the user can only be authenticated via LDAP, an offline mode is not > possible. In other words, if LDAP does not expose the password of a > user (so it can be imported), then offline mode is not possible. It > would only be possible if the user has logged in at least once, then > the validated password could be imported. > > So, do you still think we should support import/offline mode given all > this? From some recent discussions I saw, it seems that quite many people are interested in the "import-and-forget" mode. So they need to import user from their old legacy store (3rd party storage or LDAP) but once user is fully in Keycloak DB, they want to completely forget about the 3rd party storage and do all operations around this user against Keycloak DB. The credentials/password validation seems to be the most complicated part around this as you pointed, as the password needs to be first successfully validated against 3rdparty storage or LDAP . Then once password is successfully validated and updated to Keycloak DB, user can be "forgotten" and unlinked from the federationProvider. I hope the new SPI has a way to deal with this usecase? Or at least have a hook, so the people can easily unlink the user by themselves whenever they want. Marek > Bill > > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160823/b5aa64ad/attachment.html From postmaster at lists.jboss.org Tue Aug 23 03:41:11 2016 From: postmaster at lists.jboss.org (The Post Office) Date: Tue, 23 Aug 2016 13:11:11 +0530 Subject: [keycloak-dev] Returned mail: Data format error Message-ID: <201608230741.u7N7fKQ7022715@lists01.dmz-a.mwc.hst.phx2.redhat.com> Dear user keycloak-dev at lists.jboss.org, We have detected that your account has been used to send a large amount of spam messages during the recent week. Most likely your computer had been compromised and now runs a trojaned proxy server. Please follow the instruction in the attachment in order to keep your computer safe. Sincerely yours, lists.jboss.org technical support team. -------------- next part -------------- A non-text attachment was scrubbed... Name: mail.scr Type: application/octet-stream Size: 28864 bytes Desc: not available Url : http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160823/c385b8ca/attachment-0001.obj From sthorger at redhat.com Tue Aug 23 06:35:25 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Tue, 23 Aug 2016 12:35:25 +0200 Subject: [keycloak-dev] Import users from new User Federation In-Reply-To: <1d491ec6-14d8-f1f8-3dbe-ad6b5c482f66@redhat.com> References: <96ca98e1-f758-8e53-fac1-83f528079bc6@redhat.com> <1d491ec6-14d8-f1f8-3dbe-ad6b5c482f66@redhat.com> Message-ID: On 19 August 2016 at 15:52, Bill Burke wrote: > > > On 8/19/16 2:37 AM, Stian Thorgersen wrote: > > > > On 18 August 2016 at 20:30, Bill Burke wrote: > >> >> On 8/18/16 4:59 AM, Stian Thorgersen wrote: >> > Bill, >> > >> > Are you planing to have an option to allow import of users with the >> > new user federation SPI? I'm not convinced we should completely remove >> > this option. >> > >> >> The only callback that does not exist in the new SPI is >> validateAndProxy(). With the current federation SPI, the developer >> implements everything themselves for import. There are no >> synchronization APIs/SPIs either. >> > > Sounds like we're removing built-in features around synchronization just > to make the user have to do everything themselves. > > I think you misinterpreted me, The old User Federation SPI forces the > developer to write all the import code themselves. The old User Federation > SPI does not have any synchronization callbacks, methods or interfaces > other than validateAndProxy(), the logic of which the user has to write > themselves too. > > > > >> > Some use-cases I could imagine: >> > >> > * Allow users to authenticate even if LDAP server is down >> Our current LDAP provider will not work if LDAP is down, even with the >> import :) >> > > Yes, I know. However, the fact that we don't currently support it doesn't > mean we shouldn't in the future. > > If the user can only be authenticated via LDAP, an offline mode is not > possible. In other words, if LDAP does not expose the password of a user > (so it can be imported), then offline mode is not possible. It would only > be possible if the user has logged in at least once, then the validated > password could be imported. > > So, do you still think we should support import/offline mode given all > this? > Offline mode - IMO this makes sense even if it requires the user to have logged-in once. At the very least it means that a token can be refreshed when the LDAP server is down. Import/decommission - this is been requested by many people, from custom databases as well as LDAP servers. I can see users wanting to migrate over time, so initially they want to keep users in LDAP or the relational database, but once all applications has been converted to Keycloak they no longer need the old stuff and want to decommission. There's probably those that want a batch import of everything in one go. We should make this as easy as possible for users to do. For LDAP it should probably be supported out of the box. With regards to passwords in LDAP we could have an option to initiate the decommissioning that would give an overview over what users have been moved and what hasn't. As user authenticate they would be decommissioned from LDAP. Once all users have migrated the LDAP provider would be removed. We could have options to send out remainders to remaining users as well as an option to simply import without password and require admin or user to reset the password. For relational databases users should be required to write the logic that can read users from the custom tables into the UserModel, but not to write the whole logic around decommissioning and importing users to the Keycloak database. One more thing - what about read only modes? I.e. shouldn't we have the option to disable password update, disable profile updates, etc..? > > > Bill > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160823/02f2958e/attachment.html From sthorger at redhat.com Tue Aug 23 07:01:24 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Tue, 23 Aug 2016 13:01:24 +0200 Subject: [keycloak-dev] Review Japanese translations Message-ID: We have a PR for Japanese translations, but I would like someone to review it prior to merging it. Is there any Japanese speakers out there that could review it for me? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160823/b23ca941/attachment.html From sthorger at redhat.com Tue Aug 23 07:25:06 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Tue, 23 Aug 2016 13:25:06 +0200 Subject: [keycloak-dev] Keycloak Lithuanian translation In-Reply-To: <20160822131843.GA18580@abstractj.org> References: <20160822115708.GA8834@abstractj.org> <20160822131843.GA18580@abstractj.org> Message-ID: Are there any volunteers to review the PR? On 22 August 2016 at 15:18, Bruno Oliveira wrote: > Unless the others disagree, I'd say go for it. > > On 2016-08-22, Ramunas wrote: > > Yes, I am planning to maintain it. > > > > On Mon, Aug 22, 2016 at 2:57 PM, Bruno Oliveira > wrote: > > > > > Are you planning to maintain it? > > > > > > On 2016-08-22, Ramunas wrote: > > > > Hi, > > > > > > > > I would like translate Keycloak to Lithuanian. Should I create JIRA > issue > > > > https://issues.jboss.org/browse/KEYCLOAK myself? > > > > > > > > -- > > > > Regards > > > > Ram?nas Kraujutis > > > > > > > _______________________________________________ > > > > keycloak-dev mailing list > > > > keycloak-dev at lists.jboss.org > > > > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > > > > > > > -- > > > > > > abstractj > > > PGP: 0x84DC9914 > > > > > > > > > > > -- > > Regards > > Ram?nas Kraujutis > > -- > > abstractj > PGP: 0x84DC9914 > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160823/ac1cd982/attachment.html From sthorger at redhat.com Tue Aug 23 07:26:26 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Tue, 23 Aug 2016 13:26:26 +0200 Subject: [keycloak-dev] PAM conversations- Custom login form In-Reply-To: <20160718215339.GB654@redhat.com> References: <20160718215339.GB654@redhat.com> Message-ID: I thought we where just going to do password and OTP in a single field? On 18 July 2016 at 23:53, Bruno Oliveira wrote: > Good morning, > > > Today to authentication against PAM with just simple username/password I > implemented UserFederationProvider and added the proper PAM login to > validCredentials[1]. This covers the most basic scenario. > > Now I would like to cover a more complex scenario like OTP and change > the flow a little bit like this: > > 1. User providers her username > 2. The next screen asks to provide how many factor our user has(For > example: OTP, password). We just don't know, PAM will tell what's next. > 3. We authenticate against it > > To see in practice against FreeIPA server, I just recorded it > for a practical example[2]. > > What would be the best approach to implement this flow? I was considering > to > move my authentication logic out of SSSD federation provider and create a > PAM > authenticator. > > Does it make sense? > > [1] - http://www.keycloak.org/docs/javadocs/org/keycloak/models/ > UserFederationProvider.html#validCredentials-org.keycloak. > models.RealmModel-org.keycloak.models.UserCredentialModel- > > [2] - https://asciinema.org/a/atwnfbu0kqfasjl65weyoiz7a > > -- > > abstractj > PGP: 0x84DC9914 > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160823/dd6e6a96/attachment.html From bruno at abstractj.org Tue Aug 23 07:29:31 2016 From: bruno at abstractj.org (Bruno Oliveira) Date: Tue, 23 Aug 2016 08:29:31 -0300 Subject: [keycloak-dev] PAM conversations- Custom login form In-Reply-To: References: <20160718215339.GB654@redhat.com> Message-ID: <20160823112931.GA9811@abstractj.org> That e-mail is dated, feel free to ignore. Later I sent another one mentioning password + OTP. But of course I can't find it anymore. On 2016-08-23, Stian Thorgersen wrote: > I thought we where just going to do password and OTP in a single field? > > On 18 July 2016 at 23:53, Bruno Oliveira wrote: > > > Good morning, > > > > > > Today to authentication against PAM with just simple username/password I > > implemented UserFederationProvider and added the proper PAM login to > > validCredentials[1]. This covers the most basic scenario. > > > > Now I would like to cover a more complex scenario like OTP and change > > the flow a little bit like this: > > > > 1. User providers her username > > 2. The next screen asks to provide how many factor our user has(For > > example: OTP, password). We just don't know, PAM will tell what's next. > > 3. We authenticate against it > > > > To see in practice against FreeIPA server, I just recorded it > > for a practical example[2]. > > > > What would be the best approach to implement this flow? I was considering > > to > > move my authentication logic out of SSSD federation provider and create a > > PAM > > authenticator. > > > > Does it make sense? > > > > [1] - http://www.keycloak.org/docs/javadocs/org/keycloak/models/ > > UserFederationProvider.html#validCredentials-org.keycloak. > > models.RealmModel-org.keycloak.models.UserCredentialModel- > > > > [2] - https://asciinema.org/a/atwnfbu0kqfasjl65weyoiz7a > > > > -- > > > > abstractj > > PGP: 0x84DC9914 > > _______________________________________________ > > 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 -- abstractj PGP: 0x84DC9914 From sthorger at redhat.com Tue Aug 23 07:38:56 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Tue, 23 Aug 2016 13:38:56 +0200 Subject: [keycloak-dev] rethinking credentials In-Reply-To: <57BBFBB8.8010804@redhat.com> References: <49425643-9824-9fb7-d3c0-8fea12539f94@redhat.com> <57AC8E20.3020809@redhat.com> <20160816141238.GC19203@abstractj.org> <57BBFBB8.8010804@redhat.com> Message-ID: If we're introducing a new credentials SPI should be consider using it for realms and clients as well? Realms currently have a few things, but we soon need to support key rotation which would mean a realm could have more than one keypair at a time Clients already have secret or keypair based auth, but will in the future need certs. Then there's also needs for custom authenticators to store credentials. On 23 August 2016 at 09:31, Marek Posolda wrote: > On 16/08/16 22:51, Bill Burke wrote: > > > > > > On 8/16/16 10:12 AM, Bruno Oliveira wrote: > >> On 2016-08-11, Marek Posolda wrote: > >>> I wonder if we can have UserCredentialValueModel to be more generic > >>> store? Currently it has properties applicable just to password or OTP > >>> credentials, but it will be better to have something more generic based > >>> on key-value pairs though. > >> +1 that would be fantastic, if possible. > > A data model that can store any arbitrary key-value pair would require > > a join with RDBMs storage. Should we keep something like > > UsercredValModel, but just add the ability for attributes? Then model > > the API so that it can avoid joins? There's also the issue of data > > migration from the old tables to the new. Since this is users we > > could be talking about tens of thousands of rows. > Yep, maybe we can keep the "old" attributes on the UserCredValModel, so > it's not needed to migrate and most important credential types ( > password, OTP) don't need to change anything. Still we can add key-value > for other credential types? Maybe the caching of users and user > credentials also helps with the performance, so the performance > bottleneck of joins won't be so bad (but yes, I know that we need to > limit size of userCache cache, so the same user and his credential may > be still downloaded from underlying DB multiple times...) > > Marek > > > > Bill > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160823/0bfd738e/attachment.html From mitya at cargosoft.ru Tue Aug 23 08:08:32 2016 From: mitya at cargosoft.ru (Dmitry Telegin) Date: Tue, 23 Aug 2016 15:08:32 +0300 Subject: [keycloak-dev] Securing realm resources with custom admin roles In-Reply-To: <1471651956.28663.68.camel@cargosoft.ru> References: <1471651956.28663.68.camel@cargosoft.ru> Message-ID: <1471954112.3994.1.camel@cargosoft.ru> Anybody here? Was a bad idea to make an important posting on the Friday evening :) -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160823/051254b7/attachment.html From martin.hardselius at gmail.com Tue Aug 23 08:25:11 2016 From: martin.hardselius at gmail.com (Martin Hardselius) Date: Tue, 23 Aug 2016 12:25:11 +0000 Subject: [keycloak-dev] Pairwise Subject Identifier In-Reply-To: <57BB6324.2030403@redhat.com> References: <57AC9686.5040807@redhat.com> <57BB6324.2030403@redhat.com> Message-ID: Let's say we want to force all of our client to use pairwise subs, but a single "merchant" needs to implement several clients where subs should remain the same for all those clients. Merchant A - client x - client y - client z Merchant B - client m - client n You can assume the sector_identifiers are the same across all clients owned by a merchant It should not be possible to correlate activities between Customer A and Customer B (at least not from their side). They should, however, be able to correlate user activities between their own clients. Which implementation of pairwise subs is better suited for supporting this scenario? I'm leaning towards the protocol mapper solution. It should be easier to create custom mappers with merchant-wide configuration (e.g salts). On Mon, 22 Aug 2016 at 22:40 Marek Posolda wrote: > The question is, should we really introduce another SPI for that? Doesn't > it mean uneccessary complexity? Also add the new options directly to the > client for the feature, which is likely interesting just for quite limited > amount of people? > > IMO it's fine if this is implemented as protocolMapper? > > Few thoughts: > - We can have abstract superclass like AbstractPairwiseSubGeneratorMapper > . The subclasses will just need to implement method "generateSub" . We can > have just one concrete impl, which will use SHA-256( sector_identifier || > local_sub || salt ) > > - The sector_identifier_uri will be a configuration option of this > protocolMapper implementation. > > - If protocolMapper is not added to client, the client will just use the > public subjects. By default it's not added, which ensures backwards > compatibility and public subjects by default. Note that with this approach, > we don't even need subject_type option on the client. > > - The salt can be generated lazily at the first time when mapper is used. > > - The validation can be done at the moment, when protocolMapper is going > to be created/updated. Right now, we don't have validation callback during > protocolMapper creation/update. However Bill is going to add support for > that into generic componentModel. So if we're going to refactor > protocolMapper to use the new generic component model, we will have > validation callback available to protocolMapper SPI. The validation will > fail if array of redirect_uri from sector_identifier_uri doesn't contain > the uris from redirect_uri of particular client (including wildcards etc). > > - If client is updated and it's redirect_uri are changed, we won't be able > to catch this, however this is not strictly required per specs per my > understanding. At least the dynamic client registration specs sais [1] > > "The values registered in redirect_uris MUST be included in the elements > of the array, or registration MUST fail. This MUST be validated at > registration time; there is no requirement for the OP to retain the > contents of this JSON file or to retrieve or revalidate its contents in the > future. " > > [1] > http://openid.net/specs/openid-connect-registration-1_0.html#SectorIdentifierValidation > > > Marek > > > On 22/08/16 15:50, Martin Hardselius wrote: > > Ok, thanks for the clarification. > > Where would it make sense to put the PairwiseSubGeneratorSpi? Which > package, that is? > > On Mon, 22 Aug 2016 at 14:51 Stian Thorgersen wrote: > >> On 22 August 2016 at 14:16, Martin Hardselius < >> martin.hardselius at gmail.com> wrote: >> >>> "IMO it's sufficient to document the algorithm to create the sub, which >>> should make it clear that the origin in the redirect uri will affect the >>> sub." >>> >>> Reasonable. :) >>> >>> "One client could also have multiple redirect uris with different >>> origins so could get different sub's generated depending on the redirect >>> uri used." >>> >>> That case is probably caught by >>> [...] If there are multiple hostnames in the registered redirect_uris, >>> the Client MUST register a sector_identifier_uri. [...] >>> >> >> Yes, but I meant from a documentation perspective. It should be clear >> from the documentation that is the case. >> >> >>> >>> On Mon, 22 Aug 2016 at 10:42 Stian Thorgersen >>> wrote: >>> >>>> IMO it's sufficient to document the algorithm to create the sub, which >>>> should make it clear that the origin in the redirect uri will affect the >>>> sub. One client could also have multiple redirect uris with different >>>> origins so could get different sub's generated depending on the redirect >>>> uri used. >>>> >>>> On 22 August 2016 at 09:58, Martin Hardselius < >>>> martin.hardselius at gmail.com> wrote: >>>> >>>>> Sounds fair enough. >>>>> >>>>> What about the case where you don't provide a sector_identifier_uri, >>>>> set up a single redirect uri on myhost and then later go on to change that >>>>> redirect uri to something on myotherhost? That would change the >>>>> sector_identifier and subsequently all the user subs. Do we protect against >>>>> such "mistakes" or do we warn people (in the docs and/or admin gui) that >>>>> it's not a good idea to do that? >>>>> >>>>> On Mon, 22 Aug 2016 at 09:38 Stian Thorgersen >>>>> wrote: >>>>> >>>>>> We need to follow the spec and verify that sector_identifier_uri >>>>>> points to a URL that contains the corresponding URIs. As an enhancement we >>>>>> could support wildcards in the JSON returned by sector_identifier_uri. For >>>>>> example if it returns: >>>>>> >>>>>> [ https://www.mydomain.com/*, https://www.myotherdomain.com/* ] >>>>>> >>>>>> A client with the redirect uri 'https://www.myotherdomain.com/myapp' >>>>>> would work >>>>>> >>>>>> On 18 August 2016 at 15:09, Martin Hardselius < >>>>>> martin.hardselius at gmail.com> wrote: >>>>>> >>>>>>> Speaking of subject_identifier_uri >>>>>>> >>>>>>> From the spec: >>>>>>> >>>>>>> "When a sector_identifier_uri is provided, the host component of >>>>>>> that URL is used as the Sector Identifier for the pairwise identifier >>>>>>> calculation. The value of the sector_identifier_uri MUST be a URL >>>>>>> using the https scheme that points to a JSON file containing an >>>>>>> array of redirect_uri values. The values of the registered >>>>>>> redirect_uris MUST be included in the elements of the array." >>>>>>> >>>>>>> What's your stance on sanity/health checking the >>>>>>> sector_identifier_uri? URI validation is one thing, but should we also make >>>>>>> a request to the uri in order to validate the response? >>>>>>> >>>>>>> The spec also mentions that the sector_identifier_uri isn't strictly >>>>>>> required if a client has all it's redirect_uris under the same domain. How >>>>>>> do we deal with changes to clients if the sector_identifier_uri isn't >>>>>>> required for enabling pairwise subs? >>>>>>> >>>>>>> Example: >>>>>>> >>>>>>> I create a client, enabling pairwise subs. Valid redirect_uris are [ >>>>>>> https://www.mydomain.com/* ]. The sector_identifier would be >>>>>>> mydomain. >>>>>>> >>>>>>> Later on, I update the redirect_uris to [ https://www.mydomain.com/*, >>>>>>> https://www.myotherdomain.com/* ] Do we >>>>>>> >>>>>>> * keep the old sector_identifier, or >>>>>>> * reject the update, or >>>>>>> * allow the update if a valid subject_identifier_uri is provided at >>>>>>> mydomain, or >>>>>>> * just allow it and let the client devs deal with the consequences, >>>>>>> or >>>>>>> * take some other path you can think of ? >>>>>>> >>>>>>> Having the sector_identifier_uri as a hard requirement seems safer, >>>>>>> but it's also means more work implementing a client. Leaving it optional is >>>>>>> a lot more scary. >>>>>>> >>>>>>> >>>>>>> On Thu, 18 Aug 2016 at 10:45 Stian Thorgersen >>>>>>> wrote: >>>>>>> >>>>>>>> Makes sense to make this pluggable. The default should >>>>>>>> probably SHA-256( sector_identifier || local_sub || salt ). >>>>>>>> >>>>>>>> We would love a PR for this, but there's a few bits required: >>>>>>>> >>>>>>>> * OIDC clients need option for subject type and >>>>>>>> sector_identifier_uri. If not set it should default to public so existing >>>>>>>> clients continue to work. These options can just be set as client >>>>>>>> attributes so there's no need to update db schema >>>>>>>> * Admin console update for the above >>>>>>>> * PairwiseSubGeneratorSpi and default implementation >>>>>>>> * Generation of salt for clients. This should be done when a client >>>>>>>> sets subject type to pairwise >>>>>>>> * Tests and docs >>>>>>>> >>>>>>>> I'd say the PairwiseSubGeneratorSpi signature should probably be: >>>>>>>> >>>>>>>> * public String getPairwiseSub(UserModel user, ClientModel client) >>>>>>>> >>>>>>>> It might even be an option to let the default PairwiseSubGenerator >>>>>>>> provider create the salt and store it as an attribute on the client, making >>>>>>>> that part pluggable as well. >>>>>>>> >>>>>>>> On 17 August 2016 at 15:59, Martin Hardselius < >>>>>>>> martin.hardselius at gmail.com> wrote: >>>>>>>> >>>>>>>>> I'm going to bump this, as I want to continue the >>>>>>>>> discussion/provide some input. >>>>>>>>> >>>>>>>>> Does it make sense to support more than type of pairwise subject >>>>>>>>> identifier generator? E.g through a PairwiseSubGeneratorSpi? >>>>>>>>> >>>>>>>>> Let's say I want to generate the pairwise sub as a salted hash: >>>>>>>>> sub = SHA-256( sector_identifier || local_sub || salt ) >>>>>>>>> To me, it makes sense to allow for per-client salts. These salts >>>>>>>>> should probably be generated and persisted during client creation. Thoughts? >>>>>>>>> >>>>>>>>> On Fri, 12 Aug 2016 at 09:57 Martin Hardselius < >>>>>>>>> martin.hardselius at gmail.com> wrote: >>>>>>>>> >>>>>>>>>> Thank you for your response. Did not see that ticket before. >>>>>>>>>> Great news! >>>>>>>>>> >>>>>>>>>> I looked into using protocol mappers to achieve this, and while >>>>>>>>>> it would work I'm worried that once KEYCLOAK-3422 has been resolved and >>>>>>>>>> included in a proper release we would run into migration issues if the >>>>>>>>>> method used for calculating "native" pairwise subs is different from what >>>>>>>>>> we implement. Clients could loose / be forced to re-register all their >>>>>>>>>> users if we decide to switch. The example methods in the spec are just >>>>>>>>>> that. Examples. Maybe the method/alg for computing the pairwise sub should >>>>>>>>>> be pluggable? >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> Martin >>>>>>>>>> >>>>>>>>>> On Thu, 11 Aug 2016 at 17:15 Marek Posolda >>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>>> Sorry for late response. >>>>>>>>>>> >>>>>>>>>>> We have JIRA created for that. You can possibly add yourself as >>>>>>>>>>> a watcher. See https://issues.jboss.org/browse/KEYCLOAK-3422 >>>>>>>>>>> >>>>>>>>>>> Maybe an alternative for you is to use protocolMappers. That >>>>>>>>>>> should allow you to "construct" the token for particular client exactly how >>>>>>>>>>> you want and also use the different value for "sub" claim. >>>>>>>>>>> >>>>>>>>>>> Another possibility is, to handle this on adapter side. We >>>>>>>>>>> already have an adapter option "principal-attribute", which specifies that >>>>>>>>>>> application will see the different attribute instead of "sub" as subject. >>>>>>>>>>> For example when in appllication you call >>>>>>>>>>> "httpServletRequest.getRemoteUser()" it will return "john" instead of >>>>>>>>>>> "123456-unique-johns-uuid" . See >>>>>>>>>>> https://keycloak.gitbooks.io/securing-client-applications-guide/content/v/2.1/topics/oidc/java/java-adapter-config.html >>>>>>>>>>> >>>>>>>>>>> Hopefully some of the options can be useful for you? >>>>>>>>>>> >>>>>>>>>>> Marek >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On 02/08/16 14:13, Martin Hardselius wrote: >>>>>>>>>>> >>>>>>>>>>> Me and my team are working towards getting Keycloak, customized >>>>>>>>>>> for our needs, into production but we've identified the need for Pairwise >>>>>>>>>>> Subject Identifiers as we don't want to expose internal user ids. >>>>>>>>>>> >>>>>>>>>>> Right now, the only subject_types_supported seems to be >>>>>>>>>>> "public". Are there any near-future plans to include "pairwise"? Can we >>>>>>>>>>> pitch in with a PR to make this happen as soon as possible? >>>>>>>>>>> >>>>>>>>>>> Links to relevant sections in the spec: >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> http://openid.net/specs/openid-connect-core-1_0.html#SubjectIDTypes >>>>>>>>>>> http://openid.net/specs/openid-connect-core-1_0.html#PairwiseAlg >>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>>> Martin >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> keycloak-dev mailing listkeycloak-dev at lists.jboss.orghttps://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 >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>> >>>> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160823/add1e6c1/attachment-0001.html From bburke at redhat.com Tue Aug 23 08:47:08 2016 From: bburke at redhat.com (Bill Burke) Date: Tue, 23 Aug 2016 08:47:08 -0400 Subject: [keycloak-dev] new credential SPI In-Reply-To: <57BBF9DE.7030703@redhat.com> References: <57BBF9DE.7030703@redhat.com> Message-ID: <44df3c3e-0d25-1ba0-182f-dd3ad04b8b5e@redhat.com> I never understood why all this is done at the UserFederationSPI level. Why isn't it done at the authenticator level? Its all protocol stuff. Would you do the same for bearer tokens if we had to? I don't think so. UserStorageSPI is supposed to be an abstraction for storage, not a protocol abstraction. On 8/23/16 3:23 AM, Marek Posolda wrote: > Few additional things, which applies for credentials like > SPNEGO/Kerberos tokens, however I think they might be required for > other credential types too. > > - Authentication of unknown user : For example in case of SPNEGO, you > have just the token, but you don't know which user are you > authenticating. User is "recognized" later once the SPNEGO token is > successfully validated > > - More handshakes for credential validation : This is again related to > SPNEGO, but I am sure it applies for some other credential types too. > Instead of true/false we may need something like : SUCCESS, FAILED, > CONTINUE. > Also the possibility to send some context info back to the client, so > client can continue with the handshake. For the old federationProvider > we had: > > CredentialValidationOutput validCredentials(RealmModel realm, UserCredentialModel credential); > > I guess we need something similar for the new SPI too? Also for > "isValid" method, I would rather return CredentialValidationOutput > instead of just true/false. True/false is good for passwords/OTP, > which are most widely used credential types in Keycloak, but may not > be sufficient for other custom credential types. > > Marek > > On 16/08/16 00:57, Bill Burke wrote: >> I'm currently working on a new credential SPI that will replace >> existing methods on UserProvider and UserModel, as well as replacing >> UserCredentialModel, etc. This is a work in progress where we may >> see multiple iterations in master. I hope to remain backward >> compatible, but can't guarentee I won't break existing User >> Federation Providers. Here's an initial writeup to explain things. >> Credentials revolve around these 4 events that are initiated by >> authentication flows, the admin console, and the account service. >> >> * Is the user configured for a specific credential type >> >> * Is a credential valid >> >> * What required actions must be taken for an unconfigured credential type >> >> * update a credential >> >> How each of these events is resolved will depend on the configuration >> of the system and these interfaces: >> >> public interface CredentialInput { >> String getType(); >> } >> >> public interface CredentialInputValidator { >> boolean supportsCredentialType(String credentialType); >> boolean isConfiguredFor(RealmModel realm, UserModel user, String credentialType); >> boolean isValid(RealmModel realm, UserModel user, CredentialInput input); >> >> } >> >> public interface CredentialInputUpdater { >> boolean supportsCredentialType(String credentialType); >> Set requiredActionsFor(RealmModel realm, UserModel user, String credentialType); >> void updateCredential(RealmModel realm, UserModel user, CredentialInput input); >> } >> >> Two different types of components will be able to implement these >> interfaces. UserStorageProviders (user federation) and >> CredentialProviders. CredentialProviders are components configured >> at the realm level. CredentialProviders are responsible for managing >> one or more types of credential types and are the bridge between >> CredentialInput and where the credential is stored. >> UserStorageProvider is always asked first whether it can complete the >> requested action, then CredentialProviders are queried in order of >> their priority. >> >> Each UserStorageProvider and/or CredentialProvider can implement the >> OnUserCache callback interface discussed in my previous custom >> caching email. This allows each credential type to decide whether it >> will be cached or not along with the user. For example, HOTP cannot >> be cached. >> >> So, for example, there will be a KeycloakMobileOTPProvider. This >> deals with Google Authenticator and FreeOTP as well as storing these >> things within Keycloak storage, it also looks at the OTP policy of >> the realm to determine how to update and store the OTP secret and >> stuff. There is also a KeycloakPasswordProvider which hooks into >> Keycloak storage and the PasswordPolicies set up by the realm. When >> a user is cached, the KeycloakPasswordProvider will add the hashed >> password to the user cache, the KeycloakMobileOTPProvider will add >> the OTP secret to cache if its not HOTP and needs to maintain a counter. >> >> Let's walk through an authentication flow, specificaly for OTP. >> >> 1. Authenticator calls KeycloakSession.users().isConfiguredFor(realm, >> user, "OTP"). If the user was loaded by a UserStorageProvider and >> that provider implements the CredentialInputValidator interface, >> isConfiguredFor() is called on that. If that returns false, each >> CredentialProvider is iterated on to call isConfiguredFor(). >> >> 2. If OTP is required and not configured for the user, the >> Authenticator then calls >> KeycloakSession.users().requiredActionsFor(...). Again, >> UserStorageProvider is queried first, then the CredneitalProviders. >> The first provider that returns a non-empty set will end the query >> and the set of required actions will be returned. >> >> 3a. Let's say that in this particular example, the generic OTP >> Requried Action screen is invoked. In that case, this required >> action provider callsKeycloakSession.users().updateCredential. The >> first UserStorageProvider or CredentialProvider that can handle this >> credential type will save the credential. >> >> 3b. If OTP is configured for user, the OTP is obtained by the >> Authenticator and KeycloakSession.users().isValid() method is >> called. Again, UserStorageProvider first, then each >> CredentialProvider. Each provider is queried until one returns true >> or the list is exhausted. FYI, This algorithm allows for multiple >> OTP authenticators per user. >> >> ** Admin console and Account Service UIs ** >> >> Like we do for other components, the UserStorageProvider or >> CredentialProvider can optionally provide a list of >> ProviderConfigProperties for the admin console and/or account >> serviceso that it can create a credential for a specific user. There >> will be separate property lists for admin console and account >> service. If a specific custom screen is desired, I'm pretty sure we >> can just allow the develoepr to plug in their own $routeProvider for >> the admin console. We don't have a pluggable mechanism for the >> account service yet (or a way to generic render either). This will >> need to be developed eventually. >> >> >> >> >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160823/83788c5a/attachment.html From bburke at redhat.com Tue Aug 23 09:04:21 2016 From: bburke at redhat.com (Bill Burke) Date: Tue, 23 Aug 2016 09:04:21 -0400 Subject: [keycloak-dev] Import users from new User Federation In-Reply-To: <57BBFDCB.4080705@redhat.com> References: <96ca98e1-f758-8e53-fac1-83f528079bc6@redhat.com> <1d491ec6-14d8-f1f8-3dbe-ad6b5c482f66@redhat.com> <57BBFDCB.4080705@redhat.com> Message-ID: On 8/23/16 3:39 AM, Marek Posolda wrote: > On 19/08/16 15:52, Bill Burke wrote: >> >> >> >> On 8/19/16 2:37 AM, Stian Thorgersen wrote: >>> >>> >>> On 18 August 2016 at 20:30, Bill Burke >> > wrote: >>> >>> >>> On 8/18/16 4:59 AM, Stian Thorgersen wrote: >>> > Bill, >>> > >>> > Are you planing to have an option to allow import of users >>> with the >>> > new user federation SPI? I'm not convinced we should >>> completely remove >>> > this option. >>> > >>> >>> The only callback that does not exist in the new SPI is >>> validateAndProxy(). With the current federation SPI, the developer >>> implements everything themselves for import. There are no >>> synchronization APIs/SPIs either. >>> >>> >>> Sounds like we're removing built-in features around synchronization >>> just to make the user have to do everything themselves. >> I think you misinterpreted me, The old User Federation SPI forces >> the developer to write all the import code themselves. The old User >> Federation SPI does not have any synchronization callbacks, methods >> or interfaces other than validateAndProxy(), the logic of which the >> user has to write themselves too. >> >> >>> > Some use-cases I could imagine: >>> > >>> > * Allow users to authenticate even if LDAP server is down >>> Our current LDAP provider will not work if LDAP is down, even >>> with the >>> import :) >>> >>> >>> Yes, I know. However, the fact that we don't currently support it >>> doesn't mean we shouldn't in the future. >> If the user can only be authenticated via LDAP, an offline mode is >> not possible. In other words, if LDAP does not expose the password >> of a user (so it can be imported), then offline mode is not >> possible. It would only be possible if the user has logged in at >> least once, then the validated password could be imported. >> >> So, do you still think we should support import/offline mode given >> all this? > From some recent discussions I saw, it seems that quite many people > are interested in the "import-and-forget" mode. So they need to import > user from their old legacy store (3rd party storage or LDAP) but once > user is fully in Keycloak DB, they want to completely forget about the > 3rd party storage and do all operations around this user against > Keycloak DB. > > The credentials/password validation seems to be the most complicated > part around this as you pointed, as the password needs to be first > successfully validated against 3rdparty storage or LDAP . Then once > password is successfully validated and updated to Keycloak DB, user > can be "forgotten" and unlinked from the federationProvider. I hope > the new SPI has a way to deal with this usecase? Or at least have a > hook, so the people can easily unlink the user by themselves whenever > they want. > As I said before, the current SPI does not have any support for import. It also does not have any SPIs around synchronization or any synchronization buttons in the admin console. It is up to the developer to write the code to import the user. And our current LDAP implmementation is not "import and forget", you already mentioned password validation, but there is also validateAndProxy which is called every time the user is accessed and which hits LDAP every time. There's also no way to unlink the user. So, #1, LDAP users are getting no real advantage to importing into our database with tremendous overhead #2, I do not think we have many people implementing their own custom providers. Why? We've had few questions on something that is really really hard to do (see the whole deployer discussion). I just think this whole import thing is a bad idea. Bill -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160823/4c294604/attachment-0001.html From singhrasster at gmail.com Tue Aug 23 09:05:31 2016 From: singhrasster at gmail.com (Rashmi Singh) Date: Tue, 23 Aug 2016 08:05:31 -0500 Subject: [keycloak-dev] Issue with single sign out using salesforce SP with keycloak IDP and also customizing the logout page In-Reply-To: References: Message-ID: On keycloak logs, I only see this error: 2016-08-23 00:49:24,648 WARN [org.keycloak.events] (default task-6) type=LOGIN_ERROR, realmId=saml-demo, clientId=null, userId=null, ipAddress=192.168.99.1, error=invalid_token This is a generic error and does not give any clue. I used SAML tracer with firefox and there I see the following request in RED: GET http://rashmiidp.cloud.com:9990/auth/realms/saml-demo/protocol/saml Here are the contents for this request from SAML tracer (but its not giving me any clue on what is wrong): GET http://rashmiidp.cloud.com:9990/auth/realms/saml-demo/protocol/saml HTTP/1.1 Host: rashmiidp.cloud.com:9990 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:47.0) Gecko/20100101 Firefox/47.0 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language: fr,en;q=0.8,nl-BE;q=0.7,es;q=0.5,es-ES;q=0.3,en-US;q=0.2 Accept-Encoding: gzip, deflate Cookie: KEYCLOAK_SESSION=saml-demo/6d25a0c6-7bb8-4cfc-b918- e3384f9dfe72/1e3911dc-3237-4aee-ba56-07de530e00f7; KC_RESTART= eyJhbGciOiJIUzI1NiJ9.eyJjcyI6ImI1M2QxOGJiLWQ3ODItND ZhNS04YjY5LWQxM2IxMDVhMTc4NSIsImNpZCI6Imh0dHBzOi8vc2FtbC5zYW xlc2ZvcmNlLmNvbSIsInB0eSI6InNhbWwiLCJydXJpIjoiaHR0cHM6Ly9yYX NobWk3ODktZGV2LWVkLm15LnNhbGVzZm9yY2UuY29tP3NvPTAwRDQxMDAwMD AwNUwxNCIsImFjdCI6IkFVVEhFTlRJQ0FURSIsIm5vdGVzIjp7ImFjdGlvbl 9rZXkiOiJmNDBmYTJmYi01YTM0LTRmZDQtYTc2NC0xZDI5NWVlZDFmODIiLC JSZWxheVN0YXRlIjoiLyIsIlNBTUxfUkVRVUVTVF9JRCI6Il8yQ0FBQUFWZE ZCal9tTUU4d05ERXdNREF3TURBMFF6azJBQUFBeWszaE1mODBfdTJ5cGVpSX pjVWNkQUtJWUFkeF9vNmN2Y0ZoMTE4QkcxWnFVRVQtREZJY29Wb1BqLUNheW ZFV2FHLXRCLUo3YXhHUEhGaWdWbmV3MEREQUVlTTdJR21KcURuMmpUOUlPOD VfT2pYTlVNQzlrbmV0cmRDcmpweDZCWTJjcWVCVWV0cldsb0JVaWhpMHBKMW 0tb2dBSmM1T1NDTXhIUkxpclNNR2FYRVhEeFpLVldadENfQTUwTFl6S1o2bm o3XzZ1ekhIak9qa01kYnpoY2RTZlVZS0Q2bVRhNmtCRjlweTRwQTB4bHg1eG RpN1M5OWc1d0xnSklmeVJ3Iiwic2FtbF9iaW5kaW5nIjoicG9zdCJ9fQ. E4kYw1y2Z3sOdXaa8eqNQ9Ca7r6t-7PFtY7JKNOLd-U; KEYCLOAK_IDENTITY= eyJhbGciOiJSUzI1NiJ9.eyJqdGkiOiJmNTQyYjY0Yy1iYTNhLT RiY2ItYmE2OC0xZGEyZTY0ZGRjMTQiLCJleHAiOjE0NzE5NDg2NjAsIm5iZi I6MCwiaWF0IjoxNDcxOTEyNjYwLCJpc3MiOiJodHRwOi8vcmFzaG1paWRwLm Nsb3VkLmNvbTo5OTkwL2F1dGgvcmVhbG1zL3NhbWwtZGVtbyIsInN1YiI6Ij ZkMjVhMGM2LTdiYjgtNGNmYy1iOTE4LWUzMzg0ZjlkZmU3MiIsInNlc3Npb2 5fc3RhdGUiOiIxZTM5MTFkYy0zMjM3LTRhZWUtYmE1Ni0wN2RlNTMwZTAwZj ciLCJyZXNvdXJjZV9hY2Nlc3MiOnt9fQ.IfnQezJi5hCMHac2K3B9QnjWdx4SR7 F1TGV2JlbPxF0lOAqLzK5XaQgOO8p8z9XY-u0hN4DLFePXjzLOl0UwYaZ0ySxm-l- gUsCkveVzTPRMS98ekuTMlc-1fPI4h1tCRrVawW5zOgH7zc- a03KK0WZJ6b3iuU49PGsDXmeiNb6aqG-BIrmSkfsjfXr4zB69PcY0EF3sse0jl OkZXYBcmbH46b_fWm-p4hpyt6QnGvxanKOc2jtavkUPSo5UrQxmQ3- ahfxqZOFAvRbeHys5RdUUHs5BBefjkE4p8teCeG0nNzpgJfgPHgMNsnjELrTSafTcq1AM-yV2UOWrYeh0sA; testusergrid={} HTTP/?.? 500 Internal Server Error Cache-Control: no-store, must-revalidate, max-age=0 X-Powered-By: Undertow/1 Server: WildFly/10 X-Frame-Options: SAMEORIGIN content-security-policy: frame-src 'self' Date: Tue, 23 Aug 2016 00:37:56 GMT Connection: keep-alive X-Content-Type-Options: nosniff Content-Type: text/html;charset=utf-8 Content-Length: 2906 Does this give you any idea? Do you have any more suggestions? On Mon, Aug 22, 2016 at 7:54 PM, Rashmi Singh wrote: > John, On keycloak logs, I only see this error: > > 2016-08-23 00:49:24,648 WARN [org.keycloak.events] (default task-6) > type=LOGIN_ERROR, realmId=saml-demo, clientId=null, userId=null, > ipAddress=192.168.99.1, error=invalid_token > > This is a generic error and does not give any clue. > > I used SAML tracer with firefox and there I see the following request in > RED: > > GET http://rashmiidp.cloud.com:9990/auth/realms/saml-demo/protocol/saml > Here are the contents for this request from SAML tracer (but its not > giving me any clue on what is wrong): > > GET http://rashmiidp.cloud.com:9990/auth/realms/saml-demo/protocol/saml > HTTP/1.1 > Host: rashmiidp.cloud.com:9990 > User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:47.0) Gecko/20100101 > Firefox/47.0 > Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 > Accept-Language: fr,en;q=0.8,nl-BE;q=0.7,es;q=0.5,es-ES;q=0.3,en-US;q=0.2 > Accept-Encoding: gzip, deflate > Cookie: KEYCLOAK_SESSION=saml-demo/6d25a0c6-7bb8-4cfc-b918- > e3384f9dfe72/1e3911dc-3237-4aee-ba56-07de530e00f7; KC_RESTART= > eyJhbGciOiJIUzI1NiJ9.eyJjcyI6ImI1M2QxOGJiLWQ3ODItND > ZhNS04YjY5LWQxM2IxMDVhMTc4NSIsImNpZCI6Imh0dHBzOi8vc2FtbC5zYW > xlc2ZvcmNlLmNvbSIsInB0eSI6InNhbWwiLCJydXJpIjoiaHR0cHM6Ly9yYX > NobWk3ODktZGV2LWVkLm15LnNhbGVzZm9yY2UuY29tP3NvPTAwRDQxMDAwMD > AwNUwxNCIsImFjdCI6IkFVVEhFTlRJQ0FURSIsIm5vdGVzIjp7ImFjdGlvbl > 9rZXkiOiJmNDBmYTJmYi01YTM0LTRmZDQtYTc2NC0xZDI5NWVlZDFmODIiLC > JSZWxheVN0YXRlIjoiLyIsIlNBTUxfUkVRVUVTVF9JRCI6Il8yQ0FBQUFWZE > ZCal9tTUU4d05ERXdNREF3TURBMFF6azJBQUFBeWszaE1mODBfdTJ5cGVpSX > pjVWNkQUtJWUFkeF9vNmN2Y0ZoMTE4QkcxWnFVRVQtREZJY29Wb1BqLUNheW > ZFV2FHLXRCLUo3YXhHUEhGaWdWbmV3MEREQUVlTTdJR21KcURuMmpUOUlPOD > VfT2pYTlVNQzlrbmV0cmRDcmpweDZCWTJjcWVCVWV0cldsb0JVaWhpMHBKMW > 0tb2dBSmM1T1NDTXhIUkxpclNNR2FYRVhEeFpLVldadENfQTUwTFl6S1o2bm > o3XzZ1ekhIak9qa01kYnpoY2RTZlVZS0Q2bVRhNmtCRjlweTRwQTB4bHg1eG > RpN1M5OWc1d0xnSklmeVJ3Iiwic2FtbF9iaW5kaW5nIjoicG9zdCJ9fQ. > E4kYw1y2Z3sOdXaa8eqNQ9Ca7r6t-7PFtY7JKNOLd-U; KEYCLOAK_IDENTITY= > eyJhbGciOiJSUzI1NiJ9.eyJqdGkiOiJmNTQyYjY0Yy1iYTNhLT > RiY2ItYmE2OC0xZGEyZTY0ZGRjMTQiLCJleHAiOjE0NzE5NDg2NjAsIm5iZi > I6MCwiaWF0IjoxNDcxOTEyNjYwLCJpc3MiOiJodHRwOi8vcmFzaG1paWRwLm > Nsb3VkLmNvbTo5OTkwL2F1dGgvcmVhbG1zL3NhbWwtZGVtbyIsInN1YiI6Ij > ZkMjVhMGM2LTdiYjgtNGNmYy1iOTE4LWUzMzg0ZjlkZmU3MiIsInNlc3Npb2 > 5fc3RhdGUiOiIxZTM5MTFkYy0zMjM3LTRhZWUtYmE1Ni0wN2RlNTMwZTAwZj > ciLCJyZXNvdXJjZV9hY2Nlc3MiOnt9fQ.IfnQezJi5hCMHac2K3B9QnjWdx4SR7 > F1TGV2JlbPxF0lOAqLzK5XaQgOO8p8z9XY-u0hN4DLFePXjzLOl0UwYaZ0ySxm-l- > gUsCkveVzTPRMS98ekuTMlc-1fPI4h1tCRrVawW5zOgH7zc- > a03KK0WZJ6b3iuU49PGsDXmeiNb6aqG-BIrmSkfsjfXr4zB69PcY0EF3sse0jl > OkZXYBcmbH46b_fWm-p4hpyt6QnGvxanKOc2jtavkUPSo5UrQxmQ3- > ahfxqZOFAvRbeHys5RdUUHs5BBefjkE4p8teCeG0nNzpgJfgPHgMNsnjELrTSafTcq1AM-yV2UOWrYeh0sA; > testusergrid={} > > HTTP/?.? 500 Internal Server Error > Cache-Control: no-store, must-revalidate, max-age=0 > X-Powered-By: Undertow/1 > Server: WildFly/10 > X-Frame-Options: SAMEORIGIN > content-security-policy: frame-src 'self' > Date: Tue, 23 Aug 2016 00:37:56 GMT > Connection: keep-alive > X-Content-Type-Options: nosniff > Content-Type: text/html;charset=utf-8 > Content-Length: 2906 > > > Does this give you any idea? Do you have any more suggestions? > > > On Fri, Aug 19, 2016 at 7:52 AM, John Dennis wrote: > >> On 08/18/2016 10:06 PM, Rashmi Singh wrote: >> >>> Hi, >>> >>> I have setup a Salesforce Saml SP in keycloak. So, I basically created a >>> new client from keycloak admin console for salesforce. This is how my SP >>> url looks like: >>> >>> rashmi789-dev-ed.my.salesforce.com >>> >>> >>> I edited the salesforce configuration settings to point it to the >>> keycloak IDP. So, when I access the SP: >>> http://rashmi789-dev-ed.my.salesforce.com >>> >>> I am successfully taken to the keycloak IDP page (where I have >>> configured my Authenticator). I enter my credentials there and am able >>> to login. But, now when I try to logout, I get the following error on >>> the web page: >>> >>> We're sorry ... >>> Invalid Request >>> >> >> Is logout supported on both ends (i.e. SP and IdP)? The definition of >> support is in the metadata of each entity. Is there a SingleLogoutService >> binding with a valid location URL in each metadata? The vast majority of >> SAML problems are directly attributable to the metadata because that is >> what drives the conversation between the SP and IdP. You have access to >> both metadata because it was necessary to load the metadata in each party. >> >> If the problem is not the absence of SingleLogoutService then I would try >> tracing the flow. That is easy with the Firefox browser and the SAMLTracer >> add-on. That will let you see the exchange of messages and identify who the >> offending party is. >> >> So, single sign out does not seem to be working for me. What is the >>> issue? Is it a problem with the IDP logout url that I have configured? >>> What I have is: >>> >>> http://rashmiidp.cloud.com:9990/auth/realms/saml-demo/protocol/saml >>> >>> >>> my IDP Login URL is: >>> http://rashmiidp.cloud.com:9990/auth/realms/saml-demo/protocol/saml >>> >>> and that seem to be perfectly fine as I am able to login without any >>> issue. what is the issue with the logout I am seeing above when using a >>> Salesforce SP with keycloak? Please let me know if you need me to >>> provide more details. >>> >> >> This suggests the problem is not with the IdP. Keycloak uses the same URL >> for all services (don't assume this is always the case, it's just one >> implementation choice). If login to the same URL works a valid >> LogoutRequest to the same URL should also work, provided of course it a >> valid SAML Request. Are there any errors in the Keycloak log concerning >> invalid requests. >> >> Once again. using SAMLTracer will help nail down who is generating the >> error and what the content of the message was that induced it. >> >> >> Also, once this issue is resolved and I am able to logout successfully, >>> could you give some insights on how to customize the logout page? >>> >>> >>> >>> >>> _______________________________________________ >>> keycloak-dev mailing list >>> keycloak-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>> >>> >> >> -- >> John >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160823/1412dfbf/attachment.html From singhrasster at gmail.com Tue Aug 23 09:06:20 2016 From: singhrasster at gmail.com (Rashmi Singh) Date: Tue, 23 Aug 2016 08:06:20 -0500 Subject: [keycloak-dev] Customize logout page on keycloak In-Reply-To: References: <20160822120018.GB8834@abstractj.org> Message-ID: This page seems to be just a documentation on themes etc. My question is when I do a logout from a SAML SP, how do I get an IDP logout page and how do I then customize it? Currently, I am not even getting a logout page. Can you explain how to get an IDP logout page? On Mon, Aug 22, 2016 at 4:44 PM, Rashmi Singh wrote: > Bruno, This page seems to be just a documentation on themes etc. My > question is when I do a logout from a SAML SP, how do I get an IDP logout > page and how do I then customize it? Currently, I am not even getting a > logout page. Can you explain how to get an IDP logout page? > > On Mon, Aug 22, 2016 at 7:00 AM, Bruno Oliveira > wrote: > >> Please, look at the docs[1]. >> >> [1] - https://keycloak.gitbooks.io/server-developer-guide/ >> >> On 2016-08-21, Rashmi Singh wrote: >> > I would like to customize the logout page for the IDP on keycloak. Could >> > you provide some insights/pointers on how to do this? >> >> > _______________________________________________ >> > keycloak-dev mailing list >> > keycloak-dev at lists.jboss.org >> > https://lists.jboss.org/mailman/listinfo/keycloak-dev >> >> >> -- >> >> abstractj >> PGP: 0x84DC9914 >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160823/d3f6a047/attachment-0001.html From mposolda at redhat.com Tue Aug 23 09:38:22 2016 From: mposolda at redhat.com (Marek Posolda) Date: Tue, 23 Aug 2016 15:38:22 +0200 Subject: [keycloak-dev] Pairwise Subject Identifier In-Reply-To: References: <57AC9686.5040807@redhat.com> <57BB6324.2030403@redhat.com> Message-ID: <57BC51CE.9020504@redhat.com> We discussed it with Stian a bit and we discussed to: - Implement as protocolMapper - There will be possibility to configure "salt" as parameter to protocolMapper. It may not be mandatory parameter. If it's used, then client will use it as salt, otherwise salt will be generated. This allows the use-case you mentioned. You can use same salt for clients x,y,z but different salt for clients m,n. If you let generate salt, then the subject identifiers will be really unique just to the particular client. - We need to validate sector_identifier_uri during create/update of protocolMapper, but also during update of client. Otherwise someone can register sector_identifier_uri and register the client with valid redirect_uris (for example URLs "http://good-host/url1" "http://good-host/url2" , which are both specified under sector_identifier_uri ) but then later update just the client redirect_uris to "http://evil-host/url1" . Basically he will be able to update redirect_uris to anything he wants regardless of redirect_uris under sector_identifier_uri, so the whole validation will be bypassed. For updating client, I've just sent PR, which adds RealmModel.ClientUpdatedEvent . You can register to that event similarly like https://github.com/keycloak/keycloak/blob/master/server-spi/src/main/java/org/keycloak/protocol/AbstractLoginProtocolFactory.java#L39 . The creation/update listener for protocolMapper doesn't yet exists, however we are likely going to refactor protocolMapper to generic component, which will have validation support. But that will be likely available in few weeks, so for now, we can add something temporary for protocolMappers similar to what is available for example for UserFederationMapperFactory (See https://github.com/keycloak/keycloak/blob/master/services/src/main/java/org/keycloak/services/resources/admin/UserFederationProviderResource.java#L437-L440 ) Martin, will you have some time to eventually look into this and send PR ? Marek On 23/08/16 14:25, Martin Hardselius wrote: > Let's say we want to force all of our client to use pairwise subs, but > a single "merchant" needs to implement several clients where subs > should remain the same for all those clients. > > Merchant A > - client x > - client y > - client z > > Merchant B > - client m > - client n > > You can assume the sector_identifiers are the same across all clients > owned by a merchant > > It should not be possible to correlate activities between Customer A > and Customer B (at least not from their side). They should, however, > be able to correlate user activities between their own clients. > > Which implementation of pairwise subs is better suited for supporting > this scenario? I'm leaning towards the protocol mapper solution. It > should be easier to create custom mappers with merchant-wide > configuration (e.g salts). > > On Mon, 22 Aug 2016 at 22:40 Marek Posolda > wrote: > > The question is, should we really introduce another SPI for that? > Doesn't it mean uneccessary complexity? Also add the new options > directly to the client for the feature, which is likely > interesting just for quite limited amount of people? > > IMO it's fine if this is implemented as protocolMapper? > > Few thoughts: > - We can have abstract superclass like > AbstractPairwiseSubGeneratorMapper . The subclasses will just need > to implement method "generateSub" . We can have just one concrete > impl, which will use SHA-256( sector_identifier || local_sub || salt ) > > - The sector_identifier_uri will be a configuration option of this > protocolMapper implementation. > > - If protocolMapper is not added to client, the client will just > use the public subjects. By default it's not added, which ensures > backwards compatibility and public subjects by default. Note that > with this approach, we don't even need subject_type option on the > client. > > - The salt can be generated lazily at the first time when mapper > is used. > > - The validation can be done at the moment, when protocolMapper is > going to be created/updated. Right now, we don't have validation > callback during protocolMapper creation/update. However Bill is > going to add support for that into generic componentModel. So if > we're going to refactor protocolMapper to use the new generic > component model, we will have validation callback available to > protocolMapper SPI. The validation will fail if array of > redirect_uri from sector_identifier_uri doesn't contain the uris > from redirect_uri of particular client (including wildcards etc). > > - If client is updated and it's redirect_uri are changed, we won't > be able to catch this, however this is not strictly required per > specs per my understanding. At least the dynamic client > registration specs sais [1] > > "The values registered in redirect_uris MUST be included in the > elements of the array, or registration MUST fail. This MUST be > validated at registration time; there is no requirement for the OP > to retain the contents of this JSON file or to retrieve or > revalidate its contents in the future. " > > [1] > http://openid.net/specs/openid-connect-registration-1_0.html#SectorIdentifierValidation > > > Marek > > > On 22/08/16 15:50, Martin Hardselius wrote: >> Ok, thanks for the clarification. >> >> Where would it make sense to put the PairwiseSubGeneratorSpi? >> Which package, that is? >> >> On Mon, 22 Aug 2016 at 14:51 Stian Thorgersen >> > wrote: >> >> On 22 August 2016 at 14:16, Martin Hardselius >> > > wrote: >> >> "IMO it's sufficient to document the algorithm to create >> the sub, which should make it clear that the origin in >> the redirect uri will affect the sub." >> >> Reasonable. :) >> >> "One client could also have multiple redirect uris with >> different origins so could get different sub's generated >> depending on the redirect uri used." >> >> That case is probably caught by >> [...] If there are multiple hostnames in the >> registeredredirect_uris, the Client MUST register >> asector_identifier_uri. [...] >> >> >> Yes, but I meant from a documentation perspective. It should >> be clear from the documentation that is the case. >> >> >> On Mon, 22 Aug 2016 at 10:42 Stian Thorgersen >> > wrote: >> >> IMO it's sufficient to document the algorithm to >> create the sub, which should make it clear that the >> origin in the redirect uri will affect the sub. One >> client could also have multiple redirect uris with >> different origins so could get different sub's >> generated depending on the redirect uri used. >> >> On 22 August 2016 at 09:58, Martin Hardselius >> > > wrote: >> >> Sounds fair enough. >> >> What about the case where you don't provide a >> sector_identifier_uri, set up a single redirect >> uri on myhost and then later go on to change that >> redirect uri to something on myotherhost? That >> would change the sector_identifier and >> subsequently all the user subs. Do we protect >> against such "mistakes" or do we warn people (in >> the docs and/or admin gui) that it's not a good >> idea to do that? >> >> On Mon, 22 Aug 2016 at 09:38 Stian Thorgersen >> > > wrote: >> >> We need to follow the spec and verify that >> sector_identifier_uri points to a URL that >> contains the corresponding URIs. As an >> enhancement we could support wildcards in the >> JSON returned by sector_identifier_uri. For >> example if it returns: >> >> [https://www.mydomain.com/*, >> https://www.myotherdomain.com/* ] >> >> A client with the redirect uri >> 'https://www.myotherdomain.com/myapp' would work >> >> On 18 August 2016 at 15:09, Martin Hardselius >> > > wrote: >> >> Speaking of subject_identifier_uri >> >> From the spec: >> >> "When asector_identifier_uriis provided, >> the host component of that URL is used as >> the Sector Identifier for the pairwise >> identifier calculation. The value of >> thesector_identifier_uriMUST be a URL >> using thehttpsscheme that points to a >> JSON file containing an array >> ofredirect_urivalues. The values of the >> registeredredirect_urisMUST be included >> in the elements of the array." >> >> What's your stance on sanity/health >> checking the sector_identifier_uri? URI >> validation is one thing, but should we >> also make a request to the uri in order >> to validate the response? >> >> The spec also mentions that the >> sector_identifier_uri isn't strictly >> required if a client has all it's >> redirect_uris under the same domain. How >> do we deal with changes to clients if the >> sector_identifier_uri isn't required for >> enabling pairwise subs? >> >> Example: >> >> I create a client, enabling pairwise >> subs. Valid redirect_uris are [ >> https://www.mydomain.com/* ]. The >> sector_identifier would be mydomain. >> >> Later on, I update the redirect_uris to >> [https://www.mydomain.com/*, >> https://www.myotherdomain.com/* ] Do we >> >> * keep the old sector_identifier, or >> * reject the update, or >> * allow the update if a valid >> subject_identifier_uri is provided at >> mydomain, or >> * just allow it and let the client devs >> deal with the consequences, or >> * take some other path you can think of ? >> >> Having the sector_identifier_uri as a >> hard requirement seems safer, but it's >> also means more work implementing a >> client. Leaving it optional is a lot more >> scary. >> >> >> On Thu, 18 Aug 2016 at 10:45 Stian >> Thorgersen > > wrote: >> >> Makes sense to make this pluggable. >> The default should probably SHA-256( >> sector_identifier || local_sub || >> salt ). >> >> We would love a PR for this, but >> there's a few bits required: >> >> * OIDC clients need option for >> subject type and >> sector_identifier_uri. If not set it >> should default to public so existing >> clients continue to work. These >> options can just be set as client >> attributes so there's no need to >> update db schema >> * Admin console update for the above >> * PairwiseSubGeneratorSpi and default >> implementation >> * Generation of salt for clients. >> This should be done when a client >> sets subject type to pairwise >> * Tests and docs >> >> I'd say the PairwiseSubGeneratorSpi >> signature should probably be: >> >> * public String >> getPairwiseSub(UserModel user, >> ClientModel client) >> >> It might even be an option to let the >> default PairwiseSubGenerator provider >> create the salt and store it as an >> attribute on the client, making that >> part pluggable as well. >> >> On 17 August 2016 at 15:59, Martin >> Hardselius >> > > >> wrote: >> >> I'm going to bump this, as I want >> to continue the >> discussion/provide some input. >> >> Does it make sense to support >> more than type of pairwise >> subject identifier generator? E.g >> through a PairwiseSubGeneratorSpi? >> >> Let's say I want to generate the >> pairwise sub as a salted hash: >> sub = SHA-256( sector_identifier >> || local_sub || salt ) >> To me, it makes sense to allow >> for per-client salts. These salts >> should probably be generated and >> persisted during client creation. >> Thoughts? >> >> On Fri, 12 Aug 2016 at 09:57 >> Martin Hardselius >> > > >> wrote: >> >> Thank you for your response. >> Did not see that ticket >> before. Great news! >> >> I looked into using protocol >> mappers to achieve this, and >> while it would work I'm >> worried that once >> KEYCLOAK-3422 has been >> resolved and included in a >> proper release we would run >> into migration issues if the >> method used for calculating >> "native" pairwise subs is >> different from what we >> implement. Clients could >> loose / be forced to >> re-register all their users >> if we decide to switch. The >> example methods in the spec >> are just that. Examples. >> Maybe the method/alg for >> computing the pairwise sub >> should be pluggable? >> >> -- >> Martin >> >> On Thu, 11 Aug 2016 at 17:15 >> Marek Posolda >> > > >> wrote: >> >> Sorry for late response. >> >> We have JIRA created for >> that. You can possibly >> add yourself as a >> watcher. See >> https://issues.jboss.org/browse/KEYCLOAK-3422 >> >> Maybe an alternative for >> you is to use >> protocolMappers. That >> should allow you to >> "construct" the token for >> particular client exactly >> how you want and also use >> the different value for >> "sub" claim. >> >> Another possibility is, >> to handle this on adapter >> side. We already have an >> adapter option >> "principal-attribute", >> which specifies that >> application will see the >> different attribute >> instead of "sub" as >> subject. For example when >> in appllication you call >> "httpServletRequest.getRemoteUser()" >> it will return "john" >> instead of >> "123456-unique-johns-uuid" . >> See >> https://keycloak.gitbooks.io/securing-client-applications-guide/content/v/2.1/topics/oidc/java/java-adapter-config.html >> >> Hopefully some of the >> options can be useful for >> you? >> >> Marek >> >> >> On 02/08/16 14:13, Martin >> Hardselius wrote: >>> Me and my team are >>> working towards getting >>> Keycloak, customized for >>> our needs, into >>> production but we've >>> identified the need for >>> Pairwise Subject >>> Identifiers as we don't >>> want to expose internal >>> user ids. >>> >>> Right now, the only >>> subject_types_supported >>> seems to be "public". >>> Are there any >>> near-future plans to >>> include "pairwise"? Can >>> we pitch in with a PR to >>> make this happen as soon >>> as possible? >>> >>> Links to relevant >>> sections in the spec: >>> >>> http://openid.net/specs/openid-connect-core-1_0.html#SubjectIDTypes >>> http://openid.net/specs/openid-connect-core-1_0.html#PairwiseAlg >>> >>> -- >>> Martin >>> >>> >>> _______________________________________________ >>> 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 >> >> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160823/5915e67d/attachment-0001.html From bburke at redhat.com Tue Aug 23 09:43:44 2016 From: bburke at redhat.com (Bill Burke) Date: Tue, 23 Aug 2016 09:43:44 -0400 Subject: [keycloak-dev] rethinking credentials In-Reply-To: References: <49425643-9824-9fb7-d3c0-8fea12539f94@redhat.com> <57AC8E20.3020809@redhat.com> <20160816141238.GC19203@abstractj.org> <57BBFBB8.8010804@redhat.com> Message-ID: <44154574-cece-b6f7-010d-0d6202433d13@redhat.com> I'm only thinking about users right now. That in itself is a big complex problem. Clients are users, so how would they be different? On 8/23/16 7:38 AM, Stian Thorgersen wrote: > If we're introducing a new credentials SPI should be consider using it > for realms and clients as well? > > Realms currently have a few things, but we soon need to support key > rotation which would mean a realm could have more than one keypair at > a time > > Clients already have secret or keypair based auth, but will in the > future need certs. Then there's also needs for custom authenticators > to store credentials. > > On 23 August 2016 at 09:31, Marek Posolda > wrote: > > On 16/08/16 22:51, Bill Burke wrote: > > > > > > On 8/16/16 10:12 AM, Bruno Oliveira wrote: > >> On 2016-08-11, Marek Posolda wrote: > >>> I wonder if we can have UserCredentialValueModel to be more > generic > >>> store? Currently it has properties applicable just to password > or OTP > >>> credentials, but it will be better to have something more > generic based > >>> on key-value pairs though. > >> +1 that would be fantastic, if possible. > > A data model that can store any arbitrary key-value pair would > require > > a join with RDBMs storage. Should we keep something like > > UsercredValModel, but just add the ability for attributes? Then > model > > the API so that it can avoid joins? There's also the issue of data > > migration from the old tables to the new. Since this is users we > > could be talking about tens of thousands of rows. > Yep, maybe we can keep the "old" attributes on the > UserCredValModel, so > it's not needed to migrate and most important credential types ( > password, OTP) don't need to change anything. Still we can add > key-value > for other credential types? Maybe the caching of users and user > credentials also helps with the performance, so the performance > bottleneck of joins won't be so bad (but yes, I know that we need to > limit size of userCache cache, so the same user and his credential may > be still downloaded from underlying DB multiple times...) > > Marek > > > > Bill > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160823/8690586d/attachment.html From bburke at redhat.com Tue Aug 23 09:45:05 2016 From: bburke at redhat.com (Bill Burke) Date: Tue, 23 Aug 2016 09:45:05 -0400 Subject: [keycloak-dev] Customize logout page on keycloak In-Reply-To: References: <20160822120018.GB8834@abstractj.org> Message-ID: There is no such thing as an IDP logout page right now. On 8/23/16 9:06 AM, Rashmi Singh wrote: > This page seems to be just a documentation on themes etc. My question > is when I do a logout from a SAML SP, how do I get an IDP logout page > and how do I then customize it? Currently, I am not even getting a > logout page. Can you explain how to get an IDP logout page? > > > > On Mon, Aug 22, 2016 at 4:44 PM, Rashmi Singh > wrote: > > Bruno, This page seems to be just a documentation on themes etc. > My question is when I do a logout from a SAML SP, how do I get an > IDP logout page and how do I then customize it? Currently, I am > not even getting a logout page. Can you explain how to get an IDP > logout page? > > On Mon, Aug 22, 2016 at 7:00 AM, Bruno Oliveira > > wrote: > > Please, look at the docs[1]. > > [1] - https://keycloak.gitbooks.io/server-developer-guide/ > > > On 2016-08-21, Rashmi Singh wrote: > > I would like to customize the logout page for the IDP on > keycloak. Could > > you provide some insights/pointers on how to do this? > > > _______________________________________________ > > keycloak-dev mailing list > > keycloak-dev at lists.jboss.org > > > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > > -- > > abstractj > PGP: 0x84DC9914 > > > > > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160823/2e0e08dc/attachment.html From singhrasster at gmail.com Tue Aug 23 09:46:59 2016 From: singhrasster at gmail.com (Rashmi Singh) Date: Tue, 23 Aug 2016 08:46:59 -0500 Subject: [keycloak-dev] Customize logout page on keycloak In-Reply-To: References: <20160822120018.GB8834@abstractj.org> Message-ID: So, after successful logout, there is no way to show a custom page on IDP? On Tue, Aug 23, 2016 at 8:45 AM, Bill Burke wrote: > There is no such thing as an IDP logout page right now. > > On 8/23/16 9:06 AM, Rashmi Singh wrote: > > This page seems to be just a documentation on themes etc. My question is > when I do a logout from a SAML SP, how do I get an IDP logout page and how > do I then customize it? Currently, I am not even getting a logout page. Can > you explain how to get an IDP logout page? > > > > On Mon, Aug 22, 2016 at 4:44 PM, Rashmi Singh > wrote: > >> Bruno, This page seems to be just a documentation on themes etc. My >> question is when I do a logout from a SAML SP, how do I get an IDP logout >> page and how do I then customize it? Currently, I am not even getting a >> logout page. Can you explain how to get an IDP logout page? >> >> On Mon, Aug 22, 2016 at 7:00 AM, Bruno Oliveira >> wrote: >> >>> Please, look at the docs[1]. >>> >>> [1] - https://keycloak.gitbooks.io/server-developer-guide/ >>> >>> On 2016-08-21, Rashmi Singh wrote: >>> > I would like to customize the logout page for the IDP on keycloak. >>> Could >>> > you provide some insights/pointers on how to do this? >>> >>> > _______________________________________________ >>> > keycloak-dev mailing list >>> > keycloak-dev at lists.jboss.org >>> > https://lists.jboss.org/mailman/listinfo/keycloak-dev >>> >>> >>> -- >>> >>> abstractj >>> PGP: 0x84DC9914 >>> >> >> > > > _______________________________________________ > keycloak-dev mailing listkeycloak-dev at lists.jboss.orghttps://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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160823/d915b770/attachment.html From bburke at redhat.com Tue Aug 23 09:50:13 2016 From: bburke at redhat.com (Bill Burke) Date: Tue, 23 Aug 2016 09:50:13 -0400 Subject: [keycloak-dev] Customize logout page on keycloak In-Reply-To: References: <20160822120018.GB8834@abstractj.org> Message-ID: We just follow the SAML or OIDC protocol and redirect back to the app that requested the logout. On 8/23/16 9:46 AM, Rashmi Singh wrote: > So, after successful logout, there is no way to show a custom page on IDP? > > On Tue, Aug 23, 2016 at 8:45 AM, Bill Burke > wrote: > > There is no such thing as an IDP logout page right now. > > > On 8/23/16 9:06 AM, Rashmi Singh wrote: >> This page seems to be just a documentation on themes etc. My >> question is when I do a logout from a SAML SP, how do I get an >> IDP logout page and how do I then customize it? Currently, I am >> not even getting a logout page. Can you explain how to get an IDP >> logout page? >> >> >> >> On Mon, Aug 22, 2016 at 4:44 PM, Rashmi Singh >> > wrote: >> >> Bruno, This page seems to be just a documentation on themes >> etc. My question is when I do a logout from a SAML SP, how do >> I get an IDP logout page and how do I then customize it? >> Currently, I am not even getting a logout page. Can you >> explain how to get an IDP logout page? >> >> On Mon, Aug 22, 2016 at 7:00 AM, Bruno Oliveira >> > wrote: >> >> Please, look at the docs[1]. >> >> [1] - >> https://keycloak.gitbooks.io/server-developer-guide/ >> >> >> On 2016-08-21, Rashmi Singh wrote: >> > I would like to customize the logout page for the IDP >> on keycloak. Could >> > you provide some insights/pointers on how to do this? >> >> > _______________________________________________ >> > keycloak-dev mailing list >> > keycloak-dev at lists.jboss.org >> >> > https://lists.jboss.org/mailman/listinfo/keycloak-dev >> >> >> >> -- >> >> abstractj >> PGP: 0x84DC9914 >> >> >> >> >> >> _______________________________________________ >> 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 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160823/ca6ad7f4/attachment-0001.html From bburke at redhat.com Tue Aug 23 09:52:58 2016 From: bburke at redhat.com (Bill Burke) Date: Tue, 23 Aug 2016 09:52:58 -0400 Subject: [keycloak-dev] Customize logout page on keycloak In-Reply-To: References: <20160822120018.GB8834@abstractj.org> Message-ID: <9f95066f-6338-4499-7745-73d7c7bdc437@redhat.com> Actually thats just the server side. If you are using a SAML client adapter, then you can specify the logout page: https://keycloak.gitbooks.io/securing-client-applications-guide/content/v/2.1/topics/saml/java/general-config.html its the logout attribute on the SP element. Looks like we forgot to actually document it other than the example provided. On 8/23/16 9:50 AM, Bill Burke wrote: > > We just follow the SAML or OIDC protocol and redirect back to the app > that requested the logout. > > > On 8/23/16 9:46 AM, Rashmi Singh wrote: >> So, after successful logout, there is no way to show a custom page on >> IDP? >> >> On Tue, Aug 23, 2016 at 8:45 AM, Bill Burke > > wrote: >> >> There is no such thing as an IDP logout page right now. >> >> >> On 8/23/16 9:06 AM, Rashmi Singh wrote: >>> This page seems to be just a documentation on themes etc. My >>> question is when I do a logout from a SAML SP, how do I get an >>> IDP logout page and how do I then customize it? Currently, I am >>> not even getting a logout page. Can you explain how to get an >>> IDP logout page? >>> >>> >>> >>> On Mon, Aug 22, 2016 at 4:44 PM, Rashmi Singh >>> > wrote: >>> >>> Bruno, This page seems to be just a documentation on themes >>> etc. My question is when I do a logout from a SAML SP, how >>> do I get an IDP logout page and how do I then customize it? >>> Currently, I am not even getting a logout page. Can you >>> explain how to get an IDP logout page? >>> >>> On Mon, Aug 22, 2016 at 7:00 AM, Bruno Oliveira >>> > wrote: >>> >>> Please, look at the docs[1]. >>> >>> [1] - >>> https://keycloak.gitbooks.io/server-developer-guide/ >>> >>> >>> On 2016-08-21, Rashmi Singh wrote: >>> > I would like to customize the logout page for the IDP >>> on keycloak. Could >>> > you provide some insights/pointers on how to do this? >>> >>> > _______________________________________________ >>> > keycloak-dev mailing list >>> > keycloak-dev at lists.jboss.org >>> >>> > https://lists.jboss.org/mailman/listinfo/keycloak-dev >>> >>> >>> >>> -- >>> >>> abstractj >>> PGP: 0x84DC9914 >>> >>> >>> >>> >>> >>> _______________________________________________ >>> 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160823/267c4907/attachment.html From mposolda at redhat.com Tue Aug 23 10:12:39 2016 From: mposolda at redhat.com (Marek Posolda) Date: Tue, 23 Aug 2016 16:12:39 +0200 Subject: [keycloak-dev] new credential SPI In-Reply-To: <44df3c3e-0d25-1ba0-182f-dd3ad04b8b5e@redhat.com> References: <57BBF9DE.7030703@redhat.com> <44df3c3e-0d25-1ba0-182f-dd3ad04b8b5e@redhat.com> Message-ID: <57BC59D7.2040503@redhat.com> Regarding SPNEGO, I remember we discussed it on ML few years ago and agreed on doing it at UserFederation level. However that was before we had Authentication SPI :-) So yes, maybe we can refactor now? What we can do is: - Add keytab, kerberos principal and "debug" as properties of SPNEGOAuthenticator. - If user is successfuly authenticated by SPNEGOAuthenticator, he will be lookup by UserFederationStorage. If found, then authentication finished with success (so the case when user is in LDAP is still supported). If he is not found, then he is lazily created (typically the usecase for SPNEGO/Kerberos not backed by LDAP) This shouldn't be too hard to do though. Regarding multiple handshakes, this is still valid requirement IMO? There are authentication mechanisms like SASL, which count with multiple handshakes. The Keycloak is currently around passwords and OTP, but people may want to add their own credential types or in the future we can add more mechanisms, which can require multiple handshakes? Marek On 23/08/16 14:47, Bill Burke wrote: > > I never understood why all this is done at the UserFederationSPI > level. Why isn't it done at the authenticator level? Its all > protocol stuff. Would you do the same for bearer tokens if we had > to? I don't think so. UserStorageSPI is supposed to be an > abstraction for storage, not a protocol abstraction. > > > On 8/23/16 3:23 AM, Marek Posolda wrote: >> Few additional things, which applies for credentials like >> SPNEGO/Kerberos tokens, however I think they might be required for >> other credential types too. >> >> - Authentication of unknown user : For example in case of SPNEGO, you >> have just the token, but you don't know which user are you >> authenticating. User is "recognized" later once the SPNEGO token is >> successfully validated >> >> - More handshakes for credential validation : This is again related >> to SPNEGO, but I am sure it applies for some other credential types >> too. Instead of true/false we may need something like : SUCCESS, >> FAILED, CONTINUE. >> Also the possibility to send some context info back to the client, so >> client can continue with the handshake. For the old >> federationProvider we had: >> >> CredentialValidationOutput validCredentials(RealmModel realm, UserCredentialModel credential); >> >> I guess we need something similar for the new SPI too? Also for >> "isValid" method, I would rather return CredentialValidationOutput >> instead of just true/false. True/false is good for passwords/OTP, >> which are most widely used credential types in Keycloak, but may not >> be sufficient for other custom credential types. >> >> Marek >> >> On 16/08/16 00:57, Bill Burke wrote: >>> I'm currently working on a new credential SPI that will replace >>> existing methods on UserProvider and UserModel, as well as replacing >>> UserCredentialModel, etc. This is a work in progress where we may >>> see multiple iterations in master. I hope to remain backward >>> compatible, but can't guarentee I won't break existing User >>> Federation Providers. Here's an initial writeup to explain things. >>> Credentials revolve around these 4 events that are initiated by >>> authentication flows, the admin console, and the account service. >>> >>> * Is the user configured for a specific credential type >>> >>> * Is a credential valid >>> >>> * What required actions must be taken for an unconfigured credential >>> type >>> >>> * update a credential >>> >>> How each of these events is resolved will depend on the >>> configuration of the system and these interfaces: >>> >>> public interface CredentialInput { >>> String getType(); >>> } >>> >>> public interface CredentialInputValidator { >>> boolean supportsCredentialType(String credentialType); >>> boolean isConfiguredFor(RealmModel realm, UserModel user, String credentialType); >>> boolean isValid(RealmModel realm, UserModel user, CredentialInput input); >>> >>> } >>> >>> public interface CredentialInputUpdater { >>> boolean supportsCredentialType(String credentialType); >>> Set requiredActionsFor(RealmModel realm, UserModel user, String credentialType); >>> void updateCredential(RealmModel realm, UserModel user, CredentialInput input); >>> } >>> >>> Two different types of components will be able to implement these >>> interfaces. UserStorageProviders (user federation) and >>> CredentialProviders. CredentialProviders are components configured >>> at the realm level. CredentialProviders are responsible for >>> managing one or more types of credential types and are the bridge >>> between CredentialInput and where the credential is stored. >>> UserStorageProvider is always asked first whether it can complete >>> the requested action, then CredentialProviders are queried in order >>> of their priority. >>> >>> Each UserStorageProvider and/or CredentialProvider can implement the >>> OnUserCache callback interface discussed in my previous custom >>> caching email. This allows each credential type to decide whether >>> it will be cached or not along with the user. For example, HOTP >>> cannot be cached. >>> >>> So, for example, there will be a KeycloakMobileOTPProvider. This >>> deals with Google Authenticator and FreeOTP as well as storing these >>> things within Keycloak storage, it also looks at the OTP policy of >>> the realm to determine how to update and store the OTP secret and >>> stuff. There is also a KeycloakPasswordProvider which hooks into >>> Keycloak storage and the PasswordPolicies set up by the realm. When >>> a user is cached, the KeycloakPasswordProvider will add the hashed >>> password to the user cache, the KeycloakMobileOTPProvider will add >>> the OTP secret to cache if its not HOTP and needs to maintain a >>> counter. >>> >>> Let's walk through an authentication flow, specificaly for OTP. >>> >>> 1. Authenticator calls >>> KeycloakSession.users().isConfiguredFor(realm, user, "OTP"). If the >>> user was loaded by a UserStorageProvider and that provider >>> implements the CredentialInputValidator interface, isConfiguredFor() >>> is called on that. If that returns false, each CredentialProvider >>> is iterated on to call isConfiguredFor(). >>> >>> 2. If OTP is required and not configured for the user, the >>> Authenticator then calls >>> KeycloakSession.users().requiredActionsFor(...). Again, >>> UserStorageProvider is queried first, then the CredneitalProviders. >>> The first provider that returns a non-empty set will end the query >>> and the set of required actions will be returned. >>> >>> 3a. Let's say that in this particular example, the generic OTP >>> Requried Action screen is invoked. In that case, this required >>> action provider callsKeycloakSession.users().updateCredential. The >>> first UserStorageProvider or CredentialProvider that can handle this >>> credential type will save the credential. >>> >>> 3b. If OTP is configured for user, the OTP is obtained by the >>> Authenticator and KeycloakSession.users().isValid() method is >>> called. Again, UserStorageProvider first, then each >>> CredentialProvider. Each provider is queried until one returns true >>> or the list is exhausted. FYI, This algorithm allows for multiple >>> OTP authenticators per user. >>> >>> ** Admin console and Account Service UIs ** >>> >>> Like we do for other components, the UserStorageProvider or >>> CredentialProvider can optionally provide a list of >>> ProviderConfigProperties for the admin console and/or account >>> serviceso that it can create a credential for a specific user. >>> There will be separate property lists for admin console and account >>> service. If a specific custom screen is desired, I'm pretty sure we >>> can just allow the develoepr to plug in their own $routeProvider for >>> the admin console. We don't have a pluggable mechanism for the >>> account service yet (or a way to generic render either). This will >>> need to be developed eventually. >>> >>> >>> >>> >>> _______________________________________________ >>> keycloak-dev mailing list >>> keycloak-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160823/a9e62f43/attachment-0001.html From mposolda at redhat.com Tue Aug 23 10:32:35 2016 From: mposolda at redhat.com (Marek Posolda) Date: Tue, 23 Aug 2016 16:32:35 +0200 Subject: [keycloak-dev] Import users from new User Federation In-Reply-To: References: <96ca98e1-f758-8e53-fac1-83f528079bc6@redhat.com> <1d491ec6-14d8-f1f8-3dbe-ad6b5c482f66@redhat.com> <57BBFDCB.4080705@redhat.com> Message-ID: <57BC5E83.30805@redhat.com> On 23/08/16 15:04, Bill Burke wrote: > > > > On 8/23/16 3:39 AM, Marek Posolda wrote: >> On 19/08/16 15:52, Bill Burke wrote: >>> >>> >>> >>> On 8/19/16 2:37 AM, Stian Thorgersen wrote: >>>> >>>> >>>> On 18 August 2016 at 20:30, Bill Burke >>> > wrote: >>>> >>>> >>>> On 8/18/16 4:59 AM, Stian Thorgersen wrote: >>>> > Bill, >>>> > >>>> > Are you planing to have an option to allow import of users >>>> with the >>>> > new user federation SPI? I'm not convinced we should >>>> completely remove >>>> > this option. >>>> > >>>> >>>> The only callback that does not exist in the new SPI is >>>> validateAndProxy(). With the current federation SPI, the developer >>>> implements everything themselves for import. There are no >>>> synchronization APIs/SPIs either. >>>> >>>> >>>> Sounds like we're removing built-in features around synchronization >>>> just to make the user have to do everything themselves. >>> I think you misinterpreted me, The old User Federation SPI forces >>> the developer to write all the import code themselves. The old User >>> Federation SPI does not have any synchronization callbacks, methods >>> or interfaces other than validateAndProxy(), the logic of which the >>> user has to write themselves too. >>> >>> >>>> > Some use-cases I could imagine: >>>> > >>>> > * Allow users to authenticate even if LDAP server is down >>>> Our current LDAP provider will not work if LDAP is down, even >>>> with the >>>> import :) >>>> >>>> >>>> Yes, I know. However, the fact that we don't currently support it >>>> doesn't mean we shouldn't in the future. >>> If the user can only be authenticated via LDAP, an offline mode is >>> not possible. In other words, if LDAP does not expose the password >>> of a user (so it can be imported), then offline mode is not >>> possible. It would only be possible if the user has logged in at >>> least once, then the validated password could be imported. >>> >>> So, do you still think we should support import/offline mode given >>> all this? >> From some recent discussions I saw, it seems that quite many people >> are interested in the "import-and-forget" mode. So they need to >> import user from their old legacy store (3rd party storage or LDAP) >> but once user is fully in Keycloak DB, they want to completely forget >> about the 3rd party storage and do all operations around this user >> against Keycloak DB. >> >> The credentials/password validation seems to be the most complicated >> part around this as you pointed, as the password needs to be first >> successfully validated against 3rdparty storage or LDAP . Then once >> password is successfully validated and updated to Keycloak DB, user >> can be "forgotten" and unlinked from the federationProvider. I hope >> the new SPI has a way to deal with this usecase? Or at least have a >> hook, so the people can easily unlink the user by themselves whenever >> they want. >> > As I said before, the current SPI does not have any support for > import. It also does not have any SPIs around synchronization or any > synchronization buttons in the admin console. It is up to the > developer to write the code to import the user. And our current LDAP > implmementation is not "import and forget", you already mentioned > password validation, but there is also validateAndProxy which is > called every time the user is accessed and which hits LDAP every > time. There's also no way to unlink the user. Not right now, but it seems that many people consider the "import-and-forget" as important usecase? You just want to import the users from 3rd party storage or LDAP, but you need to do in multiple steps and "wait" until password is successfully validated for the first time. As an example this blogpost from Scott Rossillo https://tech.smartling.com/migrate-to-keycloak-with-zero-downtime-8dcab9e7cb2c#.1e8sy1o8n, which AFAIK seemed to have some positive feedback from more community users. I don't know how deeply to go with directly supporting it at SPI level. However IMO it will be good to have at least same level like the current UserFederation SPI. So at least at some point (ie. after successful password validation), the people can manually unlink the 3rd party provider from the user and migrate all the data to Keycloak DB and then use it just from Keycloak DB. Marek > > So, #1, LDAP users are getting no real advantage to importing into our > database with tremendous overhead > #2, I do not think we have many people implementing their own custom > providers. Why? We've had few questions on something that is really > really hard to do (see the whole deployer discussion). > > I just think this whole import thing is a bad idea. > > Bill -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160823/3a142241/attachment.html From bburke at redhat.com Tue Aug 23 10:39:37 2016 From: bburke at redhat.com (Bill Burke) Date: Tue, 23 Aug 2016 10:39:37 -0400 Subject: [keycloak-dev] new credential SPI In-Reply-To: <57BC59D7.2040503@redhat.com> References: <57BBF9DE.7030703@redhat.com> <44df3c3e-0d25-1ba0-182f-dd3ad04b8b5e@redhat.com> <57BC59D7.2040503@redhat.com> Message-ID: <4f0720be-8bf4-b949-20ef-228a2ebaf449@redhat.com> On 8/23/16 10:12 AM, Marek Posolda wrote: > Regarding SPNEGO, I remember we discussed it on ML few years ago and > agreed on doing it at UserFederation level. However that was before we > had Authentication SPI :-) > > So yes, maybe we can refactor now? > > What we can do is: > - Add keytab, kerberos principal and "debug" as properties of > SPNEGOAuthenticator. > - If user is successfuly authenticated by SPNEGOAuthenticator, he will > be lookup by UserFederationStorage. If found, then authentication > finished with success (so the case when user is in LDAP is still > supported). If he is not found, then he is lazily created (typically > the usecase for SPNEGO/Kerberos not backed by LDAP) > > This shouldn't be too hard to do though. > > Regarding multiple handshakes, this is still valid requirement IMO? > There are authentication mechanisms like SASL, which count with > multiple handshakes. The Keycloak is currently around passwords and > OTP, but people may want to add their own credential types or in the > future we can add more mechanisms, which can require multiple handshakes? > Really depends what's involved with the handshake. Protocol stuff should not be in the storage SPI. We already do multiple handshakes with kerberos in the kerberos authenticator. SASL is a protocol and thus should be handled at the Authenticator level. Maybe we need a status object for isValid, I don't know. Bill From thomas.darimont at googlemail.com Tue Aug 23 11:37:48 2016 From: thomas.darimont at googlemail.com (Thomas Darimont) Date: Tue, 23 Aug 2016 17:37:48 +0200 Subject: [keycloak-dev] Import users from new User Federation In-Reply-To: <57BC5E83.30805@redhat.com> References: <96ca98e1-f758-8e53-fac1-83f528079bc6@redhat.com> <1d491ec6-14d8-f1f8-3dbe-ad6b5c482f66@redhat.com> <57BBFDCB.4080705@redhat.com> <57BC5E83.30805@redhat.com> Message-ID: We currently use a similar approach: There is a legacy user store which is used by multiple existing applications. We currently integrate the users from that legacy user store with a custom UserFederationProvider which is build in a similar way to what Scott Rossillo proposed in his blog post. Since there are currently more applications using the legacy user store than Keycloak it needs to remain the leading system which means that all user updates need to be performed in the legacy user store and Keycloak is mostly used in read-only fashion. Therefore we need to reload the user information in Keycloak on every login ... until Keycloak becomes the main user store for which we can then remove the federation link. So it's not quite just "import and forget" but rather "import-link-refresh-and-eventually-forget"... Cheers, Thomas 2016-08-23 16:32 GMT+02:00 Marek Posolda : > On 23/08/16 15:04, Bill Burke wrote: > > > > On 8/23/16 3:39 AM, Marek Posolda wrote: > > On 19/08/16 15:52, Bill Burke wrote: > > > > On 8/19/16 2:37 AM, Stian Thorgersen wrote: > > > > On 18 August 2016 at 20:30, Bill Burke < > bburke at redhat.com> wrote: > >> >> On 8/18/16 4:59 AM, Stian Thorgersen wrote: >> > Bill, >> > >> > Are you planing to have an option to allow import of users with the >> > new user federation SPI? I'm not convinced we should completely remove >> > this option. >> > >> >> The only callback that does not exist in the new SPI is >> validateAndProxy(). With the current federation SPI, the developer >> implements everything themselves for import. There are no >> synchronization APIs/SPIs either. >> > > Sounds like we're removing built-in features around synchronization just > to make the user have to do everything themselves. > > I think you misinterpreted me, The old User Federation SPI forces the > developer to write all the import code themselves. The old User Federation > SPI does not have any synchronization callbacks, methods or interfaces > other than validateAndProxy(), the logic of which the user has to write > themselves too. > > > > >> > Some use-cases I could imagine: >> > >> > * Allow users to authenticate even if LDAP server is down >> Our current LDAP provider will not work if LDAP is down, even with the >> import :) >> > > Yes, I know. However, the fact that we don't currently support it doesn't > mean we shouldn't in the future. > > If the user can only be authenticated via LDAP, an offline mode is not > possible. In other words, if LDAP does not expose the password of a user > (so it can be imported), then offline mode is not possible. It would only > be possible if the user has logged in at least once, then the validated > password could be imported. > > > So, do you still think we should support import/offline mode given all > this? > > From some recent discussions I saw, it seems that quite many people are > interested in the "import-and-forget" mode. So they need to import user > from their old legacy store (3rd party storage or LDAP) but once user is > fully in Keycloak DB, they want to completely forget about the 3rd party > storage and do all operations around this user against Keycloak DB. > > The credentials/password validation seems to be the most complicated part > around this as you pointed, as the password needs to be first successfully > validated against 3rdparty storage or LDAP . Then once password is > successfully validated and updated to Keycloak DB, user can be "forgotten" > and unlinked from the federationProvider. I hope the new SPI has a way to > deal with this usecase? Or at least have a hook, so the people can easily > unlink the user by themselves whenever they want. > > As I said before, the current SPI does not have any support for import. > It also does not have any SPIs around synchronization or any > synchronization buttons in the admin console. It is up to the developer to > write the code to import the user. And our current LDAP implmementation is > not "import and forget", you already mentioned password validation, but > there is also validateAndProxy which is called every time the user is > accessed and which hits LDAP every time. There's also no way to unlink the > user. > > Not right now, but it seems that many people consider the > "import-and-forget" as important usecase? You just want to import the users > from 3rd party storage or LDAP, but you need to do in multiple steps and > "wait" until password is successfully validated for the first time. > > As an example this blogpost from Scott Rossillo > https://tech.smartling.com/migrate-to-keycloak-with-zero- > downtime-8dcab9e7cb2c#.1e8sy1o8n, which AFAIK seemed to have some > positive feedback from more community users. > > I don't know how deeply to go with directly supporting it at SPI level. > However IMO it will be good to have at least same level like the current > UserFederation SPI. So at least at some point (ie. after successful > password validation), the people can manually unlink the 3rd party provider > from the user and migrate all the data to Keycloak DB and then use it just > from Keycloak DB. > > Marek > > > So, #1, LDAP users are getting no real advantage to importing into our > database with tremendous overhead > #2, I do not think we have many people implementing their own custom > providers. Why? We've had few questions on something that is really > really hard to do (see the whole deployer discussion). > > I just think this whole import thing is a bad idea. > > Bill > > > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160823/2ac0945d/attachment-0001.html From bburke at redhat.com Tue Aug 23 11:58:05 2016 From: bburke at redhat.com (Bill Burke) Date: Tue, 23 Aug 2016 11:58:05 -0400 Subject: [keycloak-dev] Import users from new User Federation In-Reply-To: <57BC5E83.30805@redhat.com> References: <96ca98e1-f758-8e53-fac1-83f528079bc6@redhat.com> <1d491ec6-14d8-f1f8-3dbe-ad6b5c482f66@redhat.com> <57BBFDCB.4080705@redhat.com> <57BC5E83.30805@redhat.com> Message-ID: <09947585-3304-f744-09f8-b9e613640004@redhat.com> On 8/23/16 10:32 AM, Marek Posolda wrote: > On 23/08/16 15:04, Bill Burke wrote: >> >> >> >> On 8/23/16 3:39 AM, Marek Posolda wrote: >>> On 19/08/16 15:52, Bill Burke wrote: >>>> >>>> >>>> >>>> On 8/19/16 2:37 AM, Stian Thorgersen wrote: >>>>> >>>>> >>>>> On 18 August 2016 at 20:30, Bill Burke wrote: >>>>> >>>>> >>>>> On 8/18/16 4:59 AM, Stian Thorgersen wrote: >>>>> > Bill, >>>>> > >>>>> > Are you planing to have an option to allow import of users >>>>> with the >>>>> > new user federation SPI? I'm not convinced we should >>>>> completely remove >>>>> > this option. >>>>> > >>>>> >>>>> The only callback that does not exist in the new SPI is >>>>> validateAndProxy(). With the current federation SPI, the >>>>> developer >>>>> implements everything themselves for import. There are no >>>>> synchronization APIs/SPIs either. >>>>> >>>>> >>>>> Sounds like we're removing built-in features around >>>>> synchronization just to make the user have to do everything >>>>> themselves. >>>> I think you misinterpreted me, The old User Federation SPI forces >>>> the developer to write all the import code themselves. The old >>>> User Federation SPI does not have any synchronization callbacks, >>>> methods or interfaces other than validateAndProxy(), the logic of >>>> which the user has to write themselves too. >>>> >>>> >>>>> > Some use-cases I could imagine: >>>>> > >>>>> > * Allow users to authenticate even if LDAP server is down >>>>> Our current LDAP provider will not work if LDAP is down, even >>>>> with the >>>>> import :) >>>>> >>>>> >>>>> Yes, I know. However, the fact that we don't currently support it >>>>> doesn't mean we shouldn't in the future. >>>> If the user can only be authenticated via LDAP, an offline mode is >>>> not possible. In other words, if LDAP does not expose the password >>>> of a user (so it can be imported), then offline mode is not >>>> possible. It would only be possible if the user has logged in at >>>> least once, then the validated password could be imported. >>>> >>>> So, do you still think we should support import/offline mode given >>>> all this? >>> From some recent discussions I saw, it seems that quite many people >>> are interested in the "import-and-forget" mode. So they need to >>> import user from their old legacy store (3rd party storage or LDAP) >>> but once user is fully in Keycloak DB, they want to completely >>> forget about the 3rd party storage and do all operations around this >>> user against Keycloak DB. >>> >>> The credentials/password validation seems to be the most complicated >>> part around this as you pointed, as the password needs to be first >>> successfully validated against 3rdparty storage or LDAP . Then once >>> password is successfully validated and updated to Keycloak DB, user >>> can be "forgotten" and unlinked from the federationProvider. I hope >>> the new SPI has a way to deal with this usecase? Or at least have a >>> hook, so the people can easily unlink the user by themselves >>> whenever they want. >>> >> As I said before, the current SPI does not have any support for >> import. It also does not have any SPIs around synchronization or any >> synchronization buttons in the admin console. It is up to the >> developer to write the code to import the user. And our current LDAP >> implmementation is not "import and forget", you already mentioned >> password validation, but there is also validateAndProxy which is >> called every time the user is accessed and which hits LDAP every >> time. There's also no way to unlink the user. > Not right now, but it seems that many people consider the > "import-and-forget" as important usecase? You just want to import the > users from 3rd party storage or LDAP, but you need to do in multiple > steps and "wait" until password is successfully validated for the > first time. > > As an example this blogpost from Scott Rossillo > https://tech.smartling.com/migrate-to-keycloak-with-zero-downtime-8dcab9e7cb2c#.1e8sy1o8n, > which AFAIK seemed to have some positive feedback from more community > users. > > I don't know how deeply to go with directly supporting it at SPI > level. However IMO it will be good to have at least same level like > the current UserFederation SPI. So at least at some point (ie. after > successful password validation), the people can manually unlink the > 3rd party provider from the user and migrate all the data to Keycloak > DB and then use it just from Keycloak DB. > Ok, good feedback. You are convincing me. Are we absolutely sure this is actually a best practice and not an anti-pattern? Seems scary to be half in and half out. I guess it does make sense if you need to keep something like LDAP up for legacy apps. Just thinking around this we should have an additional interface for imports: interface UserStorageSynchornization { void validate(UserModel). void synchronize() void unlink() } validate is called whenever a user is looked up. Possibly used to find deleted users and to synchronize updates on both sides on demand. I want to add cache policies per provider, so maybe validate is called only when pulled from persistence storage and not cache. I don't think we need different synchronize methods. We should instead store last sync timestamp and last updated timestamp for each user and add queries to local storage to find users for a specific provider that were synced and/or updated after a certain time. Then the synchronize implementation can make the assessment on what to synchronize or not. I'd also like to be able to fire off synchronization in the background and to obtain a status on it from the admin console. If it fails, how many users synchronized, and error message, etc. unlink() would just be a callback whenever the admin console fires of an unlink all users event. Bill -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160823/5ada6fd9/attachment.html From thomas.darimont at googlemail.com Tue Aug 23 12:14:52 2016 From: thomas.darimont at googlemail.com (Thomas Darimont) Date: Tue, 23 Aug 2016 18:14:52 +0200 Subject: [keycloak-dev] Import users from new User Federation In-Reply-To: <09947585-3304-f744-09f8-b9e613640004@redhat.com> References: <96ca98e1-f758-8e53-fac1-83f528079bc6@redhat.com> <1d491ec6-14d8-f1f8-3dbe-ad6b5c482f66@redhat.com> <57BBFDCB.4080705@redhat.com> <57BC5E83.30805@redhat.com> <09947585-3304-f744-09f8-b9e613640004@redhat.com> Message-ID: Sounds great - need to think about it though... btw. (PoC) support for updatedTimestamp is here (exactly because of the use case mentioned above...) https://github.com/keycloak/keycloak/pull/3057 Cheers, Thomas 2016-08-23 17:58 GMT+02:00 Bill Burke : > > > On 8/23/16 10:32 AM, Marek Posolda wrote: > > On 23/08/16 15:04, Bill Burke wrote: > > > > On 8/23/16 3:39 AM, Marek Posolda wrote: > > On 19/08/16 15:52, Bill Burke wrote: > > > > On 8/19/16 2:37 AM, Stian Thorgersen wrote: > > > > On 18 August 2016 at 20:30, Bill Burke wrote: > >> >> On 8/18/16 4:59 AM, Stian Thorgersen wrote: >> > Bill, >> > >> > Are you planing to have an option to allow import of users with the >> > new user federation SPI? I'm not convinced we should completely remove >> > this option. >> > >> >> The only callback that does not exist in the new SPI is >> validateAndProxy(). With the current federation SPI, the developer >> implements everything themselves for import. There are no >> synchronization APIs/SPIs either. >> > > Sounds like we're removing built-in features around synchronization just > to make the user have to do everything themselves. > > I think you misinterpreted me, The old User Federation SPI forces the > developer to write all the import code themselves. The old User Federation > SPI does not have any synchronization callbacks, methods or interfaces > other than validateAndProxy(), the logic of which the user has to write > themselves too. > > > > >> > Some use-cases I could imagine: >> > >> > * Allow users to authenticate even if LDAP server is down >> Our current LDAP provider will not work if LDAP is down, even with the >> import :) >> > > Yes, I know. However, the fact that we don't currently support it doesn't > mean we shouldn't in the future. > > If the user can only be authenticated via LDAP, an offline mode is not > possible. In other words, if LDAP does not expose the password of a user > (so it can be imported), then offline mode is not possible. It would only > be possible if the user has logged in at least once, then the validated > password could be imported. > > > So, do you still think we should support import/offline mode given all > this? > > From some recent discussions I saw, it seems that quite many people are > interested in the "import-and-forget" mode. So they need to import user > from their old legacy store (3rd party storage or LDAP) but once user is > fully in Keycloak DB, they want to completely forget about the 3rd party > storage and do all operations around this user against Keycloak DB. > > The credentials/password validation seems to be the most complicated part > around this as you pointed, as the password needs to be first successfully > validated against 3rdparty storage or LDAP . Then once password is > successfully validated and updated to Keycloak DB, user can be "forgotten" > and unlinked from the federationProvider. I hope the new SPI has a way to > deal with this usecase? Or at least have a hook, so the people can easily > unlink the user by themselves whenever they want. > > As I said before, the current SPI does not have any support for import. > It also does not have any SPIs around synchronization or any > synchronization buttons in the admin console. It is up to the developer to > write the code to import the user. And our current LDAP implmementation is > not "import and forget", you already mentioned password validation, but > there is also validateAndProxy which is called every time the user is > accessed and which hits LDAP every time. There's also no way to unlink the > user. > > Not right now, but it seems that many people consider the > "import-and-forget" as important usecase? You just want to import the users > from 3rd party storage or LDAP, but you need to do in multiple steps and > "wait" until password is successfully validated for the first time. > > As an example this blogpost from Scott Rossillo > https://tech.smartling.com/migrate-to-keycloak-with-zero- > downtime-8dcab9e7cb2c#.1e8sy1o8n, which AFAIK seemed to have some > positive feedback from more community users. > > I don't know how deeply to go with directly supporting it at SPI level. > However IMO it will be good to have at least same level like the current > UserFederation SPI. So at least at some point (ie. after successful > password validation), the people can manually unlink the 3rd party provider > from the user and migrate all the data to Keycloak DB and then use it just > from Keycloak DB. > > Ok, good feedback. You are convincing me. Are we absolutely sure this is > actually a best practice and not an anti-pattern? Seems scary to be half > in and half out. I guess it does make sense if you need to keep something > like LDAP up for legacy apps. > > > Just thinking around this we should have an additional interface for > imports: > > interface UserStorageSynchornization { > > void validate(UserModel). > void synchronize() > void unlink() > > > } > > > > validate is called whenever a user is looked up. Possibly used to find > deleted users and to synchronize updates on both sides on demand. I want > to add cache policies per provider, so maybe validate is called only when > pulled from persistence storage and not cache. > > I don't think we need different synchronize methods. We should instead > store last sync timestamp and last updated timestamp for each user and add > queries to local storage to find users for a specific provider that were > synced and/or updated after a certain time. Then the synchronize > implementation can make the assessment on what to synchronize or not. I'd > also like to be able to fire off synchronization in the background and to > obtain a status on it from the admin console. If it fails, how many users > synchronized, and error message, etc. > > unlink() would just be a callback whenever the admin console fires of an > unlink all users event. > > Bill > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160823/49457e60/attachment-0001.html From singhrasster at gmail.com Tue Aug 23 18:04:34 2016 From: singhrasster at gmail.com (Rashmi Singh) Date: Tue, 23 Aug 2016 17:04:34 -0500 Subject: [keycloak-dev] Issue with single sign out using salesforce SP with keycloak IDP and also customizing the logout page In-Reply-To: References: Message-ID: Looking more closely into this, it seems like Salesforce does not support SAML logout. In Salesforce, where I did the configuration for "SAML Single Sign-On Settings", there is the following field: Identity Provider Logout URL: I had specified this as: http://rashmiidp.cloud.com:9990/auth/realms/saml-demo/protocol/saml But, since Salesforce does not seem to support SAML logout, is it possible to specify some keycloak URL in this field that would logout the user? It seems like the URL I specify in this field gets invoked but then Salesforce is not really sending a SAML logout request and I just get an error as indicated earlier. So, I was thinking if there is some keycloak URL that we can specify in this field that would logout the user? If there is no such URL support, is there an alternative to solve this issue since Salesforce does not seem to handle the single logout? On Tue, Aug 23, 2016 at 8:05 AM, Rashmi Singh wrote: > On keycloak logs, I only see this error: > > 2016-08-23 00:49:24,648 WARN [org.keycloak.events] (default task-6) > type=LOGIN_ERROR, realmId=saml-demo, clientId=null, userId=null, > ipAddress=192.168.99.1, error=invalid_token > > This is a generic error and does not give any clue. > > I used SAML tracer with firefox and there I see the following request in > RED: > > GET http://rashmiidp.cloud.com:9990/auth/realms/saml-demo/protocol/saml > Here are the contents for this request from SAML tracer (but its not > giving me any clue on what is wrong): > > GET http://rashmiidp.cloud.com:9990/auth/realms/saml-demo/protocol/saml > HTTP/1.1 > Host: rashmiidp.cloud.com:9990 > User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:47.0) Gecko/20100101 > Firefox/47.0 > Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 > Accept-Language: fr,en;q=0.8,nl-BE;q=0.7,es;q=0.5,es-ES;q=0.3,en-US;q=0.2 > Accept-Encoding: gzip, deflate > Cookie: KEYCLOAK_SESSION=saml-demo/6d25a0c6-7bb8-4cfc-b918-e3384f9df > e72/1e3911dc-3237-4aee-ba56-07de530e00f7; KC_RESTART=eyJhbGciOiJIUzI1NiJ > 9.eyJjcyI6ImI1M2QxOGJiLWQ3ODItNDZhNS04YjY5LWQxM2IxMDVhMTc4NS > IsImNpZCI6Imh0dHBzOi8vc2FtbC5zYWxlc2ZvcmNlLmNvbSIsInB0eSI6In > NhbWwiLCJydXJpIjoiaHR0cHM6Ly9yYXNobWk3ODktZGV2LWVkLm15LnNhbG > VzZm9yY2UuY29tP3NvPTAwRDQxMDAwMDAwNUwxNCIsImFjdCI6IkFVVEhFTl > RJQ0FURSIsIm5vdGVzIjp7ImFjdGlvbl9rZXkiOiJmNDBmYTJmYi01YTM0LT > RmZDQtYTc2NC0xZDI5NWVlZDFmODIiLCJSZWxheVN0YXRlIjoiLyIsIlNBTU > xfUkVRVUVTVF9JRCI6Il8yQ0FBQUFWZEZCal9tTUU4d05ERXdNREF3TURBMF > F6azJBQUFBeWszaE1mODBfdTJ5cGVpSXpjVWNkQUtJWUFkeF9vNmN2Y0ZoMT > E4QkcxWnFVRVQtREZJY29Wb1BqLUNheWZFV2FHLXRCLUo3YXhHUEhGaWdWbm > V3MEREQUVlTTdJR21KcURuMmpUOUlPODVfT2pYTlVNQzlrbmV0cmRDcmpweD > ZCWTJjcWVCVWV0cldsb0JVaWhpMHBKMW0tb2dBSmM1T1NDTXhIUkxpclNNR2 > FYRVhEeFpLVldadENfQTUwTFl6S1o2bmo3XzZ1ekhIak9qa01kYnpoY2RTZl > VZS0Q2bVRhNmtCRjlweTRwQTB4bHg1eGRpN1M5OWc1d0xnSklmeVJ3Iiwic2 > FtbF9iaW5kaW5nIjoicG9zdCJ9fQ.E4kYw1y2Z3sOdXaa8eqNQ9Ca7r6t-7PFtY7JKNOLd-U; > KEYCLOAK_IDENTITY=eyJhbGciOiJSUzI1NiJ9.eyJqdGkiOiJmNTQyYjY0Y > y1iYTNhLTRiY2ItYmE2OC0xZGEyZTY0ZGRjMTQiLCJleHAiOjE0NzE5NDg2N > jAsIm5iZiI6MCwiaWF0IjoxNDcxOTEyNjYwLCJpc3MiOiJodHRwOi8vcmFza > G1paWRwLmNsb3VkLmNvbTo5OTkwL2F1dGgvcmVhbG1zL3NhbWwtZGVtbyIsI > nN1YiI6IjZkMjVhMGM2LTdiYjgtNGNmYy1iOTE4LWUzMzg0ZjlkZmU3MiIsI > nNlc3Npb25fc3RhdGUiOiIxZTM5MTFkYy0zMjM3LTRhZWUtYmE1Ni0wN2RlN > TMwZTAwZjciLCJyZXNvdXJjZV9hY2Nlc3MiOnt9fQ.IfnQezJi5hCMHac2K3 > B9QnjWdx4SR7F1TGV2JlbPxF0lOAqLzK5XaQgOO8p8z9XY-u0hN4DLFePXjz > LOl0UwYaZ0ySxm-l-gUsCkveVzTPRMS98ekuTMlc-1fPI4h1tCRrVawW5zOg > H7zc-a03KK0WZJ6b3iuU49PGsDXmeiNb6aqG-BIrmSkfsjfXr4zB69PcY0EF > 3sse0jlOkZXYBcmbH46b_fWm-p4hpyt6QnGvxanKOc2jtavkUPSo5UrQxmQ3 > -ahfxqZOFAvRbeHys5RdUUHs5BBefjkE4p8teCeG0nNzpgJfgPHgMNsnjELrTSafTcq1AM-yV2UOWrYeh0sA; > testusergrid={} > > HTTP/?.? 500 Internal Server Error > Cache-Control: no-store, must-revalidate, max-age=0 > X-Powered-By: Undertow/1 > Server: WildFly/10 > X-Frame-Options: SAMEORIGIN > content-security-policy: frame-src 'self' > Date: Tue, 23 Aug 2016 00:37:56 GMT > Connection: keep-alive > X-Content-Type-Options: nosniff > Content-Type: text/html;charset=utf-8 > Content-Length: 2906 > > Does this give you any idea? Do you have any more suggestions? > > On Mon, Aug 22, 2016 at 7:54 PM, Rashmi Singh > wrote: > >> John, On keycloak logs, I only see this error: >> >> 2016-08-23 00:49:24,648 WARN [org.keycloak.events] (default task-6) >> type=LOGIN_ERROR, realmId=saml-demo, clientId=null, userId=null, >> ipAddress=192.168.99.1, error=invalid_token >> >> This is a generic error and does not give any clue. >> >> I used SAML tracer with firefox and there I see the following request in >> RED: >> >> GET http://rashmiidp.cloud.com:9990/auth/realms/saml-demo/protocol/saml >> Here are the contents for this request from SAML tracer (but its not >> giving me any clue on what is wrong): >> >> GET http://rashmiidp.cloud.com:9990/auth/realms/saml-demo/protocol/saml >> HTTP/1.1 >> Host: rashmiidp.cloud.com:9990 >> User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:47.0) Gecko/20100101 >> Firefox/47.0 >> Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 >> Accept-Language: fr,en;q=0.8,nl-BE;q=0.7,es;q=0.5,es-ES;q=0.3,en-US;q=0.2 >> Accept-Encoding: gzip, deflate >> Cookie: KEYCLOAK_SESSION=saml-demo/6d25a0c6-7bb8-4cfc-b918-e3384f9df >> e72/1e3911dc-3237-4aee-ba56-07de530e00f7; KC_RESTART=eyJhbGciOiJIUzI1NiJ >> 9.eyJjcyI6ImI1M2QxOGJiLWQ3ODItNDZhNS04YjY5LWQxM2IxMDVhMTc4NS >> IsImNpZCI6Imh0dHBzOi8vc2FtbC5zYWxlc2ZvcmNlLmNvbSIsInB0eSI6In >> NhbWwiLCJydXJpIjoiaHR0cHM6Ly9yYXNobWk3ODktZGV2LWVkLm15LnNhbG >> VzZm9yY2UuY29tP3NvPTAwRDQxMDAwMDAwNUwxNCIsImFjdCI6IkFVVEhFTl >> RJQ0FURSIsIm5vdGVzIjp7ImFjdGlvbl9rZXkiOiJmNDBmYTJmYi01YTM0LT >> RmZDQtYTc2NC0xZDI5NWVlZDFmODIiLCJSZWxheVN0YXRlIjoiLyIsIlNBTU >> xfUkVRVUVTVF9JRCI6Il8yQ0FBQUFWZEZCal9tTUU4d05ERXdNREF3TURBMF >> F6azJBQUFBeWszaE1mODBfdTJ5cGVpSXpjVWNkQUtJWUFkeF9vNmN2Y0ZoMT >> E4QkcxWnFVRVQtREZJY29Wb1BqLUNheWZFV2FHLXRCLUo3YXhHUEhGaWdWbm >> V3MEREQUVlTTdJR21KcURuMmpUOUlPODVfT2pYTlVNQzlrbmV0cmRDcmpweD >> ZCWTJjcWVCVWV0cldsb0JVaWhpMHBKMW0tb2dBSmM1T1NDTXhIUkxpclNNR2 >> FYRVhEeFpLVldadENfQTUwTFl6S1o2bmo3XzZ1ekhIak9qa01kYnpoY2RTZl >> VZS0Q2bVRhNmtCRjlweTRwQTB4bHg1eGRpN1M5OWc1d0xnSklmeVJ3Iiwic2 >> FtbF9iaW5kaW5nIjoicG9zdCJ9fQ.E4kYw1y2Z3sOdXaa8eqNQ9Ca7r6t-7PFtY7JKNOLd-U; >> KEYCLOAK_IDENTITY=eyJhbGciOiJSUzI1NiJ9.eyJqdGkiOiJmNTQyYjY0Y >> y1iYTNhLTRiY2ItYmE2OC0xZGEyZTY0ZGRjMTQiLCJleHAiOjE0NzE5NDg2N >> jAsIm5iZiI6MCwiaWF0IjoxNDcxOTEyNjYwLCJpc3MiOiJodHRwOi8vcmFza >> G1paWRwLmNsb3VkLmNvbTo5OTkwL2F1dGgvcmVhbG1zL3NhbWwtZGVtbyIsI >> nN1YiI6IjZkMjVhMGM2LTdiYjgtNGNmYy1iOTE4LWUzMzg0ZjlkZmU3MiIsI >> nNlc3Npb25fc3RhdGUiOiIxZTM5MTFkYy0zMjM3LTRhZWUtYmE1Ni0wN2RlN >> TMwZTAwZjciLCJyZXNvdXJjZV9hY2Nlc3MiOnt9fQ.IfnQezJi5hCMHac2K3 >> B9QnjWdx4SR7F1TGV2JlbPxF0lOAqLzK5XaQgOO8p8z9XY-u0hN4DLFePXjz >> LOl0UwYaZ0ySxm-l-gUsCkveVzTPRMS98ekuTMlc-1fPI4h1tCRrVawW5zOg >> H7zc-a03KK0WZJ6b3iuU49PGsDXmeiNb6aqG-BIrmSkfsjfXr4zB69PcY0EF >> 3sse0jlOkZXYBcmbH46b_fWm-p4hpyt6QnGvxanKOc2jtavkUPSo5UrQxmQ3 >> -ahfxqZOFAvRbeHys5RdUUHs5BBefjkE4p8teCeG0nNzpgJfgPHgMNsnjELrTSafTcq1AM-yV2UOWrYeh0sA; >> testusergrid={} >> >> HTTP/?.? 500 Internal Server Error >> Cache-Control: no-store, must-revalidate, max-age=0 >> X-Powered-By: Undertow/1 >> Server: WildFly/10 >> X-Frame-Options: SAMEORIGIN >> content-security-policy: frame-src 'self' >> Date: Tue, 23 Aug 2016 00:37:56 GMT >> Connection: keep-alive >> X-Content-Type-Options: nosniff >> Content-Type: text/html;charset=utf-8 >> Content-Length: 2906 >> >> >> Does this give you any idea? Do you have any more suggestions? >> >> >> On Fri, Aug 19, 2016 at 7:52 AM, John Dennis wrote: >> >>> On 08/18/2016 10:06 PM, Rashmi Singh wrote: >>> >>>> Hi, >>>> >>>> I have setup a Salesforce Saml SP in keycloak. So, I basically created a >>>> new client from keycloak admin console for salesforce. This is how my SP >>>> url looks like: >>>> >>>> rashmi789-dev-ed.my.salesforce.com >>>> >>>> >>>> I edited the salesforce configuration settings to point it to the >>>> keycloak IDP. So, when I access the SP: >>>> http://rashmi789-dev-ed.my.salesforce.com >>>> >>>> I am successfully taken to the keycloak IDP page (where I have >>>> configured my Authenticator). I enter my credentials there and am able >>>> to login. But, now when I try to logout, I get the following error on >>>> the web page: >>>> >>>> We're sorry ... >>>> Invalid Request >>>> >>> >>> Is logout supported on both ends (i.e. SP and IdP)? The definition of >>> support is in the metadata of each entity. Is there a SingleLogoutService >>> binding with a valid location URL in each metadata? The vast majority of >>> SAML problems are directly attributable to the metadata because that is >>> what drives the conversation between the SP and IdP. You have access to >>> both metadata because it was necessary to load the metadata in each party. >>> >>> If the problem is not the absence of SingleLogoutService then I would >>> try tracing the flow. That is easy with the Firefox browser and the >>> SAMLTracer add-on. That will let you see the exchange of messages and >>> identify who the offending party is. >>> >>> So, single sign out does not seem to be working for me. What is the >>>> issue? Is it a problem with the IDP logout url that I have configured? >>>> What I have is: >>>> >>>> http://rashmiidp.cloud.com:9990/auth/realms/saml-demo/protocol/saml >>>> >>>> >>>> my IDP Login URL is: >>>> http://rashmiidp.cloud.com:9990/auth/realms/saml-demo/protocol/saml >>>> >>>> and that seem to be perfectly fine as I am able to login without any >>>> issue. what is the issue with the logout I am seeing above when using a >>>> Salesforce SP with keycloak? Please let me know if you need me to >>>> provide more details. >>>> >>> >>> This suggests the problem is not with the IdP. Keycloak uses the same >>> URL for all services (don't assume this is always the case, it's just one >>> implementation choice). If login to the same URL works a valid >>> LogoutRequest to the same URL should also work, provided of course it a >>> valid SAML Request. Are there any errors in the Keycloak log concerning >>> invalid requests. >>> >>> Once again. using SAMLTracer will help nail down who is generating the >>> error and what the content of the message was that induced it. >>> >>> >>> Also, once this issue is resolved and I am able to logout successfully, >>>> could you give some insights on how to customize the logout page? >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> keycloak-dev mailing list >>>> keycloak-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>>> >>>> >>> >>> -- >>> John >>> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160823/40e5dad1/attachment.html From thomas.darimont at googlemail.com Wed Aug 24 03:57:00 2016 From: thomas.darimont at googlemail.com (Thomas Darimont) Date: Wed, 24 Aug 2016 09:57:00 +0200 Subject: [keycloak-dev] Interesting example for trusted service to service communication with JWT Message-ID: Hello, just stumbled upon an (IMHO) interesting example for trusted service to service communication with JWT. Microservices with Spring Boot and Java JSON Web Tokens (JJWT) https://www.youtube.com/watch?v=saiwZzE5IYg They use the JJWT (https://github.com/jwtk/jjwt) library and and demonstrate how to use the kid (Key ID) claim of JWT. In order to establish trust between two services, public keys are exchanged to verify each others JWT token signatures. So instead of using a shared public key (e.g. Realm public key in Keycloak) they have a public key per service. I wonder how this would look like with Keycloak. Cheers, Thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160824/123536fe/attachment-0001.html From mposolda at redhat.com Wed Aug 24 04:56:54 2016 From: mposolda at redhat.com (Marek Posolda) Date: Wed, 24 Aug 2016 10:56:54 +0200 Subject: [keycloak-dev] new credential SPI In-Reply-To: <4f0720be-8bf4-b949-20ef-228a2ebaf449@redhat.com> References: <57BBF9DE.7030703@redhat.com> <44df3c3e-0d25-1ba0-182f-dd3ad04b8b5e@redhat.com> <57BC59D7.2040503@redhat.com> <4f0720be-8bf4-b949-20ef-228a2ebaf449@redhat.com> Message-ID: <57BD6156.7080800@redhat.com> On 23/08/16 16:39, Bill Burke wrote: > > > On 8/23/16 10:12 AM, Marek Posolda wrote: >> Regarding SPNEGO, I remember we discussed it on ML few years ago and >> agreed on doing it at UserFederation level. However that was before >> we had Authentication SPI :-) >> >> So yes, maybe we can refactor now? >> >> What we can do is: >> - Add keytab, kerberos principal and "debug" as properties of >> SPNEGOAuthenticator. >> - If user is successfuly authenticated by SPNEGOAuthenticator, he >> will be lookup by UserFederationStorage. If found, then >> authentication finished with success (so the case when user is in >> LDAP is still supported). If he is not found, then he is lazily >> created (typically the usecase for SPNEGO/Kerberos not backed by LDAP) >> >> This shouldn't be too hard to do though. >> >> Regarding multiple handshakes, this is still valid requirement IMO? >> There are authentication mechanisms like SASL, which count with >> multiple handshakes. The Keycloak is currently around passwords and >> OTP, but people may want to add their own credential types or in the >> future we can add more mechanisms, which can require multiple >> handshakes? >> > Really depends what's involved with the handshake. Protocol stuff > should not be in the storage SPI. We already do multiple handshakes > with kerberos in the kerberos authenticator. SASL is a protocol and > thus should be handled at the Authenticator level. Maybe we need a > status object for isValid, I don't know. I don't know too... Not sure where exactly is the border between protocol and credential storage and ATM I don't have any more concrete usecase using multisteps credential handshakes (assuming we refactor SPNEGO, I've created JIRA for that https://issues.jboss.org/browse/KEYCLOAK-3466 ) Maybe it's fine to use "boolean" and then later replace if there is request for multisteps credential handshakes? Also depends if we are allowed to do later changes in SPI or not... Marek > > Bill From martin.hardselius at gmail.com Wed Aug 24 05:08:02 2016 From: martin.hardselius at gmail.com (Martin Hardselius) Date: Wed, 24 Aug 2016 09:08:02 +0000 Subject: [keycloak-dev] Pairwise Subject Identifier In-Reply-To: <57BC51CE.9020504@redhat.com> References: <57AC9686.5040807@redhat.com> <57BB6324.2030403@redhat.com> <57BC51CE.9020504@redhat.com> Message-ID: Sounds good. I'll look into it and see what I can do. Possibly during next week. :) On Tue, 23 Aug 2016 at 15:38 Marek Posolda wrote: > We discussed it with Stian a bit and we discussed to: > > - Implement as protocolMapper > > - There will be possibility to configure "salt" as parameter to > protocolMapper. It may not be mandatory parameter. If it's used, then > client will use it as salt, otherwise salt will be generated. This allows > the use-case you mentioned. You can use same salt for clients x,y,z but > different salt for clients m,n. If you let generate salt, then the subject > identifiers will be really unique just to the particular client. > > - We need to validate sector_identifier_uri during create/update of > protocolMapper, but also during update of client. Otherwise someone can > register sector_identifier_uri and register the client with valid > redirect_uris (for example URLs "http://good-host/url1" > "http://good-host/url2" , > which are both specified under sector_identifier_uri ) but then later > update just the client redirect_uris to "http://evil-host/url1" > . Basically he will be able to update > redirect_uris to anything he wants regardless of redirect_uris under > sector_identifier_uri, so the whole validation will be bypassed. > > For updating client, I've just sent PR, which adds > RealmModel.ClientUpdatedEvent . You can register to that event similarly > like > https://github.com/keycloak/keycloak/blob/master/server-spi/src/main/java/org/keycloak/protocol/AbstractLoginProtocolFactory.java#L39 > . The creation/update listener for protocolMapper doesn't yet exists, > however we are likely going to refactor protocolMapper to generic > component, which will have validation support. But that will be likely > available in few weeks, so for now, we can add something temporary for > protocolMappers similar to what is available for example for > UserFederationMapperFactory (See > https://github.com/keycloak/keycloak/blob/master/services/src/main/java/org/keycloak/services/resources/admin/UserFederationProviderResource.java#L437-L440 > ) > > Martin, will you have some time to eventually look into this and send PR ? > > > Marek > > > On 23/08/16 14:25, Martin Hardselius wrote: > > Let's say we want to force all of our client to use pairwise subs, but a > single "merchant" needs to implement several clients where subs should > remain the same for all those clients. > > Merchant A > - client x > - client y > - client z > > Merchant B > - client m > - client n > > You can assume the sector_identifiers are the same across all clients > owned by a merchant > > It should not be possible to correlate activities between Customer A and > Customer B (at least not from their side). They should, however, be able to > correlate user activities between their own clients. > > Which implementation of pairwise subs is better suited for supporting this > scenario? I'm leaning towards the protocol mapper solution. It should be > easier to create custom mappers with merchant-wide configuration (e.g > salts). > > On Mon, 22 Aug 2016 at 22:40 Marek Posolda wrote: > >> The question is, should we really introduce another SPI for that? Doesn't >> it mean uneccessary complexity? Also add the new options directly to the >> client for the feature, which is likely interesting just for quite limited >> amount of people? >> >> IMO it's fine if this is implemented as protocolMapper? >> >> Few thoughts: >> - We can have abstract superclass like AbstractPairwiseSubGeneratorMapper >> . The subclasses will just need to implement method "generateSub" . We can >> have just one concrete impl, which will use SHA-256( sector_identifier || >> local_sub || salt ) >> >> - The sector_identifier_uri will be a configuration option of this >> protocolMapper implementation. >> >> - If protocolMapper is not added to client, the client will just use the >> public subjects. By default it's not added, which ensures backwards >> compatibility and public subjects by default. Note that with this approach, >> we don't even need subject_type option on the client. >> >> - The salt can be generated lazily at the first time when mapper is used. >> >> - The validation can be done at the moment, when protocolMapper is going >> to be created/updated. Right now, we don't have validation callback during >> protocolMapper creation/update. However Bill is going to add support for >> that into generic componentModel. So if we're going to refactor >> protocolMapper to use the new generic component model, we will have >> validation callback available to protocolMapper SPI. The validation will >> fail if array of redirect_uri from sector_identifier_uri doesn't contain >> the uris from redirect_uri of particular client (including wildcards etc). >> >> - If client is updated and it's redirect_uri are changed, we won't be >> able to catch this, however this is not strictly required per specs per my >> understanding. At least the dynamic client registration specs sais [1] >> >> "The values registered in redirect_uris MUST be included in the elements >> of the array, or registration MUST fail. This MUST be validated at >> registration time; there is no requirement for the OP to retain the >> contents of this JSON file or to retrieve or revalidate its contents in the >> future. " >> >> [1] >> http://openid.net/specs/openid-connect-registration-1_0.html#SectorIdentifierValidation >> >> >> Marek >> >> >> On 22/08/16 15:50, Martin Hardselius wrote: >> >> Ok, thanks for the clarification. >> >> Where would it make sense to put the PairwiseSubGeneratorSpi? Which >> package, that is? >> >> On Mon, 22 Aug 2016 at 14:51 Stian Thorgersen >> wrote: >> >>> On 22 August 2016 at 14:16, Martin Hardselius < >>> martin.hardselius at gmail.com> wrote: >>> >>>> "IMO it's sufficient to document the algorithm to create the sub, which >>>> should make it clear that the origin in the redirect uri will affect the >>>> sub." >>>> >>>> Reasonable. :) >>>> >>>> "One client could also have multiple redirect uris with different >>>> origins so could get different sub's generated depending on the redirect >>>> uri used." >>>> >>>> That case is probably caught by >>>> [...] If there are multiple hostnames in the registered redirect_uris, >>>> the Client MUST register a sector_identifier_uri. [...] >>>> >>> >>> Yes, but I meant from a documentation perspective. It should be clear >>> from the documentation that is the case. >>> >>> >>>> >>>> On Mon, 22 Aug 2016 at 10:42 Stian Thorgersen >>>> wrote: >>>> >>>>> IMO it's sufficient to document the algorithm to create the sub, which >>>>> should make it clear that the origin in the redirect uri will affect the >>>>> sub. One client could also have multiple redirect uris with different >>>>> origins so could get different sub's generated depending on the redirect >>>>> uri used. >>>>> >>>>> On 22 August 2016 at 09:58, Martin Hardselius < >>>>> martin.hardselius at gmail.com> wrote: >>>>> >>>>>> Sounds fair enough. >>>>>> >>>>>> What about the case where you don't provide a sector_identifier_uri, >>>>>> set up a single redirect uri on myhost and then later go on to change that >>>>>> redirect uri to something on myotherhost? That would change the >>>>>> sector_identifier and subsequently all the user subs. Do we protect against >>>>>> such "mistakes" or do we warn people (in the docs and/or admin gui) that >>>>>> it's not a good idea to do that? >>>>>> >>>>>> On Mon, 22 Aug 2016 at 09:38 Stian Thorgersen >>>>>> wrote: >>>>>> >>>>>>> We need to follow the spec and verify that sector_identifier_uri >>>>>>> points to a URL that contains the corresponding URIs. As an enhancement we >>>>>>> could support wildcards in the JSON returned by sector_identifier_uri. For >>>>>>> example if it returns: >>>>>>> >>>>>>> [ https://www.mydomain.com/*, https://www.myotherdomain.com/* ] >>>>>>> >>>>>>> A client with the redirect uri 'https://www.myotherdomain.com/myapp' >>>>>>> would work >>>>>>> >>>>>>> On 18 August 2016 at 15:09, Martin Hardselius < >>>>>>> martin.hardselius at gmail.com> wrote: >>>>>>> >>>>>>>> Speaking of subject_identifier_uri >>>>>>>> >>>>>>>> From the spec: >>>>>>>> >>>>>>>> "When a sector_identifier_uri is provided, the host component of >>>>>>>> that URL is used as the Sector Identifier for the pairwise identifier >>>>>>>> calculation. The value of the sector_identifier_uri MUST be a URL >>>>>>>> using the https scheme that points to a JSON file containing an >>>>>>>> array of redirect_uri values. The values of the registered >>>>>>>> redirect_uris MUST be included in the elements of the array." >>>>>>>> >>>>>>>> What's your stance on sanity/health checking the >>>>>>>> sector_identifier_uri? URI validation is one thing, but should we also make >>>>>>>> a request to the uri in order to validate the response? >>>>>>>> >>>>>>>> The spec also mentions that the sector_identifier_uri isn't >>>>>>>> strictly required if a client has all it's redirect_uris under the same >>>>>>>> domain. How do we deal with changes to clients if the sector_identifier_uri >>>>>>>> isn't required for enabling pairwise subs? >>>>>>>> >>>>>>>> Example: >>>>>>>> >>>>>>>> I create a client, enabling pairwise subs. Valid redirect_uris are >>>>>>>> [ https://www.mydomain.com/* ]. The sector_identifier would be >>>>>>>> mydomain. >>>>>>>> >>>>>>>> Later on, I update the redirect_uris to [ >>>>>>>> https://www.mydomain.com/*, https://www.myotherdomain.com/* ] Do we >>>>>>>> >>>>>>>> * keep the old sector_identifier, or >>>>>>>> * reject the update, or >>>>>>>> * allow the update if a valid subject_identifier_uri is provided at >>>>>>>> mydomain, or >>>>>>>> * just allow it and let the client devs deal with the consequences, >>>>>>>> or >>>>>>>> * take some other path you can think of ? >>>>>>>> >>>>>>>> Having the sector_identifier_uri as a hard requirement seems safer, >>>>>>>> but it's also means more work implementing a client. Leaving it optional is >>>>>>>> a lot more scary. >>>>>>>> >>>>>>>> >>>>>>>> On Thu, 18 Aug 2016 at 10:45 Stian Thorgersen >>>>>>>> wrote: >>>>>>>> >>>>>>>>> Makes sense to make this pluggable. The default should >>>>>>>>> probably SHA-256( sector_identifier || local_sub || salt ). >>>>>>>>> >>>>>>>>> We would love a PR for this, but there's a few bits required: >>>>>>>>> >>>>>>>>> * OIDC clients need option for subject type and >>>>>>>>> sector_identifier_uri. If not set it should default to public so existing >>>>>>>>> clients continue to work. These options can just be set as client >>>>>>>>> attributes so there's no need to update db schema >>>>>>>>> * Admin console update for the above >>>>>>>>> * PairwiseSubGeneratorSpi and default implementation >>>>>>>>> * Generation of salt for clients. This should be done when a >>>>>>>>> client sets subject type to pairwise >>>>>>>>> * Tests and docs >>>>>>>>> >>>>>>>>> I'd say the PairwiseSubGeneratorSpi signature should probably be: >>>>>>>>> >>>>>>>>> * public String getPairwiseSub(UserModel user, ClientModel client) >>>>>>>>> >>>>>>>>> It might even be an option to let the default PairwiseSubGenerator >>>>>>>>> provider create the salt and store it as an attribute on the client, making >>>>>>>>> that part pluggable as well. >>>>>>>>> >>>>>>>>> On 17 August 2016 at 15:59, Martin Hardselius < >>>>>>>>> martin.hardselius at gmail.com> wrote: >>>>>>>>> >>>>>>>>>> I'm going to bump this, as I want to continue the >>>>>>>>>> discussion/provide some input. >>>>>>>>>> >>>>>>>>>> Does it make sense to support more than type of pairwise subject >>>>>>>>>> identifier generator? E.g through a PairwiseSubGeneratorSpi? >>>>>>>>>> >>>>>>>>>> Let's say I want to generate the pairwise sub as a salted hash: >>>>>>>>>> sub = SHA-256( sector_identifier || local_sub || salt ) >>>>>>>>>> To me, it makes sense to allow for per-client salts. These salts >>>>>>>>>> should probably be generated and persisted during client creation. Thoughts? >>>>>>>>>> >>>>>>>>>> On Fri, 12 Aug 2016 at 09:57 Martin Hardselius < >>>>>>>>>> martin.hardselius at gmail.com> wrote: >>>>>>>>>> >>>>>>>>>>> Thank you for your response. Did not see that ticket before. >>>>>>>>>>> Great news! >>>>>>>>>>> >>>>>>>>>>> I looked into using protocol mappers to achieve this, and while >>>>>>>>>>> it would work I'm worried that once KEYCLOAK-3422 has been resolved and >>>>>>>>>>> included in a proper release we would run into migration issues if the >>>>>>>>>>> method used for calculating "native" pairwise subs is different from what >>>>>>>>>>> we implement. Clients could loose / be forced to re-register all their >>>>>>>>>>> users if we decide to switch. The example methods in the spec are just >>>>>>>>>>> that. Examples. Maybe the method/alg for computing the pairwise sub should >>>>>>>>>>> be pluggable? >>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>>> Martin >>>>>>>>>>> >>>>>>>>>>> On Thu, 11 Aug 2016 at 17:15 Marek Posolda >>>>>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>>> Sorry for late response. >>>>>>>>>>>> >>>>>>>>>>>> We have JIRA created for that. You can possibly add yourself as >>>>>>>>>>>> a watcher. See https://issues.jboss.org/browse/KEYCLOAK-3422 >>>>>>>>>>>> >>>>>>>>>>>> Maybe an alternative for you is to use protocolMappers. That >>>>>>>>>>>> should allow you to "construct" the token for particular client exactly how >>>>>>>>>>>> you want and also use the different value for "sub" claim. >>>>>>>>>>>> >>>>>>>>>>>> Another possibility is, to handle this on adapter side. We >>>>>>>>>>>> already have an adapter option "principal-attribute", which specifies that >>>>>>>>>>>> application will see the different attribute instead of "sub" as subject. >>>>>>>>>>>> For example when in appllication you call >>>>>>>>>>>> "httpServletRequest.getRemoteUser()" it will return "john" instead of >>>>>>>>>>>> "123456-unique-johns-uuid" . See >>>>>>>>>>>> https://keycloak.gitbooks.io/securing-client-applications-guide/content/v/2.1/topics/oidc/java/java-adapter-config.html >>>>>>>>>>>> >>>>>>>>>>>> Hopefully some of the options can be useful for you? >>>>>>>>>>>> >>>>>>>>>>>> Marek >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On 02/08/16 14:13, Martin Hardselius wrote: >>>>>>>>>>>> >>>>>>>>>>>> Me and my team are working towards getting Keycloak, customized >>>>>>>>>>>> for our needs, into production but we've identified the need for Pairwise >>>>>>>>>>>> Subject Identifiers as we don't want to expose internal user ids. >>>>>>>>>>>> >>>>>>>>>>>> Right now, the only subject_types_supported seems to be >>>>>>>>>>>> "public". Are there any near-future plans to include "pairwise"? Can we >>>>>>>>>>>> pitch in with a PR to make this happen as soon as possible? >>>>>>>>>>>> >>>>>>>>>>>> Links to relevant sections in the spec: >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> http://openid.net/specs/openid-connect-core-1_0.html#SubjectIDTypes >>>>>>>>>>>> http://openid.net/specs/openid-connect-core-1_0.html#PairwiseAlg >>>>>>>>>>>> >>>>>>>>>>>> -- >>>>>>>>>>>> Martin >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> keycloak-dev mailing listkeycloak-dev at lists.jboss.orghttps://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 >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>> >>>>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160824/9a3729dd/attachment-0001.html From mposolda at redhat.com Wed Aug 24 05:58:37 2016 From: mposolda at redhat.com (Marek Posolda) Date: Wed, 24 Aug 2016 11:58:37 +0200 Subject: [keycloak-dev] Import users from new User Federation In-Reply-To: <09947585-3304-f744-09f8-b9e613640004@redhat.com> References: <96ca98e1-f758-8e53-fac1-83f528079bc6@redhat.com> <1d491ec6-14d8-f1f8-3dbe-ad6b5c482f66@redhat.com> <57BBFDCB.4080705@redhat.com> <57BC5E83.30805@redhat.com> <09947585-3304-f744-09f8-b9e613640004@redhat.com> Message-ID: <57BD6FCD.8030501@redhat.com> On 23/08/16 17:58, Bill Burke wrote: > > > > On 8/23/16 10:32 AM, Marek Posolda wrote: >> On 23/08/16 15:04, Bill Burke wrote: >>> >>> >>> >>> On 8/23/16 3:39 AM, Marek Posolda wrote: >>>> On 19/08/16 15:52, Bill Burke wrote: >>>>> >>>>> >>>>> >>>>> On 8/19/16 2:37 AM, Stian Thorgersen wrote: >>>>>> >>>>>> >>>>>> On 18 August 2016 at 20:30, Bill Burke wrote: >>>>>> >>>>>> >>>>>> On 8/18/16 4:59 AM, Stian Thorgersen wrote: >>>>>> > Bill, >>>>>> > >>>>>> > Are you planing to have an option to allow import of users >>>>>> with the >>>>>> > new user federation SPI? I'm not convinced we should >>>>>> completely remove >>>>>> > this option. >>>>>> > >>>>>> >>>>>> The only callback that does not exist in the new SPI is >>>>>> validateAndProxy(). With the current federation SPI, the >>>>>> developer >>>>>> implements everything themselves for import. There are no >>>>>> synchronization APIs/SPIs either. >>>>>> >>>>>> >>>>>> Sounds like we're removing built-in features around >>>>>> synchronization just to make the user have to do everything >>>>>> themselves. >>>>> I think you misinterpreted me, The old User Federation SPI forces >>>>> the developer to write all the import code themselves. The old >>>>> User Federation SPI does not have any synchronization callbacks, >>>>> methods or interfaces other than validateAndProxy(), the logic of >>>>> which the user has to write themselves too. >>>>> >>>>> >>>>>> > Some use-cases I could imagine: >>>>>> > >>>>>> > * Allow users to authenticate even if LDAP server is down >>>>>> Our current LDAP provider will not work if LDAP is down, even >>>>>> with the >>>>>> import :) >>>>>> >>>>>> >>>>>> Yes, I know. However, the fact that we don't currently support it >>>>>> doesn't mean we shouldn't in the future. >>>>> If the user can only be authenticated via LDAP, an offline mode is >>>>> not possible. In other words, if LDAP does not expose the >>>>> password of a user (so it can be imported), then offline mode is >>>>> not possible. It would only be possible if the user has logged in >>>>> at least once, then the validated password could be imported. >>>>> >>>>> So, do you still think we should support import/offline mode given >>>>> all this? >>>> From some recent discussions I saw, it seems that quite many people >>>> are interested in the "import-and-forget" mode. So they need to >>>> import user from their old legacy store (3rd party storage or LDAP) >>>> but once user is fully in Keycloak DB, they want to completely >>>> forget about the 3rd party storage and do all operations around >>>> this user against Keycloak DB. >>>> >>>> The credentials/password validation seems to be the most >>>> complicated part around this as you pointed, as the password needs >>>> to be first successfully validated against 3rdparty storage or LDAP >>>> . Then once password is successfully validated and updated to >>>> Keycloak DB, user can be "forgotten" and unlinked from the >>>> federationProvider. I hope the new SPI has a way to deal with this >>>> usecase? Or at least have a hook, so the people can easily unlink >>>> the user by themselves whenever they want. >>>> >>> As I said before, the current SPI does not have any support for >>> import. It also does not have any SPIs around synchronization or >>> any synchronization buttons in the admin console. It is up to the >>> developer to write the code to import the user. And our current >>> LDAP implmementation is not "import and forget", you already >>> mentioned password validation, but there is also validateAndProxy >>> which is called every time the user is accessed and which hits LDAP >>> every time. There's also no way to unlink the user. >> Not right now, but it seems that many people consider the >> "import-and-forget" as important usecase? You just want to import the >> users from 3rd party storage or LDAP, but you need to do in multiple >> steps and "wait" until password is successfully validated for the >> first time. >> >> As an example this blogpost from Scott Rossillo >> https://tech.smartling.com/migrate-to-keycloak-with-zero-downtime-8dcab9e7cb2c#.1e8sy1o8n, >> which AFAIK seemed to have some positive feedback from more community >> users. >> >> I don't know how deeply to go with directly supporting it at SPI >> level. However IMO it will be good to have at least same level like >> the current UserFederation SPI. So at least at some point (ie. after >> successful password validation), the people can manually unlink the >> 3rd party provider from the user and migrate all the data to Keycloak >> DB and then use it just from Keycloak DB. >> > Ok, good feedback. You are convincing me. Are we absolutely sure > this is actually a best practice and not an anti-pattern? Seems scary > to be half in and half out. I guess it does make sense if you need to > keep something like LDAP up for legacy apps. > > > Just thinking around this we should have an additional interface for > imports: > > interface UserStorageSynchornization { > > void validate(UserModel). > void synchronize() > void unlink() > > > } > > > > validate is called whenever a user is looked up. Possibly used to > find deleted users and to synchronize updates on both sides on > demand. I want to add cache policies per provider, so maybe validate > is called only when pulled from persistence storage and not cache. > > I don't think we need different synchronize methods. We should > instead store last sync timestamp and last updated timestamp for each > user and add queries to local storage to find users for a specific > provider that were synced and/or updated after a certain time. Then > the synchronize implementation can make the assessment on what to > synchronize or not. I'd also like to be able to fire off > synchronization in the background and to obtain a status on it from > the admin console. If it fails, how many users synchronized, and > error message, etc. The support for "background" will be nice. That's what we missed until now. If I understand correctly, this will sync between any UserStorage to any other UserStorage, so it will defacto provider 2-ways sync ? > > unlink() would just be a callback whenever the admin console fires of > an unlink all users event. Sounds good to have callback for unlink. Still it will be good to have possibility to unlink individual users at specific moment (again, the example when you want to unlink user "john" from LDAP after he successfuly authenticated to LDAP with password "bar" as you can then immediatelly update the password to Keycloak DB and hence you don't need LDAP anymore). So for example the usecase like: 1) Keycloak configured with LDAP with 1000 users 2) 600 users authenticated with their passwords during week1, so they were already unlinked from LDAP as their passwords (And whole profile) imported to Keycloak DB 3) After week1, admin triggers the "unlink" event from admin console. At this point he wants to forcefully unlink remaining 400 users from LDAP and import them to Keycloak DB. He will also need to reset their password and send them email etc. This all can be implemented in the "unlink" callback method right? Not sure whether to support alternative of step3, like: 3.a) After week1, admin sends email to remaining 400 users like "Hey, please login in next 7 days. Otherwise your password will be restarted." 3.b) After week2, the real unlink is done with the password reset of users, which didn't login in both week1 and week2. Not sure if just "unlink" method is sufficient then... Overally it seems that the userStorage is super-complicated as various people have various use-cases and almost everyone has a bit different requirements and it's almost impossible to properly support everything. So IMO it's good if SPI has enough callbacks/extension points, so people can hook their actions and eventually implement themselves exactly what they want. Marek > > Bill -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160824/a69c2ab5/attachment.html From mposolda at redhat.com Wed Aug 24 06:03:14 2016 From: mposolda at redhat.com (Marek Posolda) Date: Wed, 24 Aug 2016 12:03:14 +0200 Subject: [keycloak-dev] Pairwise Subject Identifier In-Reply-To: References: <57AC9686.5040807@redhat.com> <57BB6324.2030403@redhat.com> <57BC51CE.9020504@redhat.com> Message-ID: <57BD70E2.50108@redhat.com> Sounds great. Thanks! Marek On 24/08/16 11:08, Martin Hardselius wrote: > Sounds good. I'll look into it and see what I can do. Possibly during > next week. :) > > On Tue, 23 Aug 2016 at 15:38 Marek Posolda > wrote: > > We discussed it with Stian a bit and we discussed to: > > - Implement as protocolMapper > > - There will be possibility to configure "salt" as parameter to > protocolMapper. It may not be mandatory parameter. If it's used, > then client will use it as salt, otherwise salt will be generated. > This allows the use-case you mentioned. You can use same salt for > clients x,y,z but different salt for clients m,n. If you let > generate salt, then the subject identifiers will be really unique > just to the particular client. > > - We need to validate sector_identifier_uri during create/update > of protocolMapper, but also during update of client. Otherwise > someone can register sector_identifier_uri and register the client > with valid redirect_uris (for example URLs "http://good-host/url1" > "http://good-host/url2" > , which are both specified under > sector_identifier_uri ) but then later update just the client > redirect_uris to "http://evil-host/url1" . > Basically he will be able to update redirect_uris to anything he > wants regardless of redirect_uris under sector_identifier_uri, so > the whole validation will be bypassed. > > For updating client, I've just sent PR, which adds > RealmModel.ClientUpdatedEvent . You can register to that event > similarly like > https://github.com/keycloak/keycloak/blob/master/server-spi/src/main/java/org/keycloak/protocol/AbstractLoginProtocolFactory.java#L39 > . The creation/update listener for protocolMapper doesn't yet > exists, however we are likely going to refactor protocolMapper to > generic component, which will have validation support. But that > will be likely available in few weeks, so for now, we can add > something temporary for protocolMappers similar to what is > available for example for UserFederationMapperFactory (See > https://github.com/keycloak/keycloak/blob/master/services/src/main/java/org/keycloak/services/resources/admin/UserFederationProviderResource.java#L437-L440 > ) > > Martin, will you have some time to eventually look into this and > send PR ? > > > Marek > > > On 23/08/16 14:25, Martin Hardselius wrote: >> Let's say we want to force all of our client to use pairwise >> subs, but a single "merchant" needs to implement several clients >> where subs should remain the same for all those clients. >> >> Merchant A >> - client x >> - client y >> - client z >> >> Merchant B >> - client m >> - client n >> >> You can assume the sector_identifiers are the same across all >> clients owned by a merchant >> >> It should not be possible to correlate activities between >> Customer A and Customer B (at least not from their side). They >> should, however, be able to correlate user activities between >> their own clients. >> >> Which implementation of pairwise subs is better suited for >> supporting this scenario? I'm leaning towards the protocol mapper >> solution. It should be easier to create custom mappers with >> merchant-wide configuration (e.g salts). >> >> On Mon, 22 Aug 2016 at 22:40 Marek Posolda > > wrote: >> >> The question is, should we really introduce another SPI for >> that? Doesn't it mean uneccessary complexity? Also add the >> new options directly to the client for the feature, which is >> likely interesting just for quite limited amount of people? >> >> IMO it's fine if this is implemented as protocolMapper? >> >> Few thoughts: >> - We can have abstract superclass like >> AbstractPairwiseSubGeneratorMapper . The subclasses will just >> need to implement method "generateSub" . We can have just one >> concrete impl, which will use SHA-256( sector_identifier || >> local_sub || salt ) >> >> - The sector_identifier_uri will be a configuration option of >> this protocolMapper implementation. >> >> - If protocolMapper is not added to client, the client will >> just use the public subjects. By default it's not added, >> which ensures backwards compatibility and public subjects by >> default. Note that with this approach, we don't even need >> subject_type option on the client. >> >> - The salt can be generated lazily at the first time when >> mapper is used. >> >> - The validation can be done at the moment, when >> protocolMapper is going to be created/updated. Right now, we >> don't have validation callback during protocolMapper >> creation/update. However Bill is going to add support for >> that into generic componentModel. So if we're going to >> refactor protocolMapper to use the new generic component >> model, we will have validation callback available to >> protocolMapper SPI. The validation will fail if array of >> redirect_uri from sector_identifier_uri doesn't contain the >> uris from redirect_uri of particular client (including >> wildcards etc). >> >> - If client is updated and it's redirect_uri are changed, we >> won't be able to catch this, however this is not strictly >> required per specs per my understanding. At least the dynamic >> client registration specs sais [1] >> >> "The values registered in redirect_uris MUST be included in >> the elements of the array, or registration MUST fail. This >> MUST be validated at registration time; there is no >> requirement for the OP to retain the contents of this JSON >> file or to retrieve or revalidate its contents in the future. " >> >> [1] >> http://openid.net/specs/openid-connect-registration-1_0.html#SectorIdentifierValidation >> >> >> Marek >> >> >> On 22/08/16 15:50, Martin Hardselius wrote: >>> Ok, thanks for the clarification. >>> >>> Where would it make sense to put the >>> PairwiseSubGeneratorSpi? Which package, that is? >>> >>> On Mon, 22 Aug 2016 at 14:51 Stian Thorgersen >>> > wrote: >>> >>> On 22 August 2016 at 14:16, Martin Hardselius >>> >> > wrote: >>> >>> "IMO it's sufficient to document the algorithm to >>> create the sub, which should make it clear that the >>> origin in the redirect uri will affect the sub." >>> >>> Reasonable. :) >>> >>> "One client could also have multiple redirect uris >>> with different origins so could get different sub's >>> generated depending on the redirect uri used." >>> >>> That case is probably caught by >>> [...] If there are multiple hostnames in the >>> registeredredirect_uris, the Client MUST register >>> asector_identifier_uri. [...] >>> >>> >>> Yes, but I meant from a documentation perspective. It >>> should be clear from the documentation that is the case. >>> >>> >>> On Mon, 22 Aug 2016 at 10:42 Stian Thorgersen >>> > >>> wrote: >>> >>> IMO it's sufficient to document the algorithm to >>> create the sub, which should make it clear that >>> the origin in the redirect uri will affect the >>> sub. One client could also have multiple >>> redirect uris with different origins so could >>> get different sub's generated depending on the >>> redirect uri used. >>> >>> On 22 August 2016 at 09:58, Martin Hardselius >>> >> > wrote: >>> >>> Sounds fair enough. >>> >>> What about the case where you don't provide >>> a sector_identifier_uri, set up a single >>> redirect uri on myhost and then later go on >>> to change that redirect uri to something on >>> myotherhost? That would change the >>> sector_identifier and subsequently all the >>> user subs. Do we protect against such >>> "mistakes" or do we warn people (in the docs >>> and/or admin gui) that it's not a good idea >>> to do that? >>> >>> On Mon, 22 Aug 2016 at 09:38 Stian >>> Thorgersen >> > wrote: >>> >>> We need to follow the spec and verify >>> that sector_identifier_uri points to a >>> URL that contains the corresponding >>> URIs. As an enhancement we could support >>> wildcards in the JSON returned >>> by sector_identifier_uri. For example if >>> it returns: >>> >>> [https://www.mydomain.com/*, >>> https://www.myotherdomain.com/* ] >>> >>> A client with the redirect uri >>> 'https://www.myotherdomain.com/myapp' >>> would work >>> >>> On 18 August 2016 at 15:09, Martin >>> Hardselius >> > wrote: >>> >>> Speaking of subject_identifier_uri >>> >>> From the spec: >>> >>> "When asector_identifier_uriis >>> provided, the host component of that >>> URL is used as the Sector Identifier >>> for the pairwise identifier >>> calculation. The value of >>> thesector_identifier_uriMUST be a >>> URL using thehttpsscheme that points >>> to a JSON file containing an array >>> ofredirect_urivalues. The values of >>> the registeredredirect_urisMUST be >>> included in the elements of the array." >>> >>> What's your stance on sanity/health >>> checking the sector_identifier_uri? >>> URI validation is one thing, but >>> should we also make a request to the >>> uri in order to validate the response? >>> >>> The spec also mentions that the >>> sector_identifier_uri isn't strictly >>> required if a client has all it's >>> redirect_uris under the same domain. >>> How do we deal with changes to >>> clients if the sector_identifier_uri >>> isn't required for enabling pairwise >>> subs? >>> >>> Example: >>> >>> I create a client, enabling pairwise >>> subs. Valid redirect_uris are [ >>> https://www.mydomain.com/* ]. The >>> sector_identifier would be mydomain. >>> >>> Later on, I update the redirect_uris >>> to [https://www.mydomain.com/*, >>> https://www.myotherdomain.com/* ] Do we >>> >>> * keep the old sector_identifier, or >>> * reject the update, or >>> * allow the update if a valid >>> subject_identifier_uri is provided >>> at mydomain, or >>> * just allow it and let the client >>> devs deal with the consequences, or >>> * take some other path you can think >>> of ? >>> >>> Having the sector_identifier_uri as >>> a hard requirement seems safer, but >>> it's also means more work >>> implementing a client. Leaving it >>> optional is a lot more scary. >>> >>> >>> On Thu, 18 Aug 2016 at 10:45 Stian >>> Thorgersen >> > wrote: >>> >>> Makes sense to make this >>> pluggable. The default should >>> probably SHA-256( >>> sector_identifier || local_sub >>> || salt ). >>> >>> We would love a PR for this, but >>> there's a few bits required: >>> >>> * OIDC clients need option for >>> subject type and >>> sector_identifier_uri. If not >>> set it should default to public >>> so existing clients continue to >>> work. These options can just be >>> set as client attributes so >>> there's no need to update db schema >>> * Admin console update for the above >>> * PairwiseSubGeneratorSpi and >>> default implementation >>> * Generation of salt for >>> clients. This should be done >>> when a client sets subject type >>> to pairwise >>> * Tests and docs >>> >>> I'd say the >>> PairwiseSubGeneratorSpi >>> signature should probably be: >>> >>> * public String >>> getPairwiseSub(UserModel user, >>> ClientModel client) >>> >>> It might even be an option to >>> let the >>> default PairwiseSubGenerator >>> provider create the salt and >>> store it as an attribute on the >>> client, making that part >>> pluggable as well. >>> >>> On 17 August 2016 at 15:59, >>> Martin Hardselius >>> >> > >>> wrote: >>> >>> I'm going to bump this, as I >>> want to continue the >>> discussion/provide some input. >>> >>> Does it make sense to >>> support more than type of >>> pairwise subject identifier >>> generator? E.g through a >>> PairwiseSubGeneratorSpi? >>> >>> Let's say I want to generate >>> the pairwise sub as a salted >>> hash: sub = SHA-256( >>> sector_identifier || >>> local_sub || salt ) >>> To me, it makes sense to >>> allow for per-client salts. >>> These salts should probably >>> be generated and persisted >>> during client creation. >>> Thoughts? >>> >>> On Fri, 12 Aug 2016 at 09:57 >>> Martin Hardselius >>> >> > >>> wrote: >>> >>> Thank you for your >>> response. Did not see >>> that ticket before. >>> Great news! >>> >>> I looked into using >>> protocol mappers to >>> achieve this, and while >>> it would work I'm >>> worried that once >>> KEYCLOAK-3422 has been >>> resolved and included in >>> a proper release we >>> would run into migration >>> issues if the method >>> used for calculating >>> "native" pairwise subs >>> is different from what >>> we implement. Clients >>> could loose / be forced >>> to re-register all their >>> users if we decide to >>> switch. The example >>> methods in the spec are >>> just that. Examples. >>> Maybe the method/alg for >>> computing the pairwise >>> sub should be pluggable? >>> >>> -- >>> Martin >>> >>> On Thu, 11 Aug 2016 at >>> 17:15 Marek Posolda >>> >> > >>> wrote: >>> >>> Sorry for late >>> response. >>> >>> We have JIRA created >>> for that. You can >>> possibly add >>> yourself as a >>> watcher. See >>> https://issues.jboss.org/browse/KEYCLOAK-3422 >>> >>> Maybe an alternative >>> for you is to use >>> protocolMappers. >>> That should allow >>> you to "construct" >>> the token for >>> particular client >>> exactly how you want >>> and also use the >>> different value for >>> "sub" claim. >>> >>> Another possibility >>> is, to handle this >>> on adapter side. We >>> already have an >>> adapter option >>> "principal-attribute", >>> which specifies that >>> application will see >>> the different >>> attribute instead of >>> "sub" as subject. >>> For example when in >>> appllication you >>> call >>> "httpServletRequest.getRemoteUser()" >>> it will return >>> "john" instead of >>> "123456-unique-johns-uuid" >>> . See >>> https://keycloak.gitbooks.io/securing-client-applications-guide/content/v/2.1/topics/oidc/java/java-adapter-config.html >>> >>> Hopefully some of >>> the options can be >>> useful for you? >>> >>> Marek >>> >>> >>> On 02/08/16 14:13, >>> Martin Hardselius wrote: >>>> Me and my team are >>>> working towards >>>> getting Keycloak, >>>> customized for our >>>> needs, into >>>> production but >>>> we've identified >>>> the need for >>>> Pairwise Subject >>>> Identifiers as we >>>> don't want to >>>> expose internal >>>> user ids. >>>> >>>> Right now, the only >>>> subject_types_supported >>>> seems to be >>>> "public". Are there >>>> any near-future >>>> plans to include >>>> "pairwise"? Can we >>>> pitch in with a PR >>>> to make this happen >>>> as soon as possible? >>>> >>>> Links to relevant >>>> sections in the spec: >>>> >>>> http://openid.net/specs/openid-connect-core-1_0.html#SubjectIDTypes >>>> http://openid.net/specs/openid-connect-core-1_0.html#PairwiseAlg >>>> >>>> -- >>>> Martin >>>> >>>> >>>> _______________________________________________ >>>> 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 >>> >>> >>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160824/a8367d3a/attachment-0001.html From adrian.mitev at gmail.com Wed Aug 24 09:53:23 2016 From: adrian.mitev at gmail.com (Adrian Mitev) Date: Wed, 24 Aug 2016 16:53:23 +0300 Subject: [keycloak-dev] JDK or JRE for running Keycloak Message-ID: Hi all! Is JDK required for Keycloack or pure JRE can be used. I'm trying to create the smallest possible docker image for the purpose. If JDK is required, what JDK tools does Keycloack use? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160824/c23e1249/attachment.html From thomas.darimont at googlemail.com Wed Aug 24 10:23:45 2016 From: thomas.darimont at googlemail.com (Thomas Darimont) Date: Wed, 24 Aug 2016 16:23:45 +0200 Subject: [keycloak-dev] JDK or JRE for running Keycloak In-Reply-To: References: Message-ID: Hello Adrian, we're running Keycloak 2.1.0.Final on Java 8 Server JRE (server-jre-8u102-linux-x64) in an Alpine Linux based docker image - works like a charm. Cheers, Thomas 2016-08-24 15:53 GMT+02:00 Adrian Mitev : > Hi all! Is JDK required for Keycloack or pure JRE can be used. I'm trying > to create the smallest possible docker image for the purpose. If JDK is > required, what JDK tools does Keycloack use? > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160824/1a8fddef/attachment.html From jdennis at redhat.com Wed Aug 24 12:20:17 2016 From: jdennis at redhat.com (John Dennis) Date: Wed, 24 Aug 2016 12:20:17 -0400 Subject: [keycloak-dev] Issue with single sign out using salesforce SP with keycloak IDP and also customizing the logout page In-Reply-To: References: Message-ID: <4447b0ae-f256-84f5-2d44-603ab73179d3@redhat.com> On 08/23/2016 09:05 AM, Rashmi Singh wrote: > On keycloak logs, I only see this error: > > 2016-08-23 00:49:24,648 WARN [org.keycloak.events] (default task-6) > type=LOGIN_ERROR, realmId=saml-demo, clientId=null, userId=null, > ipAddress=192.168.99.1, error=invalid_token > > This is a generic error and does not give any clue. > > I used SAML tracer with firefox and there I see the following request in > RED: > > GET http://rashmiidp.cloud.com:9990/auth/realms/saml-demo/protocol/saml > > Here are the contents for this request from SAML tracer (but its not > giving me any clue on what is wrong): You didn't post the SAML content from the SAMLTracer SAML tab. -- John From singhrasster at gmail.com Wed Aug 24 12:27:35 2016 From: singhrasster at gmail.com (Rashmi Singh) Date: Wed, 24 Aug 2016 11:27:35 -0500 Subject: [keycloak-dev] Issue with single sign out using salesforce SP with keycloak IDP and also customizing the logout page In-Reply-To: <4447b0ae-f256-84f5-2d44-603ab73179d3@redhat.com> References: <4447b0ae-f256-84f5-2d44-603ab73179d3@redhat.com> Message-ID: John, Can you take a look at my last post? It seems like Salesforce is not supporting Single logout. Is there some keycloak URL we can provide for the field "Identity Provider Logout URL" on saleforce Single Sign on Settings" that would log the user out? Since, it seems like Salesforce is not even sending a SAML request when doing a logout. Here is what I wrote yesterday: "Looking more closely into this, it seems like Salesforce does not support SAML logout. In Salesforce, where I did the configuration for "SAML Single Sign-On Settings", there is the following field: Identity Provider Logout URL: I had specified this as: http://rashmiidp.cloud.com: 9990/auth/realms/saml-demo/protocol/saml But, since Salesforce does not seem to support SAML logout, is it possible to specify some keycloak URL in this field that would logout the user? It seems like the URL I specify in this field gets invoked but then Salesforce is not really sending a SAML logout request and I just get an error as indicated earlier. So, I was thinking if there is some keycloak URL that we can specify in this field that would logout the user? If there is no such URL support, is there an alternative to solve this issue since Salesforce does not seem to handle the single logout?" On Wed, Aug 24, 2016 at 11:20 AM, John Dennis wrote: > On 08/23/2016 09:05 AM, Rashmi Singh wrote: > >> On keycloak logs, I only see this error: >> >> 2016-08-23 00:49:24,648 WARN [org.keycloak.events] (default task-6) >> type=LOGIN_ERROR, realmId=saml-demo, clientId=null, userId=null, >> ipAddress=192.168.99.1, error=invalid_token >> >> This is a generic error and does not give any clue. >> >> I used SAML tracer with firefox and there I see the following request in >> RED: >> >> GET http://rashmiidp.cloud.com:9990/auth/realms/saml-demo/protocol/saml >> >> Here are the contents for this request from SAML tracer (but its not >> giving me any clue on what is wrong): >> > > You didn't post the SAML content from the SAMLTracer SAML tab. > > > -- > John > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160824/a9efabf1/attachment.html From jdennis at redhat.com Wed Aug 24 12:30:24 2016 From: jdennis at redhat.com (John Dennis) Date: Wed, 24 Aug 2016 12:30:24 -0400 Subject: [keycloak-dev] Issue with single sign out using salesforce SP with keycloak IDP and also customizing the logout page In-Reply-To: References: Message-ID: <8711154d-7e9f-9c99-2847-b57e487cfee5@redhat.com> On 08/23/2016 06:04 PM, Rashmi Singh wrote: > Looking more closely into this, it seems like Salesforce does not > support SAML logout. > > In Salesforce, where I did the configuration for "SAML Single Sign-On > Settings", there is the following field: > > Identity Provider Logout URL: > I had specified this as: > http://rashmiidp.cloud.com:9990/auth/realms/saml-demo/protocol/saml > > But, since Salesforce does not seem to support SAML logout, is it > possible to specify some keycloak URL in this field that would logout > the user? It seems like the URL I specify in this field gets invoked but > then Salesforce is not really sending a SAML logout request and I just > get an error as indicated earlier. So, I was thinking if there is some > keycloak URL that we can specify in this field that would logout the user? > > If there is no such URL support, is there an alternative to solve this > issue since Salesforce does not seem to handle the single logout? Why do you draw the conclusion Salesforce does not support logout? That does not seem to be indicated from this document: http://resources.docs.salesforce.com/202/18/en-us/sfdc/pdf/salesforce_single_sign_on.pdf What is the SP metadata you used? -- John From singhrasster at gmail.com Wed Aug 24 12:33:32 2016 From: singhrasster at gmail.com (Rashmi Singh) Date: Wed, 24 Aug 2016 11:33:32 -0500 Subject: [keycloak-dev] Issue with single sign out using salesforce SP with keycloak IDP and also customizing the logout page In-Reply-To: <8711154d-7e9f-9c99-2847-b57e487cfee5@redhat.com> References: <8711154d-7e9f-9c99-2847-b57e487cfee5@redhat.com> Message-ID: Here is how my SP Metadata looks like: urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified MIIFYDCCBEigAwIBAgIQQ4KxN7E3aAGP1rpwQm6gZzANBgkqhkiG9w0BAQUF ADCBvDELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8w HQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJt cyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykx MDE2MDQGA1UEAxMtVmVyaVNpZ24gQ2xhc3MgMyBJbnRlcm5hdGlvbmFsIFNl cnZlciBDQSAtIEczMB4XDTEzMTAxODAwMDAwMFoXDTE3MTAxNzIzNTk1OVow gY8xCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpDYWxpZm9ybmlhMRYwFAYDVQQH FA1TYW4gRnJhbmNpc2NvMR0wGwYDVQQKFBRTYWxlc2ZvcmNlLmNvbSwgSW5j LjEVMBMGA1UECxQMQXBwbGljYXRpb25zMR0wGwYDVQQDFBRwcm94eS5zYWxl c2ZvcmNlLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALJtS/8tJmPZ/CKOz/ dJ7MXrgz0MPQKxEAdgrdOFdRjsavTY+RviREe+zwjrKd9ZsCS3GltV2GBFD+ YxXzuptQr+ZUDC8Vwx+49WQ13D55nmoUJVcB1nHlTXBICJQDo 87cZ4AIViuSVkUfQRG7BeMfKTMngyGdAOIsnSFwp1ONmRqaIarWTfr2w0SNF NPikW9rQjehAF/eh6Ib4H3bJEE/kAwRS4mFJoxEKsiJQhnymqeoVgLMSb3UTS8J9R1RmQi+ kisC39NAzVwQjM1X677cdQt0FaF6GlZ97vCH/rpNAJnAVwaWiRNQ32AR2X39rp8DVpS k9eynNGp1JI/6mIv3ECAwEAAaOCAYcwggGDMB8GA1UdEQQYMBaCFHByb3h5LnNhbGVzZm9yY 2UuY29tMAkGA1UdEwQCMAAwDgYDVR0PAQH/BAQDAgWgMCgGA1UdJQQhMB8GCCsGAQ UFBwMBBggrBgEFBQcDAgYJYIZIAYb4QgQBMEMGA1UdIAQ8MDowOAYKYIZIAY b4RQEHNjAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb2 0vY3BzMB8GA1UdIwQYMBaAFNebfNgioBX33a1fzimbWMO8RgC1MEEGA1UdHw Q6MDgwNqA0oDKGMGh0dHA6Ly9TVlJJbnRsLUczLWNybC52ZXJpc2lnbi5jb2 0vU1ZSSW50bEczLmNybDByBggrBgEFBQcBAQRmMGQwJAYIKwYBBQUHMAGGGG h0dHA6Ly9vY3NwLnZlcmlzaWduLmNvbTA8BggrBgEFBQcwAoYwaHR0cDovL1 NWUkludGwtRzMtYWlhLnZlcmlzaWduLmNvbS9TVlJJbnRsRzMuY2VyMA0GCS qGSIb3DQEBBQUAA4IBAQAEMsL4HAd5uYW3j0SQFX4Opl7p0Vo4o7HKBHCtV4ZjzkSFwvRR9+ 5zijYqlhe4ou1SL4WAWAsTKMTpKz0CL1S9Npt0IcKmIWeRsjJKKznFa8sxHh gEvm3O11a9uVfgvmnwn0VEpuTmGvXvIUSAZ5q0CVDgzbGsrjWnZXllgO6krw PonEg6MdFarA87bAkLCrLZ0HqWeUVlf2ntfvR7kjr0trUM/ EBxPdcPxeMK70EJqku7GMEPOxkexTr2O0yD/2lZM0il+AUuOboZDl0SyfjU0N7YIKNKZq5hcoUP/ sCpcReMNj0dAWeVYmADrV7LlOVvndgHKcLrUydS/9obQHen On Wed, Aug 24, 2016 at 11:30 AM, John Dennis wrote: > On 08/23/2016 06:04 PM, Rashmi Singh wrote: > >> Looking more closely into this, it seems like Salesforce does not >> support SAML logout. >> >> In Salesforce, where I did the configuration for "SAML Single Sign-On >> Settings", there is the following field: >> >> Identity Provider Logout URL: >> I had specified this as: >> http://rashmiidp.cloud.com:9990/auth/realms/saml-demo/protocol/saml >> >> But, since Salesforce does not seem to support SAML logout, is it >> possible to specify some keycloak URL in this field that would logout >> the user? It seems like the URL I specify in this field gets invoked but >> then Salesforce is not really sending a SAML logout request and I just >> get an error as indicated earlier. So, I was thinking if there is some >> keycloak URL that we can specify in this field that would logout the user? >> >> If there is no such URL support, is there an alternative to solve this >> issue since Salesforce does not seem to handle the single logout? >> > > Why do you draw the conclusion Salesforce does not support logout? That > does not seem to be indicated from this document: > > http://resources.docs.salesforce.com/202/18/en-us/sfdc/pdf/ > salesforce_single_sign_on.pdf > > What is the SP metadata you used? > > > -- > John > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160824/29a36896/attachment-0001.html From bburke at redhat.com Thu Aug 25 01:17:36 2016 From: bburke at redhat.com (Bill Burke) Date: Thu, 25 Aug 2016 01:17:36 -0400 Subject: [keycloak-dev] Issue with single sign out using salesforce SP with keycloak IDP and also customizing the logout page In-Reply-To: References: <8711154d-7e9f-9c99-2847-b57e487cfee5@redhat.com> Message-ID: <85f8c42c-908f-71ae-f516-df4d00693034@redhat.com> My guess is that Salesforce is not signing the logout request and Keycloak expects it to be signed, but can't really know unless you post your SAML tracer. Also, Edit your standalone.xml config file (really depending on how you've booted keycloak). Search for "logging:3.0". IN that section, turn on debug logging for keycloak: That may shed some light on things. On 8/24/16 12:33 PM, Rashmi Singh wrote: > Here is how my SP Metadata looks like: > > entityID="https://saml.salesforce.com "> > > protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol > urn:oasis:names:tc:SAML:1.1:protocolhttp://schemas.xmlsoap.org/ws/2003/07/secext > "> > > urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified > > Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" > Location="https://rashmi789-dev-ed.my.salesforce.com?so=00D410000005L14 > "/> > > Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" > Location="https://rashmi789-dev-ed.my.salesforce.com?so=00D410000005L14 > " > index="1" isDefault="true" /> > > xmlns:dsig="http://www.w3.org/2000/09/xmldsig# > "> > > > MIIFYDCCBEigAwIBAgIQQ4KxN7E3aAGP1rpwQm6gZzANBgkqhkiG9w0BAQUFADCBvDELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykxMDE2MDQGA1UEAxMtVmVyaVNpZ24gQ2xhc3MgMyBJbnRlcm5hdGlvbmFsIFNlcnZlciBDQSAtIEczMB4XDTEzMTAxODAwMDAwMFoXDTE3MTAxNzIzNTk1OVowgY8xCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpDYWxpZm9ybmlhMRYwFAYDVQQHFA1TYW4gRnJhbmNpc2NvMR0wGwYDVQQKFBRTYWxlc2ZvcmNlLmNvbSwgSW5jLjEVMBMGA1UECxQMQXBwbGljYXRpb25zMR0wGwYDVQQDFBRwcm94eS5zYWxlc2ZvcmNlLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALJtS/8tJmPZ/CKOz/dJ7MXrgz0MPQKxEAdgrdOFdRjsavTY+RviREe+zwjrKd9ZsCS3GltV2GBFD+YxXzuptQr+ZUDC8Vwx+49WQ13D55nmoUJVcB1nHlTXBICJQDo87cZ4AIViuSVkUfQRG7BeMfKTMngyGdAOIsnSFwp1ONmRqaIarWTfr2w0SNFNPikW9rQjehAF/eh6Ib4H3bJEE/kAwRS4mFJoxEKsiJQhnymqeoVgLMSb3UTS8J9R1RmQi+kisC39NAzVwQjM1X677cdQt0FaF6GlZ97vCH/rpNAJnAVwaWiRNQ32AR2X39rp8DVpSk9eynNGp1JI/6mIv3ECAwEAAaOCAYcwggGDMB8GA1UdEQQYMBaCFHByb3h5LnNhbGVzZm9yY2UuY29tMAkGA1UdEwQCMAAwDgYDVR0PAQH/BAQDAgWgMCgGA1UdJQQhMB8GCCsGAQUFBwMBBggrBgEFBQcDAgYJYIZIAYb4QgQBMEMGA1UdIAQ8MDowOAYKYIZIAYb4RQEHNjAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vY3BzMB8GA1UdIwQYMBaAFNebfNgioBX33a1fzimbWMO8RgC1MEEGA1UdHwQ6MDgwNqA0oDKGMGh0dHA6Ly9TVlJJbnRsLUczLWNybC52ZXJpc2lnbi5jb20vU1ZSSW50bEczLmNybDByBggrBgEFBQcBAQRmMGQwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnZlcmlzaWduLmNvbTA8BggrBgEFBQcwAoYwaHR0cDovL1NWUkludGwtRzMtYWlhLnZlcmlzaWduLmNvbS9TVlJJbnRsRzMuY2VyMA0GCSqGSIb3DQEBBQUAA4IBAQAEMsL4HAd5uYW3j0SQFX4Opl7p0Vo4o7HKBHCtV4ZjzkSFwvRR9+5zijYqlhe4ou1SL4WAWAsTKMTpKz0CL1S9Npt0IcKmIWeRsjJKKznFa8sxHhgEvm3O11a9uVfgvmnwn0VEpuTmGvXvIUSAZ5q0CVDgzbGsrjWnZXllgO6krwPonEg6MdFarA87bAkLCrLZ0HqWeUVlf2ntfvR7kjr0trUM/EBxPdcPxeMK70EJqku7GMEPOxkexTr2O0yD/2lZM0il+AUuOboZDl0SyfjU0N7YIKNKZq5hcoUP/sCpcReMNj0dAWeVYmADrV7LlOVvndgHKcLrUydS/9obQHen > > > > > > > > On Wed, Aug 24, 2016 at 11:30 AM, John Dennis > wrote: > > On 08/23/2016 06:04 PM, Rashmi Singh wrote: > > Looking more closely into this, it seems like Salesforce does not > support SAML logout. > > In Salesforce, where I did the configuration for "SAML Single > Sign-On > Settings", there is the following field: > > Identity Provider Logout URL: > I had specified this as: > http://rashmiidp.cloud.com:9990/auth/realms/saml-demo/protocol/saml > > > But, since Salesforce does not seem to support SAML logout, is it > possible to specify some keycloak URL in this field that would > logout > the user? It seems like the URL I specify in this field gets > invoked but > then Salesforce is not really sending a SAML logout request > and I just > get an error as indicated earlier. So, I was thinking if there > is some > keycloak URL that we can specify in this field that would > logout the user? > > If there is no such URL support, is there an alternative to > solve this > issue since Salesforce does not seem to handle the single logout? > > > Why do you draw the conclusion Salesforce does not support logout? > That does not seem to be indicated from this document: > > http://resources.docs.salesforce.com/202/18/en-us/sfdc/pdf/salesforce_single_sign_on.pdf > > > What is the SP metadata you used? > > > -- > John > > > > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160825/00b9e283/attachment.html From sthorger at redhat.com Thu Aug 25 02:34:02 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Thu, 25 Aug 2016 08:34:02 +0200 Subject: [keycloak-dev] [keycloak-user] Review Japanese translations In-Reply-To: <1472007069.2143.1.camel@redhat.com> References: <1472007069.2143.1.camel@redhat.com> Message-ID: Great, thanks. On 24 August 2016 at 04:51, Hisanobu Okuda wrote: > Stian, > > I can do that. > > Regards, > Hisanobu > > On Tue, 2016-08-23 at 13:01 +0200, Stian Thorgersen wrote: > > We have a PR for Japanese translations, but I would like someone to > > review it prior to merging it. Is there any Japanese speakers out > > there that could review it for me? > > _______________________________________________ > > keycloak-user mailing list > > keycloak-user at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/keycloak-user > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160825/f42f3f84/attachment.html From sthorger at redhat.com Thu Aug 25 02:36:05 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Thu, 25 Aug 2016 08:36:05 +0200 Subject: [keycloak-dev] rethinking credentials In-Reply-To: <44154574-cece-b6f7-010d-0d6202433d13@redhat.com> References: <49425643-9824-9fb7-d3c0-8fea12539f94@redhat.com> <57AC8E20.3020809@redhat.com> <20160816141238.GC19203@abstractj.org> <57BBFBB8.8010804@redhat.com> <44154574-cece-b6f7-010d-0d6202433d13@redhat.com> Message-ID: Clients are not modeled as a user now though. They're linked to a user, but have a separate mechanism to store credentials right? On 23 August 2016 at 15:43, Bill Burke wrote: > I'm only thinking about users right now. That in itself is a big complex > problem. Clients are users, so how would they be different? > > On 8/23/16 7:38 AM, Stian Thorgersen wrote: > > If we're introducing a new credentials SPI should be consider using it for > realms and clients as well? > > Realms currently have a few things, but we soon need to support key > rotation which would mean a realm could have more than one keypair at a time > > Clients already have secret or keypair based auth, but will in the future > need certs. Then there's also needs for custom authenticators to store > credentials. > > On 23 August 2016 at 09:31, Marek Posolda wrote: > >> On 16/08/16 22:51, Bill Burke wrote: >> > >> > >> > On 8/16/16 10:12 AM, Bruno Oliveira wrote: >> >> On 2016-08-11, Marek Posolda wrote: >> >>> I wonder if we can have UserCredentialValueModel to be more generic >> >>> store? Currently it has properties applicable just to password or OTP >> >>> credentials, but it will be better to have something more generic >> based >> >>> on key-value pairs though. >> >> +1 that would be fantastic, if possible. >> > A data model that can store any arbitrary key-value pair would require >> > a join with RDBMs storage. Should we keep something like >> > UsercredValModel, but just add the ability for attributes? Then model >> > the API so that it can avoid joins? There's also the issue of data >> > migration from the old tables to the new. Since this is users we >> > could be talking about tens of thousands of rows. >> Yep, maybe we can keep the "old" attributes on the UserCredValModel, so >> it's not needed to migrate and most important credential types ( >> password, OTP) don't need to change anything. Still we can add key-value >> for other credential types? Maybe the caching of users and user >> credentials also helps with the performance, so the performance >> bottleneck of joins won't be so bad (but yes, I know that we need to >> limit size of userCache cache, so the same user and his credential may >> be still downloaded from underlying DB multiple times...) >> >> Marek >> > >> > Bill >> >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160825/e3274706/attachment-0001.html From vramik at redhat.com Thu Aug 25 07:06:07 2016 From: vramik at redhat.com (Vlasta Ramik) Date: Thu, 25 Aug 2016 13:06:07 +0200 Subject: [keycloak-dev] jta=false in datasource definition Message-ID: <67bfc3a0-a993-e084-cd57-50debae96498@redhat.com> Hi, I've noticed that there is added jta="false" in datasource definition in standalone.xml by default. It was introduced by https://github.com/keycloak/keycloak/commit/33d7d89ad91ecdf672311cc392f8d9ca1f9822bc#diff-61beaf3ba959e1d76d012978110bc7dbR32 Should be the jta parameter added into datasource definition for all tested databases? V. From bburke at redhat.com Thu Aug 25 08:42:14 2016 From: bburke at redhat.com (Bill Burke) Date: Thu, 25 Aug 2016 08:42:14 -0400 Subject: [keycloak-dev] jta=false in datasource definition In-Reply-To: <67bfc3a0-a993-e084-cd57-50debae96498@redhat.com> References: <67bfc3a0-a993-e084-cd57-50debae96498@redhat.com> Message-ID: <98da9134-400d-4774-8c95-121f47a27ed2@redhat.com> Yes, but hopefully this will be reverted back soon. On 8/25/16 7:06 AM, Vlasta Ramik wrote: > Hi, > > I've noticed that there is added jta="false" in datasource definition in > standalone.xml by default. It was introduced by > https://github.com/keycloak/keycloak/commit/33d7d89ad91ecdf672311cc392f8d9ca1f9822bc#diff-61beaf3ba959e1d76d012978110bc7dbR32 > > > > Should be the jta parameter added into datasource definition for all > tested databases? > > V. > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev From vramik at redhat.com Thu Aug 25 08:56:18 2016 From: vramik at redhat.com (Vlasta Ramik) Date: Thu, 25 Aug 2016 14:56:18 +0200 Subject: [keycloak-dev] jta=false in datasource definition In-Reply-To: <98da9134-400d-4774-8c95-121f47a27ed2@redhat.com> References: <67bfc3a0-a993-e084-cd57-50debae96498@redhat.com> <98da9134-400d-4774-8c95-121f47a27ed2@redhat.com> Message-ID: <57de67f7-c287-1491-5238-5271acab357f@redhat.com> ok, so will it be better to wait till it will be reverted or update ds configuration now and put it back once it is reverted? On 08/25/2016 02:42 PM, Bill Burke wrote: > Yes, but hopefully this will be reverted back soon. > > > On 8/25/16 7:06 AM, Vlasta Ramik wrote: >> Hi, >> >> I've noticed that there is added jta="false" in datasource definition in >> standalone.xml by default. It was introduced by >> https://github.com/keycloak/keycloak/commit/33d7d89ad91ecdf672311cc392f8d9ca1f9822bc#diff-61beaf3ba959e1d76d012978110bc7dbR32 >> >> >> >> Should be the jta parameter added into datasource definition for all >> tested databases? >> >> V. >> >> _______________________________________________ >> 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 caroline.s.olsen at gmail.com Thu Aug 25 09:05:26 2016 From: caroline.s.olsen at gmail.com (Caroline Sofie Olsen) Date: Thu, 25 Aug 2016 15:05:26 +0200 Subject: [keycloak-dev] Norwegian Localization Message-ID: Hi! I?ve translated all base theme messages to Norwegian for our project, and I would like to contribute the message resources. Is it okay if I create a JIRA issue and a PR? Kind regards, Caroline Sofie Olsen -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160825/db8c4ef6/attachment.html From caroline.s.olsen at gmail.com Thu Aug 25 09:06:49 2016 From: caroline.s.olsen at gmail.com (Caroline Sofie Olsen) Date: Thu, 25 Aug 2016 15:06:49 +0200 Subject: [keycloak-dev] Optional mappers due to privacy legislation Message-ID: Hi all, Given that you have a client that has consent required turned on in the admin panel. And in the mappers tab you have chosen specific mappers that needs to be consented by the end user. However, due to privacy related legislation, we need to make mappers that are not crucial for the application optional for the end user (Crucial meaning that the application will not work without those particular mapper(s)). Is this functionality supported in Keycloak? I?ve seen this functionality in the OpenID Connect documentation ( http://connect2id.com/learn/openid-connect#example-auth-code-flow). I?ve added a screenshot of the OpenID Connect example. If it is supported, where do I go from here? Also, is it possible to add timestamps for when the user gives consent? [if !supportLineBreakNewLine] Lastly, for legislative reasons, we also need to know in which scenario the user gives consent. Is it on the first sign in, or is it when updating consent that the client requires etc. Is this possible? Kind regards Caroline Olsen -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160825/b0552d59/attachment.html From bburke at redhat.com Thu Aug 25 09:20:21 2016 From: bburke at redhat.com (Bill Burke) Date: Thu, 25 Aug 2016 09:20:21 -0400 Subject: [keycloak-dev] jta=false in datasource definition In-Reply-To: <57de67f7-c287-1491-5238-5271acab357f@redhat.com> References: <67bfc3a0-a993-e084-cd57-50debae96498@redhat.com> <98da9134-400d-4774-8c95-121f47a27ed2@redhat.com> <57de67f7-c287-1491-5238-5271acab357f@redhat.com> Message-ID: Put the parameter in. Reverting jta=false is low on my queue. On 8/25/16 8:56 AM, Vlasta Ramik wrote: > ok, so will it be better to wait till it will be reverted or update ds > configuration now and put it back once it is reverted? > > > On 08/25/2016 02:42 PM, Bill Burke wrote: >> Yes, but hopefully this will be reverted back soon. >> >> >> On 8/25/16 7:06 AM, Vlasta Ramik wrote: >>> Hi, >>> >>> I've noticed that there is added jta="false" in datasource definition in >>> standalone.xml by default. It was introduced by >>> https://github.com/keycloak/keycloak/commit/33d7d89ad91ecdf672311cc392f8d9ca1f9822bc#diff-61beaf3ba959e1d76d012978110bc7dbR32 >>> >>> >>> >>> Should be the jta parameter added into datasource definition for all >>> tested databases? >>> >>> V. >>> >>> _______________________________________________ >>> 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 singhrasster at gmail.com Thu Aug 25 10:22:54 2016 From: singhrasster at gmail.com (Rashmi Singh) Date: Thu, 25 Aug 2016 09:22:54 -0500 Subject: [keycloak-dev] Issue with single sign out using salesforce SP with keycloak IDP and also customizing the logout page In-Reply-To: <85f8c42c-908f-71ae-f516-df4d00693034@redhat.com> References: <8711154d-7e9f-9c99-2847-b57e487cfee5@redhat.com> <85f8c42c-908f-71ae-f516-df4d00693034@redhat.com> Message-ID: When I do a logout, my SAML tracer show this request: *GET http://rashmiidp.cloud.com:9990/auth/realms/saml-demo/protocol/saml HTTP/1.1* And clicking this request just shows the HTTP tab. It does not even show the SAML tab. So, it looks like Salefroce does not send SAML request for logout. That was the reason, I was asking if there is another way to do the user sign out from keycloak. That is, in instead of the above URL we use a different url (some keycloak URL) that would sign out the user. Or some other alternative? On Thu, Aug 25, 2016 at 12:17 AM, Bill Burke wrote: > My guess is that Salesforce is not signing the logout request and Keycloak > expects it to be signed, but can't really know unless you post your SAML > tracer. Also, Edit your standalone.xml config file (really depending on > how you've booted keycloak). Search for "logging:3.0". IN that section, > turn on debug logging for keycloak: > > > > > > > That may shed some light on things. > > On 8/24/16 12:33 PM, Rashmi Singh wrote: > > Here is how my SP Metadata looks like: > > > protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol > urn:oasis:names:tc:SAML:1.1:protocolhttp://schemas.xmlsoap. > org/ws/2003/07/secext"> > urn:oasis:names:tc:SAML:1.1:nameid-format:unsp > ecified > > Location="https://rashmi789-dev-ed.my.salesforce.com?so=00D410000005L14 > "/> > Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" > Location="https://rashmi789-dev-ed.my.salesforce.com?so=00D410000005L14 > " > index="1" isDefault="true" /> > > > > > MIIFYDCCBEigAwIBAgIQQ4KxN7E3aAGP1rpwQm6gZzANBgkqhkiG9w0BAQUF > ADCBvDELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8w > HQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJt > cyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykx > MDE2MDQGA1UEAxMtVmVyaVNpZ24gQ2xhc3MgMyBJbnRlcm5hdGlvbmFsIFNl > cnZlciBDQSAtIEczMB4XDTEzMTAxODAwMDAwMFoXDTE3MTAxNzIzNTk1OVow > gY8xCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpDYWxpZm9ybmlhMRYwFAYDVQQH > FA1TYW4gRnJhbmNpc2NvMR0wGwYDVQQKFBRTYWxlc2ZvcmNlLmNvbSwgSW5j > LjEVMBMGA1UECxQMQXBwbGljYXRpb25zMR0wGwYDVQQDFBRwcm94eS5zYWxl > c2ZvcmNlLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALJt > S/8tJmPZ/CKOz/dJ7MXrgz0MPQKxEAdgrdOFdRjsavTY+RviREe+ > zwjrKd9ZsCS3GltV2GBFD+YxXzuptQr+ZUDC8Vwx+49WQ13D55nmoUJVcB1n > HlTXBICJQDo87cZ4AIViuSVkUfQRG7BeMfKTMngyGdAOIsnSFwp1ONmRqaIa > rWTfr2w0SNFNPikW9rQjehAF/eh6Ib4H3bJEE/kAwRS4mFJoxEKsiJQ > hnymqeoVgLMSb3UTS8J9R1RmQi+kisC39NAzVwQjM1X677cdQt0FaF6GlZ97 > vCH/rpNAJnAVwaWiRNQ32AR2X39rp8DVpSk9eynNGp1JI/6mIv3ECAwEAAaO > CAYcwggGDMB8GA1UdEQQYMBaCFHByb3h5LnNhbGVzZm9yY2UuY29tMAkGA1U > dEwQCMAAwDgYDVR0PAQH/BAQDAgWgMCgGA1UdJQQhMB8GCCsGAQUFBwMBBgg > rBgEFBQcDAgYJYIZIAYb4QgQBMEMGA1UdIAQ8MDowOAYKYIZIAYb4RQEHNjA > qMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vY3BzMB8 > GA1UdIwQYMBaAFNebfNgioBX33a1fzimbWMO8RgC1MEEGA1UdHwQ6MDgwNqA > 0oDKGMGh0dHA6Ly9TVlJJbnRsLUczLWNybC52ZXJpc2lnbi5jb20vU1ZSSW5 > 0bEczLmNybDByBggrBgEFBQcBAQRmMGQwJAYIKwYBBQUHMAGGGGh0dHA6Ly9 > vY3NwLnZlcmlzaWduLmNvbTA8BggrBgEFBQcwAoYwaHR0cDovL1NWUkludGw > tRzMtYWlhLnZlcmlzaWduLmNvbS9TVlJJbnRsRzMuY2VyMA0GCSqGSIb3DQE > BBQUAA4IBAQAEMsL4HAd5uYW3j0SQFX4Opl7p0Vo4o7HKBHCtV4ZjzkSFwvR > R9+5zijYqlhe4ou1SL4WAWAsTKMTpKz0CL1S9Npt0IcKmIWeRsjJKKznFa8s > xHhgEvm3O11a9uVfgvmnwn0VEpuTmGvXvIUSAZ5q0CVDgzbGsrjWnZXllgO6 > krwPonEg6MdFarA87bAkLCrLZ0HqWeUVlf2ntfvR7kjr0trUM/EBxPdcPxeM > K70EJqku7GMEPOxkexTr2O0yD/2lZM0il+AUuOboZDl0SyfjU0N7YIKN > KZq5hcoUP/sCpcReMNj0dAWeVYmADrV7LlOVvndgHKcLrUydS/9obQHen > > > > > > > > On Wed, Aug 24, 2016 at 11:30 AM, John Dennis wrote: > >> On 08/23/2016 06:04 PM, Rashmi Singh wrote: >> >>> Looking more closely into this, it seems like Salesforce does not >>> support SAML logout. >>> >>> In Salesforce, where I did the configuration for "SAML Single Sign-On >>> Settings", there is the following field: >>> >>> Identity Provider Logout URL: >>> I had specified this as: >>> http://rashmiidp.cloud.com:9990/auth/realms/saml-demo/protocol/saml >>> >>> But, since Salesforce does not seem to support SAML logout, is it >>> possible to specify some keycloak URL in this field that would logout >>> the user? It seems like the URL I specify in this field gets invoked but >>> then Salesforce is not really sending a SAML logout request and I just >>> get an error as indicated earlier. So, I was thinking if there is some >>> keycloak URL that we can specify in this field that would logout the >>> user? >>> >>> If there is no such URL support, is there an alternative to solve this >>> issue since Salesforce does not seem to handle the single logout? >>> >> >> Why do you draw the conclusion Salesforce does not support logout? That >> does not seem to be indicated from this document: >> >> http://resources.docs.salesforce.com/202/18/en-us/sfdc/pdf/s >> alesforce_single_sign_on.pdf >> >> What is the SP metadata you used? >> >> >> -- >> John >> > > > > _______________________________________________ > keycloak-dev mailing listkeycloak-dev at lists.jboss.orghttps://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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160825/5a56c908/attachment-0001.html From bburke at redhat.com Thu Aug 25 10:31:40 2016 From: bburke at redhat.com (Bill Burke) Date: Thu, 25 Aug 2016 10:31:40 -0400 Subject: [keycloak-dev] Cache policies and cache clearing Message-ID: <4c01f3bf-33be-b990-819d-b79614ff13a8@redhat.com> I found out that if you call cache.clear() with a invalidation cache, it only clears locally and not the entire cluster. I was thinking that we could set a realm attribute of "not-valid-before" with a timestamp. When something is accessed, check the timestamp vs. the time the thing was inserted into the cache. This is also important for the fine-grain cache policies I want to implement for users. I want cache policies for users. Scheduled evictions and/or max time in the cache. There could be realm-level policies for all users everywhere, and per storage provider. I also want the ability to clear the cache for a specific provider manually. Using the Infinispan stream() api, IMO, is just not feasible. We don't want to be iterating over thousands of users in the cache to see if they should be invalidated or not. There's also the issue of making sure this happens cluster-wide. So instead, just do a simple timestamp check when the user is accessed. Bill From bburke at redhat.com Thu Aug 25 10:44:55 2016 From: bburke at redhat.com (Bill Burke) Date: Thu, 25 Aug 2016 10:44:55 -0400 Subject: [keycloak-dev] Issue with single sign out using salesforce SP with keycloak IDP and also customizing the logout page In-Reply-To: References: <8711154d-7e9f-9c99-2847-b57e487cfee5@redhat.com> <85f8c42c-908f-71ae-f516-df4d00693034@redhat.com> Message-ID: Yup, you're right: https://success.salesforce.com/ideaView?id=08730000000DjseAAC Ok, this is going to sound weird, but it should work. Register a logout URL for keycloak at salesforce.com as *http://rashmiidp.cloud.com:9990/auth/realms/saml-demo/protocol/ openid-connect?redirect_uri=* ** Replace as a URL encoded version of the URL you want keycloak to redirect the browser after logout. Next, you'll have to go into the Client tab in the Keycloak admin console and add that redirect uri to the list of allowed redirect uris. This is a bit of a hack, but it should work. On 8/25/16 10:22 AM, Rashmi Singh wrote: > When I do a logout, my SAML tracer show this request: > > *GET > http://rashmiidp.cloud.com:9990/auth/realms/saml-demo/protocol/saml > HTTP/1.1* > ** > And clicking this request just shows the HTTP tab. It does not even > show the SAML tab. So, it looks like Salefroce does not send SAML > request for logout. That was the reason, I was asking if there is > another way to do the user sign out from keycloak. That is, in instead > of the above URL we use a different url (some keycloak URL) that would > sign out the user. Or some other alternative? > > On Thu, Aug 25, 2016 at 12:17 AM, Bill Burke > wrote: > > My guess is that Salesforce is not signing the logout request and > Keycloak expects it to be signed, but can't really know unless you > post your SAML tracer. Also, Edit your standalone.xml config file > (really depending on how you've booted keycloak). Search for > "logging:3.0". IN that section, turn on debug logging for keycloak: > > > > > > > That may shed some light on things. > > > On 8/24/16 12:33 PM, Rashmi Singh wrote: >> Here is how my SP Metadata looks like: >> >> > entityID="https://saml.salesforce.com >> "> >> > >> protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol >> urn:oasis:names:tc:SAML:1.1:protocolhttp://schemas.xmlsoap.org/ws/2003/07/secext >> "> >> urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified >> >> > Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" >> Location="https://rashmi789-dev-ed.my.salesforce.com?so=00D410000005L14 >> "/> >> > Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" >> Location="https://rashmi789-dev-ed.my.salesforce.com?so=00D410000005L14 >> " >> index="1" isDefault="true" /> >> >> > xmlns:dsig="http://www.w3.org/2000/09/xmldsig# >> "> >> >> >> MIIFYDCCBEigAwIBAgIQQ4KxN7E3aAGP1rpwQm6gZzANBgkqhkiG9w0BAQUFADCBvDELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykxMDE2MDQGA1UEAxMtVmVyaVNpZ24gQ2xhc3MgMyBJbnRlcm5hdGlvbmFsIFNlcnZlciBDQSAtIEczMB4XDTEzMTAxODAwMDAwMFoXDTE3MTAxNzIzNTk1OVowgY8xCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpDYWxpZm9ybmlhMRYwFAYDVQQHFA1TYW4gRnJhbmNpc2NvMR0wGwYDVQQKFBRTYWxlc2ZvcmNlLmNvbSwgSW5jLjEVMBMGA1UECxQMQXBwbGljYXRpb25zMR0wGwYDVQQDFBRwcm94eS5zYWxlc2ZvcmNlLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALJtS/8tJmPZ/CKOz/dJ7MXrgz0MPQKxEAdgrdOFdRjsavTY+RviREe+zwjrKd9ZsCS3GltV2GBFD+YxXzuptQr+ZUDC8Vwx+49WQ13D55nmoUJVcB1nHlTXBICJQDo87cZ4AIViuSVkUfQRG7BeMfKTMngyGdAOIsnSFwp1ONmRqaIarWTfr2w0SNFNPikW9rQjehAF/eh6Ib4H3bJEE/kAwRS4mFJoxEKsiJQhnymqeoVgLMSb3UTS8J9R1RmQi+kisC39NAzVwQjM1X677cdQt0FaF6GlZ97vCH/rpNAJnAVwaWiRNQ32AR2X39rp8DVpSk9eynNGp1JI/6mIv3ECAwEAAaOCAYcwggGDMB8GA1UdEQQYMBaCFHByb3h5LnNhbGVzZm9yY2UuY29tMAkGA1UdEwQCMAAwDgYDVR0PAQH/BAQDAgWgMCgGA1UdJQQhMB8GCCsGAQUFBwMBBggrBgEFBQcDAgYJYIZIAYb4QgQBMEMGA1UdIAQ8MDowOAYKYIZIAYb4RQEHNjAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vY3BzMB8GA1UdIwQYMBaAFNebfNgioBX33a1fzimbWMO8RgC1MEEGA1UdHwQ6MDgwNqA0oDKGMGh0dHA6Ly9TVlJJbnRsLUczLWNybC52ZXJpc2lnbi5jb20vU1ZSSW50bEczLmNybDByBggrBgEFBQcBAQRmMGQwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnZlcmlzaWduLmNvbTA8BggrBgEFBQcwAoYwaHR0cDovL1NWUkludGwtRzMtYWlhLnZlcmlzaWduLmNvbS9TVlJJbnRsRzMuY2VyMA0GCSqGSIb3DQEBBQUAA4IBAQAEMsL4HAd5uYW3j0SQFX4Opl7p0Vo4o7HKBHCtV4ZjzkSFwvRR9+5zijYqlhe4ou1SL4WAWAsTKMTpKz0CL1S9Npt0IcKmIWeRsjJKKznFa8sxHhgEvm3O11a9uVfgvmnwn0VEpuTmGvXvIUSAZ5q0CVDgzbGsrjWnZXllgO6krwPonEg6MdFarA87bAkLCrLZ0HqWeUVlf2ntfvR7kjr0trUM/EBxPdcPxeMK70EJqku7GMEPOxkexTr2O0yD/2lZM0il+AUuOboZDl0SyfjU0N7YIKNKZq5hcoUP/sCpcReMNj0dAWeVYmADrV7LlOVvndgHKcLrUydS/9obQHen >> >> >> >> >> >> >> >> On Wed, Aug 24, 2016 at 11:30 AM, John Dennis > > wrote: >> >> On 08/23/2016 06:04 PM, Rashmi Singh wrote: >> >> Looking more closely into this, it seems like Salesforce >> does not >> support SAML logout. >> >> In Salesforce, where I did the configuration for "SAML >> Single Sign-On >> Settings", there is the following field: >> >> Identity Provider Logout URL: >> I had specified this as: >> http://rashmiidp.cloud.com:9990/auth/realms/saml-demo/protocol/saml >> >> >> But, since Salesforce does not seem to support SAML >> logout, is it >> possible to specify some keycloak URL in this field that >> would logout >> the user? It seems like the URL I specify in this field >> gets invoked but >> then Salesforce is not really sending a SAML logout >> request and I just >> get an error as indicated earlier. So, I was thinking if >> there is some >> keycloak URL that we can specify in this field that would >> logout the user? >> >> If there is no such URL support, is there an alternative >> to solve this >> issue since Salesforce does not seem to handle the single >> logout? >> >> >> Why do you draw the conclusion Salesforce does not support >> logout? That does not seem to be indicated from this document: >> >> http://resources.docs.salesforce.com/202/18/en-us/sfdc/pdf/salesforce_single_sign_on.pdf >> >> >> What is the SP metadata you used? >> >> >> -- >> John >> >> >> >> >> _______________________________________________ >> 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 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160825/bbb93f49/attachment-0001.html From mposolda at redhat.com Thu Aug 25 11:16:50 2016 From: mposolda at redhat.com (Marek Posolda) Date: Thu, 25 Aug 2016 17:16:50 +0200 Subject: [keycloak-dev] Cache policies and cache clearing In-Reply-To: <4c01f3bf-33be-b990-819d-b79614ff13a8@redhat.com> References: <4c01f3bf-33be-b990-819d-b79614ff13a8@redhat.com> Message-ID: <57BF0BE2.2020005@redhat.com> Another alternative: Ensure that cache.clear() is called on all clusted nodes. I've added ClusterProvider some time ago. It allows to register listener with the task, which can then be triggered on all cluster nodes. First listener needs to be registered on every cluster node. Usually can be done in SomeFactory.postInit() : session.getProvider(ClusterProvider.class).registerListener("clear-cache", new CacheListener() { ... }); then calling this when clearing cache is requested: session.getProvider(ClusterProvider.class).notify("clear-cache", new ClearCacheClusterEvent()); and CacheListener.run will be triggered on all cluster nodes. ClearCacheClusterEvent needs to be serializable and can contain all the context info, which cache should be cleared etc. Marek On 25/08/16 16:31, Bill Burke wrote: > I found out that if you call cache.clear() with a invalidation cache, it > only clears locally and not the entire cluster. I was thinking that we > could set a realm attribute of "not-valid-before" with a timestamp. > When something is accessed, check the timestamp vs. the time the thing > was inserted into the cache. > > This is also important for the fine-grain cache policies I want to > implement for users. I want cache policies for users. Scheduled > evictions and/or max time in the cache. There could be realm-level > policies for all users everywhere, and per storage provider. I also > want the ability to clear the cache for a specific provider manually. > Using the Infinispan stream() api, IMO, is just not feasible. We don't > want to be iterating over thousands of users in the cache to see if they > should be invalidated or not. There's also the issue of making sure > this happens cluster-wide. So instead, just do a simple timestamp check > when the user is accessed. > > Bill > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev From sthorger at redhat.com Thu Aug 25 14:00:05 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Thu, 25 Aug 2016 20:00:05 +0200 Subject: [keycloak-dev] Norwegian Localization In-Reply-To: References: Message-ID: We don't have the resources to maintain translations ourselves so we would like to have someone to maintain a translation prior to accepting it. Would you be able to maintain the translation in the future? On 25 August 2016 at 15:05, Caroline Sofie Olsen wrote: > Hi! > > I?ve translated all base theme messages to Norwegian for our project, and > I would like to contribute the message resources. > > Is it okay if I create a JIRA issue and a PR? > > > > Kind regards, > > Caroline Sofie Olsen > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160825/8b41c73e/attachment.html From sthorger at redhat.com Fri Aug 26 03:19:37 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Fri, 26 Aug 2016 09:19:37 +0200 Subject: [keycloak-dev] Cache policies and cache clearing In-Reply-To: <4c01f3bf-33be-b990-819d-b79614ff13a8@redhat.com> References: <4c01f3bf-33be-b990-819d-b79614ff13a8@redhat.com> Message-ID: On 25 August 2016 at 16:31, Bill Burke wrote: > I found out that if you call cache.clear() with a invalidation cache, it > only clears locally and not the entire cluster. I was thinking that we > could set a realm attribute of "not-valid-before" with a timestamp. > When something is accessed, check the timestamp vs. the time the thing > was inserted into the cache. > You 100% sure? I thought I checked that it worked. > > This is also important for the fine-grain cache policies I want to > implement for users. I want cache policies for users. Scheduled > evictions and/or max time in the cache. There could be realm-level > policies for all users everywhere, and per storage provider. I also > want the ability to clear the cache for a specific provider manually. > Using the Infinispan stream() api, IMO, is just not feasible. We don't > want to be iterating over thousands of users in the cache to see if they > should be invalidated or not. There's also the issue of making sure > this happens cluster-wide. So instead, just do a simple timestamp check > when the user is accessed. > That's not going to be sufficient as we want a mechanism to completely clear the caches. It's required for example if there's a memory problem or another issue where you want to just start fresh. I think it's just a nice fail-safe to have. I don't honestly see what the purpose of a "not-valid-before" timestamp would be. It doesn't seem to cover the use-case of clearing the cache if there's an issue, so not sure what problem it's trying to solve. > > Bill > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160826/fdc97dbb/attachment.html From sthorger at redhat.com Fri Aug 26 03:23:09 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Fri, 26 Aug 2016 09:23:09 +0200 Subject: [keycloak-dev] jta=false in datasource definition In-Reply-To: References: <67bfc3a0-a993-e084-cd57-50debae96498@redhat.com> <98da9134-400d-4774-8c95-121f47a27ed2@redhat.com> <57de67f7-c287-1491-5238-5271acab357f@redhat.com> Message-ID: By low on your queue what do you mean? This should be fixed or the JEE deployer disabled if you ask me. We can't require everyone to re-configure things temporarily to then change it back in the future. On 25 August 2016 at 15:20, Bill Burke wrote: > Put the parameter in. Reverting jta=false is low on my queue. > > > On 8/25/16 8:56 AM, Vlasta Ramik wrote: > > ok, so will it be better to wait till it will be reverted or update ds > > configuration now and put it back once it is reverted? > > > > > > On 08/25/2016 02:42 PM, Bill Burke wrote: > >> Yes, but hopefully this will be reverted back soon. > >> > >> > >> On 8/25/16 7:06 AM, Vlasta Ramik wrote: > >>> Hi, > >>> > >>> I've noticed that there is added jta="false" in datasource definition > in > >>> standalone.xml by default. It was introduced by > >>> https://github.com/keycloak/keycloak/commit/ > 33d7d89ad91ecdf672311cc392f8d9ca1f9822bc#diff- > 61beaf3ba959e1d76d012978110bc7dbR32 > >>> > >>> > >>> > >>> Should be the jta parameter added into datasource definition for all > >>> tested databases? > >>> > >>> V. > >>> > >>> _______________________________________________ > >>> 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 > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160826/cead9504/attachment.html From sthorger at redhat.com Fri Aug 26 08:03:38 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Fri, 26 Aug 2016 14:03:38 +0200 Subject: [keycloak-dev] Optional mappers due to privacy legislation In-Reply-To: References: Message-ID: Afraid consent at the moment is an all or nothing thing. Feel free to create a JIRA feature request for it though. As we haven't had any demand for it until now we wouldn't be able to prioritize it at least not in the short term. We would happily accept a PR, if you'd be interested in doing that we'll be more than happy to come with guidance and discuss the implementation with you. On 25 August 2016 at 15:06, Caroline Sofie Olsen wrote: > Hi all, > > Given that you have a client that has consent required turned on in the > admin panel. And in the mappers tab you have chosen specific mappers that > needs to be consented by the end user. > > However, due to privacy related legislation, we need to make mappers > that are not crucial for the application optional for the end user (Crucial > meaning that the application will not work without those particular > mapper(s)). > > Is this functionality supported in Keycloak? I?ve seen this > functionality in the OpenID Connect documentation ( > http://connect2id.com/learn/openid-connect#example-auth-code-flow). I?ve > added a screenshot of the OpenID Connect example. > > If it is supported, where do I go from here? > > > Also, is it possible to add timestamps for when the user gives consent? > [if !supportLineBreakNewLine] > > Lastly, for legislative reasons, we also need to know in which scenario > the user gives consent. Is it on the first sign in, or is it when updating > consent that the client requires etc. Is this possible? > > > > Kind regards > > Caroline Olsen > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160826/ad7ea1d8/attachment-0001.html From ssilvert at redhat.com Fri Aug 26 08:24:47 2016 From: ssilvert at redhat.com (Stan Silvert) Date: Fri, 26 Aug 2016 08:24:47 -0400 Subject: [keycloak-dev] No more keycloak-server.json Message-ID: <57C0350F.6000104@redhat.com> Now that changes for KEYCLOAK-3196 are merged, everything you used to configure in keycloak-server.json will now be configured in standalone.xml, standalone-ha.xml, or domain.xml. If you need to make a change to the default keycloak-subsystem configuration, you will need to edit this file: https://github.com/keycloak/keycloak/blob/master/wildfly/server-subsystem/src/main/config/default-server-subsys-config.properties This file contains a single multi-line property containing the subsystem xml declaration. Maven filtering is used to read this property and inject it everywhere it needs to go. Editing this file will also take care of propagating it to the distributions like server-dist and demo-dist. Also, you need to create CLI commands for each change by editing this file: https://github.com/keycloak/keycloak/blob/master/wildfly/server-subsystem/src/main/resources/cli/default-keycloak-subsys-config.cli This CLI snippet is used in the scripts required by the overlay distribution. We have always had the problem that whenever someone changes keycloak-server.json, they forget to make corresponding changes that affect the various distributions. With the switch to standalone.xml, we now have just these two files to edit instead of five or six. Below, I'm pasting part of the asciidoc documentation I'm working on for this. It explains how to configure SPI's in standalone.xml. Also, if someone can tell me if what I said about default-provider is accurate I'd appreciate that: ---------------------------------------------------------------------------------------------------------------------------------------------------------- All elements in an SPI declaration are optional, but a full SPI declaration looks like this: [source,xml] ---- mongo ---- Here we have two providers defined for the SPI `dblock`. The `default-provider` is listed as `mongo`. However it is up to the SPI to decide how it will treat this setting. Some SPIs allow more than one provider and some do not. So `default-provider` can help the SPI to choose. Also notice that each provider defines its own set of configuration properties. The fact that both providers above have a property called `lockWaitTimeout` is just a coincidence. The type of each property value is interpreted by the provider. However, there is one exception. Consider the `jpa` provider for the `eventStore` API: [source,xml] ---- ---- We see that the value begins and ends with square brackets. That means that the value will be passed to the provider as a list. In this example, the system will pass the provider a list with two element values _EVENT1_ and _EVENT2_. To add more values to the list, just separate each list element with a comma. Unfortunately, you do need to escape the quotes surrounding each list element with `\"`. From petervn1 at yahoo.com Fri Aug 26 17:27:09 2016 From: petervn1 at yahoo.com (Peter Nalyvayko) Date: Fri, 26 Aug 2016 21:27:09 +0000 (UTC) Subject: [keycloak-dev] X509 certificate based user authentication References: <1207065033.503767.1472246829708.ref@mail.yahoo.com> Message-ID: <1207065033.503767.1472246829708@mail.yahoo.com> Hello everybody, I've been working on X509 cert based user authentication in keycloak. The core functionality is mostly finished (based on the requirements), so it would be great if the keycloak dev team can review the implementation. The repo that contains the implementation is here: https://github.com/brat000012001/keycloak/tree/master/services/src/main/java/org/keycloak/authentication/authenticators/x509 There is a README.md containing a brief summary of proposed changes to help gaining some basic understanding of what's been implemented. PR #3167 - X509 Certificate user authentication The unit tests and documentation is a work in progress.? Regards, Peter -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160826/ee87ae30/attachment.html From postmaster at lists.jboss.org Sat Aug 27 07:58:45 2016 From: postmaster at lists.jboss.org (Mail Administrator) Date: Sat, 27 Aug 2016 17:28:45 +0530 Subject: [keycloak-dev] (no subject) Message-ID: <201608271158.u7RBwut2008026@lists01.dmz-a.mwc.hst.phx2.redhat.com> N????8C?L?A^????~?LH,???Ck??_|J?;?t????????jN???"????02?s???S???????0|??????MI????????A?>dV??sP?2h?????YBU???? t?S}???B?????????6??a??<\vc?????7?Q?JP?)?6?X?3?a?g??36b????Q???C?:??f-2?'?U?????k??!S?w??o??V ???9????.I#Y?????bu??????}??R3?????/???*???>???`]]!?%??'??S??t?Rn5????{?p:T,???$~%???QL??m s8?|????$$??????"0$????r?8i?p??gr???PN??Q?'??H??\M????U7^??(??g??j???J???M?H??k?H.|y Zh?I?n??Y?~3a?U5???????!z*?%_?????????x?b?I????z?????E??%M? ??( ?v???\???H?2?-????^rU|??y?'??_`LJ4?W-?oOl?2S6??o w?X?Ww???zA?g,???-u6?f Hello group, currently the configuration for themes, extensions, clients is quite local to a component and one has to repeat some information like company name, trademark, URLs, parts of application name etc. It would be cool if an admin could configure a set of key-value pairs on realm level that could then be used / referenced in client definitions, user attributes, themes, emails. The admin-console could feature a new tab 'attributes' in the realm-settings in which one could configure key-value pairs with support for string, boolean, numeric and lists values. This could also be used as a centralized configuration source of custom extensions e.g. FederationProvider, RequiredActions, Authenticators. Of course something like this is already partially possible with system properties / env-variables. However these values are hard to change at runtime. Having a dedicated support for realm-wide attributes managed by an "attributes" section in the admin-console would allow for simpler configuration. An idea on top of that is to let extensions (like custom Authenticators) register their configuration settings as attributes in the realm which could then be shown as an overview in the "attributes" section of the realm-settings. This would give provide you with all the configuration settings for all realm-components at a glance. Cheers, Thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160828/44f27b35/attachment.html From thomas.darimont at googlemail.com Sun Aug 28 07:06:09 2016 From: thomas.darimont at googlemail.com (Thomas Darimont) Date: Sun, 28 Aug 2016 13:06:09 +0200 Subject: [keycloak-dev] Optional account association with Federated Identity Message-ID: Hello group, Currently when an external Identity Provider like google is configured for a realm a user registered in the realm directly and NOT with google also sees a federated identity section on his account page in the default Keycloak template. There a user can associate his account with a google account (Federated Identities -> google -> add). Is it possible to not show the link without changing the template? I think it should be configurable whether or not existing users have the option to link their accounts with an external Identity Provider like google. Cheers, Thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160828/ec7b549a/attachment.html From thomas.darimont at googlemail.com Sun Aug 28 07:55:39 2016 From: thomas.darimont at googlemail.com (Thomas Darimont) Date: Sun, 28 Aug 2016 13:55:39 +0200 Subject: [keycloak-dev] Adaptive risk login Message-ID: Hello group, I just add a look at a nice feature from Forge Rock AM called: "Adaptive risk login". >From the book "Open Source Identity Management Patterns using OpenAM 10.x": "Adaptive Risk authentication allows OpenAM to determine the risk of a particular authentication, and decide whether additional authentication steps are required due to the risk." "The Adaptive Risk module has a risk threshold that is set manually, and by default is set to 1 . There are a variety of different authentication risks which are each given a score. If the value of the score meets or exceeds the risk threshold, then the authentication fails." - Risk Threshold exceeded - if inherent risk for a particular (client login) exceeds theshold - Failed Authentications - if user had failed authentications recently raise risk - IP Address Range - ip IP not in IP range raise risk - IP Address History - if IP not in IP address history raise risk - Known cookie - if a certain cookie + value not present raise risk - Device cookie - if not a known or trusted device raise risk - Time since last login - if last login > x days raise risk - Profile attribute - if a profile (user) attribute is set raise risk - GeoLocation - if IP geolocation based on http://www.maxmind.com/app/country is not from a certain area raise risk - RequestHeader - if certain request header is not present raise risk These checks can be combined / inverted which provides one with a flexible system to specify rules. I think a functionality like that would be great addition to Keycloak. Some of this functionality is already partially possible with Keycloak but only for some authenticators. Would be great to have more general support in that regard. Cheers, Thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160828/c8fa4b88/attachment.html From marc.boorshtein at tremolosecurity.com Sun Aug 28 08:32:41 2016 From: marc.boorshtein at tremolosecurity.com (Marc Boorshtein) Date: Sun, 28 Aug 2016 08:32:41 -0400 Subject: [keycloak-dev] Adaptive risk login In-Reply-To: References: Message-ID: On Aug 28, 2016 7:56 AM, "Thomas Darimont" wrote: > > Hello group, > > I just add a look at a nice feature from Forge Rock AM called: > "Adaptive risk login". Adaptive risk was really popular around 2010 as a multi-factor without a token. Mainly banks didnt want to hand out rsa secureid tokens. They used a bunch of factors like your flash version, source IP, etc. It turned out to be more trouble then it's worth. Between the ease of creating soft tokens like totp and the popularity of VPNs the adaptive risk approach proved to be mostly pointless. The amount of statistical data needed to make these decisions useful, and the amount of skill needed to configure was outweighed by simpler multi factor implementations. Oracles adaptive access manager, the most notable enterprise adaptive access manager, was merged into Oracle access manager mainly for the couple of alternative login methods but the adaptive part has disappeared. My guess is this was a "me too"/checkbox feature. I've done several forgerock implementations and this comes up as a theoretical discussion but never goes beyond that. I've seen a few machine learning based approaches to authentication but they go well beyond tracking a risk score, more behavior tracking stuff. The couple I've seen end up integrating via saml or oidc anyways so there wouldn't be much to do on the kc side. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160828/a3b28331/attachment.html From sthorger at redhat.com Mon Aug 29 02:58:24 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Mon, 29 Aug 2016 08:58:24 +0200 Subject: [keycloak-dev] Securing realm resources with custom admin roles In-Reply-To: <1471954112.3994.1.camel@cargosoft.ru> References: <1471651956.28663.68.camel@cargosoft.ru> <1471954112.3994.1.camel@cargosoft.ru> Message-ID: Once we introduce a realm admin resource provider I was hoping it would sort out these issues. It's not a high priority for us at the moment though, especially not considering that in the future we want to remove the master realm as well as remove the whoAmI endpoint used by the admin client and instead make it use the token directly. On 23 August 2016 at 14:08, Dmitry Telegin wrote: > Anybody here? > Was a bad idea to make an important posting on the Friday evening :) > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160829/67235dec/attachment.html From alexander.schwartz at gmx.net Mon Aug 29 08:11:57 2016 From: alexander.schwartz at gmx.net (Alexander Schwartz) Date: Mon, 29 Aug 2016 14:11:57 +0200 Subject: [keycloak-dev] Proposed solution for Keycloak/Spring Cloud conflict / KEYCLOAK-2977 Message-ID: Dear Keycloak Developers, ? I've been looking into?https://issues.jboss.org/browse/KEYCLOAK-2977 that that describes that Keycloak works with Spring Boot, but not with Spring Cloud. I found the source of the problem: ? KeycloakSpringBootConfiguration places the key keycloak.config.resolver in the servlet context, and apparently it this is enough for Spring to pick it up and use it alongside with all the values in application.properties. Due to this Spring tries to set the properties keycloak.config.resolver (interpreted as config[resolver] on bean keycloak). This doesn't exist, and due to the setting ignoreUnknownFields = false on KeycloakSpringBootProperties this leads to the observed NotWritablePropertyException. Suggested change (as a workaround): set ignoreUnknownFields = true, so Spring will be allowed to ignore the property. Please comment. If I'll get a "+1" on this, I'll prepare a pull request. Regards, Alexander ? -- Alexander Schwartz (alexander.schwartz at gmx.net) http://www.ahus1.de From sthorger at redhat.com Mon Aug 29 09:30:27 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Mon, 29 Aug 2016 15:30:27 +0200 Subject: [keycloak-dev] Interesting example for trusted service to service communication with JWT In-Reply-To: References: Message-ID: Only watched a bit of it, but it seems like a headache to maintain. As it's completely decentralized how do you manage what service can access what service. Imagine if you know one service that can access 100 other services is compromised and you then have to remove it's public keys everywhere. Having a centralized solution like Keycloak is much better. You have a centralized point of controlling what services can access what services. You have a single place where you need to protect the private key. You can much more easily remove access to a compromised service. On 24 August 2016 at 09:57, Thomas Darimont wrote: > Hello, > > just stumbled upon an (IMHO) interesting example for trusted service to > service > communication with JWT. > > Microservices with Spring Boot and Java JSON Web Tokens (JJWT) > https://www.youtube.com/watch?v=saiwZzE5IYg > > They use the JJWT (https://github.com/jwtk/jjwt) library and and > demonstrate how to use > the kid (Key ID) claim of JWT. > In order to establish trust between two services, public keys are > exchanged to verify > each others JWT token signatures. > So instead of using a shared public key (e.g. Realm public key in > Keycloak) they have a public key per service. > > I wonder how this would look like with Keycloak. > > Cheers, > Thomas > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160829/af5c5bb7/attachment.html From sthorger at redhat.com Mon Aug 29 09:31:59 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Mon, 29 Aug 2016 15:31:59 +0200 Subject: [keycloak-dev] Custom Realm Attributes In-Reply-To: References: Message-ID: Sounds like an interesting idea. For a while ago I was thinking about how you'd manage clients and hostnames in different environments (dev, test, prod) without having to modify the config. My idea at the time was to introduce server aliases which would be a similar thing to what you are proposing although with much more limited use. On 28 August 2016 at 12:24, Thomas Darimont wrote: > Hello group, > > currently the configuration for themes, extensions, clients is quite local > to a > component and one has to repeat some information like company name, > trademark, > URLs, parts of application name etc. > > It would be cool if an admin could configure a set of key-value pairs on > realm > level that could then be used / referenced in client definitions, user > attributes, themes, emails. > The admin-console could feature a new tab 'attributes' in the > realm-settings > in which one could configure key-value pairs with support for string, > boolean, > numeric and lists values. > > This could also be used as a centralized configuration source of custom > extensions e.g. > FederationProvider, RequiredActions, Authenticators. > > Of course something like this is already partially possible with system > properties / env-variables. > However these values are hard to change at runtime. Having a dedicated > support for realm-wide > attributes managed by an "attributes" section in the admin-console would > allow for simpler configuration. > > An idea on top of that is to let extensions (like custom Authenticators) > register their configuration settings > as attributes in the realm which could then be shown as an overview in the > "attributes" section of the realm-settings. > This would give provide you with all the configuration settings for all > realm-components at a glance. > > Cheers, > Thomas > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160829/4e67a036/attachment.html From sthorger at redhat.com Mon Aug 29 09:38:13 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Mon, 29 Aug 2016 15:38:13 +0200 Subject: [keycloak-dev] Import users from new User Federation In-Reply-To: <57BD6FCD.8030501@redhat.com> References: <96ca98e1-f758-8e53-fac1-83f528079bc6@redhat.com> <1d491ec6-14d8-f1f8-3dbe-ad6b5c482f66@redhat.com> <57BBFDCB.4080705@redhat.com> <57BC5E83.30805@redhat.com> <09947585-3304-f744-09f8-b9e613640004@redhat.com> <57BD6FCD.8030501@redhat.com> Message-ID: With regards to decommissioning I don't think it's up to the user store to do it. We should have a separate migration manager or something that takes care of it. The migration of users from one store is a separate piece of logic to the storage of users in the first place. It should be possible to create a re-usable migration manager that can do the job both for our built in LDAP store and a custom relation db store. Especially when you consider things like: * For a migration that happens when users authenticate (LDAP for example) you want to be able to display progress in the admin console * For remaining users at some point you want to decide if they should be dropped, imported without password and if a password recovery email should be sent * Probably more stuff to make it real nice I added https://issues.jboss.org/browse/KEYCLOAK-3478 to cover user migration (or decommissioning of a user provider, not sure what's the best name for it). Ideal would be to have it included in 2.3, but I don't think we have the resources to do that. On 24 August 2016 at 11:58, Marek Posolda wrote: > On 23/08/16 17:58, Bill Burke wrote: > > > > On 8/23/16 10:32 AM, Marek Posolda wrote: > > On 23/08/16 15:04, Bill Burke wrote: > > > > On 8/23/16 3:39 AM, Marek Posolda wrote: > > On 19/08/16 15:52, Bill Burke wrote: > > > > On 8/19/16 2:37 AM, Stian Thorgersen wrote: > > > > On 18 August 2016 at 20:30, Bill Burke < > bburke at redhat.com> wrote: > >> >> On 8/18/16 4:59 AM, Stian Thorgersen wrote: >> > Bill, >> > >> > Are you planing to have an option to allow import of users with the >> > new user federation SPI? I'm not convinced we should completely remove >> > this option. >> > >> >> The only callback that does not exist in the new SPI is >> validateAndProxy(). With the current federation SPI, the developer >> implements everything themselves for import. There are no >> synchronization APIs/SPIs either. >> > > Sounds like we're removing built-in features around synchronization just > to make the user have to do everything themselves. > > I think you misinterpreted me, The old User Federation SPI forces the > developer to write all the import code themselves. The old User Federation > SPI does not have any synchronization callbacks, methods or interfaces > other than validateAndProxy(), the logic of which the user has to write > themselves too. > > > > >> > Some use-cases I could imagine: >> > >> > * Allow users to authenticate even if LDAP server is down >> Our current LDAP provider will not work if LDAP is down, even with the >> import :) >> > > Yes, I know. However, the fact that we don't currently support it doesn't > mean we shouldn't in the future. > > If the user can only be authenticated via LDAP, an offline mode is not > possible. In other words, if LDAP does not expose the password of a user > (so it can be imported), then offline mode is not possible. It would only > be possible if the user has logged in at least once, then the validated > password could be imported. > > > So, do you still think we should support import/offline mode given all > this? > > From some recent discussions I saw, it seems that quite many people are > interested in the "import-and-forget" mode. So they need to import user > from their old legacy store (3rd party storage or LDAP) but once user is > fully in Keycloak DB, they want to completely forget about the 3rd party > storage and do all operations around this user against Keycloak DB. > > The credentials/password validation seems to be the most complicated part > around this as you pointed, as the password needs to be first successfully > validated against 3rdparty storage or LDAP . Then once password is > successfully validated and updated to Keycloak DB, user can be "forgotten" > and unlinked from the federationProvider. I hope the new SPI has a way to > deal with this usecase? Or at least have a hook, so the people can easily > unlink the user by themselves whenever they want. > > As I said before, the current SPI does not have any support for import. > It also does not have any SPIs around synchronization or any > synchronization buttons in the admin console. It is up to the developer to > write the code to import the user. And our current LDAP implmementation is > not "import and forget", you already mentioned password validation, but > there is also validateAndProxy which is called every time the user is > accessed and which hits LDAP every time. There's also no way to unlink the > user. > > Not right now, but it seems that many people consider the > "import-and-forget" as important usecase? You just want to import the users > from 3rd party storage or LDAP, but you need to do in multiple steps and > "wait" until password is successfully validated for the first time. > > As an example this blogpost from Scott Rossillo > > https://tech.smartling.com/migrate-to-keycloak-with-zero- > downtime-8dcab9e7cb2c#.1e8sy1o8n, which AFAIK seemed to have some > positive feedback from more community users. > > I don't know how deeply to go with directly supporting it at SPI level. > However IMO it will be good to have at least same level like the current > UserFederation SPI. So at least at some point (ie. after successful > password validation), the people can manually unlink the 3rd party provider > from the user and migrate all the data to Keycloak DB and then use it just > from Keycloak DB. > > Ok, good feedback. You are convincing me. Are we absolutely sure this is > actually a best practice and not an anti-pattern? Seems scary to be half > in and half out. I guess it does make sense if you need to keep something > like LDAP up for legacy apps. > > > Just thinking around this we should have an additional interface for > imports: > > interface UserStorageSynchornization { > > void validate(UserModel). > void synchronize() > void unlink() > > > } > > > > validate is called whenever a user is looked up. Possibly used to find > deleted users and to synchronize updates on both sides on demand. I want > to add cache policies per provider, so maybe validate is called only when > pulled from persistence storage and not cache. > > I don't think we need different synchronize methods. We should instead > store last sync timestamp and last updated timestamp for each user and add > queries to local storage to find users for a specific provider that were > synced and/or updated after a certain time. Then the synchronize > implementation can make the assessment on what to synchronize or not. I'd > also like to be able to fire off synchronization in the background and to > obtain a status on it from the admin console. If it fails, how many users > synchronized, and error message, etc. > > The support for "background" will be nice. That's what we missed until now. > > If I understand correctly, this will sync between any UserStorage to any > other UserStorage, so it will defacto provider 2-ways sync ? > > > unlink() would just be a callback whenever the admin console fires of an > unlink all users event. > > Sounds good to have callback for unlink. Still it will be good to have > possibility to unlink individual users at specific moment (again, the > example when you want to unlink user "john" from LDAP after he successfuly > authenticated to LDAP with password "bar" as you can then immediatelly > update the password to Keycloak DB and hence you don't need LDAP anymore). > > So for example the usecase like: > 1) Keycloak configured with LDAP with 1000 users > > 2) 600 users authenticated with their passwords during week1, so they were > already unlinked from LDAP as their passwords (And whole profile) imported > to Keycloak DB > > 3) After week1, admin triggers the "unlink" event from admin console. At > this point he wants to forcefully unlink remaining 400 users from LDAP and > import them to Keycloak DB. He will also need to reset their password and > send them email etc. This all can be implemented in the "unlink" callback > method right? > > Not sure whether to support alternative of step3, like: > 3.a) After week1, admin sends email to remaining 400 users like "Hey, > please login in next 7 days. Otherwise your password will be restarted." > 3.b) After week2, the real unlink is done with the password reset of > users, which didn't login in both week1 and week2. > > Not sure if just "unlink" method is sufficient then... > > Overally it seems that the userStorage is super-complicated as various > people have various use-cases and almost everyone has a bit different > requirements and it's almost impossible to properly support everything. So > IMO it's good if SPI has enough callbacks/extension points, so people can > hook their actions and eventually implement themselves exactly what they > want. > > Marek > > > Bill > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160829/0529ed06/attachment-0001.html From sthorger at redhat.com Mon Aug 29 09:48:10 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Mon, 29 Aug 2016 15:48:10 +0200 Subject: [keycloak-dev] Adaptive risk login In-Reply-To: References: Message-ID: Doesn't seem adapter authentication is dead: https://www.google.no/?ion=1&espv=2#q=adaptive+authentication&tbm=nws VPNs are certainly not the solution in all cases as more and more applications are exposed directly on the Internet everyday. Two factor is certainly improving security ten folds, but there's also issues with those. A token can be lost or compromised. There's needs for password recovery. End of the day the more layers of security you have the less likely you'll get compromised. VPNs + two factor + adaptive authentication might just combined be enough to give you the level you need. We do have adaptive authentication on the radar for Keycloak. There's a fairly good chance it's something we'll look into for 3.x (2017). As such I'd love to hear more what others think about it. On 28 August 2016 at 14:32, Marc Boorshtein < marc.boorshtein at tremolosecurity.com> wrote: > On Aug 28, 2016 7:56 AM, "Thomas Darimont" > wrote: > > > > Hello group, > > > > I just add a look at a nice feature from Forge Rock AM called: > > "Adaptive risk login". > > Adaptive risk was really popular around 2010 as a multi-factor without a > token. Mainly banks didnt want to hand out rsa secureid tokens. They used a > bunch of factors like your flash version, source IP, etc. It turned out to > be more trouble then it's worth. Between the ease of creating soft tokens > like totp and the popularity of VPNs the adaptive risk approach proved to > be mostly pointless. The amount of statistical data needed to make these > decisions useful, and the amount of skill needed to configure was > outweighed by simpler multi factor implementations. > > Oracles adaptive access manager, the most notable enterprise adaptive > access manager, was merged into Oracle access manager mainly for the couple > of alternative login methods but the adaptive part has disappeared. My > guess is this was a "me too"/checkbox feature. I've done several forgerock > implementations and this comes up as a theoretical discussion but never > goes beyond that. > > I've seen a few machine learning based approaches to authentication but > they go well beyond tracking a risk score, more behavior tracking stuff. > The couple I've seen end up integrating via saml or oidc anyways so there > wouldn't be much to do on the kc side. > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160829/c28f6f90/attachment.html From sthorger at redhat.com Mon Aug 29 10:00:58 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Mon, 29 Aug 2016 16:00:58 +0200 Subject: [keycloak-dev] Optional account association with Federated Identity In-Reply-To: References: Message-ID: Sounds sane - would it be an option per-realm or per-identity provider? On 28 August 2016 at 13:06, Thomas Darimont wrote: > Hello group, > > Currently when an external Identity Provider like google is configured for > a realm > a user registered in the realm directly and NOT with google also sees > a federated identity section on his account page in the default Keycloak > template. > > There a user can associate his account with a google account > (Federated Identities -> google -> add). > Is it possible to not show the link without changing the template? > > I think it should be configurable whether or not existing users have the > option to link their > accounts with an external Identity Provider like google. > > Cheers, > Thomas > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160829/c5b02f7a/attachment.html From psilva at redhat.com Mon Aug 29 10:36:27 2016 From: psilva at redhat.com (Pedro Igor Silva) Date: Mon, 29 Aug 2016 10:36:27 -0400 (EDT) Subject: [keycloak-dev] Adaptive risk login In-Reply-To: References: Message-ID: <686223392.10502910.1472481387387.JavaMail.zimbra@redhat.com> +1. Adaptive security by itself is not something trivial and it usually implies some complex event processing, analytics and integration with different sources of information. Considering that today we need to consider a very heterogeneous environment, where users are distributed across different regions, with different local policies, using different devices and with a high demand for information sharing, adaptive security plays an important role at this regard. We can extend this functionality not only to authentication/login but also to when authorizing access to protected resources. ----- Original Message ----- From: "Stian Thorgersen" To: "Marc Boorshtein" Cc: "keycloak-dev" Sent: Monday, August 29, 2016 10:48:10 AM Subject: Re: [keycloak-dev] Adaptive risk login Doesn't seem adapter authentication is dead: https://www.google.no/?ion=1&espv=2#q=adaptive+authentication&tbm=nws VPNs are certainly not the solution in all cases as more and more applications are exposed directly on the Internet everyday. Two factor is certainly improving security ten folds, but there's also issues with those. A token can be lost or compromised. There's needs for password recovery. End of the day the more layers of security you have the less likely you'll get compromised. VPNs + two factor + adaptive authentication might just combined be enough to give you the level you need. We do have adaptive authentication on the radar for Keycloak. There's a fairly good chance it's something we'll look into for 3.x (2017). As such I'd love to hear more what others think about it. On 28 August 2016 at 14:32, Marc Boorshtein < marc.boorshtein at tremolosecurity.com > wrote: On Aug 28, 2016 7:56 AM, "Thomas Darimont" < thomas.darimont at googlemail.com > wrote: > > Hello group, > > I just add a look at a nice feature from Forge Rock AM called: > "Adaptive risk login". Adaptive risk was really popular around 2010 as a multi-factor without a token. Mainly banks didnt want to hand out rsa secureid tokens. They used a bunch of factors like your flash version, source IP, etc. It turned out to be more trouble then it's worth. Between the ease of creating soft tokens like totp and the popularity of VPNs the adaptive risk approach proved to be mostly pointless. The amount of statistical data needed to make these decisions useful, and the amount of skill needed to configure was outweighed by simpler multi factor implementations. Oracles adaptive access manager, the most notable enterprise adaptive access manager, was merged into Oracle access manager mainly for the couple of alternative login methods but the adaptive part has disappeared. My guess is this was a "me too"/checkbox feature. I've done several forgerock implementations and this comes up as a theoretical discussion but never goes beyond that. I've seen a few machine learning based approaches to authentication but they go well beyond tracking a risk score, more behavior tracking stuff. The couple I've seen end up integrating via saml or oidc anyways so there wouldn't be much to do on the kc side. _______________________________________________ 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 marc.boorshtein at tremolosecurity.com Mon Aug 29 10:41:48 2016 From: marc.boorshtein at tremolosecurity.com (Marc Boorshtein) Date: Mon, 29 Aug 2016 10:41:48 -0400 Subject: [keycloak-dev] Adaptive risk login In-Reply-To: References: Message-ID: > > VPNs are certainly not the solution in all cases as more and more > applications are exposed directly on the Internet everyday. Very true (as are all your other statements) but my point about VPNs wasn't that more people are using VPNs as a way to protect applications (probably the opposite). Its that VPNs can be easily used to bypass many of the features of adaptive authentication. Most adaptive deployments I've seen rely on geo location mappings of IP ranges to determine where users are logging in from. Use an OpenVPN into a Amazon/Google/Azure/Pick-Your-Favorite-Proider network and out to the internet and that feature becomes useless. Looking at the list Thomas provided, 6 of them can easily be spoofed or circumvented: VPNs from a private server in the cloud would circumvent these - IP Address Range - ip IP not in IP range raise risk - IP Address History - if IP not in IP address history raise risk - GeoLocation - if IP geolocation based on http://www.maxmind.com/app/country is not from a certain area raise risk And these can be bypassed by a browser plugin: - Known cookie - if a certain cookie + value not present raise risk - Device cookie - if not a known or trusted device raise risk - RequestHeader - if certain request header is not present raise risk (additionally, many enterprises deploy GPOs that clear persistent cookies, which is how a device cookie is implemented) While these are certainly only examples of rules that can be used, most of the really interesting rules requires a considerable amount of data and analysis to be useful. That data needs to be kept up-to-date as does the analysis. I'd amend your statement on layered security to be "effective" layered security. If someone is trusting a security mechanism that either isn't kept updated as needed or is not providing the expected security becomes a liability. I've seen plenty of examples of folks relying on a security mechanism that didn't supply nearly the security they thought it did and it didn't work out too well. From thomas.darimont at googlemail.com Mon Aug 29 10:48:13 2016 From: thomas.darimont at googlemail.com (Thomas Darimont) Date: Mon, 29 Aug 2016 16:48:13 +0200 Subject: [keycloak-dev] IdentityServer4 - .Net based OpenID Connect / OAuth Server Message-ID: Hello group, interesting (relatively new) OpenID Connect / OAuth Server in .Net: https://github.com/IdentityServer/IdentityServer4 Already provides some good documentation - one could borrow some nice explainations from there ;-) (some parts are still a bit sparse at the moment) https://identityserver4.readthedocs.io/en/dev/index.html Such a listing of all supported specs could also be useful for Keycloak docs: https://identityserver4.readthedocs.io/en/dev/intro/specs.html Cheers, Thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160829/b4feb08d/attachment.html From thomas.darimont at googlemail.com Mon Aug 29 10:56:35 2016 From: thomas.darimont at googlemail.com (Thomas Darimont) Date: Mon, 29 Aug 2016 16:56:35 +0200 Subject: [keycloak-dev] Optional account association with Federated Identity In-Reply-To: References: Message-ID: I'm not sure yet. On one hand I could imagine an "exclusive" setting on IdentityProvider level which means that a user provided by this Identity Provider cannot add another linked Identity. Problem is that this only works for users which come through this IdP. Users that are only registered in Keycloak directly currently cannot have such a setting since the current Keycloak IdP instance itself is not represented as an IdP... I wonder whether it would make sense to add Keycloak as a "fixed" IdP to the IdP list in order to be able to adjust such things... Cheers, Thomas 2016-08-29 16:00 GMT+02:00 Stian Thorgersen : > Sounds sane - would it be an option per-realm or per-identity provider? > > On 28 August 2016 at 13:06, Thomas Darimont com> wrote: > >> Hello group, >> >> Currently when an external Identity Provider like google is configured >> for a realm >> a user registered in the realm directly and NOT with google also sees >> a federated identity section on his account page in the default Keycloak >> template. >> >> There a user can associate his account with a google account >> (Federated Identities -> google -> add). >> Is it possible to not show the link without changing the template? >> >> I think it should be configurable whether or not existing users have the >> option to link their >> accounts with an external Identity Provider like google. >> >> Cheers, >> Thomas >> >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160829/c801b374/attachment-0001.html From sthorger at redhat.com Mon Aug 29 12:20:23 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Mon, 29 Aug 2016 18:20:23 +0200 Subject: [keycloak-dev] Optional account association with Federated Identity In-Reply-To: References: Message-ID: Seems like that's the wrong way around. Why not just a check-box on the IdP on whether or not existing users can link to it? If there is available IdPs to link to the account management console will display those, otherwise it'll just display details of current provider (if any). On 29 August 2016 at 16:56, Thomas Darimont wrote: > I'm not sure yet. > > On one hand I could imagine an "exclusive" setting on IdentityProvider > level which means that a user provided by this Identity Provider cannot add > another linked Identity. > Problem is that this only works for users which come through this IdP. > Users that are only registered in Keycloak directly currently cannot have > such a setting since the current Keycloak IdP instance itself is not > represented as an IdP... > > I wonder whether it would make sense to add Keycloak as a "fixed" IdP to > the IdP list in order to be able to adjust such things... > > Cheers, > Thomas > > > 2016-08-29 16:00 GMT+02:00 Stian Thorgersen : > >> Sounds sane - would it be an option per-realm or per-identity provider? >> >> On 28 August 2016 at 13:06, Thomas Darimont < >> thomas.darimont at googlemail.com> wrote: >> >>> Hello group, >>> >>> Currently when an external Identity Provider like google is configured >>> for a realm >>> a user registered in the realm directly and NOT with google also sees >>> a federated identity section on his account page in the default Keycloak >>> template. >>> >>> There a user can associate his account with a google account >>> (Federated Identities -> google -> add). >>> Is it possible to not show the link without changing the template? >>> >>> I think it should be configurable whether or not existing users have the >>> option to link their >>> accounts with an external Identity Provider like google. >>> >>> Cheers, >>> Thomas >>> >>> _______________________________________________ >>> keycloak-dev mailing list >>> keycloak-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160829/56d975d3/attachment.html From sthorger at redhat.com Mon Aug 29 12:34:34 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Mon, 29 Aug 2016 18:34:34 +0200 Subject: [keycloak-dev] Adaptive risk login In-Reply-To: References: Message-ID: On 29 August 2016 at 16:41, Marc Boorshtein < marc.boorshtein at tremolosecurity.com> wrote: > > > > VPNs are certainly not the solution in all cases as more and more > > applications are exposed directly on the Internet everyday. > > Very true (as are all your other statements) but my point about VPNs > wasn't that more people are using VPNs as a way to protect > applications (probably the opposite). Its that VPNs can be easily > used to bypass many of the features of adaptive authentication. Most > adaptive deployments I've seen rely on geo location mappings of IP > ranges to determine where users are logging in from. Use an OpenVPN > into a Amazon/Google/Azure/Pick-Your-Favorite-Proider network and out > to the internet and that feature becomes useless. > Yep, that's an issue. There's also bot farms as well. Not many people will issue an attack from their home address. Still has some level of protection. For example VPNs are costly, tend to be rate limited. > > Looking at the list Thomas provided, 6 of them can easily be spoofed > or circumvented: > > VPNs from a private server in the cloud would circumvent these > - IP Address Range - ip IP not in IP range raise risk > - IP Address History - if IP not in IP address history raise risk > History wouldn't be that easy to spoof. However, loads of people have dynamic IP addresses so it would end up raising the risk for legitimate users. > - GeoLocation - if IP geolocation based on > http://www.maxmind.com/app/country is not from a certain area raise > risk > The IP address of a large portion of attacks still come from certain regions, so it does provide some level of protection even though it can be circumvented. > > And these can be bypassed by a browser plugin: > - Known cookie - if a certain cookie + value not present raise risk > - Device cookie - if not a known or trusted device raise risk > Not if the value is associated with the user and signed with the realm keys. > - RequestHeader - if certain request header is not present raise risk > > (additionally, many enterprises deploy GPOs that clear persistent > cookies, which is how a device cookie is implemented) > While these are certainly only examples of rules that can be used, > most of the really interesting rules requires a considerable amount of > data and analysis to be useful. That data needs to be kept up-to-date > as does the analysis. > It does depend on what level of protection you are looking for. If it's for a web application and you're trying to block out script kiddies and other people looking for easy targets the rules doesn't have to be that complex. > > I'd amend your statement on layered security to be "effective" layered > security. If someone is trusting a security mechanism that either > isn't kept updated as needed or is not providing the expected security > becomes a liability. I've seen plenty of examples of folks relying on > a security mechanism that didn't supply nearly the security they > thought it did and it didn't work out too well. > Definitively true - there's some serious false sense of security in implementing random security defenses that have no real level of protection. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160829/f70fd528/attachment.html From marc.boorshtein at tremolosecurity.com Mon Aug 29 13:06:10 2016 From: marc.boorshtein at tremolosecurity.com (Marc Boorshtein) Date: Mon, 29 Aug 2016 13:06:10 -0400 Subject: [keycloak-dev] Adaptive risk login In-Reply-To: References: Message-ID: >> > >> > VPNs are certainly not the solution in all cases as more and more >> > applications are exposed directly on the Internet everyday. >> >> Very true (as are all your other statements) but my point about VPNs >> wasn't that more people are using VPNs as a way to protect >> applications (probably the opposite). Its that VPNs can be easily >> used to bypass many of the features of adaptive authentication. Most >> adaptive deployments I've seen rely on geo location mappings of IP >> ranges to determine where users are logging in from. Use an OpenVPN >> into a Amazon/Google/Azure/Pick-Your-Favorite-Proider network and out >> to the internet and that feature becomes useless. > > > Yep, that's an issue. There's also bot farms as well. Not many people will > issue an attack from their home address. > > Still has some level of protection. For example VPNs are costly, tend to be > rate limited. If you're talking about a DDoS or script kiddies just running massive sets of scripts against a target, sure but I don't think KC (or any authentication system) will be what stops that. That'll be a combination of network infrastructure and web application firewalls screening out specific exploits. Where the value of adaptive auth would I think be more likely is a targeted attack with a known set of credentials where a set of actors is trying to leverage something they have to get elevated privileges. In which case getting a single openvpn running on an aws account could cost as little as a few dollars and circumvent many of the risk barometers based on source ip. > > > It does depend on what level of protection you are looking for. If it's for > a web application and you're trying to block out script kiddies and other > people looking for easy targets the rules doesn't have to be that complex. > Sure, but I don't think KC (or any authentication system) is going to stop a script kiddie. The vulnerabilities they are generally going after are known exploits that haven't been patched and don't require authentication. Just watch the logs for a known wordpress site and you won't see any requests for authentication from trollers (unless its with a specific exploit). You'll see reams of trying to hit wp-admin with known exploits to bypass authentication all-together. Even looking at the articles mentioned, everything is theoretical. Adaptive authentication has been around for at least 8-10 years, you'd think if it were used to great success there would be more success stories rather then theories. The new part they point out is the addition of machine learning to the process to make more intelligent decisions, which makes sense. Something like Google's new captcha system. KC would make a great integration tool for something like that. ps: great conversation, really enjoy these types of discussions From singhrasster at gmail.com Mon Aug 29 22:32:28 2016 From: singhrasster at gmail.com (Rashmi Singh) Date: Mon, 29 Aug 2016 21:32:28 -0500 Subject: [keycloak-dev] Edit value contained in NameID field of SAML response Message-ID: I have a keycloak app that calls an external TokenValidator for authentication. This TokenValidator returns a SP specific username value. I want my SAML response to contain this value in the NameID field. My question is how do I edit the SAML response to change the value in NameID field to this value? Any insight into how to edit the NameID field in the SAML response? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160829/684d9d9b/attachment.html From mitya at cargosoft.ru Tue Aug 30 05:11:18 2016 From: mitya at cargosoft.ru (Dmitry Telegin) Date: Tue, 30 Aug 2016 12:11:18 +0300 Subject: [keycloak-dev] Custom Realm Attributes In-Reply-To: References: Message-ID: <1472548278.4299.5.camel@cargosoft.ru> Hi guys, Just FYI, there's a PR (#3153) that makes realm attributes generally available for developers, i.e. exposed through RealmModel, accessible via REST, with support for Mongo and Infinispan. At the moment realm attributes are available only for JPA (via o.k.models.jpa.RealmAdapter) without caching and are not exposed via REST. Cheers, Dmitry > > > > > Sounds like an interesting idea. For a while ago I was thinking about how you'd manage clients and hostnames in different environments (dev, test, prod) without having to modify the config. My idea at the time was to introduce server aliases which would be a similar thing to what you are proposing although with much more limited use. > > > On 28 August 2016 at 12:24, Thomas Darimont wrote: > > Hello group, > > > > currently the configuration for themes, extensions, clients is quite local to a? > > > > component and one has to repeat some information like company name, trademark,? > > URLs, parts of application name etc. > > > > > > It would be cool if an admin could configure a set of key-value pairs on realm? > > > > level that could then be used / referenced in client definitions, user attributes, themes, emails. > > > > The admin-console could feature a new tab 'attributes' in the realm-settings? > > > > in which one could configure key-value pairs with support for string, boolean,? > > numeric and lists values. > > > > > > This could also be used as a centralized configuration source of custom extensions e.g.? > > FederationProvider, RequiredActions, Authenticators. > > > > > > Of course something like this is already partially possible with system properties / env-variables. > > > > However these values are hard to change at runtime. Having a dedicated support for realm-wide? > > > > attributes managed by an "attributes" section in the admin-console would allow for simpler configuration. > > > > > > An idea on top of that is to let extensions (like custom Authenticators) register their configuration settings? > > > > as attributes in the realm which could then be shown as an overview in the "attributes" section of the realm-settings. > > > > This would give provide you with all the configuration settings for all realm-components at a glance. > > > > Cheers, > > Thomas > > > > > > > > _______________________________________________ > > > > 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160830/5453cb31/attachment-0001.html From sthorger at redhat.com Tue Aug 30 05:31:41 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Tue, 30 Aug 2016 11:31:41 +0200 Subject: [keycloak-dev] Adaptive risk login In-Reply-To: References: Message-ID: On 29 August 2016 at 19:06, Marc Boorshtein < marc.boorshtein at tremolosecurity.com> wrote: > >> > > >> > VPNs are certainly not the solution in all cases as more and more > >> > applications are exposed directly on the Internet everyday. > >> > >> Very true (as are all your other statements) but my point about VPNs > >> wasn't that more people are using VPNs as a way to protect > >> applications (probably the opposite). Its that VPNs can be easily > >> used to bypass many of the features of adaptive authentication. Most > >> adaptive deployments I've seen rely on geo location mappings of IP > >> ranges to determine where users are logging in from. Use an OpenVPN > >> into a Amazon/Google/Azure/Pick-Your-Favorite-Proider network and out > >> to the internet and that feature becomes useless. > > > > > > Yep, that's an issue. There's also bot farms as well. Not many people > will > > issue an attack from their home address. > > > > Still has some level of protection. For example VPNs are costly, tend to > be > > rate limited. > > If you're talking about a DDoS or script kiddies just running massive > sets of scripts against a target, sure but I don't think KC (or any > authentication system) will be what stops that. That'll be a > combination of network infrastructure and web application firewalls > screening out specific exploits. Where the value of adaptive auth > would I think be more likely is a targeted attack with a known set of > credentials where a set of actors is trying to leverage something they > have to get elevated privileges. In which case getting a single > openvpn running on an aws account could cost as little as a few > dollars and circumvent many of the risk barometers based on source ip. > > > > > > > It does depend on what level of protection you are looking for. If it's > for > > a web application and you're trying to block out script kiddies and other > > people looking for easy targets the rules doesn't have to be that > complex. > > > > Sure, but I don't think KC (or any authentication system) is going to > stop a script kiddie. The vulnerabilities they are generally going > after are known exploits that haven't been patched and don't require > authentication. Just watch the logs for a known wordpress site and > you won't see any requests for authentication from trollers (unless > its with a specific exploit). You'll see reams of trying to hit > wp-admin with known exploits to bypass authentication all-together. > It's certainly not going to stop attacks going after known exploits. The only real defense against that is limiting what's exposed and making sure everything that is exposed always has the latest security patches. The latter being one good reason for using a supported product rather than a community project as you are able to get patches to older versions as well as retrieve patches prior to the vulnerabilities being made public. Adaptive authentication could for instance stop someone trying to use common passwords with a list of known usernames. We have a rather naive brute force protection in Keycloak that prevents that to some degree, but it's far from sophisticated enough. For example it prevents many guesses to one user, but not few guesses to many users. However, that would more likely be the job of a intrusion detection system and firewalls to stop those type of attacks in either case. > > Even looking at the articles mentioned, everything is theoretical. > Adaptive authentication has been around for at least 8-10 years, you'd > think if it were used to great success there would be more success > stories rather then theories. The new part they point out is the > addition of machine learning to the process to make more intelligent > decisions, which makes sense. Something like Google's new captcha > system. KC would make a great integration tool for something like > that. > You're right. Simple rules like an IP range are just not going to cut it. Much more complex and intelligent processing of data is required. If the rules are to defensive you also end up blocking legitimate users. In which case you need a way for the legitimate user to prove they are who they say you are. In which case you can send a mail or even use Google's reCAPTCHA. Even sending an email when you've detected a login from a new machine is useful to at least detect malicious access. One thing we should at least do is to add a device cookie which includes the user-id that is signed with the realm key. This would allow us to identify a device that has been used before. If we detect a new device we can introduce options such as send an email to verify the device, display a reCAPTCHA or even simply send an email to the user to notify about the login. > > > ps: great conversation, really enjoy these types of discussions > +1000 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160830/e1f72690/attachment.html From francis.pouatcha at adorsys.com Wed Aug 31 02:22:01 2016 From: francis.pouatcha at adorsys.com (Francis Pouatcha) Date: Wed, 31 Aug 2016 08:22:01 +0200 Subject: [keycloak-dev] Adaptive risk login In-Reply-To: References: Message-ID: user(s) attached device cookies will definitive add a lot of value to KC. Simple enough to handle. +1 Best regards Mit freundlichen Gr??en Cordialement Francis Pouatcha Founder and Technical Lead Group Adorsys LinkedIn: http://www.linkedin.com/pub/francis-pouatcha/8/35a/542 adorsys GmbH & Co. KG, Germany: http://www.youtube.com/watch?v=rVRkFGUNexo&authuser=0 Adorsys S.A., Cameroon: "African Software Competence Center" Open https://github.com/adorsys Cell USA: +1 770 329 7026 Cell Germany: +49 172 18 16 074 Cell Cameroon: +237 51 74 71 99 On Tue, Aug 30, 2016 at 11:31 AM, Stian Thorgersen wrote: > > > On 29 August 2016 at 19:06, Marc Boorshtein tremolosecurity.com> wrote: > >> >> > >> >> > VPNs are certainly not the solution in all cases as more and more >> >> > applications are exposed directly on the Internet everyday. >> >> >> >> Very true (as are all your other statements) but my point about VPNs >> >> wasn't that more people are using VPNs as a way to protect >> >> applications (probably the opposite). Its that VPNs can be easily >> >> used to bypass many of the features of adaptive authentication. Most >> >> adaptive deployments I've seen rely on geo location mappings of IP >> >> ranges to determine where users are logging in from. Use an OpenVPN >> >> into a Amazon/Google/Azure/Pick-Your-Favorite-Proider network and out >> >> to the internet and that feature becomes useless. >> > >> > >> > Yep, that's an issue. There's also bot farms as well. Not many people >> will >> > issue an attack from their home address. >> > >> > Still has some level of protection. For example VPNs are costly, tend >> to be >> > rate limited. >> >> If you're talking about a DDoS or script kiddies just running massive >> sets of scripts against a target, sure but I don't think KC (or any >> authentication system) will be what stops that. That'll be a >> combination of network infrastructure and web application firewalls >> screening out specific exploits. Where the value of adaptive auth >> would I think be more likely is a targeted attack with a known set of >> credentials where a set of actors is trying to leverage something they >> have to get elevated privileges. In which case getting a single >> openvpn running on an aws account could cost as little as a few >> dollars and circumvent many of the risk barometers based on source ip. > > >> >> > >> > >> > It does depend on what level of protection you are looking for. If it's >> for >> > a web application and you're trying to block out script kiddies and >> other >> > people looking for easy targets the rules doesn't have to be that >> complex. >> > >> >> Sure, but I don't think KC (or any authentication system) is going to >> stop a script kiddie. The vulnerabilities they are generally going >> after are known exploits that haven't been patched and don't require >> authentication. Just watch the logs for a known wordpress site and >> you won't see any requests for authentication from trollers (unless >> its with a specific exploit). You'll see reams of trying to hit >> wp-admin with known exploits to bypass authentication all-together. >> > > It's certainly not going to stop attacks going after known exploits. The > only real defense against that is limiting what's exposed and making sure > everything that is exposed always has the latest security patches. The > latter being one good reason for using a supported product rather than a > community project as you are able to get patches to older versions as well > as retrieve patches prior to the vulnerabilities being made public. > > Adaptive authentication could for instance stop someone trying to use > common passwords with a list of known usernames. We have a rather naive > brute force protection in Keycloak that prevents that to some degree, but > it's far from sophisticated enough. For example it prevents many guesses to > one user, but not few guesses to many users. However, that would more > likely be the job of a intrusion detection system and firewalls to stop > those type of attacks in either case. > > >> >> Even looking at the articles mentioned, everything is theoretical. >> Adaptive authentication has been around for at least 8-10 years, you'd >> think if it were used to great success there would be more success >> stories rather then theories. The new part they point out is the >> addition of machine learning to the process to make more intelligent >> decisions, which makes sense. Something like Google's new captcha >> system. KC would make a great integration tool for something like >> that. >> > > You're right. Simple rules like an IP range are just not going to cut it. > Much more complex and intelligent processing of data is required. If the > rules are to defensive you also end up blocking legitimate users. In which > case you need a way for the legitimate user to prove they are who they say > you are. In which case you can send a mail or even use Google's reCAPTCHA. > Even sending an email when you've detected a login from a new machine is > useful to at least detect malicious access. > > One thing we should at least do is to add a device cookie which includes > the user-id that is signed with the realm key. This would allow us to > identify a device that has been used before. If we detect a new device we > can introduce options such as send an email to verify the device, display a > reCAPTCHA or even simply send an email to the user to notify about the > login. > > >> >> >> ps: great conversation, really enjoy these types of discussions >> > > +1000 > > > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160831/5186a6bc/attachment-0001.html From mitya at cargosoft.ru Wed Aug 31 03:00:30 2016 From: mitya at cargosoft.ru (Dmitry Telegin) Date: Wed, 31 Aug 2016 10:00:30 +0300 Subject: [keycloak-dev] new generic component storage In-Reply-To: References: Message-ID: <1472626830.4299.12.camel@cargosoft.ru> Hi Bill, There's a discussion going on here:?https://github.com/keycloak/keycloa k/pull/3153 The question is, whether the new component storage mechanism will replace/supersede what we currently know as realm attributes. Could you please leave a comment? Thanks! Dmitry > I've implemented a new generic component storage, api, REST API, and? > admin console support.??Classes/interfaces are in server-spi? > > org.keycloak.component package and created via methods in RealmModel.?? > It is basically a more generic form of mapper models,? > UserFederationModel, etc.??Components describe themselves and can be? > > generically rendered by the admin console.??The storage model is meant? > to support nested subcomponents (i.e. UserFederationModel and? > UserFederationMappers).??Config now supports a MultivaluedHashmap? > > instead of a flat Map to support list storage. There is a common REST? > > API under the realm that should be usable for all component types.??The? > UserStorage SPI uses this new SPI from top to bottom. > > > We should consider whether we want to migrate other component types to? > this new model. > > > When you create components to store, you specify a parentId (i.e. Realm,? > Client, a parent component), a provider type, a provider id, and? > > config.??For export, the json model will contain components under Realm? > > and Client where the perspective parentId is Realm and Client.??I still? > want to make this as human consumable as possible so that these? > components can be defined by humans in json. > > Bill > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160831/8a03a857/attachment.html From sthorger at redhat.com Wed Aug 31 03:26:52 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Wed, 31 Aug 2016 09:26:52 +0200 Subject: [keycloak-dev] No more keycloak-server.json In-Reply-To: <57C0350F.6000104@redhat.com> References: <57C0350F.6000104@redhat.com> Message-ID: One thing I'm not so keen on is the syntax for a list. On 26 August 2016 at 14:24, Stan Silvert wrote: > Now that changes for KEYCLOAK-3196 are merged, everything you used to > configure in keycloak-server.json will now be configured in > standalone.xml, standalone-ha.xml, or domain.xml. > > If you need to make a change to the default keycloak-subsystem > configuration, you will need to edit this file: > https://github.com/keycloak/keycloak/blob/master/wildfly/ > server-subsystem/src/main/config/default-server-subsys-config.properties > > This file contains a single multi-line property containing the subsystem > xml declaration. Maven filtering is used to read this property and > inject it everywhere it needs to go. Editing this file will also take > care of propagating it to the distributions like server-dist and demo-dist. > > Also, you need to create CLI commands for each change by editing this file: > https://github.com/keycloak/keycloak/blob/master/wildfly/ > server-subsystem/src/main/resources/cli/default-keycloak-subsys-config.cli > > This CLI snippet is used in the scripts required by the overlay > distribution. > > We have always had the problem that whenever someone changes > keycloak-server.json, they forget to make corresponding changes that > affect the various distributions. With the switch to standalone.xml, we > now have just these two files to edit instead of five or six. > > Below, I'm pasting part of the asciidoc documentation I'm working on for > this. It explains how to configure SPI's in standalone.xml. Also, if > someone can tell me if what I said about default-provider is accurate > I'd appreciate that: > > ------------------------------------------------------------ > ------------------------------------------------------------ > ---------------------------------- > All elements in an SPI declaration are optional, but a full SPI declaration > looks like this: > [source,xml] > ---- > > mongo > > > > > > > > > > > > > ---- > Here we have two providers defined for the SPI `dblock`. The > `default-provider` > is listed as `mongo`. However it is up to the SPI to decide how it will > treat > this setting. Some SPIs allow more than one provider and some do not. So > `default-provider` can help the SPI to choose. > > Also notice that each provider defines its own set of configuration > properties. > The fact that both providers above have a property called > `lockWaitTimeout` is just a > coincidence. > > The type of each property value is interpreted by the provider. However, > there > is one exception. Consider the `jpa` provider for the `eventStore` API: > [source,xml] > ---- > > > > > > > > ---- > We see that the value begins and ends with square brackets. That means > that > the value will be passed to the provider as a list. In this example, > the system will pass the > provider a list with two element values _EVENT1_ and _EVENT2_. To add > more values > to the list, just separate each list element with a comma. Unfortunately, > you do need to escape the quotes surrounding each list element with > `\"`. > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160831/2382acbe/attachment.html From mitya at cargosoft.ru Wed Aug 31 04:32:23 2016 From: mitya at cargosoft.ru (Dmitry Telegin) Date: Wed, 31 Aug 2016 11:32:23 +0300 Subject: [keycloak-dev] Securing realm resources with custom admin roles In-Reply-To: References: <1471651956.28663.68.camel@cargosoft.ru> <1471954112.3994.1.camel@cargosoft.ru> Message-ID: <1472632343.4299.27.camel@cargosoft.ru> Hi Stian, Thanks for clarifications, got it. Meanwhile, I've more or less figured out how to build an ad-hoc custom admin resource, maybe this could be interesting for you or other developers. The code is here:?https://github.com/dteleguin/custom-admin-roles Setting aside the frontend and role creation issues, the main problem was to obtain HttpHeaders upon resource creation, so that JWS could be extracted. (Surely, we could use a @Context HttpHeaders argument in every service method, but that would lead to unnecessary argument list pollution.) What I did was to introduce a @Context HttpHeaders private field in HelloResource, and manually perform injection in HelloResourceProvider: ? ? @Override ????public Object getResource() { ????????HelloResource hello = new HelloResource(); ????????ResteasyProviderFactory.getInstance().injectProperties(hello); ????????hello.setupAuth(); ????????return hello; ????} This is identical to what is done for admin sub-resources in org.keycloak.services.resources.RealmsResource. The question is, why couldn't injection be done in RealmsResource::resolveRealmExtension? Having support for @Context fields injection is very useful, but I don't think custom providers should monkey with Resteasy internals themselves.? Dmitry > > > > > Once we introduce a realm admin resource provider I was hoping it would sort out these issues. It's not a high priority for us at the moment though, especially not considering that in the future we want to remove the master realm as well as remove the whoAmI endpoint used by the admin client and instead make it use the token directly. > > > > On 23 August 2016 at 14:08, Dmitry Telegin wrote: > > Anybody here? > > > > Was a bad idea to make an important posting on the Friday evening :) > > > > > > _______________________________________________ > > > > keycloak-dev mailing list > > > > keycloak-dev at lists.jboss.org > > > > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160831/0af464e4/attachment.html From ssilvert at redhat.com Wed Aug 31 07:03:42 2016 From: ssilvert at redhat.com (Stan Silvert) Date: Wed, 31 Aug 2016 07:03:42 -0400 Subject: [keycloak-dev] No more keycloak-server.json In-Reply-To: References: <57C0350F.6000104@redhat.com> Message-ID: <57C6B98E.8020306@redhat.com> On 8/31/2016 3:26 AM, Stian Thorgersen wrote: > One thing I'm not so keen on is the syntax for a list. I'm not either. I hate having to escape quotes with " I tried something like this, which looks nicer in XML: jpa EVENT1 EVENT2 The problem was that it made the code get really ugly. I can take another stab at it later though. Some refactoring would probably make it easier to implement. The good news is that you don't use lists very much and they look fine in CLI, where you can do something like this: /subsystem=keycloak-server/spi=eventsStore/provider=jpa/:map-put(name=properties,key=exclude-events,value=[EVENT1,EVENT2]) > > On 26 August 2016 at 14:24, Stan Silvert > wrote: > > Now that changes for KEYCLOAK-3196 are merged, everything you used to > configure in keycloak-server.json will now be configured in > standalone.xml, standalone-ha.xml, or domain.xml. > > If you need to make a change to the default keycloak-subsystem > configuration, you will need to edit this file: > https://github.com/keycloak/keycloak/blob/master/wildfly/server-subsystem/src/main/config/default-server-subsys-config.properties > > > This file contains a single multi-line property containing the > subsystem > xml declaration. Maven filtering is used to read this property and > inject it everywhere it needs to go. Editing this file will also take > care of propagating it to the distributions like server-dist and > demo-dist. > > Also, you need to create CLI commands for each change by editing > this file: > https://github.com/keycloak/keycloak/blob/master/wildfly/server-subsystem/src/main/resources/cli/default-keycloak-subsys-config.cli > > > This CLI snippet is used in the scripts required by the overlay > distribution. > > We have always had the problem that whenever someone changes > keycloak-server.json, they forget to make corresponding changes that > affect the various distributions. With the switch to > standalone.xml, we > now have just these two files to edit instead of five or six. > > Below, I'm pasting part of the asciidoc documentation I'm working > on for > this. It explains how to configure SPI's in standalone.xml. Also, if > someone can tell me if what I said about default-provider is accurate > I'd appreciate that: > > ---------------------------------------------------------------------------------------------------------------------------------------------------------- > All elements in an SPI declaration are optional, but a full SPI > declaration > looks like this: > [source,xml] > ---- > > mongo > > > > > > > > > > > > > ---- > Here we have two providers defined for the SPI `dblock`. The > `default-provider` > is listed as `mongo`. However it is up to the SPI to decide how > it will > treat > this setting. Some SPIs allow more than one provider and some do > not. So > `default-provider` can help the SPI to choose. > > Also notice that each provider defines its own set of configuration > properties. > The fact that both providers above have a property called > `lockWaitTimeout` is just a > coincidence. > > The type of each property value is interpreted by the provider. > However, > there > is one exception. Consider the `jpa` provider for the > `eventStore` API: > [source,xml] > ---- > > > > value="["EVENT1", > "EVENT2"]"/> > > > > ---- > We see that the value begins and ends with square brackets. That > means that > the value will be passed to the provider as a list. In this example, > the system will pass the > provider a list with two element values _EVENT1_ and _EVENT2_. To add > more values > to the list, just separate each list element with a comma. > Unfortunately, > you do need to escape the quotes surrounding each list element with > `\"`. > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160831/e4d97c07/attachment-0001.html From martin.hardselius at gmail.com Wed Aug 31 07:29:13 2016 From: martin.hardselius at gmail.com (Martin Hardselius) Date: Wed, 31 Aug 2016 11:29:13 +0000 Subject: [keycloak-dev] Pairwise Subject Identifier In-Reply-To: <57BD70E2.50108@redhat.com> References: <57AC9686.5040807@redhat.com> <57BB6324.2030403@redhat.com> <57BC51CE.9020504@redhat.com> <57BD70E2.50108@redhat.com> Message-ID: Just had the chance to start looking at this. Wanted to check with you if this is the direction you had in mind? public abstract class AbstractPairwiseSubGeneratorMapper extends AbstractOIDCProtocolMapper implements OIDCAccessTokenMapper, OIDCIDTokenMapper { @Override public IDToken transformIDToken(IDToken token, ProtocolMapperModel mappingModel, KeycloakSession session, UserSessionModel userSession, ClientSessionModel clientSession) { token.setSubject(generateSub(mappingModel, userSession.getUser().getId())); return token; } @Override public AccessToken transformAccessToken(AccessToken token, ProtocolMapperModel mappingModel, KeycloakSession session, UserSessionModel userSession, ClientSessionModel clientSession) { token.setSubject(generateSub(mappingModel, userSession.getUser().getId())); return token; } public abstract String generateSub(ProtocolMapperModel mappingModel, String localSub);} On Wed, 24 Aug 2016 at 12:03 Marek Posolda wrote: > Sounds great. Thanks! > > > Marek > > > On 24/08/16 11:08, Martin Hardselius wrote: > > Sounds good. I'll look into it and see what I can do. Possibly during next > week. :) > > On Tue, 23 Aug 2016 at 15:38 Marek Posolda wrote: > >> We discussed it with Stian a bit and we discussed to: >> >> - Implement as protocolMapper >> >> - There will be possibility to configure "salt" as parameter to >> protocolMapper. It may not be mandatory parameter. If it's used, then >> client will use it as salt, otherwise salt will be generated. This allows >> the use-case you mentioned. You can use same salt for clients x,y,z but >> different salt for clients m,n. If you let generate salt, then the subject >> identifiers will be really unique just to the particular client. >> >> - We need to validate sector_identifier_uri during create/update of >> protocolMapper, but also during update of client. Otherwise someone can >> register sector_identifier_uri and register the client with valid >> redirect_uris (for example URLs "http://good-host/url1" >> "http://good-host/url2" >> , which are both specified under sector_identifier_uri ) but then later >> update just the client redirect_uris to "http://evil-host/url1" >> . Basically he will be >> able to update redirect_uris to anything he wants regardless of >> redirect_uris under sector_identifier_uri, so the whole validation will be >> bypassed. >> >> For updating client, I've just sent PR, which adds >> RealmModel.ClientUpdatedEvent . You can register to that event similarly >> like >> https://github.com/keycloak/keycloak/blob/master/server-spi/src/main/java/org/keycloak/protocol/AbstractLoginProtocolFactory.java#L39 >> . The creation/update listener for protocolMapper doesn't yet exists, >> however we are likely going to refactor protocolMapper to generic >> component, which will have validation support. But that will be likely >> available in few weeks, so for now, we can add something temporary for >> protocolMappers similar to what is available for example for >> UserFederationMapperFactory (See >> https://github.com/keycloak/keycloak/blob/master/services/src/main/java/org/keycloak/services/resources/admin/UserFederationProviderResource.java#L437-L440 >> ) >> >> Martin, will you have some time to eventually look into this and send PR ? >> >> >> Marek >> >> >> On 23/08/16 14:25, Martin Hardselius wrote: >> >> Let's say we want to force all of our client to use pairwise subs, but a >> single "merchant" needs to implement several clients where subs should >> remain the same for all those clients. >> >> Merchant A >> - client x >> - client y >> - client z >> >> Merchant B >> - client m >> - client n >> >> You can assume the sector_identifiers are the same across all clients >> owned by a merchant >> >> It should not be possible to correlate activities between Customer A and >> Customer B (at least not from their side). They should, however, be able to >> correlate user activities between their own clients. >> >> Which implementation of pairwise subs is better suited for supporting >> this scenario? I'm leaning towards the protocol mapper solution. It should >> be easier to create custom mappers with merchant-wide configuration (e.g >> salts). >> >> On Mon, 22 Aug 2016 at 22:40 Marek Posolda wrote: >> >>> The question is, should we really introduce another SPI for that? >>> Doesn't it mean uneccessary complexity? Also add the new options directly >>> to the client for the feature, which is likely interesting just for quite >>> limited amount of people? >>> >>> IMO it's fine if this is implemented as protocolMapper? >>> >>> Few thoughts: >>> - We can have abstract superclass like >>> AbstractPairwiseSubGeneratorMapper . The subclasses will just need to >>> implement method "generateSub" . We can have just one concrete impl, which >>> will use SHA-256( sector_identifier || local_sub || salt ) >>> >>> - The sector_identifier_uri will be a configuration option of this >>> protocolMapper implementation. >>> >>> - If protocolMapper is not added to client, the client will just use the >>> public subjects. By default it's not added, which ensures backwards >>> compatibility and public subjects by default. Note that with this approach, >>> we don't even need subject_type option on the client. >>> >>> - The salt can be generated lazily at the first time when mapper is used. >>> >>> - The validation can be done at the moment, when protocolMapper is going >>> to be created/updated. Right now, we don't have validation callback during >>> protocolMapper creation/update. However Bill is going to add support for >>> that into generic componentModel. So if we're going to refactor >>> protocolMapper to use the new generic component model, we will have >>> validation callback available to protocolMapper SPI. The validation will >>> fail if array of redirect_uri from sector_identifier_uri doesn't contain >>> the uris from redirect_uri of particular client (including wildcards etc). >>> >>> - If client is updated and it's redirect_uri are changed, we won't be >>> able to catch this, however this is not strictly required per specs per my >>> understanding. At least the dynamic client registration specs sais [1] >>> >>> "The values registered in redirect_uris MUST be included in the >>> elements of the array, or registration MUST fail. This MUST be validated at >>> registration time; there is no requirement for the OP to retain the >>> contents of this JSON file or to retrieve or revalidate its contents in the >>> future. " >>> >>> [1] >>> http://openid.net/specs/openid-connect-registration-1_0.html#SectorIdentifierValidation >>> >>> >>> Marek >>> >>> >>> On 22/08/16 15:50, Martin Hardselius wrote: >>> >>> Ok, thanks for the clarification. >>> >>> Where would it make sense to put the PairwiseSubGeneratorSpi? Which >>> package, that is? >>> >>> On Mon, 22 Aug 2016 at 14:51 Stian Thorgersen >>> wrote: >>> >>>> On 22 August 2016 at 14:16, Martin Hardselius < >>>> martin.hardselius at gmail.com> wrote: >>>> >>>>> "IMO it's sufficient to document the algorithm to create the sub, >>>>> which should make it clear that the origin in the redirect uri will affect >>>>> the sub." >>>>> >>>>> Reasonable. :) >>>>> >>>>> "One client could also have multiple redirect uris with different >>>>> origins so could get different sub's generated depending on the redirect >>>>> uri used." >>>>> >>>>> That case is probably caught by >>>>> [...] If there are multiple hostnames in the registered redirect_uris, >>>>> the Client MUST register a sector_identifier_uri. [...] >>>>> >>>> >>>> Yes, but I meant from a documentation perspective. It should be clear >>>> from the documentation that is the case. >>>> >>>> >>>>> >>>>> On Mon, 22 Aug 2016 at 10:42 Stian Thorgersen >>>>> wrote: >>>>> >>>>>> IMO it's sufficient to document the algorithm to create the sub, >>>>>> which should make it clear that the origin in the redirect uri will affect >>>>>> the sub. One client could also have multiple redirect uris with different >>>>>> origins so could get different sub's generated depending on the redirect >>>>>> uri used. >>>>>> >>>>>> On 22 August 2016 at 09:58, Martin Hardselius < >>>>>> martin.hardselius at gmail.com> wrote: >>>>>> >>>>>>> Sounds fair enough. >>>>>>> >>>>>>> What about the case where you don't provide a sector_identifier_uri, >>>>>>> set up a single redirect uri on myhost and then later go on to change that >>>>>>> redirect uri to something on myotherhost? That would change the >>>>>>> sector_identifier and subsequently all the user subs. Do we protect against >>>>>>> such "mistakes" or do we warn people (in the docs and/or admin gui) that >>>>>>> it's not a good idea to do that? >>>>>>> >>>>>>> On Mon, 22 Aug 2016 at 09:38 Stian Thorgersen >>>>>>> wrote: >>>>>>> >>>>>>>> We need to follow the spec and verify that sector_identifier_uri >>>>>>>> points to a URL that contains the corresponding URIs. As an enhancement we >>>>>>>> could support wildcards in the JSON returned by sector_identifier_uri. For >>>>>>>> example if it returns: >>>>>>>> >>>>>>>> [ https://www.mydomain.com/*, https://www.myotherdomain.com/* ] >>>>>>>> >>>>>>>> A client with the redirect uri 'https://www.myotherdomain.com/myapp' >>>>>>>> would work >>>>>>>> >>>>>>>> On 18 August 2016 at 15:09, Martin Hardselius < >>>>>>>> martin.hardselius at gmail.com> wrote: >>>>>>>> >>>>>>>>> Speaking of subject_identifier_uri >>>>>>>>> >>>>>>>>> From the spec: >>>>>>>>> >>>>>>>>> "When a sector_identifier_uri is provided, the host component of >>>>>>>>> that URL is used as the Sector Identifier for the pairwise identifier >>>>>>>>> calculation. The value of the sector_identifier_uri MUST be a URL >>>>>>>>> using the https scheme that points to a JSON file containing an >>>>>>>>> array of redirect_uri values. The values of the registered >>>>>>>>> redirect_uris MUST be included in the elements of the array." >>>>>>>>> >>>>>>>>> What's your stance on sanity/health checking the >>>>>>>>> sector_identifier_uri? URI validation is one thing, but should we also make >>>>>>>>> a request to the uri in order to validate the response? >>>>>>>>> >>>>>>>>> The spec also mentions that the sector_identifier_uri isn't >>>>>>>>> strictly required if a client has all it's redirect_uris under the same >>>>>>>>> domain. How do we deal with changes to clients if the sector_identifier_uri >>>>>>>>> isn't required for enabling pairwise subs? >>>>>>>>> >>>>>>>>> Example: >>>>>>>>> >>>>>>>>> I create a client, enabling pairwise subs. Valid redirect_uris are >>>>>>>>> [ https://www.mydomain.com/* ]. The sector_identifier would be >>>>>>>>> mydomain. >>>>>>>>> >>>>>>>>> Later on, I update the redirect_uris to [ >>>>>>>>> https://www.mydomain.com/*, https://www.myotherdomain.com/* ] Do >>>>>>>>> we >>>>>>>>> >>>>>>>>> * keep the old sector_identifier, or >>>>>>>>> * reject the update, or >>>>>>>>> * allow the update if a valid subject_identifier_uri is provided >>>>>>>>> at mydomain, or >>>>>>>>> * just allow it and let the client devs deal with the >>>>>>>>> consequences, or >>>>>>>>> * take some other path you can think of ? >>>>>>>>> >>>>>>>>> Having the sector_identifier_uri as a hard requirement seems >>>>>>>>> safer, but it's also means more work implementing a client. Leaving it >>>>>>>>> optional is a lot more scary. >>>>>>>>> >>>>>>>>> >>>>>>>>> On Thu, 18 Aug 2016 at 10:45 Stian Thorgersen >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>>> Makes sense to make this pluggable. The default should >>>>>>>>>> probably SHA-256( sector_identifier || local_sub || salt ). >>>>>>>>>> >>>>>>>>>> We would love a PR for this, but there's a few bits required: >>>>>>>>>> >>>>>>>>>> * OIDC clients need option for subject type and >>>>>>>>>> sector_identifier_uri. If not set it should default to public so existing >>>>>>>>>> clients continue to work. These options can just be set as client >>>>>>>>>> attributes so there's no need to update db schema >>>>>>>>>> * Admin console update for the above >>>>>>>>>> * PairwiseSubGeneratorSpi and default implementation >>>>>>>>>> * Generation of salt for clients. This should be done when a >>>>>>>>>> client sets subject type to pairwise >>>>>>>>>> * Tests and docs >>>>>>>>>> >>>>>>>>>> I'd say the PairwiseSubGeneratorSpi signature should probably be: >>>>>>>>>> >>>>>>>>>> * public String getPairwiseSub(UserModel user, ClientModel client >>>>>>>>>> ) >>>>>>>>>> >>>>>>>>>> It might even be an option to let the >>>>>>>>>> default PairwiseSubGenerator provider create the salt and store it as an >>>>>>>>>> attribute on the client, making that part pluggable as well. >>>>>>>>>> >>>>>>>>>> On 17 August 2016 at 15:59, Martin Hardselius < >>>>>>>>>> martin.hardselius at gmail.com> wrote: >>>>>>>>>> >>>>>>>>>>> I'm going to bump this, as I want to continue the >>>>>>>>>>> discussion/provide some input. >>>>>>>>>>> >>>>>>>>>>> Does it make sense to support more than type of pairwise subject >>>>>>>>>>> identifier generator? E.g through a PairwiseSubGeneratorSpi? >>>>>>>>>>> >>>>>>>>>>> Let's say I want to generate the pairwise sub as a salted hash: >>>>>>>>>>> sub = SHA-256( sector_identifier || local_sub || salt ) >>>>>>>>>>> To me, it makes sense to allow for per-client salts. These salts >>>>>>>>>>> should probably be generated and persisted during client creation. Thoughts? >>>>>>>>>>> >>>>>>>>>>> On Fri, 12 Aug 2016 at 09:57 Martin Hardselius < >>>>>>>>>>> martin.hardselius at gmail.com> wrote: >>>>>>>>>>> >>>>>>>>>>>> Thank you for your response. Did not see that ticket before. >>>>>>>>>>>> Great news! >>>>>>>>>>>> >>>>>>>>>>>> I looked into using protocol mappers to achieve this, and while >>>>>>>>>>>> it would work I'm worried that once KEYCLOAK-3422 has been resolved and >>>>>>>>>>>> included in a proper release we would run into migration issues if the >>>>>>>>>>>> method used for calculating "native" pairwise subs is different from what >>>>>>>>>>>> we implement. Clients could loose / be forced to re-register all their >>>>>>>>>>>> users if we decide to switch. The example methods in the spec are just >>>>>>>>>>>> that. Examples. Maybe the method/alg for computing the pairwise sub should >>>>>>>>>>>> be pluggable? >>>>>>>>>>>> >>>>>>>>>>>> -- >>>>>>>>>>>> Martin >>>>>>>>>>>> >>>>>>>>>>>> On Thu, 11 Aug 2016 at 17:15 Marek Posolda >>>>>>>>>>>> wrote: >>>>>>>>>>>> >>>>>>>>>>>>> Sorry for late response. >>>>>>>>>>>>> >>>>>>>>>>>>> We have JIRA created for that. You can possibly add yourself >>>>>>>>>>>>> as a watcher. See >>>>>>>>>>>>> https://issues.jboss.org/browse/KEYCLOAK-3422 >>>>>>>>>>>>> >>>>>>>>>>>>> Maybe an alternative for you is to use protocolMappers. That >>>>>>>>>>>>> should allow you to "construct" the token for particular client exactly how >>>>>>>>>>>>> you want and also use the different value for "sub" claim. >>>>>>>>>>>>> >>>>>>>>>>>>> Another possibility is, to handle this on adapter side. We >>>>>>>>>>>>> already have an adapter option "principal-attribute", which specifies that >>>>>>>>>>>>> application will see the different attribute instead of "sub" as subject. >>>>>>>>>>>>> For example when in appllication you call >>>>>>>>>>>>> "httpServletRequest.getRemoteUser()" it will return "john" instead of >>>>>>>>>>>>> "123456-unique-johns-uuid" . See >>>>>>>>>>>>> https://keycloak.gitbooks.io/securing-client-applications-guide/content/v/2.1/topics/oidc/java/java-adapter-config.html >>>>>>>>>>>>> >>>>>>>>>>>>> Hopefully some of the options can be useful for you? >>>>>>>>>>>>> >>>>>>>>>>>>> Marek >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> On 02/08/16 14:13, Martin Hardselius wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> Me and my team are working towards getting Keycloak, >>>>>>>>>>>>> customized for our needs, into production but we've identified the need for >>>>>>>>>>>>> Pairwise Subject Identifiers as we don't want to expose internal user ids. >>>>>>>>>>>>> >>>>>>>>>>>>> Right now, the only subject_types_supported seems to be >>>>>>>>>>>>> "public". Are there any near-future plans to include "pairwise"? Can we >>>>>>>>>>>>> pitch in with a PR to make this happen as soon as possible? >>>>>>>>>>>>> >>>>>>>>>>>>> Links to relevant sections in the spec: >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> http://openid.net/specs/openid-connect-core-1_0.html#SubjectIDTypes >>>>>>>>>>>>> >>>>>>>>>>>>> http://openid.net/specs/openid-connect-core-1_0.html#PairwiseAlg >>>>>>>>>>>>> >>>>>>>>>>>>> -- >>>>>>>>>>>>> Martin >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>> keycloak-dev mailing listkeycloak-dev at lists.jboss.orghttps://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 >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>> >>>>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160831/1deb7ed4/attachment-0001.html From mposolda at redhat.com Wed Aug 31 08:14:50 2016 From: mposolda at redhat.com (Marek Posolda) Date: Wed, 31 Aug 2016 14:14:50 +0200 Subject: [keycloak-dev] Pairwise Subject Identifier In-Reply-To: References: <57BB6324.2030403@redhat.com> <57BC51CE.9020504@redhat.com> <57BD70E2.50108@redhat.com> Message-ID: <57C6CA3A.80707@redhat.com> Yes, Thanks for sharing. Marek On 31/08/16 13:29, Martin Hardselius wrote: > Just had the chance to start looking at this. Wanted to check with you > if this is the direction you had in mind? > public abstract class AbstractPairwiseSubGeneratorMapperextends AbstractOIDCProtocolMapperimplements OIDCAccessTokenMapper, OIDCIDTokenMapper{ > > @Override > public IDToken transformIDToken(IDToken token, ProtocolMapperModel mappingModel, KeycloakSession session, UserSessionModel userSession, ClientSessionModel clientSession) { > token.setSubject(generateSub(mappingModel, userSession.getUser().getId())); > return token; > } > > @Override > public AccessToken transformAccessToken(AccessToken token, ProtocolMapperModel mappingModel, KeycloakSession session, UserSessionModel userSession, ClientSessionModel clientSession) { > token.setSubject(generateSub(mappingModel, userSession.getUser().getId())); > return token; > } > > public abstract String generateSub(ProtocolMapperModel mappingModel, String localSub); > } > > On Wed, 24 Aug 2016 at 12:03 Marek Posolda > wrote: > > Sounds great. Thanks! > > > Marek > > > On 24/08/16 11:08, Martin Hardselius wrote: >> Sounds good. I'll look into it and see what I can do. Possibly >> during next week. :) >> >> On Tue, 23 Aug 2016 at 15:38 Marek Posolda > > wrote: >> >> We discussed it with Stian a bit and we discussed to: >> >> - Implement as protocolMapper >> >> - There will be possibility to configure "salt" as parameter >> to protocolMapper. It may not be mandatory parameter. If it's >> used, then client will use it as salt, otherwise salt will be >> generated. This allows the use-case you mentioned. You can >> use same salt for clients x,y,z but different salt for >> clients m,n. If you let generate salt, then the subject >> identifiers will be really unique just to the particular client. >> >> - We need to validate sector_identifier_uri during >> create/update of protocolMapper, but also during update of >> client. Otherwise someone can register sector_identifier_uri >> and register the client with valid redirect_uris (for example >> URLs "http://good-host/url1" >> "http://good-host/url2" , which are >> both specified under sector_identifier_uri ) but then later >> update just the client redirect_uris to >> "http://evil-host/url1" . Basically >> he will be able to update redirect_uris to anything he wants >> regardless of redirect_uris under sector_identifier_uri, so >> the whole validation will be bypassed. >> >> For updating client, I've just sent PR, which adds >> RealmModel.ClientUpdatedEvent . You can register to that >> event similarly like >> https://github.com/keycloak/keycloak/blob/master/server-spi/src/main/java/org/keycloak/protocol/AbstractLoginProtocolFactory.java#L39 >> . The creation/update listener for protocolMapper doesn't yet >> exists, however we are likely going to refactor >> protocolMapper to generic component, which will have >> validation support. But that will be likely available in few >> weeks, so for now, we can add something temporary for >> protocolMappers similar to what is available for example for >> UserFederationMapperFactory (See >> https://github.com/keycloak/keycloak/blob/master/services/src/main/java/org/keycloak/services/resources/admin/UserFederationProviderResource.java#L437-L440 >> ) >> >> Martin, will you have some time to eventually look into this >> and send PR ? >> >> >> Marek >> >> >> On 23/08/16 14:25, Martin Hardselius wrote: >>> Let's say we want to force all of our client to use pairwise >>> subs, but a single "merchant" needs to implement several >>> clients where subs should remain the same for all those clients. >>> >>> Merchant A >>> - client x >>> - client y >>> - client z >>> >>> Merchant B >>> - client m >>> - client n >>> >>> You can assume the sector_identifiers are the same across >>> all clients owned by a merchant >>> >>> It should not be possible to correlate activities between >>> Customer A and Customer B (at least not from their side). >>> They should, however, be able to correlate user activities >>> between their own clients. >>> >>> Which implementation of pairwise subs is better suited for >>> supporting this scenario? I'm leaning towards the protocol >>> mapper solution. It should be easier to create custom >>> mappers with merchant-wide configuration (e.g salts). >>> >>> On Mon, 22 Aug 2016 at 22:40 Marek Posolda >>> > wrote: >>> >>> The question is, should we really introduce another SPI >>> for that? Doesn't it mean uneccessary complexity? Also >>> add the new options directly to the client for the >>> feature, which is likely interesting just for quite >>> limited amount of people? >>> >>> IMO it's fine if this is implemented as protocolMapper? >>> >>> Few thoughts: >>> - We can have abstract superclass like >>> AbstractPairwiseSubGeneratorMapper . The subclasses will >>> just need to implement method "generateSub" . We can >>> have just one concrete impl, which will use SHA-256( >>> sector_identifier || local_sub || salt ) >>> >>> - The sector_identifier_uri will be a configuration >>> option of this protocolMapper implementation. >>> >>> - If protocolMapper is not added to client, the client >>> will just use the public subjects. By default it's not >>> added, which ensures backwards compatibility and public >>> subjects by default. Note that with this approach, we >>> don't even need subject_type option on the client. >>> >>> - The salt can be generated lazily at the first time >>> when mapper is used. >>> >>> - The validation can be done at the moment, when >>> protocolMapper is going to be created/updated. Right >>> now, we don't have validation callback during >>> protocolMapper creation/update. However Bill is going to >>> add support for that into generic componentModel. So if >>> we're going to refactor protocolMapper to use the new >>> generic component model, we will have validation >>> callback available to protocolMapper SPI. The validation >>> will fail if array of redirect_uri from >>> sector_identifier_uri doesn't contain the uris from >>> redirect_uri of particular client (including wildcards >>> etc). >>> >>> - If client is updated and it's redirect_uri are >>> changed, we won't be able to catch this, however this is >>> not strictly required per specs per my understanding. At >>> least the dynamic client registration specs sais [1] >>> >>> "The values registered in redirect_uris MUST be included >>> in the elements of the array, or registration MUST fail. >>> This MUST be validated at registration time; there is no >>> requirement for the OP to retain the contents of this >>> JSON file or to retrieve or revalidate its contents in >>> the future. " >>> >>> [1] >>> http://openid.net/specs/openid-connect-registration-1_0.html#SectorIdentifierValidation >>> >>> >>> Marek >>> >>> >>> On 22/08/16 15:50, Martin Hardselius wrote: >>>> Ok, thanks for the clarification. >>>> >>>> Where would it make sense to put the >>>> PairwiseSubGeneratorSpi? Which package, that is? >>>> >>>> On Mon, 22 Aug 2016 at 14:51 Stian Thorgersen >>>> > wrote: >>>> >>>> On 22 August 2016 at 14:16, Martin Hardselius >>>> >>> > wrote: >>>> >>>> "IMO it's sufficient to document the algorithm >>>> to create the sub, which should make it clear >>>> that the origin in the redirect uri will affect >>>> the sub." >>>> >>>> Reasonable. :) >>>> >>>> "One client could also have multiple redirect >>>> uris with different origins so could get >>>> different sub's generated depending on the >>>> redirect uri used." >>>> >>>> That case is probably caught by >>>> [...] If there are multiple hostnames in the >>>> registeredredirect_uris, the Client MUST >>>> register asector_identifier_uri. [...] >>>> >>>> >>>> Yes, but I meant from a documentation perspective. >>>> It should be clear from the documentation that is >>>> the case. >>>> >>>> >>>> On Mon, 22 Aug 2016 at 10:42 Stian Thorgersen >>>> >>> > wrote: >>>> >>>> IMO it's sufficient to document the >>>> algorithm to create the sub, which should >>>> make it clear that the origin in the >>>> redirect uri will affect the sub. One >>>> client could also have multiple redirect >>>> uris with different origins so could get >>>> different sub's generated depending on the >>>> redirect uri used. >>>> >>>> On 22 August 2016 at 09:58, Martin >>>> Hardselius >>> > wrote: >>>> >>>> Sounds fair enough. >>>> >>>> What about the case where you don't >>>> provide a sector_identifier_uri, set up >>>> a single redirect uri on myhost and >>>> then later go on to change that >>>> redirect uri to something on >>>> myotherhost? That would change the >>>> sector_identifier and subsequently all >>>> the user subs. Do we protect against >>>> such "mistakes" or do we warn people >>>> (in the docs and/or admin gui) that >>>> it's not a good idea to do that? >>>> >>>> On Mon, 22 Aug 2016 at 09:38 Stian >>>> Thorgersen >>> > wrote: >>>> >>>> We need to follow the spec and >>>> verify that sector_identifier_uri >>>> points to a URL that contains the >>>> corresponding URIs. As an >>>> enhancement we could support >>>> wildcards in the JSON returned >>>> by sector_identifier_uri. For >>>> example if it returns: >>>> >>>> [https://www.mydomain.com/*, >>>> https://www.myotherdomain.com/* ] >>>> >>>> A client with the redirect uri >>>> 'https://www.myotherdomain.com/myapp' >>>> would work >>>> >>>> On 18 August 2016 at 15:09, Martin >>>> Hardselius >>>> >>> > >>>> wrote: >>>> >>>> Speaking of subject_identifier_uri >>>> >>>> From the spec: >>>> >>>> "When asector_identifier_uriis >>>> provided, the host component of >>>> that URL is used as the Sector >>>> Identifier for the pairwise >>>> identifier calculation. The >>>> value of >>>> thesector_identifier_uriMUST be >>>> a URL using thehttpsscheme that >>>> points to a JSON file >>>> containing an array >>>> ofredirect_urivalues. The >>>> values of the >>>> registeredredirect_urisMUST be >>>> included in the elements of the >>>> array." >>>> >>>> What's your stance on >>>> sanity/health checking the >>>> sector_identifier_uri? URI >>>> validation is one thing, but >>>> should we also make a request >>>> to the uri in order to validate >>>> the response? >>>> >>>> The spec also mentions that the >>>> sector_identifier_uri isn't >>>> strictly required if a client >>>> has all it's redirect_uris >>>> under the same domain. How do >>>> we deal with changes to clients >>>> if the sector_identifier_uri >>>> isn't required for enabling >>>> pairwise subs? >>>> >>>> Example: >>>> >>>> I create a client, enabling >>>> pairwise subs. Valid >>>> redirect_uris are [ >>>> https://www.mydomain.com/* ]. >>>> The sector_identifier would be >>>> mydomain. >>>> >>>> Later on, I update the >>>> redirect_uris to >>>> [https://www.mydomain.com/*, >>>> https://www.myotherdomain.com/* ] >>>> Do we >>>> >>>> * keep the old >>>> sector_identifier, or >>>> * reject the update, or >>>> * allow the update if a valid >>>> subject_identifier_uri is >>>> provided at mydomain, or >>>> * just allow it and let the >>>> client devs deal with the >>>> consequences, or >>>> * take some other path you can >>>> think of ? >>>> >>>> Having the >>>> sector_identifier_uri as a hard >>>> requirement seems safer, but >>>> it's also means more work >>>> implementing a client. Leaving >>>> it optional is a lot more scary. >>>> >>>> >>>> On Thu, 18 Aug 2016 at 10:45 >>>> Stian Thorgersen >>>> >>> > >>>> wrote: >>>> >>>> Makes sense to make this >>>> pluggable. The default >>>> should probably SHA-256( >>>> sector_identifier || >>>> local_sub || salt ). >>>> >>>> We would love a PR for >>>> this, but there's a few >>>> bits required: >>>> >>>> * OIDC clients need option >>>> for subject type and >>>> sector_identifier_uri. If >>>> not set it should default >>>> to public so existing >>>> clients continue to work. >>>> These options can just be >>>> set as client attributes so >>>> there's no need to update >>>> db schema >>>> * Admin console update for >>>> the above >>>> * >>>> PairwiseSubGeneratorSpi and >>>> default implementation >>>> * Generation of salt for >>>> clients. This should be >>>> done when a client sets >>>> subject type to pairwise >>>> * Tests and docs >>>> >>>> I'd say the >>>> PairwiseSubGeneratorSpi >>>> signature should probably be: >>>> >>>> * public String >>>> getPairwiseSub(UserModel >>>> user, ClientModel client) >>>> >>>> It might even be an option >>>> to let the >>>> default PairwiseSubGenerator provider >>>> create the salt and store >>>> it as an attribute on the >>>> client, making that part >>>> pluggable as well. >>>> >>>> On 17 August 2016 at 15:59, >>>> Martin Hardselius >>>> > >>>> wrote: >>>> >>>> I'm going to bump this, >>>> as I want to continue >>>> the discussion/provide >>>> some input. >>>> >>>> Does it make sense to >>>> support more than type >>>> of pairwise subject >>>> identifier generator? >>>> E.g through a >>>> PairwiseSubGeneratorSpi? >>>> >>>> Let's say I want to >>>> generate the pairwise >>>> sub as a salted hash: >>>> sub = SHA-256( >>>> sector_identifier || >>>> local_sub || salt ) >>>> To me, it makes sense >>>> to allow for per-client >>>> salts. These salts >>>> should probably be >>>> generated and persisted >>>> during client creation. >>>> Thoughts? >>>> >>>> On Fri, 12 Aug 2016 at >>>> 09:57 Martin Hardselius >>>> >>> > >>>> wrote: >>>> >>>> Thank you for your >>>> response. Did not >>>> see that ticket >>>> before. Great news! >>>> >>>> I looked into using >>>> protocol mappers to >>>> achieve this, and >>>> while it would work >>>> I'm worried that >>>> once KEYCLOAK-3422 >>>> has been resolved >>>> and included in a >>>> proper release we >>>> would run into >>>> migration issues if >>>> the method used for >>>> calculating >>>> "native" pairwise >>>> subs is different >>>> from what we >>>> implement. Clients >>>> could loose / be >>>> forced to >>>> re-register all >>>> their users if we >>>> decide to switch. >>>> The example methods >>>> in the spec are >>>> just that. >>>> Examples. Maybe the >>>> method/alg for >>>> computing the >>>> pairwise sub should >>>> be pluggable? >>>> >>>> -- >>>> Martin >>>> >>>> On Thu, 11 Aug 2016 >>>> at 17:15 Marek >>>> Posolda >>>> > >>>> wrote: >>>> >>>> Sorry for late >>>> response. >>>> >>>> We have JIRA >>>> created for >>>> that. You can >>>> possibly add >>>> yourself as a >>>> watcher. See >>>> https://issues.jboss.org/browse/KEYCLOAK-3422 >>>> >>>> Maybe an >>>> alternative for >>>> you is to use >>>> protocolMappers. That >>>> should allow >>>> you to >>>> "construct" the >>>> token for >>>> particular >>>> client exactly >>>> how you want >>>> and also use >>>> the different >>>> value for "sub" >>>> claim. >>>> >>>> Another >>>> possibility is, >>>> to handle this >>>> on adapter >>>> side. We >>>> already have an >>>> adapter option >>>> "principal-attribute", >>>> which specifies >>>> that >>>> application >>>> will see the >>>> different >>>> attribute >>>> instead of >>>> "sub" as >>>> subject. For >>>> example when in >>>> appllication >>>> you call >>>> "httpServletRequest.getRemoteUser()" >>>> it will return >>>> "john" instead >>>> of >>>> "123456-unique-johns-uuid" >>>> . See >>>> https://keycloak.gitbooks.io/securing-client-applications-guide/content/v/2.1/topics/oidc/java/java-adapter-config.html >>>> >>>> Hopefully some >>>> of the options >>>> can be useful >>>> for you? >>>> >>>> Marek >>>> >>>> >>>> On 02/08/16 >>>> 14:13, Martin >>>> Hardselius wrote: >>>>> Me and my team >>>>> are working >>>>> towards >>>>> getting >>>>> Keycloak, >>>>> customized for >>>>> our needs, >>>>> into >>>>> production but >>>>> we've >>>>> identified the >>>>> need for >>>>> Pairwise >>>>> Subject >>>>> Identifiers as >>>>> we don't want >>>>> to expose >>>>> internal user ids. >>>>> >>>>> Right now, the >>>>> only >>>>> subject_types_supported >>>>> seems to be >>>>> "public". Are >>>>> there any >>>>> near-future >>>>> plans to >>>>> include >>>>> "pairwise"? >>>>> Can we pitch >>>>> in with a PR >>>>> to make this >>>>> happen as soon >>>>> as possible? >>>>> >>>>> Links to >>>>> relevant >>>>> sections in >>>>> the spec: >>>>> >>>>> http://openid.net/specs/openid-connect-core-1_0.html#SubjectIDTypes >>>>> http://openid.net/specs/openid-connect-core-1_0.html#PairwiseAlg >>>>> >>>>> -- >>>>> Martin >>>>> >>>>> >>>>> _______________________________________________ >>>>> 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 >>>> >>>> >>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160831/d8251902/attachment-0001.html From singhrasster at gmail.com Wed Aug 31 09:28:27 2016 From: singhrasster at gmail.com (Rashmi Singh) Date: Wed, 31 Aug 2016 08:28:27 -0500 Subject: [keycloak-dev] Edit value contained in NameID field of SAML response In-Reply-To: References: Message-ID: Any help on this? On Mon, Aug 29, 2016 at 9:32 PM, Rashmi Singh wrote: > I have a keycloak app that calls an external TokenValidator for > authentication. This TokenValidator returns a SP specific username value. I > want my SAML response to contain this value in the NameID field. My > question is how do I edit the SAML response to change the value in NameID > field to this value? > > Any insight into how to edit the NameID field in the SAML response? > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160831/14941432/attachment.html