From sthorger at redhat.com Mon Jan 2 02:40:48 2017 From: sthorger at redhat.com (Stian Thorgersen) Date: Mon, 2 Jan 2017 08:40:48 +0100 Subject: [keycloak-dev] First use of initial passwords MUST be within configurable timeframe In-Reply-To: <7124405868aa41b4add75224528c80fc@DEL1EXMBXP2P.accounts.intern> References: <7124405868aa41b4add75224528c80fc@DEL1EXMBXP2P.accounts.intern> Message-ID: We have support to make the user change the temporary password on login. There is no built-in support to allow a user to use the temporary password for some configurable time. You could easily add a custom required action that would to that though. On 23 December 2016 at 07:42, Shaikh Asrafali Anwarali < asrafalianwarali.shaikh at gi-de.com> wrote: > Hi, > > Currently we are exploring keycloak for our IAMS requirement "First use of > initial or temporary passwords MUST be within configurable timeframe of > receipt". > > We explore through keycloak but did not find such functionality , could > you let us know is such functionality does exist or it can be configured. > > To elaborate more on requirement. > When user is created we assign Temporary password for activating account , > user uses temporary password to login into keyclaok and at first attempt > update for password is asked wherein user needs to changes his/her > credential. > This use of temporary password, we want to put constraint like it should > be used, say in a day or else account cannot be activated. > > Regards, > Asraf Shaikh > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > From sthorger at redhat.com Mon Jan 2 02:42:15 2017 From: sthorger at redhat.com (Stian Thorgersen) Date: Mon, 2 Jan 2017 08:42:15 +0100 Subject: [keycloak-dev] What code in Keycloak IDP is responsible to return the configuration to Java adapters? In-Reply-To: References: Message-ID: Our OIDC adapters only support Keycloak and hence do not need to invoke the well known endpoint to know the endpoints. The URLs are simply derived from the auth-server-url and realm name. On 23 December 2016 at 14:22, Michael Furman wrote: > Dear Keycloak people, > I need our help. > What code in Keycloak IDP is responsible to return the configuration to > Java adapters (Spring Security Adapter) ? > I mean all URLs in the org.keycloak.adapters.KeycloakDeployment class > (authServerBaseUrl, tokenUrl etc.). > I have modified org.keycloak.protocol.oidc.OIDCWellKnownProvider but this > code is not executed during OIDC protocol with java adapters. > Thanks in advance for your help, > Michael > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > From sthorger at redhat.com Mon Jan 2 02:43:26 2017 From: sthorger at redhat.com (Stian Thorgersen) Date: Mon, 2 Jan 2017 08:43:26 +0100 Subject: [keycloak-dev] The provider configuration In-Reply-To: References: Message-ID: Already answered on duplicated email. Please don't repeat your questions. On 26 December 2016 at 06:42, Michael Furman wrote: > Dear Bill, > I will happy for your reply. > I have found that the provider configuration of Java adapters (Spring > Security Adapter) implemented in org.keycloak.adapters. > KeycloakDeployment#resolveUrls > Just interesting why Keycloak Java adapter do not request the provider > configuration via /.well-known/openid-configuration ( > https://openid.net/specs/openid-connect-discovery-1_0- > 17.html#ProviderConfig)? > One more question: > We need to support Keycloak behind the Network Address Tranlation (NAT) > and therefore we need to modify org.keycloak.adapters.KeycloakDeployment#resolveUrls > and org.keycloak.protocol.oidc.OIDCWellKnownProvider#getConfig. > > What is the best way to contribute it to Keycloak? > > Thanks in advance for your help, > Michael > > > > ________________________________ > From: keycloak-dev-bounces at lists.jboss.org jboss.org> on behalf of Michael Furman > Sent: Friday, December 23, 2016 3:22 PM > To: keycloak-dev at lists.jboss.org > Subject: [keycloak-dev] What code in Keycloak IDP is responsible to return > the configuration to Java adapters? > > Dear Keycloak people, > I need our help. > What code in Keycloak IDP is responsible to return the configuration to > Java adapters (Spring Security Adapter) ? > I mean all URLs in the org.keycloak.adapters.KeycloakDeployment class > (authServerBaseUrl, tokenUrl etc.). > I have modified org.keycloak.protocol.oidc.OIDCWellKnownProvider but this > code is not executed during OIDC protocol with java adapters. > Thanks in advance for your help, > Michael > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > keycloak-dev Info Page - lists.jboss.org jboss.org/mailman/listinfo/keycloak-dev> > lists.jboss.org > To see the collection of prior postings to the list, visit the > keycloak-dev Archives. Using keycloak-dev: To post a message to all the > list members ... > > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > From michael_furman at hotmail.com Mon Jan 2 03:31:10 2017 From: michael_furman at hotmail.com (Michael Furman) Date: Mon, 2 Jan 2017 08:31:10 +0000 Subject: [keycloak-dev] The provider configuration In-Reply-To: References: , Message-ID: Hi Stian, Thank you for your reply! You answer just answer my second question. I will not repeat questions. Any case, now org.keycloak.protocol.oidc.OIDCWellKnownProvider#getConfig does not support deployments behind NAT. I have changed the class to support such deployments. Do you interesting in such contribution? Best regards, Michael ________________________________ From: Stian Thorgersen Sent: Monday, January 2, 2017 9:43 AM To: Michael Furman Cc: bill at burkecentral.com; keycloak-dev at lists.jboss.org Subject: Re: [keycloak-dev] The provider configuration Already answered on duplicated email. Please don't repeat your questions. On 26 December 2016 at 06:42, Michael Furman > wrote: Dear Bill, I will happy for your reply. I have found that the provider configuration of Java adapters (Spring Security Adapter) implemented in org.keycloak.adapters.KeycloakDeployment#resolveUrls Just interesting why Keycloak Java adapter do not request the provider configuration via /.well-known/openid-configuration (https://openid.net/specs/openid-connect-discovery-1_0-17.html#ProviderConfig)? One more question: We need to support Keycloak behind the Network Address Tranlation (NAT) and therefore we need to modify org.keycloak.adapters.KeycloakDeployment#resolveUrls and org.keycloak.protocol.oidc.OIDCWellKnownProvider#getConfig. What is the best way to contribute it to Keycloak? Thanks in advance for your help, Michael ________________________________ From: keycloak-dev-bounces at lists.jboss.org > on behalf of Michael Furman > Sent: Friday, December 23, 2016 3:22 PM To: keycloak-dev at lists.jboss.org Subject: [keycloak-dev] What code in Keycloak IDP is responsible to return the configuration to Java adapters? Dear Keycloak people, I need our help. What code in Keycloak IDP is responsible to return the configuration to Java adapters (Spring Security Adapter) ? I mean all URLs in the org.keycloak.adapters.KeycloakDeployment class (authServerBaseUrl, tokenUrl etc.). I have modified org.keycloak.protocol.oidc.OIDCWellKnownProvider but this code is not executed during OIDC protocol with java adapters. Thanks in advance for your help, Michael _______________________________________________ keycloak-dev mailing list keycloak-dev at lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-dev keycloak-dev Info Page - lists.jboss.org lists.jboss.org To see the collection of prior postings to the list, visit the keycloak-dev Archives. Using keycloak-dev: To post a message to all the list members ... _______________________________________________ keycloak-dev mailing list keycloak-dev at lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-dev From sthorger at redhat.com Mon Jan 2 03:35:34 2017 From: sthorger at redhat.com (Stian Thorgersen) Date: Mon, 2 Jan 2017 09:35:34 +0100 Subject: [keycloak-dev] The provider configuration In-Reply-To: References: Message-ID: Not sure how the endpoints advertised in OIDC well known endpoint has anything to do with NAT. On 2 January 2017 at 09:31, Michael Furman wrote: > Hi Stian, > > Thank you for your reply! > > > You answer just answer my second question. I will not repeat questions. > > > Any case, now org.keycloak.protocol.oidc.OIDCWellKnownProvider#getConfig > does not support deployments behind NAT. > > I have changed the class to support such deployments. > > Do you interesting in such contribution? > > Best regards, > > Michael > > > ------------------------------ > *From:* Stian Thorgersen > *Sent:* Monday, January 2, 2017 9:43 AM > *To:* Michael Furman > *Cc:* bill at burkecentral.com; keycloak-dev at lists.jboss.org > *Subject:* Re: [keycloak-dev] The provider configuration > > Already answered on duplicated email. Please don't repeat your questions. > > On 26 December 2016 at 06:42, Michael Furman > wrote: > >> Dear Bill, >> I will happy for your reply. >> I have found that the provider configuration of Java adapters (Spring >> Security Adapter) implemented in org.keycloak.adapters.Keycloak >> Deployment#resolveUrls >> Just interesting why Keycloak Java adapter do not request the provider >> configuration via /.well-known/openid-configuration ( >> https://openid.net/specs/openid-connect-discovery-1_0-17. >> html#ProviderConfig)? >> One more question: >> We need to support Keycloak behind the Network Address Tranlation (NAT) >> and therefore we need to modify org.keycloak.adapters.KeycloakDeployment#resolveUrls >> and org.keycloak.protocol.oidc.OIDCWellKnownProvider#getConfig. >> >> What is the best way to contribute it to Keycloak? >> >> Thanks in advance for your help, >> Michael >> >> >> >> ________________________________ >> From: keycloak-dev-bounces at lists.jboss.org > oss.org> on behalf of Michael Furman >> Sent: Friday, December 23, 2016 3:22 PM >> To: keycloak-dev at lists.jboss.org >> Subject: [keycloak-dev] What code in Keycloak IDP is responsible to >> return the configuration to Java adapters? >> >> Dear Keycloak people, >> I need our help. >> What code in Keycloak IDP is responsible to return the configuration to >> Java adapters (Spring Security Adapter) ? >> I mean all URLs in the org.keycloak.adapters.KeycloakDeployment class >> (authServerBaseUrl, tokenUrl etc.). >> I have modified org.keycloak.protocol.oidc.OIDCWellKnownProvider but >> this code is not executed during OIDC protocol with java adapters. >> Thanks in advance for your help, >> Michael >> >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> keycloak-dev >> Info >> Page - lists.jboss.org> cloak-dev> >> lists.jboss.org >> To see the collection of prior postings to the list, visit the >> keycloak-dev Archives. Using keycloak-dev: To post a message to all the >> list members ... >> >> >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> > > From jdennis at redhat.com Tue Jan 3 09:10:10 2017 From: jdennis at redhat.com (John Dennis) Date: Tue, 3 Jan 2017 09:10:10 -0500 Subject: [keycloak-dev] Getting error with authentication using ecp.sh script In-Reply-To: References: Message-ID: <41eb63bb-9c52-cb76-c951-8911e31d9795@redhat.com> On 12/27/2016 08:52 AM, Rashmi Singh wrote: > Hi All, Just a reminder if some insights/help could be provided on my SAML > request and the issue I am facing. What Rashmi failed to mention is that after submitting the SAML AuthnRequest to Keycloak the response was a server 500 error. I asked him to look for any backtraces that appeared in the Keycloak log after receiving the AuthnRequest which he did and included here. To the best of my knowledge the AuthnRequest is well formed but even if it wasn't the response should have been a SAML Response with an error, not a HTTP 500 status code. What we need to figure out is why Keycloak is throwing an uncaught exception resulting in the HTTP 500 status code. ECP requires either basic or digest authentication on the endpoint processing the AuthnRequest. My suspicion based on the "Failed authentication" message at the beginning of the backtrace is either the authentication did not occur on the endpoint or there was a failure to record the authentication occurred and was successful, just a guess. > > On Fri, Dec 23, 2016 at 9:01 PM, Rashmi Singh > wrote: > >> Hi All, >> >> I am using ecp.sh (provided by keycloak team, ofcourse with changes on >> idp_endpoint based on my keycloak environment) to perform authentication. Just to clarify, ecp.sh was not provided by the keycloak team. I provided it to Rashmi. It's a script I've used in the past to test ECP. >> I am using spring saml SP and keycloak IDP. I enabled ecp on the SP side >> and then I execute ecp.sh script as: >> >> ./ecp.sh -d rhsso http://192.168.99.100:8888/saml-sp/first.jsp newuser4 >> >> >> My idp_endpoint is: "http://192.168.99.100:9990/auth/realms/xxxxxxxxxx/ >> protocol/saml" >> where xxxxxxxxxx is my realm (replaced my realm with xxxxxxxxxx for this >> email) >> >> The script prompts me to enter password and then it sends an auth request >> to keycloak IDP. >> >> Now, something goes wrong at the IDP. >> I enabled saml logs on keycloak to see the incoming request and the >> following error from the logs: >> >> 00:51:40,656 DEBUG [org.keycloak.saml.SAMLRequestParser] (default task-2) >> SAML POST Binding >> 00:51:40,656 DEBUG [org.keycloak.saml.SAMLRequestParser] (default task-2) >> > AssertionConsumerServiceURL="http://192.168.99.100:8888/saml-sp/saml/SSO" >> ForceAuthn="false" ID="a31ah57718g27gd149da6jeb08620ig" IsPassive="false" >> IssueInstant="2016-12-24T00:51:34.799Z" ProtocolBinding="urn:oasis: >> names:tc:SAML:2.0:bindings:PAOS" Version="2.0"> >> http:// >> 192.168.99.100:8888/saml-sp/saml/metadata >> >> >> >> >> >> >> >> >> >> >> nfLQ9IFs9IFnSgw3HHHKuPkAbRY= >> >> >> iULSwpjBb38Vmtan4ZIocRx4PNr6fHRuhVbL+ >> 7yXNz3wqjlSavtk7haUiADwUS2cTofRM5KDzUvIkaQPXBZqEkz2xnrhpNj71 >> eIqJ6H4ZqW3mpvP8Bk9z3VEmcEQhZSd6j8rMf4JOdIBRtE7cea0wJhuQ1Uds >> HdcKeIdp+wuRvn8t9vS/mPKd9GAt11JpC+bgMQS0MDy+r1+AZof2+ >> XMyMuwECVIkouTzwlgKDEmgvQh6Aq61f+QzIeeZ9+3efwJyIH61x7J4CaiSTpesezlXx8UQ >> nqIL+AToL1OFHSp2bgXXxkP1rHSkyNM34Eg92LmI5cN3oBfQDR8r+mCoEctWA==> ds:SignatureValue> >> >> >> MIIDUjCCAjqgAwIBAgIEUOLIQTANBg >> kqhkiG9w0BAQUFADBrMQswCQYDVQQGEwJGSTEQMA4GA1UECBMHVXVzaW1hYT >> ERMA8GA1UEBxMISGVsc2lua2kxGDAWBgNVBAoTD1JNNSBTb2Z0d2FyZSBPeT >> EMMAoGA1UECwwDUiZEMQ8wDQYDVQQDEwZhcG9sbG8wHhcNMTMwMTAxMTEyOD >> AxWhcNMjIxMjMwMTEyODAxWjBrMQswCQYDVQQGEwJGSTEQMA4GA1UECBMHVX >> VzaW1hYTERMA8GA1UEBxMISGVsc2lua2kxGDAWBgNVBAoTD1JNNSBTb2Z0d2 >> FyZSBPeTEMMAoGA1UECwwDUiZEMQ8wDQYDVQQDEwZhcG9sbG8wggEiMA0GCS >> qGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCXqP0wqL2Ai1haeTj0alwsLafhrD >> tUt00E5xc7kdD7PISRA270ZmpYMB4W24Uk2QkuwaBp6dI/ >> yRdUvPfOT45YZrqIxMe2451PAQWtEKWF5Z13F0J4/lB71TtrzyH94RnqSHXFfvRN8EY/ >> rzuEzrpZrHdtNs9LRyLqcRTXMMO4z7QghBuxh3K5gu7KqxpHx6No83WNZj4B >> 3gvWLRWv05nbXh/F9YMeQClTX1iBNAhLQxWhwXMKB4u1iPQ/ >> KSaal3R26pONUUmu1qVtU1quQozSTPD8HvsDqGG19v2+/N3uf5dRYtvEPfwXN3wIY+/ >> R93vBA6lnl5nTctZIRsyg0Gv5AgMBAAEwDQYJKoZIhvcNAQEFBQADggEBAFQ >> wAAYUjso1VwjDc2kypK/RRcB8bMAUUIG0hLGL82IvnKouGixGq >> AcULwQKIvTs6uGmlgbSG6Gn5ROb2mlBztXqQ49zRvi5qWNRttir6eyqwRFGO >> M6A8rxj3Jhxi2Vb/MJn7XzeVHHLzA1sV5hwl/2PLnaL2h9WyG9QwBbwtmkMEqUt/ >> dgixKb1Rvby/tBuRogWgPONNSACiW+Z5o8UdAOqNMZQozD/ >> i1gOjBXoF0F5OksjQN7xoQZLj9xXefxCFQ69FPcFDeEWbHwSoBy5hLPNALaE >> Uoa5zPDwlixwRjFQTc5XXaRpgIjy/2gsL8+Y5QRhyXnLqgO67BlLYW/ >> GuHE= >> >> >> >> >> >> 00:51:41,265 DEBUG [org.keycloak.saml.common] (default task-2) The >> provider ApacheXMLDSig - 2.05 was added at position: 2 >> 00:51:41,545 WARN [org.keycloak.services] (default task-2) >> KC-SERVICES0013: Failed authentication: org.keycloak.authentication. >> AuthenticationFlowException >> at org.keycloak.authentication.DefaultAuthenticationFlow. >> processResult(DefaultAuthenticationFlow.java:242) >> at org.keycloak.authentication.DefaultAuthenticationFlow. >> processFlow(DefaultAuthenticationFlow.java:185) >> at org.keycloak.authentication.AuthenticationProcessor. >> authenticateOnly(AuthenticationProcessor.java:792) >> at org.keycloak.protocol.AuthorizationEndpointBase. >> handleBrowserAuthenticationRequest(AuthorizationEndpointBase.java:100) >> at org.keycloak.protocol.saml.SamlService. >> newBrowserAuthentication(SamlService.java:505) >> at org.keycloak.protocol.saml.profile.ecp.SamlEcpProfileService. >> newBrowserAuthentication(SamlEcpProfileService.java:89) >> at org.keycloak.protocol.saml.SamlService. >> newBrowserAuthentication(SamlService.java:501) >> at org.keycloak.protocol.saml.SamlService$BindingProtocol. >> loginRequest(SamlService.java:297) >> at org.keycloak.protocol.saml.profile.ecp.SamlEcpProfileService$1. >> loginRequest(SamlEcpProfileService.java:72) >> at org.keycloak.protocol.saml.SamlService$BindingProtocol. >> handleSamlRequest(SamlService.java:209) >> at org.keycloak.protocol.saml.SamlService$ >> PostBindingProtocol.execute(SamlService.java:453) >> at org.keycloak.protocol.saml.profile.ecp.SamlEcpProfileService. >> authenticate(SamlEcpProfileService.java:74) >> at org.keycloak.protocol.saml.SamlService.soapBinding( >> SamlService.java:619) >> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) >> at sun.reflect.NativeMethodAccessorImpl.invoke( >> NativeMethodAccessorImpl.java:62) >> at sun.reflect.DelegatingMethodAccessorImpl.invoke( >> DelegatingMethodAccessorImpl.java:43) >> at java.lang.reflect.Method.invoke(Method.java:498) >> at org.jboss.resteasy.core.MethodInjectorImpl.invoke( >> MethodInjectorImpl.java:139) >> at org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTarget( >> ResourceMethodInvoker.java:295) >> at org.jboss.resteasy.core.ResourceMethodInvoker.invoke( >> ResourceMethodInvoker.java:249) >> at org.jboss.resteasy.core.ResourceLocatorInvoker. >> invokeOnTargetObject(ResourceLocatorInvoker.java:138) >> at org.jboss.resteasy.core.ResourceLocatorInvoker.invoke( >> ResourceLocatorInvoker.java:101) >> at org.jboss.resteasy.core.SynchronousDispatcher.invoke( >> SynchronousDispatcher.java:395) >> at org.jboss.resteasy.core.SynchronousDispatcher.invoke( >> SynchronousDispatcher.java:202) >> at org.jboss.resteasy.plugins.server.servlet. >> ServletContainerDispatcher.service(ServletContainerDispatcher.java:221) >> at org.jboss.resteasy.plugins.server.servlet. >> HttpServletDispatcher.service(HttpServletDispatcher.java:56) >> at org.jboss.resteasy.plugins.server.servlet. >> HttpServletDispatcher.service(HttpServletDispatcher.java:51) >> at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) >> at io.undertow.servlet.handlers.ServletHandler.handleRequest( >> ServletHandler.java:85) >> at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl. >> doFilter(FilterHandler.java:129) >> at org.keycloak.services.filters.KeycloakSessionServletFilter. >> doFilter(KeycloakSessionServletFilter.java:90) >> at io.undertow.servlet.core.ManagedFilter.doFilter( >> ManagedFilter.java:60) >> at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl. >> doFilter(FilterHandler.java:131) >> at io.undertow.servlet.handlers.FilterHandler.handleRequest( >> FilterHandler.java:84) >> at io.undertow.servlet.handlers.security. >> ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler. >> java:62) >> at io.undertow.servlet.handlers.ServletDispatchingHandler. >> handleRequest(ServletDispatchingHandler.java:36) >> at org.wildfly.extension.undertow.security. >> SecurityContextAssociationHandler.handleRequest( >> SecurityContextAssociationHandler.java:78) >> at io.undertow.server.handlers.PredicateHandler.handleRequest( >> PredicateHandler.java:43) >> at io.undertow.servlet.handlers.security. >> SSLInformationAssociationHandler.handleRequest( >> SSLInformationAssociationHandler.java:131) >> at io.undertow.servlet.handlers.security. >> ServletAuthenticationCallHandler.handleRequest( >> ServletAuthenticationCallHandler.java:57) >> at io.undertow.server.handlers.PredicateHandler.handleRequest( >> PredicateHandler.java:43) >> at io.undertow.security.handlers.AbstractConfidentialityHandler >> .handleRequest(AbstractConfidentialityHandler.java:46) >> at io.undertow.servlet.handlers.security. >> ServletConfidentialityConstraintHandler.handleRequest( >> ServletConfidentialityConstraintHandler.java:64) >> at io.undertow.security.handlers.AuthenticationMechanismsHandle >> r.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.AbstractSecurityContextAssocia >> tionHandler.handleRequest(AbstractSecurityContextAssocia >> tionHandler.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 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) >> >> 00:51:41,548 WARN [org.keycloak.events] (default task-2) >> type=LOGIN_ERROR, realmId=O4ZR9N2V6U, clientId=http://192.168.99. >> 100:8888/saml-sp/saml/metadata, userId=null, ipAddress=192.168.99.1, >> error=in >> valid_user_credentials, auth_method=saml, redirect_uri=http://192.168. >> 99.100:8888/saml-sp/saml/SSO, code_id=fa04e6ff-3767-419c-a5bf-7bc2c94e8300 >> >> >> I am a bit lost here on what is wrong. Does this request I pasted above >> look correct? If not, let me know what is wrong/missing there. Also, my >> understanding is that I don't need to enable anything on keycloak for this. >> I was earlier able to do browser based authentication using this same saml >> SP, IDP and the user. Then, I enabled ECP on SP to test authentication >> using ecp.sh script but I encountered the above error and output. I would >> appreciate any help or pointers on this. >> >> >> >> >> >> >> >> >> Also, for reference, this is the SP response (I printed the $sp_resp >> variable in ecp.sh): >> >> >> >> >> > soap11:actor="http://schemas.xmlsoap.org/soap/actor/next" >> soap11:mustUnderstand="1"/> >> > IsPassive="false" soap11:actor="http://schemas.xmlsoap.org/soap/actor/next" >> soap11:mustUnderstand="1"> >> http:// >> 192.168.99.100:8888/saml-sp/saml/metadata >> >> >> >> > AssertionConsumerServiceURL="http://192.168.99.100:8888/saml-sp/saml/SSO" >> ForceAuthn="false" ID="a1bj9ed5f38c4c1f1331hifbg36363" IsPassive="false" >> IssueInstant="2016-12-24T01:14:48.538Z" ProtocolBinding="urn:oasis: >> names:tc:SAML:2.0:bindings:PAOS" Version="2.0"> >> http:// >> 192.168.99.100:8888/saml-sp/saml/metadata >> >> >> >> >> >> >> >> >> >> >> sOgymsP3qFQ4QQFiGP7oUjtutUw= >> >> >> ZGxJgqOcGe2XarIF1JtfjikRmpsIjglB4mKeYdfUbwUavtH25XgZ/ >> YmgTDFlCYbq2piAM0NvibcyPtXjgX26zATtWJg3URqHpqWclccql8I5arrVf >> kHTKUQxIx0Rk9bxxytsS012SptubO9F4a+b4LAWoaE9L4IymGVtLpZRLYRL2rhhj >> wIehT/hSXTWWNRWrLWYb03klaCp/1hZIEUIUW1nyeveyWfaeN1LF7BJ63y >> MdWOrtUEaF388chUcg1dpFB7HeYq1Q5GCYyEsFk3yi1CEcZ/ >> qeXyfbHAwixFOG0pPNyeunn6QDZzFD8sSVepXzuFLb8MuuthNYSb0hVLrwQ= >> = >> >> >> MIIDUjCCAjqgAwIBAgIEUOLIQTANBg >> kqhkiG9w0BAQUFADBrMQswCQYDVQQGEwJGSTEQMA4GA1UE >> CBMHVXVzaW1hYTERMA8GA1UEBxMISGVsc2lua2kxGDAWBgNVBAoTD1JNNSBTb2Z0d2FyZSBPeTEM >> MAoGA1UECwwDUiZEMQ8wDQYDVQQDEwZhcG9sbG8wHhcNMTMwMTAxMTEyODAxWhcNMjIxMjMwMTEy >> ODAxWjBrMQswCQYDVQQGEwJGSTEQMA4GA1UECBMHVXVzaW1hYTERMA8GA1UEBxMISGVsc2lua2kx >> GDAWBgNVBAoTD1JNNSBTb2Z0d2FyZSBPeTEMMAoGA1UECwwDUiZEMQ8wDQYDVQQDEwZhcG9sbG8w >> ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCXqP0wqL2Ai1haeTj0alwsLafhrDtUt00E >> 5xc7kdD7PISRA270ZmpYMB4W24Uk2QkuwaBp6dI/yRdUvPfOT45YZrqIxMe2451PAQWtEKWF5Z13 >> F0J4/lB71TtrzyH94RnqSHXFfvRN8EY/rzuEzrpZrHdtNs9LRyLqcRTXMMO4z7QghBuxh3K5gu7K >> qxpHx6No83WNZj4B3gvWLRWv05nbXh/F9YMeQClTX1iBNAhLQxWhwXMKB4u1iPQ/KSaal3R26pON >> UUmu1qVtU1quQozSTPD8HvsDqGG19v2+/N3uf5dRYtvEPfwXN3wIY+/R93vBA6lnl5nTctZIRsyg >> 0Gv5AgMBAAEwDQYJKoZIhvcNAQEFBQADggEBAFQwAAYUjso1VwjDc2kypK/RRcB8bMAUUIG0hLGL >> 82IvnKouGixGqAcULwQKIvTs6uGmlgbSG6Gn5ROb2mlBztXqQ49zRvi5qWNRttir6eyqwRFGOM6A >> 8rxj3Jhxi2Vb/MJn7XzeVHHLzA1sV5hwl/2PLnaL2h9WyG9QwBbwtmkMEqUt/dgixKb1Rvby/tBu >> RogWgPONNSACiW+Z5o8UdAOqNMZQozD/i1gOjBXoF0F5OksjQN7xoQZLj9xXefxCFQ69FPcFDeEW >> bHwSoBy5hLPNALaEUoa5zPDwlixwRjFQTc5XXaRpgIjy/2gsL8+ >> Y5QRhyXnLqgO67BlLYW/GuHE= >> >> >> >> >> >> >> > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > -- John From sthorger at redhat.com Tue Jan 3 09:27:21 2017 From: sthorger at redhat.com (Stian Thorgersen) Date: Tue, 3 Jan 2017 15:27:21 +0100 Subject: [keycloak-dev] Getting error with authentication using ecp.sh script In-Reply-To: <41eb63bb-9c52-cb76-c951-8911e31d9795@redhat.com> References: <41eb63bb-9c52-cb76-c951-8911e31d9795@redhat.com> Message-ID: What version of Keycloak is this? On 3 January 2017 at 15:10, John Dennis wrote: > On 12/27/2016 08:52 AM, Rashmi Singh wrote: > > Hi All, Just a reminder if some insights/help could be provided on my > SAML > > request and the issue I am facing. > > What Rashmi failed to mention is that after submitting the SAML > AuthnRequest to Keycloak the response was a server 500 error. I asked > him to look for any backtraces that appeared in the Keycloak log after > receiving the AuthnRequest which he did and included here. > > To the best of my knowledge the AuthnRequest is well formed but even if > it wasn't the response should have been a SAML Response with an error, > not a HTTP 500 status code. > > What we need to figure out is why Keycloak is throwing an uncaught > exception resulting in the HTTP 500 status code. > > ECP requires either basic or digest authentication on the endpoint > processing the AuthnRequest. My suspicion based on the "Failed > authentication" message at the beginning of the backtrace is either the > authentication did not occur on the endpoint or there was a failure to > record the authentication occurred and was successful, just a guess. > > > > > On Fri, Dec 23, 2016 at 9:01 PM, Rashmi Singh > > wrote: > > > >> Hi All, > >> > >> I am using ecp.sh (provided by keycloak team, ofcourse with changes on > >> idp_endpoint based on my keycloak environment) to perform > authentication. > > Just to clarify, ecp.sh was not provided by the keycloak team. I > provided it to Rashmi. It's a script I've used in the past to test ECP. > > >> I am using spring saml SP and keycloak IDP. I enabled ecp on the SP side > >> and then I execute ecp.sh script as: > >> > >> ./ecp.sh -d rhsso http://192.168.99.100:8888/saml-sp/first.jsp newuser4 > >> > >> > >> My idp_endpoint is: "http://192.168.99.100:9990/auth/realms/xxxxxxxxxx/ > >> protocol/saml" > >> where xxxxxxxxxx is my realm (replaced my realm with xxxxxxxxxx for this > >> email) > >> > >> The script prompts me to enter password and then it sends an auth > request > >> to keycloak IDP. > >> > >> Now, something goes wrong at the IDP. > >> I enabled saml logs on keycloak to see the incoming request and the > >> following error from the logs: > >> > >> 00:51:40,656 DEBUG [org.keycloak.saml.SAMLRequestParser] (default > task-2) > >> SAML POST Binding > >> 00:51:40,656 DEBUG [org.keycloak.saml.SAMLRequestParser] (default > task-2) > >> >> AssertionConsumerServiceURL="http://192.168.99.100:8888/ > saml-sp/saml/SSO" > >> ForceAuthn="false" ID="a31ah57718g27gd149da6jeb08620ig" > IsPassive="false" > >> IssueInstant="2016-12-24T00:51:34.799Z" ProtocolBinding="urn:oasis: > >> names:tc:SAML:2.0:bindings:PAOS" Version="2.0"> > >> http:// > >> 192.168.99.100:8888/saml-sp/saml/metadata > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> nfLQ9IFs9IFnSgw3HHHKuPkAbRY= > >> > >> > >> iULSwpjBb38Vmtan4ZIocRx4PNr6fHRuhVbL+ > >> 7yXNz3wqjlSavtk7haUiADwUS2cTofRM5KDzUvIkaQPXBZqEkz2xnrhpNj71 > >> eIqJ6H4ZqW3mpvP8Bk9z3VEmcEQhZSd6j8rMf4JOdIBRtE7cea0wJhuQ1Uds > >> HdcKeIdp+wuRvn8t9vS/mPKd9GAt11JpC+bgMQS0MDy+r1+AZof2+ > >> XMyMuwECVIkouTzwlgKDEmgvQh6Aq61f+QzIeeZ9+3efwJyIH61x7J4CaiSTpesezlXx8UQ > >> nqIL+AToL1OFHSp2bgXXxkP1rHSkyNM34Eg92LmI5cN3oBfQDR8r+mCoEctWA== >> ds:SignatureValue> > >> > >> > >> MIIDUjCCAjqgAwIBAgIEUOLIQTANBg > >> kqhkiG9w0BAQUFADBrMQswCQYDVQQGEwJGSTEQMA4GA1UECBMHVXVzaW1hYT > >> ERMA8GA1UEBxMISGVsc2lua2kxGDAWBgNVBAoTD1JNNSBTb2Z0d2FyZSBPeT > >> EMMAoGA1UECwwDUiZEMQ8wDQYDVQQDEwZhcG9sbG8wHhcNMTMwMTAxMTEyOD > >> AxWhcNMjIxMjMwMTEyODAxWjBrMQswCQYDVQQGEwJGSTEQMA4GA1UECBMHVX > >> VzaW1hYTERMA8GA1UEBxMISGVsc2lua2kxGDAWBgNVBAoTD1JNNSBTb2Z0d2 > >> FyZSBPeTEMMAoGA1UECwwDUiZEMQ8wDQYDVQQDEwZhcG9sbG8wggEiMA0GCS > >> qGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCXqP0wqL2Ai1haeTj0alwsLafhrD > >> tUt00E5xc7kdD7PISRA270ZmpYMB4W24Uk2QkuwaBp6dI/ > >> yRdUvPfOT45YZrqIxMe2451PAQWtEKWF5Z13F0J4/lB71TtrzyH94RnqSHXFfvRN8EY/ > >> rzuEzrpZrHdtNs9LRyLqcRTXMMO4z7QghBuxh3K5gu7KqxpHx6No83WNZj4B > >> 3gvWLRWv05nbXh/F9YMeQClTX1iBNAhLQxWhwXMKB4u1iPQ/ > >> KSaal3R26pONUUmu1qVtU1quQozSTPD8HvsDqGG19v2+/N3uf5dRYtvEPfwXN3wIY+/ > >> R93vBA6lnl5nTctZIRsyg0Gv5AgMBAAEwDQYJKoZIhvcNAQEFBQADggEBAFQ > >> wAAYUjso1VwjDc2kypK/RRcB8bMAUUIG0hLGL82IvnKouGixGq > >> AcULwQKIvTs6uGmlgbSG6Gn5ROb2mlBztXqQ49zRvi5qWNRttir6eyqwRFGO > >> M6A8rxj3Jhxi2Vb/MJn7XzeVHHLzA1sV5hwl/2PLnaL2h9WyG9QwBbwtmkMEqUt/ > >> dgixKb1Rvby/tBuRogWgPONNSACiW+Z5o8UdAOqNMZQozD/ > >> i1gOjBXoF0F5OksjQN7xoQZLj9xXefxCFQ69FPcFDeEWbHwSoBy5hLPNALaE > >> Uoa5zPDwlixwRjFQTc5XXaRpgIjy/2gsL8+Y5QRhyXnLqgO67BlLYW/ > >> GuHE= > >> > >> > >> > >> > >> > >> 00:51:41,265 DEBUG [org.keycloak.saml.common] (default task-2) The > >> provider ApacheXMLDSig - 2.05 was added at position: 2 > >> 00:51:41,545 WARN [org.keycloak.services] (default task-2) > >> KC-SERVICES0013: Failed authentication: org.keycloak.authentication. > >> AuthenticationFlowException > >> at org.keycloak.authentication.DefaultAuthenticationFlow. > >> processResult(DefaultAuthenticationFlow.java:242) > >> at org.keycloak.authentication.DefaultAuthenticationFlow. > >> processFlow(DefaultAuthenticationFlow.java:185) > >> at org.keycloak.authentication.AuthenticationProcessor. > >> authenticateOnly(AuthenticationProcessor.java:792) > >> at org.keycloak.protocol.AuthorizationEndpointBase. > >> handleBrowserAuthenticationRequest(AuthorizationEndpointBase.java:100) > >> at org.keycloak.protocol.saml.SamlService. > >> newBrowserAuthentication(SamlService.java:505) > >> at org.keycloak.protocol.saml.profile.ecp. > SamlEcpProfileService. > >> newBrowserAuthentication(SamlEcpProfileService.java:89) > >> at org.keycloak.protocol.saml.SamlService. > >> newBrowserAuthentication(SamlService.java:501) > >> at org.keycloak.protocol.saml.SamlService$BindingProtocol. > >> loginRequest(SamlService.java:297) > >> at org.keycloak.protocol.saml.profile.ecp. > SamlEcpProfileService$1. > >> loginRequest(SamlEcpProfileService.java:72) > >> at org.keycloak.protocol.saml.SamlService$BindingProtocol. > >> handleSamlRequest(SamlService.java:209) > >> at org.keycloak.protocol.saml.SamlService$ > >> PostBindingProtocol.execute(SamlService.java:453) > >> at org.keycloak.protocol.saml.profile.ecp. > SamlEcpProfileService. > >> authenticate(SamlEcpProfileService.java:74) > >> at org.keycloak.protocol.saml.SamlService.soapBinding( > >> SamlService.java:619) > >> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > >> at sun.reflect.NativeMethodAccessorImpl.invoke( > >> NativeMethodAccessorImpl.java:62) > >> at sun.reflect.DelegatingMethodAccessorImpl.invoke( > >> DelegatingMethodAccessorImpl.java:43) > >> at java.lang.reflect.Method.invoke(Method.java:498) > >> at org.jboss.resteasy.core.MethodInjectorImpl.invoke( > >> MethodInjectorImpl.java:139) > >> at org.jboss.resteasy.core.ResourceMethodInvoker. > invokeOnTarget( > >> ResourceMethodInvoker.java:295) > >> at org.jboss.resteasy.core.ResourceMethodInvoker.invoke( > >> ResourceMethodInvoker.java:249) > >> at org.jboss.resteasy.core.ResourceLocatorInvoker. > >> invokeOnTargetObject(ResourceLocatorInvoker.java:138) > >> at org.jboss.resteasy.core.ResourceLocatorInvoker.invoke( > >> ResourceLocatorInvoker.java:101) > >> at org.jboss.resteasy.core.SynchronousDispatcher.invoke( > >> SynchronousDispatcher.java:395) > >> at org.jboss.resteasy.core.SynchronousDispatcher.invoke( > >> SynchronousDispatcher.java:202) > >> at org.jboss.resteasy.plugins.server.servlet. > >> ServletContainerDispatcher.service(ServletContainerDispatcher.java:221) > >> at org.jboss.resteasy.plugins.server.servlet. > >> HttpServletDispatcher.service(HttpServletDispatcher.java:56) > >> at org.jboss.resteasy.plugins.server.servlet. > >> HttpServletDispatcher.service(HttpServletDispatcher.java:51) > >> at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) > >> at io.undertow.servlet.handlers.ServletHandler.handleRequest( > >> ServletHandler.java:85) > >> at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl. > >> doFilter(FilterHandler.java:129) > >> at org.keycloak.services.filters.KeycloakSessionServletFilter. > >> doFilter(KeycloakSessionServletFilter.java:90) > >> at io.undertow.servlet.core.ManagedFilter.doFilter( > >> ManagedFilter.java:60) > >> at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl. > >> doFilter(FilterHandler.java:131) > >> at io.undertow.servlet.handlers.FilterHandler.handleRequest( > >> FilterHandler.java:84) > >> at io.undertow.servlet.handlers.security. > >> ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler. > >> java:62) > >> at io.undertow.servlet.handlers.ServletDispatchingHandler. > >> handleRequest(ServletDispatchingHandler.java:36) > >> at org.wildfly.extension.undertow.security. > >> SecurityContextAssociationHandler.handleRequest( > >> SecurityContextAssociationHandler.java:78) > >> at io.undertow.server.handlers.PredicateHandler.handleRequest( > >> PredicateHandler.java:43) > >> at io.undertow.servlet.handlers.security. > >> SSLInformationAssociationHandler.handleRequest( > >> SSLInformationAssociationHandler.java:131) > >> at io.undertow.servlet.handlers.security. > >> ServletAuthenticationCallHandler.handleRequest( > >> ServletAuthenticationCallHandler.java:57) > >> at io.undertow.server.handlers.PredicateHandler.handleRequest( > >> PredicateHandler.java:43) > >> at io.undertow.security.handlers.AbstractConfidentialityHandler > >> .handleRequest(AbstractConfidentialityHandler.java:46) > >> at io.undertow.servlet.handlers.security. > >> ServletConfidentialityConstraintHandler.handleRequest( > >> ServletConfidentialityConstraintHandler.java:64) > >> at io.undertow.security.handlers.AuthenticationMechanismsHandle > >> r.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.AbstractSecurityContextAssocia > >> tionHandler.handleRequest(AbstractSecurityContextAssocia > >> tionHandler.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 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) > >> > >> 00:51:41,548 WARN [org.keycloak.events] (default task-2) > >> type=LOGIN_ERROR, realmId=O4ZR9N2V6U, clientId=http://192.168.99. > >> 100:8888/saml-sp/saml/metadata, userId=null, ipAddress=192.168.99.1, > >> error=in > >> valid_user_credentials, auth_method=saml, redirect_uri=http://192.168. > >> 99.100:8888/saml-sp/saml/SSO, code_id=fa04e6ff-3767-419c- > a5bf-7bc2c94e8300 > >> > >> > >> I am a bit lost here on what is wrong. Does this request I pasted above > >> look correct? If not, let me know what is wrong/missing there. Also, my > >> understanding is that I don't need to enable anything on keycloak for > this. > >> I was earlier able to do browser based authentication using this same > saml > >> SP, IDP and the user. Then, I enabled ECP on SP to test authentication > >> using ecp.sh script but I encountered the above error and output. I > would > >> appreciate any help or pointers on this. > >> > >> > >> > >> > >> > >> > >> > >> > >> Also, for reference, this is the SP response (I printed the $sp_resp > >> variable in ecp.sh): > >> > >> > >> > >> > >> responseConsumerURL=" > >> http://192.168.99.100:8888/saml-sp/saml/SSO" > service="urn:oasis:names:tc:SAML:2.0:profiles:SSO:ecp" > >> soap11:actor="http://schemas.xmlsoap.org/soap/actor/next" > >> soap11:mustUnderstand="1"/> > >> >> IsPassive="false" soap11:actor="http://schemas. > xmlsoap.org/soap/actor/next" > >> soap11:mustUnderstand="1"> > >> http:// > >> 192.168.99.100:8888/saml-sp/saml/metadata > >> > >> > >> > >> >> AssertionConsumerServiceURL="http://192.168.99.100:8888/ > saml-sp/saml/SSO" > >> ForceAuthn="false" ID="a1bj9ed5f38c4c1f1331hifbg36363" > IsPassive="false" > >> IssueInstant="2016-12-24T01:14:48.538Z" ProtocolBinding="urn:oasis: > >> names:tc:SAML:2.0:bindings:PAOS" Version="2.0"> > >> http:// > >> 192.168.99.100:8888/saml-sp/saml/metadata > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> sOgymsP3qFQ4QQFiGP7oUjtutUw= > >> > >> > >> ZGxJgqOcGe2XarIF1JtfjikRmpsIjg > lB4mKeYdfUbwUavtH25XgZ/ > >> YmgTDFlCYbq2piAM0NvibcyPtXjgX26zATtWJg3URqHpqWclccql8I5arrVf > >> kHTKUQxIx0Rk9bxxytsS012SptubO9F4a+b4LAWoaE9L4IymGVtLpZRLYRL2rhhj > >> wIehT/hSXTWWNRWrLWYb03klaCp/1hZIEUIUW1nyeveyWfaeN1LF7BJ63y > >> MdWOrtUEaF388chUcg1dpFB7HeYq1Q5GCYyEsFk3yi1CEcZ/ > >> qeXyfbHAwixFOG0pPNyeunn6QDZzFD8sSVepXzuFLb8MuuthNYSb0hVLrwQ= > >> = > >> > >> > >> MIIDUjCCAjqgAwIBAgIEUOLIQTANBg > >> kqhkiG9w0BAQUFADBrMQswCQYDVQQGEwJGSTEQMA4GA1UE > >> CBMHVXVzaW1hYTERMA8GA1UEBxMISGVsc2lua2kxGDAWBgNVBAoTD1JNNSBT > b2Z0d2FyZSBPeTEM > >> MAoGA1UECwwDUiZEMQ8wDQYDVQQDEwZhcG9sbG8wHhcNMTMwMTAxMTEyODAx > WhcNMjIxMjMwMTEy > >> ODAxWjBrMQswCQYDVQQGEwJGSTEQMA4GA1UECBMHVXVzaW1hYTERMA8GA1UE > BxMISGVsc2lua2kx > >> GDAWBgNVBAoTD1JNNSBTb2Z0d2FyZSBPeTEMMAoGA1UECwwDUiZEMQ8wDQYD > VQQDEwZhcG9sbG8w > >> ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCXqP0wqL2Ai1haeTj0 > alwsLafhrDtUt00E > >> 5xc7kdD7PISRA270ZmpYMB4W24Uk2QkuwaBp6dI/yRdUvPfOT45YZrqIxMe2451PAQWtEK > WF5Z13 > >> F0J4/lB71TtrzyH94RnqSHXFfvRN8EY/rzuEzrpZrHdtNs9LRyLqcRTXMMO4z7 > QghBuxh3K5gu7K > >> qxpHx6No83WNZj4B3gvWLRWv05nbXh/F9YMeQClTX1iBNAhLQxWhwXMKB4u1i > PQ/KSaal3R26pON > >> UUmu1qVtU1quQozSTPD8HvsDqGG19v2+/N3uf5dRYtvEPfwXN3wIY+/ > R93vBA6lnl5nTctZIRsyg > >> 0Gv5AgMBAAEwDQYJKoZIhvcNAQEFBQADggEBAFQwAAYUjso1VwjDc2kypK/ > RRcB8bMAUUIG0hLGL > >> 82IvnKouGixGqAcULwQKIvTs6uGmlgbSG6Gn5ROb2mlBztXqQ49zRvi5qWNR > ttir6eyqwRFGOM6A > >> 8rxj3Jhxi2Vb/MJn7XzeVHHLzA1sV5hwl/2PLnaL2h9WyG9QwBbwtmkMEqUt/ > dgixKb1Rvby/tBu > >> RogWgPONNSACiW+Z5o8UdAOqNMZQozD/i1gOjBXoF0F5OksjQN7xoQZLj9xXef > xCFQ69FPcFDeEW > >> bHwSoBy5hLPNALaEUoa5zPDwlixwRjFQTc5XXaRpgIjy/2gsL8+ > >> Y5QRhyXnLqgO67BlLYW/GuHE= > >> > >> > >> > >> > >> > >> > >> > > _______________________________________________ > > keycloak-dev mailing list > > keycloak-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > > > -- > John > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > From sthorger at redhat.com Wed Jan 4 00:46:22 2017 From: sthorger at redhat.com (Stian Thorgersen) Date: Wed, 4 Jan 2017 06:46:22 +0100 Subject: [keycloak-dev] Allow bearer-only cilents to have service accounts Message-ID: Currently a bearer-only client can't have a service account and that seems like a mistake. Further this prevents bearer-only clients to use the authorization services. Is there any good reasons why bearer-only clients can't have service accounts and be able to obtain token using the client credential grant? The only thing a bearer-only client should be prevented to do IMO is authenticate users (authorization code flow and resource owner credential grant). From sthorger at redhat.com Wed Jan 4 01:24:13 2017 From: sthorger at redhat.com (Stian Thorgersen) Date: Wed, 4 Jan 2017 07:24:13 +0100 Subject: [keycloak-dev] Keycloak 2.5.0.Final Released Message-ID: Keycloak 2.5.0.Final has just been released. There are no changes since 2.5.0.CR1. To download the release go to the Keycloak homepage . Before you upgrade refer to the migration guide . From sthorger at redhat.com Wed Jan 4 06:56:34 2017 From: sthorger at redhat.com (Stian Thorgersen) Date: Wed, 4 Jan 2017 12:56:34 +0100 Subject: [keycloak-dev] Run testsuite with distribution by default Message-ID: I propose we change the default build to also build the server distribution. We should also make the Arquillian testsuite use the server distribution by default and not the embedded Undertow version. The embedded Undertow version should only be used when running tests from within the IDE. It should only add ~2 min to a full build. Any objections/comments? From sven.thoms at gmail.com Wed Jan 4 07:03:03 2017 From: sven.thoms at gmail.com (Sven Thoms) Date: Wed, 4 Jan 2017 13:03:03 +0100 Subject: [keycloak-dev] dynamic client registration fixed registration access tokens In-Reply-To: References: Message-ID: Hello For client registration health checks and subsequent request resiliency (what if answer with registration access token does not arrive), is it possible to keep the registration access token permanent and unchanging, once client is registered ? Regards Sven From sthorger at redhat.com Wed Jan 4 07:17:13 2017 From: sthorger at redhat.com (Stian Thorgersen) Date: Wed, 4 Jan 2017 13:17:13 +0100 Subject: [keycloak-dev] dynamic client registration fixed registration access tokens In-Reply-To: References: Message-ID: For health checks do a get which doesn't change the registration access token. Only updates do. It's not possible to currently keep the registration access token, but we should be able to add an option to do so. Supporting last two registration access tokens might be a good compromise as that would allow retrying the previous one in the event of a failure, but still allow detecting if the token is leaked. On 4 January 2017 at 13:03, Sven Thoms wrote: > Hello > > For client registration health checks and subsequent request resiliency > (what if answer with registration access token does not arrive), is it > possible to keep the registration access token permanent and unchanging, > once client is registered ? > > Regards > > Sven > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > From ssilvert at redhat.com Wed Jan 4 08:39:07 2017 From: ssilvert at redhat.com (Stan Silvert) Date: Wed, 04 Jan 2017 08:39:07 -0500 Subject: [keycloak-dev] Run testsuite with distribution by default In-Reply-To: References: Message-ID: <586CFAFB.5080201@redhat.com> +1 On 1/4/2017 6:56 AM, Stian Thorgersen wrote: > I propose we change the default build to also build the server > distribution. We should also make the Arquillian testsuite use the server > distribution by default and not the embedded Undertow version. The embedded > Undertow version should only be used when running tests from within the IDE. > > It should only add ~2 min to a full build. > > Any objections/comments? > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev From psilva at redhat.com Wed Jan 4 08:56:38 2017 From: psilva at redhat.com (Pedro Igor) Date: Wed, 04 Jan 2017 11:56:38 -0200 Subject: [keycloak-dev] Allow bearer-only cilents to have service accounts In-Reply-To: References: Message-ID: +1. Besides, there is a very clear if statement on the token endpoint that blocks any attempt from bearer-only clients to obtain tokens. On 1/4/2017 3:47:48 AM, Stian Thorgersen wrote: Currently a bearer-only client can't have a service account and that seems like a mistake. Further this prevents bearer-only clients to use the authorization services. Is there any good reasons why bearer-only clients can't have service accounts and be able to obtain token using the client credential grant? The only thing a bearer-only client should be prevented to do IMO is authenticate users (authorization code flow and resource owner credential grant). _______________________________________________ keycloak-dev mailing list keycloak-dev at lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-dev From sthorger at redhat.com Wed Jan 4 09:23:40 2017 From: sthorger at redhat.com (Stian Thorgersen) Date: Wed, 4 Jan 2017 15:23:40 +0100 Subject: [keycloak-dev] Allow bearer-only cilents to have service accounts In-Reply-To: References: Message-ID: On 4 January 2017 at 14:56, Pedro Igor wrote: > +1. Besides, there is a very clear if statement on the token endpoint that > blocks any attempt from bearer-only clients to obtain tokens. > FIY that if statement was added before we did service accounts / client credential grants > On 1/4/2017 3:47:48 AM, Stian Thorgersen wrote: > Currently a bearer-only client can't have a service account and that seems > like a mistake. Further this prevents bearer-only clients to use the > authorization services. > > Is there any good reasons why bearer-only clients can't have service > accounts and be able to obtain token using the client credential grant? > > The only thing a bearer-only client should be prevented to do IMO is > authenticate users (authorization code flow and resource owner credential > grant). > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > From sven.thoms at gmail.com Wed Jan 4 09:42:02 2017 From: sven.thoms at gmail.com (Sven Thoms) Date: Wed, 4 Jan 2017 15:42:02 +0100 Subject: [keycloak-dev] dynamic client registration fixed registration access tokens In-Reply-To: References: Message-ID: The registration access token changes compared to POST request return at /clients-registrations/openid-connect even in case of health check GET response at /clients-registrations/[ client_ID] That is ok for now, the code calling ClientRegistrationUtils. updateRegistrationAccessToken. We found a way in our application to extract the changing registration access token. I agree though that having an option for keeping the registration access token constant or supporting the last two as valid would be great. Am 04.01.2017 1:17 nachm. schrieb "Stian Thorgersen" : > For health checks do a get which doesn't change the registration access > token. Only updates do. > > It's not possible to currently keep the registration access token, but we > should be able to add an option to do so. Supporting last two registration > access tokens might be a good compromise as that would allow retrying the > previous one in the event of a failure, but still allow detecting if the > token is leaked. > > On 4 January 2017 at 13:03, Sven Thoms wrote: > >> Hello >> >> For client registration health checks and subsequent request resiliency >> (what if answer with registration access token does not arrive), is it >> possible to keep the registration access token permanent and unchanging, >> once client is registered ? >> >> Regards >> >> Sven >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> > > From hmlnarik at redhat.com Wed Jan 4 09:56:08 2017 From: hmlnarik at redhat.com (Hynek Mlnarik) Date: Wed, 4 Jan 2017 15:56:08 +0100 Subject: [keycloak-dev] Run testsuite with distribution by default In-Reply-To: <586CFAFB.5080201@redhat.com> References: <586CFAFB.5080201@redhat.com> Message-ID: +1 On Wed, Jan 4, 2017 at 2:39 PM, Stan Silvert wrote: > +1 > > On 1/4/2017 6:56 AM, Stian Thorgersen wrote: > > I propose we change the default build to also build the server > > distribution. We should also make the Arquillian testsuite use the server > > distribution by default and not the embedded Undertow version. The > embedded > > Undertow version should only be used when running tests from within the > IDE. > > > > It should only add ~2 min to a full build. > > > > Any objections/comments? > > _______________________________________________ > > 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 > -- --Hynek From psilva at redhat.com Wed Jan 4 11:49:12 2017 From: psilva at redhat.com (Pedro Igor) Date: Wed, 04 Jan 2017 14:49:12 -0200 Subject: [keycloak-dev] Allow bearer-only cilents to have service accounts In-Reply-To: References: Message-ID: <4d5d8bc6-c738-4b60-892d-3887c5f07a41@getmailbird.com> Yeah, it was there since day 0 if you look git history. On 1/4/2017 12:23:42 PM, Stian Thorgersen wrote: On 4 January 2017 at 14:56, Pedro Igor wrote: +1. Besides, there is a very clear if statement on the token endpoint that blocks any attempt from bearer-only clients to obtain tokens. FIY that if statement was added before we did service accounts / client credential grants On 1/4/2017 3:47:48 AM, Stian Thorgersen wrote: Currently a bearer-only client can't have a service account and that seems like a mistake. Further this prevents bearer-only clients to use the authorization services. Is there any good reasons why bearer-only clients can't have service accounts and be able to obtain token using the client credential grant? The only thing a bearer-only client should be prevented to do IMO is authenticate users (authorization code flow and resource owner credential grant). _______________________________________________ keycloak-dev mailing list keycloak-dev at lists.jboss.org [mailto:keycloak-dev at lists.jboss.org] https://lists.jboss.org/mailman/listinfo/keycloak-dev [https://lists.jboss.org/mailman/listinfo/keycloak-dev] From sthorger at redhat.com Thu Jan 5 02:36:38 2017 From: sthorger at redhat.com (Stian Thorgersen) Date: Thu, 5 Jan 2017 08:36:38 +0100 Subject: [keycloak-dev] Allow bearer-only cilents to have service accounts In-Reply-To: <4d5d8bc6-c738-4b60-892d-3887c5f07a41@getmailbird.com> References: <4d5d8bc6-c738-4b60-892d-3887c5f07a41@getmailbird.com> Message-ID: Added https://issues.jboss.org/browse/KEYCLOAK-4156 On 4 January 2017 at 17:49, Pedro Igor wrote: > Yeah, it was there since day 0 if you look git history. > > On 1/4/2017 12:23:42 PM, Stian Thorgersen wrote: > > > On 4 January 2017 at 14:56, Pedro Igor wrote: > >> +1. Besides, there is a very clear if statement on the token endpoint >> that blocks any attempt from bearer-only clients to obtain tokens. >> > > FIY that if statement was added before we did service accounts / client > credential grants > > >> On 1/4/2017 3:47:48 AM, Stian Thorgersen wrote: >> Currently a bearer-only client can't have a service account and that >> seems >> like a mistake. Further this prevents bearer-only clients to use the >> authorization services. >> >> Is there any good reasons why bearer-only clients can't have service >> accounts and be able to obtain token using the client credential grant? >> >> The only thing a bearer-only client should be prevented to do IMO is >> authenticate users (authorization code flow and resource owner credential >> grant). >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> >> > From thomas.darimont at googlemail.com Thu Jan 5 03:21:19 2017 From: thomas.darimont at googlemail.com (Thomas Darimont) Date: Thu, 5 Jan 2017 09:21:19 +0100 Subject: [keycloak-dev] E-Mail handling in Keycloak Message-ID: Hello group, currently Keycloak allows to configure the "from" address per realm which all emails sent from that particular realm use. Often a generic address like no-reply at mycorp.com or a realm specific address like no-reply-myrealm at mycorp.com is used as "from" address. It would be nice if one would have more options here like: 1) Use the realm name or a custom string as the display name for the "from" Address Display Name e.g.: "MyCorp SSO" "MyCorp Helpdesk" 2) Allow to specify a Bounce Address (MAIL FROM) with some place-holders (user-id, realm-id) e.g.: sso-bounces+${realm-id}_${user-id}@mycorp.com This is especially useful when integrating with legacy user stores with unreliable e-mail addresses. Shall I create JIRA issues for that? Cheers, Thomas From sthorger at redhat.com Thu Jan 5 03:44:59 2017 From: sthorger at redhat.com (Stian Thorgersen) Date: Thu, 5 Jan 2017 09:44:59 +0100 Subject: [keycloak-dev] E-Mail handling in Keycloak In-Reply-To: References: Message-ID: On 5 January 2017 at 09:21, Thomas Darimont wrote: > Hello group, > > currently Keycloak allows to configure the "from" address per realm which > all emails sent from that particular realm use. > > Often a generic address like no-reply at mycorp.com or a realm specific > address like > no-reply-myrealm at mycorp.com is used as "from" address. > > It would be nice if one would have more options here like: > > 1) Use the realm name or a custom string as the display name for the "from" > Address > Display Name > e.g.: "MyCorp SSO" > "MyCorp Helpdesk" > We had someone request that in the past and I think there's a issue already open for it. If not then you can create one. Would it come with a PR ;)? > > 2) Allow to specify a Bounce Address (MAIL FROM) with some place-holders > (user-id, realm-id) > e.g.: sso-bounces+${realm-id}_${user-id}@mycorp.com > This is especially useful when integrating with legacy user stores with > unreliable e-mail addresses. > Can you explain this a bit more as I don't understand this > > Shall I create JIRA issues for that? > > Cheers, > Thomas > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > From abhi.raghav007 at gmail.com Thu Jan 5 04:12:10 2017 From: abhi.raghav007 at gmail.com (abhishek raghav) Date: Thu, 5 Jan 2017 14:42:10 +0530 Subject: [keycloak-dev] Keycoak- SQL server partnership Message-ID: Hi As you all know, Keycloak is saying that they wont support mongo as it lacks transactional support. Hence I was thinking of using SQL server as a potential candidate. Few queries which I have as below: 1. We am envisioning an environment where we will have a lot of keycloak instances. Each keycloak instance will require its own database. The way we do it right now, is that we just bring up a new keycloak instance on DCOS and then specific a new database name resident on the database host and then the instance comes up. We are not sure whether we can do this with SQL server much the same way. 2. Not sure what performance characteristics we will get into with a remote SQL Server..? 3. These are linux based container instances that we are setting up for keycloak. Mixing deployment architectures between DCOS containers vs traditional scaling architectures for databases, can it a issue.? Is there anyone here using SQL server as their backend in keycloak. Did anyone face any bad experiences while using SQL server with Keyclak.? Any suggestions for the same are most welcome. *- Best Regards* Abhishek Raghav From thomas.darimont at googlemail.com Thu Jan 5 04:30:40 2017 From: thomas.darimont at googlemail.com (Thomas Darimont) Date: Thu, 5 Jan 2017 10:30:40 +0100 Subject: [keycloak-dev] E-Mail handling in Keycloak In-Reply-To: References: Message-ID: I did look for a JIRA Issue but couldn't find one. There was one issue about being able to set custom smtp-headers: https://issues.jboss.org/browse/KEYCLOAK-3605 @1) yes I'll send a PR ;-) @2) The idea is to add a user specific bounce address to every email sent out by keycloak. So if an admin sends an email to a user with a non-existing email one would get a bounce from the particular email-provider. After some time the e-mail provider will sent a bounce mail to the address that was mentioned in the MAIL FROM, or to be more specific in the smtp.mailfrom SMTP-header header. Those emails can now be collected in a central inbox. The e-mails contain the previously set bounce email address with some additional information like service, realm, userId, e.g.: smtp.mailfrom= bounces+sso_acme-test_0b21aecc-4145-464f-86fa-719559b08869 at example.org This information can now be used to lookup the user with the bad email address and flag the user or even require the user to enter a new e-mail. One could also use a similar trick to encode some additional information like (user realm, user-d) into the custom reply-to address. Based on a generic Help Desk address like helpdesk at example.org one could generate a user specific address like: helpdesk+sso_realm-name_user-id at example.org A CRM application could now lookup the user by it's user-id to add additional information to the helpdesk ticket. The following Java program demonstrates the usage of JavMail with SMTP Envelope From. See the attached image for how this will look for the end-user in gmail. import java.util.Properties; import javax.mail.Message.RecipientType; import javax.mail.Session; import javax.mail.Transport; import javax.mail.internet.InternetAddress; import com.sun.mail.smtp.SMTPMessage; public class JavaMailSmtpBounceExample { public static void main(String[] args) throws Exception { Properties properties = new Properties(); properties.put("mail.smtp.auth", "false"); properties.put("mail.smtp.host", "smtp4server"); properties.put("mail.smtp.port", "25"); Session session = Session.getInstance(properties); SMTPMessage smtpMessage = new SMTPMessage(session); smtpMessage.setContent("Hello World", "text/plain"); smtpMessage.setSubject("Test Mail " + System.currentTimeMillis()); String userDisplayName = "Thomas Darimont"; String userId = "0b21aecc-4145-464f-86fa-719559b08869"; String userEmail = "thomas.darimont at gmail.com"; String realmDisplayName = "acme SSO (test)"; String realmName = "acme-test"; String replyToDisplayName = "Help Desk"; String replyToEmailLocalPart = "helpdesk"; String realmFromEmailLocalPart = "no-reply"; String serviceDomain = "example.org"; String to = String.format("\"%s\"<%s>", userDisplayName, userEmail); String from = String.format("\"%s\"<%s@%s>", realmDisplayName, realmFromEmailLocalPart, serviceDomain); String envelopeFrom = String.format("bounces+sso_%s_%s@%s", realmName, userId, serviceDomain); String replyTo = String.format("\"%s\"<%s@%s>", replyToDisplayName, replyToEmailLocalPart, serviceDomain); System.out.printf("to: %s%n", to); System.out.printf("from: %s%n", from); System.out.printf("envelopeFrom: %s%n", envelopeFrom); System.out.printf("replyTo: %s%n", replyTo); smtpMessage.addRecipient(RecipientType.TO, InternetAddress.parse(to)[0]); smtpMessage.setReplyTo(InternetAddress.parse(replyTo)); smtpMessage.setFrom(InternetAddress.parse(from)[0]); smtpMessage.setEnvelopeFrom(envelopeFrom); Transport.send(smtpMessage); } } Output: to: "Thomas Darimont" from: "acme SSO (test)" envelopeFrom: bounces+sso_acme-test_0b21aecc-4145-464f-86fa-719559b08869 at example.org replyTo: "Help Desk" The email smtp.mailfrom= bounces+sso_acme-test_0b21aecc-4145-464f-86fa-719559b08869 at example.org 2017-01-05 9:44 GMT+01:00 Stian Thorgersen : > > > On 5 January 2017 at 09:21, Thomas Darimont m> wrote: > >> Hello group, >> >> currently Keycloak allows to configure the "from" address per realm which >> all emails sent from that particular realm use. >> >> Often a generic address like no-reply at mycorp.com or a realm specific >> address like >> no-reply-myrealm at mycorp.com is used as "from" address. >> >> It would be nice if one would have more options here like: >> >> 1) Use the realm name or a custom string as the display name for the >> "from" >> Address >> Display Name >> e.g.: "MyCorp SSO" >> "MyCorp Helpdesk" >> > > We had someone request that in the past and I think there's a issue > already open for it. If not then you can create one. Would it come with a > PR ;)? > > >> >> 2) Allow to specify a Bounce Address (MAIL FROM) with some place-holders >> (user-id, realm-id) >> e.g.: sso-bounces+${realm-id}_${user-id}@mycorp.com >> This is especially useful when integrating with legacy user stores with >> unreliable e-mail addresses. >> > > Can you explain this a bit more as I don't understand this > > >> >> Shall I create JIRA issues for that? >> >> Cheers, >> Thomas >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> > > From sthorger at redhat.com Thu Jan 5 05:31:56 2017 From: sthorger at redhat.com (Stian Thorgersen) Date: Thu, 5 Jan 2017 11:31:56 +0100 Subject: [keycloak-dev] E-Mail handling in Keycloak In-Reply-To: References: Message-ID: The from and replyTo makes sense, but not sure the envelopeFrom makes sense. I'm sure it works for you, but it sounds very specific to your use case and not something that would be generic enough to include out of the box. On 5 January 2017 at 10:30, Thomas Darimont wrote: > I did look for a JIRA Issue but couldn't find one. > There was one issue about being able to set custom smtp-headers: > https://issues.jboss.org/browse/KEYCLOAK-3605 > > @1) yes I'll send a PR ;-) > > @2) The idea is to add a user specific bounce address to every email sent > out by keycloak. > So if an admin sends an email to a user with a non-existing email one > would get a bounce from the particular email-provider. > After some time the e-mail provider will sent a bounce mail to the address > that was mentioned in the > MAIL FROM, or to be more specific in the smtp.mailfrom SMTP-header header. > > Those emails can now be collected in a central inbox. The e-mails contain > the previously set > bounce email address with some additional information like service, realm, > userId, e.g.: > smtp.mailfrom=bounces+sso_acme-test_0b21aecc-4145-464f- > 86fa-719559b08869 at example.org > > This information can now be used to lookup the user with the bad email > address and flag the user > or even require the user to enter a new e-mail. > > One could also use a similar trick to encode some additional information > like (user realm, user-d) into the > custom reply-to address. > Based on a generic Help Desk address like helpdesk at example.org one could > generate a user specific address like: > helpdesk+sso_realm-name_user-id at example.org > > A CRM application could now lookup the user by it's user-id to add > additional information to the helpdesk ticket. > > The following Java program demonstrates the usage of JavMail with SMTP > Envelope From. > See the attached image for how this will look for the end-user in gmail. > > import java.util.Properties; > > import javax.mail.Message.RecipientType; > import javax.mail.Session; > import javax.mail.Transport; > import javax.mail.internet.InternetAddress; > > import com.sun.mail.smtp.SMTPMessage; > > public class JavaMailSmtpBounceExample { > > public static void main(String[] args) throws Exception { > > Properties properties = new Properties(); > properties.put("mail.smtp.auth", "false"); > properties.put("mail.smtp.host", "smtp4server"); > properties.put("mail.smtp.port", "25"); > > Session session = Session.getInstance(properties); > SMTPMessage smtpMessage = new SMTPMessage(session); > smtpMessage.setContent("Hello World", "text/plain"); > smtpMessage.setSubject("Test Mail " + System.currentTimeMillis()); > > String userDisplayName = "Thomas Darimont"; > String userId = "0b21aecc-4145-464f-86fa-719559b08869"; > String userEmail = "thomas.darimont at gmail.com"; > > String realmDisplayName = "acme SSO (test)"; > String realmName = "acme-test"; > String replyToDisplayName = "Help Desk"; > String replyToEmailLocalPart = "helpdesk"; > String realmFromEmailLocalPart = "no-reply"; > String serviceDomain = "example.org"; > > String to = String.format("\"%s\"<%s>", userDisplayName, > userEmail); > String from = String.format("\"%s\"<%s@%s>", realmDisplayName, > realmFromEmailLocalPart, > serviceDomain); > String envelopeFrom = String.format("bounces+sso_%s_%s@%s", > realmName, userId, > serviceDomain); > String replyTo = String.format("\"%s\"<%s@%s>", > replyToDisplayName, > replyToEmailLocalPart, serviceDomain); > > System.out.printf("to: %s%n", to); > System.out.printf("from: %s%n", from); > System.out.printf("envelopeFrom: %s%n", envelopeFrom); > System.out.printf("replyTo: %s%n", replyTo); > > smtpMessage.addRecipient(RecipientType.TO, > InternetAddress.parse(to)[0]); > smtpMessage.setReplyTo(InternetAddress.parse(replyTo)); > smtpMessage.setFrom(InternetAddress.parse(from)[0]); > smtpMessage.setEnvelopeFrom(envelopeFrom); > > Transport.send(smtpMessage); > } > } > > Output: > > to: "Thomas Darimont" > from: "acme SSO (test)" > envelopeFrom: bounces+sso_acme-test_0b21aecc-4145-464f-86fa- > 719559b08869 at example.org > replyTo: "Help Desk" > > The email > smtp.mailfrom=bounces+sso_acme-test_0b21aecc-4145-464f- > 86fa-719559b08869 at example.org > > > > > > > 2017-01-05 9:44 GMT+01:00 Stian Thorgersen : > >> >> >> On 5 January 2017 at 09:21, Thomas Darimont < >> thomas.darimont at googlemail.com> wrote: >> >>> Hello group, >>> >>> currently Keycloak allows to configure the "from" address per realm which >>> all emails sent from that particular realm use. >>> >>> Often a generic address like no-reply at mycorp.com or a realm specific >>> address like >>> no-reply-myrealm at mycorp.com is used as "from" address. >>> >>> It would be nice if one would have more options here like: >>> >>> 1) Use the realm name or a custom string as the display name for the >>> "from" >>> Address >>> Display Name >>> e.g.: "MyCorp SSO" >>> "MyCorp Helpdesk" >>> >> >> We had someone request that in the past and I think there's a issue >> already open for it. If not then you can create one. Would it come with a >> PR ;)? >> >> >>> >>> 2) Allow to specify a Bounce Address (MAIL FROM) with some place-holders >>> (user-id, realm-id) >>> e.g.: sso-bounces+${realm-id}_${user-id}@mycorp.com >>> This is especially useful when integrating with legacy user stores with >>> unreliable e-mail addresses. >>> >> >> Can you explain this a bit more as I don't understand this >> >> >>> >>> Shall I create JIRA issues for that? >>> >>> Cheers, >>> Thomas >>> _______________________________________________ >>> keycloak-dev mailing list >>> keycloak-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>> >> >> > From thomas.darimont at googlemail.com Thu Jan 5 05:46:36 2017 From: thomas.darimont at googlemail.com (Thomas Darimont) Date: Thu, 5 Jan 2017 11:46:36 +0100 Subject: [keycloak-dev] E-Mail handling in Keycloak In-Reply-To: References: Message-ID: Okay, PR is on the way for "display name" support and ReplyoTo Email address. The EnvelopeFrom example was just to show you the possibilities. For a start one could just allow to specify a fixed realm-specific bounce address. Will send a PR for that as well. Cheers, Thomas 2017-01-05 11:31 GMT+01:00 Stian Thorgersen : > The from and replyTo makes sense, but not sure the envelopeFrom makes > sense. I'm sure it works for you, but it sounds very specific to your use > case and not something that would be generic enough to include out of the > box. > > On 5 January 2017 at 10:30, Thomas Darimont com> wrote: > >> I did look for a JIRA Issue but couldn't find one. >> There was one issue about being able to set custom smtp-headers: >> https://issues.jboss.org/browse/KEYCLOAK-3605 >> >> @1) yes I'll send a PR ;-) >> >> @2) The idea is to add a user specific bounce address to every email sent >> out by keycloak. >> So if an admin sends an email to a user with a non-existing email one >> would get a bounce from the particular email-provider. >> After some time the e-mail provider will sent a bounce mail to the >> address that was mentioned in the >> MAIL FROM, or to be more specific in the smtp.mailfrom SMTP-header header. >> >> Those emails can now be collected in a central inbox. The e-mails contain >> the previously set >> bounce email address with some additional information like service, >> realm, userId, e.g.: >> smtp.mailfrom=bounces+sso_acme-test_0b21aecc-4145-464f-86fa- >> 719559b08869 at example.org >> >> This information can now be used to lookup the user with the bad email >> address and flag the user >> or even require the user to enter a new e-mail. >> >> One could also use a similar trick to encode some additional information >> like (user realm, user-d) into the >> custom reply-to address. >> Based on a generic Help Desk address like helpdesk at example.org one could >> generate a user specific address like: >> helpdesk+sso_realm-name_user-id at example.org >> >> A CRM application could now lookup the user by it's user-id to add >> additional information to the helpdesk ticket. >> >> The following Java program demonstrates the usage of JavMail with SMTP >> Envelope From. >> See the attached image for how this will look for the end-user in gmail. >> >> import java.util.Properties; >> >> import javax.mail.Message.RecipientType; >> import javax.mail.Session; >> import javax.mail.Transport; >> import javax.mail.internet.InternetAddress; >> >> import com.sun.mail.smtp.SMTPMessage; >> >> public class JavaMailSmtpBounceExample { >> >> public static void main(String[] args) throws Exception { >> >> Properties properties = new Properties(); >> properties.put("mail.smtp.auth", "false"); >> properties.put("mail.smtp.host", "smtp4server"); >> properties.put("mail.smtp.port", "25"); >> >> Session session = Session.getInstance(properties); >> SMTPMessage smtpMessage = new SMTPMessage(session); >> smtpMessage.setContent("Hello World", "text/plain"); >> smtpMessage.setSubject("Test Mail " + System.currentTimeMillis()); >> >> String userDisplayName = "Thomas Darimont"; >> String userId = "0b21aecc-4145-464f-86fa-719559b08869"; >> String userEmail = "thomas.darimont at gmail.com"; >> >> String realmDisplayName = "acme SSO (test)"; >> String realmName = "acme-test"; >> String replyToDisplayName = "Help Desk"; >> String replyToEmailLocalPart = "helpdesk"; >> String realmFromEmailLocalPart = "no-reply"; >> String serviceDomain = "example.org"; >> >> String to = String.format("\"%s\"<%s>", userDisplayName, >> userEmail); >> String from = String.format("\"%s\"<%s@%s>", realmDisplayName, >> realmFromEmailLocalPart, >> serviceDomain); >> String envelopeFrom = String.format("bounces+sso_%s_%s@%s", >> realmName, userId, >> serviceDomain); >> String replyTo = String.format("\"%s\"<%s@%s>", >> replyToDisplayName, >> replyToEmailLocalPart, serviceDomain); >> >> System.out.printf("to: %s%n", to); >> System.out.printf("from: %s%n", from); >> System.out.printf("envelopeFrom: %s%n", envelopeFrom); >> System.out.printf("replyTo: %s%n", replyTo); >> >> smtpMessage.addRecipient(RecipientType.TO, >> InternetAddress.parse(to)[0]); >> smtpMessage.setReplyTo(InternetAddress.parse(replyTo)); >> smtpMessage.setFrom(InternetAddress.parse(from)[0]); >> smtpMessage.setEnvelopeFrom(envelopeFrom); >> >> Transport.send(smtpMessage); >> } >> } >> >> Output: >> >> to: "Thomas Darimont" >> from: "acme SSO (test)" >> envelopeFrom: bounces+sso_acme-test_0b21aecc-4145-464f-86fa-719559b08869@ >> example.org >> replyTo: "Help Desk" >> >> The email >> smtp.mailfrom=bounces+sso_acme-test_0b21aecc-4145-464f-86fa- >> 719559b08869 at example.org >> >> >> >> >> >> >> 2017-01-05 9:44 GMT+01:00 Stian Thorgersen : >> >>> >>> >>> On 5 January 2017 at 09:21, Thomas Darimont < >>> thomas.darimont at googlemail.com> wrote: >>> >>>> Hello group, >>>> >>>> currently Keycloak allows to configure the "from" address per realm >>>> which >>>> all emails sent from that particular realm use. >>>> >>>> Often a generic address like no-reply at mycorp.com or a realm specific >>>> address like >>>> no-reply-myrealm at mycorp.com is used as "from" address. >>>> >>>> It would be nice if one would have more options here like: >>>> >>>> 1) Use the realm name or a custom string as the display name for the >>>> "from" >>>> Address >>>> Display Name >>>> e.g.: "MyCorp SSO" >>>> "MyCorp Helpdesk" >>>> >>> >>> We had someone request that in the past and I think there's a issue >>> already open for it. If not then you can create one. Would it come with a >>> PR ;)? >>> >>> >>>> >>>> 2) Allow to specify a Bounce Address (MAIL FROM) with some place-holders >>>> (user-id, realm-id) >>>> e.g.: sso-bounces+${realm-id}_${user-id}@mycorp.com >>>> This is especially useful when integrating with legacy user stores >>>> with >>>> unreliable e-mail addresses. >>>> >>> >>> Can you explain this a bit more as I don't understand this >>> >>> >>>> >>>> Shall I create JIRA issues for that? >>>> >>>> Cheers, >>>> Thomas >>>> _______________________________________________ >>>> keycloak-dev mailing list >>>> keycloak-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>>> >>> >>> >> > From thomas.raehalme at aitiofinland.com Thu Jan 5 08:32:35 2017 From: thomas.raehalme at aitiofinland.com (Thomas Raehalme) Date: Thu, 5 Jan 2017 15:32:35 +0200 Subject: [keycloak-dev] Roles in Client Template Message-ID: Hi! I was under the (false) impression that Client Templates would also contain role definitions for clients that use the template. Unfortunately I was wrong. My use case is an application where there are multiple instances each belonging to a different tenant. They each have the same set of roles, but their own set of users (or groups) to which the roles are assigned. I would like to be able to maintain the common client settings in the template and focus on tenant-specific settings such as URLs on each client (which are also more static). What do you think would it make sense to add the possibility to define also roles in the Client Template? Best regards, Thomas From dekela at perfectomobile.com Thu Jan 5 10:06:25 2017 From: dekela at perfectomobile.com (Dekel Aslan) Date: Thu, 5 Jan 2017 15:06:25 +0000 Subject: [keycloak-dev] Getting client secret in rest Message-ID: Hello, I'm using the Keycloak class and invoking this line: String secret = keyCloakClient.realm(realmName).clients().findAll().get(0).getSecret(); (get(0) gets the client I need) but it's always null. For getClientAuthenticatorType() it returns "client-secret" as it should, and the UI has the secret in it's credentials tab. Please advise on how to get the client secret via the object. Thanks, Dekel. The information contained in this message is proprietary to the sender, protected from disclosure, and may be privileged. The information is intended to be conveyed only to the designated recipient(s) of the message. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, use, distribution or copying of this communication is strictly prohibited and may be unlawful. If you have received this communication in error, please notify us immediately by replying to the message and deleting it from your computer. Thank you. From mstrukel at redhat.com Thu Jan 5 11:02:31 2017 From: mstrukel at redhat.com (Marko Strukelj) Date: Thu, 5 Jan 2017 17:02:31 +0100 Subject: [keycloak-dev] Getting client secret in rest In-Reply-To: References: Message-ID: Admin REST endpoints purposefully hide any passwords. There is an exception for client secret - there is an endpoint that will return it to you - the one used to get a keycloak adapter configuration for a client: realms/REALM_NAME/clients/ID/installation/providers/keycloak-oidc-keycloak-json Try: keyCloakClient.realm(realmName).clients() .get(ID_OF_CLIENT).getInstallationProvider("keycloak-oidc-keycloak-json"); On Thu, Jan 5, 2017 at 4:06 PM, Dekel Aslan wrote: > Hello, > I'm using the Keycloak class and invoking this line: > String secret = keyCloakClient.realm(realmName).clients().findAll() > .get(0).getSecret(); > (get(0) gets the client I need) > but it's always null. For getClientAuthenticatorType() it returns > "client-secret" as it should, and the UI has the secret in it's credentials > tab. > > Please advise on how to get the client secret via the object. > > Thanks, > Dekel. > > The information contained in this message is proprietary to the sender, > protected from disclosure, and may be privileged. The information is > intended to be conveyed only to the designated recipient(s) of the message. > If the reader of this message is not the intended recipient, you are hereby > notified that any dissemination, use, distribution or copying of this > communication is strictly prohibited and may be unlawful. If you have > received this communication in error, please notify us immediately by > replying to the message and deleting it from your computer. Thank you. > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > From sthorger at redhat.com Fri Jan 6 00:56:50 2017 From: sthorger at redhat.com (Stian Thorgersen) Date: Fri, 6 Jan 2017 06:56:50 +0100 Subject: [keycloak-dev] Getting client secret in rest In-Reply-To: References: Message-ID: We don't hide the client secret at all actually as it's generated by the Keycloak Server. For other secrets that are provided by the user we don't expose them again. The client secret is just not returned with the client request. One reason for this is that a client can have different types of credentials and it's pluggable. Also, there's no need to expose the secret when retrieving clients in general (i.e. listing all clients). You can get the secret from where Marko said, but also from: realms/REALM_NAME/clients/CLIENT_ID/client-secret And you can also get it through the client registration services. Take a look at the docs for that one. On 5 January 2017 at 17:02, Marko Strukelj wrote: > Admin REST endpoints purposefully hide any passwords. There is an exception > for client secret - there is an endpoint that will return it to you - the > one used to get a keycloak adapter configuration for a client: > > realms/REALM_NAME/clients/ID/installation/providers/ > keycloak-oidc-keycloak-json > > Try: > > keyCloakClient.realm(realmName).clients() > .get(ID_OF_CLIENT).getInstallationProvider("keycloak-oidc-keycloak-json"); > > > On Thu, Jan 5, 2017 at 4:06 PM, Dekel Aslan > wrote: > > > Hello, > > I'm using the Keycloak class and invoking this line: > > String secret = keyCloakClient.realm(realmName).clients().findAll() > > .get(0).getSecret(); > > (get(0) gets the client I need) > > but it's always null. For getClientAuthenticatorType() it returns > > "client-secret" as it should, and the UI has the secret in it's > credentials > > tab. > > > > Please advise on how to get the client secret via the object. > > > > Thanks, > > Dekel. > > > > The information contained in this message is proprietary to the sender, > > protected from disclosure, and may be privileged. The information is > > intended to be conveyed only to the designated recipient(s) of the > message. > > If the reader of this message is not the intended recipient, you are > hereby > > notified that any dissemination, use, distribution or copying of this > > communication is strictly prohibited and may be unlawful. If you have > > received this communication in error, please notify us immediately by > > replying to the message and deleting it from your computer. Thank you. > > _______________________________________________ > > keycloak-dev mailing list > > keycloak-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > From sthorger at redhat.com Fri Jan 6 03:31:51 2017 From: sthorger at redhat.com (Stian Thorgersen) Date: Fri, 6 Jan 2017 09:31:51 +0100 Subject: [keycloak-dev] Info endpoint to simplify debugging proxy config Message-ID: I've been looking at some issues with reverse proxy when Keycloak is installed on EAP 7.0.3+ [1]. While doing so I found out that it's fairly inconvenient and not straightforward to debug if the proxy configuration is correct. To verify URLs you have to for example open the well-known endpoint for OIDC. Then you have to verify the remote IP address by doing a failed login attempt and looking at the server log. To make this simpler I propose adding the start of a server info endpoint. It will be a SPI that allows plugging in server info providers that can show different details if authenticated or not. You can either view info for all providers at a time with "/realms/master/.info" or for a specific provider "/realms/master/.info/proxy". The proxy info provider will display: { "authServerUrl" : "http://host1/auth", "remoteAddress" : "127.0.0.1", "proxyDetected" : true, "headers" : { "Host" : "host1", "X-Forwarded-For" : "1.2.3.4", "X-Forwarded-Host" : "host2", "X-Forwarded-Proto" : "https" } } Implementation is ready [2] I just need to get feedback and add tests. In the future we can expand on this to for instance provide a health monitoring endpoint that allows checking the server health (JPA connections, Infinispan connections, IdP connections, user fed connections, etc.). [1] https://issues.jboss.org/browse/KEYCLOAK-4149 [2] https://github.com/stianst/keycloak/commit/99abbc47c49585d1e62c74f3ea227e05b22c23a8 From sthorger at redhat.com Fri Jan 6 08:02:02 2017 From: sthorger at redhat.com (Stian Thorgersen) Date: Fri, 6 Jan 2017 14:02:02 +0100 Subject: [keycloak-dev] Roles in Client Template In-Reply-To: References: Message-ID: I think it can be argued if that makes sense, but the problem is how to implement it. Other things like scope can easily be inherited when consumed, while role inheritance would actually require somehow creating/deleting roles for all clients that use a template. Otherwise it would be impossible to map the roles to anything (scope, users, composite roles, etc..). On 5 January 2017 at 14:32, Thomas Raehalme < thomas.raehalme at aitiofinland.com> wrote: > Hi! > > I was under the (false) impression that Client Templates would also contain > role definitions for clients that use the template. Unfortunately I was > wrong. > > My use case is an application where there are multiple instances each > belonging to a different tenant. They each have the same set of roles, but > their own set of users (or groups) to which the roles are assigned. > > I would like to be able to maintain the common client settings in the > template and focus on tenant-specific settings such as URLs on each client > (which are also more static). > > What do you think would it make sense to add the possibility to define also > roles in the Client Template? > > Best regards, > Thomas > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > From mposolda at redhat.com Fri Jan 6 10:05:25 2017 From: mposolda at redhat.com (Marek Posolda) Date: Fri, 6 Jan 2017 16:05:25 +0100 Subject: [keycloak-dev] Allow bearer-only cilents to have service accounts In-Reply-To: References: Message-ID: <3d0d43a9-0d63-aa2c-8e66-829019c9205f@redhat.com> On 04/01/17 06:46, Stian Thorgersen wrote: > Currently a bearer-only client can't have a service account and that seems > like a mistake. Further this prevents bearer-only clients to use the > authorization services. > > Is there any good reasons why bearer-only clients can't have service > accounts and be able to obtain token using the client credential grant? I assumed that bearer-only client shouldn't be able to have any tokens and clientSessions, which are dedicated directly to him. It is just REST service, which "consumes" the access tokens created for other clients. Also the flag name "Bearer-only" states exactly this. That's the main reason why I did it that way for service accounts. I can't see any big issue with bearer-only client being able to have service account. There are just few things, which will need to be done though (eg. tabs "Mappers" and "Scopes" will need to be enabled for bearer-only clients with enabled service account etc). Marek > > The only thing a bearer-only client should be prevented to do IMO is > authenticate users (authorization code flow and resource owner credential > grant). > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev From mposolda at redhat.com Fri Jan 6 10:21:28 2017 From: mposolda at redhat.com (Marek Posolda) Date: Fri, 6 Jan 2017 16:21:28 +0100 Subject: [keycloak-dev] Info endpoint to simplify debugging proxy config In-Reply-To: References: Message-ID: +1 I wonder if it's cleaner that we also add existing stuff in ServerInfoAdminResource to this SPI? One minor thing, it seems there is not handling of preflight OPTIONS request in your new endpoint? Marek On 06/01/17 09:31, Stian Thorgersen wrote: > I've been looking at some issues with reverse proxy when Keycloak is > installed on EAP 7.0.3+ [1]. While doing so I found out that it's fairly > inconvenient and not straightforward to debug if the proxy configuration is > correct. > > To verify URLs you have to for example open the well-known endpoint for > OIDC. Then you have to verify the remote IP address by doing a failed login > attempt and looking at the server log. > > To make this simpler I propose adding the start of a server info endpoint. > It will be a SPI that allows plugging in server info providers that can > show different details if authenticated or not. > > You can either view info for all providers at a time with > "/realms/master/.info" or for a specific provider > "/realms/master/.info/proxy". > > The proxy info provider will display: > > { > "authServerUrl" : "http://host1/auth", > "remoteAddress" : "127.0.0.1", > "proxyDetected" : true, > "headers" : { > "Host" : "host1", > "X-Forwarded-For" : "1.2.3.4", > "X-Forwarded-Host" : "host2", > "X-Forwarded-Proto" : "https" > } > } > > Implementation is ready [2] I just need to get feedback and add tests. > > In the future we can expand on this to for instance provide a health > monitoring endpoint that allows checking the server health (JPA > connections, Infinispan connections, IdP connections, user fed connections, > etc.). > > [1] https://issues.jboss.org/browse/KEYCLOAK-4149 > [2] > https://github.com/stianst/keycloak/commit/99abbc47c49585d1e62c74f3ea227e05b22c23a8 > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev From olivier.bruylandt at gmail.com Fri Jan 6 10:22:03 2017 From: olivier.bruylandt at gmail.com (Olivier Bruylandt) Date: Fri, 6 Jan 2017 16:22:03 +0100 Subject: [keycloak-dev] Retrieving client's public IP not working with HTTPS Message-ID: Dear, I get an issue to get the wanted behavior when retrieving the client public IP. This is the situation : (all IP's have been anonymized) - *infrastructure level*: ----------- Reverse Proxy NGINX ----------------------------------- KeyCloak RP is listening on ports 80 & 443 (80 is redirected to 443) There is a public certificate signed by some external CA Nginx redirects to the 8443 (https) of KC (HTTP runs on 8080) Keycloak is set as standalone server on a Wildfly last version - *Nginx config* *server { listen 443; server_name ************; fastcgi_param HTTPS on; location / { add_header X-Cache-Status $upstream_cache_status; add_header X-Real-IP $remote_addr; add_header X-Forwarded-For $remote_addr; add_header X-Forwarded-Proto $scheme; more_set_headers 'Server: ******'; more_clear_headers 'X-Powered-By'; charset UTF-8; proxy_cache ******_cache; proxy_pass https://1.1.1.1:8443/ ; }* * ssl on; ssl_certificate /etc/ssl/private/**********.crt; ssl_certificate_key /etc/ssl/private/*************.key; ssl_prefer_server_ciphers on; ssl_dhparam /etc/ssl/***********.pem; ssl_protocols TLSv1.1 TLSv1.2; ssl_stapling on; ssl_session_cache builtin:1000 shared:SSL:10m; add_header Strict-Transport-Security "max-age=63072000; includeSubdomains; preload"; add_header X-Frame-Options "DENY"; ssl_ciphers 'EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH';* - *Keycloak config* : * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * The situation is that everything is working fine and smooth EXCEPT ... the fact that under sessions (and moreover for all user activities), the user IP I see is the one of the reverse proxy !! As I put in red in the KC config, this is what should do the trick to use the X-Forwarded-For header value to set the client's IP. 15:07:55,104 WARN [org.keycloak.events] (default task-19) type=REFRESH_TOKEN_ERROR, realmId=***, clientId=account, userId=null, ipAddress=2.2.2.2, (...) When I tried to reach KC on the 8080 (HTTP) listener (so the RP terminates the SSL connection and the one to KC server is made in HTTP), I got a whole bunch of warnings and errors due to HTTP -> HTTPS transport and also a HTTP connection towards the external social identity providers like Google, FB, etc. ... BUT I got at least the real IP as you might see hereunder : 15:09:24,068 WARN [org.keycloak.events] (default task-29) type=LOGIN_ERROR, realmId=*****, clientId=account, userId=null, ipAddress=191.21.133.234, (...) So the situation is that I will only get the "real" IP of the client only if it passes through the HTTP listener of KC which is not what I want as I would prefer getting to the HTTPS listener. I obviously also tried to add the same parameter (*proxy-address-forwarding = "true"*) in the HTTPS listener configuration but then, standalone.sh shows an error and refuses to start : *14:24:30,621 INFO [org.jboss.modules] (main) JBoss Modules version 1.5.1.Final* *14:24:30,821 INFO [org.jboss.msc] (main) JBoss MSC version 1.2.6.Final* *14:24:30,888 INFO [org.jboss.as ] (MSC service thread 1-2) WFLYSRV0049: Keycloak 2.5.0.CR1 (WildFly Core 2.0.10.Final) starting* *14:24:31,597 ERROR [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0055: Caught exception during boot: org.jboss.as.controller.persistence.ConfigurationPersistenceException: WFLYCTL0085: Failed to parse configuration* * at org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:131)* * at org.jboss.as.server.ServerService.boot(ServerService.java:356)* * at org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:299)* * at java.lang.Thread.run(Thread.java:745)* *Caused by: javax.xml.stream.XMLStreamException: ParseError at [row,col]:[380,17]* *Message: WFLYCTL0376: Unexpected attribute 'proxy-address-forwarding' encountered. Valid attributes are: 'socket-binding, worker, buffer-pool, enabled, resolve-peer-address, security-realm, verify-client, enabled-cipher-suites, enabled-protocols, enable-http2, enable-spdy, ssl-session-cache-size, ssl-session-timeout, max-header-size, max-post-size, buffer-pipelined-data, max-parameters, max-headers, max-cookies, allow-encoded-slash, decode-url, url-charset, always-set-keep-alive, max-buffered-request-size, record-request-start-time, allow-equals-in-cookie-value, no-request-timeout, request-parse-timeout, disallowed-methods, tcp-backlog, receive-buffer, send-buffer, tcp-keep-alive, read-timeout, write-timeout, max-connections, secure'* * at org.jboss.as.controller.parsing.ParseUtils.unexpectedAttribute(ParseUtils.java:128)* *requirements* : - Entire solution has to run with SSL (HTTPS) from end to end Did someone already faced that situation ? Thank you for reading this post. Regards, /Olivier From sthorger at redhat.com Mon Jan 9 02:42:37 2017 From: sthorger at redhat.com (Stian Thorgersen) Date: Mon, 9 Jan 2017 08:42:37 +0100 Subject: [keycloak-dev] Info endpoint to simplify debugging proxy config In-Reply-To: References: Message-ID: Maybe, but I don't see any real benefit in doing that. The two serves quite different purposes as well. On 6 January 2017 at 16:21, Marek Posolda wrote: > +1 > > I wonder if it's cleaner that we also add existing stuff in > ServerInfoAdminResource to this SPI? > > One minor thing, it seems there is not handling of preflight OPTIONS > request in your new endpoint? > > Marek > > > On 06/01/17 09:31, Stian Thorgersen wrote: > >> I've been looking at some issues with reverse proxy when Keycloak is >> installed on EAP 7.0.3+ [1]. While doing so I found out that it's fairly >> inconvenient and not straightforward to debug if the proxy configuration >> is >> correct. >> >> To verify URLs you have to for example open the well-known endpoint for >> OIDC. Then you have to verify the remote IP address by doing a failed >> login >> attempt and looking at the server log. >> >> To make this simpler I propose adding the start of a server info endpoint. >> It will be a SPI that allows plugging in server info providers that can >> show different details if authenticated or not. >> >> You can either view info for all providers at a time with >> "/realms/master/.info" or for a specific provider >> "/realms/master/.info/proxy". >> >> The proxy info provider will display: >> >> { >> "authServerUrl" : "http://host1/auth", >> "remoteAddress" : "127.0.0.1", >> "proxyDetected" : true, >> "headers" : { >> "Host" : "host1", >> "X-Forwarded-For" : "1.2.3.4", >> "X-Forwarded-Host" : "host2", >> "X-Forwarded-Proto" : "https" >> } >> } >> >> Implementation is ready [2] I just need to get feedback and add tests. >> >> In the future we can expand on this to for instance provide a health >> monitoring endpoint that allows checking the server health (JPA >> connections, Infinispan connections, IdP connections, user fed >> connections, >> etc.). >> >> [1] https://issues.jboss.org/browse/KEYCLOAK-4149 >> [2] >> https://github.com/stianst/keycloak/commit/99abbc47c49585d1e >> 62c74f3ea227e05b22c23a8 >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> > > > From sthorger at redhat.com Mon Jan 9 02:44:06 2017 From: sthorger at redhat.com (Stian Thorgersen) Date: Mon, 9 Jan 2017 08:44:06 +0100 Subject: [keycloak-dev] Allow bearer-only cilents to have service accounts In-Reply-To: <3d0d43a9-0d63-aa2c-8e66-829019c9205f@redhat.com> References: <3d0d43a9-0d63-aa2c-8e66-829019c9205f@redhat.com> Message-ID: Set fix version on the issue to 3.0.0.CR1. It's not critical now, but we should do it. On 6 January 2017 at 16:05, Marek Posolda wrote: > On 04/01/17 06:46, Stian Thorgersen wrote: > >> Currently a bearer-only client can't have a service account and that seems >> like a mistake. Further this prevents bearer-only clients to use the >> authorization services. >> >> Is there any good reasons why bearer-only clients can't have service >> accounts and be able to obtain token using the client credential grant? >> > I assumed that bearer-only client shouldn't be able to have any tokens and > clientSessions, which are dedicated directly to him. It is just REST > service, which "consumes" the access tokens created for other clients. Also > the flag name "Bearer-only" states exactly this. That's the main reason why > I did it that way for service accounts. > > I can't see any big issue with bearer-only client being able to have > service account. There are just few things, which will need to be done > though (eg. tabs "Mappers" and "Scopes" will need to be enabled for > bearer-only clients with enabled service account etc). > > Marek > >> >> The only thing a bearer-only client should be prevented to do IMO is >> authenticate users (authorization code flow and resource owner credential >> grant). >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> > > > From mposolda at redhat.com Mon Jan 9 03:05:14 2017 From: mposolda at redhat.com (Marek Posolda) Date: Mon, 9 Jan 2017 09:05:14 +0100 Subject: [keycloak-dev] Info endpoint to simplify debugging proxy config In-Reply-To: References: Message-ID: Current ServerInfoAdminResource provides information about available providers etc, but also some real-time info about system, CPU, memory etc. Isn't that similar to the health-checks in the new endpoint, which you are proposing? Marek On 09/01/17 08:42, Stian Thorgersen wrote: > Maybe, but I don't see any real benefit in doing that. The two serves > quite different purposes as well. > > On 6 January 2017 at 16:21, Marek Posolda > wrote: > > +1 > > I wonder if it's cleaner that we also add existing stuff in > ServerInfoAdminResource to this SPI? > > One minor thing, it seems there is not handling of preflight > OPTIONS request in your new endpoint? > > Marek > > > On 06/01/17 09:31, Stian Thorgersen wrote: > > I've been looking at some issues with reverse proxy when > Keycloak is > installed on EAP 7.0.3+ [1]. While doing so I found out that > it's fairly > inconvenient and not straightforward to debug if the proxy > configuration is > correct. > > To verify URLs you have to for example open the well-known > endpoint for > OIDC. Then you have to verify the remote IP address by doing a > failed login > attempt and looking at the server log. > > To make this simpler I propose adding the start of a server > info endpoint. > It will be a SPI that allows plugging in server info providers > that can > show different details if authenticated or not. > > You can either view info for all providers at a time with > "/realms/master/.info" or for a specific provider > "/realms/master/.info/proxy". > > The proxy info provider will display: > > { > "authServerUrl" : "http://host1/auth", > "remoteAddress" : "127.0.0.1", > "proxyDetected" : true, > "headers" : { > "Host" : "host1", > "X-Forwarded-For" : "1.2.3.4", > "X-Forwarded-Host" : "host2", > "X-Forwarded-Proto" : "https" > } > } > > Implementation is ready [2] I just need to get feedback and > add tests. > > In the future we can expand on this to for instance provide a > health > monitoring endpoint that allows checking the server health (JPA > connections, Infinispan connections, IdP connections, user fed > connections, > etc.). > > [1] https://issues.jboss.org/browse/KEYCLOAK-4149 > > [2] > https://github.com/stianst/keycloak/commit/99abbc47c49585d1e62c74f3ea227e05b22c23a8 > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > > > From sthorger at redhat.com Mon Jan 9 04:41:42 2017 From: sthorger at redhat.com (Stian Thorgersen) Date: Mon, 9 Jan 2017 10:41:42 +0100 Subject: [keycloak-dev] Info endpoint to simplify debugging proxy config In-Reply-To: References: Message-ID: True, didn't consider that part. The real-time info should probably be moved to the info endpoint, while the list/details about providers kept at ServerInfoAdminResource. On 9 January 2017 at 09:05, Marek Posolda wrote: > Current ServerInfoAdminResource provides information about available > providers etc, but also some real-time info about system, CPU, memory etc. > Isn't that similar to the health-checks in the new endpoint, which you are > proposing? > > Marek > > > On 09/01/17 08:42, Stian Thorgersen wrote: > > Maybe, but I don't see any real benefit in doing that. The two serves > quite different purposes as well. > > On 6 January 2017 at 16:21, Marek Posolda wrote: > >> +1 >> >> I wonder if it's cleaner that we also add existing stuff in >> ServerInfoAdminResource to this SPI? >> >> One minor thing, it seems there is not handling of preflight OPTIONS >> request in your new endpoint? >> >> Marek >> >> >> On 06/01/17 09:31, Stian Thorgersen wrote: >> >>> I've been looking at some issues with reverse proxy when Keycloak is >>> installed on EAP 7.0.3+ [1]. While doing so I found out that it's fairly >>> inconvenient and not straightforward to debug if the proxy configuration >>> is >>> correct. >>> >>> To verify URLs you have to for example open the well-known endpoint for >>> OIDC. Then you have to verify the remote IP address by doing a failed >>> login >>> attempt and looking at the server log. >>> >>> To make this simpler I propose adding the start of a server info >>> endpoint. >>> It will be a SPI that allows plugging in server info providers that can >>> show different details if authenticated or not. >>> >>> You can either view info for all providers at a time with >>> "/realms/master/.info" or for a specific provider >>> "/realms/master/.info/proxy". >>> >>> The proxy info provider will display: >>> >>> { >>> "authServerUrl" : "http://host1/auth", >>> "remoteAddress" : "127.0.0.1", >>> "proxyDetected" : true, >>> "headers" : { >>> "Host" : "host1", >>> "X-Forwarded-For" : "1.2.3.4", >>> "X-Forwarded-Host" : "host2", >>> "X-Forwarded-Proto" : "https" >>> } >>> } >>> >>> Implementation is ready [2] I just need to get feedback and add tests. >>> >>> In the future we can expand on this to for instance provide a health >>> monitoring endpoint that allows checking the server health (JPA >>> connections, Infinispan connections, IdP connections, user fed >>> connections, >>> etc.). >>> >>> [1] https://issues.jboss.org/browse/KEYCLOAK-4149 >>> [2] >>> https://github.com/stianst/keycloak/commit/99abbc47c49585d1e >>> 62c74f3ea227e05b22c23a8 >>> _______________________________________________ >>> keycloak-dev mailing list >>> keycloak-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>> >> >> >> > > From mposolda at redhat.com Mon Jan 9 04:53:07 2017 From: mposolda at redhat.com (Marek Posolda) Date: Mon, 9 Jan 2017 10:53:07 +0100 Subject: [keycloak-dev] Info endpoint to simplify debugging proxy config In-Reply-To: References: Message-ID: <0675da35-19cc-6f34-507d-e1d66cbba974@redhat.com> +1 Marek On 09/01/17 10:41, Stian Thorgersen wrote: > True, didn't consider that part. The real-time info should probably be > moved to the info endpoint, while the list/details about providers > kept at ServerInfoAdminResource. > > On 9 January 2017 at 09:05, Marek Posolda > wrote: > > Current ServerInfoAdminResource provides information about > available providers etc, but also some real-time info about > system, CPU, memory etc. Isn't that similar to the health-checks > in the new endpoint, which you are proposing? > > Marek > > > On 09/01/17 08:42, Stian Thorgersen wrote: >> Maybe, but I don't see any real benefit in doing that. The two >> serves quite different purposes as well. >> >> On 6 January 2017 at 16:21, Marek Posolda > > wrote: >> >> +1 >> >> I wonder if it's cleaner that we also add existing stuff in >> ServerInfoAdminResource to this SPI? >> >> One minor thing, it seems there is not handling of preflight >> OPTIONS request in your new endpoint? >> >> Marek >> >> >> On 06/01/17 09:31, Stian Thorgersen wrote: >> >> I've been looking at some issues with reverse proxy when >> Keycloak is >> installed on EAP 7.0.3+ [1]. While doing so I found out >> that it's fairly >> inconvenient and not straightforward to debug if the >> proxy configuration is >> correct. >> >> To verify URLs you have to for example open the >> well-known endpoint for >> OIDC. Then you have to verify the remote IP address by >> doing a failed login >> attempt and looking at the server log. >> >> To make this simpler I propose adding the start of a >> server info endpoint. >> It will be a SPI that allows plugging in server info >> providers that can >> show different details if authenticated or not. >> >> You can either view info for all providers at a time with >> "/realms/master/.info" or for a specific provider >> "/realms/master/.info/proxy". >> >> The proxy info provider will display: >> >> { >> "authServerUrl" : "http://host1/auth", >> "remoteAddress" : "127.0.0.1", >> "proxyDetected" : true, >> "headers" : { >> "Host" : "host1", >> "X-Forwarded-For" : "1.2.3.4", >> "X-Forwarded-Host" : "host2", >> "X-Forwarded-Proto" : "https" >> } >> } >> >> Implementation is ready [2] I just need to get feedback >> and add tests. >> >> In the future we can expand on this to for instance >> provide a health >> monitoring endpoint that allows checking the server >> health (JPA >> connections, Infinispan connections, IdP connections, >> user fed connections, >> etc.). >> >> [1] https://issues.jboss.org/browse/KEYCLOAK-4149 >> >> [2] >> https://github.com/stianst/keycloak/commit/99abbc47c49585d1e62c74f3ea227e05b22c23a8 >> >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev at lists.jboss.org >> >> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> >> >> >> >> > > From ronyjoy at gmail.com Mon Jan 9 14:01:57 2017 From: ronyjoy at gmail.com (rony joy) Date: Mon, 09 Jan 2017 19:01:57 +0000 Subject: [keycloak-dev] Customizing error Pages(for example client log) Message-ID: Hi All, We are trying to customize the error pages based on the realm id. We are able to do the basic modification by extending the error pages in our custom theme. But in our error pages we wanted the have more realm specific customization(for example customer logo) by fetching the logo from external services based on the realm Id. Currently we don't see a way by looking at the code. Any help is appreciated Thanks Rony Joy From mitya at cargosoft.ru Mon Jan 9 16:05:21 2017 From: mitya at cargosoft.ru (Dmitry Telegin) Date: Tue, 10 Jan 2017 00:05:21 +0300 Subject: [keycloak-dev] Support for themes in the new deployer Message-ID: <1483995921.13694.11.camel@cargosoft.ru> Hi, The new provider deployer is incredibly cool! But could this approach be extended to themes, so that they'd be deployed from the same archive? As of 2.5.0, the preferred way to deploy providers is via the "deployments" directory. But let's imagine a complete Keycloak extension that comprises several providers and a GUI theme. ATM, there are three deployment options: - old school: package everything into a JAR and deploy it as a module; - package providers and themes separately, deploy the former via the new mechanism and the latter as a module; - package everything into a single JAR and deploy via the new mechanism. This dynamically deployed module, according to JBoss/WildFly conventions, will be named "deployment.my-module-XYZ.jar"; use this name in the main config to load theme from the module. This is hacky and requires restart, which renders unusable the whole idea of hot (re)deployment. However, there could be another option, more natural and simple one, that is to automatically deploy providers *and* themes from the same archive placed into the "deployments" directory. What do you think? Cheers, Dmitry From sven.thoms at gmail.com Mon Jan 9 17:43:56 2017 From: sven.thoms at gmail.com (Sven Thoms) Date: Mon, 9 Jan 2017 23:43:56 +0100 Subject: [keycloak-dev] Default identity provider for brokering In-Reply-To: References: Message-ID: Is there a REST endpoint for setting the default, already set identity provider at Authentication - Authentication Flows - Browser - Identity Provider Redirector - Default Identity Provider? From sthorger at redhat.com Mon Jan 9 23:59:27 2017 From: sthorger at redhat.com (Stian Thorgersen) Date: Tue, 10 Jan 2017 05:59:27 +0100 Subject: [keycloak-dev] Default identity provider for brokering In-Reply-To: References: Message-ID: Please use the user mailing list for general questions. This list is to discuss development of Keycloak. On 9 January 2017 at 23:43, Sven Thoms wrote: > Is there a REST endpoint for setting the default, already set identity > provider at > > Authentication - Authentication Flows - Browser - Identity Provider > Redirector - Default Identity Provider? > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > From sthorger at redhat.com Tue Jan 10 00:02:42 2017 From: sthorger at redhat.com (Stian Thorgersen) Date: Tue, 10 Jan 2017 06:02:42 +0100 Subject: [keycloak-dev] Support for themes in the new deployer In-Reply-To: <1483995921.13694.11.camel@cargosoft.ru> References: <1483995921.13694.11.camel@cargosoft.ru> Message-ID: +1 It should be fairly simple to achieve as we have support for pluggable theme providers ( https://github.com/keycloak/keycloak/blob/master/server-spi-private/src/main/java/org/keycloak/theme/ThemeProvider.java ). On 9 January 2017 at 22:05, Dmitry Telegin wrote: > Hi, > > The new provider deployer is incredibly cool! But could this approach > be extended to themes, so that they'd be deployed from the same > archive? > > As of 2.5.0, the preferred way to deploy providers is via the > "deployments" directory. But let's imagine a complete Keycloak > extension that comprises several providers and a GUI theme. ATM, there > are three deployment options: > - old school: package everything into a JAR and deploy it as a module; > - package providers and themes separately, deploy the former via the > new mechanism and the latter as a module; > - package everything into a single JAR and deploy via the new > mechanism. This dynamically deployed module, according to JBoss/WildFly > conventions, will be named "deployment.my-module-XYZ.jar"; use this > name in the main config to load theme from the module. This is hacky > and requires restart, which renders unusable the whole idea of hot > (re)deployment. > > However, there could be another option, more natural and simple one, > that is to automatically deploy providers *and* themes from the same > archive placed into the "deployments" directory. What do you think? > > Cheers, > Dmitry > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > From sthorger at redhat.com Tue Jan 10 00:03:09 2017 From: sthorger at redhat.com (Stian Thorgersen) Date: Tue, 10 Jan 2017 06:03:09 +0100 Subject: [keycloak-dev] Customizing error Pages(for example client log) In-Reply-To: References: Message-ID: Please use the user mailing list for general questions. This list is to discuss development of Keycloak. On 9 January 2017 at 20:01, rony joy wrote: > Hi All, > > We are trying to customize the error pages based on the realm id. We are > able to do the basic modification by extending the error pages in our > custom theme. But in our error pages we wanted the have more realm specific > customization(for example customer logo) by fetching the logo from external > services based on the realm Id. > > Currently we don't see a way by looking at the code. Any help is > appreciated > > Thanks > Rony Joy > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > From sthorger at redhat.com Tue Jan 10 00:03:24 2017 From: sthorger at redhat.com (Stian Thorgersen) Date: Tue, 10 Jan 2017 06:03:24 +0100 Subject: [keycloak-dev] Retrieving client's public IP not working with HTTPS In-Reply-To: References: Message-ID: Please use the user mailing list for general questions. This list is to discuss development of Keycloak. On 6 January 2017 at 16:22, Olivier Bruylandt wrote: > Dear, > > > I get an issue to get the wanted behavior when retrieving the client public > IP. > This is the situation : > (all IP's have been anonymized) > > > > - *infrastructure level*: > > ----------- Reverse Proxy NGINX ----------------------------------- > KeyCloak > > RP is listening on ports 80 & 443 (80 is redirected to 443) > There is a public certificate signed by some external CA > Nginx redirects to the 8443 (https) of KC (HTTP runs on 8080) > Keycloak is set as standalone server on a Wildfly last version > > > > > - *Nginx config* > > > > > > > > > > > > > > > > > > > *server { listen 443; server_name ************; > fastcgi_param HTTPS on; location / { add_header > X-Cache-Status $upstream_cache_status; add_header X-Real-IP > $remote_addr; add_header X-Forwarded-For $remote_addr; > add_header X-Forwarded-Proto $scheme; > more_set_headers 'Server: ******'; more_clear_headers > 'X-Powered-By'; charset UTF-8; proxy_cache > ******_cache; proxy_pass https://1.1.1.1:8443/ > ; }* > > > > > > > > > > > > > * ssl on; ssl_certificate /etc/ssl/private/**********.crt; > ssl_certificate_key /etc/ssl/private/*************.key; > ssl_prefer_server_ciphers on; ssl_dhparam /etc/ssl/***********.pem; > ssl_protocols TLSv1.1 TLSv1.2; ssl_stapling on; > ssl_session_cache builtin:1000 shared:SSL:10m; add_header > Strict-Transport-Security "max-age=63072000; includeSubdomains; preload"; > add_header X-Frame-Options "DENY"; ssl_ciphers > 'EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH';* > > > > > - *Keycloak config* : > > > * * > * * > * * > > * proxy-address-forwarding="true" socket-binding="http"/>* > * socket-binding="https"/>* > * * > * * > * * > * * > * * > * * > * * > * * > * * > * path="${jboss.home.dir}/welcome-content"/>* > * * > * * > > > > > > > > The situation is that everything is working fine and smooth EXCEPT ... the > fact that under sessions (and moreover for all user activities), the user > IP I see is the one of the reverse proxy !! > As I put in red in the KC config, this is what should do the trick to use > the X-Forwarded-For header value to set the client's IP. > > 15:07:55,104 WARN [org.keycloak.events] (default task-19) > type=REFRESH_TOKEN_ERROR, realmId=***, clientId=account, userId=null, > ipAddress=2.2.2.2, (...) > > > > When I tried to reach KC on the 8080 (HTTP) listener (so the RP terminates > the SSL connection and the one to KC server is made in HTTP), I got a whole > bunch of warnings and errors due to HTTP -> HTTPS transport and also a HTTP > connection towards the external social identity providers like Google, FB, > etc. ... BUT I got at least the real IP as you might see hereunder : > > 15:09:24,068 WARN [org.keycloak.events] (default task-29) > type=LOGIN_ERROR, realmId=*****, clientId=account, userId=null, > ipAddress=191.21.133.234, (...) > > > > > > So the situation is that I will only get the "real" IP of the client only > if it passes through the HTTP listener of KC which is not what I want as I > would prefer getting to the HTTPS listener. > I obviously also tried to add the same parameter (*proxy-address-forwarding > = "true"*) in the HTTPS listener configuration but then, standalone.sh > shows an error and refuses to start : > > > *14:24:30,621 INFO [org.jboss.modules] (main) JBoss Modules version > 1.5.1.Final* > *14:24:30,821 INFO [org.jboss.msc] (main) JBoss MSC version 1.2.6.Final* > *14:24:30,888 INFO [org.jboss.as ] (MSC service > thread 1-2) WFLYSRV0049: Keycloak 2.5.0.CR1 (WildFly Core 2.0.10.Final) > starting* > *14:24:31,597 ERROR [org.jboss.as.server] (Controller Boot Thread) > WFLYSRV0055: Caught exception during boot: > org.jboss.as.controller.persistence.ConfigurationPersistenceException: > WFLYCTL0085: Failed to parse configuration* > * at > org.jboss.as.controller.persistence.XmlConfigurationPersister.load( > XmlConfigurationPersister.java:131)* > * at org.jboss.as.server.ServerService.boot(ServerService.java:356)* > * at > org.jboss.as.controller.AbstractControllerService$1. > run(AbstractControllerService.java:299)* > * at java.lang.Thread.run(Thread.java:745)* > *Caused by: javax.xml.stream.XMLStreamException: ParseError at > [row,col]:[380,17]* > *Message: WFLYCTL0376: Unexpected attribute 'proxy-address-forwarding' > encountered. Valid attributes are: 'socket-binding, worker, buffer-pool, > enabled, resolve-peer-address, security-realm, verify-client, > enabled-cipher-suites, enabled-protocols, enable-http2, enable-spdy, > ssl-session-cache-size, ssl-session-timeout, max-header-size, > max-post-size, buffer-pipelined-data, max-parameters, max-headers, > max-cookies, allow-encoded-slash, decode-url, url-charset, > always-set-keep-alive, max-buffered-request-size, > record-request-start-time, allow-equals-in-cookie-value, > no-request-timeout, request-parse-timeout, disallowed-methods, tcp-backlog, > receive-buffer, send-buffer, tcp-keep-alive, read-timeout, write-timeout, > max-connections, secure'* > * at > org.jboss.as.controller.parsing.ParseUtils.unexpectedAttribute( > ParseUtils.java:128)* > > > > > > *requirements* : > > - Entire solution has to run with SSL (HTTPS) from end to end > > > > Did someone already faced that situation ? > Thank you for reading this post. > > Regards, > > > /Olivier > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > From sven.thoms at gmail.com Tue Jan 10 01:32:55 2017 From: sven.thoms at gmail.com (Sven Thoms) Date: Tue, 10 Jan 2017 07:32:55 +0100 Subject: [keycloak-dev] Service Account enable for clients In-Reply-To: References: Message-ID: Is it possible via a setting to automatically enable clients registered dynamically via the well-known registration endpoint and registration access token? My current approach is to iterate over all clients post - creation and set serviceaccountsEnabled to true. I need a more prompt and real-time way From sblanc at redhat.com Tue Jan 10 01:45:04 2017 From: sblanc at redhat.com (Sebastien Blanc) Date: Tue, 10 Jan 2017 06:45:04 +0000 Subject: [keycloak-dev] Support for themes in the new deployer In-Reply-To: References: <1483995921.13694.11.camel@cargosoft.ru> Message-ID: Yes that would be great and would be nice if we could also drop just a 'standalone' theme (not bundled with a provider) zip into the deployment folder Le mar. 10 janv. 2017 ? 06:09, Stian Thorgersen a ?crit : > +1 > > > > It should be fairly simple to achieve as we have support for pluggable > > theme providers ( > > > https://github.com/keycloak/keycloak/blob/master/server-spi-private/src/main/java/org/keycloak/theme/ThemeProvider.java > > ). > > > > On 9 January 2017 at 22:05, Dmitry Telegin wrote: > > > > > Hi, > > > > > > The new provider deployer is incredibly cool! But could this approach > > > be extended to themes, so that they'd be deployed from the same > > > archive? > > > > > > As of 2.5.0, the preferred way to deploy providers is via the > > > "deployments" directory. But let's imagine a complete Keycloak > > > extension that comprises several providers and a GUI theme. ATM, there > > > are three deployment options: > > > - old school: package everything into a JAR and deploy it as a module; > > > - package providers and themes separately, deploy the former via the > > > new mechanism and the latter as a module; > > > - package everything into a single JAR and deploy via the new > > > mechanism. This dynamically deployed module, according to JBoss/WildFly > > > conventions, will be named "deployment.my-module-XYZ.jar"; use this > > > name in the main config to load theme from the module. This is hacky > > > and requires restart, which renders unusable the whole idea of hot > > > (re)deployment. > > > > > > However, there could be another option, more natural and simple one, > > > that is to automatically deploy providers *and* themes from the same > > > archive placed into the "deployments" directory. What do you think? > > > > > > Cheers, > > > Dmitry > > > _______________________________________________ > > > keycloak-dev mailing list > > > keycloak-dev at lists.jboss.org > > > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > > > _______________________________________________ > > keycloak-dev mailing list > > keycloak-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > From sthorger at redhat.com Tue Jan 10 01:55:38 2017 From: sthorger at redhat.com (Stian Thorgersen) Date: Tue, 10 Jan 2017 07:55:38 +0100 Subject: [keycloak-dev] Service Account enable for clients In-Reply-To: References: Message-ID: Please use the user mailing list for general questions. This list is to discuss development of Keycloak. On 10 January 2017 at 07:32, Sven Thoms wrote: > Is it possible via a setting to automatically enable clients registered > dynamically via the well-known registration endpoint and registration > access token? My current approach is to iterate over all clients post - > creation and set serviceaccountsEnabled to true. I need a more prompt and > real-time way > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > From jlpettersson at gmail.com Tue Jan 10 04:50:32 2017 From: jlpettersson at gmail.com (Jonas Pettersson) Date: Tue, 10 Jan 2017 10:50:32 +0100 Subject: [keycloak-dev] Keycloak 2.5.0.Final Released Message-ID: Hi, will the Java library artifacts for this version be uploaded to Maven central? https://mvnrepository.com/artifact/org.keycloak /Jonas From mposolda at redhat.com Tue Jan 10 07:50:28 2017 From: mposolda at redhat.com (Marek Posolda) Date: Tue, 10 Jan 2017 13:50:28 +0100 Subject: [keycloak-dev] Community driven documentation for unsupported LDAP vendors Message-ID: We support and test just with few known LDAP server vendors. However there are lots of questions from the community related to other various LDAP servers (eg. MSAD LDS, Samba4 AD, Novell eDirectory). There are also some community contributions. For example we have the user, who did the integration with MSAD LDS and he contributed the MSADLDSUserAccountControlStorageMapper for that. I was thinking whether it's good to have community-driven documentation with the notes about how to integrate with various external LDAP servers. We will just add the sub-chapter like "LDAP server vendors specific configurations" to our LDAP documentation. At the beginning, we will add the Warning paragraph with the text like: "These LDAP servers are not tested and officially supported by the Keycloak team. It is all driven by the community. So be aware that provided informations are not guaranteed to be 100% up-to-date." And then paragraphs with the needed steps how to configure LDAP StorageProvider and mappers when you want to integrate with the particular LDAP vendor. For example something like this for MSAD LDS: https://issues.jboss.org/browse/KEYCLOAK-4009?focusedCommentId=13333341&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-13333341 Marek From sthorger at redhat.com Tue Jan 10 07:50:47 2017 From: sthorger at redhat.com (Stian Thorgersen) Date: Tue, 10 Jan 2017 13:50:47 +0100 Subject: [keycloak-dev] Keycloak 2.5.0.Final Released In-Reply-To: References: Message-ID: The are in Central: https://search.maven.org/#search%7Cgav%7C1%7Cg%3A%22org.keycloak%22%20AND%20a%3A%22keycloak-server-spi%22 I have no idea why they are not showing on https://mvnrepository.com, but that's not central. The search engine for central is http://search.maven.org/. On 10 January 2017 at 10:50, Jonas Pettersson wrote: > Hi, > > will the Java library artifacts for this version be uploaded to Maven > central? https://mvnrepository.com/artifact/org.keycloak > > /Jonas > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > From sthorger at redhat.com Tue Jan 10 09:09:05 2017 From: sthorger at redhat.com (Stian Thorgersen) Date: Tue, 10 Jan 2017 15:09:05 +0100 Subject: [keycloak-dev] Community driven documentation for unsupported LDAP vendors In-Reply-To: References: Message-ID: My only worry would be that we get more and more questions about various LDAP vendors as well as PRs that has to be reviewed. There's also a fair chance that PRs for a vendor we don't support can impact vendors we do support. I'd be happy with adding the section in the docs, but we should be slightly careful about which vendors we list. They should be popular vendors that we imagine we will potentially support at some point, rather than obscure old things only used by a select few. On 10 January 2017 at 13:50, Marek Posolda wrote: > We support and test just with few known LDAP server vendors. However > there are lots of questions from the community related to other various > LDAP servers (eg. MSAD LDS, Samba4 AD, Novell eDirectory). There are > also some community contributions. For example we have the user, who did > the integration with MSAD LDS and he contributed the > MSADLDSUserAccountControlStorageMapper for that. > > I was thinking whether it's good to have community-driven documentation > with the notes about how to integrate with various external LDAP > servers. We will just add the sub-chapter like "LDAP server vendors > specific configurations" to our LDAP documentation. At the beginning, we > will add the Warning paragraph with the text like: > > "These LDAP servers are not tested and officially supported by the > Keycloak team. It is all driven by the community. So be aware that > provided informations are not guaranteed to be 100% up-to-date." > > And then paragraphs with the needed steps how to configure LDAP > StorageProvider and mappers when you want to integrate with the > particular LDAP vendor. For example something like this for MSAD LDS: > https://issues.jboss.org/browse/KEYCLOAK-4009?focusedCommentId=13333341& > page=com.atlassian.jira.plugin.system.issuetabpanels% > 3Acomment-tabpanel#comment-13333341 > > Marek > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > From mposolda at redhat.com Wed Jan 11 04:49:23 2017 From: mposolda at redhat.com (Marek Posolda) Date: Wed, 11 Jan 2017 10:49:23 +0100 Subject: [keycloak-dev] Community driven documentation for unsupported LDAP vendors In-Reply-To: References: Message-ID: <0d4085a5-b49f-9ecc-463d-1aa6c69d646e@redhat.com> I've created https://issues.jboss.org/browse/KEYCLOAK-4186 and preliminary set fix version to 3.0.0 . We can start with adding MSAD LDS and then maybe continue with other vendors asked by more people. We already have questions and also PRs for various vendors. So hopefully this notes in the docs will rather simplify things instead of complicate them even more ;) My take is, that if someone asks for unsupported vendor, we claim: "No sorry. We don't test and support this vendor. You can try to have it working by yourself and then send PR to the docs (and maybe to the main codebase if something like new mapper is needed)" . If it's some obscure old thing, we can just: "No sorry. We don't test and support this vendor. You can try to have it working by yourself " If someone asks that vendor in the docs doesn't work we claim: "No sorry. We don't test and support this vendor. You can try to fix it by yourself and update docs or wait if someone else from community answers you" . I also suppose that we will have nightly builds for the supported LDAP vendors (We already have them in jenkins, but we want to migrate to new testsuite and then hopefully move to Central CI). So in theory, if some community PR breaks some supported vendors, we can immediately identify and revert that change. Marek On 10/01/17 15:09, Stian Thorgersen wrote: > My only worry would be that we get more and more questions about > various LDAP vendors as well as PRs that has to be reviewed. There's > also a fair chance that PRs for a vendor we don't support can impact > vendors we do support. > > I'd be happy with adding the section in the docs, but we should be > slightly careful about which vendors we list. They should be popular > vendors that we imagine we will potentially support at some point, > rather than obscure old things only used by a select few. > > On 10 January 2017 at 13:50, Marek Posolda > wrote: > > We support and test just with few known LDAP server vendors. However > there are lots of questions from the community related to other > various > LDAP servers (eg. MSAD LDS, Samba4 AD, Novell eDirectory). There are > also some community contributions. For example we have the user, > who did > the integration with MSAD LDS and he contributed the > MSADLDSUserAccountControlStorageMapper for that. > > I was thinking whether it's good to have community-driven > documentation > with the notes about how to integrate with various external LDAP > servers. We will just add the sub-chapter like "LDAP server vendors > specific configurations" to our LDAP documentation. At the > beginning, we > will add the Warning paragraph with the text like: > > "These LDAP servers are not tested and officially supported by the > Keycloak team. It is all driven by the community. So be aware that > provided informations are not guaranteed to be 100% up-to-date." > > And then paragraphs with the needed steps how to configure LDAP > StorageProvider and mappers when you want to integrate with the > particular LDAP vendor. For example something like this for MSAD LDS: > https://issues.jboss.org/browse/KEYCLOAK-4009?focusedCommentId=13333341&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-13333341 > > > Marek > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > From mitya at cargosoft.ru Thu Jan 12 18:57:53 2017 From: mitya at cargosoft.ru (Dmitry Telegin) Date: Fri, 13 Jan 2017 02:57:53 +0300 Subject: [keycloak-dev] Support for themes in the new deployer In-Reply-To: References: <1483995921.13694.11.camel@cargosoft.ru> Message-ID: <1484265473.10595.0.camel@cargosoft.ru> Created https://issues.jboss.org/browse/KEYCLOAK-4211 id="-x-evo- selection-start-marker"> > Yes that would be great and would be nice if we ?could also ?drop > just a 'standalone' theme (not bundled with a provider) zip into the > deployment folder? > Le?mar. 10 janv. 2017 ? 06:09, Stian Thorgersen > a ?crit?: > > +1 > > > > > > > > It should be fairly simple to achieve as we have support for > > pluggable > > > > theme providers ( > > > > https://github.com/keycloak/keycloak/blob/master/server-spi-private > > /src/main/java/org/keycloak/theme/ThemeProvider.java > > > > ). > > > > > > > > On 9 January 2017 at 22:05, Dmitry Telegin > > wrote: > > > > > > > > > Hi, > > > > > > > > > > The new provider deployer is incredibly cool! But could this > > approach > > > > > be extended to themes, so that they'd be deployed from the same > > > > > archive? > > > > > > > > > > As of 2.5.0, the preferred way to deploy providers is via the > > > > > "deployments" directory. But let's imagine a complete Keycloak > > > > > extension that comprises several providers and a GUI theme. ATM, > > there > > > > > are three deployment options: > > > > > - old school: package everything into a JAR and deploy it as a > > module; > > > > > - package providers and themes separately, deploy the former via > > the > > > > > new mechanism and the latter as a module; > > > > > - package everything into a single JAR and deploy via the new > > > > > mechanism. This dynamically deployed module, according to > > JBoss/WildFly > > > > > conventions, will be named "deployment.my-module-XYZ.jar"; use > > this > > > > > name in the main config to load theme from the module. This is > > hacky > > > > > and requires restart, which renders unusable the whole idea of > > hot > > > > > (re)deployment. > > > > > > > > > > However, there could be another option, more natural and simple > > one, > > > > > that is to automatically deploy providers *and* themes from the > > same > > > > > archive placed into the "deployments" directory. What do you > > think? > > > > > > > > > > Cheers, > > > > > Dmitry > > > > > _______________________________________________ > > > > > 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 mitya at cargosoft.ru Thu Jan 12 19:05:43 2017 From: mitya at cargosoft.ru (Dmitry Telegin) Date: Fri, 13 Jan 2017 03:05:43 +0300 Subject: [keycloak-dev] Custom login protocol not showing when creating a client Message-ID: <1484265943.10595.2.camel@cargosoft.ru> Hi, I'm working on OpenID 2.0 support for Keycloak - please don't laugh :) it's still used by many enterprise behemoths. I've created and deployed a skeleton of LoginProtocol, but I've found that it wouldn't show in the protocol select box when creating a new client (it does show when editing, though). By some reason the list of protocols is hardcoded into CreateClientCtrl, and the seemingly correct code is commented out. Can we fix that? Cheers, Dmitry From sthorger at redhat.com Fri Jan 13 01:13:04 2017 From: sthorger at redhat.com (Stian Thorgersen) Date: Fri, 13 Jan 2017 07:13:04 +0100 Subject: [keycloak-dev] Custom login protocol not showing when creating a client In-Reply-To: <1484265943.10595.2.camel@cargosoft.ru> References: <1484265943.10595.2.camel@cargosoft.ru> Message-ID: Sure, JIRA it and send a PR ;) On 13 January 2017 at 01:05, Dmitry Telegin wrote: > Hi, > > I'm working on OpenID 2.0 support for Keycloak - please don't laugh :) > it's still used by many enterprise behemoths. I've created and deployed > a skeleton of LoginProtocol, but I've found that it wouldn't show in > the protocol select box when creating a new client (it does show when > editing, though). By some reason the list of protocols is hardcoded > into CreateClientCtrl, and the seemingly correct code is commented out. > Can we fix that? > > Cheers, > Dmitry > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > From mposolda at redhat.com Fri Jan 13 05:45:39 2017 From: mposolda at redhat.com (Marek Posolda) Date: Fri, 13 Jan 2017 11:45:39 +0100 Subject: [keycloak-dev] Migration of old offline tokens Message-ID: <4f73ea00-3c08-8927-4a52-e604108ef844@redhat.com> We have a bug that offline tokens issued in the old release (eg. 1.9.8) don't work after migration into the new release and can't be successfully refreshed. JIRA is https://issues.jboss.org/browse/KEYCLOAK-4140 . Reason is, that old offline token don't have KID in the header, but currently we require KID to be present, so we can lookup correct key. I wonder about possible solutions: 1) If KID is not present in offline token, then just look for the realm active RSA key and use that one for the verification. This is easier and I've sent PR for it now https://github.com/keycloak/keycloak/pull/3752 . However there is one small limitation though, that if admin changes the active realm key, the old offline tokens won't work (even though the old publicKey is still valid, it is just not active). So seems that if we go with this one, we should add a note to the migration guide about this limitation? 2) Iterate over all realm RSA keys and try to verify token with any of them. This won't have the limitation above, but it's more complex though. IMO the limitation is acceptable, considering that it's just about backwards compatibility. So I would rather go with simpler 1. WDYT? Marek From takashi.norimatsu.ws at hitachi.com Fri Jan 13 05:59:19 2017 From: takashi.norimatsu.ws at hitachi.com (=?iso-2022-jp?B?GyRCPmg+Pk40O1YbKEIgLyBOT1JJTUFUU1UbJEIhJBsoQlRBS0FTSEk=?=) Date: Fri, 13 Jan 2017 10:59:19 +0000 Subject: [keycloak-dev] Proposal of RFC7636 (PKCE) support Message-ID: <831D472326678942A9B4BB933AAA103D25F77C0F@GSjpTK1DCembx01.service.hitachi.net> Hello. I've been using keycloak 2.4.0.FINAL. I've implemented codes for RFC 7636 for Proof Key Code Exchange experimentally. (https://tools.ietf.org/html/rfc7636) [Background: Why RFC7636 is necessary] RFC 7636 is important for industries where high level security is required because it can prevent Authorization Code Interception and Substitution attacks for OAuth2.0. For example, it is required for both confidential and public clients in draft specification of Financial API of OpenID foundation. By implementing RFC 7636, keycloak will be used more widely. [Description of the implementation] My implementation is about 90steps for Authorization Server, 90steps for Client(only Servlet-OAuth), both excluded debug log codes in step counts. Please see the detail in below links. * The implementation: https://github.com/keycloak/keycloak/commit/9e3d2d1e5e8c3b30ddc9ccd5083ba18adcb4c564 It is based on 2.4.0.FINAL. Hope we'll refine and rebase it onto master branch for PR if you accept our implementation proposal. * Design document: https://github.com/Hitachi/contributions/wiki/Description-of-RFC7636-for-keycloak * PoC test: I've validated my implementation and found worked well in following scenarios. [1] Flow: Authorization Code Flow Client: RFC 7636 not supported [2] Flow: Authorization Code Flow Client: RFC 7636 supported and operate properly [3] Flow: Authorization Code Flow Client: RFC 7636 supported but operate illegally (send invalid code_verifier to Token Endpoint) For detail of PoC test, please see: https://github.com/Hitachi/contributions/wiki/PoC-Test-Result-of-RFC7636 I am also willing to add tests to community?s testsuites according to the process as described in ?Hacking on Keycloak?. I've known that related ticket had already been issued as KEYCLOAK-2604. https://issues.jboss.org/browse/KEYCLOAK-2604 Would you mind if I contribute this RFC 7636 support to Keycloak related with KEYCLOAK-2604 ticket ? Best Regards Takashi Norimatsu Hitachi, Ltd. From christian.froehlich at agfa.com Fri Jan 13 09:02:40 2017 From: christian.froehlich at agfa.com (Christian Froehlich) Date: Fri, 13 Jan 2017 15:02:40 +0100 Subject: [keycloak-dev] Storage Provider SPI Message-ID: Hi, it seems that the Sync settings for the "periodic full sync" and the "periodic changed user sync" get only active after a restart of the keycloak server. What I did to get the error: I migrate our user federation provider from version 2.3.0.Final to the new storage proivder SPI in version 2.5.0.Final (BTW: Good job! The SPI is better structured and includes a very good documentation at all levels!). My ProviderFactory implements the ImportSynchronization interface to make a periodic sync possible. The manual sync works well when I push the coresponding buttons but the periodic sync is only activated/changed after a restart of the server. Should I create a jira bug? I can't find a matching bug/issue ... Regards Christian From sthorger at redhat.com Fri Jan 13 09:09:52 2017 From: sthorger at redhat.com (Stian Thorgersen) Date: Fri, 13 Jan 2017 15:09:52 +0100 Subject: [keycloak-dev] Migration of old offline tokens In-Reply-To: <4f73ea00-3c08-8927-4a52-e604108ef844@redhat.com> References: <4f73ea00-3c08-8927-4a52-e604108ef844@redhat.com> Message-ID: Option 1 is OK. Another option could be to add a special legacy provider. It would be added during migration together with the rsa provider, but would have a null value for the kid. It would not have an option to make it the active key. This would mean new installations wouldn't be affected and the provider could be removed once all old offline tokens are migrated. We can also deprecate the provider later on. On 13 January 2017 at 11:45, Marek Posolda wrote: > We have a bug that offline tokens issued in the old release (eg. 1.9.8) > don't work after migration into the new release and can't be > successfully refreshed. JIRA is > https://issues.jboss.org/browse/KEYCLOAK-4140 . > > Reason is, that old offline token don't have KID in the header, but > currently we require KID to be present, so we can lookup correct key. I > wonder about possible solutions: > > 1) If KID is not present in offline token, then just look for the realm > active RSA key and use that one for the verification. This is easier and > I've sent PR for it now https://github.com/keycloak/keycloak/pull/3752 . > However there is one small limitation though, that if admin changes the > active realm key, the old offline tokens won't work (even though the old > publicKey is still valid, it is just not active). So seems that if we go > with this one, we should add a note to the migration guide about this > limitation? > > 2) Iterate over all realm RSA keys and try to verify token with any of > them. This won't have the limitation above, but it's more complex though. > > IMO the limitation is acceptable, considering that it's just about > backwards compatibility. So I would rather go with simpler 1. WDYT? > > Marek > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > From bburke at redhat.com Fri Jan 13 09:15:13 2017 From: bburke at redhat.com (Bill Burke) Date: Fri, 13 Jan 2017 09:15:13 -0500 Subject: [keycloak-dev] Storage Provider SPI In-Reply-To: References: Message-ID: <886e1106-809a-a7de-092d-5e52691903b4@redhat.com> Yes please, and link it to this email. I'll try to get it in for 2.5.1 as it seems like something that should work. On 1/13/17 9:02 AM, Christian Froehlich wrote: > Hi, > > it seems that the Sync settings for the "periodic full sync" and the > "periodic changed user sync" get only active after a restart of the > keycloak server. > What I did to get the error: > I migrate our user federation provider from version 2.3.0.Final to the new > storage proivder SPI in version 2.5.0.Final (BTW: Good job! The SPI is > better structured and includes a very good documentation at all levels!). > My ProviderFactory implements the ImportSynchronization interface to make > a periodic sync possible. The manual sync works well when I push the > coresponding buttons but the periodic sync is only activated/changed after > a restart of the server. > Should I create a jira bug? I can't find a matching bug/issue ... > > Regards Christian > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev From bburke at redhat.com Fri Jan 13 12:24:24 2017 From: bburke at redhat.com (Bill Burke) Date: Fri, 13 Jan 2017 12:24:24 -0500 Subject: [keycloak-dev] Storage Provider SPI In-Reply-To: <886e1106-809a-a7de-092d-5e52691903b4@redhat.com> References: <886e1106-809a-a7de-092d-5e52691903b4@redhat.com> Message-ID: <2a529251-d058-986b-719c-393ba9603ec0@redhat.com> https://issues.jboss.org/browse/KEYCLOAK-4220 Should be fixed next release. On 1/13/17 9:15 AM, Bill Burke wrote: > Yes please, and link it to this email. I'll try to get it in for 2.5.1 > as it seems like something that should work. > > > On 1/13/17 9:02 AM, Christian Froehlich wrote: >> Hi, >> >> it seems that the Sync settings for the "periodic full sync" and the >> "periodic changed user sync" get only active after a restart of the >> keycloak server. >> What I did to get the error: >> I migrate our user federation provider from version 2.3.0.Final to the new >> storage proivder SPI in version 2.5.0.Final (BTW: Good job! The SPI is >> better structured and includes a very good documentation at all levels!). >> My ProviderFactory implements the ImportSynchronization interface to make >> a periodic sync possible. The manual sync works well when I push the >> coresponding buttons but the periodic sync is only activated/changed after >> a restart of the server. >> Should I create a jira bug? I can't find a matching bug/issue ... >> >> Regards Christian >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev From sthorger at redhat.com Mon Jan 16 03:14:45 2017 From: sthorger at redhat.com (Stian Thorgersen) Date: Mon, 16 Jan 2017 09:14:45 +0100 Subject: [keycloak-dev] Proposal of RFC7636 (PKCE) support In-Reply-To: <831D472326678942A9B4BB933AAA103D25F77C0F@GSjpTK1DCembx01.service.hitachi.net> References: <831D472326678942A9B4BB933AAA103D25F77C0F@GSjpTK1DCembx01.service.hitachi.net> Message-ID: We'd welcome a contribution. Tests would need to be written and added to the new testsuite (testsuite/integration-arquillian). If you are able to send updates to documentation as well that'd be good. On 13 January 2017 at 11:59, ???? / NORIMATSU?TAKASHI < takashi.norimatsu.ws at hitachi.com> wrote: > Hello. > > I've been using keycloak 2.4.0.FINAL. > I've implemented codes for RFC 7636 for Proof Key Code Exchange > experimentally. > (https://tools.ietf.org/html/rfc7636) > > [Background: Why RFC7636 is necessary] > RFC 7636 is important for industries where high level security is > required because it can prevent Authorization Code Interception and > Substitution attacks for OAuth2.0. For example, it is required for both > confidential and public clients in draft specification of Financial API of > OpenID foundation. By implementing RFC 7636, keycloak will be used more > widely. > > [Description of the implementation] > My implementation is about 90steps for Authorization Server, 90steps for > Client(only Servlet-OAuth), both excluded debug log codes in step counts. > Please see the detail in below links. > * The implementation: > https://github.com/keycloak/keycloak/commit/ > 9e3d2d1e5e8c3b30ddc9ccd5083ba18adcb4c564 > It is based on 2.4.0.FINAL. Hope we'll refine and rebase it onto master > branch for PR if you accept our implementation proposal. > * Design document: > https://github.com/Hitachi/contributions/wiki/Description-of-RFC7636-for- > keycloak > * PoC test: > I've validated my implementation and found worked well in following > scenarios. > [1] > Flow: Authorization Code Flow > Client: RFC 7636 not supported > [2] > Flow: Authorization Code Flow > Client: RFC 7636 supported and operate properly > [3] > Flow: Authorization Code Flow > Client: RFC 7636 supported but operate illegally > (send invalid code_verifier to Token Endpoint) > For detail of PoC test, please see: > https://github.com/Hitachi/contributions/wiki/PoC-Test-Result-of-RFC7636 > > I am also willing to add tests to community?s testsuites according to the > process as described in ?Hacking on Keycloak?. > > I've known that related ticket had already been issued as KEYCLOAK-2604. > https://issues.jboss.org/browse/KEYCLOAK-2604 > > Would you mind if I contribute this RFC 7636 support to Keycloak related > with KEYCLOAK-2604 ticket ? > > Best Regards > Takashi Norimatsu > Hitachi, Ltd. > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > From mposolda at redhat.com Mon Jan 16 04:31:37 2017 From: mposolda at redhat.com (Marek Posolda) Date: Mon, 16 Jan 2017 10:31:37 +0100 Subject: [keycloak-dev] Migration of old offline tokens In-Reply-To: References: <4f73ea00-3c08-8927-4a52-e604108ef844@redhat.com> Message-ID: Yeah, the legacy provider seems to be cleaner solution, but indeed more work :) I will try to see if I have time to do it as I have some other JIRAs related to LDAP and I would like to look at least to KEYCLOAK-2333 . Marek On 13/01/17 15:09, Stian Thorgersen wrote: > Option 1 is OK. > > Another option could be to add a special legacy provider. It would be > added during migration together with the rsa provider, but would have > a null value for the kid. It would not have an option to make it the > active key. This would mean new installations wouldn't be affected and > the provider could be removed once all old offline tokens are > migrated. We can also deprecate the provider later on. > > On 13 January 2017 at 11:45, Marek Posolda > wrote: > > We have a bug that offline tokens issued in the old release (eg. > 1.9.8) > don't work after migration into the new release and can't be > successfully refreshed. JIRA is > https://issues.jboss.org/browse/KEYCLOAK-4140 > . > > Reason is, that old offline token don't have KID in the header, but > currently we require KID to be present, so we can lookup correct > key. I > wonder about possible solutions: > > 1) If KID is not present in offline token, then just look for the > realm > active RSA key and use that one for the verification. This is > easier and > I've sent PR for it now > https://github.com/keycloak/keycloak/pull/3752 > . > However there is one small limitation though, that if admin > changes the > active realm key, the old offline tokens won't work (even though > the old > publicKey is still valid, it is just not active). So seems that if > we go > with this one, we should add a note to the migration guide about this > limitation? > > 2) Iterate over all realm RSA keys and try to verify token with any of > them. This won't have the limitation above, but it's more complex > though. > > IMO the limitation is acceptable, considering that it's just about > backwards compatibility. So I would rather go with simpler 1. WDYT? > > Marek > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > From sblanc at redhat.com Mon Jan 16 06:09:11 2017 From: sblanc at redhat.com (Sebastien Blanc) Date: Mon, 16 Jan 2017 12:09:11 +0100 Subject: [keycloak-dev] Quickstarts on keycloak GH organization Message-ID: Hi ! As you probably know we already have a set of quickstarts in this repo https://github.com/redhat-developer/redhat-sso-quickstarts. With Stian, we decided to mirror this repo into the keycloak organization and this mirror will now be the "leading" repository meaning that all updates/fixes should happen here and will after that be ported back to the redhat-sso-quickstart repo. Some important points : * A cleanup is needed for the keycloak quickstarts, for instance, all occurrences to RH-SSO / EAP needs to be replaced by Keycloak / WildFly. A first PR tackling this is available : https://github.com/keycloak/keycloak-quickstarts/pull/1 , feel free to review it to see if we missed any occurrence. * We also introduced keycloak BOMs for these quickstarts. For now these are only available here : https://github.com/stianst/keycloak/tree/BOMS * For a better User Experience, master will be based on the latest stable Keycloak release and the branch "dev" will be used for new development. * The remaining examples from https://github.com/keycloak/keycloak/tree/master/examples needs to be integrated into this new quickstarts repo. This is probably the biggest task * A PR containing SpringBoot/Spring Security quickstarts will follow today. * The NodeJS quickstart ( https://github.com/redhat-developer/redhat-sso-quickstarts/tree/7.1.x-devel/service-nodejs ) needs to be copied as well to the keycloak repo. We still need to define a "process" to keep KC and RH-SSO quickstarts in sync (full manual, half scripted ... ). If you have any question, feel free to ask. Sebi From takashi.norimatsu.ws at hitachi.com Tue Jan 17 00:38:01 2017 From: takashi.norimatsu.ws at hitachi.com (=?utf-8?B?5LmX5p2+6ZqG5b+XIC8gTk9SSU1BVFNV77yMVEFLQVNISQ==?=) Date: Tue, 17 Jan 2017 05:38:01 +0000 Subject: [keycloak-dev] Proposal of RFC7636 (PKCE) support Message-ID: <831D472326678942A9B4BB933AAA103D25F78054@GSjpTK1DCembx01.service.hitachi.net> Thank you very much. I'm now writing tests for the new testsuite(testsuite/integration-arquillian), refining documents and codes for a PR. After completing these tasks, hopefully in this week, I'd like to post mail to ask you whether I can send a PR. Best Regards Takashi Norimatsu Hitachi, Ltd. > We'd welcome a contribution. > > Tests would need to be written and added to the new testsuite > (testsuite/integration-arquillian). If you are able to send updates to > documentation as well that'd be good. > > On 13 January 2017 at 11:59, ???? / NORIMATSU?TAKASHI < >takashi.norimatsu.ws at hitachi.com> wrote: > >> Hello. >> >> I've been using keycloak 2.4.0.FINAL. >> I've implemented codes for RFC 7636 for Proof Key Code Exchange >> experimentally. >> (https://tools.ietf.org/html/rfc7636) >> >> [Background: Why RFC7636 is necessary] >> RFC 7636 is important for industries where high level security is >> required because it can prevent Authorization Code Interception and >> Substitution attacks for OAuth2.0. For example, it is required for both >> confidential and public clients in draft specification of Financial API of >> OpenID foundation. By implementing RFC 7636, keycloak will be used more >> widely. >> >> [Description of the implementation] >> My implementation is about 90steps for Authorization Server, 90steps for >> Client(only Servlet-OAuth), both excluded debug log codes in step counts. >> Please see the detail in below links. >> * The implementation: >> https://github.com/keycloak/keycloak/commit/ >> 9e3d2d1e5e8c3b30ddc9ccd5083ba18adcb4c564 >> It is based on 2.4.0.FINAL. Hope we'll refine and rebase it onto master >> branch for PR if you accept our implementation proposal. >> * Design document: >> https://github.com/Hitachi/contributions/wiki/Description-of-RFC7636-for- >> keycloak >> * PoC test: >> I've validated my implementation and found worked well in following >> scenarios. >> [1] >> Flow: Authorization Code Flow >> Client: RFC 7636 not supported >> [2] >> Flow: Authorization Code Flow >> Client: RFC 7636 supported and operate properly >> [3] >> Flow: Authorization Code Flow >> Client: RFC 7636 supported but operate illegally >> (send invalid code_verifier to Token Endpoint) >> For detail of PoC test, please see: >> https://github.com/Hitachi/contributions/wiki/PoC-Test-Result-of-RFC7636 >> >> I am also willing to add tests to community?s testsuites according to the >> process as described in ?Hacking on Keycloak?. >> >> I've known that related ticket had already been issued as KEYCLOAK-2604. >> https://issues.jboss.org/browse/KEYCLOAK-2604 >> >> Would you mind if I contribute this RFC 7636 support to Keycloak related >> with KEYCLOAK-2604 ticket ? >> >> Best Regards >> Takashi Norimatsu >> Hitachi, Ltd. >> >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> From sthorger at redhat.com Tue Jan 17 02:38:55 2017 From: sthorger at redhat.com (Stian Thorgersen) Date: Tue, 17 Jan 2017 08:38:55 +0100 Subject: [keycloak-dev] Proposal of RFC7636 (PKCE) support In-Reply-To: <831D472326678942A9B4BB933AAA103D25F78054@GSjpTK1DCembx01.service.hitachi.net> References: <831D472326678942A9B4BB933AAA103D25F78054@GSjpTK1DCembx01.service.hitachi.net> Message-ID: You can send the PR whenever it's ready from your POV and we'll review. FIY we can't accept this until we start on Keycloak 3.x, but that should be fairly soon (sometime in Feb probably). On 17 January 2017 at 06:38, ???? / NORIMATSU?TAKASHI < takashi.norimatsu.ws at hitachi.com> wrote: > Thank you very much. > > I'm now writing tests for the new testsuite(testsuite/integration-arquillian), > refining documents and codes for a PR. > After completing these tasks, hopefully in this week, I'd like to post > mail to ask you whether I can send a PR. > > Best Regards > Takashi Norimatsu > Hitachi, Ltd. > > > We'd welcome a contribution. > > > > Tests would need to be written and added to the new testsuite > > (testsuite/integration-arquillian). If you are able to send updates to > > documentation as well that'd be good. > > > > On 13 January 2017 at 11:59, ???? / NORIMATSU?TAKASHI < > >takashi.norimatsu.ws at hitachi.com> wrote: > > > >> Hello. > >> > >> I've been using keycloak 2.4.0.FINAL. > >> I've implemented codes for RFC 7636 for Proof Key Code Exchange > >> experimentally. > >> (https://tools.ietf.org/html/rfc7636) > >> > >> [Background: Why RFC7636 is necessary] > >> RFC 7636 is important for industries where high level security is > >> required because it can prevent Authorization Code Interception and > >> Substitution attacks for OAuth2.0. For example, it is required for both > >> confidential and public clients in draft specification of Financial API > of > >> OpenID foundation. By implementing RFC 7636, keycloak will be used more > >> widely. > >> > >> [Description of the implementation] > >> My implementation is about 90steps for Authorization Server, 90steps for > >> Client(only Servlet-OAuth), both excluded debug log codes in step > counts. > >> Please see the detail in below links. > >> * The implementation: > >> https://github.com/keycloak/keycloak/commit/ > >> 9e3d2d1e5e8c3b30ddc9ccd5083ba18adcb4c564 > >> It is based on 2.4.0.FINAL. Hope we'll refine and rebase it onto > master > >> branch for PR if you accept our implementation proposal. > >> * Design document: > >> https://github.com/Hitachi/contributions/wiki/ > Description-of-RFC7636-for- > >> keycloak > >> * PoC test: > >> I've validated my implementation and found worked well in following > >> scenarios. > >> [1] > >> Flow: Authorization Code Flow > >> Client: RFC 7636 not supported > >> [2] > >> Flow: Authorization Code Flow > >> Client: RFC 7636 supported and operate properly > >> [3] > >> Flow: Authorization Code Flow > >> Client: RFC 7636 supported but operate illegally > >> (send invalid code_verifier to Token Endpoint) > >> For detail of PoC test, please see: > >> https://github.com/Hitachi/contributions/wiki/PoC-Test- > Result-of-RFC7636 > >> > >> I am also willing to add tests to community?s testsuites according to > the > >> process as described in ?Hacking on Keycloak?. > >> > >> I've known that related ticket had already been issued as KEYCLOAK-2604. > >> https://issues.jboss.org/browse/KEYCLOAK-2604 > >> > >> Would you mind if I contribute this RFC 7636 support to Keycloak related > >> with KEYCLOAK-2604 ticket ? > >> > >> Best Regards > >> Takashi Norimatsu > >> Hitachi, Ltd. > >> > >> _______________________________________________ > >> keycloak-dev mailing list > >> keycloak-dev at lists.jboss.org > >> https://lists.jboss.org/mailman/listinfo/keycloak-dev > >> > > From sthorger at redhat.com Tue Jan 17 02:43:04 2017 From: sthorger at redhat.com (Stian Thorgersen) Date: Tue, 17 Jan 2017 08:43:04 +0100 Subject: [keycloak-dev] Quickstarts on keycloak GH organization In-Reply-To: References: Message-ID: On 16 January 2017 at 12:09, Sebastien Blanc wrote: > Hi ! > > As you probably know we already have a set of quickstarts in this repo > https://github.com/redhat-developer/redhat-sso-quickstarts. > > With Stian, we decided to mirror this repo into the keycloak organization > and this mirror will now be the "leading" repository meaning that all > updates/fixes should happen here and will after that be ported back to the > redhat-sso-quickstart repo. > > Some important points : > > * A cleanup is needed for the keycloak quickstarts, for instance, all > occurrences to RH-SSO / EAP needs to be replaced by Keycloak / WildFly. A > first PR tackling this is available : > https://github.com/keycloak/keycloak-quickstarts/pull/1 , feel free to > review it to see if we missed any occurrence. > I merged this. One comment is that we should just target the latest WildFLy release (10.1) rather than WF 8, 9 and 10. > > * We also introduced keycloak BOMs for these quickstarts. For now these are > only available here : https://github.com/stianst/keycloak/tree/BOMS > > * For a better User Experience, master will be based on the latest stable > Keycloak release and the branch "dev" will be used for new development. > I'll get the release CI to update the master branch whenever a KC release is done. Ideally I'd like to have a single command to run at the root pom to do that. I.e. mvn versions:set. > > * The remaining examples from > https://github.com/keycloak/keycloak/tree/master/examples needs to be > integrated into this new quickstarts repo. This is probably the biggest > task > +1 We'll need to discuss what and how though. Some quickstarts duplicate what we had in examples, while others will be more a straightforward port. > > * A PR containing SpringBoot/Spring Security quickstarts will follow today. > Merged > > * The NodeJS quickstart ( > https://github.com/redhat-developer/redhat-sso- > quickstarts/tree/7.1.x-devel/service-nodejs > ) needs to be copied as well to the keycloak repo. > Merged > > We still need to define a "process" to keep KC and RH-SSO quickstarts in > sync (full manual, half scripted ... ). > Fully automated is the aim! > > If you have any question, feel free to ask. > > Sebi > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > From sblanc at redhat.com Tue Jan 17 03:35:55 2017 From: sblanc at redhat.com (Sebastien Blanc) Date: Tue, 17 Jan 2017 09:35:55 +0100 Subject: [keycloak-dev] Quickstarts on keycloak GH organization In-Reply-To: References: Message-ID: On Tue, Jan 17, 2017 at 8:43 AM, Stian Thorgersen wrote: > > > On 16 January 2017 at 12:09, Sebastien Blanc wrote: > >> Hi ! >> >> As you probably know we already have a set of quickstarts in this repo >> https://github.com/redhat-developer/redhat-sso-quickstarts. >> >> With Stian, we decided to mirror this repo into the keycloak organization >> and this mirror will now be the "leading" repository meaning that all >> updates/fixes should happen here and will after that be ported back to the >> redhat-sso-quickstart repo. >> >> Some important points : >> >> * A cleanup is needed for the keycloak quickstarts, for instance, all >> occurrences to RH-SSO / EAP needs to be replaced by Keycloak / WildFly. A >> first PR tackling this is available : >> https://github.com/keycloak/keycloak-quickstarts/pull/1 , feel free to >> review it to see if we missed any occurrence. >> > > I merged this. One comment is that we should just target the latest > WildFLy release (10.1) rather than WF 8, 9 and 10. > I was wondering about the same while I was updating the READMEs. Actually that will make it easier, I will update the readmes. > > >> >> * We also introduced keycloak BOMs for these quickstarts. For now these >> are >> only available here : https://github.com/stianst/keycloak/tree/BOMS >> >> * For a better User Experience, master will be based on the latest stable >> Keycloak release and the branch "dev" will be used for new development. >> > > I'll get the release CI to update the master branch whenever a KC release > is done. Ideally I'd like to have a single command to run at the root pom > to do that. I.e. mvn versions:set. > Speaking of CI, do we want CI for the quickstarts ? > > >> >> * The remaining examples from >> https://github.com/keycloak/keycloak/tree/master/examples needs to be >> integrated into this new quickstarts repo. This is probably the biggest >> task >> > > +1 We'll need to discuss what and how though. Some quickstarts duplicate > what we had in examples, while others will be more a straightforward port. > I will start a separate thread for that. > > >> >> * A PR containing SpringBoot/Spring Security quickstarts will follow >> today. >> > > Merged > > >> >> * The NodeJS quickstart ( >> https://github.com/redhat-developer/redhat-sso-quickstarts/ >> tree/7.1.x-devel/service-nodejs >> ) needs to be copied as well to the keycloak repo. >> > > Merged > > >> >> We still need to define a "process" to keep KC and RH-SSO quickstarts in >> sync (full manual, half scripted ... ). >> > > Fully automated is the aim! > > >> >> If you have any question, feel free to ask. >> >> Sebi >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> > > From sthorger at redhat.com Tue Jan 17 04:16:56 2017 From: sthorger at redhat.com (Stian Thorgersen) Date: Tue, 17 Jan 2017 10:16:56 +0100 Subject: [keycloak-dev] Quickstarts on keycloak GH organization In-Reply-To: References: Message-ID: On 17 January 2017 at 09:35, Sebastien Blanc wrote: > > > On Tue, Jan 17, 2017 at 8:43 AM, Stian Thorgersen > wrote: > >> >> >> On 16 January 2017 at 12:09, Sebastien Blanc wrote: >> >>> Hi ! >>> >>> As you probably know we already have a set of quickstarts in this repo >>> https://github.com/redhat-developer/redhat-sso-quickstarts. >>> >>> With Stian, we decided to mirror this repo into the keycloak organization >>> and this mirror will now be the "leading" repository meaning that all >>> updates/fixes should happen here and will after that be ported back to >>> the >>> redhat-sso-quickstart repo. >>> >>> Some important points : >>> >>> * A cleanup is needed for the keycloak quickstarts, for instance, all >>> occurrences to RH-SSO / EAP needs to be replaced by Keycloak / WildFly. A >>> first PR tackling this is available : >>> https://github.com/keycloak/keycloak-quickstarts/pull/1 , feel free to >>> review it to see if we missed any occurrence. >>> >> >> I merged this. One comment is that we should just target the latest >> WildFLy release (10.1) rather than WF 8, 9 and 10. >> > I was wondering about the same while I was updating the READMEs. Actually > that will make it easier, I will update the readmes. > >> >> >>> >>> * We also introduced keycloak BOMs for these quickstarts. For now these >>> are >>> only available here : https://github.com/stianst/keycloak/tree/BOMS >>> >>> * For a better User Experience, master will be based on the latest stable >>> Keycloak release and the branch "dev" will be used for new development. >>> >> >> I'll get the release CI to update the master branch whenever a KC release >> is done. Ideally I'd like to have a single command to run at the root pom >> to do that. I.e. mvn versions:set. >> > Speaking of CI, do we want CI for the quickstarts ? > I have a CI job that does the release as it's all automated. Maven, brew, node, openshift, web site, etc.. I don't want to manually update POMs in the quickstarts when doing a KC release. There's separate need to have CI tests for quickstarts. I was hoping whatever we use for testing the quickstarts can also serve as a recommendation to users on how to test their apps secured with Keycloak/RH-SSO. > >> >>> >>> * The remaining examples from >>> https://github.com/keycloak/keycloak/tree/master/examples needs to be >>> integrated into this new quickstarts repo. This is probably the biggest >>> task >>> >> >> +1 We'll need to discuss what and how though. Some quickstarts duplicate >> what we had in examples, while others will be more a straightforward port. >> > I will start a separate thread for that. > >> >> >>> >>> * A PR containing SpringBoot/Spring Security quickstarts will follow >>> today. >>> >> >> Merged >> >> >>> >>> * The NodeJS quickstart ( >>> https://github.com/redhat-developer/redhat-sso-quickstarts/t >>> ree/7.1.x-devel/service-nodejs >>> ) needs to be copied as well to the keycloak repo. >>> >> >> Merged >> >> >>> >>> We still need to define a "process" to keep KC and RH-SSO quickstarts in >>> sync (full manual, half scripted ... ). >>> >> >> Fully automated is the aim! >> >> >>> >>> If you have any question, feel free to ask. >>> >>> Sebi >>> _______________________________________________ >>> keycloak-dev mailing list >>> keycloak-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>> >> >> > From Gideon.Caranzo at gemalto.com Tue Jan 17 18:39:15 2017 From: Gideon.Caranzo at gemalto.com (Caranzo Gideon) Date: Tue, 17 Jan 2017 23:39:15 +0000 Subject: [keycloak-dev] Client Signature Algorithm from SAML Metadata Message-ID: Hi, When creating a client from SAML metadata, should Keycloak use the SignatureMethod from the metadata as Signature Algorithm for the client? I noticed that the Signature Algorithm is always RSA_SHA256 regardless of the algorithm in the metadata file. Is this a bug or it's just the designed behavior? Thanks, Gideon ________________________________ This message and any attachments are intended solely for the addressees and may contain confidential information. Any unauthorized use or disclosure, either whole or partial, is prohibited. E-mails are susceptible to alteration. Our company shall not be liable for the message if altered, changed or falsified. If you are not the intended recipient of this message, please delete it and notify the sender. Although all reasonable efforts have been made to keep this transmission free from viruses, the sender will not be liable for damages caused by a transmitted virus. From hmlnarik at redhat.com Wed Jan 18 04:45:35 2017 From: hmlnarik at redhat.com (Hynek Mlnarik) Date: Wed, 18 Jan 2017 10:45:35 +0100 Subject: [keycloak-dev] Client Signature Algorithm from SAML Metadata In-Reply-To: References: Message-ID: <2a1c0294-c257-a11d-4083-1ee8fb6cbcd2@redhat.com> This is not a bug as SAML metadata standard does not contain specification of client signature algorithm: SignatureMethod is property of the signature of the metadata, not part of the metadata of the client. Keycloak currently always sets RSA_SHA256 to client Signature algorithm. If this is important for your usecase, please file a JIRA feature request and provide details of the usecase. --Hynek On 01/18/2017 12:39 AM, Caranzo Gideon wrote: > Hi, > > When creating a client from SAML metadata, should Keycloak use the SignatureMethod from the metadata as Signature Algorithm for the client? > > I noticed that the Signature Algorithm is always RSA_SHA256 regardless of the algorithm in the metadata file. Is this a bug or it's just the designed behavior? > > Thanks, > Gideon > > ________________________________ > This message and any attachments are intended solely for the addressees and may contain confidential information. Any unauthorized use or disclosure, either whole or partial, is prohibited. > E-mails are susceptible to alteration. Our company shall not be liable for the message if altered, changed or falsified. If you are not the intended recipient of this message, please delete it and notify the sender. > Although all reasonable efforts have been made to keep this transmission free from viruses, the sender will not be liable for damages caused by a transmitted virus. > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > From mitya at cargosoft.ru Wed Jan 18 05:54:02 2017 From: mitya at cargosoft.ru (Dmitry Telegin) Date: Wed, 18 Jan 2017 13:54:02 +0300 Subject: [keycloak-dev] Deploying provider with dependencies Message-ID: <1484736842.3591.1.camel@cargosoft.ru> Hi, It's easy to imagine a provider that would integrate a third party library which, together with transitive dependencies, might result in dozens of JARs. A real-world example: OpenID 2.0 login protocol implementation using openid4java, which in its turn pulls in another 10 JARs. What are the deployment options for configurations like that? Is it really necessary to install each and every dependency as a WildFly module? This could become a PITA if there are a lot of deps. Could it be a single, self-sufficient artifact just to be put into deployments subdir? If yes, what type of artifact it should be (EAR maybe)? Thx, Dmitry From sthorger at redhat.com Wed Jan 18 06:34:17 2017 From: sthorger at redhat.com (Stian Thorgersen) Date: Wed, 18 Jan 2017 12:34:17 +0100 Subject: [keycloak-dev] Deploying provider with dependencies In-Reply-To: <1484736842.3591.1.camel@cargosoft.ru> References: <1484736842.3591.1.camel@cargosoft.ru> Message-ID: You have two options deploy as a module which requires adding modules for all dependencies or using the new deploy as a JEE archive approach, which also supports hot deployment. Check out the server developer guide for more details. On 18 January 2017 at 11:54, Dmitry Telegin wrote: > Hi, > > It's easy to imagine a provider that would integrate a third party > library which, together with transitive dependencies, might result in > dozens of JARs. A real-world example: OpenID 2.0 login protocol > implementation using openid4java, which in its turn pulls in another 10 > JARs. > > What are the deployment options for configurations like that? Is it > really necessary to install each and every dependency as a WildFly > module? This could become a PITA if there are a lot of deps. Could it > be a single, self-sufficient artifact just to be put into deployments > subdir? If yes, what type of artifact it should be (EAR maybe)? > > Thx, > Dmitry > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > From sblanc at redhat.com Wed Jan 18 09:36:10 2017 From: sblanc at redhat.com (Sebastien Blanc) Date: Wed, 18 Jan 2017 15:36:10 +0100 Subject: [keycloak-dev] Migrating Examples to Quickstarts Message-ID: Hi ! We have our new quickstart repo but we still have our "old" examples folder containing a lot of samples (more than 50!). While most of them are relevant, we still need to look if all of them are still relevant. I need the whole team for that. Could anyone point out examples that could be removed or merged with other examples ? Watch out , here is the list : * admin-client * authz : ** hello-world ** hello-world-authz-service ** photoz ** servlet-authz * basic-auth * saml-broker-authentication * cordova * cors : ** angular-product-app ** database-service * fuse : ** camel ** customer-app-fuse ** cxf-jaxrs ** cxf-jaxws ** external-config ** features ** fuse-admin ** product-app-fuse * js-console * kerberos * ldap * multi-tenant * saml : ** post-with-encryption ** post-with-signature ** redirect-with-signature ** servlet-filter * themes * providers : ** authenticator ** domain-extension ** event-listener-sysout ** event-store-mem ** federation-provider ** rest ** user-storage-jpa * preconfigured-demo : ** admin-access-app ** angular2-product-app ** angular-product-app ** customer-app ** customer-app-cli ** customer-app-filter ** customer-app-js ** database-service ** example-ear ** offline-access-app ** product-app ** service-account ** third-party ** third-party-cdi From sthorger at redhat.com Wed Jan 18 10:33:40 2017 From: sthorger at redhat.com (Stian Thorgersen) Date: Wed, 18 Jan 2017 16:33:40 +0100 Subject: [keycloak-dev] Migrating Examples to Quickstarts In-Reply-To: References: Message-ID: Here's my take on it. "demo" bits (everything in demo-template) should be replaced with the new quickstarts format. Some of these are already redundant (service, jsp, html5). Authz - Pedro is working on RHSSO quickstart / migration Fuse - Marek is working on RHSSO quickstart / migration Broker - These needs some updating as they don't work and are not even included in example DL. Not sure how important these are though. The rest I would put at the following priorities: P1: Cordova Themes Cors (maybe the existing quickstarts i.e. services should have explanation on how to configure CORS instead) SAML - maybe they should be updated to follow new quickstart format P2: JS Console Kerberos LDAP Providers Admin client P3: Multi tenant Basic auth On 18 January 2017 at 15:36, Sebastien Blanc wrote: > Hi ! > > We have our new quickstart repo but we still have our "old" examples folder > containing a lot of samples (more than 50!). While most of them are > relevant, we still need to look if all of them are still relevant. I need > the whole team for that. > > Could anyone point out examples that could be removed or merged with other > examples ? > > Watch out , here is the list : > > * admin-client > * authz : > ** hello-world > ** hello-world-authz-service > ** photoz > ** servlet-authz > * basic-auth > * saml-broker-authentication > * cordova > * cors : > ** angular-product-app > ** database-service > * fuse : > ** camel > ** customer-app-fuse > ** cxf-jaxrs > ** cxf-jaxws > ** external-config > ** features > ** fuse-admin > ** product-app-fuse > * js-console > * kerberos > * ldap > * multi-tenant > * saml : > ** post-with-encryption > ** post-with-signature > ** redirect-with-signature > ** servlet-filter > * themes > * providers : > ** authenticator > ** domain-extension > ** event-listener-sysout > ** event-store-mem > ** federation-provider > ** rest > ** user-storage-jpa > * preconfigured-demo : > ** admin-access-app > ** angular2-product-app > ** angular-product-app > ** customer-app > ** customer-app-cli > ** customer-app-filter > ** customer-app-js > ** database-service > ** example-ear > ** offline-access-app > ** product-app > ** service-account > ** third-party > ** third-party-cdi > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > From sthorger at redhat.com Wed Jan 18 10:34:33 2017 From: sthorger at redhat.com (Stian Thorgersen) Date: Wed, 18 Jan 2017 16:34:33 +0100 Subject: [keycloak-dev] Migrating Examples to Quickstarts In-Reply-To: References: Message-ID: Forgot to mention that in addition to the quickstarts we should have a demo bundle. It would replace the "demo" bits as well as the demo distribution. Probably based on Docker images. Something that with one click can get a full blown demo to showcase Keycloak up and running. On 18 January 2017 at 16:33, Stian Thorgersen wrote: > Here's my take on it. > > "demo" bits (everything in demo-template) should be replaced with the new > quickstarts format. Some of these are already redundant (service, jsp, > html5). > > Authz - Pedro is working on RHSSO quickstart / migration > > Fuse - Marek is working on RHSSO quickstart / migration > > Broker - These needs some updating as they don't work and are not even > included in example DL. Not sure how important these are though. > > The rest I would put at the following priorities: > > P1: > Cordova > Themes > Cors (maybe the existing quickstarts i.e. services should have explanation > on how to configure CORS instead) > SAML - maybe they should be updated to follow new quickstart format > > P2: > JS Console > Kerberos > LDAP > Providers > Admin client > > P3: > Multi tenant > Basic auth > > > > On 18 January 2017 at 15:36, Sebastien Blanc wrote: > >> Hi ! >> >> We have our new quickstart repo but we still have our "old" examples >> folder >> containing a lot of samples (more than 50!). While most of them are >> relevant, we still need to look if all of them are still relevant. I need >> the whole team for that. >> >> Could anyone point out examples that could be removed or merged with other >> examples ? >> >> Watch out , here is the list : >> >> * admin-client >> * authz : >> ** hello-world >> ** hello-world-authz-service >> ** photoz >> ** servlet-authz >> * basic-auth >> * saml-broker-authentication >> * cordova >> * cors : >> ** angular-product-app >> ** database-service >> * fuse : >> ** camel >> ** customer-app-fuse >> ** cxf-jaxrs >> ** cxf-jaxws >> ** external-config >> ** features >> ** fuse-admin >> ** product-app-fuse >> * js-console >> * kerberos >> * ldap >> * multi-tenant >> * saml : >> ** post-with-encryption >> ** post-with-signature >> ** redirect-with-signature >> ** servlet-filter >> * themes >> * providers : >> ** authenticator >> ** domain-extension >> ** event-listener-sysout >> ** event-store-mem >> ** federation-provider >> ** rest >> ** user-storage-jpa >> * preconfigured-demo : >> ** admin-access-app >> ** angular2-product-app >> ** angular-product-app >> ** customer-app >> ** customer-app-cli >> ** customer-app-filter >> ** customer-app-js >> ** database-service >> ** example-ear >> ** offline-access-app >> ** product-app >> ** service-account >> ** third-party >> ** third-party-cdi >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> > > From gaalvarez0910 at gmail.com Wed Jan 18 14:15:56 2017 From: gaalvarez0910 at gmail.com (Gustavo Alvarez) Date: Wed, 18 Jan 2017 19:15:56 +0000 Subject: [keycloak-dev] Change language of information in keycloak database Message-ID: Hello everyone. I need to change the language of the data in the keycloak database, for example the list of "password policies" in the Authentication menu, 'Password Policies' tab. I try to change the values of the database, but when I create a new realm, the language in this is English always. Thank you. Gustavo ?lvarez. From mitya at cargosoft.ru Wed Jan 18 15:10:47 2017 From: mitya at cargosoft.ru (Dmitry Telegin) Date: Wed, 18 Jan 2017 23:10:47 +0300 Subject: [keycloak-dev] Deploying provider with dependencies In-Reply-To: References: <1484736842.3591.1.camel@cargosoft.ru> Message-ID: <1484770247.18494.1.camel@cargosoft.ru> Stian, I've tried to package my provider JAR into an EAR, but that didn't work :( The layout is the following: foo-0.1-SNAPSHOT.ear +- foo-provider-0.1-SNAPSHOT.jar +- META-INF +- application.xml When I put the JAR into the deployments subdir, it is deployed successfully, initialization code is called etc. But when I drop the EAR in the same subdir, there is only a successful deployment message. The provider doesn't get initialized; seems like deployer doesn't recurse into EAR contents. Tried to place the JAR into the "lib" subdir inside EAR, this didn't work either. The EAR is generated by maven-ear- plugin with the standard settings. Am I missing something? Sorry for bugging you, but unfortunately there is not much said in the docs about deploying providers from inside EARs. A working example would be helpful as well. Dmitry ? Wed, 18/01/2017 ? 12:34 +0100, Stian Thorgersen ?????: > You have two options deploy as a module which requires adding modules > for all dependencies or using the new deploy as a JEE archive > approach, which also supports hot deployment. Check out the server > developer guide for more details. > > On 18 January 2017 at 11:54, Dmitry Telegin > wrote: > > Hi, > > > > It's easy to imagine a provider that would integrate a third party > > library which, together with transitive dependencies, might result > > in > > dozens of JARs. A real-world example: OpenID 2.0 login protocol > > implementation using openid4java, which in its turn pulls in > > another 10 > > JARs. > > > > What are the deployment options for configurations like that? Is it > > really necessary to install each and every dependency as a WildFly > > module? This could become a PITA if there are a lot of deps. Could > > it > > be a single, self-sufficient artifact just to be put into > > deployments > > subdir? If yes, what type of artifact it should be (EAR maybe)? > > > > Thx, > > Dmitry > > _______________________________________________ > > keycloak-dev mailing list > > keycloak-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > > From mitya at cargosoft.ru Wed Jan 18 16:20:10 2017 From: mitya at cargosoft.ru (Dmitry Telegin) Date: Thu, 19 Jan 2017 00:20:10 +0300 Subject: [keycloak-dev] Deploying provider with dependencies In-Reply-To: <1484770247.18494.1.camel@cargosoft.ru> References: <1484736842.3591.1.camel@cargosoft.ru> <1484770247.18494.1.camel@cargosoft.ru> Message-ID: <1484774410.18494.3.camel@cargosoft.ru> I've finally solved this. There are two moments to pay attention to: - maven-ear-plugin by default generates almost empty application.xml. In order for subdeployment to be recognized, it must be mentioned in application.xml as a module. Both and worked for me; - in JBoss/WildFly, only top-level jboss-deployment-structure.xml files are recognized. Thus, this file should be moved from a JAR to an EAR and tweaked accordingly. This is discussed in detail here: http://stackoverflow.com/questions/26859092/jboss-deployment-structure- xml-does-not-loads-the-dependencies-in-my-ear-project Again, it would be nice to have a complete working example to demonstrate this approach. I think I could (one day) update my BeerCloak example to cover this new deployment technique. Dmitry ? Wed, 18/01/2017 ? 23:10 +0300, Dmitry Telegin ?????: > Stian, > > I've tried to package my provider JAR into an EAR, but that didn't > work > ?:( > > The layout is the following: > > foo-0.1-SNAPSHOT.ear > +- foo-provider-0.1-SNAPSHOT.jar > +- META-INF > ???+- application.xml > > When I put the JAR into the deployments subdir, it is deployed > successfully, initialization code is called etc. But when I drop the > EAR in the same subdir, there is only a successful deployment > message. > The provider doesn't get initialized; seems like deployer doesn't > recurse into EAR contents. Tried to place the JAR into the "lib" > subdir > inside EAR, this didn't work either. The EAR is generated by maven- > ear- > plugin with the standard settings. > > Am I missing something? Sorry for bugging you, but unfortunately > there > is not much said in the docs about deploying providers from inside > EARs. A working example would be helpful as well. > > Dmitry > > ? Wed, 18/01/2017 ? 12:34 +0100, Stian Thorgersen ?????: > > You have two options deploy as a module which requires adding > > modules > > for all dependencies or using the new deploy as a JEE archive > > approach, which also supports hot deployment. Check out the server > > developer guide for more details. > > > > On 18 January 2017 at 11:54, Dmitry Telegin > > wrote: > > > Hi, > > > > > > It's easy to imagine a provider that would integrate a third > > > party > > > library which, together with transitive dependencies, might > > > result > > > in > > > dozens of JARs. A real-world example: OpenID 2.0 login protocol > > > implementation using openid4java, which in its turn pulls in > > > another 10 > > > JARs. > > > > > > What are the deployment options for configurations like that? Is > > > it > > > really necessary to install each and every dependency as a > > > WildFly > > > module? This could become a PITA if there are a lot of deps. > > > Could > > > it > > > be a single, self-sufficient artifact just to be put into > > > deployments > > > subdir? If yes, what type of artifact it should be (EAR maybe)? > > > > > > Thx, > > > Dmitry > > > _______________________________________________ > > > keycloak-dev mailing list > > > keycloak-dev at lists.jboss.org > > > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > > > > > > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev From bruno at abstractj.org Wed Jan 18 21:06:33 2017 From: bruno at abstractj.org (Bruno Oliveira) Date: Thu, 19 Jan 2017 00:06:33 -0200 Subject: [keycloak-dev] Migrating Examples to Quickstarts In-Reply-To: References: Message-ID: <20170119020633.GB8436@abstractj.org> Do you mean something related to this https://issues.jboss.org/browse/KEYCLOAK-3577 ? On 2017-01-18, Stian Thorgersen wrote: > Forgot to mention that in addition to the quickstarts we should have a demo > bundle. It would replace the "demo" bits as well as the demo distribution. > Probably based on Docker images. > > Something that with one click can get a full blown demo to showcase > Keycloak up and running. > > On 18 January 2017 at 16:33, Stian Thorgersen wrote: > > > Here's my take on it. > > > > "demo" bits (everything in demo-template) should be replaced with the new > > quickstarts format. Some of these are already redundant (service, jsp, > > html5). > > > > Authz - Pedro is working on RHSSO quickstart / migration > > > > Fuse - Marek is working on RHSSO quickstart / migration > > > > Broker - These needs some updating as they don't work and are not even > > included in example DL. Not sure how important these are though. > > > > The rest I would put at the following priorities: > > > > P1: > > Cordova > > Themes > > Cors (maybe the existing quickstarts i.e. services should have explanation > > on how to configure CORS instead) > > SAML - maybe they should be updated to follow new quickstart format > > > > P2: > > JS Console > > Kerberos > > LDAP > > Providers > > Admin client > > > > P3: > > Multi tenant > > Basic auth > > > > > > > > On 18 January 2017 at 15:36, Sebastien Blanc wrote: > > > >> Hi ! > >> > >> We have our new quickstart repo but we still have our "old" examples > >> folder > >> containing a lot of samples (more than 50!). While most of them are > >> relevant, we still need to look if all of them are still relevant. I need > >> the whole team for that. > >> > >> Could anyone point out examples that could be removed or merged with other > >> examples ? > >> > >> Watch out , here is the list : > >> > >> * admin-client > >> * authz : > >> ** hello-world > >> ** hello-world-authz-service > >> ** photoz > >> ** servlet-authz > >> * basic-auth > >> * saml-broker-authentication > >> * cordova > >> * cors : > >> ** angular-product-app > >> ** database-service > >> * fuse : > >> ** camel > >> ** customer-app-fuse > >> ** cxf-jaxrs > >> ** cxf-jaxws > >> ** external-config > >> ** features > >> ** fuse-admin > >> ** product-app-fuse > >> * js-console > >> * kerberos > >> * ldap > >> * multi-tenant > >> * saml : > >> ** post-with-encryption > >> ** post-with-signature > >> ** redirect-with-signature > >> ** servlet-filter > >> * themes > >> * providers : > >> ** authenticator > >> ** domain-extension > >> ** event-listener-sysout > >> ** event-store-mem > >> ** federation-provider > >> ** rest > >> ** user-storage-jpa > >> * preconfigured-demo : > >> ** admin-access-app > >> ** angular2-product-app > >> ** angular-product-app > >> ** customer-app > >> ** customer-app-cli > >> ** customer-app-filter > >> ** customer-app-js > >> ** database-service > >> ** example-ear > >> ** offline-access-app > >> ** product-app > >> ** service-account > >> ** third-party > >> ** third-party-cdi > >> _______________________________________________ > >> keycloak-dev mailing list > >> keycloak-dev at lists.jboss.org > >> https://lists.jboss.org/mailman/listinfo/keycloak-dev > >> > > > > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev -- abstractj From sthorger at redhat.com Thu Jan 19 00:34:41 2017 From: sthorger at redhat.com (Stian Thorgersen) Date: Thu, 19 Jan 2017 06:34:41 +0100 Subject: [keycloak-dev] Migrating Examples to Quickstarts In-Reply-To: <20170119020633.GB8436@abstractj.org> References: <20170119020633.GB8436@abstractj.org> Message-ID: Maybe, there's two separate needs one is for us to be able to showcase Keycloak and the other is for folks to be able to try out Keycloak. One solution that fits all could be great. If we have a single click install that let's folk play with all aspects including LDAP/Kerberos that could be great. On 19 January 2017 at 03:06, Bruno Oliveira wrote: > Do you mean something related to this https://issues.jboss.org/ > browse/KEYCLOAK-3577 ? > > On 2017-01-18, Stian Thorgersen wrote: > > Forgot to mention that in addition to the quickstarts we should have a > demo > > bundle. It would replace the "demo" bits as well as the demo > distribution. > > Probably based on Docker images. > > > > Something that with one click can get a full blown demo to showcase > > Keycloak up and running. > > > > On 18 January 2017 at 16:33, Stian Thorgersen > wrote: > > > > > Here's my take on it. > > > > > > "demo" bits (everything in demo-template) should be replaced with the > new > > > quickstarts format. Some of these are already redundant (service, jsp, > > > html5). > > > > > > Authz - Pedro is working on RHSSO quickstart / migration > > > > > > Fuse - Marek is working on RHSSO quickstart / migration > > > > > > Broker - These needs some updating as they don't work and are not even > > > included in example DL. Not sure how important these are though. > > > > > > The rest I would put at the following priorities: > > > > > > P1: > > > Cordova > > > Themes > > > Cors (maybe the existing quickstarts i.e. services should have > explanation > > > on how to configure CORS instead) > > > SAML - maybe they should be updated to follow new quickstart format > > > > > > P2: > > > JS Console > > > Kerberos > > > LDAP > > > Providers > > > Admin client > > > > > > P3: > > > Multi tenant > > > Basic auth > > > > > > > > > > > > On 18 January 2017 at 15:36, Sebastien Blanc > wrote: > > > > > >> Hi ! > > >> > > >> We have our new quickstart repo but we still have our "old" examples > > >> folder > > >> containing a lot of samples (more than 50!). While most of them are > > >> relevant, we still need to look if all of them are still relevant. I > need > > >> the whole team for that. > > >> > > >> Could anyone point out examples that could be removed or merged with > other > > >> examples ? > > >> > > >> Watch out , here is the list : > > >> > > >> * admin-client > > >> * authz : > > >> ** hello-world > > >> ** hello-world-authz-service > > >> ** photoz > > >> ** servlet-authz > > >> * basic-auth > > >> * saml-broker-authentication > > >> * cordova > > >> * cors : > > >> ** angular-product-app > > >> ** database-service > > >> * fuse : > > >> ** camel > > >> ** customer-app-fuse > > >> ** cxf-jaxrs > > >> ** cxf-jaxws > > >> ** external-config > > >> ** features > > >> ** fuse-admin > > >> ** product-app-fuse > > >> * js-console > > >> * kerberos > > >> * ldap > > >> * multi-tenant > > >> * saml : > > >> ** post-with-encryption > > >> ** post-with-signature > > >> ** redirect-with-signature > > >> ** servlet-filter > > >> * themes > > >> * providers : > > >> ** authenticator > > >> ** domain-extension > > >> ** event-listener-sysout > > >> ** event-store-mem > > >> ** federation-provider > > >> ** rest > > >> ** user-storage-jpa > > >> * preconfigured-demo : > > >> ** admin-access-app > > >> ** angular2-product-app > > >> ** angular-product-app > > >> ** customer-app > > >> ** customer-app-cli > > >> ** customer-app-filter > > >> ** customer-app-js > > >> ** database-service > > >> ** example-ear > > >> ** offline-access-app > > >> ** product-app > > >> ** service-account > > >> ** third-party > > >> ** third-party-cdi > > >> _______________________________________________ > > >> keycloak-dev mailing list > > >> keycloak-dev at lists.jboss.org > > >> https://lists.jboss.org/mailman/listinfo/keycloak-dev > > >> > > > > > > > > _______________________________________________ > > keycloak-dev mailing list > > keycloak-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > -- > > abstractj > From abhi.raghav007 at gmail.com Thu Jan 19 00:56:30 2017 From: abhi.raghav007 at gmail.com (abhishek raghav) Date: Thu, 19 Jan 2017 11:26:30 +0530 Subject: [keycloak-dev] User Group in the response header by proxy Message-ID: Hi, I am maintaining a legacy application where i can not install keycloak adapter. This is secured behind the keycloak proxy. Keycloak proxy inject some identity headers by default keycloak_subject, name, username, email and access token. My requirement is such that that i need role and group should also be going as part of injected headers. I know for the fact that this information exists in the access token itself but then i need to add a depency/plugin on application side to parse the token info and get the roles/groups. Is there a way on the proxy side, i can add these two headers which can also be sent along with the identity headers. Secondly, is it a good approach or breaking the secured design patter. *- Best Regards* Abhishek Raghav From Martin.Plank at softec.sk Thu Jan 19 02:18:26 2017 From: Martin.Plank at softec.sk (Plank Martin) Date: Thu, 19 Jan 2017 07:18:26 +0000 Subject: [keycloak-dev] Sending email if the account is temporarily disabled Message-ID: <2e65f2aaff2b4dd1a3ab603db411231d@softec.sk> Hi all! I have a requirement to send an email if an account is temporarity disabled by brute force protection. It would be nice if the brute force protector fired an event when the account is temporarily disabled and then the event could be processed with event listener. But I don't see any option to create events of custom types. Do you think that creating this type of event is a good idea for improvement? The other way would be to create my own implementation of BruteForceProtector and EmailTemplateProvider. Any hints or suggestions are welcomed. Thanks for your answers Martin Plank From yunusoncel at gmail.com Thu Jan 19 02:47:43 2017 From: yunusoncel at gmail.com (=?UTF-8?B?WXVudXMgw5ZOQ0VM?=) Date: Thu, 19 Jan 2017 10:47:43 +0300 Subject: [keycloak-dev] Token Expired Event Message-ID: Hello; it is possible to use token expired event. I saw a lot of event type but I think there is no Token expired Event. if there is no token expired event, what do you suggest ? i dont know but maybe ? can use logout event ? Thank you From yunusoncel at gmail.com Thu Jan 19 02:55:37 2017 From: yunusoncel at gmail.com (=?UTF-8?B?WXVudXMgw5ZOQ0VM?=) Date: Thu, 19 Jan 2017 10:55:37 +0300 Subject: [keycloak-dev] Token Expired Event In-Reply-To: References: Message-ID: Hello ; I saw in javascript a method 'onTokenexpired'. I cannot find how does it work? Which method run on keycloak server? Thank You From mitya at cargosoft.ru Thu Jan 19 05:31:49 2017 From: mitya at cargosoft.ru (Dmitry Telegin) Date: Thu, 19 Jan 2017 13:31:49 +0300 Subject: [keycloak-dev] Stateful per-realm objects Message-ID: <1484821909.29708.1.camel@cargosoft.ru> Hi, A new login protocol endpoint instance is created each time per-request (o.k.protocol.LoginProtocolFactory::createProtocolEndpoint). I need all the instances to have access to a shared, per-realm stateful object. (Background: I'm implementing OpenID 2.0 for Keycloak using openid4java library. There, the central concept is ServerManager, a per-endpoint singleton that stores cryptographic associations and other shared data.) Just interested if there's already similar mechanism in Keycloak. It shouldn't be that hard to implement a singleton registry, but it'd prefer not to reinvent the wheel. Dmitry From sthorger at redhat.com Thu Jan 19 06:06:16 2017 From: sthorger at redhat.com (Stian Thorgersen) Date: Thu, 19 Jan 2017 12:06:16 +0100 Subject: [keycloak-dev] This list is for discussing development of Keycloak only! Message-ID: This list is only for discussing development of Keycloak. Please do not use this list if you are using Keycloak and need help. Same applies if you are customizing Keycloak and writing your own providers or creating themes. Unless you want to participate on design discussions, considering sending a PR to Keycloak or are a core team member you should likely not send emails to this list! Instead please use the user mailing list https://lists.jboss.org/mailman/listinfo/keycloak-user. From ritesh.garg at outlook.com Thu Jan 19 09:47:15 2017 From: ritesh.garg at outlook.com (Ritesh Garg) Date: Thu, 19 Jan 2017 14:47:15 +0000 Subject: [keycloak-dev] Keycloak Impersonation feature | KEYCLOAK-4219 Message-ID: Hello everyone, As of now, Keycloak supports impersonation by an admin user at the front end application level. However, if someone is using JWT token based API security, there is no existing way to get a user's JWT token "on behalf" of the user by admin u. I understand and agree with Stian Thorgersen that this is not just adding the return of a JWT token to the current impersonation endpoint. But I believe if keycloak supports impersonation; we should support that for API security as well and not just front-end applications. If we decide to incorporate it; one implementation approach can be to introduce an impersonation grant type which would perform client and admin user authentication before granting a token on behalf of the user it is requested for. Please let me know if this sounds completely absurd to you guys. Thoughts? Thanks, Ritesh Garg From bburke at redhat.com Thu Jan 19 09:56:56 2017 From: bburke at redhat.com (Bill Burke) Date: Thu, 19 Jan 2017 09:56:56 -0500 Subject: [keycloak-dev] Deploying provider with dependencies In-Reply-To: <1484774410.18494.3.camel@cargosoft.ru> References: <1484736842.3591.1.camel@cargosoft.ru> <1484770247.18494.1.camel@cargosoft.ru> <1484774410.18494.3.camel@cargosoft.ru> Message-ID: <0cd22167-1915-1509-2b77-fddcf009d477@redhat.com> I'm pretty sure you can just remove the application.xml too. Then the ear will be recursed. I tried this out when I first wrote the deployer. On 1/18/17 4:20 PM, Dmitry Telegin wrote: > I've finally solved this. There are two moments to pay attention to: > > - maven-ear-plugin by default generates almost empty application.xml. > In order for subdeployment to be recognized, it must be mentioned in > application.xml as a module. Both and worked for me; > - in JBoss/WildFly, only top-level jboss-deployment-structure.xml files > are recognized. Thus, this file should be moved from a JAR to an EAR > and tweaked accordingly. This is discussed in detail here: > http://stackoverflow.com/questions/26859092/jboss-deployment-structure- > xml-does-not-loads-the-dependencies-in-my-ear-project > > Again, it would be nice to have a complete working example to > demonstrate this approach. I think I could (one day) update my > BeerCloak example to cover this new deployment technique. > > Dmitry > > ? Wed, 18/01/2017 ? 23:10 +0300, Dmitry Telegin ?????: >> Stian, >> >> I've tried to package my provider JAR into an EAR, but that didn't >> work >> :( >> >> The layout is the following: >> >> foo-0.1-SNAPSHOT.ear >> +- foo-provider-0.1-SNAPSHOT.jar >> +- META-INF >> +- application.xml >> >> When I put the JAR into the deployments subdir, it is deployed >> successfully, initialization code is called etc. But when I drop the >> EAR in the same subdir, there is only a successful deployment >> message. >> The provider doesn't get initialized; seems like deployer doesn't >> recurse into EAR contents. Tried to place the JAR into the "lib" >> subdir >> inside EAR, this didn't work either. The EAR is generated by maven- >> ear- >> plugin with the standard settings. >> >> Am I missing something? Sorry for bugging you, but unfortunately >> there >> is not much said in the docs about deploying providers from inside >> EARs. A working example would be helpful as well. >> >> Dmitry >> >> ? Wed, 18/01/2017 ? 12:34 +0100, Stian Thorgersen ?????: >>> You have two options deploy as a module which requires adding >>> modules >>> for all dependencies or using the new deploy as a JEE archive >>> approach, which also supports hot deployment. Check out the server >>> developer guide for more details. >>> >>> On 18 January 2017 at 11:54, Dmitry Telegin >>> wrote: >>>> Hi, >>>> >>>> It's easy to imagine a provider that would integrate a third >>>> party >>>> library which, together with transitive dependencies, might >>>> result >>>> in >>>> dozens of JARs. A real-world example: OpenID 2.0 login protocol >>>> implementation using openid4java, which in its turn pulls in >>>> another 10 >>>> JARs. >>>> >>>> What are the deployment options for configurations like that? Is >>>> it >>>> really necessary to install each and every dependency as a >>>> WildFly >>>> module? This could become a PITA if there are a lot of deps. >>>> Could >>>> it >>>> be a single, self-sufficient artifact just to be put into >>>> deployments >>>> subdir? If yes, what type of artifact it should be (EAR maybe)? >>>> >>>> Thx, >>>> Dmitry >>>> _______________________________________________ >>>> keycloak-dev mailing list >>>> keycloak-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>>> >>> >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev From bruno at abstractj.org Thu Jan 19 11:04:59 2017 From: bruno at abstractj.org (Bruno Oliveira) Date: Thu, 19 Jan 2017 14:04:59 -0200 Subject: [keycloak-dev] Migrating Examples to Quickstarts In-Reply-To: References: <20170119020633.GB8436@abstractj.org> Message-ID: <20170119160459.GA28452@abstractj.org> Not sure if we can do a single click install. I was thinking about something like this: Let's say I want to run our nodejs example, user would just have to run "docker-compose up nodejs" and this would be responsible for spinning up an instance of Keycloak with HTML5 example, pointing to the nodejs service app deployed in another container? Is that what you mean by "single click"? On 2017-01-19, Stian Thorgersen wrote: > Maybe, there's two separate needs one is for us to be able to showcase > Keycloak and the other is for folks to be able to try out Keycloak. One > solution that fits all could be great. If we have a single click install > that let's folk play with all aspects including LDAP/Kerberos that could be > great. > > On 19 January 2017 at 03:06, Bruno Oliveira wrote: > > > Do you mean something related to this https://issues.jboss.org/ > > browse/KEYCLOAK-3577 ? > > > > On 2017-01-18, Stian Thorgersen wrote: > > > Forgot to mention that in addition to the quickstarts we should have a > > demo > > > bundle. It would replace the "demo" bits as well as the demo > > distribution. > > > Probably based on Docker images. > > > > > > Something that with one click can get a full blown demo to showcase > > > Keycloak up and running. > > > > > > On 18 January 2017 at 16:33, Stian Thorgersen > > wrote: > > > > > > > Here's my take on it. > > > > > > > > "demo" bits (everything in demo-template) should be replaced with the > > new > > > > quickstarts format. Some of these are already redundant (service, jsp, > > > > html5). > > > > > > > > Authz - Pedro is working on RHSSO quickstart / migration > > > > > > > > Fuse - Marek is working on RHSSO quickstart / migration > > > > > > > > Broker - These needs some updating as they don't work and are not even > > > > included in example DL. Not sure how important these are though. > > > > > > > > The rest I would put at the following priorities: > > > > > > > > P1: > > > > Cordova > > > > Themes > > > > Cors (maybe the existing quickstarts i.e. services should have > > explanation > > > > on how to configure CORS instead) > > > > SAML - maybe they should be updated to follow new quickstart format > > > > > > > > P2: > > > > JS Console > > > > Kerberos > > > > LDAP > > > > Providers > > > > Admin client > > > > > > > > P3: > > > > Multi tenant > > > > Basic auth > > > > > > > > > > > > > > > > On 18 January 2017 at 15:36, Sebastien Blanc > > wrote: > > > > > > > >> Hi ! > > > >> > > > >> We have our new quickstart repo but we still have our "old" examples > > > >> folder > > > >> containing a lot of samples (more than 50!). While most of them are > > > >> relevant, we still need to look if all of them are still relevant. I > > need > > > >> the whole team for that. > > > >> > > > >> Could anyone point out examples that could be removed or merged with > > other > > > >> examples ? > > > >> > > > >> Watch out , here is the list : > > > >> > > > >> * admin-client > > > >> * authz : > > > >> ** hello-world > > > >> ** hello-world-authz-service > > > >> ** photoz > > > >> ** servlet-authz > > > >> * basic-auth > > > >> * saml-broker-authentication > > > >> * cordova > > > >> * cors : > > > >> ** angular-product-app > > > >> ** database-service > > > >> * fuse : > > > >> ** camel > > > >> ** customer-app-fuse > > > >> ** cxf-jaxrs > > > >> ** cxf-jaxws > > > >> ** external-config > > > >> ** features > > > >> ** fuse-admin > > > >> ** product-app-fuse > > > >> * js-console > > > >> * kerberos > > > >> * ldap > > > >> * multi-tenant > > > >> * saml : > > > >> ** post-with-encryption > > > >> ** post-with-signature > > > >> ** redirect-with-signature > > > >> ** servlet-filter > > > >> * themes > > > >> * providers : > > > >> ** authenticator > > > >> ** domain-extension > > > >> ** event-listener-sysout > > > >> ** event-store-mem > > > >> ** federation-provider > > > >> ** rest > > > >> ** user-storage-jpa > > > >> * preconfigured-demo : > > > >> ** admin-access-app > > > >> ** angular2-product-app > > > >> ** angular-product-app > > > >> ** customer-app > > > >> ** customer-app-cli > > > >> ** customer-app-filter > > > >> ** customer-app-js > > > >> ** database-service > > > >> ** example-ear > > > >> ** offline-access-app > > > >> ** product-app > > > >> ** service-account > > > >> ** third-party > > > >> ** third-party-cdi > > > >> _______________________________________________ > > > >> keycloak-dev mailing list > > > >> keycloak-dev at lists.jboss.org > > > >> https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > >> > > > > > > > > > > > _______________________________________________ > > > keycloak-dev mailing list > > > keycloak-dev at lists.jboss.org > > > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > > -- > > > > abstractj > > -- abstractj From bruno at abstractj.org Thu Jan 19 11:59:26 2017 From: bruno at abstractj.org (Bruno Oliveira) Date: Thu, 19 Jan 2017 14:59:26 -0200 Subject: [keycloak-dev] Change language of information in keycloak database In-Reply-To: References: Message-ID: <20170119165926.GB28452@abstractj.org> There was an issue on Keycloak 2.5.0 that even changing the default language, english was still a default. This was fixed on master and will be available on the next release. For questions like this, please use keycloak-user mailing list. On 2017-01-18, Gustavo Alvarez wrote: > Hello everyone. > > I need to change the language of the data in the keycloak database, for > example the list of "password policies" in the Authentication menu, > 'Password Policies' tab. > > I try to change the values of the database, but when I create a new realm, > the language in this is English always. > > Thank you. > > Gustavo ?lvarez. > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev -- abstractj From madaras_adrian at yahoo.com Fri Jan 20 04:36:42 2017 From: madaras_adrian at yahoo.com (Adrian Madaras) Date: Fri, 20 Jan 2017 09:36:42 +0000 (UTC) Subject: [keycloak-dev] LDAP Attribute to Keycloak Role References: <1355544323.287015.1484905002691.ref@mail.yahoo.com> Message-ID: <1355544323.287015.1484905002691@mail.yahoo.com> Hi everybody, I am trying to map a user attribute named 'sRoles' from LDAP to Roles in Keycloak. Is this possible? I could not find any reference regarding this online and I think it's a subject that a lot of people would be interested in. Thanks in advance, Adrian From sthorger at redhat.com Fri Jan 20 08:41:21 2017 From: sthorger at redhat.com (Stian Thorgersen) Date: Fri, 20 Jan 2017 14:41:21 +0100 Subject: [keycloak-dev] Migrating Examples to Quickstarts In-Reply-To: <20170119160459.GA28452@abstractj.org> References: <20170119020633.GB8436@abstractj.org> <20170119160459.GA28452@abstractj.org> Message-ID: Single click install / demo is not for the quickstarts. It's for a pre-configured and ready setup demo which includes apps and services to showcase Keycloak. A while back Stan suggested using domain mode for it. One domain with one server for KC and another for apps. All ready to go with realms and apps pre-configured. On 19 January 2017 at 17:04, Bruno Oliveira wrote: > Not sure if we can do a single click install. I was thinking about > something like this: > > Let's say I want to run our nodejs example, user would just have to run > "docker-compose up nodejs" and this would be responsible for spinning up an > instance of Keycloak with HTML5 example, pointing to the nodejs > service app deployed in another container? > > Is that what you mean by "single click"? > > > On 2017-01-19, Stian Thorgersen wrote: > > Maybe, there's two separate needs one is for us to be able to showcase > > Keycloak and the other is for folks to be able to try out Keycloak. One > > solution that fits all could be great. If we have a single click install > > that let's folk play with all aspects including LDAP/Kerberos that could > be > > great. > > > > On 19 January 2017 at 03:06, Bruno Oliveira wrote: > > > > > Do you mean something related to this https://issues.jboss.org/ > > > browse/KEYCLOAK-3577 ? > > > > > > On 2017-01-18, Stian Thorgersen wrote: > > > > Forgot to mention that in addition to the quickstarts we should have > a > > > demo > > > > bundle. It would replace the "demo" bits as well as the demo > > > distribution. > > > > Probably based on Docker images. > > > > > > > > Something that with one click can get a full blown demo to showcase > > > > Keycloak up and running. > > > > > > > > On 18 January 2017 at 16:33, Stian Thorgersen > > > wrote: > > > > > > > > > Here's my take on it. > > > > > > > > > > "demo" bits (everything in demo-template) should be replaced with > the > > > new > > > > > quickstarts format. Some of these are already redundant (service, > jsp, > > > > > html5). > > > > > > > > > > Authz - Pedro is working on RHSSO quickstart / migration > > > > > > > > > > Fuse - Marek is working on RHSSO quickstart / migration > > > > > > > > > > Broker - These needs some updating as they don't work and are not > even > > > > > included in example DL. Not sure how important these are though. > > > > > > > > > > The rest I would put at the following priorities: > > > > > > > > > > P1: > > > > > Cordova > > > > > Themes > > > > > Cors (maybe the existing quickstarts i.e. services should have > > > explanation > > > > > on how to configure CORS instead) > > > > > SAML - maybe they should be updated to follow new quickstart format > > > > > > > > > > P2: > > > > > JS Console > > > > > Kerberos > > > > > LDAP > > > > > Providers > > > > > Admin client > > > > > > > > > > P3: > > > > > Multi tenant > > > > > Basic auth > > > > > > > > > > > > > > > > > > > > On 18 January 2017 at 15:36, Sebastien Blanc > > > wrote: > > > > > > > > > >> Hi ! > > > > >> > > > > >> We have our new quickstart repo but we still have our "old" > examples > > > > >> folder > > > > >> containing a lot of samples (more than 50!). While most of them > are > > > > >> relevant, we still need to look if all of them are still > relevant. I > > > need > > > > >> the whole team for that. > > > > >> > > > > >> Could anyone point out examples that could be removed or merged > with > > > other > > > > >> examples ? > > > > >> > > > > >> Watch out , here is the list : > > > > >> > > > > >> * admin-client > > > > >> * authz : > > > > >> ** hello-world > > > > >> ** hello-world-authz-service > > > > >> ** photoz > > > > >> ** servlet-authz > > > > >> * basic-auth > > > > >> * saml-broker-authentication > > > > >> * cordova > > > > >> * cors : > > > > >> ** angular-product-app > > > > >> ** database-service > > > > >> * fuse : > > > > >> ** camel > > > > >> ** customer-app-fuse > > > > >> ** cxf-jaxrs > > > > >> ** cxf-jaxws > > > > >> ** external-config > > > > >> ** features > > > > >> ** fuse-admin > > > > >> ** product-app-fuse > > > > >> * js-console > > > > >> * kerberos > > > > >> * ldap > > > > >> * multi-tenant > > > > >> * saml : > > > > >> ** post-with-encryption > > > > >> ** post-with-signature > > > > >> ** redirect-with-signature > > > > >> ** servlet-filter > > > > >> * themes > > > > >> * providers : > > > > >> ** authenticator > > > > >> ** domain-extension > > > > >> ** event-listener-sysout > > > > >> ** event-store-mem > > > > >> ** federation-provider > > > > >> ** rest > > > > >> ** user-storage-jpa > > > > >> * preconfigured-demo : > > > > >> ** admin-access-app > > > > >> ** angular2-product-app > > > > >> ** angular-product-app > > > > >> ** customer-app > > > > >> ** customer-app-cli > > > > >> ** customer-app-filter > > > > >> ** customer-app-js > > > > >> ** database-service > > > > >> ** example-ear > > > > >> ** offline-access-app > > > > >> ** product-app > > > > >> ** service-account > > > > >> ** third-party > > > > >> ** third-party-cdi > > > > >> _______________________________________________ > > > > >> keycloak-dev mailing list > > > > >> keycloak-dev at lists.jboss.org > > > > >> https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > > >> > > > > > > > > > > > > > > _______________________________________________ > > > > keycloak-dev mailing list > > > > keycloak-dev at lists.jboss.org > > > > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > > > > -- > > > > > > abstractj > > > > > -- > > abstractj > From mitya at cargosoft.ru Fri Jan 20 17:49:35 2017 From: mitya at cargosoft.ru (Dmitry Telegin) Date: Sat, 21 Jan 2017 01:49:35 +0300 Subject: [keycloak-dev] Custom login protocol not showing when creating a client In-Reply-To: References: <1484265943.10595.2.camel@cargosoft.ru> Message-ID: <1484952575.9785.0.camel@cargosoft.ru> https://issues.jboss.org/browse/KEYCLOAK-4270 https://github.com/keycloak/keycloak/pull/3782 > Sure, JIRA it and send a PR ;) > > On 13 January 2017 at 01:05, Dmitry Telegin > wrote: > > Hi, > > > > I'm working on OpenID 2.0 support for Keycloak - please don't laugh > > :) > > it's still used by many enterprise behemoths. I've created and > > deployed > > a skeleton of LoginProtocol, but I've found that it wouldn't show > > in > > the protocol select box when creating a new client (it does show > > when > > editing, though). By some reason the list of protocols is hardcoded > > into CreateClientCtrl, and the seemingly correct code is commented > > out. > > Can we fix that? > > > > Cheers, > > Dmitry > > _______________________________________________ > > keycloak-dev mailing list > > keycloak-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > > From mitya at cargosoft.ru Sun Jan 22 17:16:16 2017 From: mitya at cargosoft.ru (Dmitry Telegin) Date: Mon, 23 Jan 2017 01:16:16 +0300 Subject: [keycloak-dev] Deploying provider with dependencies In-Reply-To: <0cd22167-1915-1509-2b77-fddcf009d477@redhat.com> References: <1484736842.3591.1.camel@cargosoft.ru> <1484770247.18494.1.camel@cargosoft.ru> <1484774410.18494.3.camel@cargosoft.ru> <0cd22167-1915-1509-2b77-fddcf009d477@redhat.com> Message-ID: <1485123376.9077.1.camel@cargosoft.ru> Tried with 2.5.0.Final - the EAR doesn't get recursed unless there's an application.xml with all the internal JARs explicitly declared as modules. Could it have been some special jboss-deployment-structure.xml in your case? Either way, it's a very subtle issue that deserves being documented IMHO. Cheers, Dmitry ? Thu, 19/01/2017 ? 09:56 -0500, Bill Burke ?????: > I'm pretty sure you can just remove the application.xml too. Then > the? > ear will be recursed.??I tried this out when I first wrote the > deployer. > > > On 1/18/17 4:20 PM, Dmitry Telegin wrote: > > I've finally solved this. There are two moments to pay attention > > to: > > > > - maven-ear-plugin by default generates almost empty > > application.xml. > > In order for subdeployment to be recognized, it must be mentioned > > in > > application.xml as a module. Both and worked for me; > > - in JBoss/WildFly, only top-level jboss-deployment-structure.xml > > files > > are recognized. Thus, this file should be moved from a JAR to an > > EAR > > and tweaked accordingly. This is discussed in detail here: > > http://stackoverflow.com/questions/26859092/jboss-deployment-struct > > ure- > > xml-does-not-loads-the-dependencies-in-my-ear-project > > > > Again, it would be nice to have a complete working example to > > demonstrate this approach. I think I could (one day) update my > > BeerCloak example to cover this new deployment technique. > > > > Dmitry > > > > ? Wed, 18/01/2017 ? 23:10 +0300, Dmitry Telegin ?????: > > > Stian, > > > > > > I've tried to package my provider JAR into an EAR, but that > > > didn't > > > work > > > ? :( > > > > > > The layout is the following: > > > > > > foo-0.1-SNAPSHOT.ear > > > +- foo-provider-0.1-SNAPSHOT.jar > > > +- META-INF > > > ????+- application.xml > > > > > > When I put the JAR into the deployments subdir, it is deployed > > > successfully, initialization code is called etc. But when I drop > > > the > > > EAR in the same subdir, there is only a successful deployment > > > message. > > > The provider doesn't get initialized; seems like deployer doesn't > > > recurse into EAR contents. Tried to place the JAR into the "lib" > > > subdir > > > inside EAR, this didn't work either. The EAR is generated by > > > maven- > > > ear- > > > plugin with the standard settings. > > > > > > Am I missing something? Sorry for bugging you, but unfortunately > > > there > > > is not much said in the docs about deploying providers from > > > inside > > > EARs. A working example would be helpful as well. > > > > > > Dmitry > > > > > > ? Wed, 18/01/2017 ? 12:34 +0100, Stian Thorgersen ?????: > > > > You have two options deploy as a module which requires adding > > > > modules > > > > for all dependencies or using the new deploy as a JEE archive > > > > approach, which also supports hot deployment. Check out the > > > > server > > > > developer guide for more details. > > > > > > > > On 18 January 2017 at 11:54, Dmitry Telegin > > > > > > > > wrote: > > > > > Hi, > > > > > > > > > > It's easy to imagine a provider that would integrate a third > > > > > party > > > > > library which, together with transitive dependencies, might > > > > > result > > > > > in > > > > > dozens of JARs. A real-world example: OpenID 2.0 login > > > > > protocol > > > > > implementation using openid4java, which in its turn pulls in > > > > > another 10 > > > > > JARs. > > > > > > > > > > What are the deployment options for configurations like that? > > > > > Is > > > > > it > > > > > really necessary to install each and every dependency as a > > > > > WildFly > > > > > module? This could become a PITA if there are a lot of deps. > > > > > Could > > > > > it > > > > > be a single, self-sufficient artifact just to be put into > > > > > deployments > > > > > subdir? If yes, what type of artifact it should be (EAR > > > > > maybe)? > > > > > > > > > > Thx, > > > > > Dmitry > > > > > _______________________________________________ > > > > > keycloak-dev mailing list > > > > > keycloak-dev at lists.jboss.org > > > > > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > > > > > > > > > _______________________________________________ > > > keycloak-dev mailing list > > > keycloak-dev at lists.jboss.org > > > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > > _______________________________________________ > > keycloak-dev mailing list > > keycloak-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev From mposolda at redhat.com Mon Jan 23 03:56:02 2017 From: mposolda at redhat.com (Marek Posolda) Date: Mon, 23 Jan 2017 09:56:02 +0100 Subject: [keycloak-dev] LDAP Attribute to Keycloak Role In-Reply-To: <1355544323.287015.1484905002691@mail.yahoo.com> References: <1355544323.287015.1484905002691.ref@mail.yahoo.com> <1355544323.287015.1484905002691@mail.yahoo.com> Message-ID: This mailing list is exclusively dedicated to discussions around Keycloak development. Please resend your question to keycloak-user mailing list [1] which is a place for any questions related to installing, setting up, and using Keycloak. [1] https://lists.jboss.org/mailman/listinfo/keycloak-user On 20/01/17 10:36, Adrian Madaras wrote: > Hi everybody, > I am trying to map a user attribute named 'sRoles' from LDAP to Roles in Keycloak. > Is this possible? I could not find any reference regarding this online and I think it's a subject that a lot of people would be interested in. > Thanks in advance, > Adrian > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev From ritesh.garg at outlook.com Mon Jan 23 09:30:44 2017 From: ritesh.garg at outlook.com (Ritesh Garg) Date: Mon, 23 Jan 2017 14:30:44 +0000 Subject: [keycloak-dev] Keycloak Impersonation feature | KEYCLOAK-4219 In-Reply-To: References: Message-ID: Hello, Any thoughts on this? Thanks, Ritesh ________________________________ From: Ritesh Garg Sent: Thursday, January 19, 2017 9:47 AM To: keycloak-dev at lists.jboss.org Subject: Keycloak Impersonation feature | KEYCLOAK-4219 Hello everyone, As of now, Keycloak supports impersonation by an admin user at the front end application level. However, if someone is using JWT token based API security, there is no existing way to get a user's JWT token "on behalf" of the user by admin u. I understand and agree with Stian Thorgersen that this is not just adding the return of a JWT token to the current impersonation endpoint. But I believe if keycloak supports impersonation; we should support that for API security as well and not just front-end applications. If we decide to incorporate it; one implementation approach can be to introduce an impersonation grant type which would perform client and admin user authentication before granting a token on behalf of the user it is requested for. Please let me know if this sounds completely absurd to you guys. Thoughts? Thanks, Ritesh Garg From liam.maruff at gmail.com Mon Jan 23 21:56:51 2017 From: liam.maruff at gmail.com (Liam Maruff) Date: Tue, 24 Jan 2017 12:56:51 +1000 Subject: [keycloak-dev] Extend LDAP User Federation Mechanism with TOTP capability Message-ID: Hello there, I'd like to replace a custom-built authentication system with OpenID Connect via Keycloak. To do so, I intend to extend the LDAP User Federation mechanism (See LDAPStorageProvider, LDAPStorageProviderFactory) to support TOTP authentication. Having implemented my extension as a provider (albeit an extension lacking any additional capability), when I attempt to add an instance of my provider in the Keycloak administration console the 'Required Settings' page contains all of the settings for the LDAP federation I am deriving from, but lacks combo boxes (instead presenting line inputs in their place), and captions against most fields. What can I do to correct this behaviour? Alternatively, is there a more appropriate mechanism for me to provide the behaviour I desire? Any guidance would be greatly appreciated. Regards, Liam M From Andriy.Vyedyeneyev at allianz.at Tue Jan 24 05:41:18 2017 From: Andriy.Vyedyeneyev at allianz.at (Vyedyeneyev, Andriy (AMOS Austria GmbH)) Date: Tue, 24 Jan 2017 11:41:18 +0100 Subject: [keycloak-dev] handling duplicatemodel in direct grant authentication flow Message-ID: Hello, I will start with a short background. We have requirement to support accounts with duplicated email, so in that case user should be notified to use username as credential to login. So far we have no problems with it while using login form for webapp we have used browser authentication flow, and there UserNameFormValidator handles it this way: UserModel user = null; try { user = KeycloakModelUtils.findUserByNameOrEmail(context.getSession(), context.getRealm(), username); } catch (ModelDuplicateException mde) { ServicesLogger.LOGGER.modelDuplicateException(mde); // Could happen during federation import if (mde.getDuplicateFieldName() != null && mde.getDuplicateFieldName().equals(UserModel.EMAIL)) { setDuplicateUserChallenge(context, Errors.EMAIL_IN_USE, Messages.EMAIL_EXISTS, AuthenticationFlowError.INVALID_USER); } else { setDuplicateUserChallenge(context, Errors.USERNAME_IN_USE, Messages.USERNAME_EXISTS, AuthenticationFlowError.INVALID_USER); } return false; } With a new requirement we are handling login inside Mobile App, and we are using direct-grant instead browser authentication flow. At this point we have troubles with response code, since ValidateUsername implemented this way UserModel user = null; try { user = KeycloakModelUtils.findUserByNameOrEmail(context.getSession(), context.getRealm(), username); } catch (ModelDuplicateException mde) { logger.error(mde.getMessage(), mde); Response challengeResponse = errorResponse(Response.Status.UNAUTHORIZED.getStatusCode(), "invalid_request", "Invalid user credentials"); context.failure(AuthenticationProcessor.Error.INVALID_USER, challengeResponse); return; } Well I have reported this as bug, but seems like it's working as designed, with a reason "We do not want to leak if a username or email is linked to a real user or not.". So my point is we need consistent error handling behavior independent which flow browser/direct-grant/something-else client using. The intruder can link response body {"invalid_request": "Invalid user credentials"} to this error anyway, so there is no point to use cryptic response codes here. I would like to hear from you arguments against my proposal, many thanks in advance :) Kind regards, Andriy Vyedyeneyev AMOS Austria GmbH 1130 Wien, Hietzinger Kai 101-105 FN 365014k, Handelsgericht Wien UID: ATU 66614737 http://www.allianz.at ******************************************************** Dieses E-Mail und allfaellig daran angeschlossene Anhaenge enthalten Informationen, die vertraulich und ausschliesslich fuer den (die) bezeichneten Adressaten bestimmt sind. Wenn Sie nicht der genannte Adressat sind, darf dieses E-Mail samt allfaelliger Anhaenge von Ihnen weder anderen Personen zugaenglich gemacht noch in anderer Weise verwertet werden. Wenn Sie nicht der beabsichtigte Empfaenger sind, bitten wir Sie, dieses E-Mail und saemtliche angeschlossene Anhaenge zu loeschen. Please note: This email and any files transmitted with it is intended only for the named recipients and may contain confidential and/or privileged information. If you are not the intended recipient, please do not read, copy, use or disclose the contents of this communication to others and notify the sender immediately. Then please delete the email and any copies of it. Thank you. ******************************************************** From mposolda at redhat.com Tue Jan 24 06:59:06 2017 From: mposolda at redhat.com (Marek Posolda) Date: Tue, 24 Jan 2017 12:59:06 +0100 Subject: [keycloak-dev] Extend LDAP User Federation Mechanism with TOTP capability In-Reply-To: References: Message-ID: <3b60af0e-7329-e9a7-92a6-7b969971bddd@redhat.com> Yes, I think that creating your own CredentialProvider (perhaps subclass of OTPCredentialProvider) would work better. Just answered on keycloak-user though. Marek On 24/01/17 03:56, Liam Maruff wrote: > Hello there, > > I'd like to replace a custom-built authentication system with OpenID > Connect via Keycloak. To do so, I intend to extend the LDAP User Federation > mechanism (See LDAPStorageProvider, LDAPStorageProviderFactory) to support > TOTP authentication. > > Having implemented my extension as a provider (albeit an extension lacking > any additional capability), when I attempt to add an instance of my > provider in the Keycloak administration console the 'Required Settings' > page contains all of the settings for the LDAP federation I am deriving > from, but lacks combo boxes (instead presenting line inputs in their > place), and captions against most fields. What can I do to correct this > behaviour? > > Alternatively, is there a more appropriate mechanism for me to provide the > behaviour I desire? Any guidance would be greatly appreciated. > > Regards, > > Liam M > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev From sthorger at redhat.com Wed Jan 25 07:02:09 2017 From: sthorger at redhat.com (Stian Thorgersen) Date: Wed, 25 Jan 2017 13:02:09 +0100 Subject: [keycloak-dev] Keycloak Impersonation feature | KEYCLOAK-4219 In-Reply-To: References: Message-ID: Please have patience rather than repeat yourself. I don't really need 3 emails about the same thing in my mailbox as I have loads of email to get through in a day! I don't really see the use-case for this. Impersonation is specifically for a user to impersonate another user. As such there has to be a front-end application as users don't go around manually obtaining tokens to invoke backend services. On 23 January 2017 at 15:30, Ritesh Garg wrote: > Hello, > > > Any thoughts on this? > > > Thanks, > > Ritesh > > ________________________________ > From: Ritesh Garg > Sent: Thursday, January 19, 2017 9:47 AM > To: keycloak-dev at lists.jboss.org > Subject: Keycloak Impersonation feature | KEYCLOAK-4219 > > Hello everyone, > > As of now, Keycloak supports impersonation by an admin user at the front > end application level. However, if someone is using JWT token based API > security, there is no existing way to get a user's JWT token "on behalf" of > the user by admin u. > > I understand and agree with Stian Thorgersen that this is not just adding > the return of a JWT token to the current impersonation endpoint. But I > believe if keycloak supports impersonation; we should support that for API > security as well and not just front-end applications. > > If we decide to incorporate it; one implementation approach can be to > introduce an impersonation grant type which would perform client and admin > user authentication before granting a token on behalf of the user it is > requested for. Please let me know if this sounds completely absurd to you > guys. > > Thoughts? > > Thanks, > Ritesh Garg > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > From grossws at gmail.com Wed Jan 25 07:24:21 2017 From: grossws at gmail.com (Konstantin Gribov) Date: Wed, 25 Jan 2017 12:24:21 +0000 Subject: [keycloak-dev] Keycloak Impersonation feature | KEYCLOAK-4219 In-Reply-To: References: Message-ID: Hello, Stian. I have such usecase where app should be able to work on behalf of some user for periodic tasks. But I'm not sure that such case should be implemented using impersonation. It's too coarse grained and makes attack surface much larger, since it allows to get access token for any scope including offline for impersonated user. Currently I use usernames (which are unique in my case because of my ldap contraints on users `cn`s) and a little service to obtain all required info (like email, groups/roles) for periodic tasks via Keycloak Admin API using service user for this activity. I have to make this service a confidential client because of bearer-only lacks support for service accounts (so I hope that KEYCLOAK-4156 will come soon). Another way to do something on behalf of some user would be offline token which is intended for such usecases, but it can't be easily integrated to our system. ??, 25 ???. 2017 ?. ? 15:03, Stian Thorgersen : > Please have patience rather than repeat yourself. I don't really need 3 > emails about the same thing in my mailbox as I have loads of email to get > through in a day! > > I don't really see the use-case for this. Impersonation is specifically for > a user to impersonate another user. As such there has to be a front-end > application as users don't go around manually obtaining tokens to invoke > backend services. > > On 23 January 2017 at 15:30, Ritesh Garg wrote: > > > Hello, > > > > > > Any thoughts on this? > > > > > > Thanks, > > > > Ritesh > > > > ________________________________ > > From: Ritesh Garg > > Sent: Thursday, January 19, 2017 9:47 AM > > To: keycloak-dev at lists.jboss.org > > Subject: Keycloak Impersonation feature | KEYCLOAK-4219 > > > > Hello everyone, > > > > As of now, Keycloak supports impersonation by an admin user at the front > > end application level. However, if someone is using JWT token based API > > security, there is no existing way to get a user's JWT token "on behalf" > of > > the user by admin u. > > > > I understand and agree with Stian Thorgersen that this is not just adding > > the return of a JWT token to the current impersonation endpoint. But I > > believe if keycloak supports impersonation; we should support that for > API > > security as well and not just front-end applications. > > > > If we decide to incorporate it; one implementation approach can be to > > introduce an impersonation grant type which would perform client and > admin > > user authentication before granting a token on behalf of the user it is > > requested for. Please let me know if this sounds completely absurd to you > > guys. > > > > Thoughts? > > > > Thanks, > > Ritesh Garg > > > > _______________________________________________ > > 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 > -- Best regards, Konstantin Gribov From sthorger at redhat.com Wed Jan 25 07:31:28 2017 From: sthorger at redhat.com (Stian Thorgersen) Date: Wed, 25 Jan 2017 13:31:28 +0100 Subject: [keycloak-dev] Keycloak Impersonation feature | KEYCLOAK-4219 In-Reply-To: References: Message-ID: On 25 January 2017 at 13:24, Konstantin Gribov wrote: > Hello, Stian. > > I have such usecase where app should be able to work on behalf of some > user for periodic tasks. > > But I'm not sure that such case should be implemented using impersonation. > It's too coarse grained and makes attack surface much larger, since it > allows to get access token for any scope including offline for impersonated > user. > > Currently I use usernames (which are unique in my case because of my ldap > contraints on users `cn`s) and a little service to obtain all required info > (like email, groups/roles) for periodic tasks via Keycloak Admin API using > service user for this activity. I have to make this service a confidential > client because of bearer-only lacks support for service accounts (so I hope > that KEYCLOAK-4156 will come soon). > > Another way to do something on behalf of some user would be offline token > which is intended for such usecases, but it can't be easily integrated to > our system. > Offline tokens are the way your use-case should be solved and we won't add another approach. Allowing an application to impersonate any arbitrary user is just plain crazy. It's actually a really god reason we should not support impersonation through an api. > > > ??, 25 ???. 2017 ?. ? 15:03, Stian Thorgersen : > >> Please have patience rather than repeat yourself. I don't really need 3 >> emails about the same thing in my mailbox as I have loads of email to get >> through in a day! >> >> I don't really see the use-case for this. Impersonation is specifically >> for >> a user to impersonate another user. As such there has to be a front-end >> application as users don't go around manually obtaining tokens to invoke >> backend services. >> >> On 23 January 2017 at 15:30, Ritesh Garg wrote: >> >> > Hello, >> > >> > >> > Any thoughts on this? >> > >> > >> > Thanks, >> > >> > Ritesh >> > >> > ________________________________ >> > From: Ritesh Garg >> > Sent: Thursday, January 19, 2017 9:47 AM >> > To: keycloak-dev at lists.jboss.org >> > Subject: Keycloak Impersonation feature | KEYCLOAK-4219 >> > >> > Hello everyone, >> > >> > As of now, Keycloak supports impersonation by an admin user at the front >> > end application level. However, if someone is using JWT token based API >> > security, there is no existing way to get a user's JWT token "on >> behalf" of >> > the user by admin u. >> > >> > I understand and agree with Stian Thorgersen that this is not just >> adding >> > the return of a JWT token to the current impersonation endpoint. But I >> > believe if keycloak supports impersonation; we should support that for >> API >> > security as well and not just front-end applications. >> > >> > If we decide to incorporate it; one implementation approach can be to >> > introduce an impersonation grant type which would perform client and >> admin >> > user authentication before granting a token on behalf of the user it is >> > requested for. Please let me know if this sounds completely absurd to >> you >> > guys. >> > >> > Thoughts? >> > >> > Thanks, >> > Ritesh Garg >> > >> > _______________________________________________ >> > 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 >> > -- > > Best regards, > Konstantin Gribov > From grossws at gmail.com Wed Jan 25 08:20:11 2017 From: grossws at gmail.com (Konstantin Gribov) Date: Wed, 25 Jan 2017 13:20:11 +0000 Subject: [keycloak-dev] Keycloak Impersonation feature | KEYCLOAK-4219 In-Reply-To: References: Message-ID: Yes, I totally agree. I'm not a OP, though. Maybe he has some other use case where he think he need impersonation. I've just explained a workaroud I have in use case where I *could* think impersonation would be way to go because it's hard to integrate offline tokens in my case. But I'm totally aware that such feature shouldn't be implemented because of its security implications. ??, 25 ???. 2017 ?. ? 15:31, Stian Thorgersen : > On 25 January 2017 at 13:24, Konstantin Gribov wrote: > > Hello, Stian. > > I have such usecase where app should be able to work on behalf of some > user for periodic tasks. > > > But I'm not sure that such case should be implemented using impersonation. > It's too coarse grained and makes attack surface much larger, since it > allows to get access token for any scope including offline for impersonated > user. > > Currently I use usernames (which are unique in my case because of my ldap > contraints on users `cn`s) and a little service to obtain all required info > (like email, groups/roles) for periodic tasks via Keycloak Admin API using > service user for this activity. I have to make this service a confidential > client because of bearer-only lacks support for service accounts (so I hope > that KEYCLOAK-4156 will come soon). > > Another way to do something on behalf of some user would be offline token > which is intended for such usecases, but it can't be easily integrated to > our system. > > > Offline tokens are the way your use-case should be solved and we won't add > another approach. Allowing an application to impersonate any arbitrary user > is just plain crazy. It's actually a really god reason we should not > support impersonation through an api. > > > > > ??, 25 ???. 2017 ?. ? 15:03, Stian Thorgersen : > > Please have patience rather than repeat yourself. I don't really need 3 > emails about the same thing in my mailbox as I have loads of email to get > through in a day! > > I don't really see the use-case for this. Impersonation is specifically for > a user to impersonate another user. As such there has to be a front-end > application as users don't go around manually obtaining tokens to invoke > backend services. > > On 23 January 2017 at 15:30, Ritesh Garg wrote: > > > Hello, > > > > > > Any thoughts on this? > > > > > > Thanks, > > > > Ritesh > > > > ________________________________ > > From: Ritesh Garg > > Sent: Thursday, January 19, 2017 9:47 AM > > To: keycloak-dev at lists.jboss.org > > Subject: Keycloak Impersonation feature | KEYCLOAK-4219 > > > > Hello everyone, > > > > As of now, Keycloak supports impersonation by an admin user at the front > > end application level. However, if someone is using JWT token based API > > security, there is no existing way to get a user's JWT token "on behalf" > of > > the user by admin u. > > > > I understand and agree with Stian Thorgersen that this is not just adding > > the return of a JWT token to the current impersonation endpoint. But I > > believe if keycloak supports impersonation; we should support that for > API > > security as well and not just front-end applications. > > > > If we decide to incorporate it; one implementation approach can be to > > introduce an impersonation grant type which would perform client and > admin > > user authentication before granting a token on behalf of the user it is > > requested for. Please let me know if this sounds completely absurd to you > > guys. > > > > Thoughts? > > > > Thanks, > > Ritesh Garg > > > > _______________________________________________ > > 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 > > -- > > Best regards, > Konstantin Gribov > > -- Best regards, Konstantin Gribov From tkyjovsk at redhat.com Wed Jan 25 15:39:44 2017 From: tkyjovsk at redhat.com (Tomas Kyjovsky) Date: Wed, 25 Jan 2017 15:39:44 -0500 (EST) Subject: [keycloak-dev] Missing RESTful equivalents for some User Storage SPI methods? In-Reply-To: <61631390.15799261.1485375598299.JavaMail.zimbra@redhat.com> Message-ID: <2107231106.15803127.1485376784991.JavaMail.zimbra@redhat.com> Hello, It seems there are some User Storage SPI methods for which there should be some equivalents in REST API -- but there aren't. 1) Searching for users by attribute: UserQueryProvider.searchForUserByUserAttribute(String attrName, String attrValue, RealmModel realm) 2) Credential types (not 100% sure about these though): CredentialInputValidator.isConfiguredFor(RealmModel realm, UserModel user, String credentialType) CredentialInputUpdater.getDisableableCredentialTypes(RealmModel realm, UserModel user) CredentialInputUpdater.disableCredentialType(RealmModel realm, UserModel user, String credentialType) Does it make sense to add these? Tomas From tkyjovsk at redhat.com Wed Jan 25 15:47:27 2017 From: tkyjovsk at redhat.com (Tomas Kyjovsky) Date: Wed, 25 Jan 2017 15:47:27 -0500 (EST) Subject: [keycloak-dev] Missing RESTful equivalents for some User Storage SPI methods? In-Reply-To: <2107231106.15803127.1485376784991.JavaMail.zimbra@redhat.com> References: <2107231106.15803127.1485376784991.JavaMail.zimbra@redhat.com> Message-ID: <966319612.15804808.1485377247022.JavaMail.zimbra@redhat.com> 3) bulk update UserBulkUpdateProvider.grantToAllUsers(RealmModel realm, RoleModel role) ----- Original Message ----- > Hello, > > It seems there are some User Storage SPI methods for which there should be > some equivalents in REST API -- but there aren't. > > > 1) Searching for users by attribute: > > UserQueryProvider.searchForUserByUserAttribute(String attrName, String > attrValue, RealmModel realm) > > > 2) Credential types (not 100% sure about these though): > > CredentialInputValidator.isConfiguredFor(RealmModel realm, UserModel user, > String credentialType) > > CredentialInputUpdater.getDisableableCredentialTypes(RealmModel realm, > UserModel user) > CredentialInputUpdater.disableCredentialType(RealmModel realm, UserModel > user, String credentialType) > > > Does it make sense to add these? > > > Tomas > From bburke at redhat.com Wed Jan 25 16:26:56 2017 From: bburke at redhat.com (Bill Burke) Date: Wed, 25 Jan 2017 16:26:56 -0500 Subject: [keycloak-dev] Missing RESTful equivalents for some User Storage SPI methods? In-Reply-To: <2107231106.15803127.1485376784991.JavaMail.zimbra@redhat.com> References: <2107231106.15803127.1485376784991.JavaMail.zimbra@redhat.com> Message-ID: On 1/25/17 3:39 PM, Tomas Kyjovsky wrote: > Hello, > > It seems there are some User Storage SPI methods for which there should be some equivalents in REST API -- but there aren't. > > > 1) Searching for users by attribute: > > UserQueryProvider.searchForUserByUserAttribute(String attrName, String attrValue, RealmModel realm) Used internally only at the moment. > > > 2) Credential types (not 100% sure about these though): > > CredentialInputValidator.isConfiguredFor(RealmModel realm, UserModel user, String credentialType) > > CredentialInputUpdater.getDisableableCredentialTypes(RealmModel realm, UserModel user) Available in user json representation > CredentialInputUpdater.disableCredentialType(RealmModel realm, UserModel user, String credentialType) Yes, there is a REST method for that, but not on the REST client interface. Needs to be added. I'll do that. Good catch. Bill From bburke at redhat.com Wed Jan 25 16:31:37 2017 From: bburke at redhat.com (Bill Burke) Date: Wed, 25 Jan 2017 16:31:37 -0500 Subject: [keycloak-dev] Missing RESTful equivalents for some User Storage SPI methods? In-Reply-To: References: <2107231106.15803127.1485376784991.JavaMail.zimbra@redhat.com> Message-ID: <0dc3286c-9550-0455-d6a9-f79fbf1c1e2c@redhat.com> https://issues.jboss.org/browse/KEYCLOAK-4289 PR incoming On 1/25/17 4:26 PM, Bill Burke wrote: > > On 1/25/17 3:39 PM, Tomas Kyjovsky wrote: >> Hello, >> >> It seems there are some User Storage SPI methods for which there should be some equivalents in REST API -- but there aren't. >> >> >> 1) Searching for users by attribute: >> >> UserQueryProvider.searchForUserByUserAttribute(String attrName, String attrValue, RealmModel realm) > Used internally only at the moment. >> >> 2) Credential types (not 100% sure about these though): >> >> CredentialInputValidator.isConfiguredFor(RealmModel realm, UserModel user, String credentialType) >> >> CredentialInputUpdater.getDisableableCredentialTypes(RealmModel realm, UserModel user) > Available in user json representation > >> CredentialInputUpdater.disableCredentialType(RealmModel realm, UserModel user, String credentialType) > Yes, there is a REST method for that, but not on the REST client > interface. Needs to be added. I'll do that. Good catch. > > Bill > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev From sthorger at redhat.com Thu Jan 26 03:18:34 2017 From: sthorger at redhat.com (Stian Thorgersen) Date: Thu, 26 Jan 2017 09:18:34 +0100 Subject: [keycloak-dev] Keycloak 2.5.1.Final Released Message-ID: We've just released Keycloak 2.5.1.Final! There are no new features to brag about this time, but we did fix a good amount of issues so I recommend everyone to upgrade. This release will also be the basis for the next Red Hat Single-Sign On release. To download the release go to the Keycloak homepage . Before you upgrade refer to the migration guide . From sthorger at redhat.com Thu Jan 26 03:50:50 2017 From: sthorger at redhat.com (Stian Thorgersen) Date: Thu, 26 Jan 2017 09:50:50 +0100 Subject: [keycloak-dev] Test coverage Message-ID: Now that Keycloak 2.5.1 is released we should focus 100% on test coverage/automation before we get started on Keycloak 3. I'd like everyone on the team to help out with reviewing test coverage and creating JIRAs for areas that are not covered. Let's not spend to much time on this part and I hope we can complete it be early next week. Once we've got an understanding of what areas that needs expanding on we'll prioritize and start working on more test coverage, while QE focus on more test automation. We only have ~2 weeks set aside to this so let's focus on this and not get distracted by starting writing more code ;) From gambol99 at gmail.com Thu Jan 26 06:09:04 2017 From: gambol99 at gmail.com (gambol) Date: Thu, 26 Jan 2017 11:09:04 +0000 Subject: [keycloak-dev] Keycloak v3.0.0 Message-ID: Hiya Just a quick question .. I was wondering if the up coming v3.0.0 release will come with UMA enabled for the admin console, providing fine grain support. Rohith From sthorger at redhat.com Thu Jan 26 06:27:17 2017 From: sthorger at redhat.com (Stian Thorgersen) Date: Thu, 26 Jan 2017 12:27:17 +0100 Subject: [keycloak-dev] Keycloak v3.0.0 In-Reply-To: References: Message-ID: Very interesting question. To be honest it's something we have planned to do, including removing the "master" realm concept which would be a fundamental part of it. We should look into it and prototype it, but I doubt we'll deliver on it for 3.x. On 26 January 2017 at 12:09, gambol wrote: > Hiya > > Just a quick question .. I was wondering if the up coming v3.0.0 release > will come with UMA enabled for the admin console, providing fine grain > support. > > Rohith > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > From jm85martins at gmail.com Thu Jan 26 06:32:46 2017 From: jm85martins at gmail.com (Jorge M.) Date: Thu, 26 Jan 2017 11:32:46 +0000 Subject: [keycloak-dev] Custom user federation after 2.5.x Message-ID: Hi, It seems that some of the internal SPI's that supported custom federation development in previous versions are now deprecated. I'm looking at the new examples (jpa and simple) but I'm struggling with the registration method. My problem is that to use a custom webservice or a jpa implementation, I need to know the basic user information at that point in order to do the registration on my federation (name, email, username, ...) as the schema or WS as non nullable / mandatory fields. Is there any way to get that managed data at that point? (In the past I used a solution based on TxAwareLDAPUserModelDelegate) >From the jpa example: @Override public UserModel addUser(RealmModel realm, String username) { UserEntity entity = new UserEntity(); entity.setId(UUID.randomUUID().toString()); entity.setUsername(username); *//GET first name, last name and email here!!* em.persist(entity); logger.info("added user: " + username); return new UserAdapter(session, realm, model, entity); } Thank you. JM From bburke at redhat.com Thu Jan 26 10:35:29 2017 From: bburke at redhat.com (Bill Burke) Date: Thu, 26 Jan 2017 10:35:29 -0500 Subject: [keycloak-dev] Custom user federation after 2.5.x In-Reply-To: References: Message-ID: <56839658-e602-a89d-9320-ac0754a8c248@redhat.com> I'm sorry, this usecase fell through the cracks when redesigning the SPI. I'm guessing you need something that works with registration, REST API, and admin console? If so, I think this will work. It will be nasty though. Let's say your provider class name is MyUserStorageProvider. 1. Define a value object class that implements UserModel and keeps all updates in memory. Let's call it UserValueObject. 2. Define a class that implements the KeycloakTransaction interface. This class will be responsible for adding the user to the external store just before transaction commit. It will just callback to MyUserStorageProvider. public class AddUserSynchronization implements KeycloakTransaction { MyUserStorageProvider provider; UserValueObject valueObject; public AddUserSynchronization(MyUserStorageProvider provider, UserValueObject valueObject) { this.valueObject = valueObject; this.provider = provider; } public void commit() { this.provider.addUser(UserValueObject valueObject); } } 3. In your MyUserStorageProvider.addUser(RealmModel realm, String usernmae) method, allocate and return the value object and register with the KeycloakTransactionManager. public UserModel addUser(RealmModel realm, String username) { UserValueObject valueObject = new UserValueObject(); StorageId id = new StorageId(providerComponentId, externalIdOfUser); valueObject.setId(id.getId()); valueObject.setUsername(username); session.getTransactionManager().enlistPrepare(new AddUserSynchronization(this, valueObject)); return valueObject; } Does this make sense? On 1/26/17 6:32 AM, Jorge M. wrote: > Hi, > > It seems that some of the internal SPI's that supported custom federation > development in previous versions are now deprecated. > I'm looking at the new examples (jpa and simple) but I'm struggling with > the registration method. > My problem is that to use a custom webservice or a jpa implementation, I > need to know the basic user information at that point in order to do the > registration on my federation (name, email, username, ...) as the schema or > WS as non nullable / mandatory fields. > Is there any way to get that managed data at that point? (In the past I > used a solution based on TxAwareLDAPUserModelDelegate) > > >From the jpa example: > > @Override > public UserModel addUser(RealmModel realm, String username) { > UserEntity entity = new UserEntity(); > entity.setId(UUID.randomUUID().toString()); > entity.setUsername(username); > > > > *//GET first name, last name and email here!!* > em.persist(entity); > logger.info("added user: " + username); > return new UserAdapter(session, realm, model, entity); > } > > > Thank you. > JM > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev From jm85martins at gmail.com Thu Jan 26 11:42:27 2017 From: jm85martins at gmail.com (Jorge M.) Date: Thu, 26 Jan 2017 16:42:27 +0000 Subject: [keycloak-dev] Custom user federation after 2.5.x In-Reply-To: <56839658-e602-a89d-9320-ac0754a8c248@redhat.com> References: <56839658-e602-a89d-9320-ac0754a8c248@redhat.com> Message-ID: Bill, Thank you! I will try to do that! Cheers, JM 2017-01-26 15:35 GMT+00:00 Bill Burke : > I'm sorry, this usecase fell through the cracks when redesigning the SPI. > > I'm guessing you need something that works with registration, REST API, > and admin console? If so, I think this will work. It will be nasty > though. > > Let's say your provider class name is MyUserStorageProvider. > > 1. Define a value object class that implements UserModel and keeps all > updates in memory. Let's call it UserValueObject. > > 2. Define a class that implements the KeycloakTransaction interface. > This class will be responsible for adding the user to the external store > just before transaction commit. It will just callback to > MyUserStorageProvider. > > public class AddUserSynchronization implements KeycloakTransaction { > > MyUserStorageProvider provider; > > UserValueObject valueObject; > > public AddUserSynchronization(MyUserStorageProvider provider, > UserValueObject valueObject) { > > this.valueObject = valueObject; > > this.provider = provider; > > } > > public void commit() { > > this.provider.addUser(UserValueObject valueObject); > > } > > } > > 3. In your MyUserStorageProvider.addUser(RealmModel realm, String > usernmae) method, allocate and return the value object and register with > the KeycloakTransactionManager. > > > public UserModel addUser(RealmModel realm, String username) { > > UserValueObject valueObject = new UserValueObject(); > > StorageId id = new StorageId(providerComponentId, externalIdOfUser); > > valueObject.setId(id.getId()); > > valueObject.setUsername(username); > > session.getTransactionManager().enlistPrepare(new > AddUserSynchronization(this, valueObject)); > > return valueObject; > > } > > > Does this make sense? > > > > On 1/26/17 6:32 AM, Jorge M. wrote: > > Hi, > > > > It seems that some of the internal SPI's that supported custom federation > > development in previous versions are now deprecated. > > I'm looking at the new examples (jpa and simple) but I'm struggling with > > the registration method. > > My problem is that to use a custom webservice or a jpa implementation, I > > need to know the basic user information at that point in order to do the > > registration on my federation (name, email, username, ...) as the schema > or > > WS as non nullable / mandatory fields. > > Is there any way to get that managed data at that point? (In the past I > > used a solution based on TxAwareLDAPUserModelDelegate) > > > > >From the jpa example: > > > > @Override > > public UserModel addUser(RealmModel realm, String username) { > > UserEntity entity = new UserEntity(); > > entity.setId(UUID.randomUUID().toString()); > > entity.setUsername(username); > > > > > > > > *//GET first name, last name and email here!!* > > em.persist(entity); > > logger.info("added user: " + username); > > return new UserAdapter(session, realm, model, entity); > > } > > > > > > Thank you. > > JM > > _______________________________________________ > > 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 Jan 26 14:14:18 2017 From: sthorger at redhat.com (Stian Thorgersen) Date: Thu, 26 Jan 2017 20:14:18 +0100 Subject: [keycloak-dev] Custom user federation after 2.5.x In-Reply-To: References: <56839658-e602-a89d-9320-ac0754a8c248@redhat.com> Message-ID: Do you have auto flush on or something? The db shouldn't complain until flush/commit occurs which is only after all fields are filled in. On 26 January 2017 at 17:42, Jorge M. wrote: > Bill, > > Thank you! I will try to do that! > > Cheers, > JM > > 2017-01-26 15:35 GMT+00:00 Bill Burke : > > > I'm sorry, this usecase fell through the cracks when redesigning the SPI. > > > > I'm guessing you need something that works with registration, REST API, > > and admin console? If so, I think this will work. It will be nasty > > though. > > > > Let's say your provider class name is MyUserStorageProvider. > > > > 1. Define a value object class that implements UserModel and keeps all > > updates in memory. Let's call it UserValueObject. > > > > 2. Define a class that implements the KeycloakTransaction interface. > > This class will be responsible for adding the user to the external store > > just before transaction commit. It will just callback to > > MyUserStorageProvider. > > > > public class AddUserSynchronization implements KeycloakTransaction { > > > > MyUserStorageProvider provider; > > > > UserValueObject valueObject; > > > > public AddUserSynchronization(MyUserStorageProvider provider, > > UserValueObject valueObject) { > > > > this.valueObject = valueObject; > > > > this.provider = provider; > > > > } > > > > public void commit() { > > > > this.provider.addUser(UserValueObject valueObject); > > > > } > > > > } > > > > 3. In your MyUserStorageProvider.addUser(RealmModel realm, String > > usernmae) method, allocate and return the value object and register with > > the KeycloakTransactionManager. > > > > > > public UserModel addUser(RealmModel realm, String username) { > > > > UserValueObject valueObject = new UserValueObject(); > > > > StorageId id = new StorageId(providerComponentId, externalIdOfUser); > > > > valueObject.setId(id.getId()); > > > > valueObject.setUsername(username); > > > > session.getTransactionManager().enlistPrepare(new > > AddUserSynchronization(this, valueObject)); > > > > return valueObject; > > > > } > > > > > > Does this make sense? > > > > > > > > On 1/26/17 6:32 AM, Jorge M. wrote: > > > Hi, > > > > > > It seems that some of the internal SPI's that supported custom > federation > > > development in previous versions are now deprecated. > > > I'm looking at the new examples (jpa and simple) but I'm struggling > with > > > the registration method. > > > My problem is that to use a custom webservice or a jpa implementation, > I > > > need to know the basic user information at that point in order to do > the > > > registration on my federation (name, email, username, ...) as the > schema > > or > > > WS as non nullable / mandatory fields. > > > Is there any way to get that managed data at that point? (In the past I > > > used a solution based on TxAwareLDAPUserModelDelegate) > > > > > > >From the jpa example: > > > > > > @Override > > > public UserModel addUser(RealmModel realm, String username) { > > > UserEntity entity = new UserEntity(); > > > entity.setId(UUID.randomUUID().toString()); > > > entity.setUsername(username); > > > > > > > > > > > > *//GET first name, last name and email here!!* > > > em.persist(entity); > > > logger.info("added user: " + username); > > > return new UserAdapter(session, realm, model, entity); > > > } > > > > > > > > > Thank you. > > > JM > > > _______________________________________________ > > > keycloak-dev mailing list > > > keycloak-dev at lists.jboss.org > > > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > > _______________________________________________ > > keycloak-dev mailing list > > keycloak-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > From shmuein+keycloak-dev at gmail.com Thu Jan 26 15:33:27 2017 From: shmuein+keycloak-dev at gmail.com (Muein Muzamil) Date: Thu, 26 Jan 2017 14:33:27 -0600 Subject: [keycloak-dev] Keycloak 2.5.1.Final Released In-Reply-To: References: Message-ID: Hi Stian, Did we upload the KeyCloak 2.5.1 artifacts on maven repo? I was trying to upgrade to this version but it seems artificats are missing on maven repo. https://search.maven.org/#search%7Cgav%7C1%7Cg%3A%22org.keycloak%22%20AND%20a%3A%22keycloak-server-spi%22 Regards, Muein On Thu, Jan 26, 2017 at 2:18 AM, Stian Thorgersen wrote: > We've just released Keycloak 2.5.1.Final! There are no new features to brag > about this time, but we did fix a good amount of issues so I recommend > everyone to upgrade. This release will also be the basis for the next Red > Hat Single-Sign On > release. > > To download the release go to the Keycloak homepage > . Before you upgrade refer to the > migration > guide > MigrationFromOlderVersions.html> > . > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > From stevenmirabito at gmail.com Thu Jan 26 16:16:04 2017 From: stevenmirabito at gmail.com (Steven Mirabito) Date: Thu, 26 Jan 2017 21:16:04 +0000 Subject: [keycloak-dev] Password Changes with Kerberos Message-ID: Hi all, I didn't see anything in Jira regarding this, so I figured I'd ask here. I have an organization that uses OpenLDAP and Kerberos to authenticate users, and have set up an LDAP federation provider and enabled Kerberos integration. That part works great, but if I enable write on the federation provider and try to change a user's password, it attempts to update the password through LDAP and not Kerberos. I took a look at LDAPStorageProvider.java and it appears that there isn't support for updating credentials via Kerberos when Kerberos integration is enabled, and the Kerberos federation provider itself doesn't currently support password changes. As this is necessary to enable password changes through Keycloak for my organization, I wanted to reach out and see if there were any suggestions as to how I could go about implementing this and to get any feedback or concerns regarding this feature. It looks fairly simple to implement with the ApacheDS kerberos-client: http://stackoverflow.com/a/34575316 Thanks! -Steven From bruno at abstractj.org Thu Jan 26 20:04:58 2017 From: bruno at abstractj.org (Bruno Oliveira) Date: Thu, 26 Jan 2017 23:04:58 -0200 Subject: [keycloak-dev] SHA1 for checking Keycloak file integrity Message-ID: <20170127010458.GA26932@abstractj.org> Ahoy, for the quickstarts we have to provide a wrapper, which will be responsible to download a specific version of Keycloak and other tasks[1]. For this wrapper we have some scenarios: Scenario #1: User execute the script and manage to download Keycloak Scenario #2: User execute the script and download is interrupted. Which means that next time the script will resume that download Scenario #3: User already downloaded Keycloak and of course she does not want to do it again. For scenario 3, I was thinking about generate a SHA1[2] file for each Keycloak distribution to check the integrity of that file, not only for security, but for consistency. If we just check if file exists, thinking about scenario 2 and 3, we can't tell if that file was corrupted or not. Thoughts? [1] - https://issues.jboss.org/browse/KEYCLOAK-4321 [2] - http://maven.apache.org/plugins/maven-install-plugin/examples/installing-checksums.html -- abstractj From bruno at abstractj.org Thu Jan 26 21:15:19 2017 From: bruno at abstractj.org (Bruno Oliveira) Date: Fri, 27 Jan 2017 00:15:19 -0200 Subject: [keycloak-dev] Keycloak 2.5.1.Final Released In-Reply-To: References: Message-ID: Certainly yes, but I believe it takes 24 h to be updated on Maven central. On Thu, Jan 26, 2017 at 6:33 PM, Muein Muzamil wrote: > Hi Stian, > > Did we upload the KeyCloak 2.5.1 artifacts on maven repo? I was trying to > upgrade to this version but it seems artificats are missing on maven repo. > > https://search.maven.org/#search%7Cgav%7C1%7Cg%3A%22org.keycloak%22%20AND%20a%3A%22keycloak-server-spi%22 > > Regards, > Muein > > On Thu, Jan 26, 2017 at 2:18 AM, Stian Thorgersen > wrote: > >> We've just released Keycloak 2.5.1.Final! There are no new features to brag >> about this time, but we did fix a good amount of issues so I recommend >> everyone to upgrade. This release will also be the basis for the next Red >> Hat Single-Sign On >> release. >> >> To download the release go to the Keycloak homepage >> . Before you upgrade refer to the >> migration >> guide >> > MigrationFromOlderVersions.html> >> . >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev -- - abstractj From sthorger at redhat.com Fri Jan 27 03:13:04 2017 From: sthorger at redhat.com (Stian Thorgersen) Date: Fri, 27 Jan 2017 09:13:04 +0100 Subject: [keycloak-dev] SHA1 for checking Keycloak file integrity In-Reply-To: <20170127010458.GA26932@abstractj.org> References: <20170127010458.GA26932@abstractj.org> Message-ID: Checksums are already generated and Maven central already have checksums for all files: http://search.maven.org/remotecontent?filepath=org/keycloak/keycloak-server-dist/2.5.1.Final/keycloak-server-dist-2.5.1.Final.zip http://search.maven.org/remotecontent?filepath=org/keycloak/keycloak-server-dist/2.5.1.Final/keycloak-server-dist-2.5.1.Final.zip.sha1 The wrapper script should download from there and not from downloads.jboss.org as it's slower. We will add checksums to downloads.jboss.org and the website as well at some point. On 27 January 2017 at 02:04, Bruno Oliveira wrote: > Ahoy, for the quickstarts we have to provide a wrapper, which will be > responsible to download a specific version of Keycloak and other > tasks[1]. > > For this wrapper we have some scenarios: > > Scenario #1: User execute the script and manage to download Keycloak > Scenario #2: User execute the script and download is interrupted. Which > means that next time the script will resume that download > Scenario #3: User already downloaded Keycloak and of course she does not > want to do it again. > > For scenario 3, I was thinking about generate a SHA1[2] file for each > Keycloak distribution to check the integrity of that file, not only for > security, but for consistency. If we just check if file exists, thinking > about scenario 2 and 3, we can't tell if that file was corrupted or not. > > Thoughts? > > > > [1] - https://issues.jboss.org/browse/KEYCLOAK-4321 > [2] - http://maven.apache.org/plugins/maven-install-plugin/ > examples/installing-checksums.html > > -- > > abstractj > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > From sthorger at redhat.com Fri Jan 27 03:47:37 2017 From: sthorger at redhat.com (Stian Thorgersen) Date: Fri, 27 Jan 2017 09:47:37 +0100 Subject: [keycloak-dev] SHA1 for checking Keycloak file integrity In-Reply-To: References: <20170127010458.GA26932@abstractj.org> Message-ID: We'll look at adding checksums to downloads/website for 3.0.0.CR1, but not right now as we need to focus the testsuite. On 27 January 2017 at 09:13, Stian Thorgersen wrote: > Checksums are already generated and Maven central already have checksums > for all files: > > http://search.maven.org/remotecontent?filepath=org/ > keycloak/keycloak-server-dist/2.5.1.Final/keycloak-server- > dist-2.5.1.Final.zip > http://search.maven.org/remotecontent?filepath=org/ > keycloak/keycloak-server-dist/2.5.1.Final/keycloak-server- > dist-2.5.1.Final.zip.sha1 > > The wrapper script should download from there and not from > downloads.jboss.org as it's slower. > > We will add checksums to downloads.jboss.org and the website as well at > some point. > > On 27 January 2017 at 02:04, Bruno Oliveira wrote: > >> Ahoy, for the quickstarts we have to provide a wrapper, which will be >> responsible to download a specific version of Keycloak and other >> tasks[1]. >> >> For this wrapper we have some scenarios: >> >> Scenario #1: User execute the script and manage to download Keycloak >> Scenario #2: User execute the script and download is interrupted. Which >> means that next time the script will resume that download >> Scenario #3: User already downloaded Keycloak and of course she does not >> want to do it again. >> >> For scenario 3, I was thinking about generate a SHA1[2] file for each >> Keycloak distribution to check the integrity of that file, not only for >> security, but for consistency. If we just check if file exists, thinking >> about scenario 2 and 3, we can't tell if that file was corrupted or not. >> >> Thoughts? >> >> >> >> [1] - https://issues.jboss.org/browse/KEYCLOAK-4321 >> [2] - http://maven.apache.org/plugins/maven-install-plugin/example >> s/installing-checksums.html >> >> -- >> >> abstractj >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> > > From bruno at abstractj.org Fri Jan 27 04:07:31 2017 From: bruno at abstractj.org (Bruno Oliveira) Date: Fri, 27 Jan 2017 09:07:31 +0000 Subject: [keycloak-dev] SHA1 for checking Keycloak file integrity In-Reply-To: References: <20170127010458.GA26932@abstractj.org> Message-ID: Thanks Stian, that helps. On Fri, Jan 27, 2017, 6:47 AM Stian Thorgersen wrote: > We'll look at adding checksums to downloads/website for 3.0.0.CR1, but not > right now as we need to focus the testsuite. > > On 27 January 2017 at 09:13, Stian Thorgersen wrote: > > Checksums are already generated and Maven central already have checksums > for all files: > > > http://search.maven.org/remotecontent?filepath=org/keycloak/keycloak-server-dist/2.5.1.Final/keycloak-server-dist-2.5.1.Final.zip > > http://search.maven.org/remotecontent?filepath=org/keycloak/keycloak-server-dist/2.5.1.Final/keycloak-server-dist-2.5.1.Final.zip.sha1 > > The wrapper script should download from there and not from > downloads.jboss.org as it's slower. > > We will add checksums to downloads.jboss.org and the website as well at > some point. > > On 27 January 2017 at 02:04, Bruno Oliveira wrote: > > Ahoy, for the quickstarts we have to provide a wrapper, which will be > responsible to download a specific version of Keycloak and other > tasks[1]. > > For this wrapper we have some scenarios: > > Scenario #1: User execute the script and manage to download Keycloak > Scenario #2: User execute the script and download is interrupted. Which > means that next time the script will resume that download > Scenario #3: User already downloaded Keycloak and of course she does not > want to do it again. > > For scenario 3, I was thinking about generate a SHA1[2] file for each > Keycloak distribution to check the integrity of that file, not only for > security, but for consistency. If we just check if file exists, thinking > about scenario 2 and 3, we can't tell if that file was corrupted or not. > > Thoughts? > > > > [1] - https://issues.jboss.org/browse/KEYCLOAK-4321 > [2] - > http://maven.apache.org/plugins/maven-install-plugin/examples/installing-checksums.html > > -- > > abstractj > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > > From sblanc at redhat.com Fri Jan 27 04:25:11 2017 From: sblanc at redhat.com (Sebastien Blanc) Date: Fri, 27 Jan 2017 10:25:11 +0100 Subject: [keycloak-dev] Publishing "App Server + installed adapter" artifacts to Maven Central ? Message-ID: Hi, For testing the quickstarts, we need to deploy them on an app server that has the adapter installed. This app server will then be managed by Arquillian. We have already in our testsuite a project that creates these server zips : https://github.com/keycloak/keycloak/tree/master/testsuite/integration-arquillian/servers/app-server . But these artifacts are currently not published to Maven Central. Is there any particular reasons that we don't do it ? I think it will be really useful and would simplify the "quickstart testsuite framework". I can create a ticket for that if needed. Sebi From sthorger at redhat.com Fri Jan 27 06:01:38 2017 From: sthorger at redhat.com (Stian Thorgersen) Date: Fri, 27 Jan 2017 12:01:38 +0100 Subject: [keycloak-dev] Publishing "App Server + installed adapter" artifacts to Maven Central ? In-Reply-To: References: Message-ID: -1 Those are for internal use only. I'd rather see the quickstart tests able to download a specific WF version + ability to install a specific KC adapter version. On 27 January 2017 at 10:25, Sebastien Blanc wrote: > Hi, > > For testing the quickstarts, we need to deploy them on an app server that > has the adapter installed. This app server will then be managed by > Arquillian. > We have already in our testsuite a project that creates these server zips : > https://github.com/keycloak/keycloak/tree/master/testsuite/integration- > arquillian/servers/app-server > . But these artifacts are currently not published to Maven Central. > Is there any particular reasons that we don't do it ? I think it will be > really useful and would simplify the "quickstart testsuite framework". > I can create a ticket for that if needed. > > Sebi > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > From sthorger at redhat.com Fri Jan 27 07:45:37 2017 From: sthorger at redhat.com (Stian Thorgersen) Date: Fri, 27 Jan 2017 13:45:37 +0100 Subject: [keycloak-dev] BOMS for adapter and server-spi development added Message-ID: https://issues.jboss.org/browse/KEYCLOAK-4195 From sthorger at redhat.com Fri Jan 27 07:50:55 2017 From: sthorger at redhat.com (Stian Thorgersen) Date: Fri, 27 Jan 2017 13:50:55 +0100 Subject: [keycloak-dev] Ability to run tests from within Keycloak server added Message-ID: I've added the option to run pieces of a test from within the Keycloak server. This is useful when you need some details that is only internally available or if you need to execute something on the server. It's pretty simply all you need is to add an Arquillian deployment. This is required to add classes for the code you want to run. An example is added to: https://github.com/keycloak/keycloak/blob/master/testsuite/integration-arquillian/tests/base/src/test/java/org/keycloak/testsuite/runonserver/RunOnServerTest.java You can run stuff on the server, fetch stuff from the server and even do assertions on the server which is sent back to the client side. Finally there's some helpers in: https://github.com/keycloak/keycloak/blob/master/testsuite/integration-arquillian/servers/auth-server/services/testsuite-providers/src/main/java/org/keycloak/testsuite/runonserver/RunHelpers.java These makes it easy to fetch internal realm and component settings. We can add more here as needed. Take a look at RealmTest for an example on how to use these. Finally it's pretty nice to use remote WildFly container when writing tests like these. To do that: * Build including dist (mvn clean install -Pdistribution) * Run "testsuite/integration-arquillian/servers/auth-server/jboss/wildfly/target/unpacked/keycloak-3.0.0.CR1-SNAPSHOT/bin/standalone.sh -Djboss.socket.binding.port-offset=100" * In IntelliJ select view -> Tool Windows -> Maven * In the open window expand profiles and select auth-server-remote Now you can run the test and it will use the remote container rather than embedded Undertow. From tech at psynd.net Fri Jan 27 08:31:19 2017 From: tech at psynd.net (Tech) Date: Fri, 27 Jan 2017 14:31:19 +0100 Subject: [keycloak-dev] keycloak-dev Digest, Vol 43, Issue 17 In-Reply-To: References: Message-ID: Dear experts, from version 2.5.0 we noticed the lack in the examples of: keycloak-examples-2.4.0.Final/providers/federation-provide Will this integrated back from version 2.6.0? Thanks! From mark.pardijs at topicus.nl Fri Jan 27 09:24:57 2017 From: mark.pardijs at topicus.nl (Mark Pardijs) Date: Fri, 27 Jan 2017 14:24:57 +0000 Subject: [keycloak-dev] Validation of IdP SAML signatures using KeyInfo Message-ID: <8646658B-0433-41A6-B335-81B6A3E5A558@topicus.nl> Hi, We use a SAML IdP which is configured in Keycloak as federated IdP, and I?ve a question concerning the validation of SAML signatures. In Keycloaks Identity provider config page, the validating X509 Certificates can be configured, with description ?The certificate in PEM format that must be used to check for signatures. Multiple certificates can be entered, separated by comma (,).? but in the code, I see that for checking the signatures a hardcoded key locator is used, which does not use the keyName provided in the SAML but always returns the first configured certificate. See org.keycloak.broker.saml.SAMLEndpoint.Binding#getIDPKeyLocator which returns a HardcodedKeyLocator for details. This code is recently added to solve https://issues.jboss.org/browse/KEYCLOAK-1881, see commit https://github.com/keycloak/keycloak/commit/70a8255eae0af64628f07326df1c73d86c1b9fd2. My two questions concerning this approach: 1. Keycloak is currently expecting a element with a in the incoming SAML message, while this is not a required element in the SAML specs. Are there plans to check the signature against the configured X509 certificates without having to provide a KeyInfo element, currently I?m facing a NullPointer exception when sending a SAMLResponse without KeyInfo element. 2. What?s the idea behind the HardcodedKeyLocator, it doesn?t seem to match with the multiple keys configuration option in Keycloaks frontend. Is this a preliminary approach which should be extended? Hope to hear your thoughts on this! Mark From mstrukel at redhat.com Fri Jan 27 09:43:16 2017 From: mstrukel at redhat.com (Marko Strukelj) Date: Fri, 27 Jan 2017 15:43:16 +0100 Subject: [keycloak-dev] keycloak-dev Digest, Vol 43, Issue 17 In-Reply-To: References: Message-ID: This mailing list is exclusively dedicated to discussions around Keycloak development. Please resend your question to keycloak-user mailing list [1] which is a place for any questions related to installing, setting up, and using Keycloak. [1] https://lists.jboss.org/mailman/listinfo/keycloak-user On Fri, Jan 27, 2017 at 2:31 PM, Tech wrote: > Dear experts, > > from version 2.5.0 we noticed the lack in the examples of: > > keycloak-examples-2.4.0.Final/providers/federation-provide > > Will this integrated back from version 2.6.0? > > Thanks! > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > From tkyjovsk at redhat.com Fri Jan 27 10:43:20 2017 From: tkyjovsk at redhat.com (Tomas Kyjovsky) Date: Fri, 27 Jan 2017 10:43:20 -0500 (EST) Subject: [keycloak-dev] Publishing "App Server + installed adapter" artifacts to Maven Central ? In-Reply-To: References: Message-ID: <2034708391.16641248.1485531800273.JavaMail.zimbra@redhat.com> These artifacts were intended for the testsuite. Not sure it's a good idea to publish them. Some server configs (ssl, threads, logging, etc) may differ depending on params/profiles you run the module with - depending on aspects which are tested. Tomas ----- Original Message ----- > Hi, > > For testing the quickstarts, we need to deploy them on an app server that > has the adapter installed. This app server will then be managed by > Arquillian. > We have already in our testsuite a project that creates these server zips : > https://github.com/keycloak/keycloak/tree/master/testsuite/integration-arquillian/servers/app-server > . But these artifacts are currently not published to Maven Central. > Is there any particular reasons that we don't do it ? I think it will be > really useful and would simplify the "quickstart testsuite framework". > I can create a ticket for that if needed. > > Sebi > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > From hmlnarik at redhat.com Mon Jan 30 03:47:59 2017 From: hmlnarik at redhat.com (Hynek Mlnarik) Date: Mon, 30 Jan 2017 09:47:59 +0100 Subject: [keycloak-dev] Validation of IdP SAML signatures using KeyInfo In-Reply-To: <8646658B-0433-41A6-B335-81B6A3E5A558@topicus.nl> References: <8646658B-0433-41A6-B335-81B6A3E5A558@topicus.nl> Message-ID: This mailing list is exclusively dedicated to discussions around Keycloak development. Please resend your question to keycloak-user mailing list [1] which is a place for any questions related to installing, setting up, and using Keycloak. For item 1, please file a JIRA and state as much details of NPE and your configuration as possible. [1] https://lists.jboss.org/mailman/listinfo/keycloak-user On Fri, Jan 27, 2017 at 3:24 PM, Mark Pardijs wrote: > Hi, > > We use a SAML IdP which is configured in Keycloak as federated IdP, and I?ve a question concerning the validation of SAML signatures. In Keycloaks Identity provider config page, the validating X509 Certificates can be configured, with description ?The certificate in PEM format that must be used to check for signatures. Multiple certificates can be entered, separated by comma (,).? but in the code, I see that for checking the signatures a hardcoded key locator is used, which does not use the keyName provided in the SAML but always returns the first configured certificate. See org.keycloak.broker.saml.SAMLEndpoint.Binding#getIDPKeyLocator which returns a HardcodedKeyLocator for details. > > This code is recently added to solve https://issues.jboss.org/browse/KEYCLOAK-1881, see commit https://github.com/keycloak/keycloak/commit/70a8255eae0af64628f07326df1c73d86c1b9fd2. > > My two questions concerning this approach: > > > 1. Keycloak is currently expecting a element with a in the incoming SAML message, while this is not a required element in the SAML specs. Are there plans to check the signature against the configured X509 certificates without having to provide a KeyInfo element, currently I?m facing a NullPointer exception when sending a SAMLResponse without KeyInfo element. > 2. What?s the idea behind the HardcodedKeyLocator, it doesn?t seem to match with the multiple keys configuration option in Keycloaks frontend. Is this a preliminary approach which should be extended? > > Hope to hear your thoughts on this! > > Mark > > > > > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev -- --Hynek From mposolda at redhat.com Mon Jan 30 03:51:25 2017 From: mposolda at redhat.com (Marek Posolda) Date: Mon, 30 Jan 2017 09:51:25 +0100 Subject: [keycloak-dev] Password Changes with Kerberos In-Reply-To: References: Message-ID: Yes, we don't yet have support for this. The problems I can see is: - It seems that both ApacheDS based solution and "embeddded kpasswd process" based solution requires the old password of user. But In Keycloak we don't usually have the old password of user (eg. when admin changes password, or during UPDATE_PASSWORD require action etc. Just the account management is the only place where existing password is available). - Another question is, if ApacheDS based approach really uses just the kerberos standards and works for the other Kerberos vendors besides ApacheDS (MSAD, FreeIPA, MIT Kerberos) Feel free to create a JIRA, however not sure if we add that in the near future... Marek On 26/01/17 22:16, Steven Mirabito wrote: > Hi all, > > I didn't see anything in Jira regarding this, so I figured I'd ask here. I > have an organization that uses OpenLDAP and Kerberos to authenticate users, > and have set up an LDAP federation provider and enabled Kerberos > integration. That part works great, but if I enable write on the federation > provider and try to change a user's password, it attempts to update the > password through LDAP and not Kerberos. I took a look > at LDAPStorageProvider.java and it appears that there isn't support for > updating credentials via Kerberos when Kerberos integration is enabled, and > the Kerberos federation provider itself doesn't currently support password > changes. > > As this is necessary to enable password changes through Keycloak for my > organization, I wanted to reach out and see if there were any suggestions > as to how I could go about implementing this and to get any feedback or > concerns regarding this feature. It looks fairly simple to implement with > the ApacheDS kerberos-client: http://stackoverflow.com/a/34575316 > > Thanks! > > -Steven > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev From tech at psynd.net Mon Jan 30 06:20:08 2017 From: tech at psynd.net (Tech) Date: Mon, 30 Jan 2017 12:20:08 +0100 Subject: [keycloak-dev] Error deploying Keycloak over MariaDB Message-ID: Hello, I need to deploy keycloak over MariaDB: I downloaded the latest version of Keycloak, 2.5.1 and I want to connect to my DB running over MariaDB. I'm using the same JDBC driver that I also use for other applications: I start WildFly, I open the console and I go to Deployment. I load the mariadb-java-client-1.5.5.jar. The driver is correctly loaded. I shutdown the server, I edit the standalone.xml and I add: jdbc:mariadb://localhost:3306/KcTbs mariadb-java-client-1.5.5.jar org.mariadb.jdbc.Driver KcUsr KcPwd true false I restart the server and I can see the new datasource. I open it, I go to "Connection" and I receive the following error when I try to test the connection: 12:12:51,248 ERROR [org.jboss.as.controller.management-operation] (management task-7) WFLYCTL0013: Operation ("test-connection-in-pool") failed - address: ([ ("subsystem" => "datasources"), ("data-source" => "MariaDBDS") ]) - failure description: "WFLYJCA0040: failed to invoke operation: WFLYJCA0047: Connection is not valid" Any idea? From mauriciogiacomini at hotmail.com Tue Jan 31 07:27:50 2017 From: mauriciogiacomini at hotmail.com (=?iso-8859-1?Q?Maur=EDcio_Giacomini_Penteado?=) Date: Tue, 31 Jan 2017 12:27:50 +0000 Subject: [keycloak-dev] The best place to get the Request Party Token Message-ID: Please, I am trying use policy enforcer on my project but I am not having successful. My app are loging correctly by the two codes: code 1) var initOptions = { onLoad: 'check-sso', responseMode: 'query', flow: 'standard' }; keycloak.init(initOptions).success(function (authenticated) { ... ... ... } ... and by an angular interceptor: code 2) factory('authInterceptor', ['$q', 'keycloak', function ($q, keycloak) { return { request: function (config) { var deferred = $q.defer(); keycloak.updateToken(30).success(function () { config.headers = config.headers || {}; config.headers.Authorization = 'Bearer ' + keycloak.token; deferred.resolve(config); }).error(function () { deferred.reject('Failed to refresh token'); }); return deferred.promise; } }; }]) But, if I enable policy enforcer my service calls are unauthorazed. It seems to me the best option to use the policy enforcer, in the exact moment that I receive the access token I must change this by an rpt token and from this point forward all my protected service calls will have access to my rpt token. I have no difficulty using the keycloak-authz.js library to get the rpt token. However, to get this process up and running, I must send a protected resource call and intercept the "WWW-Authenticate" header. I do not see how I can get the rpt token with the codes listed above and If I try to force the rtp token as an authorization header my interceptor it runs and changes the header for my access to the token again. There is a way to get the rpt token where I am trying or do I have any misconceptions it can not be done in this place? I will be very grateful if anyone can help me. Kind regards, Maur?cio Penteado. From tkyjovsk at redhat.com Tue Jan 31 19:03:58 2017 From: tkyjovsk at redhat.com (Tomas Kyjovsky) Date: Tue, 31 Jan 2017 19:03:58 -0500 (EST) Subject: [keycloak-dev] UserStorageProvider.preRemove() hooks In-Reply-To: <190323935.18279073.1485906567921.JavaMail.zimbra@redhat.com> Message-ID: <290094629.18279886.1485907438735.JavaMail.zimbra@redhat.com> UserStorageProvider interace has 3 preRemove methods: void preRemove(RealmModel realm) void preRemove(RealmModel realm, GroupModel group) void preRemove(RealmModel realm, RoleModel role) These are triggered when a realm in which the provider is configured, or a group/role in that realm, are deleted. For removal of individual entities they are triggered as expected but the problem might be when removing a realm: only the preRemove for realm is triggered - not for the groups/roles it contains. Not sure if this is a bug. Maybe it's just a matter of documentation, to let people know they need to add logic for removing groups/roles to the "realm" preRemove method too. Tomas