From sthorger at redhat.com Mon May 2 04:56:22 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Mon, 2 May 2016 10:56:22 +0200 Subject: [keycloak-dev] Thinking about step-up authentication and token timeouts In-Reply-To: <6b9e58e9-65f9-87ac-8991-f6ccab25aca8@redhat.com> References: <6b9e58e9-65f9-87ac-8991-f6ccab25aca8@redhat.com> Message-ID: Wouldn't saml support it fairly easily? It's just another auth request with SE different params? On 29 Apr 2016 16:19, "Bill Burke" wrote: > Sounds great. I hope we don't have to implement this for SAML too ;) > > On 4/29/2016 12:02 AM, Stian Thorgersen wrote: > > Clients should be able to obtain tokens with reduced scope and longer or > shorter expiration, then later request new tokens with increased scope and > different expiration. They should also be able to require different levels > of authentication and also require re-authentication. > > An application may for example: > > * At first only need users email - this would allow showing the name + > email. In this situation a long expiration access token in combination with > implicit flow would do. It's also not necessary to re-authenticate the user > and a user that has been logged-in for months or even a year is fine. > > * When a user clicks on orders it would require the password and extend > scope to be able to view orders. Now you'll want to switch to short > expiration access tokens and authorization code grant. You'll also want to > make sure the user logged-in fairly recently, max 30 days could be sensible. > > * When a user tries to purchase something the user now has to provide the > OTP to be able to purchase with saved credit card details. You'll also want > to make sure the user logged-in very recently, max a day could be required. > There may also be cases where you always want the user to re-authenticate, > for example when trying to purchase something over a certain price level. > > > _______________________________________________ > keycloak-dev mailing listkeycloak-dev at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-dev > > > -- > Bill Burke > JBoss, a division of Red Hathttp://bill.burkecentral.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/20160502/d5ba9263/attachment.html From bburke at redhat.com Mon May 2 08:54:55 2016 From: bburke at redhat.com (Bill Burke) Date: Mon, 2 May 2016 08:54:55 -0400 Subject: [keycloak-dev] Thinking about step-up authentication and token timeouts In-Reply-To: References: <6b9e58e9-65f9-87ac-8991-f6ccab25aca8@redhat.com> Message-ID: <4d2c6034-ee77-33ab-7135-8c1c54996b0d@redhat.com> I have no idea. What you are describing is different. Its scope, SAML probably has it, but I don't know what it is. You also describe a token exchange service On 5/2/2016 4:56 AM, Stian Thorgersen wrote: > > Wouldn't saml support it fairly easily? It's just another auth request > with SE different params? > > On 29 Apr 2016 16:19, "Bill Burke" > wrote: > > Sounds great. I hope we don't have to implement this for SAML too ;) > > On 4/29/2016 12:02 AM, Stian Thorgersen wrote: >> Clients should be able to obtain tokens with reduced scope and >> longer or shorter expiration, then later request new tokens with >> increased scope and different expiration. They should also be >> able to require different levels of authentication and also >> require re-authentication. >> >> An application may for example: >> >> * At first only need users email - this would allow showing the >> name + email. In this situation a long expiration access token in >> combination with implicit flow would do. It's also not necessary >> to re-authenticate the user and a user that has been logged-in >> for months or even a year is fine. >> >> * When a user clicks on orders it would require the password and >> extend scope to be able to view orders. Now you'll want to switch >> to short expiration access tokens and authorization code grant. >> You'll also want to make sure the user logged-in fairly recently, >> max 30 days could be sensible. >> >> * When a user tries to purchase something the user now has to >> provide the OTP to be able to purchase with saved credit card >> details. You'll also want to make sure the user logged-in very >> recently, max a day could be required. There may also be cases >> where you always want the user to re-authenticate, for example >> when trying to purchase something over a certain price level. >> >> >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev > > -- > Bill Burke > JBoss, a division of Red Hat > http://bill.burkecentral.com > > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160502/493360af/attachment.html From sthorger at redhat.com Mon May 2 09:10:57 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Mon, 2 May 2016 15:10:57 +0200 Subject: [keycloak-dev] Thinking about step-up authentication and token timeouts In-Reply-To: <4d2c6034-ee77-33ab-7135-8c1c54996b0d@redhat.com> References: <6b9e58e9-65f9-87ac-8991-f6ccab25aca8@redhat.com> <4d2c6034-ee77-33ab-7135-8c1c54996b0d@redhat.com> Message-ID: I wasn't thinking a token exchange, I was thinking it would just do a new authentication request with different scope, etc.. On 2 May 2016 at 14:54, Bill Burke wrote: > I have no idea. What you are describing is different. Its scope, SAML > probably has it, but I don't know what it is. You also describe a token > exchange service > > On 5/2/2016 4:56 AM, Stian Thorgersen wrote: > > Wouldn't saml support it fairly easily? It's just another auth request > with SE different params? > On 29 Apr 2016 16:19, "Bill Burke" < bburke at redhat.com> > wrote: > >> Sounds great. I hope we don't have to implement this for SAML too ;) >> >> On 4/29/2016 12:02 AM, Stian Thorgersen wrote: >> >> Clients should be able to obtain tokens with reduced scope and longer or >> shorter expiration, then later request new tokens with increased scope and >> different expiration. They should also be able to require different levels >> of authentication and also require re-authentication. >> >> An application may for example: >> >> * At first only need users email - this would allow showing the name + >> email. In this situation a long expiration access token in combination with >> implicit flow would do. It's also not necessary to re-authenticate the user >> and a user that has been logged-in for months or even a year is fine. >> >> * When a user clicks on orders it would require the password and extend >> scope to be able to view orders. Now you'll want to switch to short >> expiration access tokens and authorization code grant. You'll also want to >> make sure the user logged-in fairly recently, max 30 days could be sensible. >> >> * When a user tries to purchase something the user now has to provide the >> OTP to be able to purchase with saved credit card details. You'll also want >> to make sure the user logged-in very recently, max a day could be required. >> There may also be cases where you always want the user to re-authenticate, >> for example when trying to purchase something over a certain price level. >> >> >> _______________________________________________ >> keycloak-dev mailing listkeycloak-dev at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-dev >> >> >> -- >> Bill Burke >> JBoss, a division of Red Hathttp://bill.burkecentral.com >> >> >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> > > -- > Bill Burke > JBoss, a division of Red Hathttp://bill.burkecentral.com > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160502/8d038146/attachment.html From corinnekrych at gmail.com Mon May 2 16:11:20 2016 From: corinnekrych at gmail.com (Corinne Krych) Date: Mon, 2 May 2016 22:11:20 +0200 Subject: [keycloak-dev] Failed to verify token: org.keycloak.common.VerificationException: Realm URL is null. Message-ID: Hello Keycloak team, I'm trying to move my OAuth2 demo app from Keyclaok 1.5 to Keyclaok 1.9.1. I've change the OAuth2 endpoints for the access token. I manage the Oauth2 dansc ok but when trying to access a protected resource I hit the error: 22:00:13,501 ERROR [org.keycloak.adapters.BearerTokenRequestAuthenticator] (default task-101) Failed to verify token: org.keycloak.common.VerificationException: Realm URL is null. Make sure to add auth-server-url to the configuration of your adapter! at org.keycloak.RSATokenVerifier.verifyToken(RSATokenVerifier.java:46) at org.keycloak.RSATokenVerifier.verifyToken(RSATokenVerifier.java:35) at org.keycloak.adapters.BearerTokenRequestAuthenticator.authenticateToken(BearerTokenRequestAuthenticator.java:87) at org.keycloak.adapters.BearerTokenRequestAuthenticator.authenticate(BearerTokenRequestAuthenticator.java:82) at org.keycloak.adapters.RequestAuthenticator.authenticate(RequestAuthenticator.java:65) at org.keycloak.adapters.undertow.AbstractUndertowKeycloakAuthMech.keycloakAuthenticate(AbstractUndertowKeycloakAuthMech.java:110) at org.keycloak.adapters.undertow.ServletKeycloakAuthMech.authenticate(ServletKeycloakAuthMech.java:92) at io.undertow.security.impl.SecurityContextImpl$AuthAttempter.transition(SecurityContextImpl.java:233) at io.undertow.security.impl.SecurityContextImpl$AuthAttempter.transition(SecurityContextImpl.java:250) at io.undertow.security.impl.SecurityContextImpl$AuthAttempter.access$100(SecurityContextImpl.java:219) at io.undertow.security.impl.SecurityContextImpl.attemptAuthentication(SecurityContextImpl.java:121) at io.undertow.security.impl.SecurityContextImpl.authTransition(SecurityContextImpl.java:96) at io.undertow.security.impl.SecurityContextImpl.authenticate(SecurityContextImpl.java:89) at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:55) at io.undertow.server.handlers.DisableCacheHandler.handleRequest(DisableCacheHandler.java:33) at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) at io.undertow.security.handlers.AuthenticationConstraintHandler.handleRequest(AuthenticationConstraintHandler.java:51) at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46) at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64) at io.undertow.servlet.handlers.security.ServletSecurityConstraintHandler.handleRequest(ServletSecurityConstraintHandler.java:56) at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60) at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77) at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50) at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43) at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61) at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) at org.keycloak.adapters.undertow.ServletPreAuthActionsHandler.handleRequest(ServletPreAuthActionsHandler.java:69) at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:284) at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:263) at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81) at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:174) at io.undertow.server.Connectors.executeRootHandler(Connectors.java:202) at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:793) 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) My realm setup is here: https://github.com/aerogear/aerogear-backend-cookbook/blob/master/Shoot/configuration/shoot-realm.json The keycloak.json used for the protected endpoint is: https://github.com/aerogear/aerogear-backend-cookbook/blob/master/Shoot/src/main/webapp/WEB-INF/keycloak.json Is there some specific settings I should add to work with Keycloak 1.9.x? Your help would be welcome. ++ Corinne -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160502/849db7a0/attachment-0001.html From bruno at abstractj.org Mon May 2 18:13:34 2016 From: bruno at abstractj.org (Bruno Oliveira) Date: Mon, 2 May 2016 19:13:34 -0300 Subject: [keycloak-dev] Failed to verify token: org.keycloak.common.VerificationException: Realm URL is null. In-Reply-To: References: Message-ID: <20160502221334.GA15838@abstractj.org> Hi Corinne, I tried here with Keycloak 1.9.3.Final and couldn't reproduce your issue. I followed exactly the same steps described at your readme file. On 2016-05-02, Corinne Krych wrote: > Hello Keycloak team, > > I'm trying to move my OAuth2 demo app from Keyclaok 1.5 to Keyclaok 1.9.1. > I've change the OAuth2 endpoints for the access token. I manage the Oauth2 > dansc ok but when trying to access a protected resource I hit the error: > > 22:00:13,501 ERROR [org.keycloak.adapters.BearerTokenRequestAuthenticator] > (default task-101) Failed to verify token: > org.keycloak.common.VerificationException: Realm URL is null. Make sure to > add auth-server-url to the configuration of your adapter! > at org.keycloak.RSATokenVerifier.verifyToken(RSATokenVerifier.java:46) > at org.keycloak.RSATokenVerifier.verifyToken(RSATokenVerifier.java:35) > at > org.keycloak.adapters.BearerTokenRequestAuthenticator.authenticateToken(BearerTokenRequestAuthenticator.java:87) > at > org.keycloak.adapters.BearerTokenRequestAuthenticator.authenticate(BearerTokenRequestAuthenticator.java:82) > at > org.keycloak.adapters.RequestAuthenticator.authenticate(RequestAuthenticator.java:65) > at > org.keycloak.adapters.undertow.AbstractUndertowKeycloakAuthMech.keycloakAuthenticate(AbstractUndertowKeycloakAuthMech.java:110) > at > org.keycloak.adapters.undertow.ServletKeycloakAuthMech.authenticate(ServletKeycloakAuthMech.java:92) > at > io.undertow.security.impl.SecurityContextImpl$AuthAttempter.transition(SecurityContextImpl.java:233) > at > io.undertow.security.impl.SecurityContextImpl$AuthAttempter.transition(SecurityContextImpl.java:250) > at > io.undertow.security.impl.SecurityContextImpl$AuthAttempter.access$100(SecurityContextImpl.java:219) > at > io.undertow.security.impl.SecurityContextImpl.attemptAuthentication(SecurityContextImpl.java:121) > at > io.undertow.security.impl.SecurityContextImpl.authTransition(SecurityContextImpl.java:96) > at > io.undertow.security.impl.SecurityContextImpl.authenticate(SecurityContextImpl.java:89) > at > io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:55) > at > io.undertow.server.handlers.DisableCacheHandler.handleRequest(DisableCacheHandler.java:33) > at > io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > at > io.undertow.security.handlers.AuthenticationConstraintHandler.handleRequest(AuthenticationConstraintHandler.java:51) > at > io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46) > at > io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64) > at > io.undertow.servlet.handlers.security.ServletSecurityConstraintHandler.handleRequest(ServletSecurityConstraintHandler.java:56) > at > io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60) > at > io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77) > at > io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50) > at > io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43) > at > io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > at > org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61) > at > io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > at > org.keycloak.adapters.undertow.ServletPreAuthActionsHandler.handleRequest(ServletPreAuthActionsHandler.java:69) > at > io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > at > io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:284) > at > io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:263) > at > io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81) > at > io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:174) > at io.undertow.server.Connectors.executeRootHandler(Connectors.java:202) > at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:793) > 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) > > My realm setup is here: > https://github.com/aerogear/aerogear-backend-cookbook/blob/master/Shoot/configuration/shoot-realm.json > > The keycloak.json used for the protected endpoint is: > https://github.com/aerogear/aerogear-backend-cookbook/blob/master/Shoot/src/main/webapp/WEB-INF/keycloak.json > > Is there some specific settings I should add to work with Keycloak 1.9.x? > > Your help would be welcome. > > ++ > Corinne > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev -- abstractj PGP: 0x84DC9914 From corinnekrych at gmail.com Tue May 3 02:35:06 2016 From: corinnekrych at gmail.com (Corinne Krych) Date: Tue, 3 May 2016 08:35:06 +0200 Subject: [keycloak-dev] Failed to verify token: org.keycloak.common.VerificationException: Realm URL is null. In-Reply-To: <20160502221334.GA15838@abstractj.org> References: <20160502221334.GA15838@abstractj.org> Message-ID: Ah let me try with KC1.9.3.Final then. ++ Corinne On 3 May 2016 at 00:13, Bruno Oliveira wrote: > Hi Corinne, I tried here with Keycloak 1.9.3.Final and couldn't > reproduce your issue. > > I followed exactly the same steps described at your readme file. > > On 2016-05-02, Corinne Krych wrote: > > Hello Keycloak team, > > > > I'm trying to move my OAuth2 demo app from Keyclaok 1.5 to Keyclaok > 1.9.1. > > I've change the OAuth2 endpoints for the access token. I manage the > Oauth2 > > dansc ok but when trying to access a protected resource I hit the error: > > > > 22:00:13,501 ERROR > [org.keycloak.adapters.BearerTokenRequestAuthenticator] > > (default task-101) Failed to verify token: > > org.keycloak.common.VerificationException: Realm URL is null. Make sure > to > > add auth-server-url to the configuration of your adapter! > > at org.keycloak.RSATokenVerifier.verifyToken(RSATokenVerifier.java:46) > > at org.keycloak.RSATokenVerifier.verifyToken(RSATokenVerifier.java:35) > > at > > > org.keycloak.adapters.BearerTokenRequestAuthenticator.authenticateToken(BearerTokenRequestAuthenticator.java:87) > > at > > > org.keycloak.adapters.BearerTokenRequestAuthenticator.authenticate(BearerTokenRequestAuthenticator.java:82) > > at > > > org.keycloak.adapters.RequestAuthenticator.authenticate(RequestAuthenticator.java:65) > > at > > > org.keycloak.adapters.undertow.AbstractUndertowKeycloakAuthMech.keycloakAuthenticate(AbstractUndertowKeycloakAuthMech.java:110) > > at > > > org.keycloak.adapters.undertow.ServletKeycloakAuthMech.authenticate(ServletKeycloakAuthMech.java:92) > > at > > > io.undertow.security.impl.SecurityContextImpl$AuthAttempter.transition(SecurityContextImpl.java:233) > > at > > > io.undertow.security.impl.SecurityContextImpl$AuthAttempter.transition(SecurityContextImpl.java:250) > > at > > > io.undertow.security.impl.SecurityContextImpl$AuthAttempter.access$100(SecurityContextImpl.java:219) > > at > > > io.undertow.security.impl.SecurityContextImpl.attemptAuthentication(SecurityContextImpl.java:121) > > at > > > io.undertow.security.impl.SecurityContextImpl.authTransition(SecurityContextImpl.java:96) > > at > > > io.undertow.security.impl.SecurityContextImpl.authenticate(SecurityContextImpl.java:89) > > at > > > io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:55) > > at > > > io.undertow.server.handlers.DisableCacheHandler.handleRequest(DisableCacheHandler.java:33) > > at > > > io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > > at > > > io.undertow.security.handlers.AuthenticationConstraintHandler.handleRequest(AuthenticationConstraintHandler.java:51) > > at > > > io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46) > > at > > > io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64) > > at > > > io.undertow.servlet.handlers.security.ServletSecurityConstraintHandler.handleRequest(ServletSecurityConstraintHandler.java:56) > > at > > > io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60) > > at > > > io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77) > > at > > > io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50) > > at > > > io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43) > > at > > > io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > > at > > > org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61) > > at > > > io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > > at > > > org.keycloak.adapters.undertow.ServletPreAuthActionsHandler.handleRequest(ServletPreAuthActionsHandler.java:69) > > at > > > io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > > at > > > io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:284) > > at > > > io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:263) > > at > > > io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81) > > at > > > io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:174) > > at io.undertow.server.Connectors.executeRootHandler(Connectors.java:202) > > at > io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:793) > > 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) > > > > My realm setup is here: > > > https://github.com/aerogear/aerogear-backend-cookbook/blob/master/Shoot/configuration/shoot-realm.json > > > > The keycloak.json used for the protected endpoint is: > > > https://github.com/aerogear/aerogear-backend-cookbook/blob/master/Shoot/src/main/webapp/WEB-INF/keycloak.json > > > > Is there some specific settings I should add to work with Keycloak 1.9.x? > > > > Your help would be welcome. > > > > ++ > > Corinne > > > _______________________________________________ > > 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/20160503/e3c332b3/attachment.html From corinnekrych at gmail.com Tue May 3 03:04:06 2016 From: corinnekrych at gmail.com (Corinne Krych) Date: Tue, 3 May 2016 09:04:06 +0200 Subject: [keycloak-dev] Failed to verify token: org.keycloak.common.VerificationException: Realm URL is null. In-Reply-To: References: <20160502221334.GA15838@abstractj.org> Message-ID: Hello Bruno I've tried with Keycloak-demo-1.9.3 and I still hit the issue: 09:02:27,847 ERROR [org.keycloak.adapters.BearerTokenRequestAuthenticator] (default task-74) Failed to verify token: org.keycloak.common.VerificationException: Realm URL is null. Make sure to add auth-server-url to the configuration of your adapter! at org.keycloak.RSATokenVerifier.verifyToken(RSATokenVerifier.java:46) at org.keycloak.RSATokenVerifier.verifyToken(RSATokenVerifier.java:35) I think the secure endpoint is missing some configuration but not sure what i'm missing. ++ Corinne On 3 May 2016 at 08:35, Corinne Krych wrote: > Ah let me try with KC1.9.3.Final then. > > ++ > Corinne > > On 3 May 2016 at 00:13, Bruno Oliveira wrote: > >> Hi Corinne, I tried here with Keycloak 1.9.3.Final and couldn't >> reproduce your issue. >> >> I followed exactly the same steps described at your readme file. >> >> On 2016-05-02, Corinne Krych wrote: >> > Hello Keycloak team, >> > >> > I'm trying to move my OAuth2 demo app from Keyclaok 1.5 to Keyclaok >> 1.9.1. >> > I've change the OAuth2 endpoints for the access token. I manage the >> Oauth2 >> > dansc ok but when trying to access a protected resource I hit the error: >> > >> > 22:00:13,501 ERROR >> [org.keycloak.adapters.BearerTokenRequestAuthenticator] >> > (default task-101) Failed to verify token: >> > org.keycloak.common.VerificationException: Realm URL is null. Make sure >> to >> > add auth-server-url to the configuration of your adapter! >> > at org.keycloak.RSATokenVerifier.verifyToken(RSATokenVerifier.java:46) >> > at org.keycloak.RSATokenVerifier.verifyToken(RSATokenVerifier.java:35) >> > at >> > >> org.keycloak.adapters.BearerTokenRequestAuthenticator.authenticateToken(BearerTokenRequestAuthenticator.java:87) >> > at >> > >> org.keycloak.adapters.BearerTokenRequestAuthenticator.authenticate(BearerTokenRequestAuthenticator.java:82) >> > at >> > >> org.keycloak.adapters.RequestAuthenticator.authenticate(RequestAuthenticator.java:65) >> > at >> > >> org.keycloak.adapters.undertow.AbstractUndertowKeycloakAuthMech.keycloakAuthenticate(AbstractUndertowKeycloakAuthMech.java:110) >> > at >> > >> org.keycloak.adapters.undertow.ServletKeycloakAuthMech.authenticate(ServletKeycloakAuthMech.java:92) >> > at >> > >> io.undertow.security.impl.SecurityContextImpl$AuthAttempter.transition(SecurityContextImpl.java:233) >> > at >> > >> io.undertow.security.impl.SecurityContextImpl$AuthAttempter.transition(SecurityContextImpl.java:250) >> > at >> > >> io.undertow.security.impl.SecurityContextImpl$AuthAttempter.access$100(SecurityContextImpl.java:219) >> > at >> > >> io.undertow.security.impl.SecurityContextImpl.attemptAuthentication(SecurityContextImpl.java:121) >> > at >> > >> io.undertow.security.impl.SecurityContextImpl.authTransition(SecurityContextImpl.java:96) >> > at >> > >> io.undertow.security.impl.SecurityContextImpl.authenticate(SecurityContextImpl.java:89) >> > at >> > >> io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:55) >> > at >> > >> io.undertow.server.handlers.DisableCacheHandler.handleRequest(DisableCacheHandler.java:33) >> > at >> > >> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) >> > at >> > >> io.undertow.security.handlers.AuthenticationConstraintHandler.handleRequest(AuthenticationConstraintHandler.java:51) >> > at >> > >> io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46) >> > at >> > >> io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64) >> > at >> > >> io.undertow.servlet.handlers.security.ServletSecurityConstraintHandler.handleRequest(ServletSecurityConstraintHandler.java:56) >> > at >> > >> io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60) >> > at >> > >> io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77) >> > at >> > >> io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50) >> > at >> > >> io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43) >> > at >> > >> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) >> > at >> > >> org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61) >> > at >> > >> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) >> > at >> > >> org.keycloak.adapters.undertow.ServletPreAuthActionsHandler.handleRequest(ServletPreAuthActionsHandler.java:69) >> > at >> > >> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) >> > at >> > >> io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:284) >> > at >> > >> io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:263) >> > at >> > >> io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81) >> > at >> > >> io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:174) >> > at io.undertow.server.Connectors.executeRootHandler(Connectors.java:202) >> > at >> io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:793) >> > 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) >> > >> > My realm setup is here: >> > >> https://github.com/aerogear/aerogear-backend-cookbook/blob/master/Shoot/configuration/shoot-realm.json >> > >> > The keycloak.json used for the protected endpoint is: >> > >> https://github.com/aerogear/aerogear-backend-cookbook/blob/master/Shoot/src/main/webapp/WEB-INF/keycloak.json >> > >> > Is there some specific settings I should add to work with Keycloak >> 1.9.x? >> > >> > Your help would be welcome. >> > >> > ++ >> > Corinne >> >> > _______________________________________________ >> > 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/20160503/9f1d2ac6/attachment-0001.html From mposolda at redhat.com Tue May 3 03:20:06 2016 From: mposolda at redhat.com (Marek Posolda) Date: Tue, 3 May 2016 09:20:06 +0200 Subject: [keycloak-dev] Failed to verify token: org.keycloak.common.VerificationException: Realm URL is null. In-Reply-To: References: <20160502221334.GA15838@abstractj.org> Message-ID: <57285126.4040305@redhat.com> Strange, this error usually happens if you don't have "auth-server-url" in the configuration of keycloak.json . But you have it in https://github.com/aerogear/aerogear-backend-cookbook/blob/master/Shoot/src/main/webapp/WEB-INF/keycloak.json as you pointed in the first mail. Isn't any chance there is other REST backend, which you are calling and which is missing this? If not, then can you try to temporarily use absolute URL like: "auth-server-url" : "http://localhost:8080/auth" and see if it helps? Marek On 03/05/16 09:04, Corinne Krych wrote: > Hello Bruno > > I've tried with Keycloak-demo-1.9.3 and I still hit the issue: > > 09:02:27,847 ERROR > [org.keycloak.adapters.BearerTokenRequestAuthenticator] (default > task-74) Failed to verify token: > org.keycloak.common.VerificationException: Realm URL is null. Make > sure to add auth-server-url to the configuration of your adapter! > > at org.keycloak.RSATokenVerifier.verifyToken(RSATokenVerifier.java:46) > > at org.keycloak.RSATokenVerifier.verifyToken(RSATokenVerifier.java:35) > > I think the secure endpoint is missing some configuration but not sure > what i'm missing. > > ++ > > Corinne > > > On 3 May 2016 at 08:35, Corinne Krych > wrote: > > Ah let me try with KC1.9.3.Final then. > > ++ > Corinne > > On 3 May 2016 at 00:13, Bruno Oliveira > wrote: > > Hi Corinne, I tried here with Keycloak 1.9.3.Final and couldn't > reproduce your issue. > > I followed exactly the same steps described at your readme file. > > On 2016-05-02, Corinne Krych wrote: > > Hello Keycloak team, > > > > I'm trying to move my OAuth2 demo app from Keyclaok 1.5 to > Keyclaok 1.9.1. > > I've change the OAuth2 endpoints for the access token. I > manage the Oauth2 > > dansc ok but when trying to access a protected resource I > hit the error: > > > > 22:00:13,501 ERROR > [org.keycloak.adapters.BearerTokenRequestAuthenticator] > > (default task-101) Failed to verify token: > > org.keycloak.common.VerificationException: Realm URL is > null. Make sure to > > add auth-server-url to the configuration of your adapter! > > at > org.keycloak.RSATokenVerifier.verifyToken(RSATokenVerifier.java:46) > > at > org.keycloak.RSATokenVerifier.verifyToken(RSATokenVerifier.java:35) > > at > > > org.keycloak.adapters.BearerTokenRequestAuthenticator.authenticateToken(BearerTokenRequestAuthenticator.java:87) > > at > > > org.keycloak.adapters.BearerTokenRequestAuthenticator.authenticate(BearerTokenRequestAuthenticator.java:82) > > at > > > org.keycloak.adapters.RequestAuthenticator.authenticate(RequestAuthenticator.java:65) > > at > > > org.keycloak.adapters.undertow.AbstractUndertowKeycloakAuthMech.keycloakAuthenticate(AbstractUndertowKeycloakAuthMech.java:110) > > at > > > org.keycloak.adapters.undertow.ServletKeycloakAuthMech.authenticate(ServletKeycloakAuthMech.java:92) > > at > > > io.undertow.security.impl.SecurityContextImpl$AuthAttempter.transition(SecurityContextImpl.java:233) > > at > > > io.undertow.security.impl.SecurityContextImpl$AuthAttempter.transition(SecurityContextImpl.java:250) > > at > > > io.undertow.security.impl.SecurityContextImpl$AuthAttempter.access$100(SecurityContextImpl.java:219) > > at > > > io.undertow.security.impl.SecurityContextImpl.attemptAuthentication(SecurityContextImpl.java:121) > > at > > > io.undertow.security.impl.SecurityContextImpl.authTransition(SecurityContextImpl.java:96) > > at > > > io.undertow.security.impl.SecurityContextImpl.authenticate(SecurityContextImpl.java:89) > > at > > > io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:55) > > at > > > io.undertow.server.handlers.DisableCacheHandler.handleRequest(DisableCacheHandler.java:33) > > at > > > io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > > at > > > io.undertow.security.handlers.AuthenticationConstraintHandler.handleRequest(AuthenticationConstraintHandler.java:51) > > at > > > io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46) > > at > > > io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64) > > at > > > io.undertow.servlet.handlers.security.ServletSecurityConstraintHandler.handleRequest(ServletSecurityConstraintHandler.java:56) > > at > > > io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60) > > at > > > io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77) > > at > > > io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50) > > at > > > io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43) > > at > > > io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > > at > > > org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61) > > at > > > io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > > at > > > org.keycloak.adapters.undertow.ServletPreAuthActionsHandler.handleRequest(ServletPreAuthActionsHandler.java:69) > > at > > > io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > > at > > > io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:284) > > at > > > io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:263) > > at > > > io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81) > > at > > > io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:174) > > at > io.undertow.server.Connectors.executeRootHandler(Connectors.java:202) > > at > io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:793) > > 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) > > > > My realm setup is here: > > > https://github.com/aerogear/aerogear-backend-cookbook/blob/master/Shoot/configuration/shoot-realm.json > > > > The keycloak.json used for the protected endpoint is: > > > https://github.com/aerogear/aerogear-backend-cookbook/blob/master/Shoot/src/main/webapp/WEB-INF/keycloak.json > > > > Is there some specific settings I should add to work with > Keycloak 1.9.x? > > > > Your help would be welcome. > > > > ++ > > Corinne > > > _______________________________________________ > > 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/20160503/3744f6e4/attachment.html From corinnekrych at gmail.com Tue May 3 06:33:22 2016 From: corinnekrych at gmail.com (Corinne Krych) Date: Tue, 3 May 2016 12:33:22 +0200 Subject: [keycloak-dev] Failed to verify token: org.keycloak.common.VerificationException: Realm URL is null. In-Reply-To: <57285126.4040305@redhat.com> References: <20160502221334.GA15838@abstractj.org> <57285126.4040305@redhat.com> Message-ID: Thanks Bruno, Marek, My issue was a exactly this missing auth-server-url on keycloak.jason. I was on a non-rebased branch :)) Thanks again, ++ Corinne On 3 May 2016 at 09:20, Marek Posolda wrote: > Strange, this error usually happens if you don't have "auth-server-url" in > the configuration of keycloak.json . But you have it in > https://github.com/aerogear/aerogear-backend-cookbook/blob/master/Shoot/src/main/webapp/WEB-INF/keycloak.json > as you pointed in the first mail. > > Isn't any chance there is other REST backend, which you are calling and > which is missing this? > If not, then can you try to temporarily use absolute URL like: > "auth-server-url" : "http://localhost:8080/auth" > > and see if it helps? > > Marek > > > On 03/05/16 09:04, Corinne Krych wrote: > > Hello Bruno > > I've tried with Keycloak-demo-1.9.3 and I still hit the issue: > > 09:02:27,847 ERROR [org.keycloak.adapters.BearerTokenRequestAuthenticator] > (default task-74) Failed to verify token: > org.keycloak.common.VerificationException: Realm URL is null. Make sure to > add auth-server-url to the configuration of your adapter! > > at org.keycloak.RSATokenVerifier.verifyToken(RSATokenVerifier.java:46) > > at org.keycloak.RSATokenVerifier.verifyToken(RSATokenVerifier.java:35) > > I think the secure endpoint is missing some configuration but not sure > what i'm missing. > > ++ > > Corinne > > On 3 May 2016 at 08:35, Corinne Krych wrote: > >> Ah let me try with KC1.9.3.Final then. >> >> ++ >> Corinne >> >> On 3 May 2016 at 00:13, Bruno Oliveira < >> bruno at abstractj.org> wrote: >> >>> Hi Corinne, I tried here with Keycloak 1.9.3.Final and couldn't >>> reproduce your issue. >>> >>> I followed exactly the same steps described at your readme file. >>> >>> On 2016-05-02, Corinne Krych wrote: >>> > Hello Keycloak team, >>> > >>> > I'm trying to move my OAuth2 demo app from Keyclaok 1.5 to Keyclaok >>> 1.9.1. >>> > I've change the OAuth2 endpoints for the access token. I manage the >>> Oauth2 >>> > dansc ok but when trying to access a protected resource I hit the >>> error: >>> > >>> > 22:00:13,501 ERROR >>> [org.keycloak.adapters.BearerTokenRequestAuthenticator] >>> > (default task-101) Failed to verify token: >>> > org.keycloak.common.VerificationException: Realm URL is null. Make >>> sure to >>> > add auth-server-url to the configuration of your adapter! >>> > at org.keycloak.RSATokenVerifier.verifyToken(RSATokenVerifier.java:46) >>> > at org.keycloak.RSATokenVerifier.verifyToken(RSATokenVerifier.java:35) >>> > at >>> > >>> org.keycloak.adapters.BearerTokenRequestAuthenticator.authenticateToken(BearerTokenRequestAuthenticator.java:87) >>> > at >>> > >>> org.keycloak.adapters.BearerTokenRequestAuthenticator.authenticate(BearerTokenRequestAuthenticator.java:82) >>> > at >>> > >>> org.keycloak.adapters.RequestAuthenticator.authenticate(RequestAuthenticator.java:65) >>> > at >>> > >>> org.keycloak.adapters.undertow.AbstractUndertowKeycloakAuthMech.keycloakAuthenticate(AbstractUndertowKeycloakAuthMech.java:110) >>> > at >>> > >>> org.keycloak.adapters.undertow.ServletKeycloakAuthMech.authenticate(ServletKeycloakAuthMech.java:92) >>> > at >>> > >>> io.undertow.security.impl.SecurityContextImpl$AuthAttempter.transition(SecurityContextImpl.java:233) >>> > at >>> > >>> io.undertow.security.impl.SecurityContextImpl$AuthAttempter.transition(SecurityContextImpl.java:250) >>> > at >>> > >>> io.undertow.security.impl.SecurityContextImpl$AuthAttempter.access$100(SecurityContextImpl.java:219) >>> > at >>> > >>> io.undertow.security.impl.SecurityContextImpl.attemptAuthentication(SecurityContextImpl.java:121) >>> > at >>> > >>> io.undertow.security.impl.SecurityContextImpl.authTransition(SecurityContextImpl.java:96) >>> > at >>> > >>> io.undertow.security.impl.SecurityContextImpl.authenticate(SecurityContextImpl.java:89) >>> > at >>> > >>> io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:55) >>> > at >>> > >>> io.undertow.server.handlers.DisableCacheHandler.handleRequest(DisableCacheHandler.java:33) >>> > at >>> > >>> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) >>> > at >>> > >>> io.undertow.security.handlers.AuthenticationConstraintHandler.handleRequest(AuthenticationConstraintHandler.java:51) >>> > at >>> > >>> io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46) >>> > at >>> > >>> io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64) >>> > at >>> > >>> io.undertow.servlet.handlers.security.ServletSecurityConstraintHandler.handleRequest(ServletSecurityConstraintHandler.java:56) >>> > at >>> > >>> io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60) >>> > at >>> > >>> io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77) >>> > at >>> > >>> io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50) >>> > at >>> > >>> io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43) >>> > at >>> > >>> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) >>> > at >>> > >>> org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61) >>> > at >>> > >>> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) >>> > at >>> > >>> org.keycloak.adapters.undertow.ServletPreAuthActionsHandler.handleRequest(ServletPreAuthActionsHandler.java:69) >>> > at >>> > >>> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) >>> > at >>> > >>> io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:284) >>> > at >>> > >>> io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:263) >>> > at >>> > >>> io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81) >>> > at >>> > >>> io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:174) >>> > at >>> io.undertow.server.Connectors.executeRootHandler(Connectors.java:202) >>> > at >>> io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:793) >>> > 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) >>> > >>> > My realm setup is here: >>> > >>> https://github.com/aerogear/aerogear-backend-cookbook/blob/master/Shoot/configuration/shoot-realm.json >>> > >>> > The keycloak.json used for the protected endpoint is: >>> > >>> https://github.com/aerogear/aerogear-backend-cookbook/blob/master/Shoot/src/main/webapp/WEB-INF/keycloak.json >>> > >>> > Is there some specific settings I should add to work with Keycloak >>> 1.9.x? >>> > >>> > Your help would be welcome. >>> > >>> > ++ >>> > Corinne >>> >>> > _______________________________________________ >>> > 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/20160503/8c959dec/attachment-0001.html From corinnekrych at gmail.com Tue May 3 06:33:27 2016 From: corinnekrych at gmail.com (Corinne Krych) Date: Tue, 3 May 2016 12:33:27 +0200 Subject: [keycloak-dev] redirect_uri validation on Keycloak 1.9.x Message-ID: Hello guys, Moving cookbook demo AeroGear iOS sdk to Keycloak 1.9.x I noticed that the redirect_uri validation has changes . I used to have "org.aerogear.Shoot://oauth2Callback" for a redirect_uri. In iOS land we used custom schema [1], as a best practice very often the first part of it is defined using the iOS bundle id (Apple unique id) which most of the time contains a mix of upper/lower case letters. When discussing the subject on irc with @Marek, it seems there might be an issue in RedirectUtils.lowerCaseHostname in https://github.com/keycloak/keycloak/blob/master/services/src/main/java/org/keycloak/protocol/oidc/utils/RedirectUtils.java#L119 I converted this url to : "org.aerogear.shoot://oauth2Callback" and it works better [2] and did change locally the bundle id of the iOs app. But in KC 1.4.x I was able to use upper case in redirect_uri and for an iOS point of view, it was much more convenient. What is the reasoning behind redirect_uri? Should we use http(s) as the only protocol? Thanks for your feedback. ++ Corinne [1] http://iosdevelopertips.com/cocoa/launching-your-own-application-via-a-custom-url-scheme.html [2] https://github.com/aerogear/aerogear-backend-cookbook/pull/30/files -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160503/47f6d040/attachment.html From sthorger at redhat.com Tue May 3 07:05:12 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Tue, 3 May 2016 13:05:12 +0200 Subject: [keycloak-dev] Enable JDK8 for testsuite Message-ID: I've changed source/target to 1.8 for testsuite/integration-arquillian. This is so I can use lambdas for testing permissions (otherwise I end up with extremely messy tests with loads of anonymous inner classes). Anyone have any issues with that? In 2.x we can look at setting 1.8 as default for everything except adapters and shared modules. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160503/33d22791/attachment.html From psilva at redhat.com Tue May 3 09:05:36 2016 From: psilva at redhat.com (Pedro Igor Silva) Date: Tue, 3 May 2016 09:05:36 -0400 (EDT) Subject: [keycloak-dev] Thinking about step-up authentication and token timeouts In-Reply-To: References: <6b9e58e9-65f9-87ac-8991-f6ccab25aca8@redhat.com> <4d2c6034-ee77-33ab-7135-8c1c54996b0d@redhat.com> Message-ID: <1381984901.622873.1462280736505.JavaMail.zimbra@redhat.com> ----- Original Message ----- > From: "Stian Thorgersen" > To: "Bill Burke" > Cc: "keycloak-dev" > Sent: Monday, May 2, 2016 10:10:57 AM > Subject: Re: [keycloak-dev] Thinking about step-up authentication and token timeouts > > I wasn't thinking a token exchange, I was thinking it would just do a new > authentication request with different scope, etc.. AFAIK ... In SAML, AuthnRequest may have a ForceAuthn attribute set to true to indicate that IdP must authenticate the presenter directly rather than rely on a previous security context. There is also a RequestedAuthnContext that can be used to specify an "authentication class" pretty much like the "acr_values" in a OIDC Authentication Request. > > On 2 May 2016 at 14:54, Bill Burke < bburke at redhat.com > wrote: > > > > > > I have no idea. What you are describing is different. Its scope, SAML > probably has it, but I don't know what it is. You also describe a token > exchange service > > On 5/2/2016 4:56 AM, Stian Thorgersen wrote: > > > > > Wouldn't saml support it fairly easily? It's just another auth request with > SE different params? > On 29 Apr 2016 16:19, "Bill Burke" < bburke at redhat.com > wrote: > > > > Sounds great. I hope we don't have to implement this for SAML too ;) > > On 4/29/2016 12:02 AM, Stian Thorgersen wrote: > > > > Clients should be able to obtain tokens with reduced scope and longer or > shorter expiration, then later request new tokens with increased scope and > different expiration. They should also be able to require different levels > of authentication and also require re-authentication. > > An application may for example: > > * At first only need users email - this would allow showing the name + email. > In this situation a long expiration access token in combination with > implicit flow would do. It's also not necessary to re-authenticate the user > and a user that has been logged-in for months or even a year is fine. > > * When a user clicks on orders it would require the password and extend scope > to be able to view orders. Now you'll want to switch to short expiration > access tokens and authorization code grant. You'll also want to make sure > the user logged-in fairly recently, max 30 days could be sensible. > > * When a user tries to purchase something the user now has to provide the OTP > to be able to purchase with saved credit card details. You'll also want to > make sure the user logged-in very recently, max a day could be required. > There may also be cases where you always want the user to re-authenticate, > for example when trying to purchase something over a certain price level. > > > _______________________________________________ > keycloak-dev mailing list keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > -- > Bill Burke > JBoss, a division of Red Hat http://bill.burkecentral.com > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > -- > Bill Burke > JBoss, a division of Red Hat http://bill.burkecentral.com > > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev From lball at redhat.com Tue May 3 15:25:46 2016 From: lball at redhat.com (Lance Ball) Date: Tue, 3 May 2016 15:25:46 -0400 Subject: [keycloak-dev] Node.js Module for Client Registration REST API Message-ID: Hi all I have just published an initial 0.1.0 version of a Node.js client for the Keycloak client registration API. You can check it out here: https://www.npmjs.com/package/keycloak-client-registration It currently supports CRUD operations for Keycloak 'default' and 'openid-connect' provider endpoints. The documentation, such as it is, can be found here: http://bucharest-gold.github.io/keycloak-client-registration/. Please feel free to give it a spin. And if you do and have something to say about it, feedback is welcome. The client requires Node.js 5.0 or higher, and is known to work with Keycloak versions 1.9.2 and 1.9.3. If you find a bug, please provide as much detail as you can in a github issue: https://github.com/bucharest-gold/keycloak-client-registration/issues. Pull requests encouraged. :) Cheers Lance -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160503/a45681fd/attachment.html From sthorger at redhat.com Wed May 4 00:54:48 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Wed, 4 May 2016 06:54:48 +0200 Subject: [keycloak-dev] Node.js Module for Client Registration REST API In-Reply-To: References: Message-ID: Nice work, thanks :) On 3 May 2016 at 21:25, Lance Ball wrote: > Hi all > > I have just published an initial 0.1.0 version of a Node.js client for the > Keycloak client registration API. You can check it out here: > https://www.npmjs.com/package/keycloak-client-registration > > It currently supports CRUD operations for Keycloak 'default' and > 'openid-connect' provider endpoints. The documentation, such as it is, can > be found here: > http://bucharest-gold.github.io/keycloak-client-registration/. Please > feel free to give it a spin. And if you do and have something to say about > it, feedback is welcome. > > The client requires Node.js 5.0 or higher, and is known to work with > Keycloak versions 1.9.2 and 1.9.3. > > If you find a bug, please provide as much detail as you can in a github > issue: > https://github.com/bucharest-gold/keycloak-client-registration/issues. > Pull requests encouraged. :) > > Cheers > Lance > > _______________________________________________ > 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/20160504/16a66bb8/attachment.html From sthorger at redhat.com Wed May 4 02:15:47 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Wed, 4 May 2016 08:15:47 +0200 Subject: [keycloak-dev] Remove realms after tests in AbstractKeycloakTest Message-ID: Removing test realms was commented out in AbstractKeycloakTest. I'm removed the comment and tests realms are now removed after the tests. Test need to cleanup after themselves and should leave the server as they found it. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160504/241cb778/attachment.html From mhajas at redhat.com Thu May 5 05:46:00 2016 From: mhajas at redhat.com (Michal Hajas) Date: Thu, 5 May 2016 05:46:00 -0400 (EDT) Subject: [keycloak-dev] Enable JDK8 for testsuite In-Reply-To: References: Message-ID: <846012173.25808680.1462441560076.JavaMail.zimbra@redhat.com> Hi Stian, I think we may have problem with this, because our servlets are in base testsuite (https://github.com/keycloak/keycloak/tree/master/testsuite/integration-arquillian/tests/base/src/main/java/org/keycloak/testsuite/adapter/servlet) and they need to be compiled with java 7. We need to be able to deploy them to containers running on java 7. Will be these files involved too? Michal. ----- Original Message ----- > From: "Stian Thorgersen" > To: "keycloak-dev" > Sent: Tuesday, May 3, 2016 1:05:12 PM > Subject: [keycloak-dev] Enable JDK8 for testsuite > > I've changed source/target to 1.8 for testsuite/integration-arquillian. This > is so I can use lambdas for testing permissions (otherwise I end up with > extremely messy tests with loads of anonymous inner classes). > > Anyone have any issues with that? > > In 2.x we can look at setting 1.8 as default for everything except adapters > and shared modules. > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev From sthorger at redhat.com Fri May 6 01:15:50 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Fri, 6 May 2016 07:15:50 +0200 Subject: [keycloak-dev] Enable JDK8 for testsuite In-Reply-To: <846012173.25808680.1462441560076.JavaMail.zimbra@redhat.com> References: <846012173.25808680.1462441560076.JavaMail.zimbra@redhat.com> Message-ID: I'm afraid I've already merged this. I could change it back, but in the future we will start using JDK8 features on the server side, that means all modules not used by adapters will be allowed to use JDK8 features. It seems like a better way forward would be to solve the issue (my PermissionsTests will be horrible without lambdas as well). Why are the servlets in "tests/base" at all? Seems like these are only used by "tests/other/adapters" and that's where they should be. Base should focus on only testing the server itself. If the servlets are moved there we can make only "tests/base" use JDK8. That would solve the problem right? On 5 May 2016 at 11:46, Michal Hajas wrote: > Hi Stian, > > I think we may have problem with this, because our servlets are in base > testsuite ( > https://github.com/keycloak/keycloak/tree/master/testsuite/integration-arquillian/tests/base/src/main/java/org/keycloak/testsuite/adapter/servlet) > and they need to be compiled with java 7. We need to be able to deploy them > to containers running on java 7. Will be these files involved too? > > Michal. > > ----- Original Message ----- > > From: "Stian Thorgersen" > > To: "keycloak-dev" > > Sent: Tuesday, May 3, 2016 1:05:12 PM > > Subject: [keycloak-dev] Enable JDK8 for testsuite > > > > I've changed source/target to 1.8 for testsuite/integration-arquillian. > This > > is so I can use lambdas for testing permissions (otherwise I end up with > > extremely messy tests with loads of anonymous inner classes). > > > > Anyone have any issues with that? > > > > In 2.x we can look at setting 1.8 as default for everything except > adapters > > and shared modules. > > > > _______________________________________________ > > 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/20160506/c9473160/attachment.html From mposolda at redhat.com Fri May 6 05:24:37 2016 From: mposolda at redhat.com (Marek Posolda) Date: Fri, 6 May 2016 11:24:37 +0200 Subject: [keycloak-dev] Reuse Apache HTTP client in the quickstarts and examples? Message-ID: <572C62D5.1030905@redhat.com> Right now, we always create new instance of Apache HTTP Client per each request. Like in the quickstarts [1] or in the examples [2] . This is anti-pattern and not very good usage of Apache HTTP Client, which is supposed to be application-scoped object though. I know the point is to have examples as easy as possible. However shouldn't we avoid anti-patterns? Otherwise there might be possible risk that people will inspire and use the same pattern in their production apps :-) [1] https://github.com/keycloak/keycloak-examples/blob/master/app-jee/src/main/java/org/keycloak/quickstart/appjee/ServiceClient.java#L148 [2] https://github.com/keycloak/keycloak/blob/master/examples/demo-template/customer-app/src/main/java/org/keycloak/example/CustomerDatabaseClient.java#L67 Marek From sthorger at redhat.com Fri May 6 07:13:32 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Fri, 6 May 2016 13:13:32 +0200 Subject: [keycloak-dev] Reuse Apache HTTP client in the quickstarts and examples? In-Reply-To: <572C62D5.1030905@redhat.com> References: <572C62D5.1030905@redhat.com> Message-ID: I've actually got more of an issue with the fact that it disables SSL: SSLContext sslContext = new SSLContextBuilder().loadTrustMaterial(null, new TrustStrategy() { public boolean isTrusted(X509Certificate[] arg0, String arg1) throws CertificateException { return true; } }).build(); b.setSslcontext( sslContext); // don't check Hostnames, either. // -- use SSLConnectionSocketFactory.getDefaultHostnameVerifier(), if you don't want to weaken HostnameVerifier hostnameVerifier = SSLConnectionSocketFactory.ALLOW_ALL_HOSTNAME_VERIFIER; On 6 May 2016 at 11:24, Marek Posolda wrote: > Right now, we always create new instance of Apache HTTP Client per each > request. Like in the quickstarts [1] or in the examples [2] . > > This is anti-pattern and not very good usage of Apache HTTP Client, > which is supposed to be application-scoped object though. I know the > point is to have examples as easy as possible. However shouldn't we > avoid anti-patterns? Otherwise there might be possible risk that people > will inspire and use the same pattern in their production apps :-) > > [1] > > https://github.com/keycloak/keycloak-examples/blob/master/app-jee/src/main/java/org/keycloak/quickstart/appjee/ServiceClient.java#L148 > [2] > > https://github.com/keycloak/keycloak/blob/master/examples/demo-template/customer-app/src/main/java/org/keycloak/example/CustomerDatabaseClient.java#L67 > > 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/20160506/987514ce/attachment.html From mposolda at redhat.com Fri May 6 14:33:42 2016 From: mposolda at redhat.com (Marek Posolda) Date: Fri, 6 May 2016 20:33:42 +0200 Subject: [keycloak-dev] Reuse Apache HTTP client in the quickstarts and examples? In-Reply-To: References: <572C62D5.1030905@redhat.com> Message-ID: <572CE386.6040406@redhat.com> Seems that SSL and HostnameVerified disabled is needed just because of openshift. I wonder if we should have separate version of quickstarts for openshift. Sent separate mail about it to Bill DeCoste. Marek On 06/05/16 13:13, Stian Thorgersen wrote: > I've actually got more of an issue with the fact that it disables SSL: > > SSLContext sslContext = new > SSLContextBuilder().loadTrustMaterial(null, new TrustStrategy() { > public boolean isTrusted(X509Certificate[] arg0, String > arg1) throws CertificateException { > return true; > } > }).build(); > b.setSslcontext( sslContext); > // don't check Hostnames, either. > // -- use > SSLConnectionSocketFactory.getDefaultHostnameVerifier(), if you don't > want to weaken > HostnameVerifier hostnameVerifier = > SSLConnectionSocketFactory.ALLOW_ALL_HOSTNAME_VERIFIER; > > On 6 May 2016 at 11:24, Marek Posolda > wrote: > > Right now, we always create new instance of Apache HTTP Client per > each > request. Like in the quickstarts [1] or in the examples [2] . > > This is anti-pattern and not very good usage of Apache HTTP Client, > which is supposed to be application-scoped object though. I know the > point is to have examples as easy as possible. However shouldn't we > avoid anti-patterns? Otherwise there might be possible risk that > people > will inspire and use the same pattern in their production apps :-) > > [1] > https://github.com/keycloak/keycloak-examples/blob/master/app-jee/src/main/java/org/keycloak/quickstart/appjee/ServiceClient.java#L148 > [2] > https://github.com/keycloak/keycloak/blob/master/examples/demo-template/customer-app/src/main/java/org/keycloak/example/CustomerDatabaseClient.java#L67 > > 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/20160506/0cb313a0/attachment.html From sthorger at redhat.com Sun May 8 23:55:53 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Mon, 9 May 2016 05:55:53 +0200 Subject: [keycloak-dev] Reuse Apache HTTP client in the quickstarts and examples? In-Reply-To: <572CE386.6040406@redhat.com> References: <572C62D5.1030905@redhat.com> <572CE386.6040406@redhat.com> Message-ID: Not sure why it's even using SSL then. We should find a way to rip out that code and use SSL properly. This is very very bad IMO. On 6 May 2016 at 20:33, Marek Posolda wrote: > Seems that SSL and HostnameVerified disabled is needed just because of > openshift. I wonder if we should have separate version of quickstarts for > openshift. Sent separate mail about it to Bill DeCoste. > > Marek > > > On 06/05/16 13:13, Stian Thorgersen wrote: > > I've actually got more of an issue with the fact that it disables SSL: > > SSLContext sslContext = new SSLContextBuilder().loadTrustMaterial(null, > new TrustStrategy() { > public boolean isTrusted(X509Certificate[] arg0, String arg1) > throws CertificateException { > return true; > } > }).build(); > b.setSslcontext( sslContext); > > // don't check Hostnames, either. > // -- use > SSLConnectionSocketFactory.getDefaultHostnameVerifier(), if you don't want > to weaken > HostnameVerifier hostnameVerifier = > SSLConnectionSocketFactory.ALLOW_ALL_HOSTNAME_VERIFIER; > > On 6 May 2016 at 11:24, Marek Posolda wrote: > >> Right now, we always create new instance of Apache HTTP Client per each >> request. Like in the quickstarts [1] or in the examples [2] . >> >> This is anti-pattern and not very good usage of Apache HTTP Client, >> which is supposed to be application-scoped object though. I know the >> point is to have examples as easy as possible. However shouldn't we >> avoid anti-patterns? Otherwise there might be possible risk that people >> will inspire and use the same pattern in their production apps :-) >> >> [1] >> >> https://github.com/keycloak/keycloak-examples/blob/master/app-jee/src/main/java/org/keycloak/quickstart/appjee/ServiceClient.java#L148 >> [2] >> >> https://github.com/keycloak/keycloak/blob/master/examples/demo-template/customer-app/src/main/java/org/keycloak/example/CustomerDatabaseClient.java#L67 >> >> 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/20160509/a9d8a787/attachment-0001.html From sthorger at redhat.com Mon May 9 01:19:45 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Mon, 9 May 2016 07:19:45 +0200 Subject: [keycloak-dev] Enable JDK8 for testsuite In-Reply-To: References: <846012173.25808680.1462441560076.JavaMail.zimbra@redhat.com> Message-ID: I'm dropping JDK8 for now. In the future we'll have this issue again at some point though as we will eventually allow server only modules to use Java8 features. On 6 May 2016 at 07:15, Stian Thorgersen wrote: > I'm afraid I've already merged this. I could change it back, but in the > future we will start using JDK8 features on the server side, that means all > modules not used by adapters will be allowed to use JDK8 features. It seems > like a better way forward would be to solve the issue (my PermissionsTests > will be horrible without lambdas as well). > > Why are the servlets in "tests/base" at all? Seems like these are only > used by "tests/other/adapters" and that's where they should be. Base should > focus on only testing the server itself. If the servlets are moved there we > can make only "tests/base" use JDK8. That would solve the problem right? > > On 5 May 2016 at 11:46, Michal Hajas wrote: > >> Hi Stian, >> >> I think we may have problem with this, because our servlets are in base >> testsuite ( >> https://github.com/keycloak/keycloak/tree/master/testsuite/integration-arquillian/tests/base/src/main/java/org/keycloak/testsuite/adapter/servlet) >> and they need to be compiled with java 7. We need to be able to deploy them >> to containers running on java 7. Will be these files involved too? >> >> Michal. >> >> ----- Original Message ----- >> > From: "Stian Thorgersen" >> > To: "keycloak-dev" >> > Sent: Tuesday, May 3, 2016 1:05:12 PM >> > Subject: [keycloak-dev] Enable JDK8 for testsuite >> > >> > I've changed source/target to 1.8 for testsuite/integration-arquillian. >> This >> > is so I can use lambdas for testing permissions (otherwise I end up with >> > extremely messy tests with loads of anonymous inner classes). >> > >> > Anyone have any issues with that? >> > >> > In 2.x we can look at setting 1.8 as default for everything except >> adapters >> > and shared modules. >> > >> > _______________________________________________ >> > 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/20160509/a75d924c/attachment.html From sthorger at redhat.com Mon May 9 05:02:54 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Mon, 9 May 2016 11:02:54 +0200 Subject: [keycloak-dev] Keycloak 1.9.4.Final Released Message-ID: We've just release 1.9.4.Final. This release only has two bug fixes, but comes with a fair bit more automated testing. For the full list of resolved issues 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/20160509/c3c9a40b/attachment.html From mposolda at redhat.com Mon May 9 06:29:38 2016 From: mposolda at redhat.com (Marek Posolda) Date: Mon, 9 May 2016 12:29:38 +0200 Subject: [keycloak-dev] Admin events questions Message-ID: <57306692.2050808@redhat.com> * Currently we support admin events just for 'success' cases. We don't log any error situations or missing permissions. Is it sufficient? * Some minor usability issues: ** For both classic events and admin events, there is filtering by Date (from or to). Couldn't we add some "nice" component for easily select date? Also the "from" date is included, but "to" date is excluded. This may not be obvious. Shouldn't we somehow mention it in tooltips? ** In "Auth details" for admin events, there is filtering by "Realm" , "Client" or "User". It may not be obvious, that this points to IDs. To be even more confusing, in "classic" events there is "Client" too, but that points to clientId (not database ID). Also in many situations, admins don't know the UserID or client database ID, so there is additional action required from them that they need to lookup ID it first. For clients, the client database ID is not even visible in admin console, so they need to decode either from URL or from some existing event. I wonder if we should add possibility to filter by "username" or "clientId"? For users maybe even filtering by email? In case that "username" or "email" or "clientId" is filled, admin will need to fill the "realm" too. From sthorger at redhat.com Mon May 9 08:55:04 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Mon, 9 May 2016 14:55:04 +0200 Subject: [keycloak-dev] Admin events questions In-Reply-To: <57306692.2050808@redhat.com> References: <57306692.2050808@redhat.com> Message-ID: On 9 May 2016 at 12:29, Marek Posolda wrote: > * Currently we support admin events just for 'success' cases. We don't > log any error situations or missing permissions. Is it sufficient? > +1 To errors, create a jira for 2.0.cr1 > > * Some minor usability issues: > ** For both classic events and admin events, there is filtering by Date > (from or to). Couldn't we add some "nice" component for easily select > date? Also the "from" date is included, but "to" date is excluded. This > may not be obvious. Shouldn't we somehow mention it in tooltips? > +1 PatternFly was about to add one when we did this, but it wasn't ready yet. JIRA for 2.0.cr1 please. > > ** In "Auth details" for admin events, there is filtering by "Realm" , > "Client" or "User". It may not be obvious, that this points to IDs. To > be even more confusing, in "classic" events there is "Client" too, but > that points to clientId (not database ID). Also in many situations, > admins don't know the UserID or client database ID, so there is > additional action required from them that they need to lookup ID it > first. For clients, the client database ID is not even visible in admin > console, so they need to decode either from URL or from some existing > event. I wonder if we should add possibility to filter by "username" or > "clientId"? For users maybe even filtering by email? In case that > "username" or "email" or "clientId" is filled, admin will need to fill > the "realm" too. > Events doesn't always have username, username can also change over time. So user id isn't the reliable thing to use. We could add something to allow looking up userid by username or something though. > _______________________________________________ > 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/20160509/2b6beec5/attachment.html From sthorger at redhat.com Mon May 9 08:56:23 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Mon, 9 May 2016 14:56:23 +0200 Subject: [keycloak-dev] Admin events questions In-Reply-To: References: <57306692.2050808@redhat.com> Message-ID: On 9 May 2016 at 14:55, Stian Thorgersen wrote: > > > On 9 May 2016 at 12:29, Marek Posolda wrote: > >> * Currently we support admin events just for 'success' cases. We don't >> log any error situations or missing permissions. Is it sufficient? >> > > +1 To errors, create a jira for 2.0.cr1 > > >> >> * Some minor usability issues: >> ** For both classic events and admin events, there is filtering by Date >> (from or to). Couldn't we add some "nice" component for easily select >> date? Also the "from" date is included, but "to" date is excluded. This >> may not be obvious. Shouldn't we somehow mention it in tooltips? >> > > +1 PatternFly was about to add one when we did this, but it wasn't ready > yet. JIRA for 2.0.cr1 please. > > >> >> ** In "Auth details" for admin events, there is filtering by "Realm" , >> "Client" or "User". It may not be obvious, that this points to IDs. To >> be even more confusing, in "classic" events there is "Client" too, but >> that points to clientId (not database ID). Also in many situations, >> admins don't know the UserID or client database ID, so there is >> additional action required from them that they need to lookup ID it >> first. For clients, the client database ID is not even visible in admin >> console, so they need to decode either from URL or from some existing >> event. I wonder if we should add possibility to filter by "username" or >> "clientId"? For users maybe even filtering by email? In case that >> "username" or "email" or "clientId" is filled, admin will need to fill >> the "realm" too. >> > > Events doesn't always have username, username can also change over time. > So user id isn't the reliable thing to use. We could add something to allow > looking up userid by username or something though. > I meant user id is the only reliable thing to use. Same with "client-id" it can change, so id for clients is only thing that works over time. > > >> _______________________________________________ >> 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/20160509/e9cf79ed/attachment-0001.html From mposolda at redhat.com Mon May 9 10:17:58 2016 From: mposolda at redhat.com (Marek Posolda) Date: Mon, 9 May 2016 16:17:58 +0200 Subject: [keycloak-dev] Admin events questions In-Reply-To: References: <57306692.2050808@redhat.com> Message-ID: <57309C16.3090302@redhat.com> On 09/05/16 14:56, Stian Thorgersen wrote: > > > On 9 May 2016 at 14:55, Stian Thorgersen > wrote: > > > > On 9 May 2016 at 12:29, Marek Posolda > wrote: > > * Currently we support admin events just for 'success' cases. > We don't > log any error situations or missing permissions. Is it sufficient? > > > +1 To errors, create a jira for 2.0.cr1 > https://issues.jboss.org/browse/KEYCLOAK-2982 > > > * Some minor usability issues: > ** For both classic events and admin events, there is > filtering by Date > (from or to). Couldn't we add some "nice" component for easily > select > date? Also the "from" date is included, but "to" date is > excluded. This > may not be obvious. Shouldn't we somehow mention it in tooltips? > > > +1 PatternFly was about to add one when we did this, but it wasn't > ready yet. JIRA for 2.0.cr1 please. > https://issues.jboss.org/browse/KEYCLOAK-2983 > > > ** In "Auth details" for admin events, there is filtering by > "Realm" , > "Client" or "User". It may not be obvious, that this points to > IDs. To > be even more confusing, in "classic" events there is "Client" > too, but > that points to clientId (not database ID). Also in many > situations, > admins don't know the UserID or client database ID, so there is > additional action required from them that they need to lookup > ID it > first. For clients, the client database ID is not even visible > in admin > console, so they need to decode either from URL or from some > existing > event. I wonder if we should add possibility to filter by > "username" or > "clientId"? For users maybe even filtering by email? In case that > "username" or "email" or "clientId" is filled, admin will need > to fill > the "realm" too. > > > Events doesn't always have username, username can also change over > time. So user id isn't the reliable thing to use. We could add > something to allow looking up userid by username or something though. > > > I meant user id is the only reliable thing to use. Same with > "client-id" it can change, so id for clients is only thing that works > over time. Yeah, I meant that if you filter by username (or email or clientId), you will be required to fill the realm too. Then it's the responsibility of RealmAdminResource.getEvents to lookup user by realm+username and sent the found userID to EventStore for filtering by. So EventsStore will be unchanged and will still persist just the userId + client DB ID. 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/20160509/139b1005/attachment.html From nafiux at gmail.com Wed May 11 02:43:46 2016 From: nafiux at gmail.com (Ignacio Ocampo) Date: Tue, 10 May 2016 23:43:46 -0700 Subject: [keycloak-dev] How to use Keycloack Proxy Message-ID: Hello Team, I'm trying to understand how to use the Keycloak proxy, I have read the documentation: https://keycloak.github.io/docs/userguide/keycloak-server/html/proxy.html Do you have another example to a public API which I can test? And, can I enable a "verbose" output to see more errors for the proxy? Thanks in advance. Regards. -- Ignacio Ocampo Mill?n -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160510/ed83f5c4/attachment.html From mposolda at redhat.com Wed May 11 03:11:28 2016 From: mposolda at redhat.com (Marek Posolda) Date: Wed, 11 May 2016 09:11:28 +0200 Subject: [keycloak-dev] redirect_uri validation on Keycloak 1.9.x In-Reply-To: References: Message-ID: <5732DB20.6050708@redhat.com> Sorry for late response. I am personally not seeing any issue with support the redirect_uri "org.aerogear.Shoot://oauth2Callback" . So I suggest to create JIRA for Keycloak 2.0.0.CR1 for add this. Thanks, Marek On 03/05/16 12:33, Corinne Krych wrote: > Hello guys, > > Moving cookbook demo AeroGear iOS sdk to Keycloak 1.9.x I noticed that > the redirect_uri validation has changes . I used to have > "org.aerogear.Shoot://oauth2Callback" for a redirect_uri. In iOS land > we used custom schema [1], as a best practice very often the first > part of it is defined using the iOS bundle id (Apple unique id) which > most of the time contains a mix of upper/lower case letters. > > When discussing the subject on irc with @Marek, it seems there might > be an issue in RedirectUtils.lowerCaseHostname in > https://github.com/keycloak/keycloak/blob/master/services/src/main/java/org/keycloak/protocol/oidc/utils/RedirectUtils.java#L119 > > I converted this url to : "org.aerogear.shoot://oauth2Callback" and it > works better [2] and did change locally the bundle id of the iOs app. > But in KC 1.4.x I was able to use upper case in redirect_uri and for > an iOS point of view, it was much more convenient. What is the > reasoning behind redirect_uri? Should we use http(s) as the only protocol? > > Thanks for your feedback. > ++ > Corinne > [1] > http://iosdevelopertips.com/cocoa/launching-your-own-application-via-a-custom-url-scheme.html > [2] https://github.com/aerogear/aerogear-backend-cookbook/pull/30/files > > > _______________________________________________ > 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/20160511/d6bc8997/attachment.html From mstrukel at redhat.com Wed May 11 08:33:17 2016 From: mstrukel at redhat.com (Marko Strukelj) Date: Wed, 11 May 2016 14:33:17 +0200 Subject: [keycloak-dev] Failing integration-arquillian tests when using -Pauth-server-wildfly Message-ID: There are currently many tests failing when running: mvn clean install -Pdistribution -DskipTests cd testsuite/integration-arquillian mvn clean install -Pauth-server-wildfly Failed tests: ProvidersTest.testClientAuthenticatorProviders:85->compareProviders:178 Providers count expected:<3> but was:<2> ProvidersTest.testInitialAuthenticationProviders:130->compareProviders:178 Providers count expected:<20> but was:<18> ProvidersTest.testPerClientConfigDescriptions:93 null CustomFlowTest.clientAuthTest:209->grantAccessToken:235 expected:<200> but was:<400> CustomFlowTest.grantTest:202->grantAccessToken:235 expected:<200> but was:<400> RefreshTokenTest.refreshTokenRequest:154 Expected: (a value equal to or greater than <1799> and a value less than or equal to <1800>) but: a value equal to or greater than <1799> <1798> was less than <1799> RefreshTokenTest.refreshTokenReuseTokenWithRefreshTokensRevoked:261 expected:<400> but was:<200> RefreshTokenTest.refreshTokenUserSessionMaxLifespan:456 expected:<400> but was:<200> RefreshTokenTest.testUserSessionRefreshAndIdle:398 Values should be different. Actual: 1462968567 Tests in error: CustomFlowTest.loginSuccess:193 ? IllegalArgument No enum constant org.keycloa... CustomRegistrationFlowTest.registerUserSuccess:98 ? IllegalArgument No enum co... ResetPasswordTest.resetPasswordExpiredCode:386 ? NotAuthorized HTTP 401 Unauth... ResetPasswordTest.resetPasswordExpiredCodeShort:430 ? NotAuthorized HTTP 401 U... ResetPasswordTest.resetPasswordWithPasswordHisoryPolicy:575->resetPassword:267 ? NotAuthorized OfflineTokenTest.offlineTokenAllowedWithCompositeRole:428->offlineTokenDirectGrantFlow:290 ? Runtime OfflineTokenTest.offlineTokenBrowserFlow:210 ? Runtime Failed to verify token OfflineTokenTest.offlineTokenDirectGrantFlow:311->testRefreshWithOfflineToken:255 ? Runtime OfflineTokenTest.offlineTokenDirectGrantFlowWithRefreshTokensRevoked:325 ? Runtime OfflineTokenTest.offlineTokenServiceAccountFlow:371 ? Runtime Failed to verify... Tests run: 480, Failures: 9, Errors: 10, Skipped: 3 It's probably just server-side changes that require maintenance in the tests themselves. We should maybe configure Travis CI with -Pauth-server-wildfly option so that we detect these right away. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160511/43974845/attachment-0001.html From Stephen.Merchant at gandlake.com Wed May 11 11:59:14 2016 From: Stephen.Merchant at gandlake.com (Stephen Merchant) Date: Wed, 11 May 2016 15:59:14 +0000 Subject: [keycloak-dev] SpringBoot : Multi-tenant Example Message-ID: <3DE4BF1BF8EDD84B8F8D61B0A88BD5630FFA75@EXCH01.gandlake.local> Hello, I would really appreciate advice on how to implement Multi-tenant SSO in a Spring Boot application. The "User Guide" Spring Boot Adapter section mentions that the keycloak.json settings are maintained in the Spring Boot configuration file. Comparing this approach to a non-Spring Boot application (such as that provided in the Examples) using KeycloakConfigResolver,I would like to know how I can simulate this approach with a Spring Boot configuration file, rather than appropriately named JSON files (such as tenant1-realm.json and tenant1-realm.json). 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160511/f5f787ec/attachment.html From anshulm at stytch.com Thu May 12 01:24:54 2016 From: anshulm at stytch.com (Anshul Malpani) Date: Wed, 11 May 2016 22:24:54 -0700 Subject: [keycloak-dev] Keycloak impersonate programmatically In-Reply-To: <6D865EE1-A08F-4944-A31C-83C4E83AEA45@dnbcloud.com> References: <6D865EE1-A08F-4944-A31C-83C4E83AEA45@dnbcloud.com> Message-ID: Hi, I am trying to use impersonate feature using my java client. When I call impersonate api using admin access grant. I get back the cookies. How can I get the access token for the impersonate user. HttpPost post = new HttpPost( KeycloakUriBuilder.fromUri(authServerUrl).path(? /admin/realms/{realm}/users/{id}/impersonation").build(realm, accountKeycloakId)); This is returning me cookies. In next step I would like to get the access token of impersonate user. Thanks On Wed, May 11, 2016 at 3:25 PM, Anshul Malpani wrote: > Hi, > > I am trying to use impersonate feature using my java client. When I call > impersonate api using admin access grant. I get back the cookies. How can I > get the access token for the impersonate user. > > > > HttpPost post = new HttpPost( > KeycloakUriBuilder.fromUri(authServerUrl).path(? > /admin/realms/{realm}/users/{id}/impersonation").build(realm, > accountKeycloakId)); > > This is returning me cookies. In next step I would like to get the access > token of impersonate user. > > Thanks > A > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160511/486bbf9c/attachment.html From mstrukel at redhat.com Thu May 12 04:38:07 2016 From: mstrukel at redhat.com (Marko Strukelj) Date: Thu, 12 May 2016 10:38:07 +0200 Subject: [keycloak-dev] Failing integration-arquillian tests when using -Pauth-server-wildfly In-Reply-To: References: Message-ID: I fixed the tests: https://issues.jboss.org/browse/KEYCLOAK-2993 There were two basic issues: 1) Usage of Time object on the client. We added a mechanism to set offset on the server - it's done by using setTimeOffset() of AbstractKeycloakTest rather than Time.setOffset(). However, we forgot that client can also sometimes directly rely on Time object - for one, admin-client uses it to check if token needs to be refreshed before doing a remote call. Also, JsonWebToken has validation methods that rely on Time object, and is also used inside tests. Thus, client-side Time.offset, and server-side Time.offset have to be in sync for things to work properly. Since Undertow runs embedded in the same JVM where tests execute there was no problem, but for Wildfly there are two JVMs then, and any Time.offset mismatch starts wreaking havoc. 2) Installation of some testing providers was not done through testsuite-providers module, but instead used tests/base directly - which works for embedded Undertow which loads from classpath, but not for running with Wildfly which loads from modules. On Wed, May 11, 2016 at 2:33 PM, Marko Strukelj wrote: > There are currently many tests failing when running: > > mvn clean install -Pdistribution -DskipTests > cd testsuite/integration-arquillian > mvn clean install -Pauth-server-wildfly > > Failed tests: > ProvidersTest.testClientAuthenticatorProviders:85->compareProviders:178 > Providers count expected:<3> but was:<2> > > ProvidersTest.testInitialAuthenticationProviders:130->compareProviders:178 > Providers count expected:<20> but was:<18> > ProvidersTest.testPerClientConfigDescriptions:93 null > CustomFlowTest.clientAuthTest:209->grantAccessToken:235 expected:<200> > but was:<400> > CustomFlowTest.grantTest:202->grantAccessToken:235 expected:<200> but > was:<400> > RefreshTokenTest.refreshTokenRequest:154 > Expected: (a value equal to or greater than <1799> and a value less than > or equal to <1800>) > but: a value equal to or greater than <1799> <1798> was less than > <1799> > RefreshTokenTest.refreshTokenReuseTokenWithRefreshTokensRevoked:261 > expected:<400> but was:<200> > RefreshTokenTest.refreshTokenUserSessionMaxLifespan:456 expected:<400> > but was:<200> > RefreshTokenTest.testUserSessionRefreshAndIdle:398 Values should be > different. Actual: 1462968567 > > Tests in error: > CustomFlowTest.loginSuccess:193 ? IllegalArgument No enum constant > org.keycloa... > CustomRegistrationFlowTest.registerUserSuccess:98 ? IllegalArgument No > enum co... > ResetPasswordTest.resetPasswordExpiredCode:386 ? NotAuthorized HTTP 401 > Unauth... > ResetPasswordTest.resetPasswordExpiredCodeShort:430 ? NotAuthorized HTTP > 401 U... > > ResetPasswordTest.resetPasswordWithPasswordHisoryPolicy:575->resetPassword:267 > ? NotAuthorized > > OfflineTokenTest.offlineTokenAllowedWithCompositeRole:428->offlineTokenDirectGrantFlow:290 > ? Runtime > OfflineTokenTest.offlineTokenBrowserFlow:210 ? Runtime Failed to verify > token > > OfflineTokenTest.offlineTokenDirectGrantFlow:311->testRefreshWithOfflineToken:255 > ? Runtime > OfflineTokenTest.offlineTokenDirectGrantFlowWithRefreshTokensRevoked:325 > ? Runtime > OfflineTokenTest.offlineTokenServiceAccountFlow:371 ? Runtime Failed to > verify... > > Tests run: 480, Failures: 9, Errors: 10, Skipped: 3 > > It's probably just server-side changes that require maintenance in the > tests themselves. > > We should maybe configure Travis CI with -Pauth-server-wildfly option so > that we detect these right away. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160512/17709899/attachment.html From vramik at redhat.com Thu May 12 05:06:20 2016 From: vramik at redhat.com (Vlasta Ramik) Date: Thu, 12 May 2016 11:06:20 +0200 Subject: [keycloak-dev] Failing integration-arquillian tests when using -Pauth-server-wildfly In-Reply-To: References: Message-ID: <5734478C.5050007@redhat.com> FYI There is https://keycloak-jenkins.rhev-ci-vms.eng.rdu2.redhat.com/job/keycloak-deploy/ It checkouts 1.9.x branch and builds keycloak daily. If it succeeds artifacts are deployed to nexus staging repo and https://keycloak-jenkins.rhev-ci-vms.eng.rdu2.redhat.com/job/keycloak-parent/ job is triggered. This is multi-job and one of its jobs is https://keycloak-jenkins.rhev-ci-vms.eng.rdu2.redhat.com/job/keycloak-wildfly/. It run base testsuite on wildfly. So if you want you can check test results of the job regularly to be kept informed. On 05/12/2016 10:38 AM, Marko Strukelj wrote: > I fixed the tests: https://issues.jboss.org/browse/KEYCLOAK-2993 > > There were two basic issues: > > 1) Usage of Time object on the client. We added a mechanism to set > offset on the server - it's done by using setTimeOffset() of > AbstractKeycloakTest rather than Time.setOffset(). > However, we forgot that client can also sometimes directly rely on > Time object - for one, admin-client uses it to check if token needs to > be refreshed before doing a remote call. Also, JsonWebToken has > validation methods that rely on Time object, and is also used inside > tests. Thus, client-side Time.offset, and server-side Time.offset have > to be in sync for things to work properly. Since Undertow runs > embedded in the same JVM where tests execute there was no problem, but > for Wildfly there are two JVMs then, and any Time.offset mismatch > starts wreaking havoc. > > 2) Installation of some testing providers was not done through > testsuite-providers module, but instead used tests/base directly - > which works for embedded Undertow which loads from classpath, but not > for running with Wildfly which loads from modules. > > > > > On Wed, May 11, 2016 at 2:33 PM, Marko Strukelj > wrote: > > There are currently many tests failing when running: > > mvn clean install -Pdistribution -DskipTests > cd testsuite/integration-arquillian > mvn clean install -Pauth-server-wildfly > > Failed tests: > ProvidersTest.testClientAuthenticatorProviders:85->compareProviders:178 > Providers count expected:<3> but was:<2> > ProvidersTest.testInitialAuthenticationProviders:130->compareProviders:178 > Providers count expected:<20> but was:<18> > ProvidersTest.testPerClientConfigDescriptions:93 null > CustomFlowTest.clientAuthTest:209->grantAccessToken:235 > expected:<200> but was:<400> > CustomFlowTest.grantTest:202->grantAccessToken:235 > expected:<200> but was:<400> > RefreshTokenTest.refreshTokenRequest:154 > Expected: (a value equal to or greater than <1799> and a value > less than or equal to <1800>) > but: a value equal to or greater than <1799> <1798> was less > than <1799> > RefreshTokenTest.refreshTokenReuseTokenWithRefreshTokensRevoked:261 expected:<400> > but was:<200> > RefreshTokenTest.refreshTokenUserSessionMaxLifespan:456 > expected:<400> but was:<200> > RefreshTokenTest.testUserSessionRefreshAndIdle:398 Values should > be different. Actual: 1462968567 > > Tests in error: > CustomFlowTest.loginSuccess:193 ? IllegalArgument No enum > constant org.keycloa... > CustomRegistrationFlowTest.registerUserSuccess:98 ? > IllegalArgument No enum co... > ResetPasswordTest.resetPasswordExpiredCode:386 ? NotAuthorized > HTTP 401 Unauth... > ResetPasswordTest.resetPasswordExpiredCodeShort:430 ? > NotAuthorized HTTP 401 U... > ResetPasswordTest.resetPasswordWithPasswordHisoryPolicy:575->resetPassword:267 > ? NotAuthorized > OfflineTokenTest.offlineTokenAllowedWithCompositeRole:428->offlineTokenDirectGrantFlow:290 > ? Runtime > OfflineTokenTest.offlineTokenBrowserFlow:210 ? Runtime Failed to > verify token > OfflineTokenTest.offlineTokenDirectGrantFlow:311->testRefreshWithOfflineToken:255 > ? Runtime > OfflineTokenTest.offlineTokenDirectGrantFlowWithRefreshTokensRevoked:325 > ? Runtime > OfflineTokenTest.offlineTokenServiceAccountFlow:371 ? Runtime > Failed to verify... > > Tests run: 480, Failures: 9, Errors: 10, Skipped: 3 > > It's probably just server-side changes that require maintenance in > the tests themselves. > > We should maybe configure Travis CI with -Pauth-server-wildfly > option so that we detect these right away. > > > > > _______________________________________________ > 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/20160512/70ad39f5/attachment-0001.html From bburke at redhat.com Thu May 12 11:20:49 2016 From: bburke at redhat.com (Bill Burke) Date: Thu, 12 May 2016 11:20:49 -0400 Subject: [keycloak-dev] Keycloak impersonate programmatically In-Reply-To: References: <6D865EE1-A08F-4944-A31C-83C4E83AEA45@dnbcloud.com> Message-ID: <80e6cd9e-1043-96aa-6ce3-655b4bb99093@redhat.com> You can't impersonate progammatically at the moment. On 5/12/16 1:24 AM, Anshul Malpani wrote: > Hi, > > I am trying to use impersonate feature using my java client. When I > call impersonate api using admin access grant. I get back the cookies. > How can I get the access token for the impersonate user. > > > > HttpPost post = new HttpPost( > > KeycloakUriBuilder.fromUri(authServerUrl).path(?/admin/realms/{realm}/users/{id}/impersonation").build(realm, > accountKeycloakId)); > > This is returning me cookies. In next step I would like to get the > access token of impersonate user. > > Thanks > > On Wed, May 11, 2016 at 3:25 PM, Anshul Malpani > wrote: > > Hi, > > I am trying to use impersonate feature using my java client. When > I call impersonate api using admin access grant. I get back the > cookies. How can I get the access token for the impersonate user. > > > > HttpPost post = new HttpPost( > KeycloakUriBuilder.fromUri(authServerUrl).path(?/admin/realms/{realm}/users/{id}/impersonation").build(realm, > accountKeycloakId)); > > This is returning me cookies. In next step I would like to get the > access token of impersonate user. > > Thanks > A > > > > > > _______________________________________________ > 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/20160512/0ed5e7af/attachment.html From srossillo at smartling.com Thu May 12 13:43:41 2016 From: srossillo at smartling.com (Scott Rossillo) Date: Thu, 12 May 2016 13:43:41 -0400 Subject: [keycloak-dev] Keycloak impersonate programmatically In-Reply-To: <162C205D-BF33-4E6E-A413-C8808253BFD5@smartling.com> References: <6D865EE1-A08F-4944-A31C-83C4E83AEA45@dnbcloud.com> <80e6cd9e-1043-96aa-6ce3-655b4bb99093@redhat.com> <162C205D-BF33-4E6E-A413-C8808253BFD5@smartling.com> Message-ID: <1F2B299D-044D-4A2A-BFE8-AF450230A368@smartling.com> Adding back mailing list. See below. > On May 12, 2016, at 1:39 PM, Scott Rossillo wrote: > > We have a way to do in on our fork. It relies on a hard coded role to determine who can impersonate but the rest of the code is probably reusable. > > https://github.com/Smartling/keycloak/commit/06ac25bf24110061d3cb66ee8c62a726199000bb > > Scott Rossillo > Smartling | Senior Software Engineer > srossillo at smartling.com > >> On May 12, 2016, at 11:20 AM, Bill Burke wrote: >> >> You can't impersonate progammatically at the moment. >> >> On 5/12/16 1:24 AM, Anshul Malpani wrote: >>> Hi, >>> >>> I am trying to use impersonate feature using my java client. When I call impersonate api using admin access grant. I get back the cookies. How can I get the access token for the impersonate user. >>> >>> >>> >>> HttpPost post = new HttpPost( >>> KeycloakUriBuilder.fromUri(authServerUrl).path(?/admin/realms/{realm}/users/{id}/impersonation").build(realm, accountKeycloakId)); >>> >>> This is returning me cookies. In next step I would like to get the access token of impersonate user. >>> >>> Thanks >>> >>> On Wed, May 11, 2016 at 3:25 PM, Anshul Malpani > wrote: >>> Hi, >>> >>> I am trying to use impersonate feature using my java client. When I call impersonate api using admin access grant. I get back the cookies. How can I get the access token for the impersonate user. >>> >>> >>> >>> HttpPost post = new HttpPost( >>> KeycloakUriBuilder.fromUri(authServerUrl).path(?/admin/realms/{realm}/users/{id}/impersonation").build(realm, accountKeycloakId)); >>> >>> This is returning me cookies. In next step I would like to get the access token of impersonate user. >>> >>> Thanks >>> A >>> >>> >>> >>> >>> >>> _______________________________________________ >>> 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/20160512/dd96adbf/attachment.html From tech at psynd.net Fri May 13 07:28:41 2016 From: tech at psynd.net (Tech @ PSYND) Date: Fri, 13 May 2016 13:28:41 +0200 Subject: [keycloak-dev] Keycloak custom authenticator Message-ID: <88df47f58fa865ca26d4d986d9fb30e6@psynd.net> Dear experts, I'm working with keycloak 1.9.4. We ran some customization with the Authenticators: we implemented a couple of authenticators in sequence, like provide an OTP token, provide an additional information etc. We are facing several issues: 1) we create our custom Flow from the Authentication interface 2) we add our 4 form (Add Execution) 3) from the Flows Module we select the order in which they should be selected 4) we define in the binding sour flow as Browser Flow 5) we register and enable our executions from the Required Actions module. About point 3): even if we change the order of the flows using the priorities arrows, the forms doesn't show up in order. We tried to delete and to re-create, but we don't understand if we should do something else to impose the order that we need? Could you please support? Thanks From anshulm at stytch.com Fri May 13 15:25:31 2016 From: anshulm at stytch.com (Anshul Malpani) Date: Fri, 13 May 2016 12:25:31 -0700 Subject: [keycloak-dev] Keycloak impersonate programmatically In-Reply-To: <1F2B299D-044D-4A2A-BFE8-AF450230A368@smartling.com> References: <6D865EE1-A08F-4944-A31C-83C4E83AEA45@dnbcloud.com> <80e6cd9e-1043-96aa-6ce3-655b4bb99093@redhat.com> <162C205D-BF33-4E6E-A413-C8808253BFD5@smartling.com> <1F2B299D-044D-4A2A-BFE8-AF450230A368@smartling.com> Message-ID: <2AE5B057-65E2-4FB7-A3E7-5D2C54EC83C8@dnbcloud.com> Hi Bill, Thanks great change. Its something we don?t want to fork off the repository and maintain by ourselves. I am wondering if we can create a pull request and submit to master branch? Thanks A > On May 12, 2016, at 10:43 AM, Scott Rossillo wrote: > > Adding back mailing list. See below. > >> On May 12, 2016, at 1:39 PM, Scott Rossillo > wrote: >> >> We have a way to do in on our fork. It relies on a hard coded role to determine who can impersonate but the rest of the code is probably reusable. >> >> https://github.com/Smartling/keycloak/commit/06ac25bf24110061d3cb66ee8c62a726199000bb >> >> Scott Rossillo >> Smartling | Senior Software Engineer >> srossillo at smartling.com >> >>> On May 12, 2016, at 11:20 AM, Bill Burke > wrote: >>> >>> You can't impersonate progammatically at the moment. >>> >>> On 5/12/16 1:24 AM, Anshul Malpani wrote: >>>> Hi, >>>> >>>> I am trying to use impersonate feature using my java client. When I call impersonate api using admin access grant. I get back the cookies. How can I get the access token for the impersonate user. >>>> >>>> >>>> >>>> HttpPost post = new HttpPost( >>>> KeycloakUriBuilder.fromUri(authServerUrl).path(?/admin/realms/{realm}/users/{id}/impersonation").build(realm, accountKeycloakId)); >>>> >>>> This is returning me cookies. In next step I would like to get the access token of impersonate user. >>>> >>>> Thanks >>>> >>>> On Wed, May 11, 2016 at 3:25 PM, Anshul Malpani > wrote: >>>> Hi, >>>> >>>> I am trying to use impersonate feature using my java client. When I call impersonate api using admin access grant. I get back the cookies. How can I get the access token for the impersonate user. >>>> >>>> >>>> >>>> HttpPost post = new HttpPost( >>>> KeycloakUriBuilder.fromUri(authServerUrl).path(?/admin/realms/{realm}/users/{id}/impersonation").build(realm, accountKeycloakId)); >>>> >>>> This is returning me cookies. In next step I would like to get the access token of impersonate user. >>>> >>>> Thanks >>>> A >>>> >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> 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/20160513/9aac89bc/attachment.html From srossillo at smartling.com Fri May 13 15:28:59 2016 From: srossillo at smartling.com (Scott Rossillo) Date: Fri, 13 May 2016 15:28:59 -0400 Subject: [keycloak-dev] Keycloak impersonate programmatically In-Reply-To: <2AE5B057-65E2-4FB7-A3E7-5D2C54EC83C8@dnbcloud.com> References: <6D865EE1-A08F-4944-A31C-83C4E83AEA45@dnbcloud.com> <80e6cd9e-1043-96aa-6ce3-655b4bb99093@redhat.com> <162C205D-BF33-4E6E-A413-C8808253BFD5@smartling.com> <1F2B299D-044D-4A2A-BFE8-AF450230A368@smartling.com> <2AE5B057-65E2-4FB7-A3E7-5D2C54EC83C8@dnbcloud.com> Message-ID: <21DEBB37-2792-4465-9AA7-D92045D1B08B@smartling.com> Yes, we try to contribute as much back as possible. However, we?re a bit resource strapped right now and a proper PR would require full test coverage and documentation updates. If Keycloak maintainers think our patch looks acceptable and want us to contribute, I?ll spend the time on a proper PR. Scott Rossillo Smartling | Senior Software Engineer srossillo at smartling.com > On May 13, 2016, at 3:25 PM, Anshul Malpani wrote: > > Hi Bill, > > Thanks great change. Its something we don?t want to fork off the repository and maintain by ourselves. I am wondering if we can create a pull request and submit to master branch? > > Thanks > A > > > >> On May 12, 2016, at 10:43 AM, Scott Rossillo > wrote: >> >> Adding back mailing list. See below. >> >>> On May 12, 2016, at 1:39 PM, Scott Rossillo > wrote: >>> >>> We have a way to do in on our fork. It relies on a hard coded role to determine who can impersonate but the rest of the code is probably reusable. >>> >>> https://github.com/Smartling/keycloak/commit/06ac25bf24110061d3cb66ee8c62a726199000bb >>> >>> Scott Rossillo >>> Smartling | Senior Software Engineer >>> srossillo at smartling.com >>> >>>> On May 12, 2016, at 11:20 AM, Bill Burke > wrote: >>>> >>>> You can't impersonate progammatically at the moment. >>>> >>>> On 5/12/16 1:24 AM, Anshul Malpani wrote: >>>>> Hi, >>>>> >>>>> I am trying to use impersonate feature using my java client. When I call impersonate api using admin access grant. I get back the cookies. How can I get the access token for the impersonate user. >>>>> >>>>> >>>>> >>>>> HttpPost post = new HttpPost( >>>>> KeycloakUriBuilder.fromUri(authServerUrl).path(?/admin/realms/{realm}/users/{id}/impersonation").build(realm, accountKeycloakId)); >>>>> >>>>> This is returning me cookies. In next step I would like to get the access token of impersonate user. >>>>> >>>>> Thanks >>>>> >>>>> On Wed, May 11, 2016 at 3:25 PM, Anshul Malpani > wrote: >>>>> Hi, >>>>> >>>>> I am trying to use impersonate feature using my java client. When I call impersonate api using admin access grant. I get back the cookies. How can I get the access token for the impersonate user. >>>>> >>>>> >>>>> >>>>> HttpPost post = new HttpPost( >>>>> KeycloakUriBuilder.fromUri(authServerUrl).path(?/admin/realms/{realm}/users/{id}/impersonation").build(realm, accountKeycloakId)); >>>>> >>>>> This is returning me cookies. In next step I would like to get the access token of impersonate user. >>>>> >>>>> Thanks >>>>> A >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> 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/20160513/da3f1849/attachment-0001.html From brooks.isoldi at traversed.com Mon May 16 13:41:01 2016 From: brooks.isoldi at traversed.com (Brooks Isoldi) Date: Mon, 16 May 2016 13:41:01 -0400 Subject: [keycloak-dev] Helping accessing user Oauth tokens Message-ID: <573A062D.1040901@traversed.com> Hi all, I'm having trouble getting access to the oauth tokens that should be returned from the user authenticating with Twitter via the Keycloak login page. FYI, this is cross-posted on SO (http://stackoverflow.com/questions/37257623/accessing-user-oauth-tokens-returned-by-keycloak). ----- I have a Keycloak (standalone) v1.9.4.Final install setup using Wildfly 10 on an AWS instance and am trying to use keycloak (via keycloak's login page) and Twitter4j to authenticate a user with Twitter and then obviously have my application authenticate and view the users timeline, etc. I have configured the Identity Provider (Twitter), the realm and my client application. I also have a Twitter application setup at apps.twitter.com and the keys put into my twitter4j.properties file. So far, I am able to: 1. Go to my application's JSF webpage and get redirected to Keycloak's /auth login page 2. Click the Twitter logo and login with my Twitter account (separate account from the account that owns the Twitter application) 3. Complete the user information that Keycloak asks for 4. After completing the user information, Keycloak successfully directs the user back to the client application (in this case, a JSF page). The problem is, I can't figure out how to get access to the users OAuth AccessToken and AccessTokenSecret to combine with the Twitter application's ConsumerKey and ConsumerKeySecret. I'm trying to get the tokens from the FacesContext, but I suspect that context would not have it. |HttpSessionhttpSession =(HttpSession)facesContext.getExternalContext().getSession(false);KeycloakSecurityContextkeycloakContext =(RefreshableKeycloakSecurityContext)httpSession.getAttribute(KeycloakSecurityContext.class.getName());------- | Taking a page from the twitter broker demo, we used the KeyCloakSecurityContext held in the FacesContext's HTTPSession to get the Bearer token, dropped the demo's TwitterOAuthResponse class into our project and made a REST call to the realm's twitter token endpoint using the, but then we got a permission denied saying the client did not have access to the identity providers token. Any help would be greatly appreciated! -- Brooks Isoldi, Software Developer Traversed 7164 Columbia Gateway Drive, Suite 120A Columbia, MD 21046 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160516/03fee514/attachment.html From lball at redhat.com Mon May 16 17:19:05 2016 From: lball at redhat.com (Lance Ball) Date: Mon, 16 May 2016 17:19:05 -0400 Subject: [keycloak-dev] Direct Grant API for Confidential Clients Message-ID: Hi All I've been updating the keycloak-nodejs-auth-utils module to keep up with recent changes in Keycloak, and one thing I've noticed seems to contradict what's written in the documentation. Can anyone provide clarity on this for me? In the docs for Direct Access Grants[1] it says, "For confidential client's, you must create a Basic Auth Authorization header that contains the client_id and client secret. And pass in the form parameters for username and for each user credential. For example:" POST /auth/realms/demo/protocol/openid-connect/token Authorization: Basic atasdf023l2312023 Content-Type: application/x-www-form-urlencoded username=bburke&password=geheim&grant_type=password (That's copied and pasted into GMail. I hope the formatting is OK). But in the keycloak-nodejs-auth-utils module, I am able to obtain a grant without including the username and password. Additionally, I must specify 'client_credentials' as the grant_type [2]. Do I misunderstand what is going on here or is the documentation out of date? Thanks Lance [1] http://keycloak.github.io/docs/userguide/keycloak-server/html/direct-access-grants.html [2] https://github.com/keycloak/keycloak-nodejs-auth-utils/blob/master/lib/grant-manager.js#L71-L79 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160516/26cd3ed3/attachment.html From singhrasster at gmail.com Mon May 16 17:52:26 2016 From: singhrasster at gmail.com (Rashmi Singh) Date: Mon, 16 May 2016 16:52:26 -0500 Subject: [keycloak-dev] Authentication Provider chaining Message-ID: Hi, I am looking for a way to do authentication provider chaining with keycloak. Basically, I want to have multiple authentication providers, example username, Suregrid etc. On submitting username, we call a service and if that service tells us to use SureGrid, then we should be able to pass control to the corresponding authentication provider. So basically, I want to spilt one authentication provider into multiple and be able to chain them based on the response from the service called. I have not found any documentation that explains this. Could you suggest how to achieve this? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160516/27e315f3/attachment.html From alexgv99 at gmail.com Mon May 16 17:58:19 2016 From: alexgv99 at gmail.com (=?UTF-8?Q?Alex_Gouv=C3=AAa_Vasconcelos?=) Date: Mon, 16 May 2016 18:58:19 -0300 Subject: [keycloak-dev] Location Response Header Message-ID: I'm trying to follow the link obtained in a 201 (user created) in the Keycloak API but I can't access the "location" header which should be returned in the response... $http.post(url, user) .then( function(response) { console.log(response.headers()); }, function(error) {} ) The whole response.header() collection is empty... yet, the chrome developer console shows the url to the new resource... I think, maybe this is related to the problem described here ( http://www.aaron-powell.com/posts/2013-11-28-accessing-location-header-in-cors-response.html), but I have tryed to add the following lines to my keycloak.json and yet no success: "enable-cors": true, "cors-allowed-headers": "Location" Could anyone help me with that issue? ?Regards. Alex Gouv?a Vasconcelos?? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160516/0170c501/attachment.html From mposolda at redhat.com Tue May 17 04:36:20 2016 From: mposolda at redhat.com (Marek Posolda) Date: Tue, 17 May 2016 10:36:20 +0200 Subject: [keycloak-dev] Direct Grant API for Confidential Clients In-Reply-To: References: Message-ID: <573AD804.5070309@redhat.com> Hi Lance, if you specify the "grant_type=password" you are using Direct access grants (it's called "Resource Owner Password credentials grant" in OAuth2 specification) documented here [1] if you specify the "grant_type=client_credentials" you are using Service accounts and you are obtaining token on behalf of client (it's called "Client Credentials grant" in OAuth2 specification) and it's documented here [2] [1] http://keycloak.github.io/docs/userguide/keycloak-server/html/direct-access-grants.html [2] http://keycloak.github.io/docs/userguide/keycloak-server/html/service-accounts.html Marek On 16/05/16 23:19, Lance Ball wrote: > Hi All > > I've been updating the keycloak-nodejs-auth-utils module to keep up > with recent changes in Keycloak, and one thing I've noticed seems to > contradict what's written in the documentation. Can anyone provide > clarity on this for me? > > In the docs for Direct Access Grants[1] it says, "For confidential > client's, you must create a Basic Auth|Authorization|header that > contains the client_id and client secret. And pass in the form > parameters for username and for each user credential. For example:" > POST /auth/realms/demo/protocol/openid-connect/token > Authorization: Basic atasdf023l2312023 > Content-Type: application/x-www-form-urlencoded > > username=bburke&password=geheim&grant_type=password > (That's copied and pasted into GMail. I hope the formatting is OK). > > But in the keycloak-nodejs-auth-utils module, I am able to obtain a > grant without including the username and password. Additionally, I > must specify 'client_credentials' as the grant_type [2]. > > Do I misunderstand what is going on here or is the documentation out > of date? > > Thanks > Lance > > [1] > http://keycloak.github.io/docs/userguide/keycloak-server/html/direct-access-grants.html > [2] > https://github.com/keycloak/keycloak-nodejs-auth-utils/blob/master/lib/grant-manager.js#L71-L79 > > > _______________________________________________ > 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/20160517/61a2f83e/attachment-0001.html From mposolda at redhat.com Tue May 17 04:42:09 2016 From: mposolda at redhat.com (Marek Posolda) Date: Tue, 17 May 2016 10:42:09 +0200 Subject: [keycloak-dev] Helping accessing user Oauth tokens In-Reply-To: <573A062D.1040901@traversed.com> References: <573A062D.1040901@traversed.com> Message-ID: <573AD961.30201@redhat.com> You need to have "Store tokens" enabled for your identity provider in keycloak admin console. We also have some twitter example for showing this. It's maybe not working and needs some changes (it's not part of the official example distribution), but hopefully you can take a look at sources and have some inspiration from it : https://github.com/keycloak/keycloak/tree/master/examples/broker/twitter-authentication Btv. I would try to have first working setup locally and then move to AWS later. Just to eliminate that AWS is not the thing, which is causing issues here. Marek On 16/05/16 19:41, Brooks Isoldi wrote: > Hi all, > > I'm having trouble getting access to the oauth tokens that should be > returned from the user authenticating with Twitter via the Keycloak > login page. > > FYI, this is cross-posted on SO > (http://stackoverflow.com/questions/37257623/accessing-user-oauth-tokens-returned-by-keycloak). > > ----- > I have a Keycloak (standalone) v1.9.4.Final install setup using > Wildfly 10 on an AWS instance and am trying to use keycloak (via > keycloak's login page) and Twitter4j to authenticate a user with > Twitter and then obviously have my application authenticate and view > the users timeline, etc. > > I have configured the Identity Provider (Twitter), the realm and my > client application. > > I also have a Twitter application setup at apps.twitter.com and the > keys put into my twitter4j.properties file. > > So far, I am able to: > > 1. Go to my application's JSF webpage and get redirected to > Keycloak's /auth login page > 2. Click the Twitter logo and login with my Twitter account (separate > account from the account that owns the Twitter application) > 3. Complete the user information that Keycloak asks for > 4. After completing the user information, Keycloak successfully > directs the user back to the client application (in this case, a > JSF page). > > The problem is, I can't figure out how to get access to the users > OAuth AccessToken and AccessTokenSecret to combine with the Twitter > application's ConsumerKey and ConsumerKeySecret. > > I'm trying to get the tokens from the FacesContext, but I suspect that > context would not have it. > > |HttpSessionhttpSession > =(HttpSession)facesContext.getExternalContext().getSession(false);KeycloakSecurityContextkeycloakContext > =(RefreshableKeycloakSecurityContext)httpSession.getAttribute(KeycloakSecurityContext.class.getName());------- > | > Taking a page from the twitter broker demo, we used the > KeyCloakSecurityContext held in the FacesContext's HTTPSession to get > the Bearer token, dropped the demo's TwitterOAuthResponse class into > our project and made a REST call to the realm's twitter token endpoint > using the, but then we got a permission denied saying the client did > not have access to the identity providers token. > > Any help would be greatly appreciated! > > > -- > Brooks Isoldi, Software Developer > > Traversed > 7164 Columbia Gateway Drive, Suite 120A > Columbia, MD 21046 > > > > _______________________________________________ > 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/20160517/5e9e1dd5/attachment.html From mposolda at redhat.com Tue May 17 04:49:34 2016 From: mposolda at redhat.com (Marek Posolda) Date: Tue, 17 May 2016 10:49:34 +0200 Subject: [keycloak-dev] Authentication Provider chaining In-Reply-To: References: Message-ID: <573ADB1E.5090107@redhat.com> The docs is here : http://keycloak.github.io/docs/userguide/keycloak-server/html/auth_spi.html We have also example for authentication SPI. Note that you can create sub-flows in the "top" flow, which might be a way to split the authenticator into multiple ones. For example see "Forms" flow in default "Browser" flow. Also maybe you will need to implement some logic programatically in your authenticators based on various conditions etc. Depends on the usecase though... Marek On 16/05/16 23:52, Rashmi Singh wrote: > Hi, > > I am looking for a way to do authentication provider chaining with > keycloak. Basically, I want to have multiple authentication providers, > example username, Suregrid etc. On submitting username, we call a > service and if that service tells us to use SureGrid, then we should > be able to pass control to the corresponding authentication provider. > So basically, I want to spilt one authentication provider into > multiple and be able to chain them based on the response from the > service called. I have not found any documentation that explains this. > Could you suggest how to achieve this? > > > > > > _______________________________________________ > 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/20160517/88f76b69/attachment.html From thomas.raehalme at aitiofinland.com Tue May 17 09:21:56 2016 From: thomas.raehalme at aitiofinland.com (Thomas Raehalme) Date: Tue, 17 May 2016 16:21:56 +0300 Subject: [keycloak-dev] HttpClientBuilder and timeouts Message-ID: Hi! We have had a couple of strange issues where the HTTP connection pool for the HttpClient used by ServerRequest has been exhausted. Strange thing is, the thread dump on the JVM reports many threads waiting for a connection, but none actually using them. "http-apr-8080-exec-1" #33 daemon prio=5 os_prio=0 tid=0x00007f5c3400b000 nid=0x723a waiting on condition [0x00007f5bff7f6000] java.lang.Thread.State: WAITING (parking) at sun.misc.Unsafe.park(Native Method) - parking to wait for <0x00000000eb3edac0> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject) at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039) at org.apache.http.impl.conn.tsccm.WaitingThread.await(WaitingThread.java:159) at org.apache.http.impl.conn.tsccm.ConnPoolByRoute.getEntryBlocking(ConnPoolByRoute.java:398) at org.apache.http.impl.conn.tsccm.ConnPoolByRoute$1.getPoolEntry(ConnPoolByRoute.java:298) at org.apache.http.impl.conn.tsccm.ThreadSafeClientConnManager$1.getConnection(ThreadSafeClientConnManager.java:238) at org.apache.http.impl.client.DefaultRequestDirector.execute(DefaultRequestDirector.java:423) at org.apache.http.impl.client.AbstractHttpClient.doExecute(AbstractHttpClient.java:863) at org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:82) at org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:106) at org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:57) at org.keycloak.adapters.ServerRequest.invokeRefresh(ServerRequest.java:149) at org.keycloak.adapters.RefreshableKeycloakSecurityContext.refreshExpiredToken(RefreshableKeycloakSecurityContext.java:113) I'm still trying to figure out what's going on here, but while digging around I noticed that the HttpClientBuilder[1] does not set a timeout for obtaining a connection from the pool. Wouldn't it be a good idea to set one? Maybe 30s or so, just to avoid waiting indefinitely. The same applies to socket timeout as well. [1] https://github.com/keycloak/keycloak/blob/1.9.4.Final/services/src/main/java/org/keycloak/connections/httpclient/HttpClientBuilder.java Best regards, Thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160517/5232bb86/attachment.html From lball at redhat.com Tue May 17 11:25:44 2016 From: lball at redhat.com (Lance Ball) Date: Tue, 17 May 2016 11:25:44 -0400 Subject: [keycloak-dev] Direct Grant API for Confidential Clients In-Reply-To: <573AD804.5070309@redhat.com> References: <573AD804.5070309@redhat.com> Message-ID: Marek Thanks for that clarification - this helps a lot. It helps to read the spec. :) Resource Owner Password Credentials Grant - https://tools.ietf.org/html/rfc6749#section-4.3 Client Credentials Grant - https://tools.ietf.org/html/rfc6749#section-4.4 Lance On Tue, May 17, 2016 at 4:36 AM, Marek Posolda wrote: > Hi Lance, > > if you specify the "grant_type=password" you are using Direct access > grants (it's called "Resource Owner Password credentials grant" in OAuth2 > specification) documented here [1] > > if you specify the "grant_type=client_credentials" you are using Service > accounts and you are obtaining token on behalf of client (it's called > "Client Credentials grant" in OAuth2 specification) and it's documented > here [2] > > [1] > http://keycloak.github.io/docs/userguide/keycloak-server/html/direct-access-grants.html > [2] > http://keycloak.github.io/docs/userguide/keycloak-server/html/service-accounts.html > > Marek > > > On 16/05/16 23:19, Lance Ball wrote: > > Hi All > > I've been updating the keycloak-nodejs-auth-utils module to keep up with > recent changes in Keycloak, and one thing I've noticed seems to contradict > what's written in the documentation. Can anyone provide clarity on this for > me? > > In the docs for Direct Access Grants[1] it says, "For confidential > client's, you must create a Basic Auth Authorization header that contains > the client_id and client secret. And pass in the form parameters for > username and for each user credential. For example:" > > POST /auth/realms/demo/protocol/openid-connect/token > Authorization: Basic atasdf023l2312023 > Content-Type: application/x-www-form-urlencoded > > username=bburke&password=geheim&grant_type=password > > (That's copied and pasted into GMail. I hope the formatting is OK). > > But in the keycloak-nodejs-auth-utils module, I am able to obtain a grant > without including the username and password. Additionally, I must specify > 'client_credentials' as the grant_type [2]. > > Do I misunderstand what is going on here or is the documentation out of > date? > > Thanks > Lance > > [1] > http://keycloak.github.io/docs/userguide/keycloak-server/html/direct-access-grants.html > [2] > https://github.com/keycloak/keycloak-nodejs-auth-utils/blob/master/lib/grant-manager.js#L71-L79 > > > _______________________________________________ > 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/20160517/63f07408/attachment-0001.html From mitya at cargosoft.ru Tue May 17 23:37:09 2016 From: mitya at cargosoft.ru (Mitya) Date: Wed, 18 May 2016 06:37:09 +0300 Subject: [keycloak-dev] Support for LDAP referrals Message-ID: <1463542629.13752.20.camel@cargosoft.ru> Hi, In replicated LDAP setups, it's a common situation where the slave is read-only,?and if a write operation is attempted, it returns a so- called referral (see more here). Simply put, a referral is an instruction to proceed with the same LDAP operation but using different URL, contained within response. In a replicated setup, this URL would point to master instance, which is read-write. Currently, KeyCloak cannot use such a slave replica as a federation provider in a WRITABLE edit mode. LDAP entries are imported successfully; but further attempts to modify them in KeyCloak admin console give success message, while the actual values are not modified. If Sync Registrations is on, attempt to create a user results in the following exception: javax.naming.PartialResultException: [LDAP: error code 10 - Referral]; remaining name 'uid=foo,ou=People,dc=foobar,dc=com' at com.sun.jndi.ldap.LdapCtx.processReturnCode(LdapCtx.java:2971) at com.sun.jndi.ldap.LdapCtx.processReturnCode(LdapCtx.java:2888) at com.sun.jndi.ldap.LdapCtx.c_createSubcontext(LdapCtx.java:812) at com.sun.jndi.toolkit.ctx.ComponentDirContext.p_createSubcontext(Compone ntDirContext.java:341) at com.sun.jndi.toolkit.ctx.PartialCompositeDirContext.createSubcontext(Pa rtialCompositeDirContext.java:268) at com.sun.jndi.toolkit.ctx.PartialCompositeDirContext.createSubcontext(Pa rtialCompositeDirContext.java:256) at javax.naming.directory.InitialDirContext.createSubcontext(InitialDirCon text.java:197) at javax.naming.directory.InitialDirContext.createSubcontext(InitialDirCon text.java:197) at org.keycloak.federation.ldap.idm.store.ldap.LDAPOperationManager$7.exec ute(LDAPOperationManager.java:434) at org.keycloak.federation.ldap.idm.store.ldap.LDAPOperationManager$7.exec ute(LDAPOperationManager.java:431) at org.keycloak.federation.ldap.idm.store.ldap.LDAPOperationManager.execut e(LDAPOperationManager.java:536) at org.keycloak.federation.ldap.idm.store.ldap.LDAPOperationManager.create SubContext(LDAPOperationManager.java:431) LDAP referrals are fully supported by JNDI and LDAP stack; the only thing we need is to set a Context.REFERRAL ("java.naming.referral") environment property to "follow" before creating an InitialLdapContext. I've noticed that in org.keycloak.federation.ldap.LDAPConfig, there is an initial support for additional connection properties (currently hardcoded to return null). Are there any plans to implement this? Cheers, Mitya -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160518/3402a6ad/attachment.html From sthorger at redhat.com Wed May 18 02:45:33 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Wed, 18 May 2016 08:45:33 +0200 Subject: [keycloak-dev] Location Response Header In-Reply-To: References: Message-ID: Permitting the Location header has to be changed in the admin endpoints on the Keycloak server side. Adding those properties to keycloak.json only control CORS headers for services in your own application. Please create a JIRA issue for this, you can mark it as a bug as the admin endpoints should support CORS. On 16 May 2016 at 23:58, Alex Gouv?a Vasconcelos wrote: > I'm trying to follow the link obtained in a 201 (user created) in the > Keycloak API but I can't access the "location" header which should be > returned in the response... > > $http.post(url, user) > .then( > function(response) { console.log(response.headers()); }, > function(error) {} > ) > > The whole response.header() collection is empty... yet, the chrome > developer console shows the url to the new resource... > > I think, maybe this is related to the problem described here ( > http://www.aaron-powell.com/posts/2013-11-28-accessing-location-header-in-cors-response.html), > but I have tryed to add the following lines to my keycloak.json and yet no > success: > "enable-cors": true, > "cors-allowed-headers": "Location" > > Could anyone help me with that issue? > > ?Regards. > Alex Gouv?a Vasconcelos?? > > > _______________________________________________ > 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/20160518/7c8e84fc/attachment.html From sthorger at redhat.com Wed May 18 02:47:59 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Wed, 18 May 2016 08:47:59 +0200 Subject: [keycloak-dev] HttpClientBuilder and timeouts In-Reply-To: References: Message-ID: I see you created https://issues.jboss.org/browse/KEYCLOAK-3016. Is that the cause of this issue or are there potentially more issues here? On 17 May 2016 at 15:21, Thomas Raehalme wrote: > Hi! > > We have had a couple of strange issues where the HTTP connection pool for > the HttpClient used by ServerRequest has been exhausted. Strange thing is, > the thread dump on the JVM reports many threads waiting for a connection, > but none actually using them. > > "http-apr-8080-exec-1" #33 daemon prio=5 os_prio=0 tid=0x00007f5c3400b000 > nid=0x723a waiting on condition [0x00007f5bff7f6000] > java.lang.Thread.State: WAITING (parking) > at sun.misc.Unsafe.park(Native Method) > - parking to wait for <0x00000000eb3edac0> (a > java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject) > at > java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) > at > java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039) > at > org.apache.http.impl.conn.tsccm.WaitingThread.await(WaitingThread.java:159) > at > org.apache.http.impl.conn.tsccm.ConnPoolByRoute.getEntryBlocking(ConnPoolByRoute.java:398) > at > org.apache.http.impl.conn.tsccm.ConnPoolByRoute$1.getPoolEntry(ConnPoolByRoute.java:298) > at > org.apache.http.impl.conn.tsccm.ThreadSafeClientConnManager$1.getConnection(ThreadSafeClientConnManager.java:238) > at > org.apache.http.impl.client.DefaultRequestDirector.execute(DefaultRequestDirector.java:423) > at > org.apache.http.impl.client.AbstractHttpClient.doExecute(AbstractHttpClient.java:863) > at > org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:82) > at > org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:106) > at > org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:57) > at > org.keycloak.adapters.ServerRequest.invokeRefresh(ServerRequest.java:149) > at > org.keycloak.adapters.RefreshableKeycloakSecurityContext.refreshExpiredToken(RefreshableKeycloakSecurityContext.java:113) > > I'm still trying to figure out what's going on here, but while digging > around I noticed that the HttpClientBuilder[1] does not set a timeout for > obtaining a connection from the pool. Wouldn't it be a good idea to set > one? Maybe 30s or so, just to avoid waiting indefinitely. The same applies > to socket timeout as well. > > [1] > https://github.com/keycloak/keycloak/blob/1.9.4.Final/services/src/main/java/org/keycloak/connections/httpclient/HttpClientBuilder.java > > Best regards, > 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/20160518/d460fd64/attachment.html From thomas.raehalme at aitiofinland.com Wed May 18 02:52:43 2016 From: thomas.raehalme at aitiofinland.com (Thomas Raehalme) Date: Wed, 18 May 2016 09:52:43 +0300 Subject: [keycloak-dev] HttpClientBuilder and timeouts In-Reply-To: References: Message-ID: Hi! In my opinion they are two separate issues, but related to each other. KEYCLOAK-3016 describes a situation where this behavior can be reproduced. As a safety measure I'd still define reasonable timeouts instead of waiting indefinitely after the issue has been fixed. I'm examining the testsuite to find the proper place for testing BasicAuthRequestAuthenticator error handling... Best regards, Thomas On Wed, May 18, 2016 at 9:47 AM, Stian Thorgersen wrote: > I see you created https://issues.jboss.org/browse/KEYCLOAK-3016. Is that > the cause of this issue or are there potentially more issues here? > > On 17 May 2016 at 15:21, Thomas Raehalme > wrote: > >> Hi! >> >> We have had a couple of strange issues where the HTTP connection pool for >> the HttpClient used by ServerRequest has been exhausted. Strange thing is, >> the thread dump on the JVM reports many threads waiting for a connection, >> but none actually using them. >> >> "http-apr-8080-exec-1" #33 daemon prio=5 os_prio=0 tid=0x00007f5c3400b000 >> nid=0x723a waiting on condition [0x00007f5bff7f6000] >> java.lang.Thread.State: WAITING (parking) >> at sun.misc.Unsafe.park(Native Method) >> - parking to wait for <0x00000000eb3edac0> (a >> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject) >> at >> java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) >> at >> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039) >> at >> org.apache.http.impl.conn.tsccm.WaitingThread.await(WaitingThread.java:159) >> at >> org.apache.http.impl.conn.tsccm.ConnPoolByRoute.getEntryBlocking(ConnPoolByRoute.java:398) >> at >> org.apache.http.impl.conn.tsccm.ConnPoolByRoute$1.getPoolEntry(ConnPoolByRoute.java:298) >> at >> org.apache.http.impl.conn.tsccm.ThreadSafeClientConnManager$1.getConnection(ThreadSafeClientConnManager.java:238) >> at >> org.apache.http.impl.client.DefaultRequestDirector.execute(DefaultRequestDirector.java:423) >> at >> org.apache.http.impl.client.AbstractHttpClient.doExecute(AbstractHttpClient.java:863) >> at >> org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:82) >> at >> org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:106) >> at >> org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:57) >> at >> org.keycloak.adapters.ServerRequest.invokeRefresh(ServerRequest.java:149) >> at >> org.keycloak.adapters.RefreshableKeycloakSecurityContext.refreshExpiredToken(RefreshableKeycloakSecurityContext.java:113) >> >> I'm still trying to figure out what's going on here, but while digging >> around I noticed that the HttpClientBuilder[1] does not set a timeout for >> obtaining a connection from the pool. Wouldn't it be a good idea to set >> one? Maybe 30s or so, just to avoid waiting indefinitely. The same applies >> to socket timeout as well. >> >> [1] >> https://github.com/keycloak/keycloak/blob/1.9.4.Final/services/src/main/java/org/keycloak/connections/httpclient/HttpClientBuilder.java >> >> Best regards, >> 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/20160518/06446376/attachment-0001.html From thomas.raehalme at aitiofinland.com Wed May 18 03:13:51 2016 From: thomas.raehalme at aitiofinland.com (Thomas Raehalme) Date: Wed, 18 May 2016 10:13:51 +0300 Subject: [keycloak-dev] HttpClientBuilder and timeouts In-Reply-To: References: Message-ID: Hi! I now have a test reproducing the error, I should be able to submit a PR to fix KEYCLOAK-3016 within an hour or so. Best regards, Thomas On Wed, May 18, 2016 at 9:52 AM, Thomas Raehalme < thomas.raehalme at aitiofinland.com> wrote: > Hi! > > In my opinion they are two separate issues, but related to each other. > KEYCLOAK-3016 describes a situation where this behavior can be reproduced. > As a safety measure I'd still define reasonable timeouts instead of waiting > indefinitely after the issue has been fixed. > > I'm examining the testsuite to find the proper place for testing > BasicAuthRequestAuthenticator error handling... > > Best regards, > Thomas > > > On Wed, May 18, 2016 at 9:47 AM, Stian Thorgersen > wrote: > >> I see you created https://issues.jboss.org/browse/KEYCLOAK-3016. Is that >> the cause of this issue or are there potentially more issues here? >> >> On 17 May 2016 at 15:21, Thomas Raehalme < >> thomas.raehalme at aitiofinland.com> wrote: >> >>> Hi! >>> >>> We have had a couple of strange issues where the HTTP connection pool >>> for the HttpClient used by ServerRequest has been exhausted. Strange thing >>> is, the thread dump on the JVM reports many threads waiting for a >>> connection, but none actually using them. >>> >>> "http-apr-8080-exec-1" #33 daemon prio=5 os_prio=0 >>> tid=0x00007f5c3400b000 nid=0x723a waiting on condition [0x00007f5bff7f6000] >>> java.lang.Thread.State: WAITING (parking) >>> at sun.misc.Unsafe.park(Native Method) >>> - parking to wait for <0x00000000eb3edac0> (a >>> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject) >>> at >>> java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) >>> at >>> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039) >>> at >>> org.apache.http.impl.conn.tsccm.WaitingThread.await(WaitingThread.java:159) >>> at >>> org.apache.http.impl.conn.tsccm.ConnPoolByRoute.getEntryBlocking(ConnPoolByRoute.java:398) >>> at >>> org.apache.http.impl.conn.tsccm.ConnPoolByRoute$1.getPoolEntry(ConnPoolByRoute.java:298) >>> at >>> org.apache.http.impl.conn.tsccm.ThreadSafeClientConnManager$1.getConnection(ThreadSafeClientConnManager.java:238) >>> at >>> org.apache.http.impl.client.DefaultRequestDirector.execute(DefaultRequestDirector.java:423) >>> at >>> org.apache.http.impl.client.AbstractHttpClient.doExecute(AbstractHttpClient.java:863) >>> at >>> org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:82) >>> at >>> org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:106) >>> at >>> org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:57) >>> at >>> org.keycloak.adapters.ServerRequest.invokeRefresh(ServerRequest.java:149) >>> at >>> org.keycloak.adapters.RefreshableKeycloakSecurityContext.refreshExpiredToken(RefreshableKeycloakSecurityContext.java:113) >>> >>> I'm still trying to figure out what's going on here, but while digging >>> around I noticed that the HttpClientBuilder[1] does not set a timeout for >>> obtaining a connection from the pool. Wouldn't it be a good idea to set >>> one? Maybe 30s or so, just to avoid waiting indefinitely. The same applies >>> to socket timeout as well. >>> >>> [1] >>> https://github.com/keycloak/keycloak/blob/1.9.4.Final/services/src/main/java/org/keycloak/connections/httpclient/HttpClientBuilder.java >>> >>> Best regards, >>> 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/20160518/f969c16a/attachment.html From thomas.raehalme at aitiofinland.com Wed May 18 05:14:37 2016 From: thomas.raehalme at aitiofinland.com (Thomas Raehalme) Date: Wed, 18 May 2016 12:14:37 +0300 Subject: [keycloak-dev] Realm templates Message-ID: Hi! I searched Jira and the mailing lists if realm templates have been discussed before, but didn't find anything. Apologies if I missed an already existing thread. What would you think of adding support for realm templates? The idea would be similar to client templates. One could define common properties in a realm template and create concrete realms based on the template. Whenever any of the common properties need to be changed, it would only be necessary to make the changes on the template instead of changing individual realms separately. Changes to the template would propagate to realms automatically. I would like to see at least realm settings and roles being defined on the template. Maybe also clients and groups. Identity providers would also be useful. Keys, certificates, users and various credentials would naturally be specific to each realm. If possible it would be great if one could choose to override the settings in the template so that the template would only define default values. But if it complicates the implementation too much I'm sure the feature is just as useful without this possibility. I think this would make the life of SaaS application developers with realm per tenant much easier as you would not need to write custom tools to automate change propagation to realms. Could this be something for 2.0? Best regards, Thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160518/a8db5031/attachment.html From thomas.darimont at googlemail.com Wed May 18 05:21:38 2016 From: thomas.darimont at googlemail.com (Thomas Darimont) Date: Wed, 18 May 2016 11:21:38 +0200 Subject: [keycloak-dev] Location Response Header In-Reply-To: References: Message-ID: Hello, Would it be enough to add .exposedHeaders("Location") where the CORS headers are configured like: org.keycloak.services.resources.admin.AdminRoot#getRealmsAdmin? https://github.com/keycloak/keycloak/blob/92db7b3618852d953e5b53482668c3ff2a0bb057/services/src/main/java/org/keycloak/services/resources/admin/AdminRoot.java#L212 Cheers, Thomas 2016-05-18 8:45 GMT+02:00 Stian Thorgersen : > Permitting the Location header has to be changed in the admin endpoints on > the Keycloak server side. Adding those properties to keycloak.json only > control CORS headers for services in your own application. > > Please create a JIRA issue for this, you can mark it as a bug as the admin > endpoints should support CORS. > > On 16 May 2016 at 23:58, Alex Gouv?a Vasconcelos > wrote: > >> I'm trying to follow the link obtained in a 201 (user created) in the >> Keycloak API but I can't access the "location" header which should be >> returned in the response... >> >> $http.post(url, user) >> .then( >> function(response) { console.log(response.headers()); }, >> function(error) {} >> ) >> >> The whole response.header() collection is empty... yet, the chrome >> developer console shows the url to the new resource... >> >> I think, maybe this is related to the problem described here ( >> http://www.aaron-powell.com/posts/2013-11-28-accessing-location-header-in-cors-response.html), >> but I have tryed to add the following lines to my keycloak.json and yet no >> success: >> "enable-cors": true, >> "cors-allowed-headers": "Location" >> >> Could anyone help me with that issue? >> >> ?Regards. >> Alex Gouv?a Vasconcelos?? >> >> >> _______________________________________________ >> 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/20160518/17eceeb7/attachment.html From sthorger at redhat.com Wed May 18 08:04:16 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Wed, 18 May 2016 14:04:16 +0200 Subject: [keycloak-dev] Realm templates In-Reply-To: References: Message-ID: Having links between realms like this is not great. It shouldn't matter if two realms are on the same server or on different servers. In fact in a SaaS environment you should most likely not have many tenants on a single server and rather shard it. It would also be a fairly tedious thing to implement. Realms would need some inheritance, then there's the admin console to worry about. At the moment there's not even a "shared" place for multiple realms, so no logical place to create/edit realm templates. Another thing is that in the future we plan to remove master realm concept completely. Instead we'll have a trusted realm option that will use identity brokering behind the covers. The idea is that a single admin can manage multiple realms independently on what servers the realm are located on. This would mean that an admin in reality can only manage a single realm, but automatically authenticate to other realms to manage those as well without re-authentication. There would be no cross-realm permissions though, so no "master" realm admin that can manage realm templates. On 18 May 2016 at 11:14, Thomas Raehalme wrote: > Hi! > > I searched Jira and the mailing lists if realm templates have been > discussed before, but didn't find anything. Apologies if I missed an > already existing thread. > > What would you think of adding support for realm templates? > > The idea would be similar to client templates. One could define common > properties in a realm template and create concrete realms based on the > template. Whenever any of the common properties need to be changed, it > would only be necessary to make the changes on the template instead of > changing individual realms separately. Changes to the template would > propagate to realms automatically. > > I would like to see at least realm settings and roles being defined on the > template. Maybe also clients and groups. Identity providers would also be > useful. Keys, certificates, users and various credentials would naturally > be specific to each realm. > > If possible it would be great if one could choose to override the settings > in the template so that the template would only define default values. But > if it complicates the implementation too much I'm sure the feature is just > as useful without this possibility. > > I think this would make the life of SaaS application developers with realm > per tenant much easier as you would not need to write custom tools to > automate change propagation to realms. > > Could this be something for 2.0? > > Best regards, > 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/20160518/fa8cf0bd/attachment-0001.html From sthorger at redhat.com Wed May 18 08:06:00 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Wed, 18 May 2016 14:06:00 +0200 Subject: [keycloak-dev] Location Response Header In-Reply-To: References: Message-ID: Maybe, not 100% sure though On 18 May 2016 at 11:21, Thomas Darimont wrote: > Hello, > > Would it be enough to add .exposedHeaders("Location") where the CORS > headers are configured like: > org.keycloak.services.resources.admin.AdminRoot#getRealmsAdmin? > > https://github.com/keycloak/keycloak/blob/92db7b3618852d953e5b53482668c3ff2a0bb057/services/src/main/java/org/keycloak/services/resources/admin/AdminRoot.java#L212 > > Cheers, > Thomas > > 2016-05-18 8:45 GMT+02:00 Stian Thorgersen : > >> Permitting the Location header has to be changed in the admin endpoints >> on the Keycloak server side. Adding those properties to keycloak.json only >> control CORS headers for services in your own application. >> >> Please create a JIRA issue for this, you can mark it as a bug as the >> admin endpoints should support CORS. >> >> On 16 May 2016 at 23:58, Alex Gouv?a Vasconcelos >> wrote: >> >>> I'm trying to follow the link obtained in a 201 (user created) in the >>> Keycloak API but I can't access the "location" header which should be >>> returned in the response... >>> >>> $http.post(url, user) >>> .then( >>> function(response) { console.log(response.headers()); }, >>> function(error) {} >>> ) >>> >>> The whole response.header() collection is empty... yet, the chrome >>> developer console shows the url to the new resource... >>> >>> I think, maybe this is related to the problem described here ( >>> http://www.aaron-powell.com/posts/2013-11-28-accessing-location-header-in-cors-response.html), >>> but I have tryed to add the following lines to my keycloak.json and yet no >>> success: >>> "enable-cors": true, >>> "cors-allowed-headers": "Location" >>> >>> Could anyone help me with that issue? >>> >>> ?Regards. >>> Alex Gouv?a Vasconcelos?? >>> >>> >>> _______________________________________________ >>> 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/20160518/a2ffddb5/attachment.html From thomas.darimont at googlemail.com Wed May 18 08:08:51 2016 From: thomas.darimont at googlemail.com (Thomas Darimont) Date: Wed, 18 May 2016 12:08:51 +0000 Subject: [keycloak-dev] Location Response Header In-Reply-To: References: Message-ID: Okay, Alex could you provide us with a small example (js) that reproduces this? Cheers, Thomas Stian Thorgersen schrieb am Mi., 18. Mai 2016, 14:06: > Maybe, not 100% sure though > > On 18 May 2016 at 11:21, Thomas Darimont > wrote: > >> Hello, >> >> Would it be enough to add .exposedHeaders("Location") where the CORS >> headers are configured like: >> org.keycloak.services.resources.admin.AdminRoot#getRealmsAdmin? >> >> https://github.com/keycloak/keycloak/blob/92db7b3618852d953e5b53482668c3ff2a0bb057/services/src/main/java/org/keycloak/services/resources/admin/AdminRoot.java#L212 >> >> Cheers, >> Thomas >> >> 2016-05-18 8:45 GMT+02:00 Stian Thorgersen : >> >>> Permitting the Location header has to be changed in the admin endpoints >>> on the Keycloak server side. Adding those properties to keycloak.json only >>> control CORS headers for services in your own application. >>> >>> Please create a JIRA issue for this, you can mark it as a bug as the >>> admin endpoints should support CORS. >>> >>> On 16 May 2016 at 23:58, Alex Gouv?a Vasconcelos >>> wrote: >>> >>>> I'm trying to follow the link obtained in a 201 (user created) in the >>>> Keycloak API but I can't access the "location" header which should be >>>> returned in the response... >>>> >>>> $http.post(url, user) >>>> .then( >>>> function(response) { console.log(response.headers()); }, >>>> function(error) {} >>>> ) >>>> >>>> The whole response.header() collection is empty... yet, the chrome >>>> developer console shows the url to the new resource... >>>> >>>> I think, maybe this is related to the problem described here ( >>>> http://www.aaron-powell.com/posts/2013-11-28-accessing-location-header-in-cors-response.html), >>>> but I have tryed to add the following lines to my keycloak.json and yet no >>>> success: >>>> "enable-cors": true, >>>> "cors-allowed-headers": "Location" >>>> >>>> Could anyone help me with that issue? >>>> >>>> ?Regards. >>>> Alex Gouv?a Vasconcelos?? >>>> >>>> >>>> _______________________________________________ >>>> 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/20160518/bd02a65d/attachment.html From thomas.raehalme at aitiofinland.com Wed May 18 08:52:42 2016 From: thomas.raehalme at aitiofinland.com (Thomas Raehalme) Date: Wed, 18 May 2016 15:52:42 +0300 Subject: [keycloak-dev] Realm templates In-Reply-To: References: Message-ID: On Wed, May 18, 2016 at 3:04 PM, Stian Thorgersen wrote: > Having links between realms like this is not great. It shouldn't matter if > two realms are on the same server or on different servers. In fact in a > SaaS environment you should most likely not have many tenants on a single > server and rather shard it. > By sharding do you mean that the environment should have multiple independent Keycloak instances/clusters to which tenants are distributed? It would also be a fairly tedious thing to implement. Realms would need > some inheritance, then there's the admin console to worry about. At the > moment there's not even a "shared" place for multiple realms, so no logical > place to create/edit realm templates. > Oh I never presumed this would be easy task to do :-) > Another thing is that in the future we plan to remove master realm concept > completely. Instead we'll have a trusted realm option that will use > identity brokering behind the covers. The idea is that a single admin can > manage multiple realms independently on what servers the realm are located > on. This would mean that an admin in reality can only manage a single > realm, but automatically authenticate to other realms to manage those as > well without re-authentication. There would be no cross-realm permissions > though, so no "master" realm admin that can manage realm templates. > Do you mean that in the future the current master realm will be just-another-realm, but when creating new realms they automatically trust the master? Best regards, Thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160518/f7a8e820/attachment-0001.html From sthorger at redhat.com Wed May 18 08:59:23 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Wed, 18 May 2016 14:59:23 +0200 Subject: [keycloak-dev] Realm templates In-Reply-To: References: Message-ID: On 18 May 2016 at 14:52, Thomas Raehalme wrote: > > On Wed, May 18, 2016 at 3:04 PM, Stian Thorgersen > wrote: > >> Having links between realms like this is not great. It shouldn't matter >> if two realms are on the same server or on different servers. In fact in a >> SaaS environment you should most likely not have many tenants on a single >> server and rather shard it. >> > > By sharding do you mean that the environment should have multiple > independent Keycloak instances/clusters to which tenants are distributed? > Yes. At first our plan was to have a single Keycloak support multiple tenants in a SaaS environment. However, we decided that this level of tenants would be better achieved by having completely separate instances. > > It would also be a fairly tedious thing to implement. Realms would need >> some inheritance, then there's the admin console to worry about. At the >> moment there's not even a "shared" place for multiple realms, so no logical >> place to create/edit realm templates. >> > > Oh I never presumed this would be easy task to do :-) > I meant we're very unlikely to accept the feature due to the amount of complexity that would be involved. It also has very little benefit in the use-cases we've designed Keycloak for and wouldn't work when realms are located on separate instances which we expect would be the norm. > > >> Another thing is that in the future we plan to remove master realm >> concept completely. Instead we'll have a trusted realm option that will use >> identity brokering behind the covers. The idea is that a single admin can >> manage multiple realms independently on what servers the realm are located >> on. This would mean that an admin in reality can only manage a single >> realm, but automatically authenticate to other realms to manage those as >> well without re-authentication. There would be no cross-realm permissions >> though, so no "master" realm admin that can manage realm templates. >> > > Do you mean that in the future the current master realm will be > just-another-realm, but when creating new realms they automatically trust > the master? > There will be no special "master" realm at all. We've not fully figured out the bootstrapping of new realms. Rather than having a "master" realm it would be possible to link realms together which will enable cross-realm management. One key aspect of this is that not only will you be able to manage multiple realms within the Keycloak admin console, but you will also be able to authenticate to your own applications that exist in different realms. > > Best regards, > Thomas > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160518/588d64f6/attachment.html From alexgv99 at gmail.com Wed May 18 09:02:49 2016 From: alexgv99 at gmail.com (=?UTF-8?Q?Alex_Gouv=C3=AAa_Vasconcelos?=) Date: Wed, 18 May 2016 10:02:49 -0300 Subject: [keycloak-dev] Location Response Header In-Reply-To: References: Message-ID: Sure... HttpService.insertNewUser = function(user) { var deferred = $q.defer(); //user object brings from the interface, firstName, lastName, userName and email //here, it receives some other properties user.attributes = {}; user.emailVerified = false; user.enabled = true; user.requiredActions = ["VERIFY_EMAIL", "UPDATE_PASSWORD"]; var url = service.getUrlBase() + "/users"; //var url = https://sso-server/auth/admin/realms/realmname/users $http.post(url, user).then( function(response) { deferred.resolve( "User " + user.firstName + " " + user.lastName + " (" + user.email + ") successfully added" ); }, function(retorno) { deferred.reject( retorno.status + ": " + retorno.statusText + " [" + retorno.data + "]" ); } ); return deferred.promise; } that response in the first callback from the $http.post should be able to access the headers array, inlcuding location, but it can't. response.headers() returns []. Cordialmente. Alex Gouv?a Vasconcelos mailto:alexgv99 at gmail.com MSN: alexgv99 at hotmail.com http://about.me/alexgv99 2016-05-18 9:08 GMT-03:00 Thomas Darimont : > Okay, > > Alex could you provide us with a small example (js) that reproduces this? > > Cheers, > Thomas > > Stian Thorgersen schrieb am Mi., 18. Mai 2016, > 14:06: > >> Maybe, not 100% sure though >> >> On 18 May 2016 at 11:21, Thomas Darimont >> wrote: >> >>> Hello, >>> >>> Would it be enough to add .exposedHeaders("Location") where the CORS >>> headers are configured like: >>> org.keycloak.services.resources.admin.AdminRoot#getRealmsAdmin? >>> >>> https://github.com/keycloak/keycloak/blob/92db7b3618852d953e5b53482668c3ff2a0bb057/services/src/main/java/org/keycloak/services/resources/admin/AdminRoot.java#L212 >>> >>> Cheers, >>> Thomas >>> >>> 2016-05-18 8:45 GMT+02:00 Stian Thorgersen : >>> >>>> Permitting the Location header has to be changed in the admin endpoints >>>> on the Keycloak server side. Adding those properties to keycloak.json only >>>> control CORS headers for services in your own application. >>>> >>>> Please create a JIRA issue for this, you can mark it as a bug as the >>>> admin endpoints should support CORS. >>>> >>>> On 16 May 2016 at 23:58, Alex Gouv?a Vasconcelos >>>> wrote: >>>> >>>>> I'm trying to follow the link obtained in a 201 (user created) in the >>>>> Keycloak API but I can't access the "location" header which should be >>>>> returned in the response... >>>>> >>>>> $http.post(url, user) >>>>> .then( >>>>> function(response) { console.log(response.headers()); }, >>>>> function(error) {} >>>>> ) >>>>> >>>>> The whole response.header() collection is empty... yet, the chrome >>>>> developer console shows the url to the new resource... >>>>> >>>>> I think, maybe this is related to the problem described here ( >>>>> http://www.aaron-powell.com/posts/2013-11-28-accessing-location-header-in-cors-response.html), >>>>> but I have tryed to add the following lines to my keycloak.json and yet no >>>>> success: >>>>> "enable-cors": true, >>>>> "cors-allowed-headers": "Location" >>>>> >>>>> Could anyone help me with that issue? >>>>> >>>>> ?Regards. >>>>> Alex Gouv?a Vasconcelos?? >>>>> >>>>> >>>>> _______________________________________________ >>>>> 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/20160518/3430b5de/attachment-0001.html From thomas.raehalme at aitiofinland.com Wed May 18 09:07:38 2016 From: thomas.raehalme at aitiofinland.com (Thomas Raehalme) Date: Wed, 18 May 2016 16:07:38 +0300 Subject: [keycloak-dev] Realm templates In-Reply-To: References: Message-ID: On Wed, May 18, 2016 at 3:59 PM, Stian Thorgersen wrote: > > On 18 May 2016 at 14:52, Thomas Raehalme > wrote: >> >> By sharding do you mean that the environment should have multiple >> independent Keycloak instances/clusters to which tenants are distributed? >> > > Yes. At first our plan was to have a single Keycloak support multiple > tenants in a SaaS environment. However, we decided that this level of > tenants would be better achieved by having completely separate instances. > Ok, thanks for the clarification. I don't think from a developer point of view it makes a big difference to have multiple instances if you're already working with multiple realms. My concern, however, is how to manage all those realms hence my original message. At the moment there is no tool to support that, or at least I am not aware of one. It would also be a fairly tedious thing to implement. Realms would need >>> some inheritance, then there's the admin console to worry about. At the >>> moment there's not even a "shared" place for multiple realms, so no logical >>> place to create/edit realm templates. >>> >> >> Oh I never presumed this would be easy task to do :-) >> > > I meant we're very unlikely to accept the feature due to the amount of > complexity that would be involved. It also has very little benefit in the > use-cases we've designed Keycloak for and wouldn't work when realms are > located on separate instances which we expect would be the norm. > One important use case in my opinion is the possibility to ensure that in a SaaS environment all realms contain the required data. If you, for example, add a new role in your SaaS application, you'll need to make sure the role is added to all realms (and assign it to users properly). Another thing is that in the future we plan to remove master realm concept >> completely. Instead we'll have a trusted realm option that will use >> identity brokering behind the covers. The idea is that a single admin can >> manage multiple realms independently on what servers the realm are located >> on. This would mean that an admin in reality can only manage a single >> realm, but automatically authenticate to other realms to manage those as >> well without re-authentication. There would be no cross-realm permissions >> though, so no "master" realm admin that can manage realm templates. >> >> Do you mean that in the future the current master realm will be >> just-another-realm, but when creating new realms they automatically trust >> the master? >> > > There will be no special "master" realm at all. We've not fully figured > out the bootstrapping of new realms. Rather than having a "master" realm it > would be possible to link realms together which will enable cross-realm > management. One key aspect of this is that not only will you be able to > manage multiple realms within the Keycloak admin console, but you will also > be able to authenticate to your own applications that exist in different > realms. > How is that different from the currently available keycloak-oidc identity provider? Best regards, Thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160518/12819ec8/attachment.html From sthorger at redhat.com Wed May 18 09:19:52 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Wed, 18 May 2016 15:19:52 +0200 Subject: [keycloak-dev] Realm templates In-Reply-To: References: Message-ID: On 18 May 2016 at 15:07, Thomas Raehalme wrote: > > > On Wed, May 18, 2016 at 3:59 PM, Stian Thorgersen > wrote: >> >> On 18 May 2016 at 14:52, Thomas Raehalme < >> thomas.raehalme at aitiofinland.com> wrote: >>> >>> By sharding do you mean that the environment should have multiple >>> independent Keycloak instances/clusters to which tenants are distributed? >>> >> >> Yes. At first our plan was to have a single Keycloak support multiple >> tenants in a SaaS environment. However, we decided that this level of >> tenants would be better achieved by having completely separate instances. >> > > Ok, thanks for the clarification. I don't think from a developer point of > view it makes a big difference to have multiple instances if you're already > working with multiple realms. My concern, however, is how to manage all > those realms hence my original message. At the moment there is no tool to > support that, or at least I am not aware of one. > Fair point, but any solution would need to work with realms that are located on the same instance as well as on different instances. > > It would also be a fairly tedious thing to implement. Realms would need >>>> some inheritance, then there's the admin console to worry about. At the >>>> moment there's not even a "shared" place for multiple realms, so no logical >>>> place to create/edit realm templates. >>>> >>> >>> Oh I never presumed this would be easy task to do :-) >>> >> >> I meant we're very unlikely to accept the feature due to the amount of >> complexity that would be involved. It also has very little benefit in the >> use-cases we've designed Keycloak for and wouldn't work when realms are >> located on separate instances which we expect would be the norm. >> > > One important use case in my opinion is the possibility to ensure that in > a SaaS environment all realms contain the required data. If you, for > example, add a new role in your SaaS application, you'll need to make sure > the role is added to all realms (and assign it to users properly). > You could do that through admin rest endpoints > > > Another thing is that in the future we plan to remove master realm >>> concept completely. Instead we'll have a trusted realm option that will use >>> identity brokering behind the covers. The idea is that a single admin can >>> manage multiple realms independently on what servers the realm are located >>> on. This would mean that an admin in reality can only manage a single >>> realm, but automatically authenticate to other realms to manage those as >>> well without re-authentication. There would be no cross-realm permissions >>> though, so no "master" realm admin that can manage realm templates. >>> >>> Do you mean that in the future the current master realm will be >>> just-another-realm, but when creating new realms they automatically trust >>> the master? >>> >> >> There will be no special "master" realm at all. We've not fully figured >> out the bootstrapping of new realms. Rather than having a "master" realm it >> would be possible to link realms together which will enable cross-realm >> management. One key aspect of this is that not only will you be able to >> manage multiple realms within the Keycloak admin console, but you will also >> be able to authenticate to your own applications that exist in different >> realms. >> > > How is that different from the currently available keycloak-oidc identity > provider? > It would use keycloak-oidc identity provider behind the covers, but the bootstrapping would be a single click button. Rather than a button on login form we'd also hide the button and use idp_hint to automatically "login" to another realm. > > Best regards, > Thomas > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160518/ac7e874e/attachment.html From bburke at redhat.com Wed May 18 09:54:10 2016 From: bburke at redhat.com (Bill Burke) Date: Wed, 18 May 2016 09:54:10 -0400 Subject: [keycloak-dev] Realm templates In-Reply-To: References: Message-ID: <0c15ad8c-a2e4-add8-8977-d64b99708d7a@redhat.com> This would need to be a community contribution. We (the RHT/Keycloak open source devs) have too many things scheduled in queue right now and I don't think there would be a lot of users that would request this feature. On 5/18/16 9:19 AM, Stian Thorgersen wrote: > > > On 18 May 2016 at 15:07, Thomas Raehalme > > wrote: > > > > On Wed, May 18, 2016 at 3:59 PM, Stian Thorgersen > > wrote: > > On 18 May 2016 at 14:52, Thomas Raehalme > > wrote: > > By sharding do you mean that the environment should have > multiple independent Keycloak instances/clusters to which > tenants are distributed? > > > Yes. At first our plan was to have a single Keycloak support > multiple tenants in a SaaS environment. However, we decided > that this level of tenants would be better achieved by having > completely separate instances. > > > Ok, thanks for the clarification. I don't think from a developer > point of view it makes a big difference to have multiple instances > if you're already working with multiple realms. My concern, > however, is how to manage all those realms hence my original > message. At the moment there is no tool to support that, or at > least I am not aware of one. > > > Fair point, but any solution would need to work with realms that are > located on the same instance as well as on different instances. > > > It would also be a fairly tedious thing to implement. > Realms would need some inheritance, then there's the > admin console to worry about. At the moment there's > not even a "shared" place for multiple realms, so no > logical place to create/edit realm templates. > > > Oh I never presumed this would be easy task to do :-) > > > I meant we're very unlikely to accept the feature due to the > amount of complexity that would be involved. It also has very > little benefit in the use-cases we've designed Keycloak for > and wouldn't work when realms are located on separate > instances which we expect would be the norm. > > > One important use case in my opinion is the possibility to ensure > that in a SaaS environment all realms contain the required data. > If you, for example, add a new role in your SaaS application, > you'll need to make sure the role is added to all realms (and > assign it to users properly). > > > You could do that through admin rest endpoints > > > > Another thing is that in the future we plan to remove > master realm concept completely. Instead we'll have a > trusted realm option that will use identity brokering > behind the covers. The idea is that a single admin can > manage multiple realms independently on what servers the > realm are located on. This would mean that an admin in > reality can only manage a single realm, but automatically > authenticate to other realms to manage those as well > without re-authentication. There would be no cross-realm > permissions though, so no "master" realm admin that can > manage realm templates. > > Do you mean that in the future the current master realm > will be just-another-realm, but when creating new realms > they automatically trust the master? > > > There will be no special "master" realm at all. We've not > fully figured out the bootstrapping of new realms. Rather than > having a "master" realm it would be possible to link realms > together which will enable cross-realm management. One key > aspect of this is that not only will you be able to manage > multiple realms within the Keycloak admin console, but you > will also be able to authenticate to your own applications > that exist in different realms. > > > How is that different from the currently available keycloak-oidc > identity provider? > > > It would use keycloak-oidc identity provider behind the covers, but > the bootstrapping would be a single click button. Rather than a button > on login form we'd also hide the button and use idp_hint to > automatically "login" to another realm. > > > Best regards, > 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/20160518/1dd912ad/attachment-0001.html From sthorger at redhat.com Wed May 18 10:39:35 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Wed, 18 May 2016 16:39:35 +0200 Subject: [keycloak-dev] Realm templates In-Reply-To: <0c15ad8c-a2e4-add8-8977-d64b99708d7a@redhat.com> References: <0c15ad8c-a2e4-add8-8977-d64b99708d7a@redhat.com> Message-ID: IMO we shouldn't accept this if it was a community contribution as it would add unnecessary complexity On 18 May 2016 at 15:54, Bill Burke wrote: > This would need to be a community contribution. We (the RHT/Keycloak open > source devs) have too many things scheduled in queue right now and I don't > think there would be a lot of users that would request this feature. > > On 5/18/16 9:19 AM, Stian Thorgersen wrote: > > > > On 18 May 2016 at 15:07, Thomas Raehalme > wrote: > >> >> >> On Wed, May 18, 2016 at 3:59 PM, Stian Thorgersen >> wrote: >>> >>> On 18 May 2016 at 14:52, Thomas Raehalme < >>> thomas.raehalme at aitiofinland.com> >>> wrote: >>>> >>>> By sharding do you mean that the environment should have multiple >>>> independent Keycloak instances/clusters to which tenants are distributed? >>>> >>> >>> Yes. At first our plan was to have a single Keycloak support multiple >>> tenants in a SaaS environment. However, we decided that this level of >>> tenants would be better achieved by having completely separate instances. >>> >> >> Ok, thanks for the clarification. I don't think from a developer point of >> view it makes a big difference to have multiple instances if you're already >> working with multiple realms. My concern, however, is how to manage all >> those realms hence my original message. At the moment there is no tool to >> support that, or at least I am not aware of one. >> > > Fair point, but any solution would need to work with realms that are > located on the same instance as well as on different instances. > > >> >> It would also be a fairly tedious thing to implement. Realms would need >>>>> some inheritance, then there's the admin console to worry about. At the >>>>> moment there's not even a "shared" place for multiple realms, so no logical >>>>> place to create/edit realm templates. >>>>> >>>> >>>> Oh I never presumed this would be easy task to do :-) >>>> >>> >>> I meant we're very unlikely to accept the feature due to the amount of >>> complexity that would be involved. It also has very little benefit in the >>> use-cases we've designed Keycloak for and wouldn't work when realms are >>> located on separate instances which we expect would be the norm. >>> >> >> One important use case in my opinion is the possibility to ensure that in >> a SaaS environment all realms contain the required data. If you, for >> example, add a new role in your SaaS application, you'll need to make sure >> the role is added to all realms (and assign it to users properly). >> > > You could do that through admin rest endpoints > > >> >> >> Another thing is that in the future we plan to remove master realm >>>> concept completely. Instead we'll have a trusted realm option that will use >>>> identity brokering behind the covers. The idea is that a single admin can >>>> manage multiple realms independently on what servers the realm are located >>>> on. This would mean that an admin in reality can only manage a single >>>> realm, but automatically authenticate to other realms to manage those as >>>> well without re-authentication. There would be no cross-realm permissions >>>> though, so no "master" realm admin that can manage realm templates. >>>> >>>> Do you mean that in the future the current master realm will be >>>> just-another-realm, but when creating new realms they automatically trust >>>> the master? >>>> >>> >>> There will be no special "master" realm at all. We've not fully figured >>> out the bootstrapping of new realms. Rather than having a "master" realm it >>> would be possible to link realms together which will enable cross-realm >>> management. One key aspect of this is that not only will you be able to >>> manage multiple realms within the Keycloak admin console, but you will also >>> be able to authenticate to your own applications that exist in different >>> realms. >>> >> >> How is that different from the currently available keycloak-oidc identity >> provider? >> > > It would use keycloak-oidc identity provider behind the covers, but the > bootstrapping would be a single click button. Rather than a button on login > form we'd also hide the button and use idp_hint to automatically "login" to > another realm. > > >> >> Best regards, >> Thomas >> > > > > _______________________________________________ > 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/20160518/739ec9f6/attachment.html From singhrasster at gmail.com Wed May 18 17:21:58 2016 From: singhrasster at gmail.com (Rashmi Singh) Date: Wed, 18 May 2016 16:21:58 -0500 Subject: [keycloak-dev] Authentication Provider chaining In-Reply-To: <573ADB1E.5090107@redhat.com> References: <573ADB1E.5090107@redhat.com> Message-ID: Thanks a lot for your response. I went through the chapter. What I understand is we can create multiple executions (authentication providers) but they are executed in a serial fashion in a fixed order defined. Is there a way to be able to switch between them (so, not have it executed in the default serial way but depending on the response we get from an external service we called, we can switch to the corresponding one). Any ideas? On Tue, May 17, 2016 at 3:49 AM, Marek Posolda wrote: > The docs is here : > http://keycloak.github.io/docs/userguide/keycloak-server/html/auth_spi.html > > We have also example for authentication SPI. Note that you can create > sub-flows in the "top" flow, which might be a way to split the > authenticator into multiple ones. For example see "Forms" flow in default > "Browser" flow. Also maybe you will need to implement some logic > programatically in your authenticators based on various conditions etc. > Depends on the usecase though... > > Marek > > > On 16/05/16 23:52, Rashmi Singh wrote: > > Hi, > > I am looking for a way to do authentication provider chaining with > keycloak. Basically, I want to have multiple authentication providers, > example username, Suregrid etc. On submitting username, we call a service > and if that service tells us to use SureGrid, then we should be able to > pass control to the corresponding authentication provider. So basically, I > want to spilt one authentication provider into multiple and be able to > chain them based on the response from the service called. I have not found > any documentation that explains this. Could you suggest how to achieve this? > > > > > > _______________________________________________ > 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/20160518/13085542/attachment-0001.html From Stephen.Merchant at gandlake.com Thu May 19 04:20:42 2016 From: Stephen.Merchant at gandlake.com (Stephen Merchant) Date: Thu, 19 May 2016 08:20:42 +0000 Subject: [keycloak-dev] Keycloak : Multi-tenant : Login screen theming. Message-ID: <3DE4BF1BF8EDD84B8F8D61B0A88BD5630FFDEB@EXCH01.gandlake.local> Hello, Please - can somebody help me?! I have been evaluating Keycloak with the intention of providing SSO in a multi-tenant SAAS system. We intend that each tenant will have a dedicated realm, and 'Login User Experience' for each tenant must be cooperate customised. I have sussed from online sources that using innate Keycloak 'theming' will not help me to achieve this? I have also been advised not to use Login SPI as it is regarded as an internal software interface, and consequently subject to change in future Keycloak releases. I would be really grateful for a suggested legitimate approach of how to achieve this in Keycloak, I am a supporter of Keycloak, I can see the potential, and I really want to involve it within our SAAS solution. Thanks in advance, 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/20160519/6e6a3bc1/attachment.html From sthorger at redhat.com Thu May 19 05:20:08 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Thu, 19 May 2016 11:20:08 +0200 Subject: [keycloak-dev] Keycloak : Multi-tenant : Login screen theming. In-Reply-To: <3DE4BF1BF8EDD84B8F8D61B0A88BD5630FFDEB@EXCH01.gandlake.local> References: <3DE4BF1BF8EDD84B8F8D61B0A88BD5630FFDEB@EXCH01.gandlake.local> Message-ID: Please appreciate the fact that we are busy and that it may take a few days for us to be able to respond to questions in the community. As long as you are having a separate realm per tenant there's no problem at all. Each realm can have it's own theme. What's not supported is having a theme per client, but it doesn't sound like you need that. On 19 May 2016 at 10:20, Stephen Merchant wrote: > Hello, > > Please ? can somebody help me?! > > > > I have been evaluating Keycloak with the intention of providing SSO in a > multi-tenant SAAS system. > > > > We intend that each tenant will have a dedicated realm, and ?Login User > Experience? for each tenant must be cooperate customised. > > > > I have sussed from online sources that using innate Keycloak ?theming? > will not help me to achieve this? I have also been advised not to use > Login SPI as it is regarded as an internal software interface, and > consequently subject to change in future Keycloak releases. > > > > I would be *really* grateful for a suggested legitimate approach of how > to achieve this in Keycloak, > > > > I am a supporter of Keycloak, I can see the potential, and I *really* > want to involve it within our SAAS solution. > > > > Thanks in advance, > > > > 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/20160519/86828f2a/attachment.html From mitya at cargosoft.ru Thu May 19 06:36:18 2016 From: mitya at cargosoft.ru (Mitya) Date: Thu, 19 May 2016 13:36:18 +0300 Subject: [keycloak-dev] Implementing custom entities with KeyCloak Message-ID: <1463654178.4641.21.camel@cargosoft.ru> Hi, My goal is to implement a custom first-class KeyCloak entity (like User, Group, etc.) Entities should persist in KeyCloak database along with Users, Groups etc.; there should be a CRUD interface in the admin console to manage them; it will have an unidirectional N:1 relationship to User and will participate in authentication process. In some future, most likely it will also participate in federation (to/from external LDAP server with custom schema). After briefly studying KeyCloak internals, I've got an impression that Provider SPIs won't help me much. Seems like what I'll have to implement is at least: - model interface (org.keycloak.models) - entity class (org.keycloak.models.entities) - JPA adapter (org.keycloak.models.jpa) - JPA entity (org.keycloak.models.jpa.entities) - (the same for Mongo and Infinispan) - REST representation (org.keycloak.representations.idm) - REST resource (org.keycloak.services.resources.admin) ? Next, there will be custom authenticator (to make use of the entity) and GUI modifications. I hope I didn't forget anything? Important question is - can I implement all of that without modifying KeyCloak code? Maintaining a fork and producing customized builds will complicate development process a lot. Ideally, classes should reside in my own packages (not org.keycloak.*), the code should be packaged as a module (JBoss module? OSGi bundle?) and simply be plugged into an official KeyCloak build. I see forking only as a last resort, it's something I'd like to avoid absolutely. Thanks! Mitya From thomas.raehalme at aitiofinland.com Thu May 19 06:40:44 2016 From: thomas.raehalme at aitiofinland.com (Thomas Raehalme) Date: Thu, 19 May 2016 13:40:44 +0300 Subject: [keycloak-dev] The release date of 1.9.5 Message-ID: Hi! Do you already have the release date set for 1.9.5? I'd like to see KEYCLOAK-3016 fixed and was wondering if we should use a local build until 1.9.5 becomes available (hopefully containing the fix :-). Best regards, Thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160519/4dc0315a/attachment.html From sthorger at redhat.com Thu May 19 07:00:31 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Thu, 19 May 2016 13:00:31 +0200 Subject: [keycloak-dev] The release date of 1.9.5 In-Reply-To: References: Message-ID: Most likely next week. On 19 May 2016 at 12:40, Thomas Raehalme wrote: > Hi! > > Do you already have the release date set for 1.9.5? > > I'd like to see KEYCLOAK-3016 fixed and was wondering if we should use a > local build until 1.9.5 becomes available (hopefully containing the fix :-). > > Best regards, > 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/20160519/c7f69229/attachment.html From thomas.raehalme at aitiofinland.com Thu May 19 07:01:12 2016 From: thomas.raehalme at aitiofinland.com (Thomas Raehalme) Date: Thu, 19 May 2016 14:01:12 +0300 Subject: [keycloak-dev] The release date of 1.9.5 In-Reply-To: References: Message-ID: Ok, that's great, thanks! Best regards, Thomas On Thu, May 19, 2016 at 2:00 PM, Stian Thorgersen wrote: > Most likely next week. > > On 19 May 2016 at 12:40, Thomas Raehalme > wrote: > >> Hi! >> >> Do you already have the release date set for 1.9.5? >> >> I'd like to see KEYCLOAK-3016 fixed and was wondering if we should use a >> local build until 1.9.5 becomes available (hopefully containing the fix :-). >> >> Best regards, >> 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/20160519/a0478f06/attachment-0001.html From sthorger at redhat.com Thu May 19 07:02:29 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Thu, 19 May 2016 13:02:29 +0200 Subject: [keycloak-dev] The release date of 1.9.5 In-Reply-To: References: Message-ID: Thanks for the PR btw, it's always a pleasure to have JIRAs accompanied with PRs :) On 19 May 2016 at 13:01, Thomas Raehalme wrote: > Ok, that's great, thanks! > > Best regards, > Thomas > > > On Thu, May 19, 2016 at 2:00 PM, Stian Thorgersen > wrote: > >> Most likely next week. >> >> On 19 May 2016 at 12:40, Thomas Raehalme < >> thomas.raehalme at aitiofinland.com> wrote: >> >>> Hi! >>> >>> Do you already have the release date set for 1.9.5? >>> >>> I'd like to see KEYCLOAK-3016 fixed and was wondering if we should use a >>> local build until 1.9.5 becomes available (hopefully containing the fix :-). >>> >>> Best regards, >>> 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/20160519/65854d63/attachment.html From thomas.raehalme at aitiofinland.com Thu May 19 07:04:11 2016 From: thomas.raehalme at aitiofinland.com (Thomas Raehalme) Date: Thu, 19 May 2016 14:04:11 +0300 Subject: [keycloak-dev] The release date of 1.9.5 In-Reply-To: References: Message-ID: No prob! Glad I was able to fix the issue. Best regards, Thomas On Thu, May 19, 2016 at 2:02 PM, Stian Thorgersen wrote: > Thanks for the PR btw, it's always a pleasure to have JIRAs accompanied > with PRs :) > > On 19 May 2016 at 13:01, Thomas Raehalme > wrote: > >> Ok, that's great, thanks! >> >> Best regards, >> Thomas >> >> >> On Thu, May 19, 2016 at 2:00 PM, Stian Thorgersen >> wrote: >> >>> Most likely next week. >>> >>> On 19 May 2016 at 12:40, Thomas Raehalme < >>> thomas.raehalme at aitiofinland.com> wrote: >>> >>>> Hi! >>>> >>>> Do you already have the release date set for 1.9.5? >>>> >>>> I'd like to see KEYCLOAK-3016 fixed and was wondering if we should use >>>> a local build until 1.9.5 becomes available (hopefully containing the fix >>>> :-). >>>> >>>> Best regards, >>>> 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/20160519/0c4051be/attachment.html From sthorger at redhat.com Thu May 19 07:06:15 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Thu, 19 May 2016 13:06:15 +0200 Subject: [keycloak-dev] Implementing custom entities with KeyCloak In-Reply-To: <1463654178.4641.21.camel@cargosoft.ru> References: <1463654178.4641.21.camel@cargosoft.ru> Message-ID: You don't strictly need to use model interface, JPA adapter, etc.. You can just make it a entity directly. We have those layers because we support JPA and Mongo. At the moment you can't add custom entities to the persistence.xml without modifying it within the JAR, but we plan to introduce an Entity SPI that allows adding custom entities (we have a PR for it, it needs some work, but should be included in 2.0.0.CR1 due some time in June). We have added support for custom REST resource, but not admin resources. Main difference is how it's secured and URLs. You'd also need to modify the admin console, but that can be done with a custom theme. On 19 May 2016 at 12:36, Mitya wrote: > Hi, > > My goal is to implement a custom first-class KeyCloak entity (like > User, Group, etc.) Entities should persist in KeyCloak database along > with Users, Groups etc.; there should be a CRUD interface in the admin > console to manage them; it will have an unidirectional N:1 relationship > to User and will participate in authentication process. In some future, > most likely it will also participate in federation (to/from external > LDAP server with custom schema). > > After briefly studying KeyCloak internals, I've got an impression that > Provider SPIs won't help me much. Seems like what I'll have to > implement is at least: > > - model interface (org.keycloak.models) > - entity class (org.keycloak.models.entities) > - JPA adapter (org.keycloak.models.jpa) > - JPA entity (org.keycloak.models.jpa.entities) > - (the same for Mongo and Infinispan) > - REST representation (org.keycloak.representations.idm) > - REST resource (org.keycloak.services.resources.admin) > > Next, there will be custom authenticator (to make use of the entity) > and GUI modifications. I hope I didn't forget anything? > > Important question is - can I implement all of that without modifying > KeyCloak code? Maintaining a fork and producing customized builds will > complicate development process a lot. Ideally, classes should reside in > my own packages (not org.keycloak.*), the code should be packaged as a > module (JBoss module? OSGi bundle?) and simply be plugged into an > official KeyCloak build. I see forking only as a last resort, it's > something I'd like to avoid absolutely. > > Thanks! > 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/20160519/89546924/attachment.html From mitya at cargosoft.ru Thu May 19 08:48:19 2016 From: mitya at cargosoft.ru (Mitya) Date: Thu, 19 May 2016 15:48:19 +0300 Subject: [keycloak-dev] Implementing custom entities with KeyCloak In-Reply-To: References: <1463654178.4641.21.camel@cargosoft.ru> Message-ID: <1463662099.4641.29.camel@cargosoft.ru> Hi Stian, thanks for response! > You don't strictly need to use model interface, JPA adapter, etc.. > You can just make it a entity directly. We have those layers because > we support JPA and Mongo. thx, got it (interestingly, many IDM developers end up implementing a JDO-like engine; this has also happened to PicketLink, they supported both JPA and LDAP with a single API) > At the moment you can't add custom entities to the persistence.xml > without modifying it within the JAR, but we plan to introduce an > Entity SPI that allows adding custom entities (we have a PR for it, > it needs some work, but should be included in 2.0.0.CR1 due some time > in June). Glad to hear about Entity SPI! I'll probably start with modified KeyCloak, and migrate to the SPI as soon as it's ready. > We have added support for custom REST resource, but not admin > resources. Main difference is how it's secured and URLs. Could you please elaborate on "custom REST resources"? I couldn't find anything in the docs, there is only "21. Admin REST API". What are custom REST resources, how to implement them? Could they be helpful in my use case? Cheers, Mitya > > You'd also need to modify the admin console, but that can be done > with a custom theme. > > > On 19 May 2016 at 12:36, Mitya wrote: > > Hi, > > > > My goal is to implement a custom first-class KeyCloak entity (like > > User, Group, etc.) Entities should persist in KeyCloak database > > along > > with Users, Groups etc.; there should be a CRUD interface in the > > admin > > console to manage them; it will have an unidirectional N:1 > > relationship > > to User and will participate in authentication process. In some > > future, > > most likely it will also participate in federation (to/from > > external > > LDAP server with custom schema). > > > > After briefly studying KeyCloak internals, I've got an impression > > that > > Provider SPIs won't help me much. Seems like what I'll have to > > implement is at least: > > > > - model interface (org.keycloak.models) > > - entity class (org.keycloak.models.entities) > > - JPA adapter (org.keycloak.models.jpa) > > - JPA entity (org.keycloak.models.jpa.entities) > > - (the same for Mongo and Infinispan) > > - REST representation (org.keycloak.representations.idm) > > - REST resource (org.keycloak.services.resources.admin) > > ? > > Next, there will be custom authenticator (to make use of the > > entity) > > and GUI modifications. I hope I didn't forget anything? > > > > Important question is - can I implement all of that without > > modifying > > KeyCloak code? Maintaining a fork and producing customized builds > > will > > complicate development process a lot. Ideally, classes should > > reside in > > my own packages (not org.keycloak.*), the code should be packaged > > as a > > module (JBoss module? OSGi bundle?) and simply be plugged into an > > official KeyCloak build. I see forking only as a last resort, it's > > something I'd like to avoid absolutely. > > > > Thanks! > > Mitya > > > > _______________________________________________ > > keycloak-dev mailing list > > keycloak-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/keycloak-dev From sthorger at redhat.com Thu May 19 09:01:25 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Thu, 19 May 2016 15:01:25 +0200 Subject: [keycloak-dev] Implementing custom entities with KeyCloak In-Reply-To: <1463662099.4641.29.camel@cargosoft.ru> References: <1463654178.4641.21.camel@cargosoft.ru> <1463662099.4641.29.camel@cargosoft.ru> Message-ID: On 19 May 2016 at 14:48, Mitya wrote: > Hi Stian, thanks for response! > > > You don't strictly need to use model interface, JPA adapter, etc.. > > You can just make it a entity directly. We have those layers because > > we support JPA and Mongo. > > thx, got it > > (interestingly, many IDM developers end up implementing a JDO-like > engine; this has also happened to PicketLink, they supported both JPA > and LDAP with a single API) > > > At the moment you can't add custom entities to the persistence.xml > > without modifying it within the JAR, but we plan to introduce an > > Entity SPI that allows adding custom entities (we have a PR for it, > > it needs some work, but should be included in 2.0.0.CR1 due some time > > in June). > > Glad to hear about Entity SPI! I'll probably start with modified > KeyCloak, and migrate to the SPI as soon as it's ready. > You can give the PR a test if you'd like. It's in the list of PRs waiting to be merged. > > > We have added support for custom REST resource, but not admin > > resources. Main difference is how it's secured and URLs. > > Could you please elaborate on "custom REST resources"? I couldn't find > anything in the docs, there is only "21. Admin REST API". What are > custom REST resources, how to implement them? Could they be helpful in > my use case? > It allows adding custom rest endpoints. No docs or examples yet, but you can take a look at https://github.com/keycloak/keycloak/blob/master/testsuite/integration-arquillian/servers/auth-server/services/testsuite-providers/src/main/java/org/keycloak/testsuite/rest/TestingResourceProvider.java. We use it for our testsuite. > > Cheers, > Mitya > > > > You'd also need to modify the admin console, but that can be done > > with a custom theme. > > > > On 19 May 2016 at 12:36, Mitya wrote: > > > Hi, > > > > > > My goal is to implement a custom first-class KeyCloak entity (like > > > User, Group, etc.) Entities should persist in KeyCloak database > > > along > > > with Users, Groups etc.; there should be a CRUD interface in the > > > admin > > > console to manage them; it will have an unidirectional N:1 > > > relationship > > > to User and will participate in authentication process. In some > > > future, > > > most likely it will also participate in federation (to/from > > > external > > > LDAP server with custom schema). > > > > > > After briefly studying KeyCloak internals, I've got an impression > > > that > > > Provider SPIs won't help me much. Seems like what I'll have to > > > implement is at least: > > > > > > - model interface (org.keycloak.models) > > > - entity class (org.keycloak.models.entities) > > > - JPA adapter (org.keycloak.models.jpa) > > > - JPA entity (org.keycloak.models.jpa.entities) > > > - (the same for Mongo and Infinispan) > > > - REST representation (org.keycloak.representations.idm) > > > - REST resource (org.keycloak.services.resources.admin) > > > > > > Next, there will be custom authenticator (to make use of the > > > entity) > > > and GUI modifications. I hope I didn't forget anything? > > > > > > Important question is - can I implement all of that without > > > modifying > > > KeyCloak code? Maintaining a fork and producing customized builds > > > will > > > complicate development process a lot. Ideally, classes should > > > reside in > > > my own packages (not org.keycloak.*), the code should be packaged > > > as a > > > module (JBoss module? OSGi bundle?) and simply be plugged into an > > > official KeyCloak build. I see forking only as a last resort, it's > > > something I'd like to avoid absolutely. > > > > > > Thanks! > > > 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/20160519/0aa7814d/attachment-0001.html From lball at redhat.com Thu May 19 09:41:36 2016 From: lball at redhat.com (Lance Ball) Date: Thu, 19 May 2016 09:41:36 -0400 Subject: [keycloak-dev] Account Endpoint Message-ID: Hi there While updating the keycloak-nodejs-auth-utils to match current endpoints, I stumbled on this function: https://github.com/keycloak/keycloak-nodejs-auth-utils/blob/master/lib/grant-manager.js#L326-L353. It looks like the endpoint is $REALM_URL/account, but I don't think that endpoint still exists. I looked through the documentation to try and find its current equivalent, but nothing jumped out at me. Can anyone here point me in the right direction? Somewhat related, as I have been doing this work on the JS module, I have been stymied a bit by the existing documentation. As I complained to him, Bruno pointed me to this document https://github.com/keycloak/keycloak/wiki/Docs. I applaud the effort and want to give a big +100 to " Improved organization / grouping of REST endpoints." For my efforts, this has been the biggest impediment to speedy progress so far. Thanks Lance -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160519/5aa45a9a/attachment.html From sthorger at redhat.com Thu May 19 09:56:53 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Thu, 19 May 2016 15:56:53 +0200 Subject: [keycloak-dev] Account Endpoint In-Reply-To: References: Message-ID: There's no REST API for account services at the moment, only HTML pages. So not sure what "grant-manager" is supposed to do. On 19 May 2016 at 15:41, Lance Ball wrote: > Hi there > > While updating the keycloak-nodejs-auth-utils to match current endpoints, > I stumbled on this function: > https://github.com/keycloak/keycloak-nodejs-auth-utils/blob/master/lib/grant-manager.js#L326-L353. > It looks like the endpoint is $REALM_URL/account, but I don't think that > endpoint still exists. I looked through the documentation to try and find > its current equivalent, but nothing jumped out at me. Can anyone here point > me in the right direction? > > Somewhat related, as I have been doing this work on the JS module, I have > been stymied a bit by the existing documentation. As I complained to him, > Bruno pointed me to this document > https://github.com/keycloak/keycloak/wiki/Docs. I applaud the effort and > want to give a big +100 to " Improved organization / grouping of REST > endpoints." For my efforts, this has been the biggest impediment to speedy > progress so far. > > Thanks > Lance > > _______________________________________________ > 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/20160519/439cf217/attachment.html From lball at redhat.com Thu May 19 09:59:08 2016 From: lball at redhat.com (Lance Ball) Date: Thu, 19 May 2016 09:59:08 -0400 Subject: [keycloak-dev] Account Endpoint In-Reply-To: References: Message-ID: On Thu, May 19, 2016 at 9:56 AM, Stian Thorgersen wrote: > There's no REST API for account services at the moment, only HTML pages. > So not sure what "grant-manager" is supposed to do. > Me neither - that's why I asked! :) I'll ping bobmcw - the original author to see if he can shed some light. Thanks Lance -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160519/9fbbb202/attachment.html From lball at redhat.com Thu May 19 10:10:44 2016 From: lball at redhat.com (Lance Ball) Date: Thu, 19 May 2016 10:10:44 -0400 Subject: [keycloak-dev] Account Endpoint In-Reply-To: References: Message-ID: Stian OK - so Bob points me to this: https://github.com/keycloak/keycloak/blob/master/services/src/main/java/org/keycloak/services/resources/RealmsResource.java#L190-L205 and https://github.com/keycloak/keycloak/blob/master/services/src/main/java/org/keycloak/services/resources/AccountService.java#L253-L287 Is this endpoint documented anywhere? Thanks Lance On Thu, May 19, 2016 at 9:59 AM, Lance Ball wrote: > > On Thu, May 19, 2016 at 9:56 AM, Stian Thorgersen > wrote: > >> There's no REST API for account services at the moment, only HTML pages. >> So not sure what "grant-manager" is supposed to do. >> > > Me neither - that's why I asked! :) > > I'll ping bobmcw - the original author to see if he can shed some light. > > Thanks > Lance > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160519/873648e1/attachment.html From sthorger at redhat.com Thu May 19 10:24:15 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Thu, 19 May 2016 16:24:15 +0200 Subject: [keycloak-dev] Account Endpoint In-Reply-To: References: Message-ID: The only endpoint that is supported in AccountService is getting user profile, but that's kind outdated and changing to the OIDC userinfo endpoint would be recommended (..//protocols/openid-connect/userinfo). On 19 May 2016 at 16:10, Lance Ball wrote: > Stian > > OK - so Bob points me to this: > > > https://github.com/keycloak/keycloak/blob/master/services/src/main/java/org/keycloak/services/resources/RealmsResource.java#L190-L205 > and > > https://github.com/keycloak/keycloak/blob/master/services/src/main/java/org/keycloak/services/resources/AccountService.java#L253-L287 > > Is this endpoint documented anywhere? > > Thanks > Lance > > > On Thu, May 19, 2016 at 9:59 AM, Lance Ball wrote: > >> >> On Thu, May 19, 2016 at 9:56 AM, Stian Thorgersen >> wrote: >> >>> There's no REST API for account services at the moment, only HTML pages. >>> So not sure what "grant-manager" is supposed to do. >>> >> >> Me neither - that's why I asked! :) >> >> I'll ping bobmcw - the original author to see if he can shed some light. >> >> Thanks >> Lance >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160519/1a1d6fa4/attachment.html From sthorger at redhat.com Thu May 19 10:24:33 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Thu, 19 May 2016 16:24:33 +0200 Subject: [keycloak-dev] Account Endpoint In-Reply-To: References: Message-ID: ....Not outdated, but userinfo endpoint is standard spec way to do it On 19 May 2016 at 16:24, Stian Thorgersen wrote: > The only endpoint that is supported in AccountService is getting user > profile, but that's kind outdated and changing to the OIDC userinfo > endpoint would be recommended > (..//protocols/openid-connect/userinfo). > > On 19 May 2016 at 16:10, Lance Ball wrote: > >> Stian >> >> OK - so Bob points me to this: >> >> >> https://github.com/keycloak/keycloak/blob/master/services/src/main/java/org/keycloak/services/resources/RealmsResource.java#L190-L205 >> and >> >> https://github.com/keycloak/keycloak/blob/master/services/src/main/java/org/keycloak/services/resources/AccountService.java#L253-L287 >> >> Is this endpoint documented anywhere? >> >> Thanks >> Lance >> >> >> On Thu, May 19, 2016 at 9:59 AM, Lance Ball wrote: >> >>> >>> On Thu, May 19, 2016 at 9:56 AM, Stian Thorgersen >>> wrote: >>> >>>> There's no REST API for account services at the moment, only HTML >>>> pages. So not sure what "grant-manager" is supposed to do. >>>> >>> >>> Me neither - that's why I asked! :) >>> >>> I'll ping bobmcw - the original author to see if he can shed some light. >>> >>> Thanks >>> Lance >>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160519/7c5ca376/attachment-0001.html From singhrasster at gmail.com Thu May 19 10:31:08 2016 From: singhrasster at gmail.com (Rashmi Singh) Date: Thu, 19 May 2016 09:31:08 -0500 Subject: [keycloak-dev] Authentication Provider chaining In-Reply-To: References: <573ADB1E.5090107@redhat.com> Message-ID: Could someone please tell me if this is even possible? I do not want the execution engines/authentication providers to be executed in a fixed order defined in the admin console. But, need to be able to switch to any in the chain depending on some response I get upon invoking an external service. I needed to know if this is possible and if yes, then how? Any help would be appreciated. On Wed, May 18, 2016 at 4:21 PM, Rashmi Singh wrote: > Thanks a lot for your response. I went through the chapter. What I > understand is we can create multiple executions (authentication providers) > but they are executed in a serial fashion in a fixed order defined. Is > there a way to be able to switch between them (so, not have it executed in > the default serial way but depending on the response we get from an > external service we called, we can switch to the corresponding one). Any > ideas? > > On Tue, May 17, 2016 at 3:49 AM, Marek Posolda > wrote: > >> The docs is here : >> http://keycloak.github.io/docs/userguide/keycloak-server/html/auth_spi.html >> >> We have also example for authentication SPI. Note that you can create >> sub-flows in the "top" flow, which might be a way to split the >> authenticator into multiple ones. For example see "Forms" flow in default >> "Browser" flow. Also maybe you will need to implement some logic >> programatically in your authenticators based on various conditions etc. >> Depends on the usecase though... >> >> Marek >> >> >> On 16/05/16 23:52, Rashmi Singh wrote: >> >> Hi, >> >> I am looking for a way to do authentication provider chaining with >> keycloak. Basically, I want to have multiple authentication providers, >> example username, Suregrid etc. On submitting username, we call a service >> and if that service tells us to use SureGrid, then we should be able to >> pass control to the corresponding authentication provider. So basically, I >> want to spilt one authentication provider into multiple and be able to >> chain them based on the response from the service called. I have not found >> any documentation that explains this. Could you suggest how to achieve this? >> >> >> >> >> >> _______________________________________________ >> 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/20160519/b9a2ea9a/attachment.html From lball at redhat.com Thu May 19 11:17:12 2016 From: lball at redhat.com (Lance Ball) Date: Thu, 19 May 2016 11:17:12 -0400 Subject: [keycloak-dev] Account Endpoint In-Reply-To: References: Message-ID: OK - thank you. I will update the NPM module to use this endpoint. LB On Thu, May 19, 2016 at 10:24 AM, Stian Thorgersen wrote: > ....Not outdated, but userinfo endpoint is standard spec way to do it > > On 19 May 2016 at 16:24, Stian Thorgersen wrote: > >> The only endpoint that is supported in AccountService is getting user >> profile, but that's kind outdated and changing to the OIDC userinfo >> endpoint would be recommended >> (..//protocols/openid-connect/userinfo). >> >> On 19 May 2016 at 16:10, Lance Ball wrote: >> >>> Stian >>> >>> OK - so Bob points me to this: >>> >>> >>> https://github.com/keycloak/keycloak/blob/master/services/src/main/java/org/keycloak/services/resources/RealmsResource.java#L190-L205 >>> and >>> >>> https://github.com/keycloak/keycloak/blob/master/services/src/main/java/org/keycloak/services/resources/AccountService.java#L253-L287 >>> >>> Is this endpoint documented anywhere? >>> >>> Thanks >>> Lance >>> >>> >>> On Thu, May 19, 2016 at 9:59 AM, Lance Ball wrote: >>> >>>> >>>> On Thu, May 19, 2016 at 9:56 AM, Stian Thorgersen >>>> wrote: >>>> >>>>> There's no REST API for account services at the moment, only HTML >>>>> pages. So not sure what "grant-manager" is supposed to do. >>>>> >>>> >>>> Me neither - that's why I asked! :) >>>> >>>> I'll ping bobmcw - the original author to see if he can shed some light. >>>> >>>> Thanks >>>> Lance >>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160519/99922d5f/attachment.html From marc.savy at redhat.com Thu May 19 14:07:05 2016 From: marc.savy at redhat.com (Marc Savy) Date: Thu, 19 May 2016 19:07:05 +0100 Subject: [keycloak-dev] Possible bug in Tomcat8 adapter Message-ID: Hi All, I've been setting up apiman's quickstart tomcat8 distro with Keycloak (rather than using the inbuilt auth). I've managed to get everything working swimmingly, with one strange issue: HttpServletRequest#getRemoteUser() - On WildFly, this code[1] returns the preferred_username (e.g. admin). Expected behaviour. - On Tomcat8 it return the subject[2] (e.g. 5291684c-225a-4b3d-8795-15486feaf2ae) I think the problem might stem from where the principal is being built: https://github.com/keycloak/keycloak/blob/master/adapters/spi/tomcat-adapter-spi/src/main/java/org/keycloak/adapters/tomcat/GenericPrincipalFactory.java#L39 Are we misusing #getRemoteUser, or is there an error in the adapter? Regards, Marc [1] https://github.com/apiman/apiman/blob/master/manager/ui/war/src/main/java/io/apiman/manager/ui/server/servlets/ConfigurationServlet.java#L105 [2] 'id' in UI From mitya at cargosoft.ru Thu May 19 14:44:41 2016 From: mitya at cargosoft.ru (Mitya) Date: Thu, 19 May 2016 21:44:41 +0300 Subject: [keycloak-dev] Implementing custom entities with KeyCloak In-Reply-To: <1463662099.4641.29.camel@cargosoft.ru> References: <1463654178.4641.21.camel@cargosoft.ru> <1463662099.4641.29.camel@cargosoft.ru> Message-ID: <1463683481.4641.40.camel@cargosoft.ru> Stian, A follow-up on realm resources - I've stumbled upon this thread:?http://lists.jboss.org/pipermail/keycloak-dev/2015-December/006100.html That "(coming) ability to freely extend the JPA entities and DB schema" is the very same Entity SPI you were talking about, right? I see now how to implement realm resources. It's a pity that custom admin resources (initially included into Pedro Igor's commit) were removed; these would be a fairly natural addition to the upcoming Entity SPI. Are there any plans to include that back? As a workaround, is it possible to install a custom realm resource (/realms/{realm}/foo), manually protect it with an authorization constraint, and use it inside admin console (as a surrogate admin resource)? Cheers, Mitya P.S. BTW, examples/providers/rest/pom.xml contains an erroneous "Authenticator Example" inside > Hi Stian, thanks for response! > > > You don't strictly need to use model interface, JPA adapter, etc.. > > You can just make it a entity directly. We have those layers > > because > > we support JPA and Mongo.? > > thx, got it > > (interestingly, many IDM developers end up implementing a JDO-like > engine; this has also happened to PicketLink, they supported both JPA > and LDAP with a single API) > > > At the moment you can't add custom entities to the persistence.xml > > without modifying it within the JAR, but we plan to introduce an > > Entity SPI that allows adding custom entities (we have a PR for it, > > it needs some work, but should be included in 2.0.0.CR1 due some > > time > > in June). > > Glad to hear about Entity SPI! I'll probably start with modified > KeyCloak, and migrate to the SPI as soon as it's ready. > > > We have added support for custom REST resource, but not admin > > resources. Main difference is how it's secured and URLs. > > Could you please elaborate on "custom REST resources"? I couldn't > find > anything in the docs, there is only "21. Admin REST API". What are > custom REST resources, how to implement them? Could they be helpful > in > my use case? > > Cheers, > Mitya > > > > You'd also need to modify the admin console, but that can be done > > with a custom theme. > > > > On 19 May 2016 at 12:36, Mitya wrote: > > > Hi, > > > > > > My goal is to implement a custom first-class KeyCloak entity > > > (like > > > User, Group, etc.) Entities should persist in KeyCloak database > > > along > > > with Users, Groups etc.; there should be a CRUD interface in the > > > admin > > > console to manage them; it will have an unidirectional N:1 > > > relationship > > > to User and will participate in authentication process. In some > > > future, > > > most likely it will also participate in federation (to/from > > > external > > > LDAP server with custom schema). > > > > > > After briefly studying KeyCloak internals, I've got an impression > > > that > > > Provider SPIs won't help me much. Seems like what I'll have to > > > implement is at least: > > > > > > - model interface (org.keycloak.models) > > > - entity class (org.keycloak.models.entities) > > > - JPA adapter (org.keycloak.models.jpa) > > > - JPA entity (org.keycloak.models.jpa.entities) > > > - (the same for Mongo and Infinispan) > > > - REST representation (org.keycloak.representations.idm) > > > - REST resource (org.keycloak.services.resources.admin) > > > ? > > > Next, there will be custom authenticator (to make use of the > > > entity) > > > and GUI modifications. I hope I didn't forget anything? > > > > > > Important question is - can I implement all of that without > > > modifying > > > KeyCloak code? Maintaining a fork and producing customized builds > > > will > > > complicate development process a lot. Ideally, classes should > > > reside in > > > my own packages (not org.keycloak.*), the code should be packaged > > > as a > > > module (JBoss module? OSGi bundle?) and simply be plugged into an > > > official KeyCloak build. I see forking only as a last resort, > > > it's > > > something I'd like to avoid absolutely. > > > > > > Thanks! > > > Mitya > > > > > > _______________________________________________ > > > 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 Thu May 19 15:05:30 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Thu, 19 May 2016 21:05:30 +0200 Subject: [keycloak-dev] Possible bug in Tomcat8 adapter In-Reply-To: References: Message-ID: By default it returns the UUID for the user. So in Tomcat you are seeing the default behavior, while on WildFly you are seeing the behavior if principal-attribute is set to principal-attribute in keycloak.json. See http://keycloak.github.io/docs/userguide/keycloak-server/html/ch08.html#adapter-config On 19 May 2016 at 20:07, Marc Savy wrote: > Hi All, > > I've been setting up apiman's quickstart tomcat8 distro with Keycloak > (rather than using the inbuilt auth). > > I've managed to get everything working swimmingly, with one strange issue: > > HttpServletRequest#getRemoteUser() > > - On WildFly, this code[1] returns the preferred_username (e.g. > admin). Expected behaviour. > > - On Tomcat8 it return the subject[2] (e.g. > 5291684c-225a-4b3d-8795-15486feaf2ae) > > I think the problem might stem from where the principal is being built: > > > https://github.com/keycloak/keycloak/blob/master/adapters/spi/tomcat-adapter-spi/src/main/java/org/keycloak/adapters/tomcat/GenericPrincipalFactory.java#L39 > > Are we misusing #getRemoteUser, or is there an error in the adapter? > > Regards, > Marc > > [1] > https://github.com/apiman/apiman/blob/master/manager/ui/war/src/main/java/io/apiman/manager/ui/server/servlets/ConfigurationServlet.java#L105 > [2] 'id' in UI > _______________________________________________ > 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/20160519/4469c312/attachment-0001.html From sthorger at redhat.com Thu May 19 15:08:04 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Thu, 19 May 2016 21:08:04 +0200 Subject: [keycloak-dev] Implementing custom entities with KeyCloak In-Reply-To: <1463683481.4641.40.camel@cargosoft.ru> References: <1463654178.4641.21.camel@cargosoft.ru> <1463662099.4641.29.camel@cargosoft.ru> <1463683481.4641.40.camel@cargosoft.ru> Message-ID: On 19 May 2016 at 20:44, Mitya wrote: > Stian, > > A follow-up on realm resources - I've stumbled upon this thread: > http://lists.jboss.org/pipermail/keycloak-dev/2015-December/006100.html > > That "(coming) ability to freely extend the JPA entities and DB schema" is > the very same Entity SPI you were talking about, right? > Yep > > I see now how to implement realm resources. It's a pity that custom > admin resources (initially included into Pedro Igor's commit) were > removed; these would be a fairly natural addition to the upcoming > Entity SPI. Are there any plans to include that back? > We plan to add it, but we'd like it to have some support for authorization, which the PR didn't provide. So there was basically no difference between the two in the original PR. > > As a workaround, is it possible to install a custom realm resource > (/realms/{realm}/foo), manually protect it with an authorization > constraint, and use it inside admin console (as a surrogate admin > resource)? > Yes, that's fine. You can look at the source code for how we deal with authorization in the admin resources. Look at AdminRootResource I think it is. > > Cheers, > Mitya > > P.S. BTW, examples/providers/rest/pom.xml contains an erroneous > "Authenticator Example" inside > > > Hi Stian, thanks for response! > > > > > You don't strictly need to use model interface, JPA adapter, etc.. > > > You can just make it a entity directly. We have those layers > > > because > > > we support JPA and Mongo. > > > > thx, got it > > > > (interestingly, many IDM developers end up implementing a JDO-like > > engine; this has also happened to PicketLink, they supported both JPA > > and LDAP with a single API) > > > > > At the moment you can't add custom entities to the persistence.xml > > > without modifying it within the JAR, but we plan to introduce an > > > Entity SPI that allows adding custom entities (we have a PR for it, > > > it needs some work, but should be included in 2.0.0.CR1 due some > > > time > > > in June). > > > > Glad to hear about Entity SPI! I'll probably start with modified > > KeyCloak, and migrate to the SPI as soon as it's ready. > > > > > We have added support for custom REST resource, but not admin > > > resources. Main difference is how it's secured and URLs. > > > > Could you please elaborate on "custom REST resources"? I couldn't > > find > > anything in the docs, there is only "21. Admin REST API". What are > > custom REST resources, how to implement them? Could they be helpful > > in > > my use case? > > > > Cheers, > > Mitya > > > > > > You'd also need to modify the admin console, but that can be done > > > with a custom theme. > > > > > On 19 May 2016 at 12:36, Mitya wrote: > > > > Hi, > > > > > > > > My goal is to implement a custom first-class KeyCloak entity > > > > (like > > > > User, Group, etc.) Entities should persist in KeyCloak database > > > > along > > > > with Users, Groups etc.; there should be a CRUD interface in the > > > > admin > > > > console to manage them; it will have an unidirectional N:1 > > > > relationship > > > > to User and will participate in authentication process. In some > > > > future, > > > > most likely it will also participate in federation (to/from > > > > external > > > > LDAP server with custom schema). > > > > > > > > After briefly studying KeyCloak internals, I've got an impression > > > > that > > > > Provider SPIs won't help me much. Seems like what I'll have to > > > > implement is at least: > > > > > > > > - model interface (org.keycloak.models) > > > > - entity class (org.keycloak.models.entities) > > > > - JPA adapter (org.keycloak.models.jpa) > > > > - JPA entity (org.keycloak.models.jpa.entities) > > > > - (the same for Mongo and Infinispan) > > > > - REST representation (org.keycloak.representations.idm) > > > > - REST resource (org.keycloak.services.resources.admin) > > > > > > > > Next, there will be custom authenticator (to make use of the > > > > entity) > > > > and GUI modifications. I hope I didn't forget anything? > > > > > > > > Important question is - can I implement all of that without > > > > modifying > > > > KeyCloak code? Maintaining a fork and producing customized builds > > > > will > > > > complicate development process a lot. Ideally, classes should > > > > reside in > > > > my own packages (not org.keycloak.*), the code should be packaged > > > > as a > > > > module (JBoss module? OSGi bundle?) and simply be plugged into an > > > > official KeyCloak build. I see forking only as a last resort, > > > > it's > > > > something I'd like to avoid absolutely. > > > > > > > > Thanks! > > > > Mitya > > > > > > > > _______________________________________________ > > > > 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/20160519/961c4b3f/attachment.html From marc.savy at redhat.com Thu May 19 15:17:48 2016 From: marc.savy at redhat.com (Marc Savy) Date: Thu, 19 May 2016 20:17:48 +0100 Subject: [keycloak-dev] Possible bug in Tomcat8 adapter In-Reply-To: References: Message-ID: Uh oh, operator error :-). I'd actually been on that exact page and not joined those dots. Thanks! On 19 May 2016 at 20:05, Stian Thorgersen wrote: > By default it returns the UUID for the user. So in Tomcat you are seeing the > default behavior, while on WildFly you are seeing the behavior if > principal-attribute is set to principal-attribute in keycloak.json. See > http://keycloak.github.io/docs/userguide/keycloak-server/html/ch08.html#adapter-config > > > On 19 May 2016 at 20:07, Marc Savy wrote: >> >> Hi All, >> >> I've been setting up apiman's quickstart tomcat8 distro with Keycloak >> (rather than using the inbuilt auth). >> >> I've managed to get everything working swimmingly, with one strange issue: >> >> HttpServletRequest#getRemoteUser() >> >> - On WildFly, this code[1] returns the preferred_username (e.g. >> admin). Expected behaviour. >> >> - On Tomcat8 it return the subject[2] (e.g. >> 5291684c-225a-4b3d-8795-15486feaf2ae) >> >> I think the problem might stem from where the principal is being built: >> >> >> https://github.com/keycloak/keycloak/blob/master/adapters/spi/tomcat-adapter-spi/src/main/java/org/keycloak/adapters/tomcat/GenericPrincipalFactory.java#L39 >> >> Are we misusing #getRemoteUser, or is there an error in the adapter? >> >> Regards, >> Marc >> >> [1] >> https://github.com/apiman/apiman/blob/master/manager/ui/war/src/main/java/io/apiman/manager/ui/server/servlets/ConfigurationServlet.java#L105 >> [2] 'id' in UI >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev > > From mposolda at redhat.com Thu May 19 15:54:31 2016 From: mposolda at redhat.com (Marek Posolda) Date: Thu, 19 May 2016 21:54:31 +0200 Subject: [keycloak-dev] Support for LDAP referrals In-Reply-To: <1463542629.13752.20.camel@cargosoft.ru> References: <1463542629.13752.20.camel@cargosoft.ru> Message-ID: <573E19F7.2060304@redhat.com> LDAP referrals were not yet tested and supported, could you please create JIRA for this? Thanks, Marek On 18/05/16 05:37, Mitya wrote: > Hi, > > In replicated LDAP setups, it's a common situation where the slave is > read-only, and if a write operation is attempted, it returns a > so-called referral (see more here > ). Simply > put, a referral is an instruction to proceed with the same LDAP > operation but using different URL, contained within response. In a > replicated setup, this URL would point to master instance, which is > read-write. > > Currently, KeyCloak cannot use such a slave replica as a federation > provider in a WRITABLE edit mode. LDAP entries are imported > successfully; but further attempts to modify them in KeyCloak admin > console give success message, while the actual values are not > modified. If Sync Registrations is on, attempt to create a user > results in the following exception: > > javax.naming.PartialResultException: [LDAP: error code 10 - Referral]; remaining name 'uid=foo,ou=People,dc=foobar,dc=com' > at com.sun.jndi.ldap.LdapCtx.processReturnCode(LdapCtx.java:2971) > at com.sun.jndi.ldap.LdapCtx.processReturnCode(LdapCtx.java:2888) > at com.sun.jndi.ldap.LdapCtx.c_createSubcontext(LdapCtx.java:812) > at com.sun.jndi.toolkit.ctx.ComponentDirContext.p_createSubcontext(ComponentDirContext.java:341) > at com.sun.jndi.toolkit.ctx.PartialCompositeDirContext.createSubcontext(PartialCompositeDirContext.java:268) > at com.sun.jndi.toolkit.ctx.PartialCompositeDirContext.createSubcontext(PartialCompositeDirContext.java:256) > at javax.naming.directory.InitialDirContext.createSubcontext(InitialDirContext.java:197) > at javax.naming.directory.InitialDirContext.createSubcontext(InitialDirContext.java:197) > at org.keycloak.federation.ldap.idm.store.ldap.LDAPOperationManager$7.execute(LDAPOperationManager.java:434) > at org.keycloak.federation.ldap.idm.store.ldap.LDAPOperationManager$7.execute(LDAPOperationManager.java:431) > at org.keycloak.federation.ldap.idm.store.ldap.LDAPOperationManager.execute(LDAPOperationManager.java:536) > at org.keycloak.federation.ldap.idm.store.ldap.LDAPOperationManager.createSubContext(LDAPOperationManager.java:431) > LDAP referrals are fully supported by JNDI and LDAP stack; the only > thing we need is to set a Context.REFERRAL ("java.naming.referral") > environment property to "follow" before creating an > InitialLdapContext. I've noticed that in > org.keycloak.federation.ldap.LDAPConfig, there is an initial support > for additional connection properties (currently hardcoded to return > null). Are there any plans to implement this? > > Cheers, > 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/20160519/09abe4c4/attachment.html From mposolda at redhat.com Thu May 19 16:06:59 2016 From: mposolda at redhat.com (Marek Posolda) Date: Thu, 19 May 2016 22:06:59 +0200 Subject: [keycloak-dev] Authentication Provider chaining In-Reply-To: References: <573ADB1E.5090107@redhat.com> Message-ID: <573E1CE3.10106@redhat.com> For example you can create 2 subflows of the top flow and mark them as ALTERNATIVE. Then if you create "children" execution of subflow1 pointing to your authenticator inside it, then in the code of your authenticator you can switch the state to ATTEMPTED and if the authenticator execution is required, it will cancel subflow1 and go to subflow2. At least I hope it will work like this :-) If you want some more complex logic and dependency of authenticator on the state of other authenticator etc. you can maintain the state inside clientSession notes. Then authenticators will be executed in the fixed order, but for example in the code of authenticator2 you can do something like : if ("true".equals(clientSession.getNote("wasAuthenticator1FinishedSuccessfully")) { // skip this authenticator2 as authenticator1 already authenticated user or did something, which allows you to skip authenticator2 and move directly to authenticator3 etc. context.attempted(); return; } etc. Marek On 19/05/16 16:31, Rashmi Singh wrote: > Could someone please tell me if this is even possible? I do not want > the execution engines/authentication providers to be executed in a > fixed order defined in the admin console. But, need to be able to > switch to any in the chain depending on some response I get upon > invoking an external service. I needed to know if this is possible and > if yes, then how? Any help would be appreciated. > > On Wed, May 18, 2016 at 4:21 PM, Rashmi Singh > wrote: > > Thanks a lot for your response. I went through the chapter. What I > understand is we can create multiple executions (authentication > providers) but they are executed in a serial fashion in a fixed > order defined. Is there a way to be able to switch between them > (so, not have it executed in the default serial way but depending > on the response we get from an external service we called, we can > switch to the corresponding one). Any ideas? > > On Tue, May 17, 2016 at 3:49 AM, Marek Posolda > > wrote: > > The docs is here : > http://keycloak.github.io/docs/userguide/keycloak-server/html/auth_spi.html > > We have also example for authentication SPI. Note that you can > create sub-flows in the "top" flow, which might be a way to > split the authenticator into multiple ones. For example see > "Forms" flow in default "Browser" flow. Also maybe you will > need to implement some logic programatically in your > authenticators based on various conditions etc. Depends on the > usecase though... > > Marek > > > On 16/05/16 23:52, Rashmi Singh wrote: >> Hi, >> >> I am looking for a way to do authentication provider chaining >> with keycloak. Basically, I want to have multiple >> authentication providers, example username, Suregrid etc. On >> submitting username, we call a service and if that service >> tells us to use SureGrid, then we should be able to pass >> control to the corresponding authentication provider. So >> basically, I want to spilt one authentication provider into >> multiple and be able to chain them based on the response from >> the service called. I have not found any documentation that >> explains this. Could you suggest how to achieve this? >> >> >> >> >> >> _______________________________________________ >> 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/20160519/30aac30a/attachment-0001.html From singhrasster at gmail.com Thu May 19 17:12:27 2016 From: singhrasster at gmail.com (Rashmi Singh) Date: Thu, 19 May 2016 16:12:27 -0500 Subject: [keycloak-dev] Authentication Provider chaining In-Reply-To: <573E1CE3.10106@redhat.com> References: <573ADB1E.5090107@redhat.com> <573E1CE3.10106@redhat.com> Message-ID: I will try this out. Thanks for this. I have another question on this. To me, it looks like it will work in switching to authentication providers down in the chain (by letting us skip the ones in between), but what if we want to switch to an authentication provider up? For example, from authenticator1, we switch to authenticator4, and then we want to switch to authenticator2 (back up in the chain), can this be achieved? On Thu, May 19, 2016 at 3:06 PM, Marek Posolda wrote: > For example you can create 2 subflows of the top flow and mark them as > ALTERNATIVE. Then if you create "children" execution of subflow1 pointing > to your authenticator inside it, then in the code of your authenticator you > can switch the state to ATTEMPTED and if the authenticator execution is > required, it will cancel subflow1 and go to subflow2. At least I hope it > will work like this :-) > > If you want some more complex logic and dependency of authenticator on the > state of other authenticator etc. you can maintain the state inside > clientSession notes. Then authenticators will be executed in the fixed > order, but for example in the code of authenticator2 you can do something > like : > > if > ("true".equals(clientSession.getNote("wasAuthenticator1FinishedSuccessfully")) > { > // skip this authenticator2 as authenticator1 already authenticated > user or did something, which allows you to skip authenticator2 and move > directly to authenticator3 etc. > context.attempted(); > return; > } > > etc. > Marek > > > On 19/05/16 16:31, Rashmi Singh wrote: > > Could someone please tell me if this is even possible? I do not want the > execution engines/authentication providers to be executed in a fixed order > defined in the admin console. But, need to be able to switch to any in the > chain depending on some response I get upon invoking an external service. I > needed to know if this is possible and if yes, then how? Any help would be > appreciated. > > On Wed, May 18, 2016 at 4:21 PM, Rashmi Singh > wrote: > >> Thanks a lot for your response. I went through the chapter. What I >> understand is we can create multiple executions (authentication providers) >> but they are executed in a serial fashion in a fixed order defined. Is >> there a way to be able to switch between them (so, not have it executed in >> the default serial way but depending on the response we get from an >> external service we called, we can switch to the corresponding one). Any >> ideas? >> >> On Tue, May 17, 2016 at 3:49 AM, Marek Posolda < >> mposolda at redhat.com> wrote: >> >>> The docs is here : >>> http://keycloak.github.io/docs/userguide/keycloak-server/html/auth_spi.html >>> >>> We have also example for authentication SPI. Note that you can create >>> sub-flows in the "top" flow, which might be a way to split the >>> authenticator into multiple ones. For example see "Forms" flow in default >>> "Browser" flow. Also maybe you will need to implement some logic >>> programatically in your authenticators based on various conditions etc. >>> Depends on the usecase though... >>> >>> Marek >>> >>> >>> On 16/05/16 23:52, Rashmi Singh wrote: >>> >>> Hi, >>> >>> I am looking for a way to do authentication provider chaining with >>> keycloak. Basically, I want to have multiple authentication providers, >>> example username, Suregrid etc. On submitting username, we call a service >>> and if that service tells us to use SureGrid, then we should be able to >>> pass control to the corresponding authentication provider. So basically, I >>> want to spilt one authentication provider into multiple and be able to >>> chain them based on the response from the service called. I have not found >>> any documentation that explains this. Could you suggest how to achieve this? >>> >>> >>> >>> >>> >>> _______________________________________________ >>> 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/20160519/ccc90a9d/attachment.html From singhrasster at gmail.com Sat May 21 13:14:56 2016 From: singhrasster at gmail.com (Rashmi Singh) Date: Sat, 21 May 2016 12:14:56 -0500 Subject: [keycloak-dev] Authentication Provider chaining In-Reply-To: References: <573ADB1E.5090107@redhat.com> <573E1CE3.10106@redhat.com> Message-ID: I created two subflows under a flow "test", and added an execution for the authenticator under each subflow: Subflow1 (ALTERNATIVE) Authenticator1 (REQUIRED) Subflow2 (ALTERNATIVE) Authenticator2 (REQUIRED) In Authenticator1, I set context.attempted(); return; in authenticate() method Login seem to be cancelled/failed in authenticator1. However, it does not seem to enter the authenticator2: The logs I see on the console looks like: 11:56:33,261 INFO [org.keycloak.services] (default task-28) Authenticator - authenticator1 11:56:33,263 WARN [org.keycloak.events] (default task-28) type=LOGIN_ERROR, realmId=testrealm, clientId=account, userId=null, ipAddress=127 .0.0.1, error=invalid_user_credentials, auth_method=openid-connect, auth_type=code, response_type=code, redirect_uri=http://localhost:8080/a uth/realms/testrealm/account/login-redirect, code_id=bdbd40d3-33b0-42e7-a46b-f61e5fd7e303, response_mode=query Could you please point what I am doing wrong here that it does not enter the authenticator2 under subflow2? On Thu, May 19, 2016 at 4:12 PM, Rashmi Singh wrote: > I will try this out. Thanks for this. I have another question on this. To > me, it looks like it will work in switching to authentication providers > down in the chain (by letting us skip the ones in between), but what if we > want to switch to an authentication provider up? For example, from > authenticator1, we switch to authenticator4, and then we want to switch to > authenticator2 (back up in the chain), can this be achieved? > > On Thu, May 19, 2016 at 3:06 PM, Marek Posolda > wrote: > >> For example you can create 2 subflows of the top flow and mark them as >> ALTERNATIVE. Then if you create "children" execution of subflow1 pointing >> to your authenticator inside it, then in the code of your authenticator you >> can switch the state to ATTEMPTED and if the authenticator execution is >> required, it will cancel subflow1 and go to subflow2. At least I hope it >> will work like this :-) >> >> If you want some more complex logic and dependency of authenticator on >> the state of other authenticator etc. you can maintain the state inside >> clientSession notes. Then authenticators will be executed in the fixed >> order, but for example in the code of authenticator2 you can do something >> like : >> >> if >> ("true".equals(clientSession.getNote("wasAuthenticator1FinishedSuccessfully")) >> { >> // skip this authenticator2 as authenticator1 already authenticated >> user or did something, which allows you to skip authenticator2 and move >> directly to authenticator3 etc. >> context.attempted(); >> return; >> } >> >> etc. >> Marek >> >> >> On 19/05/16 16:31, Rashmi Singh wrote: >> >> Could someone please tell me if this is even possible? I do not want the >> execution engines/authentication providers to be executed in a fixed order >> defined in the admin console. But, need to be able to switch to any in the >> chain depending on some response I get upon invoking an external service. I >> needed to know if this is possible and if yes, then how? Any help would be >> appreciated. >> >> On Wed, May 18, 2016 at 4:21 PM, Rashmi Singh >> wrote: >> >>> Thanks a lot for your response. I went through the chapter. What I >>> understand is we can create multiple executions (authentication providers) >>> but they are executed in a serial fashion in a fixed order defined. Is >>> there a way to be able to switch between them (so, not have it executed in >>> the default serial way but depending on the response we get from an >>> external service we called, we can switch to the corresponding one). Any >>> ideas? >>> >>> On Tue, May 17, 2016 at 3:49 AM, Marek Posolda < >>> mposolda at redhat.com> wrote: >>> >>>> The docs is here : >>>> http://keycloak.github.io/docs/userguide/keycloak-server/html/auth_spi.html >>>> >>>> We have also example for authentication SPI. Note that you can create >>>> sub-flows in the "top" flow, which might be a way to split the >>>> authenticator into multiple ones. For example see "Forms" flow in default >>>> "Browser" flow. Also maybe you will need to implement some logic >>>> programatically in your authenticators based on various conditions etc. >>>> Depends on the usecase though... >>>> >>>> Marek >>>> >>>> >>>> On 16/05/16 23:52, Rashmi Singh wrote: >>>> >>>> Hi, >>>> >>>> I am looking for a way to do authentication provider chaining with >>>> keycloak. Basically, I want to have multiple authentication providers, >>>> example username, Suregrid etc. On submitting username, we call a service >>>> and if that service tells us to use SureGrid, then we should be able to >>>> pass control to the corresponding authentication provider. So basically, I >>>> want to spilt one authentication provider into multiple and be able to >>>> chain them based on the response from the service called. I have not found >>>> any documentation that explains this. Could you suggest how to achieve this? >>>> >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> 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/20160521/219ca0dc/attachment-0001.html From fabricio.milone at shinetech.com Sun May 22 21:28:56 2016 From: fabricio.milone at shinetech.com (Fabricio Milone) Date: Mon, 23 May 2016 11:28:56 +1000 Subject: [keycloak-dev] SingleFileExportProvider always tries to export users Message-ID: Hi devs, I've been working with some realm configurations and today I wanted to export all my work to a file so I tried to follow this: http://keycloak.github.io/docs/userguide/keycloak-server/html/export-import.html After some failed attempts due to my custom federator, I've decided to SKIP users from the export using the SKIP property as described in the documentation but it didn't work at all, so I've checked the code that is performing the export action and found that the usersExportStrategy is not being taken from the configuration but it is just set to TRUE instead. Look at the lines 65 and 83 in this file: https://github.com/keycloak/keycloak/blob/master/services/src/main/java/org/keycloak/exportimport/singlefile/SingleFileExportProvider.java For now, I've just modified the code locally to get the configuration correctly from the property I am passing at startup (like MultipleStepsExportProvider.java is doing), but I would like to contribute with a PR if necessary. Is there any reason to not do this? Thanks in advance. Regards, Fabricio -- *Fabricio Milone* Developer *Shine Consulting * 30/600 Bourke Street Melbourne VIC 3000 T: 03 8488 9939 M: 04 3200 4006 www.shinetech.com *a* passion for excellence -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160523/e4570ffb/attachment.html From sthorger at redhat.com Mon May 23 01:20:18 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Mon, 23 May 2016 07:20:18 +0200 Subject: [keycloak-dev] SingleFileExportProvider always tries to export users In-Reply-To: References: Message-ID: The usersExportStrategy as stated in the docs is only used by the dir provider, hence why it's hard-coded in the single file export provider. I can't see why it couldn't be supported though. Marek - is there any good reason why singlefileexport could support skipping users? On 23 May 2016 at 03:28, Fabricio Milone wrote: > Hi devs, > > I've been working with some realm configurations and today I wanted to > export all my work to a file so I tried to follow this: > > > http://keycloak.github.io/docs/userguide/keycloak-server/html/export-import.html > > After some failed attempts due to my custom federator, I've decided to > SKIP users from the export using the SKIP property as described in the > documentation but it didn't work at all, so I've checked the code that is > performing the export action and found that the usersExportStrategy is not > being taken from the configuration but it is just set to TRUE instead. > > Look at the lines 65 and 83 in this file: > > > https://github.com/keycloak/keycloak/blob/master/services/src/main/java/org/keycloak/exportimport/singlefile/SingleFileExportProvider.java > > For now, I've just modified the code locally to get the configuration > correctly from the property I am passing at startup (like > MultipleStepsExportProvider.java is doing), but I would like to contribute > with a PR if necessary. > > Is there any reason to not do this? > > Thanks in advance. > > Regards, > Fabricio > > -- > *Fabricio Milone* > Developer > > *Shine Consulting * > > 30/600 Bourke Street > > Melbourne VIC 3000 > > T: 03 8488 9939 > > M: 04 3200 4006 > > > www.shinetech.com *a* passion for excellence > > _______________________________________________ > 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/20160523/37a5452d/attachment.html From brooks.isoldi at traversed.com Mon May 23 14:30:12 2016 From: brooks.isoldi at traversed.com (Brooks Isoldi) Date: Mon, 23 May 2016 14:30:12 -0400 Subject: [keycloak-dev] Undeployed war Message-ID: <57434C34.2040107@traversed.com> Hi Keycloak team, We've had a couple of instances where we've found the keycloak war has been undeployed from wildfly and we're unable to find a war that we can redeploy. Can anyone point me to a war file that we can use to deploy in such instances? Thank you! -Brooks From bruno at abstractj.org Mon May 23 15:56:41 2016 From: bruno at abstractj.org (Bruno Oliveira) Date: Mon, 23 May 2016 16:56:41 -0300 Subject: [keycloak-dev] Undeployed war In-Reply-To: <57434C34.2040107@traversed.com> References: <57434C34.2040107@traversed.com> Message-ID: <20160523195641.GA25275@abstractj.org> I believe that Stian answered it in the past: http://lists.jboss.org/pipermail/keycloak-user/2015-October/003366.html On 2016-05-23, Brooks Isoldi wrote: > Hi Keycloak team, > > We've had a couple of instances where we've found the keycloak war has > been undeployed from wildfly and we're unable to find a war that we can > redeploy. > > Can anyone point me to a war file that we can use to deploy in such > instances? > > Thank you! > > > > > -Brooks > _______________________________________________ > 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 May 23 16:10:24 2016 From: bruno at abstractj.org (Bruno Oliveira) Date: Mon, 23 May 2016 17:10:24 -0300 Subject: [keycloak-dev] Documentation updates Message-ID: <20160523201024.GA27905@abstractj.org> Ahoy, I was looking at 3.4 section from our docs (https://keycloak.github.io/docs/userguide/keycloak-server/html/server-installation.html). I believe this section is no longer valid, right? If yes, I'm planning to remove it or should we replace with some alternative? -- abstractj PGP: 0x84DC9914 From sthorger at redhat.com Tue May 24 02:17:14 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Tue, 24 May 2016 08:17:14 +0200 Subject: [keycloak-dev] Documentation updates In-Reply-To: <20160523201024.GA27905@abstractj.org> References: <20160523201024.GA27905@abstractj.org> Message-ID: We're completely redoing the docs at the moment. Why do you say that section is not valid, at a quick glance it looks ok to me. On 23 May 2016 at 22:10, Bruno Oliveira wrote: > Ahoy, I was looking at 3.4 section from our docs ( > https://keycloak.github.io/docs/userguide/keycloak-server/html/server-installation.html). > I believe this section is no longer valid, right? > > If yes, I'm planning to remove it or should we replace with some > alternative? > > -- > > 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/20160524/5879049a/attachment-0001.html From bruno at abstractj.org Tue May 24 04:53:10 2016 From: bruno at abstractj.org (Bruno Oliveira) Date: Tue, 24 May 2016 05:53:10 -0300 Subject: [keycloak-dev] Documentation updates In-Reply-To: References: <20160523201024.GA27905@abstractj.org> Message-ID: <20160524085310.GA13751@abstractj.org> Because today we no longer distribute/deploy war files to get Keycloak up and running, but I can be wrong and totally missing the point here. Also, I couldn't find any reference at the docs to deploy that WAR, or generate it with -Pdistribution. On 2016-05-24, Stian Thorgersen wrote: > We're completely redoing the docs at the moment. > > Why do you say that section is not valid, at a quick glance it looks ok to > me. > > On 23 May 2016 at 22:10, Bruno Oliveira wrote: > > > Ahoy, I was looking at 3.4 section from our docs ( > > https://keycloak.github.io/docs/userguide/keycloak-server/html/server-installation.html). > > I believe this section is no longer valid, right? > > > > If yes, I'm planning to remove it or should we replace with some > > alternative? > > > > -- > > > > 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 sthorger at redhat.com Tue May 24 05:22:05 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Tue, 24 May 2016 11:22:05 +0200 Subject: [keycloak-dev] Documentation updates In-Reply-To: <20160524085310.GA13751@abstractj.org> References: <20160523201024.GA27905@abstractj.org> <20160524085310.GA13751@abstractj.org> Message-ID: It's a bit confusing, but Keycloak server is still technically a war under the covers, that's why setting it like that works. I wonder if we could just rename the war to drop the war extension and then it would just be "keycloak-server" and we could remove all the talk about war and name changes. On 24 May 2016 at 10:53, Bruno Oliveira wrote: > Because today we no longer distribute/deploy war files to get Keycloak up > and > running, but I can be wrong and totally missing the point here. Also, I > couldn't > find any reference at the docs to deploy that WAR, or generate it with > -Pdistribution. > > > On 2016-05-24, Stian Thorgersen wrote: > > We're completely redoing the docs at the moment. > > > > Why do you say that section is not valid, at a quick glance it looks ok > to > > me. > > > > On 23 May 2016 at 22:10, Bruno Oliveira wrote: > > > > > Ahoy, I was looking at 3.4 section from our docs ( > > > > https://keycloak.github.io/docs/userguide/keycloak-server/html/server-installation.html > ). > > > I believe this section is no longer valid, right? > > > > > > If yes, I'm planning to remove it or should we replace with some > > > alternative? > > > > > > -- > > > > > > 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/20160524/fd7b0523/attachment.html From bruno at abstractj.org Tue May 24 05:44:22 2016 From: bruno at abstractj.org (Bruno Oliveira) Date: Tue, 24 May 2016 06:44:22 -0300 Subject: [keycloak-dev] Documentation updates In-Reply-To: References: <20160523201024.GA27905@abstractj.org> <20160524085310.GA13751@abstractj.org> Message-ID: <20160524094422.GA21212@abstractj.org> +1 Jira created: https://issues.jboss.org/browse/KEYCLOAK-3030 On 2016-05-24, Stian Thorgersen wrote: > It's a bit confusing, but Keycloak server is still technically a war under > the covers, that's why setting it like that works. I wonder if we could > just rename the war to drop the war extension and then it would just be > "keycloak-server" and we could remove all the talk about war and name > changes. > > On 24 May 2016 at 10:53, Bruno Oliveira wrote: > > > Because today we no longer distribute/deploy war files to get Keycloak up > > and > > running, but I can be wrong and totally missing the point here. Also, I > > couldn't > > find any reference at the docs to deploy that WAR, or generate it with > > -Pdistribution. > > > > > > On 2016-05-24, Stian Thorgersen wrote: > > > We're completely redoing the docs at the moment. > > > > > > Why do you say that section is not valid, at a quick glance it looks ok > > to > > > me. > > > > > > On 23 May 2016 at 22:10, Bruno Oliveira wrote: > > > > > > > Ahoy, I was looking at 3.4 section from our docs ( > > > > > > https://keycloak.github.io/docs/userguide/keycloak-server/html/server-installation.html > > ). > > > > I believe this section is no longer valid, right? > > > > > > > > If yes, I'm planning to remove it or should we replace with some > > > > alternative? > > > > > > > > -- > > > > > > > > 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 From sthorger at redhat.com Tue May 24 05:49:33 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Tue, 24 May 2016 11:49:33 +0200 Subject: [keycloak-dev] Documentation updates In-Reply-To: <20160524094422.GA21212@abstractj.org> References: <20160523201024.GA27905@abstractj.org> <20160524085310.GA13751@abstractj.org> <20160524094422.GA21212@abstractj.org> Message-ID: Thanks On 24 May 2016 at 11:44, Bruno Oliveira wrote: > +1 Jira created: https://issues.jboss.org/browse/KEYCLOAK-3030 > > On 2016-05-24, Stian Thorgersen wrote: > > It's a bit confusing, but Keycloak server is still technically a war > under > > the covers, that's why setting it like that works. I wonder if we could > > just rename the war to drop the war extension and then it would just be > > "keycloak-server" and we could remove all the talk about war and name > > changes. > > > > On 24 May 2016 at 10:53, Bruno Oliveira wrote: > > > > > Because today we no longer distribute/deploy war files to get Keycloak > up > > > and > > > running, but I can be wrong and totally missing the point here. Also, I > > > couldn't > > > find any reference at the docs to deploy that WAR, or generate it with > > > -Pdistribution. > > > > > > > > > On 2016-05-24, Stian Thorgersen wrote: > > > > We're completely redoing the docs at the moment. > > > > > > > > Why do you say that section is not valid, at a quick glance it looks > ok > > > to > > > > me. > > > > > > > > On 23 May 2016 at 22:10, Bruno Oliveira wrote: > > > > > > > > > Ahoy, I was looking at 3.4 section from our docs ( > > > > > > > > > https://keycloak.github.io/docs/userguide/keycloak-server/html/server-installation.html > > > ). > > > > > I believe this section is no longer valid, right? > > > > > > > > > > If yes, I'm planning to remove it or should we replace with some > > > > > alternative? > > > > > > > > > > -- > > > > > > > > > > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160524/4fdb6d6e/attachment.html From mposolda at redhat.com Tue May 24 06:17:48 2016 From: mposolda at redhat.com (Marek Posolda) Date: Tue, 24 May 2016 12:17:48 +0200 Subject: [keycloak-dev] SingleFileExportProvider always tries to export users In-Reply-To: References: Message-ID: <57442A4C.2010101@redhat.com> The only reason is, that singleFile provided can have support just for some subset of usersExportStrategy options (REALM_FILE and SKIP). The others doesn't makes sense for singleFile provider as it always uses same file. Originally the singleFile export/import provider was intended to be used just for small environments with small number of users, where you just quickly export everything into single file and you are good. For environments with big number of users where more flexibility is needed, you would use either dir provider or zip provider (which was later removed because nobody was using it and it required additional 3rd party dependency). So the support for usersExportStrategy and also for "pagination" (limiting number of users in each transaction) was added just to those providers. Feel free to create JIRA for support usersExportStrategy and pagination for singleFile provider. Until we have it, you can use dir provider. Or is it something which blocks you from using dir provider? Marek On 23/05/16 07:20, Stian Thorgersen wrote: > The usersExportStrategy as stated in the docs is only used by the dir > provider, hence why it's hard-coded in the single file export > provider. I can't see why it couldn't be supported though. > > Marek - is there any good reason why singlefileexport could support > skipping users? > > On 23 May 2016 at 03:28, Fabricio Milone > > > wrote: > > Hi devs, > > I've been working with some realm configurations and today I > wanted to export all my work to a file so I tried to follow this: > > http://keycloak.github.io/docs/userguide/keycloak-server/html/export-import.html > > After some failed attempts due to my custom federator, I've > decided to SKIP users from the export using the SKIP property as > described in the documentation but it didn't work at all, so I've > checked the code that is performing the export action and found > that the usersExportStrategy is not being taken from the > configuration but it is just set to TRUE instead. > > Look at the lines 65 and 83 in this file: > > https://github.com/keycloak/keycloak/blob/master/services/src/main/java/org/keycloak/exportimport/singlefile/SingleFileExportProvider.java > > For now, I've just modified the code locally to get the > configuration correctly from the property I am passing at startup > (like MultipleStepsExportProvider.java is doing), but I would like > to contribute with a PR if necessary. > > Is there any reason to not do this? > > Thanks in advance. > > Regards, > Fabricio > > -- > *Fabricio Milone* > Developer > * > * > * > Shine Consulting * > > 30/600 Bourke Street > > Melbourne VIC 3000 > > T: 03 8488 9939 > > M: 04 3200 4006 > > > www.shinetech.com /*a*/ passion for > excellence > > > _______________________________________________ > 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/20160524/b45a9339/attachment-0001.html From thomas.darimont at googlemail.com Tue May 24 18:03:31 2016 From: thomas.darimont at googlemail.com (Thomas Darimont) Date: Wed, 25 May 2016 00:03:31 +0200 Subject: [keycloak-dev] OpenID Connect Certification Tests Message-ID: Hello list, sorry for the longer email... I just noticed that Keycloak is currently not listed as a certified OpenID Connect implementation under: http://openid.net/certification/ As it turns out one can run the tests oneself by creating a test profile as described here: http://openid.net/certification/testing/ The OpenID Connect test can be configured here: https://op.certification.openid.net:60000/ I just gave the test a spin by running a Keycloak Application instance (Version 1.9.1.Final - as I had that running) embedded in a Spring Boot App on Cloud Foundry which I exposed to the op.certification.openid.net test server. ... it works and was a quick way to get Keycloak exposed to the test - and yes I know this is of course not a prod environment ;-) The results looked not bad. Note that you need to execute each step manually by clicking on it... First run got me 23 green (+2 manually verified) out of 41 tests overall, rest was 9 yellow and 6 red. You can find a screenshot of the overall test results here: http://s33.postimg.org/h6zawnbbz/screencapture_op_certification_openid_net_60628.png I think those tests are a great way to close gaps between specification and implementation and help to make Keycloak more compatible. I also have the logs with the detailed request / response pairs with failed tests and explanations. Please ping me if you want to have those for investigation (~600 kb text). Some of the tests like ("Scope requesting all claims [Basic, Implicit, Hybrid] (OP-scope-All)") were yellow because the some claim information was missing in the user info like: ['nickname', 'profile', 'picture', 'website', 'gender', 'birthdate', 'zoneinfo', 'locale', 'updated_at', 'phone_number', 'phone_number_verified']. The red tests like "IDToken has kid [Basic, Implicit, Hybrid] (OP-IDToken-kid)" mostly failed due to missing values in the response e.g. "[verify-signed-idtoken-has-kid] status: ERROR description: Verifies that the header of a signed IDToken includes a kid claim. info: Signed ID Token has no kid: header={u'alg': u'RS256'}" If you want to try it out yourself here are the settings I used for the OpenID Connect Test Application: -------------------- Provider configuration: "Does the OP have a .well-known/openid-configuration endpoint?" yes "What is the issuer path for this configuration information?" https://tdlabs-keycloak-test2.cfapps.io/realms/test "Do the provider support dynamic client registration?" no (I know keycloak supports that but I couldn't get that working) "Redirect uris" https://op.certification.openid.net:60629/authz_cb "Client id" openid-cert "Client secret" 4692ca28-daad-4d76-aa82-0991e518d931 Required info "Which subject type do you want to use by default?" public "Which response type should be used by default?" code "Select supported features" JWT signed with algorithm other than "none" Encrypted JWT Test specific request parameters: "Login hint" tom at example.com "UI locales" en de "Claims locales" en de "Acr values" 2 1 "Webfinger url" https://example.com/tom "Webfinger email" tom at example.com E.g. bob at example.com For testing purposes I created a new realm "test" with an additional client "openid-cert" with "confidential" access type and the valid redirect url provided by the op.certification.openid.net test server. I also created a user "tester" for the login tests. Cheers, Thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160525/5ccfaa7f/attachment.html From fabricio.milone at shinetech.com Tue May 24 19:53:26 2016 From: fabricio.milone at shinetech.com (Fabricio Milone) Date: Wed, 25 May 2016 09:53:26 +1000 Subject: [keycloak-dev] SingleFileExportProvider always tries to export users In-Reply-To: <57442A4C.2010101@redhat.com> References: <57442A4C.2010101@redhat.com> Message-ID: Thanks Stian, Marek, I will create the Jira ticket because it will be nice to have it, but I'm not blocked by that in any way actually. Regards, Fab On 24 May 2016 at 20:17, Marek Posolda wrote: > The only reason is, that singleFile provided can have support just for > some subset of usersExportStrategy options (REALM_FILE and SKIP). The > others doesn't makes sense for singleFile provider as it always uses same > file. > > Originally the singleFile export/import provider was intended to be used > just for small environments with small number of users, where you just > quickly export everything into single file and you are good. > For environments with big number of users where more flexibility is > needed, you would use either dir provider or zip provider (which was later > removed because nobody was using it and it required additional 3rd party > dependency). So the support for usersExportStrategy and also for > "pagination" (limiting number of users in each transaction) was added just > to those providers. > > Feel free to create JIRA for support usersExportStrategy and pagination > for singleFile provider. > > Until we have it, you can use dir provider. Or is it something which > blocks you from using dir provider? > > Marek > > > On 23/05/16 07:20, Stian Thorgersen wrote: > > The usersExportStrategy as stated in the docs is only used by the dir > provider, hence why it's hard-coded in the single file export provider. I > can't see why it couldn't be supported though. > > Marek - is there any good reason why singlefileexport could support > skipping users? > > On 23 May 2016 at 03:28, Fabricio Milone > wrote: > >> Hi devs, >> >> I've been working with some realm configurations and today I wanted to >> export all my work to a file so I tried to follow this: >> >> >> http://keycloak.github.io/docs/userguide/keycloak-server/html/export-import.html >> >> After some failed attempts due to my custom federator, I've decided to >> SKIP users from the export using the SKIP property as described in the >> documentation but it didn't work at all, so I've checked the code that is >> performing the export action and found that the usersExportStrategy is not >> being taken from the configuration but it is just set to TRUE instead. >> >> Look at the lines 65 and 83 in this file: >> >> >> https://github.com/keycloak/keycloak/blob/master/services/src/main/java/org/keycloak/exportimport/singlefile/SingleFileExportProvider.java >> >> For now, I've just modified the code locally to get the configuration >> correctly from the property I am passing at startup (like >> MultipleStepsExportProvider.java is doing), but I would like to contribute >> with a PR if necessary. >> >> Is there any reason to not do this? >> >> Thanks in advance. >> >> Regards, >> Fabricio >> >> -- >> *Fabricio Milone* >> Developer >> >> * Shine Consulting * >> >> 30/600 Bourke Street >> >> Melbourne VIC 3000 >> >> T: 03 8488 9939 >> >> M: 04 3200 4006 >> >> >> www.shinetech.com *a* passion for excellence >> >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> > > > -- *Fabricio Milone* Developer *Shine Consulting * 30/600 Bourke Street Melbourne VIC 3000 T: 03 8488 9939 M: 04 3200 4006 www.shinetech.com *a* passion for excellence -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160525/839ade1a/attachment.html From sthorger at redhat.com Wed May 25 00:29:30 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Wed, 25 May 2016 06:29:30 +0200 Subject: [keycloak-dev] OpenID Connect Certification Tests In-Reply-To: References: Message-ID: Hi Thomas, That's great news, thanks for sharing. We've tried to execute these tests a while back, but there was issues with them at the time. Our plan is to revisit this in the next few months and to resolve issues where we're not following the spec. On 25 May 2016 at 00:03, Thomas Darimont wrote: > Hello list, > > sorry for the longer email... > > I just noticed that Keycloak is currently not listed as a > certified OpenID Connect implementation under: > http://openid.net/certification/ > > As it turns out one can run the tests oneself by creating a test profile > as described here: > http://openid.net/certification/testing/ > > The OpenID Connect test can be configured here: > https://op.certification.openid.net:60000/ > > I just gave the test a spin by running a Keycloak Application instance > (Version 1.9.1.Final - as I had that running) embedded in a Spring Boot > App > on Cloud Foundry which I exposed to the op.certification.openid.net test > server. > ... it works and was a quick way to get Keycloak exposed to the test - and > yes I know > this is of course not a prod environment ;-) > > The results looked not bad. > Note that you need to execute each step manually by clicking on it... > > First run got me 23 green (+2 manually verified) out of 41 tests overall, > rest was 9 yellow and 6 red. > > You can find a screenshot of the overall test results here: > > http://s33.postimg.org/h6zawnbbz/screencapture_op_certification_openid_net_60628.png > > I think those tests are a great way to close gaps between specification > and implementation > and help to make Keycloak more compatible. > > I also have the logs with the detailed request / response pairs with > failed tests and > explanations. > Please ping me if you want to have those for investigation (~600 kb text). > > Some of the tests like ("Scope requesting all claims [Basic, Implicit, > Hybrid] (OP-scope-All)") > were yellow because the some claim information was missing in the user > info like: > ['nickname', 'profile', 'picture', 'website', 'gender', 'birthdate', > 'zoneinfo', 'locale', 'updated_at', 'phone_number', > 'phone_number_verified']. > > The red tests like "IDToken has kid [Basic, Implicit, Hybrid] > (OP-IDToken-kid)" mostly failed due to > missing values in the response e.g. > "[verify-signed-idtoken-has-kid] > status: ERROR > description: Verifies that the header of a signed IDToken includes a kid > claim. > info: Signed ID Token has no kid: header={u'alg': u'RS256'}" > > If you want to try it out yourself here are the settings I used for the > OpenID Connect Test Application: > > -------------------- > > Provider configuration: > "Does the OP have a .well-known/openid-configuration endpoint?" > yes > > "What is the issuer path for this configuration information?" > https://tdlabs-keycloak-test2.cfapps.io/realms/test > > "Do the provider support dynamic client registration?" > no (I know keycloak supports that but I couldn't get that working) > > "Redirect uris" > https://op.certification.openid.net:60629/authz_cb > > "Client id" > openid-cert > > "Client secret" > 4692ca28-daad-4d76-aa82-0991e518d931 > > Required info > "Which subject type do you want to use by default?" > public > > "Which response type should be used by default?" > code > > "Select supported features" > JWT signed with algorithm other than "none" > Encrypted JWT > > Test specific request parameters: > > "Login hint" > tom at example.com > "UI locales" > en de > "Claims locales" > en de > "Acr values" > 2 1 > > "Webfinger url" > https://example.com/tom > > "Webfinger email" > tom at example.com > E.g. bob at example.com > > For testing purposes I created a new realm "test" with an additional > client "openid-cert" with "confidential" access type and > the valid redirect url provided by the op.certification.openid.net test > server. > > I also created a user "tester" for the login tests. > > 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/20160525/3172bde2/attachment-0001.html From jm85martins at gmail.com Wed May 25 06:33:42 2016 From: jm85martins at gmail.com (Jorge M.) Date: Wed, 25 May 2016 11:33:42 +0100 Subject: [keycloak-dev] Native mobile authentication Message-ID: Hi, I'm trying to figure out the currently best approach for mobile app authentication with keycloak. Is it possible to do this with native apps? IOS, Android + Windows phone? (Without webview). Is there any examples? If so, it has support social login? Thank you. JM -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160525/15b00b53/attachment.html From sthorger at redhat.com Wed May 25 08:11:26 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Wed, 25 May 2016 14:11:26 +0200 Subject: [keycloak-dev] Native mobile authentication In-Reply-To: References: Message-ID: Hi, Native applications should still use an external user-agent, that is best practice for OAuth and OpenID Connect, see [1] and [2]. Also take a look at AeroGear libraries [3]. That will support social login. [1] https://tools.ietf.org/html/draft-ietf-oauth-native-apps-01 [2] https://github.com/openid/AppAuth-Android / https://github.com/openid/AppAuth-iOS [3] https://aerogear.org/docs/guides/security/oauth2-guide/ On 25 May 2016 at 12:33, Jorge M. wrote: > Hi, > > I'm trying to figure out the currently best approach for mobile app > authentication with keycloak. > Is it possible to do this with native apps? IOS, Android + Windows phone? > (Without webview). Is there any examples? > If so, it has support social login? > > Thank you. > JM > > _______________________________________________ > 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/20160525/93ed1a9f/attachment.html From sthorger at redhat.com Thu May 26 15:13:55 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Thu, 26 May 2016 21:13:55 +0200 Subject: [keycloak-dev] Keycloak 1.9.5.Final Released Message-ID: Keycloak 1.9.5.Final has just been released. There's one change worth highlighting in this release. We've increased the default password hashing intervals to 20000. Yes, you read that right. We've actually recommended using 20000 for a while now, but the default was only 1. This is a clear trade-off between performance and how secure passwords are stored. With 1 password hashing interval it takes less than 1 ms to hash a password, while with 20000 it takes tens of ms. For the full list of resolved issues 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/20160526/03afc21d/attachment.html From bburke at redhat.com Thu May 26 16:59:12 2016 From: bburke at redhat.com (Bill Burke) Date: Thu, 26 May 2016 16:59:12 -0400 Subject: [keycloak-dev] Stackoverflow login Message-ID: <843a5e28-a2bd-17b8-9424-4e320b91aa38@redhat.com> I am unable to set up social login with Stackoverflow. Is it possible to use it with a localhost callback? Anybody know any special settings here? From sthorger at redhat.com Fri May 27 01:28:46 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Fri, 27 May 2016 07:28:46 +0200 Subject: [keycloak-dev] Stackoverflow login In-Reply-To: <843a5e28-a2bd-17b8-9424-4e320b91aa38@redhat.com> References: <843a5e28-a2bd-17b8-9424-4e320b91aa38@redhat.com> Message-ID: Worked fine here and I didn't set anything special. I didn't use any special settings and used "localhost" for OAuth Domain. What's the error you're getting? On 26 May 2016 at 22:59, Bill Burke wrote: > I am unable to set up social login with Stackoverflow. Is it possible > to use it with a localhost callback? Anybody know any special settings > here? > > _______________________________________________ > 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/20160527/850a4cde/attachment.html From bburke at redhat.com Fri May 27 08:12:31 2016 From: bburke at redhat.com (Bill Burke) Date: Fri, 27 May 2016 08:12:31 -0400 Subject: [keycloak-dev] Stackoverflow login In-Reply-To: References: <843a5e28-a2bd-17b8-9424-4e320b91aa38@redhat.com> Message-ID: <3d879002-eac7-9999-273a-9fdbaa575acc@redhat.com> Do you have to register some callback url? On 5/27/16 1:28 AM, Stian Thorgersen wrote: > Worked fine here and I didn't set anything special. I didn't use any > special settings and used "localhost" for OAuth Domain. What's the > error you're getting? > > On 26 May 2016 at 22:59, Bill Burke > wrote: > > I am unable to set up social login with Stackoverflow. Is it possible > to use it with a localhost callback? Anybody know any special > settings > here? > > _______________________________________________ > 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/20160527/36cfa8d8/attachment.html From bburke at redhat.com Fri May 27 08:15:00 2016 From: bburke at redhat.com (Bill Burke) Date: Fri, 27 May 2016 08:15:00 -0400 Subject: [keycloak-dev] Stackoverflow login In-Reply-To: References: <843a5e28-a2bd-17b8-9424-4e320b91aa38@redhat.com> Message-ID: Am I missing a step here? https://keycloak.gitbooks.io/server-adminstration-guide/content/topics/identity-broker/social/stack-overflow.html On 5/27/16 1:28 AM, Stian Thorgersen wrote: > Worked fine here and I didn't set anything special. I didn't use any > special settings and used "localhost" for OAuth Domain. What's the > error you're getting? > > On 26 May 2016 at 22:59, Bill Burke > wrote: > > I am unable to set up social login with Stackoverflow. Is it possible > to use it with a localhost callback? Anybody know any special > settings > here? > > _______________________________________________ > 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/20160527/dd0cdbd8/attachment-0001.html From brooks.isoldi at traversed.com Fri May 27 16:01:20 2016 From: brooks.isoldi at traversed.com (Brooks Isoldi) Date: Fri, 27 May 2016 16:01:20 -0400 Subject: [keycloak-dev] standalone-full in keycloak standalone Message-ID: <5748A790.6010006@traversed.com> Hi all, I noticed the Keycloak standalone server distribution does not contain a standalone-full.xml file, whereas the development bundle does. Is there a reason and how would I use standalone-full with the keycloak standalone distribution? Thanks. -Brooks From thomas.darimont at googlemail.com Sun May 29 16:52:06 2016 From: thomas.darimont at googlemail.com (Thomas Darimont) Date: Sun, 29 May 2016 22:52:06 +0200 Subject: [keycloak-dev] Proof of Concept for User Activity Dashboard Message-ID: Hello group, a few months ago I raised the feature request "Activity dashboard" in the Keycloak JIRA. https://issues.jboss.org/browse/KEYCLOAK-1840 This weekend I gave this a spin and I think I got pretty far with it, see attached annotated screenshot. The idea was to leverage the information from the stored event data to compute some Keycloak usage statistics over time. My current prototype supports JPA (user / event) storage provider and works with postgresql but could be adapted to other databases including MongoDB. Since I need to compute the usage statistics based on the event data, events need to be stored and some views (3) need to be defined to make the data accessible from JPA in a generic fashion. Since the queries are quite complex I wanted to keep them out of the code and therefore used named native queries via orm.xml. The actual queries use some database specific date/time functions that I wanted to keep out of the code - thus I created views that could be adapted for each database and provisioned via liquibase. The view definitions can be found here: https://gist.github.com/thomasdarimont/24e11be101c6ed8773f22e1defc5d66e For MongoDB one could define appropriate aggregation framework pipelines to express the same query logic. I basically exposed the data from those views per realm via a newly introduced AnalyticsProvider interface that is accessible via KeycloakSession. Data from this AnalyticsProvider is then exposed as a REST resource called "DashboardResource". Data from this REST endpoint is then consumed by the admin frontend in a new section called "dashboard". In the frontend I used basic patternfly components, e.g.: cards & tables: https://rawgit.com/patternfly/patternfly/master/tests/cards.html For the heatmap I used http://cal-heatmap.com/#start which is based on d3js. There is also an angularjs directive that could be used as well. https://github.com/shekhargulati/angular-cal-heatmap-directive The current hacky code can be found here.: https://github.com/thomasdarimont/keycloak/commits/poc/KEYCLOAK-1840-dashboard The relevant commit is: https://github.com/thomasdarimont/keycloak/commit/40a7956f8e547edc148d2ddbaf27961f2a852203 The code still needs a decent amount of polishing but I wanted to share this with you guys first to see if this could make it into Keycloak at some point. Cheers, Thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160529/714ce037/attachment-0001.html -------------- next part -------------- A non-text attachment was scrubbed... Name: Selection_064.png Type: image/png Size: 111013 bytes Desc: not available Url : http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160529/714ce037/attachment-0001.png From sthorger at redhat.com Mon May 30 01:29:15 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Mon, 30 May 2016 07:29:15 +0200 Subject: [keycloak-dev] Stackoverflow login In-Reply-To: <3d879002-eac7-9999-273a-9fdbaa575acc@redhat.com> References: <843a5e28-a2bd-17b8-9424-4e320b91aa38@redhat.com> <3d879002-eac7-9999-273a-9fdbaa575acc@redhat.com> Message-ID: Seems like they're just using the value from OAuth Domain, not specific URL. They're even allowing all subdomains as well. On 27 May 2016 at 14:12, Bill Burke wrote: > Do you have to register some callback url? > > On 5/27/16 1:28 AM, Stian Thorgersen wrote: > > Worked fine here and I didn't set anything special. I didn't use any > special settings and used "localhost" for OAuth Domain. What's the error > you're getting? > > On 26 May 2016 at 22:59, Bill Burke wrote: > >> I am unable to set up social login with Stackoverflow. Is it possible >> to use it with a localhost callback? Anybody know any special settings >> here? >> >> _______________________________________________ >> 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/20160530/df343a70/attachment.html From sthorger at redhat.com Mon May 30 01:30:04 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Mon, 30 May 2016 07:30:04 +0200 Subject: [keycloak-dev] Stackoverflow login In-Reply-To: References: <843a5e28-a2bd-17b8-9424-4e320b91aa38@redhat.com> Message-ID: Looks good, only comment would be that it may not be clear that 'dns domain name' is supposed to go into 'OAuth Domain'. On 27 May 2016 at 14:15, Bill Burke wrote: > Am I missing a step here? > > > > https://keycloak.gitbooks.io/server-adminstration-guide/content/topics/identity-broker/social/stack-overflow.html > > On 5/27/16 1:28 AM, Stian Thorgersen wrote: > > Worked fine here and I didn't set anything special. I didn't use any > special settings and used "localhost" for OAuth Domain. What's the error > you're getting? > > On 26 May 2016 at 22:59, Bill Burke wrote: > >> I am unable to set up social login with Stackoverflow. Is it possible >> to use it with a localhost callback? Anybody know any special settings >> here? >> >> _______________________________________________ >> 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/20160530/7fcfe6d2/attachment.html From sthorger at redhat.com Mon May 30 01:34:03 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Mon, 30 May 2016 07:34:03 +0200 Subject: [keycloak-dev] standalone-full in keycloak standalone In-Reply-To: <5748A790.6010006@traversed.com> References: <5748A790.6010006@traversed.com> Message-ID: The server distribution is a standalone Keycloak server bundle. It's not a JEE app server and hence doesn't need a full configuration (for example full contains messaging, which standard config doesn't). The development bundle is a WildFly JEE app server, with Keycloak server added. This is recommended mainly for development. On 27 May 2016 at 22:01, Brooks Isoldi wrote: > Hi all, > > I noticed the Keycloak standalone server distribution does not contain a > standalone-full.xml file, whereas the development bundle does. > > Is there a reason and how would I use standalone-full with the keycloak > standalone distribution? > > Thanks. > > > > -Brooks > _______________________________________________ > 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/20160530/15fbeac7/attachment.html From sthorger at redhat.com Mon May 30 01:47:44 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Mon, 30 May 2016 07:47:44 +0200 Subject: [keycloak-dev] Proof of Concept for User Activity Dashboard In-Reply-To: References: Message-ID: That's really cool and would be great to have this added to Keycloak. Some questions/comments: * What's the (+) under 7 total users? * What's the purpose of "Logins along the year" - it looks cool, but I'm not sure how it'd be used. It would also require storing events for the whole year. * I'm not keen on having db specific views. We already support quite a few dbs so maintaining these would be painful. Would be better to delegate this to Hibernate if possible and use ejq queries. * Logins/Registrations should display date and time. At least if date is not today. On 29 May 2016 at 22:52, Thomas Darimont wrote: > Hello group, > > a few months ago I raised the feature request "Activity dashboard" in the > Keycloak JIRA. > https://issues.jboss.org/browse/KEYCLOAK-1840 > > This weekend I gave this a spin and I think I got pretty far with it, > see attached annotated screenshot. > > The idea was to leverage the information from the stored event data > to compute some Keycloak usage statistics over time. > My current prototype supports JPA (user / event) storage provider > and works with postgresql but could be adapted to other databases > including MongoDB. > > Since I need to compute the usage statistics based on the event data, > events need to be stored and some views (3) need to be defined to > make the data accessible from JPA in a generic fashion. > > Since the queries are quite complex I wanted to keep them out > of the code and therefore used named native queries via orm.xml. > The actual queries use some database specific date/time functions > that I wanted to keep out of the code - thus I created views > that could be adapted for each database and provisioned via liquibase. > > The view definitions can be found here: > https://gist.github.com/thomasdarimont/24e11be101c6ed8773f22e1defc5d66e > > For MongoDB one could define appropriate aggregation framework pipelines > to express the same query logic. > > I basically exposed the data from those views per realm via a newly > introduced AnalyticsProvider interface that is accessible via > KeycloakSession. > > Data from this AnalyticsProvider is then exposed as a REST resource called > "DashboardResource". > Data from this REST endpoint is then consumed by the admin frontend in a > new section > called "dashboard". > > In the frontend I used basic patternfly components, e.g.: cards & tables: > https://rawgit.com/patternfly/patternfly/master/tests/cards.html > > For the heatmap I used http://cal-heatmap.com/#start which is based on > d3js. > There is also an angularjs directive that could be used as well. > https://github.com/shekhargulati/angular-cal-heatmap-directive > > The current hacky code can be found here.: > > https://github.com/thomasdarimont/keycloak/commits/poc/KEYCLOAK-1840-dashboard > > The relevant commit is: > > https://github.com/thomasdarimont/keycloak/commit/40a7956f8e547edc148d2ddbaf27961f2a852203 > > The code still needs a decent amount of polishing but I wanted to share > this with > you guys first to see if this could make it into Keycloak at some point. > > 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/20160530/d7790aab/attachment.html From thomas.darimont at googlemail.com Mon May 30 03:51:08 2016 From: thomas.darimont at googlemail.com (Thomas Darimont) Date: Mon, 30 May 2016 09:51:08 +0200 Subject: [keycloak-dev] Proof of Concept for User Activity Dashboard In-Reply-To: References: Message-ID: * What's the (+) under 7 total users? -> currently it's only a placeholder but the idea is to link to the "create new user" page * What's the purpose of "Logins along the year" - it looks cool, but I'm not sure how it'd be used. It would also require storing events for the whole year. -> This heatmap gives you an idea of the overall realm usage over the year at a glance - which allows to recognize patterns visually if the thresholds are calibrated accordingly. It could also be used to identify login problems e.g. after rolling out a new version - fewer logins than before could indicate problems for some users. * I'm not keen on having db specific views. We already support quite a few dbs so maintaining these would be painful. Would be better to delegate this to Hibernate if possible and use ejq queries. -> One could of course replace the fews with simple more simple and generic queries that could also be expressed via jpaql but this would require some processing within the keycloak server. At least for this prototype I wanted to keep the amount of code small. On the other hand view definitions for each database allow for optimal performance if you need to compute statistics / summaries after the fact from events. One could also compute the statistics eagerly e.g. update with each login (via custom EventListener). An alternative approach for computing summary / login statistics would be to use some kind of approximation mechanism. E.g. instead of computing the summary from the events one could also use a sketching data structure like a count min-sketch that is updated with each login (via custom EventListener) with an appropriately configured accuracy (e.g. 99%) that work with a fixed amount of memory. * Logins/Registrations should display date and time. At least if date is not today. -> Date is displayed if date is not the same day ;-) Some additional remarks: -> The lower line of the cards in the upper area are currently mocked. In the login card the "red 4 | 1" is meant to indicate 4 failed logins and 1 login that lead to a blocked account. The "red 1" below the registrations card should indicate 1 failed registration attempt (e.g. something wrong in the server side). I can also imagine an indicator for "aborted" registration attempts. -> The "latest logins" as well the "New registrations" should actually be right next to each other instead of below each other. -> The REST endpoint, currently called DashboardResource, could also be exposed in a more generic form like "AnalyticsResource" which could then offer various time series and summaries as JSON output for consumption by other tools like nagios. 2016-05-30 7:47 GMT+02:00 Stian Thorgersen : > That's really cool and would be great to have this added to Keycloak. > > Some questions/comments: > > * What's the (+) under 7 total users? > * What's the purpose of "Logins along the year" - it looks cool, but I'm > not sure how it'd be used. It would also require storing events for the > whole year. > * I'm not keen on having db specific views. We already support quite a few > dbs so maintaining these would be painful. Would be better to delegate this > to Hibernate if possible and use ejq queries. > * Logins/Registrations should display date and time. At least if date is > not today. > > On 29 May 2016 at 22:52, Thomas Darimont > wrote: > >> Hello group, >> >> a few months ago I raised the feature request "Activity dashboard" in the >> Keycloak JIRA. >> https://issues.jboss.org/browse/KEYCLOAK-1840 >> >> This weekend I gave this a spin and I think I got pretty far with it, >> see attached annotated screenshot. >> >> The idea was to leverage the information from the stored event data >> to compute some Keycloak usage statistics over time. >> My current prototype supports JPA (user / event) storage provider >> and works with postgresql but could be adapted to other databases >> including MongoDB. >> >> Since I need to compute the usage statistics based on the event data, >> events need to be stored and some views (3) need to be defined to >> make the data accessible from JPA in a generic fashion. >> >> Since the queries are quite complex I wanted to keep them out >> of the code and therefore used named native queries via orm.xml. >> The actual queries use some database specific date/time functions >> that I wanted to keep out of the code - thus I created views >> that could be adapted for each database and provisioned via liquibase. >> >> The view definitions can be found here: >> https://gist.github.com/thomasdarimont/24e11be101c6ed8773f22e1defc5d66e >> >> For MongoDB one could define appropriate aggregation framework pipelines >> to express the same query logic. >> >> I basically exposed the data from those views per realm via a newly >> introduced AnalyticsProvider interface that is accessible via >> KeycloakSession. >> >> Data from this AnalyticsProvider is then exposed as a REST resource >> called "DashboardResource". >> Data from this REST endpoint is then consumed by the admin frontend in a >> new section >> called "dashboard". >> >> In the frontend I used basic patternfly components, e.g.: cards & tables: >> https://rawgit.com/patternfly/patternfly/master/tests/cards.html >> >> For the heatmap I used http://cal-heatmap.com/#start which is based on >> d3js. >> There is also an angularjs directive that could be used as well. >> https://github.com/shekhargulati/angular-cal-heatmap-directive >> >> The current hacky code can be found here.: >> >> https://github.com/thomasdarimont/keycloak/commits/poc/KEYCLOAK-1840-dashboard >> >> The relevant commit is: >> >> https://github.com/thomasdarimont/keycloak/commit/40a7956f8e547edc148d2ddbaf27961f2a852203 >> >> The code still needs a decent amount of polishing but I wanted to share >> this with >> you guys first to see if this could make it into Keycloak at some point. >> >> 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/20160530/115ea322/attachment-0001.html From sthorger at redhat.com Mon May 30 04:56:05 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Mon, 30 May 2016 10:56:05 +0200 Subject: [keycloak-dev] Proof of Concept for User Activity Dashboard In-Reply-To: References: Message-ID: One worry here is that this is pretty much just a rip off from the Auth0 dashboard. That's not ideal IMO and we should have our own designed, maybe we should include UXP guys from Red Hat to do that. If we list the details that we want to display they can then design one for us. On 30 May 2016 at 09:51, Thomas Darimont wrote: > * What's the (+) under 7 total users? > > -> currently it's only a placeholder but the idea is to link to the > "create new user" page > That wasn't clear to me at least. Not sure we need a link to create user from the dashboard. > > * What's the purpose of "Logins along the year" - it looks cool, but I'm > not sure how it'd be used. > > It would also require storing events for the whole year. > > -> This heatmap gives you an idea of the overall realm usage over the year > at a glance - which allows > > to recognize patterns visually if the thresholds are calibrated > accordingly. > > It could also be used to identify login problems e.g. after rolling out a > new version - fewer logins than before > > could indicate problems for some users. > Wouldn't a simple graph do the same? In either case you could only display as much data as available in the database, so it would be good if only available months are displayed. > > * I'm not keen on having db specific views. We already support quite a few > dbs so maintaining these would be painful. > > Would be better to delegate this to Hibernate if possible and use ejq > queries. > > -> One could of course replace the fews with simple more simple and > generic queries that could also > > be expressed via jpaql but this would require some processing within the > keycloak server. > > At least for this prototype I wanted to keep the amount of code small. > > On the other hand view definitions for each database allow for optimal > performance if you > > need to compute statistics / summaries after the fact from events. > > One could also compute the statistics eagerly e.g. update with each login > (via custom EventListener). > > An alternative approach for computing summary / login statistics would be > to use some kind of approximation mechanism. > > E.g. instead of computing the summary from the events one could also use a > sketching data structure like a count min-sketch > > that is updated with each login (via custom EventListener) with an > appropriately configured accuracy (e.g. 99%) that work with > > a fixed amount of memory. > A simple implementation based on events is probably good enough at least initially. I appreciate the fact that it may be possible to tweak views for each database, but we don't have the resources to do that. We already support PostgreSQL, MySQL, MariaDB, Sybase, MSSQL, ..... For someone to write specific views for each database is time-consuming and it also needs to be maintained. Having to persist additional things on top of events is also not ideal. Sounds like an approximation or an alternative listener would have to do that. IMO performance of logins are much more important than the performance of the dashboard. > > * Logins/Registrations should display date and time. At least if date is > not today. > > -> Date is displayed if date is not the same day ;-) > > Some additional remarks: > > -> The lower line of the cards in the upper area are currently mocked. > > In the login card the "red 4 | 1" is meant to indicate 4 failed logins > and 1 login > > that lead to a blocked account. > > The "red 1" below the registrations card should indicate 1 failed > registration > > attempt (e.g. something wrong in the server side). I can also imagine an > indicator for "aborted" registration attempts. > That wasn't clear to me. Failed logins was clear, but not the blocked account. You could actually argue that blocked accounts should be red as they are "worse" than a single failed login. > > -> The "latest logins" as well the "New registrations" should actually be > right next to each other instead of below each other. > > -> The REST endpoint, currently called DashboardResource, could also be > exposed > > in a more generic form like "AnalyticsResource" which could then offer > > various time series and summaries as JSON output for consumption by > other tools like nagios. > > > > 2016-05-30 7:47 GMT+02:00 Stian Thorgersen : > >> That's really cool and would be great to have this added to Keycloak. >> >> Some questions/comments: >> >> * What's the (+) under 7 total users? >> * What's the purpose of "Logins along the year" - it looks cool, but I'm >> not sure how it'd be used. It would also require storing events for the >> whole year. >> * I'm not keen on having db specific views. We already support quite a >> few dbs so maintaining these would be painful. Would be better to delegate >> this to Hibernate if possible and use ejq queries. >> * Logins/Registrations should display date and time. At least if date is >> not today. >> >> On 29 May 2016 at 22:52, Thomas Darimont >> wrote: >> >>> Hello group, >>> >>> a few months ago I raised the feature request "Activity dashboard" in >>> the Keycloak JIRA. >>> https://issues.jboss.org/browse/KEYCLOAK-1840 >>> >>> This weekend I gave this a spin and I think I got pretty far with it, >>> see attached annotated screenshot. >>> >>> The idea was to leverage the information from the stored event data >>> to compute some Keycloak usage statistics over time. >>> My current prototype supports JPA (user / event) storage provider >>> and works with postgresql but could be adapted to other databases >>> including MongoDB. >>> >>> Since I need to compute the usage statistics based on the event data, >>> events need to be stored and some views (3) need to be defined to >>> make the data accessible from JPA in a generic fashion. >>> >>> Since the queries are quite complex I wanted to keep them out >>> of the code and therefore used named native queries via orm.xml. >>> The actual queries use some database specific date/time functions >>> that I wanted to keep out of the code - thus I created views >>> that could be adapted for each database and provisioned via liquibase. >>> >>> The view definitions can be found here: >>> https://gist.github.com/thomasdarimont/24e11be101c6ed8773f22e1defc5d66e >>> >>> For MongoDB one could define appropriate aggregation framework pipelines >>> to express the same query logic. >>> >>> I basically exposed the data from those views per realm via a newly >>> introduced AnalyticsProvider interface that is accessible via >>> KeycloakSession. >>> >>> Data from this AnalyticsProvider is then exposed as a REST resource >>> called "DashboardResource". >>> Data from this REST endpoint is then consumed by the admin frontend in a >>> new section >>> called "dashboard". >>> >>> In the frontend I used basic patternfly components, e.g.: cards & tables: >>> https://rawgit.com/patternfly/patternfly/master/tests/cards.html >>> >>> For the heatmap I used http://cal-heatmap.com/#start which is based on >>> d3js. >>> There is also an angularjs directive that could be used as well. >>> https://github.com/shekhargulati/angular-cal-heatmap-directive >>> >>> The current hacky code can be found here.: >>> >>> https://github.com/thomasdarimont/keycloak/commits/poc/KEYCLOAK-1840-dashboard >>> >>> The relevant commit is: >>> >>> https://github.com/thomasdarimont/keycloak/commit/40a7956f8e547edc148d2ddbaf27961f2a852203 >>> >>> The code still needs a decent amount of polishing but I wanted to share >>> this with >>> you guys first to see if this could make it into Keycloak at some point. >>> >>> 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/20160530/9e667858/attachment.html From thomas.darimont at googlemail.com Mon May 30 05:27:38 2016 From: thomas.darimont at googlemail.com (Thomas Darimont) Date: Mon, 30 May 2016 11:27:38 +0200 Subject: [keycloak-dev] Proof of Concept for User Activity Dashboard In-Reply-To: References: Message-ID: Answers inline... 2016-05-30 10:56 GMT+02:00 Stian Thorgersen : > One worry here is that this is pretty much just a rip off from the Auth0 > dashboard. That's not ideal IMO and we should have our own designed, maybe > we should include UXP guys from Red Hat to do that. If we list the details > that we want to display they can then design one for us. > Yes I took some inspirations from Auth0 and I fully agree - as said this was a just a PoC as a base for discussion ;-) I'm sure your UX guys are better at frontend stuff than I am :) > > On 30 May 2016 at 09:51, Thomas Darimont > wrote: > >> * What's the (+) under 7 total users? >> >> -> currently it's only a placeholder but the idea is to link to the >> "create new user" page >> > > That wasn't clear to me at least. Not sure we need a link to create user > from the dashboard. > That came with the patternfly "card" templated I used as a base and thought that might be useful (like a set of quick common operations). > > >> >> * What's the purpose of "Logins along the year" - it looks cool, but I'm >> not sure how it'd be used. >> >> It would also require storing events for the whole year. >> >> -> This heatmap gives you an idea of the overall realm usage over the >> year at a glance - which allows >> >> to recognize patterns visually if the thresholds are calibrated >> accordingly. >> >> It could also be used to identify login problems e.g. after rolling out a >> new version - fewer logins than before >> >> could indicate problems for some users. >> > > Wouldn't a simple graph do the same? In either case you could only display > as much data as available in the database, so it would be good if only > available months are displayed. > I think this is just a matter of specifying the "end" date for the cal-heatmap. Note that the cal-heatmap widget also supports browsing "past" login activity which might be quite handy at times. Having the calendar shown for the whole year leads to a more stable UI IMHO and would be there anyways once enough login data is accumulated. > > >> >> * I'm not keen on having db specific views. We already support quite a >> few dbs so maintaining these would be painful. >> >> Would be better to delegate this to Hibernate if possible and use ejq >> queries. >> >> -> One could of course replace the fews with simple more simple and >> generic queries that could also >> >> be expressed via jpaql but this would require some processing within the >> keycloak server. >> >> At least for this prototype I wanted to keep the amount of code small. >> >> On the other hand view definitions for each database allow for optimal >> performance if you >> >> need to compute statistics / summaries after the fact from events. >> >> One could also compute the statistics eagerly e.g. update with each login >> (via custom EventListener). >> >> An alternative approach for computing summary / login statistics would be >> to use some kind of approximation mechanism. >> >> E.g. instead of computing the summary from the events one could also use >> a sketching data structure like a count min-sketch >> >> that is updated with each login (via custom EventListener) with an >> appropriately configured accuracy (e.g. 99%) that work with >> >> a fixed amount of memory. >> > > A simple implementation based on events is probably good enough at least > initially. I appreciate the fact that it may be possible to tweak views for > each database, but we don't have the resources to do that. We already > support PostgreSQL, MySQL, MariaDB, Sybase, MSSQL, ..... For someone to > write specific views for each database is time-consuming and it also needs > to be maintained. > > Having to persist additional things on top of events is also not ideal. > Sounds like an approximation or an alternative listener would have to do > that. > > IMO performance of logins are much more important than the performance of > the dashboard. > As said if one would (asynchronously) process login events to update / store the statistics / summary directly you wouldn't need to store too much... also the login code path to remain fast. For the daily aggregated login information one could have a table like: date; realmId; totalLoginCount; totalLoginFailedCount; totalLoginBlockedCount; totalRegisterCount; totalAbortedRegistrationsCount.... which would be maintained asynchronously - this would only require 1 new table and an internal (asynchronous) event processor. An "analytic events processor" that emits "increment opertations" which are reduced to a sum would also scale to support scenarios with multiple cluster nodes. > > >> >> * Logins/Registrations should display date and time. At least if date is >> not today. >> >> -> Date is displayed if date is not the same day ;-) >> >> Some additional remarks: >> >> -> The lower line of the cards in the upper area are currently mocked. >> >> In the login card the "red 4 | 1" is meant to indicate 4 failed logins >> and 1 login >> >> that lead to a blocked account. >> >> The "red 1" below the registrations card should indicate 1 failed >> registration >> >> attempt (e.g. something wrong in the server side). I can also imagine an >> indicator for "aborted" registration attempts. >> > > That wasn't clear to me. Failed logins was clear, but not the blocked > account. You could actually argue that blocked accounts should be red as > they are "worse" than a single failed login. > You're right I think the same - didn't pay attention here ;-) > > >> >> -> The "latest logins" as well the "New registrations" should actually be >> right next to each other instead of below each other. >> >> -> The REST endpoint, currently called DashboardResource, could also be >> exposed >> >> in a more generic form like "AnalyticsResource" which could then offer >> >> various time series and summaries as JSON output for consumption by >> other tools like nagios. >> >> >> >> 2016-05-30 7:47 GMT+02:00 Stian Thorgersen : >> >>> That's really cool and would be great to have this added to Keycloak. >>> >>> Some questions/comments: >>> >>> * What's the (+) under 7 total users? >>> * What's the purpose of "Logins along the year" - it looks cool, but I'm >>> not sure how it'd be used. It would also require storing events for the >>> whole year. >>> * I'm not keen on having db specific views. We already support quite a >>> few dbs so maintaining these would be painful. Would be better to delegate >>> this to Hibernate if possible and use ejq queries. >>> * Logins/Registrations should display date and time. At least if date is >>> not today. >>> >>> On 29 May 2016 at 22:52, Thomas Darimont >> > wrote: >>> >>>> Hello group, >>>> >>>> a few months ago I raised the feature request "Activity dashboard" in >>>> the Keycloak JIRA. >>>> https://issues.jboss.org/browse/KEYCLOAK-1840 >>>> >>>> This weekend I gave this a spin and I think I got pretty far with it, >>>> see attached annotated screenshot. >>>> >>>> The idea was to leverage the information from the stored event data >>>> to compute some Keycloak usage statistics over time. >>>> My current prototype supports JPA (user / event) storage provider >>>> and works with postgresql but could be adapted to other databases >>>> including MongoDB. >>>> >>>> Since I need to compute the usage statistics based on the event data, >>>> events need to be stored and some views (3) need to be defined to >>>> make the data accessible from JPA in a generic fashion. >>>> >>>> Since the queries are quite complex I wanted to keep them out >>>> of the code and therefore used named native queries via orm.xml. >>>> The actual queries use some database specific date/time functions >>>> that I wanted to keep out of the code - thus I created views >>>> that could be adapted for each database and provisioned via liquibase. >>>> >>>> The view definitions can be found here: >>>> https://gist.github.com/thomasdarimont/24e11be101c6ed8773f22e1defc5d66e >>>> >>>> For MongoDB one could define appropriate aggregation framework pipelines >>>> to express the same query logic. >>>> >>>> I basically exposed the data from those views per realm via a newly >>>> introduced AnalyticsProvider interface that is accessible via >>>> KeycloakSession. >>>> >>>> Data from this AnalyticsProvider is then exposed as a REST resource >>>> called "DashboardResource". >>>> Data from this REST endpoint is then consumed by the admin frontend in >>>> a new section >>>> called "dashboard". >>>> >>>> In the frontend I used basic patternfly components, e.g.: cards & >>>> tables: >>>> https://rawgit.com/patternfly/patternfly/master/tests/cards.html >>>> >>>> For the heatmap I used http://cal-heatmap.com/#start which is based on >>>> d3js. >>>> There is also an angularjs directive that could be used as well. >>>> https://github.com/shekhargulati/angular-cal-heatmap-directive >>>> >>>> The current hacky code can be found here.: >>>> >>>> https://github.com/thomasdarimont/keycloak/commits/poc/KEYCLOAK-1840-dashboard >>>> >>>> The relevant commit is: >>>> >>>> https://github.com/thomasdarimont/keycloak/commit/40a7956f8e547edc148d2ddbaf27961f2a852203 >>>> >>>> The code still needs a decent amount of polishing but I wanted to share >>>> this with >>>> you guys first to see if this could make it into Keycloak at some point. >>>> >>>> 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/20160530/c7171421/attachment-0001.html From bburke at redhat.com Tue May 31 00:08:21 2016 From: bburke at redhat.com (Bill Burke) Date: Tue, 31 May 2016 00:08:21 -0400 Subject: [keycloak-dev] Stackoverflow login In-Reply-To: References: <843a5e28-a2bd-17b8-9424-4e320b91aa38@redhat.com> Message-ID: <6eaa95d3-290e-4ed8-a257-d23c8117f350@redhat.com> I couldn't get Stackoverflow on my laptop to work with localhost. Haven't gotten a chance to look into it further. So, if the docs are ok, then I'm not sure what I did wrong :) On 5/30/16 1:30 AM, Stian Thorgersen wrote: > Looks good, only comment would be that it may not be clear that 'dns > domain name' is supposed to go into 'OAuth Domain'. > > On 27 May 2016 at 14:15, Bill Burke > wrote: > > Am I missing a step here? > > > https://keycloak.gitbooks.io/server-adminstration-guide/content/topics/identity-broker/social/stack-overflow.html > > > On 5/27/16 1:28 AM, Stian Thorgersen wrote: >> Worked fine here and I didn't set anything special. I didn't use >> any special settings and used "localhost" for OAuth Domain. >> What's the error you're getting? >> >> On 26 May 2016 at 22:59, Bill Burke > > wrote: >> >> I am unable to set up social login with Stackoverflow. Is it >> possible >> to use it with a localhost callback? Anybody know any >> special settings >> here? >> >> _______________________________________________ >> 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/20160531/681c71ac/attachment.html From bburke at redhat.com Tue May 31 00:15:03 2016 From: bburke at redhat.com (Bill Burke) Date: Tue, 31 May 2016 00:15:03 -0400 Subject: [keycloak-dev] Proof of Concept for User Activity Dashboard In-Reply-To: References: Message-ID: I didn't read whole thread on this: Having a JPA event store would be bad performance? Isn't there more than one even per login? That means multiple DB inserts per login just to gather stats. Stats that would be looked at rarely (once a day? once a week? once a month?) Just something to think about. On 5/29/16 4:52 PM, Thomas Darimont wrote: > Hello group, > > a few months ago I raised the feature request "Activity dashboard" in > the Keycloak JIRA. > https://issues.jboss.org/browse/KEYCLOAK-1840 > > This weekend I gave this a spin and I think I got pretty far with it, > see attached annotated screenshot. > > The idea was to leverage the information from the stored event data > to compute some Keycloak usage statistics over time. > My current prototype supports JPA (user / event) storage provider > and works with postgresql but could be adapted to other databases > including MongoDB. > > Since I need to compute the usage statistics based on the event data, > events need to be stored and some views (3) need to be defined to > make the data accessible from JPA in a generic fashion. > > Since the queries are quite complex I wanted to keep them out > of the code and therefore used named native queries via orm.xml. > The actual queries use some database specific date/time functions > that I wanted to keep out of the code - thus I created views > that could be adapted for each database and provisioned via liquibase. > > The view definitions can be found here: > https://gist.github.com/thomasdarimont/24e11be101c6ed8773f22e1defc5d66e > > For MongoDB one could define appropriate aggregation framework pipelines > to express the same query logic. > > I basically exposed the data from those views per realm via a newly > introduced AnalyticsProvider interface that is accessible via > KeycloakSession. > > Data from this AnalyticsProvider is then exposed as a REST resource > called "DashboardResource". > Data from this REST endpoint is then consumed by the admin frontend in > a new section > called "dashboard". > > In the frontend I used basic patternfly components, e.g.: cards & tables: > https://rawgit.com/patternfly/patternfly/master/tests/cards.html > > For the heatmap I used http://cal-heatmap.com/#start which is based on > d3js. > There is also an angularjs directive that could be used as well. > https://github.com/shekhargulati/angular-cal-heatmap-directive > > The current hacky code can be found here.: > https://github.com/thomasdarimont/keycloak/commits/poc/KEYCLOAK-1840-dashboard > > The relevant commit is: > https://github.com/thomasdarimont/keycloak/commit/40a7956f8e547edc148d2ddbaf27961f2a852203 > > The code still needs a decent amount of polishing but I wanted to > share this with > you guys first to see if this could make it into Keycloak at some point. > > 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/20160531/c4735219/attachment.html From sthorger at redhat.com Tue May 31 11:55:22 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Tue, 31 May 2016 17:55:22 +0200 Subject: [keycloak-dev] standalone-full in keycloak standalone In-Reply-To: References: <5748A790.6010006@traversed.com> <574DA2B5.1050103@traversed.com> Message-ID: It's not supported to deploy JEE apps to the Keycloak server and we recommend having a separate WildFly instance for your apps. At the moment in theory it's possible, but we may remove and/or alter the config of the underlying WildFly which would break your apps in the future. You can also use the overlay and add it to an existing WildFly, but we only support one specific version of WildFly and again your applications may require config that conflicts with what Keycloak requires. On 31 May 2016 16:41, "Brooks Isoldi" wrote: Hi Stian, Thanks for that. Is it therefore not recommended to try to deploy a JEE application to the keycloak provided wildfly server? Or is it not recommended to deploy any applications to the keycloak provided wildfly server? If either is the case, than how would we configure the web.xml to authenticate via keycloak (e.g. the below): KEYCLOAK app-name I'm trying to deploy a JEE application (which requires standalone-full) to the keycloak provided wildfly server so that I don't need to have separate instances but if the development bundle is not recommended for production, what would be the recommended method of deploying a JEE application to the production-ready keycloak/wildfly server? Thanks again. -Brooks On 05/30/2016 01:34 AM, Stian Thorgersen wrote: The server distribution is a standalone Keycloak server bundle. It's not a JEE app server and hence doesn't need a full configuration (for example full contains messaging, which standard config doesn't). The development bundle is a WildFly JEE app server, with Keycloak server added. This is recommended mainly for development. On 27 May 2016 at 22:01, Brooks Isoldi wrote: > Hi all, > > I noticed the Keycloak standalone server distribution does not contain a > standalone-full.xml file, whereas the development bundle does. > > Is there a reason and how would I use standalone-full with the keycloak > standalone distribution? > > Thanks. > > > > -Brooks > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > -- Brooks Isoldi, Software Developer Traversed 7164 Columbia Gateway Drive, Suite 120A Columbia, MD 21046 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160531/b783d510/attachment.html From thomas.darimont at googlemail.com Tue May 31 13:42:26 2016 From: thomas.darimont at googlemail.com (Thomas Darimont) Date: Tue, 31 May 2016 19:42:26 +0200 Subject: [keycloak-dev] Proof of Concept for User Activity Dashboard In-Reply-To: References: Message-ID: Hello Bill, I didn't say that using JPA to store event data would lead to bad performance :-) it's just that querying and aggregating event data via JPA(QL) is a pain ... and I didn't want to potentially pull 100k+ events into memory to compute the stats in Java. I wanted to keep the processing in the Keycloak JVM as low as possible to not risk any OOME scenarios (though one could also use batch fetching here...). That's the reason why I used a view that uses database specific means to do so. With that said recording events with JPA is fine IMHO - though it could be done asynchronously in the background. My current approach for computing stats only relies on the already stored event_entity data, which of course needs to be persisted then - currently I don't need to store anything. But since the event_entity data can be deleted I'd proposed to periodically compute aggregates based on those when a day is over. It could then compute stuff like: * totalUserCount - how many users do we have in the realm? * totalLoginCount - how many users did login on that particular day? * totalLoginFailedCount - how many logins failed on that day? * totalLoginBlockedCount - how many failed logins lead to blocked accounts? * totalRegisterCount - how many users did register on that day? * totalAbortedRegistrationsCount - how many users abandonned the registration? - per realm per day. Similar stats could also be held by each keycloak instance in-memory and shared via infinispan. Those stats could then also periodically aggregated (every 5 mins) to give information near real-time. Regarding the rare usage of this info I'd argue that the dashboard should actually be the first page that an administrator sees when logging in to Keycloak (after initial setup of course) - I think it gives you a lot more than just a few stats - e.g. the possibility to login see patterns and identify potential problems this probably consulted multiple times a day by multiple people - especially if one uses a lot of different tenants. Cheers, Thomas 2016-05-31 6:15 GMT+02:00 Bill Burke : > I didn't read whole thread on this: Having a JPA event store would be bad > performance? Isn't there more than one even per login? That means > multiple DB inserts per login just to gather stats. Stats that would be > looked at rarely (once a day? once a week? once a month?) Just something > to think about. > > On 5/29/16 4:52 PM, Thomas Darimont wrote: > > Hello group, > > a few months ago I raised the feature request "Activity dashboard" in the > Keycloak JIRA. > https://issues.jboss.org/browse/KEYCLOAK-1840 > > This weekend I gave this a spin and I think I got pretty far with it, > see attached annotated screenshot. > > The idea was to leverage the information from the stored event data > to compute some Keycloak usage statistics over time. > My current prototype supports JPA (user / event) storage provider > and works with postgresql but could be adapted to other databases > including MongoDB. > > Since I need to compute the usage statistics based on the event data, > events need to be stored and some views (3) need to be defined to > make the data accessible from JPA in a generic fashion. > > Since the queries are quite complex I wanted to keep them out > of the code and therefore used named native queries via orm.xml. > The actual queries use some database specific date/time functions > that I wanted to keep out of the code - thus I created views > that could be adapted for each database and provisioned via liquibase. > > The view definitions can be found here: > https://gist.github.com/thomasdarimont/24e11be101c6ed8773f22e1defc5d66e > > For MongoDB one could define appropriate aggregation framework pipelines > to express the same query logic. > > I basically exposed the data from those views per realm via a newly > introduced AnalyticsProvider interface that is accessible via > KeycloakSession. > > Data from this AnalyticsProvider is then exposed as a REST resource called > "DashboardResource". > Data from this REST endpoint is then consumed by the admin frontend in a > new section > called "dashboard". > > In the frontend I used basic patternfly components, e.g.: cards & tables: > https://rawgit.com/patternfly/patternfly/master/tests/cards.html > > For the heatmap I used http://cal-heatmap.com/#start which is based on > d3js. > There is also an angularjs directive that could be used as well. > https://github.com/shekhargulati/angular-cal-heatmap-directive > > The current hacky code can be found here.: > > https://github.com/thomasdarimont/keycloak/commits/poc/KEYCLOAK-1840-dashboard > > The relevant commit is: > > https://github.com/thomasdarimont/keycloak/commit/40a7956f8e547edc148d2ddbaf27961f2a852203 > > The code still needs a decent amount of polishing but I wanted to share > this with > you guys first to see if this could make it into Keycloak at some point. > > Cheers, > Thomas > > > _______________________________________________ > 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/20160531/3eb235e9/attachment-0001.html From petervn1 at yahoo.com Tue May 31 20:41:32 2016 From: petervn1 at yahoo.com (Peter Nalyvayko) Date: Wed, 1 Jun 2016 00:41:32 +0000 (UTC) Subject: [keycloak-dev] Are there plans to implement PK Certificate user authentication? References: <546849148.2815900.1464741692784.JavaMail.yahoo.ref@mail.yahoo.com> Message-ID: <546849148.2815900.1464741692784.JavaMail.yahoo@mail.yahoo.com> Hello, We are considering using keycloak as an STS (Secure Token Service). One of the requirements is PK certificate user authentication. Right now it seems that user credentials (user name / password) is the only way to get user authenticated. Are there any plans adding PK certificate authentication into keycloak in a [very] near future?Regards,Peter -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160601/83aea56d/attachment.html