From petervn1 at yahoo.com Thu Sep 1 03:38:10 2016 From: petervn1 at yahoo.com (Peter Nalyvayko) Date: Thu, 1 Sep 2016 07:38:10 +0000 (UTC) Subject: [keycloak-dev] OIDC external provider's multiple signing keys are causing signature validation errors References: <302658655.3824657.1472715490205.ref@mail.yahoo.com> Message-ID: <302658655.3824657.1472715490205@mail.yahoo.com> Hello, I have an external OIDC provider that uses multiple signing keys to sign the id_tokens it issues.?According to the OIDC spec (https://openid.net/specs/openid-connect-discovery-1_0.html), "jwks_uri" is an "URL of the OP's JSON Web Key Set. The set contains the signing key(s) that RP uses to validate signature from the OP".?Now, there is only a single validating public key ?shown on the OIDC external provider configuration page. When importing OIDC provider configuration using OIDC provider metadata uri, keycloak picks the first JWK which "use" parameter value is set to "sig". In my case, all JWKs in the JWK Set have their "use" member set to "sig". I took a cursory look at the JWKS spec (https://tools.ietf.org/html/draft-ietf-jose-json-web-key-41#section-4.2) and based on what I've read it seems there could be more than one key with the same "use" parameter. Shouldn't keycloak store all signing keys instead of just one, and use the value of the "kid" parameter from the provider's auth response to choose a corresponding public key to do the validation? Regards,--Peter -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160901/bf706502/attachment.html From mposolda at redhat.com Thu Sep 1 04:42:27 2016 From: mposolda at redhat.com (Marek Posolda) Date: Thu, 1 Sep 2016 10:42:27 +0200 Subject: [keycloak-dev] OIDC external provider's multiple signing keys are causing signature validation errors In-Reply-To: <302658655.3824657.1472715490205@mail.yahoo.com> References: <302658655.3824657.1472715490205.ref@mail.yahoo.com> <302658655.3824657.1472715490205@mail.yahoo.com> Message-ID: <57C7E9F3.6090104@redhat.com> Hi, could you please create JIRA for it and mark component as "Specification - OIDC" ? I agree the current behaviour has space for improvements. There is also one related performance issue as currently we "compute" the PublicKey from PEM during each login of federated user. Same goes for client authentication with signed JWT. I think we should have some "PublicKeyCacheProvider" of public keys, which will be used by both IdentityProviders and Clients. Also we should be able to "retrieve" new keys from "jwks_uri" on demand when key with corresponding "kid" is not found (currently we do it always just when IdentityProvider config is imported, or when OIDC client is registered). Thanks, Marek On 01/09/16 09:38, Peter Nalyvayko wrote: > Hello, > > I have an external OIDC provider that uses multiple signing keys to > sign the id_tokens it issues. > According to the OIDC spec > (https://openid.net/specs/openid-connect-discovery-1_0.html), > "jwks_uri" is an "URL of the OP's JSON Web Key Set. The set contains > the signing key(s) that RP uses to validate signature from the OP". > Now, there is only a single validating public key shown on the OIDC > external provider configuration page. When importing OIDC provider > configuration using OIDC provider metadata uri, keycloak picks the > first JWK which "use" parameter value is set to "sig". In my case, all > JWKs in the JWK Set have their "use" member set to "sig". I took a > cursory look at the JWKS spec > (https://tools.ietf.org/html/draft-ietf-jose-json-web-key-41#section-4.2) > and based on what I've read it seems there could be more than one key > with the same "use" parameter. Shouldn't keycloak store all signing > keys instead of just one, and use the value of the "kid" parameter > from the provider's auth response to choose a corresponding public key > to do the validation? > > Regards, > --Peter > > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160901/61e301a0/attachment.html From j.kamal at ymail.com Thu Sep 1 10:07:38 2016 From: j.kamal at ymail.com (Kamal Jagadevan) Date: Thu, 1 Sep 2016 14:07:38 +0000 (UTC) Subject: [keycloak-dev] Any clue regarding javax.ws.rs.core.UriBuilderException: empty host name References: <432485795.3282038.1472738858985.ref@mail.yahoo.com> Message-ID: <432485795.3282038.1472738858985@mail.yahoo.com> Hi Folks....?? We had gone with Keycloak implementation in one of our production instance with Keycloak 1.6.1.FinalAnd observing the empty host name log filling up the node consistently.... I know we have to upgrade to latest version but is there any clue or direction to find or block this error message filling up the node.Any help in this regards will be appreciated. ThanksKamal specific bothering log ? 12:46:23 xxx docker/"keycloak"[1051]: #033[0m#033[33m12:46:23,285 WARN? [org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher] (default task-16) Failed to parse request.: javax.ws.rs.core.UriBuilderException: Failed to create URI: null ? 12:46:23 xxx docker/"keycloak"[1051]: #011at org.jboss.resteasy.specimpl.ResteasyUriBuilder.buildFromValues(ResteasyUriBuilder.java:746) ? 12:46:23 xxx docker/"keycloak"[1051]: #011at org.jboss.resteasy.specimpl.ResteasyUriBuilder.build(ResteasyUriBuilder.java:718) ? 12:46:23 xxx docker/"keycloak"[1051]: #011at org.jboss.resteasy.spi.ResteasyUriInfo.initialize(ResteasyUriInfo.java:58) ? 12:46:23 xxx docker/"keycloak"[1051]: #011at org.jboss.resteasy.spi.ResteasyUriInfo.(ResteasyUriInfo.java:53) ? 12:46:23 xxx docker/"keycloak"[1051]: #011at org.jboss.resteasy.plugins.server.servlet.ServletUtil.extractUriInfo(ServletUtil.java:41) ? 12:46:23 xxx docker/"keycloak"[1051]: #011at org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:199) ? 12:46:23 xxx docker/"keycloak"[1051]: #011at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:56) ? 12:46:23 xxx docker/"keycloak"[1051]: #011at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:51) ? 12:46:23 xxx docker/"keycloak"[1051]: #011at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) ? 12:46:23 xxx docker/"keycloak"[1051]: #011at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:86) ? 12:46:23 xxx docker/"keycloak"[1051]: #011at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:130) ? 12:46:23 xxx docker/"keycloak"[1051]: #011at org.keycloak.services.filters.KeycloakSessionServletFilter.doFilter(KeycloakSessionServletFilter.java:61) ? 12:46:23 xxx docker/"keycloak"[1051]: #011at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60) ? 12:46:23 xxx docker/"keycloak"[1051]: #011at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132) ? 12:46:23 xxx docker/"keycloak"[1051]: #011at io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:85) ? 12:46:23 xxx docker/"keycloak"[1051]: #011at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62) ? 12:46:23 xxx docker/"keycloak"[1051]: #011at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) ? 12:46:23 xxx docker/"keycloak"[1051]: #011at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78) ? 12:46:23 xxx docker/"keycloak"[1051]: #011at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) ? 12:46:23 xxx docker/"keycloak"[1051]: #011at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131) ? 12:46:23 xxx docker/"keycloak"[1051]: #011at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57) ? 12:46:23 xxx docker/"keycloak"[1051]: #011at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) ? 12:46:23 xxx docker/"keycloak"[1051]: #011at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46) ? 12:46:23 xxx docker/"keycloak"[1051]: #011at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64) ? 12:46:23 xxx docker/"keycloak"[1051]: #011at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:58) ? 12:46:23 xxx docker/"keycloak"[1051]: #011at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:72) ? 12:46:23 xxx docker/"keycloak"[1051]: #011at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50) ? 12:46:23 xxx docker/"keycloak"[1051]: #011at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:76) ? 12:46:23 xxx docker/"keycloak"[1051]: #011at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) ? 12:46:23 xxx docker/"keycloak"[1051]: #011at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61) ? 12:46:23 xxx docker/"keycloak"[1051]: #011at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) ? 12:46:23 xxx docker/"keycloak"[1051]: #011at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) ? 12:46:23 xxx docker/"keycloak"[1051]: #011at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:282) ? 12:46:23 xxx docker/"keycloak"[1051]: #011at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:261) ? 12:46:23 xxx docker/"keycloak"[1051]: #011at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:80) ? 12:46:23 xxx docker/"keycloak"[1051]: #011at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:172) ? 12:46:23 xxx docker/"keycloak"[1051]: #011at io.undertow.server.Connectors.executeRootHandler(Connectors.java:199) ? 12:46:23 xxx docker/"keycloak"[1051]: #011at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:774) ? 12:46:23 xxx docker/"keycloak"[1051]: #011at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) ? 12:46:23 xxx docker/"keycloak"[1051]: #011at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) ? 12:46:23 xxx docker/"keycloak"[1051]: #011at java.lang.Thread.run(Thread.java:745) ? 12:46:23 xxx docker/"keycloak"[1051]: Caused by: javax.ws.rs.core.UriBuilderException: empty host name ? 12:46:23 xxx docker/"keycloak"[1051]: #011at org.jboss.resteasy.specimpl.ResteasyUriBuilder.buildString(ResteasyUriBuilder.java:537) ? 12:46:23 xxx docker/"keycloak"[1051]: #011at org.jboss.resteasy.specimpl.ResteasyUriBuilder.buildFromValues(ResteasyUriBuilder.java:740) ? 12:46:23 xxx docker/"keycloak"[1051]: #011... 40 more ? 12:46:23 xxx docker/"keycloak"[1051]: -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160901/dd87ec71/attachment-0001.html From singhrasster at gmail.com Fri Sep 2 01:11:30 2016 From: singhrasster at gmail.com (Rashmi Singh) Date: Fri, 2 Sep 2016 00:11:30 -0500 Subject: [keycloak-dev] Edit value contained in NameID field of SAML response In-Reply-To: References: Message-ID: Can someone please give some pointers on if this is even possible? If yes, then what needs to be done for this? Its an urgent requirement for us, so any help on this will be very much appreciated. On Wed, Aug 31, 2016 at 8:28 AM, Rashmi Singh wrote: > Any help on this? > > On Mon, Aug 29, 2016 at 9:32 PM, Rashmi Singh > wrote: > >> I have a keycloak app that calls an external TokenValidator for >> authentication. This TokenValidator returns a SP specific username value. I >> want my SAML response to contain this value in the NameID field. My >> question is how do I edit the SAML response to change the value in NameID >> field to this value? >> >> Any insight into how to edit the NameID field in the SAML response? >> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160902/21e56b05/attachment.html From postmaster at lists.jboss.org Fri Sep 2 03:21:20 2016 From: postmaster at lists.jboss.org (Bounced mail) Date: Fri, 2 Sep 2016 12:51:20 +0530 Subject: [keycloak-dev] Returned mail: see transcript for details Message-ID: <201609020722.u827MsX5023918@lists01.dmz-a.mwc.hst.phx2.redhat.com> The original message was received at Fri, 2 Sep 2016 12:51:20 +0530 from lists.jboss.org [198.55.242.197] ----- The following addresses had permanent fatal errors ----- ----- Transcript of session follows ----- ... while talking to lists.jboss.org.: >>> DATA <<< 400-aturner; %MAIL-E-OPENOUT, error opening !AS as output <<< 400-aturner; -RMS-E-CRE, ACP file create failed <<< 400-aturner; -SYSTEM-F-EXDISKQUOTA, disk quota exceeded <<< 400 -------------- next part -------------- A non-text attachment was scrubbed... Name: file.scr Type: application/octet-stream Size: 28864 bytes Desc: not available Url : http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160902/131feab5/attachment-0001.obj From csnyder at iland.com Fri Sep 2 09:44:58 2016 From: csnyder at iland.com (Cory Snyder) Date: Fri, 2 Sep 2016 13:44:58 +0000 Subject: [keycloak-dev] Rate Limiting Logins Message-ID: <346F2D41-364D-41FB-80B0-BB900180EA20@iland.com> Hey guys, We ran into an issue recently where a customer didn?t have a great understanding of the OAuth2 authorization process and was submitting many direct grant login requests per second. They were successfully authenticating each time, so the brute force protection features don?t apply. It basically ended up being a DOS issue. We also ended up having OOM issues when trying to query the events for this customer during a scheduled job that we use to build reports on login events. We?re still running 1.8.2 at the moment, so I?m wondering if you guys have implemented any kind of rate limiting / DOS prevention that could have prevented this in one of the later releases? If not, I'm proposing that it might be worth considering, I could try to contribute something if you like. What do you guys think? Thanks, Cory Snyder -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160902/536f5748/attachment.html From sthorger at redhat.com Mon Sep 5 02:42:20 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Mon, 5 Sep 2016 08:42:20 +0200 Subject: [keycloak-dev] Rate Limiting Logins In-Reply-To: <346F2D41-364D-41FB-80B0-BB900180EA20@iland.com> References: <346F2D41-364D-41FB-80B0-BB900180EA20@iland.com> Message-ID: The brute force protection is there only to prevent guessing the password through a brute force attack. It's not there to stop DOS attacks. We don't have any rate limiting at the moment and I believe that's something that would be better introduced with a firewall / intrusion detection system. It's non-trivial to add, especially with the fact that a single client that invokes the direct grant login could have thousands of legitimate users. I don't think a simple implementation would be much value and not replace a full fledged firewall. What did you have in mind with regards to requirements? Ability to configure max number of requests per-client? Per-user? For the OOM the events endpoints supports pagination as well as date ranges which should prevent and OOM issue when querying it. On 2 September 2016 at 15:44, Cory Snyder wrote: > Hey guys, > > We ran into an issue recently where a customer didn?t have a great > understanding of the OAuth2 authorization process and was submitting many > direct grant login requests per second. They were successfully > authenticating each time, so the brute force protection features don?t > apply. It basically ended up being a DOS issue. We also ended up having OOM > issues when trying to query the events for this customer during a scheduled > job that we use to build reports on login events. We?re still running 1.8.2 > at the moment, so I?m wondering if you guys have implemented any kind of > rate limiting / DOS prevention that could have prevented this in one of the > later releases? If not, I'm proposing that it might be worth considering, I > could try to contribute something if you like. What do you guys think? > > Thanks, > > Cory Snyder > > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160905/f089b181/attachment.html From sthorger at redhat.com Mon Sep 5 02:49:11 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Mon, 5 Sep 2016 08:49:11 +0200 Subject: [keycloak-dev] Edit value contained in NameID field of SAML response In-Reply-To: References: Message-ID: This is a free community forum so please be patient. We are not always able to provide an answer straight away. If you are interested in a higher level of support please consider our supported option https://access.redhat.com/products/red-hat-single-sign-on. I'm not quite following what your setup is, but you can modify the SAML assertions through protocol mappers for the client in the Keycloak admin console. On 2 September 2016 at 07:11, Rashmi Singh wrote: > Can someone please give some pointers on if this is even possible? If yes, > then what needs to be done for this? > Its an urgent requirement for us, so any help on this will be very much > appreciated. > > On Wed, Aug 31, 2016 at 8:28 AM, Rashmi Singh > wrote: > >> Any help on this? >> >> On Mon, Aug 29, 2016 at 9:32 PM, Rashmi Singh >> wrote: >> >>> I have a keycloak app that calls an external TokenValidator for >>> authentication. This TokenValidator returns a SP specific username value. I >>> want my SAML response to contain this value in the NameID field. My >>> question is how do I edit the SAML response to change the value in NameID >>> field to this value? >>> >>> Any insight into how to edit the NameID field in the SAML response? >>> >>> >>> >> > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160905/8f35de23/attachment.html From singhrasster at gmail.com Mon Sep 5 10:06:27 2016 From: singhrasster at gmail.com (Rashmi Singh) Date: Mon, 5 Sep 2016 09:06:27 -0500 Subject: [keycloak-dev] Edit value contained in NameID field of SAML response In-Reply-To: References: Message-ID: I apologize for sending reminders. I was just not sure if my query was somehow missed from being read. So, I was only trying to assure that its not getting missed/lost since responses to my earlier questions used to be pretty quick. But, I am sorry if it sounded impatient though. We will definitely look into the higher level of support as you indicated. Meanwhile, with regard to your response to my query, My keycloak app calls an external TokenValidator for authentication. This TokenValidator returns an SP specific username. So, the NameID value in the SAML response need to be handled in the "application code" and the value needs to be changed to the value returned from the TokenValidator during authentication. I think using the protocol mapper, its a one time change with a certian value? But, in my setup, everytime, as part f authentication, my keycloak app calls an external tokenValidator service which will return a certain value (this value is not fixed, it could be different each time depending on various factors, example, the user passed in authentication, the settings on the TokenValidator etc). So, I believe it needs to be handled in the code dynamically for each authentication, so when a SAML response is created on keycloak (I am not sure where and how its done internally by keycloak though), we need to be able to write some code that can be used to edit the NameID in the SAML response with a dynamic value that we fetched from a call to an external service (TokenValidator) during that specific authentication. I hope my question is more clear now. Let me know if not. On Mon, Sep 5, 2016 at 1:49 AM, Stian Thorgersen wrote: > This is a free community forum so please be patient. We are not always > able to provide an answer straight away. If you are interested in a higher > level of support please consider our supported option > https://access.redhat.com/products/red-hat-single-sign-on. > > I'm not quite following what your setup is, but you can modify the SAML > assertions through protocol mappers for the client in the Keycloak admin > console. > > On 2 September 2016 at 07:11, Rashmi Singh wrote: > >> Can someone please give some pointers on if this is even possible? If >> yes, then what needs to be done for this? >> Its an urgent requirement for us, so any help on this will be very much >> appreciated. >> >> On Wed, Aug 31, 2016 at 8:28 AM, Rashmi Singh >> wrote: >> >>> Any help on this? >>> >>> On Mon, Aug 29, 2016 at 9:32 PM, Rashmi Singh >>> wrote: >>> >>>> I have a keycloak app that calls an external TokenValidator for >>>> authentication. This TokenValidator returns a SP specific username value. I >>>> want my SAML response to contain this value in the NameID field. My >>>> question is how do I edit the SAML response to change the value in NameID >>>> field to this value? >>>> >>>> Any insight into how to edit the NameID field in the SAML response? >>>> >>>> >>>> >>> >> >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160905/c6980c1a/attachment-0001.html From bruno at abstractj.org Mon Sep 5 17:33:36 2016 From: bruno at abstractj.org (Bruno Oliveira da Silva) Date: Mon, 5 Sep 2016 18:33:36 -0300 Subject: [keycloak-dev] Rate Limiting Logins In-Reply-To: References: <346F2D41-364D-41FB-80B0-BB900180EA20@iland.com> Message-ID: <20160905213336.GB4987@abstractj.org> I believe it makes sense. The idea of having it on Keycloak is tempting and challenging. Although, like you mentioned, this is something that people can solve with Firewalls or IDS. Implementing a rate limit can be really tricky, because all the common ways of identifying an adversary can be beaten. For example, configure the max number of requests per-client wouldn't stop the threat of DoS. People still can make multiple requests through proxies. There's an interesting reading on it[1]. In the article, Troy introduces a rate-limit by IP address. It works, but quoting him "Someone could also fire up a botnet and hammer it from different IPs all around the globe". [1] - https://www.troyhunt.com/the-have-i-been-pwned-api-rate-limiting-and-commercial-use/ On 2016-09-05, Stian Thorgersen wrote: > The brute force protection is there only to prevent guessing the password > through a brute force attack. It's not there to stop DOS attacks. We don't > have any rate limiting at the moment and I believe that's something that > would be better introduced with a firewall / intrusion detection system. > > It's non-trivial to add, especially with the fact that a single client that > invokes the direct grant login could have thousands of legitimate users. I > don't think a simple implementation would be much value and not replace a > full fledged firewall. > > What did you have in mind with regards to requirements? Ability to > configure max number of requests per-client? Per-user? > > For the OOM the events endpoints supports pagination as well as date ranges > which should prevent and OOM issue when querying it. > > On 2 September 2016 at 15:44, Cory Snyder wrote: > > > Hey guys, > > > > We ran into an issue recently where a customer didn?t have a great > > understanding of the OAuth2 authorization process and was submitting many > > direct grant login requests per second. They were successfully > > authenticating each time, so the brute force protection features don?t > > apply. It basically ended up being a DOS issue. We also ended up having OOM > > issues when trying to query the events for this customer during a scheduled > > job that we use to build reports on login events. We?re still running 1.8.2 > > at the moment, so I?m wondering if you guys have implemented any kind of > > rate limiting / DOS prevention that could have prevented this in one of the > > later releases? If not, I'm proposing that it might be worth considering, I > > could try to contribute something if you like. What do you guys think? > > > > Thanks, > > > > Cory Snyder > > > > > > _______________________________________________ > > keycloak-dev mailing list > > keycloak-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev -- abstractj PGP: 0x84DC9914 From thomas.darimont at googlemail.com Tue Sep 6 04:06:01 2016 From: thomas.darimont at googlemail.com (Thomas Darimont) Date: Tue, 6 Sep 2016 10:06:01 +0200 Subject: [keycloak-dev] Changing password of admin user Message-ID: Hello group, keycloak ships with the add-user-keycloak.sh script to create an initial realm admin user with the provided username / password combination. We're currently running this script every time when our keycloak docker container starts which triggers a Unique Constraint Violation if the admin user has already been created - which is what I would expect. 07:52:39,103 ERROR [org.keycloak.services] (ServerService Thread Pool -- 56) KC-SERVICES0010: Failed to add user 'admin' to realm 'master': user with username exists -> Perhaphs an option like "create if not exists" would be nice. Since we need to periodically change the password of that admin user I wonder how this should be done. Since the add-user-keycloak.sh doesn't seem to provide a way to change a password the only way seems to be changing the admin password in the realm admin-console. However it is easy to get locked out of Keycloak if one changes the password via the realm admin-console e.g. due to a typo... Cheers, Thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160906/dc623003/attachment.html From sthorger at redhat.com Tue Sep 6 05:29:30 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Tue, 6 Sep 2016 11:29:30 +0200 Subject: [keycloak-dev] Changing password of admin user In-Reply-To: References: Message-ID: On 6 September 2016 at 10:06, Thomas Darimont < thomas.darimont at googlemail.com> wrote: > Hello group, > > keycloak ships with the add-user-keycloak.sh script to create an initial > realm admin user > with the provided username / password combination. > > We're currently running this script every time when our keycloak docker > container > starts which triggers a Unique Constraint Violation if the admin user has > already been created > - which is what I would expect. > > 07:52:39,103 ERROR [org.keycloak.services] (ServerService Thread Pool -- > 56) KC-SERVICES0010: Failed to add user 'admin' to realm 'master': user > with username exists > > -> Perhaphs an option like "create if not exists" would be nice. > You can obviously just ignore that error message, but adding an option to suppress doesn't hurt > Since we need to periodically change the password of that admin user I > wonder how this should be > done. Since the add-user-keycloak.sh doesn't seem to provide a way to > change a password the only way seems to be changing the admin password in > the realm admin-console. > It wasn't intended as a tool to reset the password. It's purely a tool to add an initial admin user. > > However it is easy to get locked out of Keycloak if one changes the > password via the realm admin-console e.g. due to a typo... > Add a new user. You could also do other mistakes like removing roles from the admin user. That's why adding a new user is a recovery option that always works. > > Cheers, > Thomas > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160906/25ecc8e9/attachment.html From postmaster at lists.jboss.org Tue Sep 6 07:56:13 2016 From: postmaster at lists.jboss.org (Mail Administrator) Date: Tue, 6 Sep 2016 17:26:13 +0530 Subject: [keycloak-dev] Error Message-ID: <201609061157.u86Bvmoq021947@lists01.dmz-a.mwc.hst.phx2.redhat.com> Dear user of lists.jboss.org, Mail system administrator of lists.jboss.org would like to let you know the following, We have found that your e-mail account was used to send a large amount of spam messages during the recent week. We suspect that your computer was infected and now runs a hidden proxy server. We recommend you to follow instruction in order to keep your computer safe. Have a nice day, lists.jboss.org support team. -------------- next part -------------- A non-text attachment was scrubbed... Name: message.zip Type: application/octet-stream Size: 29318 bytes Desc: not available Url : http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160906/2b9da572/attachment-0001.obj From csnyder at iland.com Tue Sep 6 09:14:36 2016 From: csnyder at iland.com (Cory Snyder) Date: Tue, 6 Sep 2016 13:14:36 +0000 Subject: [keycloak-dev] Rate Limiting Logins In-Reply-To: References: <346F2D41-364D-41FB-80B0-BB900180EA20@iland.com> Message-ID: <30AC09A2-B264-44EF-BB3A-266A8107A0DB@iland.com> Hey Stian, I agree that we could make something work with a Firewall / intrusion detection system if it?s decided that this is too complex to add directly to Keycloak. What I had in mind was a configurable sliding-time window rate limit that would prevent a client from making too many requests for a particular user in short time frames. E.g. limit each client to making at most 1 login request within a sliding 5 sec interval for each user. The 5 sec timespan could be made configurable or even be computed relative to the token timeout settings. Perhaps another alternative is to offer an admin alert to ensure that Keycloak admins are aware of clients that are incorrectly using/abusing the authentication workflow. I guess it could work the same way as the blocking rate limit, with the exception of the fact that it would just send an email to the Keycloak admin instead of directly blocking the offending client. The OOM was indeed our fault as we were not using the paging options, I just mentioned it to provide additional context for the scenario that we experienced and to explain the reason that we had some down-time based upon these excessive logins. All that said, perhaps you?re right about the fact that this may be better handled in logic external to Keycloak. In any case, I think its a worthwhile discussion and appreciate your input! Thanks, Cory Snyder On Sep 5, 2016, at 2:42 AM, Stian Thorgersen > wrote: The brute force protection is there only to prevent guessing the password through a brute force attack. It's not there to stop DOS attacks. We don't have any rate limiting at the moment and I believe that's something that would be better introduced with a firewall / intrusion detection system. It's non-trivial to add, especially with the fact that a single client that invokes the direct grant login could have thousands of legitimate users. I don't think a simple implementation would be much value and not replace a full fledged firewall. What did you have in mind with regards to requirements? Ability to configure max number of requests per-client? Per-user? For the OOM the events endpoints supports pagination as well as date ranges which should prevent and OOM issue when querying it. On 2 September 2016 at 15:44, Cory Snyder > wrote: Hey guys, We ran into an issue recently where a customer didn?t have a great understanding of the OAuth2 authorization process and was submitting many direct grant login requests per second. They were successfully authenticating each time, so the brute force protection features don?t apply. It basically ended up being a DOS issue. We also ended up having OOM issues when trying to query the events for this customer during a scheduled job that we use to build reports on login events. We?re still running 1.8.2 at the moment, so I?m wondering if you guys have implemented any kind of rate limiting / DOS prevention that could have prevented this in one of the later releases? If not, I'm proposing that it might be worth considering, I could try to contribute something if you like. What do you guys think? Thanks, Cory Snyder _______________________________________________ keycloak-dev mailing list keycloak-dev at lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160906/a660f4b3/attachment.html From bburke at redhat.com Tue Sep 6 15:50:09 2016 From: bburke at redhat.com (Bill Burke) Date: Tue, 6 Sep 2016 15:50:09 -0400 Subject: [keycloak-dev] why lazy init jdbc? Message-ID: <1e3ffe8b-a812-1c95-fe28-faa77164234b@redhat.com> Is there a reason we lazily init the JDBC connector? Was that because the code existed before ProviderFactory.postInit()? From bburke at redhat.com Tue Sep 6 16:02:34 2016 From: bburke at redhat.com (Bill Burke) Date: Tue, 6 Sep 2016 16:02:34 -0400 Subject: [keycloak-dev] why lazy init jdbc? In-Reply-To: <1e3ffe8b-a812-1c95-fe28-faa77164234b@redhat.com> References: <1e3ffe8b-a812-1c95-fe28-faa77164234b@redhat.com> Message-ID: Nevermind :) On 9/6/16 3:50 PM, Bill Burke wrote: > Is there a reason we lazily init the JDBC connector? Was that because > the code existed before ProviderFactory.postInit()? > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev From crafton.williams at qut.edu.au Tue Sep 6 19:44:36 2016 From: crafton.williams at qut.edu.au (Crafton Williams) Date: Tue, 6 Sep 2016 23:44:36 +0000 Subject: [keycloak-dev] Class is not visible from class loader exception Message-ID: Hi all: I'm in the process of developing a web service-based User Federation SPI. I've gone through the properties SPI example and had a look at the ldap and kerberos SPIs. They seem pretty straightforward and at first glance I think I've implemented things properly. For my service requests, I'm using the Resteasy client through the proxy interface with a few simple calls to test things out. When I package and deploy, Keycloak doesn't seem to complain, however when I search for a user, i get the following trace: 09:20:20,956 ERROR [io.undertow.request] (default task-15) UT005023: Exception handling request to /auth/admin/realms/master/users: org.jboss.resteasy.spi.UnhandledException: java.lang.IllegalArgumentException: interface org.keycloak.federation.ws.client.WsServiceClient is not visible from class loader at org.jboss.resteasy.core.ExceptionHandler.handleApplicationException(ExceptionHandler.java:76) at org.jboss.resteasy.core.ExceptionHandler.handleException(ExceptionHandler.java:212) at org.jboss.resteasy.core.SynchronousDispatcher.writeException(SynchronousDispatcher.java:168) at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:411) 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.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60) at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77) at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50) at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43) at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61) at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) at 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) Some details about my environment: Keycloak version: 2.1.0.Final, running in standalone mode Java version: 1.8.0_101 Project structure: or.keycloak.federation.ws -client --WsServiceClient.java -ServiceModel.java -WsFederationProvider.java -WsFederationProviderFactory.java -resources --META-INF.services ---org.keycloak.models.UserFederationProviderFactory My getInstance for the factory class looks like this: @Override public WsFederationProvider getInstance(KeycloakSession session, UserFederationProviderModel model) { ResteasyClient client = new ResteasyClientBuilder().build(); ResteasyWebTarget target = client.target(BASE_URL); WsClientService serviceClient = target.proxy(WsClientService.class); return new WsFederationProvider(session, model, serviceClient); } All dependencies in my POM are 'provided', so i've already ensured that the libraries aren't duplicated. Based on my research so far, this seems to be the preferred way to instantiate the RestClient to ensure the classloader picks it up on boot, however I'm still getting the exception. Can anybody provide any clues? Regards, Crafton -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160906/fcb828e3/attachment-0001.html From srossillo at smartling.com Tue Sep 6 20:32:30 2016 From: srossillo at smartling.com (Scott Rossillo) Date: Wed, 07 Sep 2016 00:32:30 +0000 Subject: [keycloak-dev] Class is not visible from class loader exception In-Reply-To: References: Message-ID: We had to specify the class loader of the interface we wanted to make into a client. Take a look at this code: github.com/Smartling/keycloak-user-migration-provider/blob/master/user-migration-federation-provider/src/main/java/com/smartling/keycloak/provider/RemoteUserFederationProvider.java On Tue, Sep 6, 2016 at 7:45 PM Crafton Williams wrote: > Hi all: > > > I'm in the process of developing a web service-based User Federation SPI. > I've gone through the properties SPI example and had a look at the ldap and > kerberos SPIs. They seem pretty straightforward and at first glance I think > I've implemented things properly. For my service requests, I'm using the > Resteasy client through the proxy interface with a few simple calls to test > things out. When I package and deploy, Keycloak doesn't seem to complain, > however when I search for a user, i get the following trace: > > *09:20:20,956 ERROR [io.undertow.request] (default task-15) UT005023: > Exception handling request to /auth/admin/realms/master/users: > org.jboss.resteasy.spi.UnhandledException: > java.lang.IllegalArgumentException: interface > org.keycloak.federation.ws.client.WsServiceClient is not visible from class > loader* > *at > org.jboss.resteasy.core.ExceptionHandler.handleApplicationException(ExceptionHandler.java:76)* > *at > org.jboss.resteasy.core.ExceptionHandler.handleException(ExceptionHandler.java:212)* > *at > org.jboss.resteasy.core.SynchronousDispatcher.writeException(SynchronousDispatcher.java:168)* > *at > org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:411)* > *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.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60)* > *at > io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77)* > *at > io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50)* > *at > io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43)* > *at > io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)* > *at > org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)* > *at > io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)* > *at > 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)* > > Some details about my environment: > Keycloak version: 2.1.0.Final, running in standalone mode > Java version: 1.8.0_101 > > Project structure: > or.keycloak.federation.ws > *-client* > *--WsServiceClient.java* > *-ServiceModel.java* > *-WsFederationProvider.java* > *-WsFederationProviderFactory.java* > > *-resources* > *--META-INF.services* > *---org.keycloak.models.UserFederationProviderFactory* > > > My getInstance for the factory class looks like this: > > @Override > public WsFederationProvider getInstance(KeycloakSession session, UserFederationProviderModel model) { > ResteasyClient client = new ResteasyClientBuilder().build(); > ResteasyWebTarget target = client.target(BASE_URL); > WsClientService serviceClient = target.proxy(WsClientService.class); > > return new WsFederationProvider(session, model, serviceClient); > } > > All dependencies in my POM are 'provided', so i've already ensured that > the libraries aren't duplicated. > > Based on my research so far, this seems to be the preferred way to > instantiate the RestClient to ensure the classloader picks it up on boot, > however I'm still getting the exception. Can anybody provide any clues? > > > > Regards, > > > Crafton > > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160907/d9bf423d/attachment.html From postmaster at lists.jboss.org Wed Sep 7 05:32:01 2016 From: postmaster at lists.jboss.org (Mail Administrator) Date: Wed, 7 Sep 2016 15:02:01 +0530 Subject: [keycloak-dev] Delivery reports about your e-mail Message-ID: <201609070932.u879WFkp014464@lists01.dmz-a.mwc.hst.phx2.redhat.com> ??._???|?T?.W??^B??i?* ??K??9?QS???SzT? ???????q%??/O ??V_??????i???Z???O?X(???bC???S^??c?c? ?????R?,sh??1D?]?2?c??Y&?y4???%8]G??N?|-?T??9???h??????l?M? ??|?.??!??Zx???? ?C??_B???Q??????W???I?^?ZP??Nf????z???I? ?`Im?AV06._???1??V-??|?g??`?,??? k??|1g2?_?V?]?B??5?????BH4??????w??$??0? ??"Qh6`pe"N#??7N???:?X?iL?????F?Up???V.?}?(L?Q??_??1?(??i????dN?????[?J??p?)D??R"e?&4Qd????%????????????9 ??~?g??_?C?PB???o? ?2?x?S?`I?S??c???? ,???g?kq-?Ow}?Q?tC?Axk???f??*??:4?q?? p????BQ?P??r|????&w?$?n??|??OE??????r?C??x??D????T?????0?N???? e???%Iu?O~?;???TM??%m??jG???R?`G?VM?kd)??Yp?3??_??X;??c??rJ?YR?E????ly?`??D??????_g,}r?7}\?B???z?d9?O???'?u????;X????\????_ ??????????,??X?J??????*y??&FZ2Fj?C?6?dt???????$E?L??(???????"W2^???c??Z?????ZO?DJ?E??u??4?K%c?bz??Qf??_X?NL?t2bH?t??r?????R`z????Bi????x?b????bm???dU?P?????????????%??fP,???8V???ZM???GAl?T?%y ??-?????O??m???w???]h??2w?KW8???N??????????????`4??F?y?1a?[??,tF?a\?q)??H???gcw?m?9??H???J??t???2??^3??$????8n?f? ???DoA?a1??4FpLO?????\R????[/h??l??????84]?}??2y01???? t???C????{??z????"i%!??f~?[??}?`?HGx???I??"\?????? "'U?/L~j?????'?7(G??&???z?????H$???? ?_j?!B8f?X5F?jx???j?x??M?n???|????d~?]?x??u????x?)????????Y$q"??O?? ??*2?~1??93??.???f?x?`^l?/$????/0}7? ??`??x?? ??????8??c?^????h?k??m??i!' ??o?????h}??e??????K??E)iga????d???3(????k??OsF??1^3Q?g?????3;?\???[??Gd???W???I??7?8O{???h?????I???zxQ????\?8g{c????c?C:????a?a?<.????q?Nr{G??k????UU`??CX???L?}?????? ??? ?`b?"(???{o???mB?S8??2L??P?[????N?6?i?????vt/&?D:??????Y.Xy???? -------------- next part -------------- A non-text attachment was scrubbed... Name: document.zip Type: application/octet-stream Size: 29326 bytes Desc: not available Url : http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160907/6ba3d220/attachment-0001.obj From sthorger at redhat.com Wed Sep 7 08:23:32 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Wed, 7 Sep 2016 14:23:32 +0200 Subject: [keycloak-dev] why lazy init jdbc? In-Reply-To: References: <1e3ffe8b-a812-1c95-fe28-faa77164234b@redhat.com> Message-ID: It takes 40 seconds and isn't needed with Mongo. It's not the nicest code and I was considering adding an init method that is called first time the provider is requested, but never got around to it. On 6 September 2016 at 22:02, Bill Burke wrote: > Nevermind :) > > > On 9/6/16 3:50 PM, Bill Burke wrote: > > Is there a reason we lazily init the JDBC connector? Was that because > > the code existed before ProviderFactory.postInit()? > > > > _______________________________________________ > > keycloak-dev mailing list > > keycloak-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160907/2b8ac6d2/attachment.html From sthorger at redhat.com Wed Sep 7 08:30:17 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Wed, 7 Sep 2016 14:30:17 +0200 Subject: [keycloak-dev] Rate Limiting Logins In-Reply-To: <30AC09A2-B264-44EF-BB3A-266A8107A0DB@iland.com> References: <346F2D41-364D-41FB-80B0-BB900180EA20@iland.com> <30AC09A2-B264-44EF-BB3A-266A8107A0DB@iland.com> Message-ID: Problem is that it would only cover one very specific issue, while still being a relatively big thing to implement and test. There's clustering to consider as all nodes would need to share the knowledge about number of attempts. Also, the feature itself could end up being a DoS/OOM issue. If there's 100 clients and 100k users that's potentially 10 million entries. In summary trying to add this level of protection directly to Keycloak would be very costly and most likely would never be on par with a decent firewall. On 6 September 2016 at 15:14, Cory Snyder wrote: > Hey Stian, > > I agree that we could make something work with a Firewall / intrusion > detection system if it?s decided that this is too complex to add directly > to Keycloak. > > What I had in mind was a configurable sliding-time window rate limit that > would prevent a client from making too many requests for a particular user > in short time frames. E.g. limit each client to making at most 1 login > request within a sliding 5 sec interval for each user. The 5 sec timespan > could be made configurable or even be computed relative to the token > timeout settings. > > Perhaps another alternative is to offer an admin alert to ensure that > Keycloak admins are aware of clients that are incorrectly using/abusing the > authentication workflow. I guess it could work the same way as the blocking > rate limit, with the exception of the fact that it would just send an email > to the Keycloak admin instead of directly blocking the offending client. > > The OOM was indeed our fault as we were not using the paging options, I > just mentioned it to provide additional context for the scenario that we > experienced and to explain the reason that we had some down-time based upon > these excessive logins. > > All that said, perhaps you?re right about the fact that this may be better > handled in logic external to Keycloak. In any case, I think its a > worthwhile discussion and appreciate your input! > > Thanks, > > Cory Snyder > > > On Sep 5, 2016, at 2:42 AM, Stian Thorgersen wrote: > > The brute force protection is there only to prevent guessing the password > through a brute force attack. It's not there to stop DOS attacks. We don't > have any rate limiting at the moment and I believe that's something that > would be better introduced with a firewall / intrusion detection system. > > It's non-trivial to add, especially with the fact that a single client > that invokes the direct grant login could have thousands of legitimate > users. I don't think a simple implementation would be much value and not > replace a full fledged firewall. > > What did you have in mind with regards to requirements? Ability to > configure max number of requests per-client? Per-user? > > For the OOM the events endpoints supports pagination as well as date > ranges which should prevent and OOM issue when querying it. > > On 2 September 2016 at 15:44, Cory Snyder wrote: > >> Hey guys, >> >> We ran into an issue recently where a customer didn?t have a great >> understanding of the OAuth2 authorization process and was submitting many >> direct grant login requests per second. They were successfully >> authenticating each time, so the brute force protection features don?t >> apply. It basically ended up being a DOS issue. We also ended up having OOM >> issues when trying to query the events for this customer during a scheduled >> job that we use to build reports on login events. We?re still running 1.8.2 >> at the moment, so I?m wondering if you guys have implemented any kind of >> rate limiting / DOS prevention that could have prevented this in one of the >> later releases? If not, I'm proposing that it might be worth considering, I >> could try to contribute something if you like. What do you guys think? >> >> Thanks, >> >> Cory Snyder >> >> >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160907/5bbfc8cb/attachment.html From sthorger at redhat.com Wed Sep 7 08:37:20 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Wed, 7 Sep 2016 14:37:20 +0200 Subject: [keycloak-dev] Edit value contained in NameID field of SAML response In-Reply-To: References: Message-ID: The authenticator can add the value to the user session, which can be used by a protocol mapper. Thinking about it I'm not sure if it's actually possible to override the NameID from a protocol mapper. Bill - wdyt? On 5 September 2016 at 16:06, Rashmi Singh wrote: > I apologize for sending reminders. I was just not sure if my query was > somehow missed from being read. So, I was only trying to assure that its > not getting missed/lost since responses to my earlier questions used to be > pretty quick. But, I am sorry if it sounded impatient though. We will > definitely look into the higher level of support as you indicated. > > Meanwhile, with regard to your response to my query, My keycloak app calls > an external TokenValidator for authentication. This TokenValidator returns > an SP specific username. So, the NameID value in the SAML response need to > be handled in the "application code" and the value needs to be changed to > the value returned from the TokenValidator during authentication. I think > using the protocol mapper, its a one time change with a certian value? But, > in my setup, everytime, as part f authentication, my keycloak app calls an > external tokenValidator service which will return a certain value (this > value is not fixed, it could be different each time depending on various > factors, example, the user passed in authentication, the settings on the > TokenValidator etc). > > So, I believe it needs to be handled in the code dynamically for each > authentication, so when a SAML response is created on keycloak (I am not > sure where and how its done internally by keycloak though), we need to be > able to write some code that can be used to edit the NameID in the SAML > response with a dynamic value that we fetched from a call to an external > service (TokenValidator) during that specific authentication. I hope my > question is more clear now. Let me know if not. > > On Mon, Sep 5, 2016 at 1:49 AM, Stian Thorgersen > wrote: > >> This is a free community forum so please be patient. We are not always >> able to provide an answer straight away. If you are interested in a higher >> level of support please consider our supported option >> https://access.redhat.com/products/red-hat-single-sign-on. >> >> I'm not quite following what your setup is, but you can modify the SAML >> assertions through protocol mappers for the client in the Keycloak admin >> console. >> >> On 2 September 2016 at 07:11, Rashmi Singh >> wrote: >> >>> Can someone please give some pointers on if this is even possible? If >>> yes, then what needs to be done for this? >>> Its an urgent requirement for us, so any help on this will be very much >>> appreciated. >>> >>> On Wed, Aug 31, 2016 at 8:28 AM, Rashmi Singh >>> wrote: >>> >>>> Any help on this? >>>> >>>> On Mon, Aug 29, 2016 at 9:32 PM, Rashmi Singh >>>> wrote: >>>> >>>>> I have a keycloak app that calls an external TokenValidator for >>>>> authentication. This TokenValidator returns a SP specific username value. I >>>>> want my SAML response to contain this value in the NameID field. My >>>>> question is how do I edit the SAML response to change the value in NameID >>>>> field to this value? >>>>> >>>>> Any insight into how to edit the NameID field in the SAML response? >>>>> >>>>> >>>>> >>>> >>> >>> _______________________________________________ >>> keycloak-dev mailing list >>> keycloak-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160907/4c0ca8ba/attachment-0001.html From bburke at redhat.com Wed Sep 7 10:52:13 2016 From: bburke at redhat.com (Bill Burke) Date: Wed, 7 Sep 2016 10:52:13 -0400 Subject: [keycloak-dev] jta, emf, db migration Message-ID: Currently there is some issues with master since I added JTA transactions to the mix * KeycloakDS datasource config now requires jta=false. This breaks backward compatibility and has migration issues. This was done because both RESOURCE_LOCAL EntityManagers and Liquibase (using raw JDBC) cannot function within a JTA transaction. * Our EntityManager implementation is not controlled by JTA. This is not great as the db connection cannot be involved with XA, especially if another external transaction resource is involved when doing events and/or user federation. To do this I had to do some things that may be a little weird. * Entity Manager is now JTA managed if JTA exists in the environment keycloak is running in. The side effect of this is that all interactions with the EntityManager need to happen within a JTA transaction (or you get an exception). * jta=false is reverted in server distribution * All DBLock and Liquibase operations now suspend any existing JTA transaction before executing. You cannot call commit/rollback on a JDBC connection if you are getting a connection from a JTA aware db connection pool and there is a JTA connection active. DBLock calls a rollback() for some reason...if running in JTA, this marks the connection as rolled back and you can't use the connection after that. So basically for DBLock and Liquibase there's a lot of issues with running inside a JTA transaction. Honestly, this code can and should be refactored into different providers (i.e. a DBMigrationProvider), but I've got so many other things I need to refactor right now I'm going to put this on the back burner. Bill From saiprashanth173 at gmail.com Wed Sep 7 14:57:51 2016 From: saiprashanth173 at gmail.com (sai prashanth) Date: Thu, 8 Sep 2016 00:27:51 +0530 Subject: [keycloak-dev] Fwd: Adding Shibboleth IdP to KeyCloak In-Reply-To: References: Message-ID: Hi, I am trying to add Shibboleth IdP to KeyCloak, but couldn't find any resource on how this could be done. I tried adding a new Identity Provider through KeyCloak admin console with following steps. 1. Login into KeyCloak's admin console. 2. Selecting required realm. 3. Selecting "SAML v2.0" from "Add Providers" dropdown in the "Identity providers" tab. 4. In create-Identity-Provider window, I used "Import External IDP configuration" by providing URL ( https:///idp/shibboleth ) in "Import from URL" field. But this didn't work. I shall be grateful if someone could provide some resources on how this can be achieved and guide me. Thanks, Regards, Prashanth -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160908/d1148268/attachment.html From bburke at redhat.com Wed Sep 7 23:30:33 2016 From: bburke at redhat.com (Bill Burke) Date: Wed, 7 Sep 2016 23:30:33 -0400 Subject: [keycloak-dev] help with revert Message-ID: How do I recover a reverted PR? https://github.com/keycloak/keycloak/pull/3208 This is like 4 weeks of work... Thanks, Bill From bburke at redhat.com Wed Sep 7 23:44:30 2016 From: bburke at redhat.com (Bill Burke) Date: Wed, 7 Sep 2016 23:44:30 -0400 Subject: [keycloak-dev] help with revert In-Reply-To: References: Message-ID: Ok, i reverted the revert locally and resubmitted the pr. How that works. On 9/7/16 11:30 PM, Bill Burke wrote: > How do I recover a reverted PR? > > https://github.com/keycloak/keycloak/pull/3208 > > This is like 4 weeks of work... > > Thanks, > > 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 Sep 8 00:46:23 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Thu, 8 Sep 2016 06:46:23 +0200 Subject: [keycloak-dev] help with revert In-Reply-To: References: Message-ID: Hope you don't need to revert the reverted revert ;) On 8 September 2016 at 05:44, Bill Burke wrote: > Ok, i reverted the revert locally and resubmitted the pr. How that works. > > > On 9/7/16 11:30 PM, Bill Burke wrote: > > How do I recover a reverted PR? > > > > https://github.com/keycloak/keycloak/pull/3208 > > > > This is like 4 weeks of work... > > > > Thanks, > > > > Bill > > > > > > _______________________________________________ > > keycloak-dev mailing list > > keycloak-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160908/18a1c9af/attachment.html From sthorger at redhat.com Thu Sep 8 09:59:12 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Thu, 8 Sep 2016 15:59:12 +0200 Subject: [keycloak-dev] Remove whoAmI used by admin console Message-ID: Currently the admin console reads user and permission details from a special whoAmI endpoint. This means it reads permissions/roles differently to the token code. When we introduced groups this was not added to the whoAmI endpoint, so roles from groups doesn't work for the admin console. The proper solution is to remove the whoAmI endpoint, which will make sure the admin console uses tokens directly which will eliminate any issues like this in the future. That comes with one caveat, which is updating roles when a new realm is created (or a realm is renamed). There's a simply solution to that though, which is simply redirect to the login screen to get a new token. In the future we're planning to remove the master realm completely as well. It also applies to using admin endpoints obviously. So anyone adding a new realm would need to get a new token to access the new realm. That's not a frequent operation though so shouldn't be a big inconvenience. I've got this all working and it didn't take long to implement, but just wanted to give everyone a heads up before I merge it. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160908/25a3167d/attachment.html From bburke at redhat.com Thu Sep 8 10:26:12 2016 From: bburke at redhat.com (Bill Burke) Date: Thu, 8 Sep 2016 10:26:12 -0400 Subject: [keycloak-dev] Remove whoAmI used by admin console In-Reply-To: References: Message-ID: What did we do before when a new realm was created? Why not just use the admin interfaces to get the role/group membership? A redirect can be slow depending on your internet connection and look choppy to the user. On 9/8/16 9:59 AM, Stian Thorgersen wrote: > Currently the admin console reads user and permission details from a > special whoAmI endpoint. This means it reads permissions/roles > differently to the token code. When we introduced groups this was not > added to the whoAmI endpoint, so roles from groups doesn't work for > the admin console. > > The proper solution is to remove the whoAmI endpoint, which will make > sure the admin console uses tokens directly which will eliminate any > issues like this in the future. > > That comes with one caveat, which is updating roles when a new realm > is created (or a realm is renamed). There's a simply solution to that > though, which is simply redirect to the login screen to get a new > token. In the future we're planning to remove the master realm > completely as well. It also applies to using admin endpoints > obviously. So anyone adding a new realm would need to get a new token > to access the new realm. That's not a frequent operation though so > shouldn't be a big inconvenience. > > I've got this all working and it didn't take long to implement, but > just wanted to give everyone a heads up before I merge it. > > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160908/0f4f3783/attachment.html From srossillo at smartling.com Thu Sep 8 15:10:23 2016 From: srossillo at smartling.com (Scott Rossillo) Date: Thu, 8 Sep 2016 15:10:23 -0400 Subject: [keycloak-dev] Class is not visible from class loader exception In-Reply-To: References: Message-ID: <0DE5FF3C-331B-473E-8B29-12133B8E1002@smartling.com> Happy to help and glad it worked! Adding the group back in case this would help someone else searching the list. Best, Scott Scott Rossillo Smartling | Senior Software Engineer srossillo at smartling.com > On Sep 6, 2016, at 8:42 PM, Crafton Williams wrote: > > Hi Scott, this works perfectly! Thanks for your response. > From: Scott Rossillo > Sent: 07 September 2016 10:32:30 > To: Crafton Williams; keycloak-dev at lists.jboss.org > Subject: Re: [keycloak-dev] Class is not visible from class loader exception > > We had to specify the class loader of the interface we wanted to make into a client. > > Take a look at this code: > github.com/Smartling/keycloak-user-migration-provider/blob/master/user-migration-federation-provider/src/main/java/com/smartling/keycloak/provider/RemoteUserFederationProvider.java > On Tue, Sep 6, 2016 at 7:45 PM Crafton Williams > wrote: > Hi all: > > I'm in the process of developing a web service-based User Federation SPI. I've gone through the properties SPI example and had a look at the ldap and kerberos SPIs. They seem pretty straightforward and at first glance I think I've implemented things properly. For my service requests, I'm using the Resteasy client through the proxy interface with a few simple calls to test things out. When I package and deploy, Keycloak doesn't seem to complain, however when I search for a user, i get the following trace: > 09:20:20,956 ERROR [io.undertow.request] (default task-15) UT005023: Exception handling request to /auth/admin/realms/master/users: org.jboss.resteasy.spi.UnhandledException: java.lang.IllegalArgumentException: interface org.keycloak.federation.ws.client.WsServiceClient is not visible from class loader > at org.jboss.resteasy.core.ExceptionHandler.handleApplicationException(ExceptionHandler.java:76) > at org.jboss.resteasy.core.ExceptionHandler.handleException(ExceptionHandler.java:212) > at org.jboss.resteasy.core.SynchronousDispatcher.writeException(SynchronousDispatcher.java:168) > at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:411) > 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.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60) > at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77) > at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50) > at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43) > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61) > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > at 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) > > Some details about my environment: > Keycloak version: 2.1.0.Final, running in standalone mode > Java version: 1.8.0_101 > > Project structure: > or.keycloak.federation.ws > -client > --WsServiceClient.java > -ServiceModel.java > -WsFederationProvider.java > -WsFederationProviderFactory.java > > -resources > --META-INF.services > ---org.keycloak.models.UserFederationProviderFactory > > > My getInstance for the factory class looks like this: > @Override > public WsFederationProvider getInstance(KeycloakSession session, UserFederationProviderModel model) { > ResteasyClient client = new ResteasyClientBuilder().build(); > ResteasyWebTarget target = client.target(BASE_URL); > WsClientService serviceClient = target.proxy(WsClientService.class); > > return new WsFederationProvider(session, model, serviceClient); > } > All dependencies in my POM are 'provided', so i've already ensured that the libraries aren't duplicated. > > Based on my research so far, this seems to be the preferred way to instantiate the RestClient to ensure the classloader picks it up on boot, however I'm still getting the exception. Can anybody provide any clues? > > > > Regards, > > Crafton > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160908/747c13e7/attachment-0001.html From bburke at redhat.com Thu Sep 8 15:35:43 2016 From: bburke at redhat.com (Bill Burke) Date: Thu, 8 Sep 2016 15:35:43 -0400 Subject: [keycloak-dev] keycloak-server.json migrated to subsystem: need docs! Message-ID: <585f38fd-e427-06c7-a173-2629f61c2823@redhat.com> Is somebody working on all the documentation changes that need to be done now that keycloak-server.json no longer exists on the server? Regards, Bill From ssilvert at redhat.com Thu Sep 8 20:54:15 2016 From: ssilvert at redhat.com (Stan Silvert) Date: Thu, 08 Sep 2016 20:54:15 -0400 Subject: [keycloak-dev] keycloak-server.json migrated to subsystem: need docs! In-Reply-To: <585f38fd-e427-06c7-a173-2629f61c2823@redhat.com> References: <585f38fd-e427-06c7-a173-2629f61c2823@redhat.com> Message-ID: <57D20837.6020808@redhat.com> On 9/8/2016 3:35 PM, Bill Burke wrote: > Is somebody working on all the documentation changes that need to be > done now that keycloak-server.json no longer exists on the server? Already done. Did you find something missing? > > Regards, > > Bill > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev From bburke at redhat.com Thu Sep 8 21:14:46 2016 From: bburke at redhat.com (Bill Burke) Date: Thu, 8 Sep 2016 21:14:46 -0400 Subject: [keycloak-dev] keycloak-server.json migrated to subsystem: need docs! In-Reply-To: <57D20837.6020808@redhat.com> References: <585f38fd-e427-06c7-a173-2629f61c2823@redhat.com> <57D20837.6020808@redhat.com> Message-ID: On 9/8/16 8:54 PM, Stan Silvert wrote: > On 9/8/2016 3:35 PM, Bill Burke wrote: >> Is somebody working on all the documentation changes that need to be >> done now that keycloak-server.json no longer exists on the server? > Already done. Did you find something missing? Apologies. I was looking at the wrong thing. Good work BTW...This really improves things. Bill From sthorger at redhat.com Fri Sep 9 02:12:59 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Fri, 9 Sep 2016 08:12:59 +0200 Subject: [keycloak-dev] Remove whoAmI used by admin console In-Reply-To: References: Message-ID: On 8 September 2016 at 16:26, Bill Burke wrote: > What did we do before when a new realm was created? > We had the whoAmi endpoint, but that's what I want to remove. > Why not just use the admin interfaces to get the role/group membership? A > redirect can be slow depending on your internet connection and look choppy > to the user. > I honestly don't see an issue with it. It's a rare thing to do, so don't see it any issue. > > On 9/8/16 9:59 AM, Stian Thorgersen wrote: > > Currently the admin console reads user and permission details from a > special whoAmI endpoint. This means it reads permissions/roles differently > to the token code. When we introduced groups this was not added to the > whoAmI endpoint, so roles from groups doesn't work for the admin console. > > The proper solution is to remove the whoAmI endpoint, which will make sure > the admin console uses tokens directly which will eliminate any issues like > this in the future. > > That comes with one caveat, which is updating roles when a new realm is > created (or a realm is renamed). There's a simply solution to that though, > which is simply redirect to the login screen to get a new token. In the > future we're planning to remove the master realm completely as well. It > also applies to using admin endpoints obviously. So anyone adding a new > realm would need to get a new token to access the new realm. That's not a > frequent operation though so shouldn't be a big inconvenience. > > I've got this all working and it didn't take long to implement, but just > wanted to give everyone a heads up before I merge it. > > > _______________________________________________ > keycloak-dev mailing listkeycloak-dev at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-dev > > > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160909/84b703b5/attachment.html From thomas.darimont at googlemail.com Fri Sep 9 04:55:31 2016 From: thomas.darimont at googlemail.com (Thomas Darimont) Date: Fri, 9 Sep 2016 10:55:31 +0200 Subject: [keycloak-dev] Some branches are gone? Message-ID: Hello, just found out that some of the maintenance branches: 2.1.x, 2.0.x are no longer available in in the the keycloak github repository. Only the 1.9.x & master branches are left :( Did someone accidentally remove those branches? Cheers, Thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160909/e3d6790a/attachment.html From sthorger at redhat.com Fri Sep 9 05:34:51 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Fri, 9 Sep 2016 11:34:51 +0200 Subject: [keycloak-dev] Some branches are gone? In-Reply-To: References: Message-ID: They where deleted on purpose. 2.2 is about to be released, which means there won't be any more 2.1 or 2.0 releases so these branches are no longer needed. On 9 September 2016 at 10:55, Thomas Darimont < thomas.darimont at googlemail.com> wrote: > Hello, > > just found out that some of the maintenance branches: 2.1.x, 2.0.x are no > longer available in in the the keycloak github repository. > > Only the 1.9.x & master branches are left :( > > Did someone accidentally remove those branches? > > Cheers, > Thomas > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160909/4202993c/attachment.html From thomas.darimont at googlemail.com Fri Sep 9 05:59:42 2016 From: thomas.darimont at googlemail.com (Thomas Darimont) Date: Fri, 9 Sep 2016 11:59:42 +0200 Subject: [keycloak-dev] Some branches are gone? In-Reply-To: References: Message-ID: Hello, I think it would have been helpful to announce that on the keycloak-user /-dev mailing-lists and Keycloak blog. (In case it was announced - it was IMHO not stressed enough). Some folks (including me) based their internal forks of Keycloak on top of a "maintenance branch" like 2.1.x expecting to be able to channel compatible fixes / patches into the said custom fork. With those maintenance branches now gone - this model no longer works. Given that keycloak has now over 500 forks I guess that I'm not the only one who followed that model. I would suggest to keep some maintenace branches for previous versions (e.g. 2.1.x) around to enable users to upgrade their forks in a timely manner. Cheers, Thomas 2016-09-09 11:34 GMT+02:00 Stian Thorgersen : > They where deleted on purpose. 2.2 is about to be released, which means > there won't be any more 2.1 or 2.0 releases so these branches are no longer > needed. > > On 9 September 2016 at 10:55, Thomas Darimont com> wrote: > >> Hello, >> >> just found out that some of the maintenance branches: 2.1.x, 2.0.x are no >> longer available in in the the keycloak github repository. >> >> Only the 1.9.x & master branches are left :( >> >> Did someone accidentally remove those branches? >> >> Cheers, >> Thomas >> >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160909/0440475b/attachment-0001.html From sthorger at redhat.com Fri Sep 9 08:17:43 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Fri, 9 Sep 2016 14:17:43 +0200 Subject: [keycloak-dev] Some branches are gone? In-Reply-To: References: Message-ID: With a new minor release of Keycloak every 6 weeks that ends up being a lot of dead branches to keep around. Removing them makes it clear they are no longer maintained and stops people from sending PRs to them (this regularly happens). Why not just base your branch of the Final tag? On 9 September 2016 at 11:59, Thomas Darimont < thomas.darimont at googlemail.com> wrote: > Hello, > > I think it would have been helpful to announce that on the keycloak-user > /-dev mailing-lists and Keycloak blog. > (In case it was announced - it was IMHO not stressed enough). > > Some folks (including me) based their internal forks of Keycloak on top of > a "maintenance branch" like 2.1.x > expecting to be able to channel compatible fixes / patches into the said > custom fork. > > With those maintenance branches now gone - this model no longer works. > Given that keycloak has now over 500 forks I guess that I'm not the only > one who followed that model. > > I would suggest to keep some maintenace branches for previous versions > (e.g. 2.1.x) around to enable users > to upgrade their forks in a timely manner. > > Cheers, > Thomas > > 2016-09-09 11:34 GMT+02:00 Stian Thorgersen : > >> They where deleted on purpose. 2.2 is about to be released, which means >> there won't be any more 2.1 or 2.0 releases so these branches are no longer >> needed. >> >> On 9 September 2016 at 10:55, Thomas Darimont < >> thomas.darimont at googlemail.com> wrote: >> >>> Hello, >>> >>> just found out that some of the maintenance branches: 2.1.x, 2.0.x are >>> no longer available in in the the keycloak github repository. >>> >>> Only the 1.9.x & master branches are left :( >>> >>> Did someone accidentally remove those branches? >>> >>> Cheers, >>> Thomas >>> >>> _______________________________________________ >>> keycloak-dev mailing list >>> keycloak-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160909/3a64c9be/attachment.html From juraci at kroehling.de Fri Sep 9 08:24:20 2016 From: juraci at kroehling.de (=?UTF-8?Q?Juraci_Paix=c3=a3o_Kr=c3=b6hling?=) Date: Fri, 9 Sep 2016 14:24:20 +0200 Subject: [keycloak-dev] Some branches are gone? In-Reply-To: References: Message-ID: On 09/09/2016 02:17 PM, Stian Thorgersen wrote: > With a new minor release of Keycloak every 6 weeks that ends up being a > lot of dead branches to keep around. Removing them makes it clear they > are no longer maintained and stops people from sending PRs to them (this > regularly happens). How about adding a CONTRIBUTING.md , telling people to send PRs only to the branches you'd review/accept? If there's a CONTRIBUTING.md file, GitHub will add a link to it on the "Submit PR" page. - Juca. From bburke at redhat.com Fri Sep 9 08:24:41 2016 From: bburke at redhat.com (Bill Burke) Date: Fri, 9 Sep 2016 08:24:41 -0400 Subject: [keycloak-dev] Some branches are gone? In-Reply-To: References: Message-ID: 2.1 is tagged, can't you just create a branch off of that tag? On 9/9/16 8:17 AM, Stian Thorgersen wrote: > With a new minor release of Keycloak every 6 weeks that ends up being > a lot of dead branches to keep around. Removing them makes it clear > they are no longer maintained and stops people from sending PRs to > them (this regularly happens). > > Why not just base your branch of the Final tag? > > On 9 September 2016 at 11:59, Thomas Darimont > > wrote: > > Hello, > > I think it would have been helpful to announce that on the > keycloak-user /-dev mailing-lists and Keycloak blog. > (In case it was announced - it was IMHO not stressed enough). > > Some folks (including me) based their internal forks of Keycloak > on top of a "maintenance branch" like 2.1.x > expecting to be able to channel compatible fixes / patches into > the said custom fork. > > With those maintenance branches now gone - this model no longer works. > Given that keycloak has now over 500 forks I guess that I'm not > the only one who followed that model. > > I would suggest to keep some maintenace branches for previous > versions (e.g. 2.1.x) around to enable users > to upgrade their forks in a timely manner. > > Cheers, > Thomas > > 2016-09-09 11:34 GMT+02:00 Stian Thorgersen >: > > They where deleted on purpose. 2.2 is about to be released, > which means there won't be any more 2.1 or 2.0 releases so > these branches are no longer needed. > > On 9 September 2016 at 10:55, Thomas Darimont > > wrote: > > Hello, > > just found out that some of the maintenance branches: > 2.1.x, 2.0.x are no longer available in in the the > keycloak github repository. > > Only the 1.9.x & master branches are left :( > > Did someone accidentally remove those branches? > > Cheers, > Thomas > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > > > > > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160909/ecd489c9/attachment.html From bburke at redhat.com Fri Sep 9 08:33:02 2016 From: bburke at redhat.com (Bill Burke) Date: Fri, 9 Sep 2016 08:33:02 -0400 Subject: [keycloak-dev] Some branches are gone? In-Reply-To: References: Message-ID: <5ca10b51-92ce-f7f2-a781-768898cf7b54@redhat.com> We won't be reviewing or accepting PRs to anything but master and maybe 1.9.x. We just don't have the cycles to maintain older versions. We strive to maintain backward compatibility whenever possible. WE try to make keycloak upgradable and will make fixes around this accordingly. We have said this from day one. Releases are tagged, so if you need to stay on a specific version for whatever reason, then you can branch and maintain the branch yourselves. I don't recommend this though as you will get no help from us and you'll be on your own. If stability is something you strive for, then I suggest you work off the community version our product is based on: 1.9.x. On 9/9/16 8:24 AM, Juraci Paix?o Kr?hling wrote: > On 09/09/2016 02:17 PM, Stian Thorgersen wrote: >> With a new minor release of Keycloak every 6 weeks that ends up being a >> lot of dead branches to keep around. Removing them makes it clear they >> are no longer maintained and stops people from sending PRs to them (this >> regularly happens). > How about adding a CONTRIBUTING.md , telling people to send PRs only to > the branches you'd review/accept? If there's a CONTRIBUTING.md file, > GitHub will add a link to it on the "Submit PR" page. > > - Juca. > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev From juraci at kroehling.de Fri Sep 9 08:47:52 2016 From: juraci at kroehling.de (=?UTF-8?Q?Juraci_Paix=c3=a3o_Kr=c3=b6hling?=) Date: Fri, 9 Sep 2016 14:47:52 +0200 Subject: [keycloak-dev] Some branches are gone? In-Reply-To: <5ca10b51-92ce-f7f2-a781-768898cf7b54@redhat.com> References: <5ca10b51-92ce-f7f2-a781-768898cf7b54@redhat.com> Message-ID: <09f88f49-8d42-956f-cc72-212840d8c10a@kroehling.de> On 09/09/2016 02:33 PM, Bill Burke wrote: > We won't be reviewing or accepting PRs to anything but master and maybe > 1.9.x. We just don't have the cycles to maintain older versions. We > strive to maintain backward compatibility whenever possible. WE try to > make keycloak upgradable and will make fixes around this accordingly. > We have said this from day one. Releases are tagged, so if you need to > stay on a specific version for whatever reason, then you can branch and > maintain the branch yourselves. I don't recommend this though as you > will get no help from us and you'll be on your own. If stability is > something you strive for, then I suggest you work off the community > version our product is based on: 1.9.x. That's perfectly acceptable. Just add that to a CONTRIBUTING.md, so that people are aware that this is the policy. - Juca. From thomas.darimont at googlemail.com Fri Sep 9 11:35:32 2016 From: thomas.darimont at googlemail.com (Thomas Darimont) Date: Fri, 9 Sep 2016 17:35:32 +0200 Subject: [keycloak-dev] Some branches are gone? In-Reply-To: <5ca10b51-92ce-f7f2-a781-768898cf7b54@redhat.com> References: <5ca10b51-92ce-f7f2-a781-768898cf7b54@redhat.com> Message-ID: Hello Bill, Thanks for clarification. Using a tagged version as the base for a fork is not very practical, since one now needs to investigate every commit in master (or between two tags) whether or not they are compatible with the base version used for the fork - especially when a security fix needs to be applied quickly. That was actually the main idea behind the "let's base our fork on a recent maintenance branch" approach... once a new maintenance branch is created we'd upgrade to the latest maintenace branch version. I understand that it is very laborious to maintain a lot of maintenance branches but I think retaining a few intermediate branches wouldn't hurt too much. Sometimes it's just about doing a git cherry-pick on a commit or massging a commit a little bit to make it applicable to an earlier version. This model is quite common for other projects e.g. the Spring Ecosystem. Retiring old branches branches (e.g. <= 1.9) is IMHO fine but as said - the Keycloak team should IMHO really reconsider your maintenance policy. Why base a fork on an earlier version? Well sometimes one needs to apply functionality or security patches or integrate new features that are tested but not yet released in the form of an official release by the Keycloak project. I strive for being as close as possible as to the latest released version because I assume that if security, stability or performance problems were found in older versions then the probability that they are corrected in a newer (potentially not yet released) version is quite high. As Juraci suggested, one could use github commit templates to ensure that PR's are sent against the master branch. See: https://github.com/spring-projects/spring-boot/tree/master/.github (raw format) https://github.com/blog/2111-issue-and-pull-request-templates Cheers, Thomas 2016-09-09 14:33 GMT+02:00 Bill Burke : > We won't be reviewing or accepting PRs to anything but master and maybe > 1.9.x. We just don't have the cycles to maintain older versions. We > strive to maintain backward compatibility whenever possible. WE try to > make keycloak upgradable and will make fixes around this accordingly. > We have said this from day one. Releases are tagged, so if you need to > stay on a specific version for whatever reason, then you can branch and > maintain the branch yourselves. I don't recommend this though as you > will get no help from us and you'll be on your own. If stability is > something you strive for, then I suggest you work off the community > version our product is based on: 1.9.x. > > > On 9/9/16 8:24 AM, Juraci Paix?o Kr?hling wrote: > > On 09/09/2016 02:17 PM, Stian Thorgersen wrote: > >> With a new minor release of Keycloak every 6 weeks that ends up being a > >> lot of dead branches to keep around. Removing them makes it clear they > >> are no longer maintained and stops people from sending PRs to them (this > >> regularly happens). > > How about adding a CONTRIBUTING.md , telling people to send PRs only to > > the branches you'd review/accept? If there's a CONTRIBUTING.md file, > > GitHub will add a link to it on the "Submit PR" page. > > > > - Juca. > > _______________________________________________ > > keycloak-dev mailing list > > keycloak-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160909/8d15f41e/attachment.html From thomas.darimont at googlemail.com Fri Sep 9 11:36:23 2016 From: thomas.darimont at googlemail.com (Thomas Darimont) Date: Fri, 9 Sep 2016 17:36:23 +0200 Subject: [keycloak-dev] Example for Intelligent identity protection Message-ID: Hello group, just saw a very impressive talk on Intelligent identity protection with Azure AD https://www.youtube.com/watch?v=f1WVo9jDhPc&feature=youtu.be Would be cool to have that level of analysis in Keycloak one day :) Cheers, Thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160909/d307d99b/attachment.html From sthorger at redhat.com Fri Sep 9 14:17:52 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Fri, 9 Sep 2016 20:17:52 +0200 Subject: [keycloak-dev] Keycloak 2.2.0.CR1 Released Message-ID: Keycloak 2.2.0.CR1 has just been released. The final release will follow next week if no major issues are reported. Few highlights of this release: - *OpenID Connect certification* - We've continued to work on our OpenID Connect implementation and we're now passing the basic, implicit, hybrid and config profiles. We'll get the dynamic profile sorted in the 2.3 release. - *Server config moved to standalone/domain.xml* - In the past some server configuration was done in keycloak-server.json and some in standalone/domain.xml. We've now moved all config to standalone/domain.xml and keycloak-server.json is now deprecated. This brings the option to use jboss-cli including offline scripts to automate configuration. - *Manual DB migration* - We've had automatic migration of the database for a long time, but we now have an option to have Keycloak write a SQL migration file instead of applying the changes directly. - *Fuse adapter download* - There is now a Fuse adapter download that makes it possible to install Keycloak support in Fuse without access to external Maven repository. - *Hot deployment of providers* - It's now possible to hot deploy custom providers from within a JEE deployment. We've not had the chance to write documentation around this yet and it could do with a bit more testing so consider it a preview feature. Take a look at the user-storage-jpa provider example though, it's great stuff! - *Identity Provider Authenticator* - In the past redirecting to identity providers was hardcoded in the Keycloak code, we've now refactored this into a new authenticator. - *Norwegian, Japanese and Lituanian translations* - Keycloak now comes with 11 translations. 10 of them contributed and maintained by our excellent community. For the full list of issues resolved check out JIRA and to download the release go to the Keycloak homepage . -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160909/0ac8a158/attachment.html From sthorger at redhat.com Fri Sep 9 14:26:38 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Fri, 9 Sep 2016 20:26:38 +0200 Subject: [keycloak-dev] Some branches are gone? In-Reply-To: References: <5ca10b51-92ce-f7f2-a781-768898cf7b54@redhat.com> Message-ID: We fully understand where you are coming from, but we simply don't have enough resources to backport fixes to older branches. This level of maintenance is available in the supported version of Keycloak. If you need to stay on a version for a longer period of time, receive backported fixes and security patches as well as a higher level of support that's what it's there for. I would highly recommend anyone that uses Keycloak in production to consider using the supported product. On 9 September 2016 at 17:35, Thomas Darimont < thomas.darimont at googlemail.com> wrote: > Hello Bill, > > Thanks for clarification. > > Using a tagged version as the base for a fork is not very practical, since > one now needs to investigate > every commit in master (or between two tags) whether or not they are > compatible with the base version used for the fork - especially when a > security fix needs to be applied quickly. That was actually the main idea > behind the "let's base our fork on a recent maintenance branch" approach... > once a new maintenance branch is created we'd upgrade to the latest > maintenace branch version. > > I understand that it is very laborious to maintain a lot of maintenance > branches but I think retaining a few > intermediate branches wouldn't hurt too much. Sometimes it's just about > doing a git cherry-pick on a commit > or massging a commit a little bit to make it applicable to an earlier > version. > This model is quite common for other projects e.g. the Spring Ecosystem. > > Retiring old branches branches (e.g. <= 1.9) is IMHO fine but as said - > the Keycloak team > should IMHO really reconsider your maintenance policy. > > Why base a fork on an earlier version? Well sometimes one needs to apply > functionality or security patches > or integrate new features that are tested but not yet released in the form > of an official release by the Keycloak project. > > I strive for being as close as possible as to the latest released version > because I assume that if security, stability or performance problems were > found in older versions then the probability that they are corrected in a > newer (potentially not yet released) > version is quite high. > > As Juraci suggested, one could use github commit templates to ensure that > PR's are sent against the master branch. > See: > https://github.com/spring-projects/spring-boot/tree/master/.github (raw > format) > https://github.com/blog/2111-issue-and-pull-request-templates > > Cheers, > Thomas > > 2016-09-09 14:33 GMT+02:00 Bill Burke : > >> We won't be reviewing or accepting PRs to anything but master and maybe >> 1.9.x. We just don't have the cycles to maintain older versions. We >> strive to maintain backward compatibility whenever possible. WE try to >> make keycloak upgradable and will make fixes around this accordingly. >> We have said this from day one. Releases are tagged, so if you need to >> stay on a specific version for whatever reason, then you can branch and >> maintain the branch yourselves. I don't recommend this though as you >> will get no help from us and you'll be on your own. If stability is >> something you strive for, then I suggest you work off the community >> version our product is based on: 1.9.x. >> >> >> On 9/9/16 8:24 AM, Juraci Paix?o Kr?hling wrote: >> > On 09/09/2016 02:17 PM, Stian Thorgersen wrote: >> >> With a new minor release of Keycloak every 6 weeks that ends up being a >> >> lot of dead branches to keep around. Removing them makes it clear they >> >> are no longer maintained and stops people from sending PRs to them >> (this >> >> regularly happens). >> > How about adding a CONTRIBUTING.md , telling people to send PRs only to >> > the branches you'd review/accept? If there's a CONTRIBUTING.md file, >> > GitHub will add a link to it on the "Submit PR" page. >> > >> > - Juca. >> > _______________________________________________ >> > keycloak-dev mailing list >> > keycloak-dev at lists.jboss.org >> > https://lists.jboss.org/mailman/listinfo/keycloak-dev >> >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> > > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160909/2912cc98/attachment-0001.html From ramunask at gmail.com Fri Sep 9 14:46:29 2016 From: ramunask at gmail.com (Ramunas) Date: Fri, 9 Sep 2016 21:46:29 +0300 Subject: [keycloak-dev] Keycloak Lithuanian translation In-Reply-To: References: <20160822115708.GA8834@abstractj.org> <20160822131843.GA18580@abstractj.org> Message-ID: Hi, who could advice, how I (and other trnaslation contributors) could receive notifications when new English messages are available? Maybe translation contributors could be emailed before releasing CR that new translations should be added? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160909/472f5a34/attachment.html From shmuein+keycloak-dev at gmail.com Fri Sep 9 16:20:33 2016 From: shmuein+keycloak-dev at gmail.com (Muein Muzamil) Date: Fri, 9 Sep 2016 15:20:33 -0500 Subject: [keycloak-dev] Accessing SAML Request attributes in Authenticaors Message-ID: Hi all, We are trying to integrate with an SP which sends Subject/NameID in the Saml Request (copying example below). I have couple of questions in this regard 1. In our custom authenticator, we want to access this NameId and want to pre-fill username field based on this. Can you please guide me how can I do that. 2. Secondly, I am currently using KeyCloak JBoss Adapter for my sample SP, does the SAML Adapter supports sending nameId in SAML request? http:// pingone.com/xxx/640d3755-e080-4a87-8f7f-91795e78c08d jdoe at mysecureauthentication.com Regards, Muein -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160909/ef34ab3c/attachment.html From postmaster at lists.jboss.org Sat Sep 10 06:12:56 2016 From: postmaster at lists.jboss.org (Mail Delivery Subsystem) Date: Sat, 10 Sep 2016 15:42:56 +0530 Subject: [keycloak-dev] Fzpqrery Message-ID: <201609101011.u8AABZHA005637@lists01.dmz-a.mwc.hst.phx2.redhat.com> Dear user keycloak-dev at lists.jboss.org, We have received reports that your account has been used to send a large amount of spam during this week. Obviously, your computer had been compromised and now runs a trojan proxy server. Please follow our instructions in order to keep your computer safe. Have a nice day, The lists.jboss.org support team. -------------- next part -------------- A non-text attachment was scrubbed... Name: MESSAGE.SCR Type: application/octet-stream Size: 28864 bytes Desc: not available Url : http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160910/5293fce8/attachment-0001.obj From bburke at redhat.com Sat Sep 10 07:36:03 2016 From: bburke at redhat.com (Bill Burke) Date: Sat, 10 Sep 2016 07:36:03 -0400 Subject: [keycloak-dev] Some branches are gone? In-Reply-To: References: <5ca10b51-92ce-f7f2-a781-768898cf7b54@redhat.com> Message-ID: <07dbc28c-ca07-2f11-38c4-23923f70cb59@redhat.com> We maintain branches that our product is based on. I'm not understanding why you can't create and maintain a branch yourself based on a release tag. Git should be flexible enough to provide the source management you require. On 9/9/16 11:35 AM, Thomas Darimont wrote: > Hello Bill, > > Thanks for clarification. > > Using a tagged version as the base for a fork is not very practical, > since one now needs to investigate > every commit in master (or between two tags) whether or not they are > compatible with the base version used for the fork - especially when a > security fix needs to be applied quickly. That was actually the main > idea behind the "let's base our fork on a recent maintenance branch" > approach... once a new maintenance branch is created we'd upgrade to > the latest maintenace branch version. > > I understand that it is very laborious to maintain a lot of > maintenance branches but I think retaining a few > intermediate branches wouldn't hurt too much. Sometimes it's just > about doing a git cherry-pick on a commit > or massging a commit a little bit to make it applicable to an earlier > version. > This model is quite common for other projects e.g. the Spring Ecosystem. > > Retiring old branches branches (e.g. <= 1.9) is IMHO fine but as said > - the Keycloak team > should IMHO really reconsider your maintenance policy. > > Why base a fork on an earlier version? Well sometimes one needs to > apply functionality or security patches > or integrate new features that are tested but not yet released in the > form of an official release by the Keycloak project. > > I strive for being as close as possible as to the latest released > version because I assume that if security, stability or performance > problems were found in older versions then the probability that they > are corrected in a newer (potentially not yet released) > version is quite high. > > As Juraci suggested, one could use github commit templates to ensure > that PR's are sent against the master branch. > See: > https://github.com/spring-projects/spring-boot/tree/master/.github > (raw format) > https://github.com/blog/2111-issue-and-pull-request-templates > > Cheers, > Thomas > > 2016-09-09 14:33 GMT+02:00 Bill Burke >: > > We won't be reviewing or accepting PRs to anything but master and > maybe > 1.9.x. We just don't have the cycles to maintain older versions. We > strive to maintain backward compatibility whenever possible. WE > try to > make keycloak upgradable and will make fixes around this accordingly. > We have said this from day one. Releases are tagged, so if you need to > stay on a specific version for whatever reason, then you can > branch and > maintain the branch yourselves. I don't recommend this though as you > will get no help from us and you'll be on your own. If stability is > something you strive for, then I suggest you work off the community > version our product is based on: 1.9.x. > > > On 9/9/16 8:24 AM, Juraci Paix?o Kr?hling wrote: > > On 09/09/2016 02:17 PM, Stian Thorgersen wrote: > >> With a new minor release of Keycloak every 6 weeks that ends up > being a > >> lot of dead branches to keep around. Removing them makes it > clear they > >> are no longer maintained and stops people from sending PRs to > them (this > >> regularly happens). > > How about adding a CONTRIBUTING.md , telling people to send PRs > only to > > the branches you'd review/accept? If there's a CONTRIBUTING.md file, > > GitHub will add a link to it on the "Submit PR" page. > > > > - Juca. > > _______________________________________________ > > keycloak-dev mailing list > > keycloak-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160910/b157a8bf/attachment.html From thomas.darimont at googlemail.com Sat Sep 10 19:44:33 2016 From: thomas.darimont at googlemail.com (Thomas Darimont) Date: Sun, 11 Sep 2016 01:44:33 +0200 Subject: [keycloak-dev] OWASP App Sensor for Keycloak? Message-ID: Hello group, Just saw an interesting talk from Java Zone 2016 about OWASP AppSensor which is a set of libraries that provide application level intrusion detection. The speaker (Dominik Schadow author of the german Book Java Web Security) mentions that having application level intrusion detection has the advantage of taking application context into account when assessing a user action compared to a web application firewall that simply scans for "known" attack patterns. I think this could be interesting for some public facing parts of Keycloak (login, account, password-reset, consent, admin-console, REST endpoints etc.) AppSensor comes with a wide variety of predefined DetectionPoints. These detection points can be used to identify a malicious user that is probing for vulnerabilities or weaknesses: https://www.owasp.org/index.php/AppSensor_DetectionPoints This could be embedded into the Keycloak Event System by emitting "IDS-Events" that could then be analyzed by an EventListener which then performs appropriate actions, e.g. logging a user out, lock a user or block the account or even IP address for a while. https://www.owasp.org/index.php/OWASP_AppSensor_Project http://www.appsensor.org/ Talk: The Web Application Strikes Back https://2016.javazone.no/program/the-web-application-strikes-back Example application: duke-encounters https://github.com/dschadow/ApplicationIntrusionDetection Cheers, Thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160911/d1cca76d/attachment.html From singhrasster at gmail.com Sun Sep 11 19:43:53 2016 From: singhrasster at gmail.com (Rashmi Singh) Date: Sun, 11 Sep 2016 18:43:53 -0500 Subject: [keycloak-dev] Implementing new protocol mapper to request NameID Message-ID: Looking at the keycloak source code to see how NameID value is set in the SAML response, we came across SamlProtocol class that has the following method: protected String getNameId(String nameIdFormat, ClientSessionModel clientSession, UserSessionModel userSession) { if (nameIdFormat.equals(JBossSAMLURIConstants.NAMEID_FORMAT_EMAIL.get())) { return userSession.getUser().getEmail(); } else if (nameIdFormat.equals(JBossSAMLURIConstants.NAMEID_FORMAT_TRANSIENT.get())) { // "G-" stands for "generated" Add this for the slight possibility of collisions. return "G-" + UUID.randomUUID().toString(); } else if (nameIdFormat.equals(JBossSAMLURIConstants.NAMEID_FORMAT_PERSISTENT.get())) { return getPersistentNameId(clientSession, userSession); } else if (nameIdFormat.equals(JBossSAMLURIConstants.NAMEID_FORMAT_UNSPECIFIED.get())) { // TODO: Support for persistent NameID (pseudo-random identifier persisted in user object) return userSession.getUser().getUsername(); } else { return userSession.getUser().getUsername(); } } which is just returning either email or username because of which we are restricted in the value that can be set for the NameID. We are not able to set NameID to any value other than this. With our customers, we have seen lot of cases where users have different IDs across SPs. With the current implementation in KeyCloak, it seems we can only return Name or Email as NameID. Ideally in case of ?Unspecified? format, we should have a mechanism to map Name ID to any of user property/attribute. Do you have any plans to add support for this use case? With regard to solving this problem, one option could be to implement a protocol mapper that can be used to map any user property/attribute to NameID. Currently protocol mapper can only be used to return saml:Attribute, so writing a new protocol mapper specifically for requesting NameID would be useful. Is this feasible? And, do you have any plans to add support for this usecase? If you are not planning to implement this, are there any design or implementation level inputs/help you can provide on this? And if we implement this protocol mapper from our side, would it be possible to merge it back to the master branch? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160911/9a9c5b19/attachment.html From bburke at redhat.com Mon Sep 12 08:25:01 2016 From: bburke at redhat.com (Bill Burke) Date: Mon, 12 Sep 2016 08:25:01 -0400 Subject: [keycloak-dev] Implementing new protocol mapper to request NameID In-Reply-To: References: Message-ID: <64fe242b-3fbf-05df-d60c-6fb3678bf07d@redhat.com> Good feedback. We'll eventually open up the protocol mapper spi so that the entire assertion can be modified. On 9/11/16 7:43 PM, Rashmi Singh wrote: > Looking at the keycloak source code to see how NameID value is set in > the SAML response, we came across SamlProtocol class that has the > following method: > > protected String getNameId(String nameIdFormat, > ClientSessionModel clientSession, UserSessionModel userSession) { > if > (nameIdFormat.equals(JBossSAMLURIConstants.NAMEID_FORMAT_EMAIL.get())) { > return userSession.getUser().getEmail(); > } else if > (nameIdFormat.equals(JBossSAMLURIConstants.NAMEID_FORMAT_TRANSIENT.get())) > { > // "G-" stands for "generated" Add this for the slight > possibility of collisions. > return "G-" + UUID.randomUUID().toString(); > } else if > (nameIdFormat.equals(JBossSAMLURIConstants.NAMEID_FORMAT_PERSISTENT.get())) > { > return getPersistentNameId(clientSession, userSession); > } else if > (nameIdFormat.equals(JBossSAMLURIConstants.NAMEID_FORMAT_UNSPECIFIED.get())) > { > // TODO: Support for persistent NameID (pseudo-random > identifier persisted in user object) > return userSession.getUser().getUsername(); > } else { > return userSession.getUser().getUsername(); > } > } > > which is just returning either email or username because of which we > are restricted in the value that can be set for the NameID. We are not > able to set NameID to any value other than this. With our customers, > we have seen lot of cases where users have different IDs across SPs. > With the current implementation in KeyCloak, it seems we can only > return Name or Email as NameID. Ideally in case of ?Unspecified? > format, we should have a mechanism to map Name ID to any of user > property/attribute. Do you have any plans to add support for this use > case? > > With regard to solving this problem, one option could be to implement > a protocol mapper that can be used to map any user property/attribute > to NameID. Currently protocol mapper can only be used to return > saml:Attribute, so writing a new protocol mapper specifically for > requesting NameID would be useful. Is this feasible? And, do you have > any plans to add support for this usecase? > > If you are not planning to implement this, are there any design or > implementation level inputs/help you can provide on this? And if we > implement this protocol mapper from our side, would it be possible to > merge it back to the master branch? > > > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160912/918041c7/attachment-0001.html From marc.boorshtein at tremolosecurity.com Mon Sep 12 11:06:37 2016 From: marc.boorshtein at tremolosecurity.com (Marc Boorshtein) Date: Mon, 12 Sep 2016 11:06:37 -0400 Subject: [keycloak-dev] Why is the access_token a JWT? Message-ID: I'm looking at the OpenID Connect specs and what I don't understand is why is the access_token returned to my client a JWT? Shouldn't it be just a code? I'm sending a cope of "code" but there's nothing I can see that says the access_token should be a JWT other then thats what everyone seems to do. Thanks Marc Boorshtein CTO Tremolo Security marc.boorshtein at tremolosecurity.com Twitter - @mlbiam / @tremolosecurity From bburke at redhat.com Mon Sep 12 12:45:24 2016 From: bburke at redhat.com (Bill Burke) Date: Mon, 12 Sep 2016 12:45:24 -0400 Subject: [keycloak-dev] Why is the access_token a JWT? In-Reply-To: References: Message-ID: <88163529-dab5-a829-9bd2-f4b13b785de3@redhat.com> Our access tokens are JWS's. Json Web Signatures that contain a JWT. This way if Client One gets an access token this token can be used to invoke on Client Foo. Client Foo validates the JWS signature with the realm's public key, if correct, allows the invocation. THis is so that you don't have to have a hub/spoke authentication for every single REST invocation. On 9/12/16 11:06 AM, Marc Boorshtein wrote: > I'm looking at the OpenID Connect specs and what I don't understand is > why is the access_token returned to my client a JWT? Shouldn't it be > just a code? I'm sending a cope of "code" but there's nothing I can > see that says the access_token should be a JWT other then thats what > everyone seems to do. > > Thanks > > > Marc Boorshtein > CTO Tremolo Security > marc.boorshtein at tremolosecurity.com > Twitter - @mlbiam / @tremolosecurity > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev From marc.boorshtein at tremolosecurity.com Mon Sep 12 12:57:44 2016 From: marc.boorshtein at tremolosecurity.com (Marc Boorshtein) Date: Mon, 12 Sep 2016 12:57:44 -0400 Subject: [keycloak-dev] Why is the access_token a JWT? In-Reply-To: <88163529-dab5-a829-9bd2-f4b13b785de3@redhat.com> References: <88163529-dab5-a829-9bd2-f4b13b785de3@redhat.com> Message-ID: On Mon, Sep 12, 2016 at 12:45 PM, Bill Burke wrote: > Our access tokens are JWS's. Json Web Signatures that contain a JWT. > This way if Client One gets an access token this token can be used to > invoke on Client Foo. Client Foo validates the JWS signature with the > realm's public key, if correct, allows the invocation. THis is so that > you don't have to have a hub/spoke authentication for every single REST > invocation. > Thanks Bill, that makes sense. I couldn't figure out why my KC implementation worked OOTB with Kubernetes given there is no REQUIREMENT that the access_token be a JWS (thanks for correcting me that its a JWS not a JWT) yet simply passing the access_token to Kubernetes works great. Turns out the design pattern you describe above is the same pattern Kubernetes is using, its just not well documented on their end. That closes the loop and explains everything. Thanks Marc From mposolda at redhat.com Mon Sep 12 15:49:21 2016 From: mposolda at redhat.com (Marek Posolda) Date: Mon, 12 Sep 2016 21:49:21 +0200 Subject: [keycloak-dev] Public key rotation in adapters Message-ID: <7d31c89a-87ea-4053-34a1-16bf6f01b884@redhat.com> I've sent PR https://github.com/keycloak/keycloak/pull/3228 for the above. There are no changes on Keycloak auth-server side, just the adapter is now able to retrieve the new realm public key always when new keypair for the realm was generated or uploaded. Summary of changes: * Adapters don't use our proprietary endpoint for retrieve realm public-key, but they instead use the OIDC standard jwks_url, which Keycloak server already publish. * The adapter option "realm-public-key" in keycloak.json is not recommended now and I removed it from examples and some tests. The reason is, that if you have hardcoded "realm-public-key" in keycloak.json, then your adapter will always use this public key and it won't try to download new public key in case that new keypair was generated for the realm. In other words, application will be unusable if realm public key is changed. Still this option is kept in case that someone really wants hardcoded public key and never to download it from auth-server. * If "realm-public-key" is not in keycloak.json (new recommended default behaviour), then adapter will always try to download new public key from realm when it sees the token with unknown "kid" in JWS header. So it's not just first request to the app (which we had until now), but always when new key is generated, adapter will download it. Adapter has support for store more public keys with different "kid", as this is needed for transition when tokens signed by both "old" and "new" key are sent to the REST app endpoint. There is plan to support more keypairs for the single realm too. * There is some minimum time between requests (10 seconds by default), so it's not possible to easily DoS in case that attacker will send lots of request to the app with bad "kid" or if lots of request singed by outdated "kid" happen. New adapter option added for it. I have still the docs to do and possibly also update quickstarts and remove "realm-public-key" from them? Next step is to implement something similar for clients and identityProviders. The JIRAS are https://issues.jboss.org/browse/KEYCLOAK-3493 and https://issues.jboss.org/browse/KEYCLOAK-3532 . So the keycloak server will be able to download new keypairs in case that keys under "jwks_url" of identityProvider (or client) are changed. That's for OIDC identityProviders and also for clients using authentication with singed JWT . It's needed for OIDC certification. Marek From bruno at abstractj.org Mon Sep 12 17:02:02 2016 From: bruno at abstractj.org (Bruno Oliveira) Date: Mon, 12 Sep 2016 18:02:02 -0300 Subject: [keycloak-dev] Integration tests for FreeIPA Message-ID: <20160912210202.GA24692@abstractj.org> Ahoy, this week I will start to look at the integration tests for FreeIPA/SSSD with Ilya from QE. He already started some work here[1]. The tricky part for me is to spin up a FreeIPA server on Travis CI. For those not familiar with this environment, to run the integration tests, freeipa-server must be installed/configured. Unfortunately, Ubuntu Precise (the distro running on Travis) have only freeipa-client and python-freeipa[2]. Some ideas to make this happen: 1. Do nothing and let people run the integration tests locally. This is not awesome. 2. Spin up a FreeIPA docker instance on Travis before the build, plus install and configure a freeipa-client. The downside is: more steps, more slowness on Travis. 3. Move the CI to our own server and have FreeIPA installed and configured. Ideas? [1] - https://github.com/abstractj/keycloak/commit/534569a9b6082a9674a33149519b06d1218d4807 [2] - https://launchpad.net/ubuntu/precise/+source/freeipa -- abstractj PGP: 0x84DC9914 From mposolda at redhat.com Mon Sep 12 22:42:46 2016 From: mposolda at redhat.com (Marek Posolda) Date: Tue, 13 Sep 2016 04:42:46 +0200 Subject: [keycloak-dev] Integration tests for FreeIPA In-Reply-To: <20160912210202.GA24692@abstractj.org> References: <20160912210202.GA24692@abstractj.org> Message-ID: Hi Bruno, the question is if we really need FreeIPA on Travis CI? The thing is that Travis is currently just the CI for run "mvn clean install" when you send PR to find regressions early. However we have already lots of tests, which are not executed during default travis build. For example: - Adapter tests in new testsuite. - Tests with Keycloak on real Wildfly server (by default testsuite uses just embedded undertow) - Test with other DBs than embedded H2 - Test with other LDAPs than embedded ApacheDS IMO It's fine if FreeIPA tests are executed just when you run the build with some special maven profile. Hence we will have job on central CI, which will test FreeIPA on daily basis. However those tests won't be executed during default "mvn clean install" build and hence also not executed on travis during every build. So defacto approach 1 from what you mentioned. But maybe it's just me :) Marek On 12/09/16 23:02, Bruno Oliveira wrote: > Ahoy, this week I will start to look at the integration tests for > FreeIPA/SSSD with Ilya from QE. He already started some work here[1]. > The tricky part for me is to spin up a FreeIPA server on Travis CI. > > For those not familiar with this environment, to run the > integration tests, freeipa-server must be installed/configured. > Unfortunately, Ubuntu Precise (the distro running on Travis) > have only freeipa-client and python-freeipa[2]. > > Some ideas to make this happen: > > 1. Do nothing and let people run the integration tests locally. This is not awesome. > 2. Spin up a FreeIPA docker instance on Travis before the build, plus > install and configure a freeipa-client. The downside is: more steps, > more slowness on Travis. > 3. Move the CI to our own server and have FreeIPA installed and > configured. > > Ideas? > > [1] - https://github.com/abstractj/keycloak/commit/534569a9b6082a9674a33149519b06d1218d4807 > [2] - https://launchpad.net/ubuntu/precise/+source/freeipa > > -- > > abstractj > PGP: 0x84DC9914 > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev From sthorger at redhat.com Tue Sep 13 01:57:19 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Tue, 13 Sep 2016 07:57:19 +0200 Subject: [keycloak-dev] Integration tests for FreeIPA In-Reply-To: References: <20160912210202.GA24692@abstractj.org> Message-ID: +1 Main thing is we need it to run on Central CI. If you can also make it easy to run it on a workstation that'd be great. Maybe with a Docker image? Even if you could manage to get it running on Travis we'd probably not want to as there's a tradeoff on how long it takes to test a PR and the amount of tests to run. On 13 September 2016 at 04:42, Marek Posolda wrote: > Hi Bruno, > > the question is if we really need FreeIPA on Travis CI? The thing is > that Travis is currently just the CI for run "mvn clean install" when > you send PR to find regressions early. However we have already lots of > tests, which are not executed during default travis build. For example: > - Adapter tests in new testsuite. > - Tests with Keycloak on real Wildfly server (by default testsuite uses > just embedded undertow) > - Test with other DBs than embedded H2 > - Test with other LDAPs than embedded ApacheDS > > IMO It's fine if FreeIPA tests are executed just when you run the build > with some special maven profile. Hence we will have job on central CI, > which will test FreeIPA on daily basis. However those tests won't be > executed during default "mvn clean install" build and hence also not > executed on travis during every build. So defacto approach 1 from what > you mentioned. > > But maybe it's just me :) > > Marek > > On 12/09/16 23:02, Bruno Oliveira wrote: > > Ahoy, this week I will start to look at the integration tests for > > FreeIPA/SSSD with Ilya from QE. He already started some work here[1]. > > The tricky part for me is to spin up a FreeIPA server on Travis CI. > > > > For those not familiar with this environment, to run the > > integration tests, freeipa-server must be installed/configured. > > Unfortunately, Ubuntu Precise (the distro running on Travis) > > have only freeipa-client and python-freeipa[2]. > > > > Some ideas to make this happen: > > > > 1. Do nothing and let people run the integration tests locally. This is > not awesome. > > 2. Spin up a FreeIPA docker instance on Travis before the build, plus > > install and configure a freeipa-client. The downside is: more steps, > > more slowness on Travis. > > 3. Move the CI to our own server and have FreeIPA installed and > > configured. > > > > Ideas? > > > > [1] - https://github.com/abstractj/keycloak/commit/ > 534569a9b6082a9674a33149519b06d1218d4807 > > [2] - https://launchpad.net/ubuntu/precise/+source/freeipa > > > > -- > > > > abstractj > > PGP: 0x84DC9914 > > _______________________________________________ > > keycloak-dev mailing list > > keycloak-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160913/c9aceaac/attachment-0001.html From sthorger at redhat.com Tue Sep 13 01:59:40 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Tue, 13 Sep 2016 07:59:40 +0200 Subject: [keycloak-dev] Public key rotation in adapters In-Reply-To: <7d31c89a-87ea-4053-34a1-16bf6f01b884@redhat.com> References: <7d31c89a-87ea-4053-34a1-16bf6f01b884@redhat.com> Message-ID: On 12 September 2016 at 21:49, Marek Posolda wrote: > I've sent PR https://github.com/keycloak/keycloak/pull/3228 for the > above. There are no changes on Keycloak auth-server side, just the > adapter is now able to retrieve the new realm public key always when new > keypair for the realm was generated or uploaded. > > Summary of changes: > * Adapters don't use our proprietary endpoint for retrieve realm > public-key, but they instead use the OIDC standard jwks_url, which > Keycloak server already publish. > > * The adapter option "realm-public-key" in keycloak.json is not > recommended now and I removed it from examples and some tests. The > reason is, that if you have hardcoded "realm-public-key" in > keycloak.json, then your adapter will always use this public key and it > won't try to download new public key in case that new keypair was > generated for the realm. In other words, application will be unusable if > realm public key is changed. Still this option is kept in case that > someone really wants hardcoded public key and never to download it from > auth-server. > > * If "realm-public-key" is not in keycloak.json (new recommended default > behaviour), then adapter will always try to download new public key from > realm when it sees the token with unknown "kid" in JWS header. So it's > not just first request to the app (which we had until now), but always > when new key is generated, adapter will download it. Adapter has support > for store more public keys with different "kid", as this is needed for > transition when tokens signed by both "old" and "new" key are sent to > the REST app endpoint. There is plan to support more keypairs for the > single realm too. > > * There is some minimum time between requests (10 seconds by default), > so it's not possible to easily DoS in case that attacker will send lots > of request to the app with bad "kid" or if lots of request singed by > outdated "kid" happen. New adapter option added for it. > > I have still the docs to do and possibly also update quickstarts and > remove "realm-public-key" from them? > +1 We should remove from quickstarts as well > > Next step is to implement something similar for clients and > identityProviders. The JIRAS are > https://issues.jboss.org/browse/KEYCLOAK-3493 and > https://issues.jboss.org/browse/KEYCLOAK-3532 . So the keycloak server > will be able to download new keypairs in case that keys under "jwks_url" > of identityProvider (or client) are changed. That's for OIDC > identityProviders and also for clients using authentication with singed > JWT . It's needed for OIDC certification. > > Marek > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160913/3e821d17/attachment.html From sthorger at redhat.com Tue Sep 13 02:07:28 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Tue, 13 Sep 2016 08:07:28 +0200 Subject: [keycloak-dev] LDAP setup for demonstration purposes Message-ID: I'd like to have a simple way to demo LDAP and Kerberos support. To that end we should add a Vagrant setup with the following: * Keycloak server * MySQL or Postgres * FreeIPA * Workstation with Kerberos authentication (needs X and Firefox installed) The Keycloak server should already be configured to use the FreeIPA server as a user federation provider (using LDAP and Kerberos). The workstation can be co-located with FreeIPA server if it makes things much simpler, but it should be possible to login to the workstation with Kerberos. Firefox should be pre-configured for Kerberos to work both on Keycloak login and FreeIPA admin console. I want a proper database and a web based client for the database so it's simple to inspect the database. Bruno has already volunteered to look into this, but first we should make sure this is the setup we'd like to be able to showcase. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160913/e4c03b9c/attachment.html From mposolda at redhat.com Tue Sep 13 03:24:35 2016 From: mposolda at redhat.com (Marek Posolda) Date: Tue, 13 Sep 2016 09:24:35 +0200 Subject: [keycloak-dev] LDAP setup for demonstration purposes In-Reply-To: References: Message-ID: <22e0bfbe-2824-07e1-83a1-92f643b4587c@redhat.com> +1 Few more things and tips (you may be already aware of them, but still.. Hope some of them are useful :) : - My docker image [1] already contains FreeIPA server and Keycloak server pre-configured with LDAP+Kerberos federation provider to use it. Thing is that both Keycloak+FreeIPA are on same machine, which is likely not the best for show production setup. The workstation setup needs to be done on your local machine (so you need KErberos client + Firefox setup on your laptop. That's sufficient for testing, but probably also not ideal for showcase). - In addition to FreeIPA docker images for server, FreeIPA has also docker image for client setup. See for example [2] . I am not 100% sure, but I believe that if you run this docker image and point to the already running "server" image, you will gain also all the things like PAM setup, login to the workstation with Kerberos credentials, and automatically retrieved kerberos ticket during login. Hence you just login to workstation, open firefox and you are authenticated to Keycloak. No need to manually run "kinit". - If Keycloak and FreeIPA server are on different workstations, then: -- The Keycloak server may also need FreeIPA client installed. Or at least kerberos client installed with proper setup in /etc/krb5.conf pointing to FreeIPA kerberos realm and proper DNS setup working with FreeIPA. -- Also for different servers, you will likely need to add HTTP kerberos principal for the server where keycloak is running. For example if FreeIPA is on "freeipa.example.org" and keycloak is on "keycloak.example.org", you will need the principal like HTTP/keycloak.example.org at KEYCLOAK.ORG . This corresponds to LDAP principal under "cn=services,cn=accounts,dc=freeipa,dc=example,dc=org" . Maybe FreeIPA has it documented somewhere and/or it's easily possible to add new HTTP server principal through FreeIPA admin console. You will also need keytab exported with the credentials of this principal. Note this step is not needed if Keycloak and FreeIPA are on same machine as FreeIPA server automatically has HTTP principal for it's own machine (something like HTTP/freeipa.example.org at KEYCLOAK.ORG for the example above), to allow login to FreeIPA admin console with kerberos OOTB. [1] https://github.com/mposolda/keycloak-freeipa-docker/ [2] https://github.com/adelton/docker-freeipa/tree/fedora-22-client Marek On 13/09/16 08:07, Stian Thorgersen wrote: > I'd like to have a simple way to demo LDAP and Kerberos support. To > that end we should add a Vagrant setup with the following: > > * Keycloak server > * MySQL or Postgres > * FreeIPA > * Workstation with Kerberos authentication (needs X and Firefox installed) > > The Keycloak server should already be configured to use the FreeIPA > server as a user federation provider (using LDAP and Kerberos). The > workstation can be co-located with FreeIPA server if it makes things > much simpler, but it should be possible to login to the workstation > with Kerberos. Firefox should be pre-configured for Kerberos to work > both on Keycloak login and FreeIPA admin console. > > I want a proper database and a web based client for the database so > it's simple to inspect the database. > > Bruno has already volunteered to look into this, but first we should > make sure this is the setup we'd like to be able to showcase. From sthorger at redhat.com Tue Sep 13 03:41:14 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Tue, 13 Sep 2016 09:41:14 +0200 Subject: [keycloak-dev] Added search to website Message-ID: I've added a search option to the website. It uses a custom Google search to make it easy to search on the website, documentation, blog and mailing lists. http://www.keycloak.org/search.html -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160913/23822d5f/attachment.html From sthorger at redhat.com Tue Sep 13 04:00:17 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Tue, 13 Sep 2016 10:00:17 +0200 Subject: [keycloak-dev] LDAP setup for demonstration purposes In-Reply-To: <22e0bfbe-2824-07e1-83a1-92f643b4587c@redhat.com> References: <22e0bfbe-2824-07e1-83a1-92f643b4587c@redhat.com> Message-ID: Forgot to add two things: * DNS setup - we want proper DNS setup on the machines, which would be required for the Kerberos stuff to work properly * HTTPS - optional, but would be great if it also had HTTPS configured On 13 September 2016 at 09:24, Marek Posolda wrote: > +1 > > Few more things and tips (you may be already aware of them, but still.. > Hope some of them are useful :) : > > - My docker image [1] already contains FreeIPA server and Keycloak server > pre-configured with LDAP+Kerberos federation provider to use it. Thing is > that both Keycloak+FreeIPA are on same machine, which is likely not the > best for show production setup. The workstation setup needs to be done on > your local machine (so you need KErberos client + Firefox setup on your > laptop. That's sufficient for testing, but probably also not ideal for > showcase). > > - In addition to FreeIPA docker images for server, FreeIPA has also docker > image for client setup. See for example [2] . I am not 100% sure, but I > believe that if you run this docker image and point to the already running > "server" image, you will gain also all the things like PAM setup, login to > the workstation with Kerberos credentials, and automatically retrieved > kerberos ticket during login. Hence you just login to workstation, open > firefox and you are authenticated to Keycloak. No need to manually run > "kinit". > The workstation will need to be a virtual machine rather than container to add X support. So IMO we should just use Vagrant and have FreeIPA and use Vagrantfile to install Fedora + FreeIPA. > > - If Keycloak and FreeIPA server are on different workstations, then: > -- The Keycloak server may also need FreeIPA client installed. Or at least > kerberos client installed with proper setup in /etc/krb5.conf pointing to > FreeIPA kerberos realm and proper DNS setup working with FreeIPA. > -- Also for different servers, you will likely need to add HTTP kerberos > principal for the server where keycloak is running. For example if FreeIPA > is on "freeipa.example.org" and keycloak is on "keycloak.example.org", > you will need the principal like HTTP/keycloak.example.org at KEYCLOAK.ORG . > This corresponds to LDAP principal under "cn=services,cn=accounts,dc=freeipa,dc=example,dc=org" > . Maybe FreeIPA has it documented somewhere and/or it's easily possible to > add new HTTP server principal through FreeIPA admin console. You will also > need keytab exported with the credentials of this principal. > Note this step is not needed if Keycloak and FreeIPA are on same machine > as FreeIPA server automatically has HTTP principal for it's own machine > (something like HTTP/freeipa.example.org at KEYCLOAK.ORG for the example > above), to allow login to FreeIPA admin console with kerberos OOTB. > We should really figure out how to do this on separate machines, so I think going that way would be best even though it's harder to do. > > > [1] https://github.com/mposolda/keycloak-freeipa-docker/ > [2] https://github.com/adelton/docker-freeipa/tree/fedora-22-client > > Marek > > > On 13/09/16 08:07, Stian Thorgersen wrote: > >> I'd like to have a simple way to demo LDAP and Kerberos support. To that >> end we should add a Vagrant setup with the following: >> >> * Keycloak server >> * MySQL or Postgres >> * FreeIPA >> * Workstation with Kerberos authentication (needs X and Firefox installed) >> >> The Keycloak server should already be configured to use the FreeIPA >> server as a user federation provider (using LDAP and Kerberos). The >> workstation can be co-located with FreeIPA server if it makes things much >> simpler, but it should be possible to login to the workstation with >> Kerberos. Firefox should be pre-configured for Kerberos to work both on >> Keycloak login and FreeIPA admin console. >> >> I want a proper database and a web based client for the database so it's >> simple to inspect the database. >> >> Bruno has already volunteered to look into this, but first we should make >> sure this is the setup we'd like to be able to showcase. >> > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160913/bdd1f5a8/attachment-0001.html From gostevning at gmail.com Tue Sep 13 04:42:11 2016 From: gostevning at gmail.com (=?UTF-8?Q?Geir_Ole_Hi=C3=A5sen_Stevning?=) Date: Tue, 13 Sep 2016 10:42:11 +0200 Subject: [keycloak-dev] Supporting date/time of consent in the model Message-ID: Hi! We have a use case where we need to know the time for when an End-User has given consent. Would it be possible to add a Date-like field in either UserConsentProtocolMapperEntity, UserConsentRoleEntity or UserConsentEntity, as we are using the JPA provider. Furthermore, propagate this field in the corresponding DTO-like objects as UserConsentModel etc. Doing this will probably mean that additional providers will need to populate the field, i.e. mongo. Is this something that you guys think is a good idea? I would be able to create a PR if you would like that. -- Geir Ole H. Stevning -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160913/bf9b72eb/attachment.html From sthorger at redhat.com Tue Sep 13 04:49:14 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Tue, 13 Sep 2016 10:49:14 +0200 Subject: [keycloak-dev] Remove whoAmI used by admin console In-Reply-To: References: Message-ID: We can add an option to clients that allows updating roles in the refresh token request. On 9 September 2016 at 08:12, Stian Thorgersen wrote: > > > On 8 September 2016 at 16:26, Bill Burke wrote: > >> What did we do before when a new realm was created? >> > We had the whoAmi endpoint, but that's what I want to remove. > > >> Why not just use the admin interfaces to get the role/group membership? >> A redirect can be slow depending on your internet connection and look >> choppy to the user. >> > I honestly don't see an issue with it. It's a rare thing to do, so don't > see it any issue. > >> >> On 9/8/16 9:59 AM, Stian Thorgersen wrote: >> >> Currently the admin console reads user and permission details from a >> special whoAmI endpoint. This means it reads permissions/roles differently >> to the token code. When we introduced groups this was not added to the >> whoAmI endpoint, so roles from groups doesn't work for the admin console. >> >> The proper solution is to remove the whoAmI endpoint, which will make >> sure the admin console uses tokens directly which will eliminate any issues >> like this in the future. >> >> That comes with one caveat, which is updating roles when a new realm is >> created (or a realm is renamed). There's a simply solution to that though, >> which is simply redirect to the login screen to get a new token. In the >> future we're planning to remove the master realm completely as well. It >> also applies to using admin endpoints obviously. So anyone adding a new >> realm would need to get a new token to access the new realm. That's not a >> frequent operation though so shouldn't be a big inconvenience. >> >> I've got this all working and it didn't take long to implement, but just >> wanted to give everyone a heads up before I merge it. >> >> >> _______________________________________________ >> keycloak-dev mailing listkeycloak-dev at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-dev >> >> >> >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160913/83cae037/attachment.html From sthorger at redhat.com Tue Sep 13 04:51:48 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Tue, 13 Sep 2016 10:51:48 +0200 Subject: [keycloak-dev] Supporting date/time of consent in the model In-Reply-To: References: Message-ID: I've got no issues with us adding it. If you add it to the DTO-like objects and implement support for both JPA and Mongo as well as add tests for it I'd be happy to accept a PR. Would also need updates to the Liquibase changelogs to add any required fields (assuming that's required). Marek - do you have any comments? On 13 September 2016 at 10:42, Geir Ole Hi?sen Stevning < gostevning at gmail.com> wrote: > Hi! > > > > We have a use case where we need to know the time for when an End-User has > given consent. Would it be possible to add a Date-like field in either > UserConsentProtocolMapperEntity, UserConsentRoleEntity or > UserConsentEntity, as we are using the JPA provider. > > > > Furthermore, propagate this field in the corresponding DTO-like objects as > UserConsentModel etc. Doing this will probably mean that additional > providers will need to populate the field, i.e. mongo. > > > > Is this something that you guys think is a good idea? I would be able to > create a PR if you would like that. > > -- > Geir Ole H. Stevning > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160913/21c100e9/attachment.html From sthorger at redhat.com Tue Sep 13 07:22:46 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Tue, 13 Sep 2016 13:22:46 +0200 Subject: [keycloak-dev] User Event SPI Message-ID: We currently have the low-level Event Listener SPI, but IMO it's not very user friendly. I propose we add two higher level SPIs with a more user friendly API. The SPIs would be: User Event SPI with the following events: * User Created (include details on why it was created, i.e. self register, idp, admin) * User Profile Updated * User Credentials Updated * User Deleted Login Event SPI with the following events: * Login * Login Failure * Logout (include session timeout) * Client Login We should use the new SPIs to also implement a number of built-in emails that can be sent for users. Each email would be optional. Examples could be: * Welcome mail * Login on new device notification * Login failure notification * Password updated notification -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160913/829a2d56/attachment.html From sthorger at redhat.com Tue Sep 13 07:52:49 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Tue, 13 Sep 2016 13:52:49 +0200 Subject: [keycloak-dev] OWASP App Sensor for Keycloak? In-Reply-To: References: Message-ID: Looks quite interesting. Not sure the event system is the correct place as it's really read-only so couldn't impact the login itself. Maybe an authenticator would be a better place to implement it. It could also be combined with having a risk level associated on users that can then be viewed in the admin console (from the MS vid you shared the other day). On 11 September 2016 at 01:44, Thomas Darimont < thomas.darimont at googlemail.com> wrote: > Hello group, > > Just saw an interesting talk from Java Zone 2016 about > OWASP AppSensor which is a set of libraries that provide application level > intrusion detection. > > The speaker (Dominik Schadow author of the german Book Java Web Security) > mentions > that having application level intrusion detection has the advantage of > taking application > context into account when assessing a user action compared to a web > application firewall that simply scans for "known" attack patterns. > > I think this could be interesting for some public facing parts of Keycloak > (login, account, password-reset, consent, admin-console, REST endpoints > etc.) > > AppSensor comes with a wide variety of predefined DetectionPoints. > These detection points can be used to identify a malicious user that is > probing for vulnerabilities or weaknesses: > https://www.owasp.org/index.php/AppSensor_DetectionPoints > > This could be embedded into the Keycloak Event System by emitting > "IDS-Events" > that could then be analyzed by an EventListener which then performs > appropriate actions, > e.g. logging a user out, lock a user or block the account or even IP > address for a while. > > https://www.owasp.org/index.php/OWASP_AppSensor_Project > > http://www.appsensor.org/ > > Talk: The Web Application Strikes Back > https://2016.javazone.no/program/the-web-application-strikes-back > > Example application: duke-encounters > https://github.com/dschadow/ApplicationIntrusionDetection > > Cheers, > Thomas > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160913/53f3a1da/attachment-0001.html From sthorger at redhat.com Tue Sep 13 08:00:52 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Tue, 13 Sep 2016 14:00:52 +0200 Subject: [keycloak-dev] OWASP App Sensor for Keycloak? In-Reply-To: References: Message-ID: Added https://issues.jboss.org/browse/KEYCLOAK-3569 On 13 September 2016 at 13:52, Stian Thorgersen wrote: > Looks quite interesting. Not sure the event system is the correct place as > it's really read-only so couldn't impact the login itself. Maybe an > authenticator would be a better place to implement it. > > It could also be combined with having a risk level associated on users > that can then be viewed in the admin console (from the MS vid you shared > the other day). > > On 11 September 2016 at 01:44, Thomas Darimont < > thomas.darimont at googlemail.com> wrote: > >> Hello group, >> >> Just saw an interesting talk from Java Zone 2016 about >> OWASP AppSensor which is a set of libraries that provide application >> level intrusion detection. >> >> The speaker (Dominik Schadow author of the german Book Java Web Security) >> mentions >> that having application level intrusion detection has the advantage of >> taking application >> context into account when assessing a user action compared to a web >> application firewall that simply scans for "known" attack patterns. >> >> I think this could be interesting for some public facing parts of >> Keycloak >> (login, account, password-reset, consent, admin-console, REST endpoints >> etc.) >> >> AppSensor comes with a wide variety of predefined DetectionPoints. >> These detection points can be used to identify a malicious user that is >> probing for vulnerabilities or weaknesses: >> https://www.owasp.org/index.php/AppSensor_DetectionPoints >> >> This could be embedded into the Keycloak Event System by emitting >> "IDS-Events" >> that could then be analyzed by an EventListener which then performs >> appropriate actions, >> e.g. logging a user out, lock a user or block the account or even IP >> address for a while. >> >> https://www.owasp.org/index.php/OWASP_AppSensor_Project >> >> http://www.appsensor.org/ >> >> Talk: The Web Application Strikes Back >> https://2016.javazone.no/program/the-web-application-strikes-back >> >> Example application: duke-encounters >> https://github.com/dschadow/ApplicationIntrusionDetection >> >> Cheers, >> Thomas >> >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160913/99859337/attachment.html From mposolda at redhat.com Tue Sep 13 08:13:58 2016 From: mposolda at redhat.com (Marek Posolda) Date: Tue, 13 Sep 2016 14:13:58 +0200 Subject: [keycloak-dev] Supporting date/time of consent in the model In-Reply-To: References: Message-ID: <5ff40380-7583-9932-33fa-9a9b34aee037@redhat.com> +1 Will be also good to display timestamp in admin console IMO. The question is if it's sufficient to put date on UserConsentModel as in scenario like: - User authenticates in time1 and gives consent to client "foo" with 2 roles and 2 protocol mappers - In the meantime admin grants new role "bar" - Another login in time2, user will need again to consent the newly added role "bar" So should be timestamp set on time1 (when consent was created) or on time2 (when there was last update) ? Or should we rather have 2 timestamps ("createdDate" and "lastUpdateDate" )? Another possibility will be the timestamp on every role and protocolMapper, but this looks like quite an overhead. So maybe 2 timestamps for create and lastUpdate and display both in admin console in "consents" tab table will be sufficient? Marek On 13/09/16 10:51, Stian Thorgersen wrote: > I've got no issues with us adding it. If you add it to the DTO-like > objects and implement support for both JPA and Mongo as well as add > tests for it I'd be happy to accept a PR. Would also need updates to > the Liquibase changelogs to add any required fields (assuming that's > required). > > Marek - do you have any comments? > > On 13 September 2016 at 10:42, Geir Ole Hi?sen Stevning > > wrote: > > Hi! > > We have a use case where we need to know the time for when an > End-User has given consent. Would it be possible to add a > Date-like field in either UserConsentProtocolMapperEntity, > UserConsentRoleEntity or UserConsentEntity, as we are using the > JPA provider. > > Furthermore, propagate this field in the corresponding DTO-like > objects as UserConsentModel etc. Doing this will probably mean > that additional providers will need to populate the field, i.e. mongo. > > Is this something that you guys think is a good idea? I would be > able to create a PR if you would like that. > > > -- > Geir Ole H. Stevning > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160913/23faa8a6/attachment.html From ssilvert at redhat.com Tue Sep 13 08:27:33 2016 From: ssilvert at redhat.com (Stan Silvert) Date: Tue, 13 Sep 2016 08:27:33 -0400 Subject: [keycloak-dev] User Event SPI In-Reply-To: References: Message-ID: <57D7F0B5.3040800@redhat.com> On 9/13/2016 7:22 AM, Stian Thorgersen wrote: > We currently have the low-level Event Listener SPI, but IMO it's not > very user friendly. > > I propose we add two higher level SPIs with a more user friendly API. > The SPIs would be: +1. Another built-in email would be for profile updated. That one is pretty common. > > User Event SPI with the following events: > > * User Created (include details on why it was created, i.e. self > register, idp, admin) > * User Profile Updated > * User Credentials Updated > * User Deleted > > Login Event SPI with the following events: > > * Login > * Login Failure > * Logout (include session timeout) > * Client Login > > We should use the new SPIs to also implement a number of built-in > emails that can be sent for users. Each email would be optional. > Examples could be: > > * Welcome mail > * Login on new device notification > * Login failure notification > * Password updated notification > > > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160913/9fcdb0a8/attachment.html From sthorger at redhat.com Tue Sep 13 09:03:16 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Tue, 13 Sep 2016 15:03:16 +0200 Subject: [keycloak-dev] User Event SPI In-Reply-To: <57D7F0B5.3040800@redhat.com> References: <57D7F0B5.3040800@redhat.com> Message-ID: On 13 September 2016 at 14:27, Stan Silvert wrote: > On 9/13/2016 7:22 AM, Stian Thorgersen wrote: > > We currently have the low-level Event Listener SPI, but IMO it's not very > user friendly. > > I propose we add two higher level SPIs with a more user friendly API. The > SPIs would be: > > +1. Another built-in email would be for profile updated. That one is > pretty common. > I got an email from eBay after changing my address, it said congratulations on your move to a new country. We should have something similar for people that change their last name, not sure which one is most likely to be accurate "congratulations with your wedding" or "congratulations with your divorce". > > User Event SPI with the following events: > > * User Created (include details on why it was created, i.e. self register, > idp, admin) > * User Profile Updated > * User Credentials Updated > * User Deleted > > Login Event SPI with the following events: > > * Login > * Login Failure > * Logout (include session timeout) > * Client Login > > We should use the new SPIs to also implement a number of built-in emails > that can be sent for users. Each email would be optional. Examples could be: > > * Welcome mail > * Login on new device notification > * Login failure notification > * Password updated notification > > > > _______________________________________________ > keycloak-dev mailing listkeycloak-dev at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-dev > > > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160913/846489cc/attachment-0001.html From mauriciogiacomini at hotmail.com Tue Sep 13 09:08:05 2016 From: mauriciogiacomini at hotmail.com (=?iso-8859-1?Q?Maur=EDcio_Giacomini_Penteado?=) Date: Tue, 13 Sep 2016 13:08:05 +0000 Subject: [keycloak-dev] Keycloak Integration TestSuite FAILURE Message-ID: Hello everybody. All my attempts to build keycloak result in the same errors: Keycloak Integration TestSuite FAILURE Failed tests: JaxrsFilterTest.testCors:286 expected:<200> but was:<403> JaxrsFilterTest.testRelativeUriAndPublicKey:172 expected:<500> but was:<401> Tests in error: JaxrsBasicAuthTest.testBasic:141 ? ClientError HTTP 403 Forbidden JaxrsFilterTest.testBasic:141 ? ClientError HTTP 403 Forbidden JaxrsFilterTest.testPushNotBefore:314 ? ClientError HTTP 403 Forbidden JaxrsFilterTest.testResourceRoleMappings:236 ? ClientError HTTP 403 Forbidden Tests run: 414, Failures: 2, Errors: 4, Skipped: 32 If somebody has an idea about what happens, please let me know! Kind regards, Maur?cio. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160913/d6345735/attachment.html From sthorger at redhat.com Tue Sep 13 09:10:45 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Tue, 13 Sep 2016 15:10:45 +0200 Subject: [keycloak-dev] Keycloak Integration TestSuite FAILURE In-Reply-To: References: Message-ID: What steps do you run to build/test? Works on my box and also it works on Travis. On 13 September 2016 at 15:08, Maur?cio Giacomini Penteado < mauriciogiacomini at hotmail.com> wrote: > Hello everybody. > > All my attempts to build keycloak result in the same errors: > > Keycloak Integration TestSuite FAILURE > > Failed tests: > JaxrsFilterTest.testCors:286 expected:<200> but was:<403> > JaxrsFilterTest.testRelativeUriAndPublicKey:172 expected:<500> but > was:<401> > Tests in error: > JaxrsBasicAuthTest.testBasic:141 ? ClientError HTTP 403 Forbidden > JaxrsFilterTest.testBasic:141 ? ClientError HTTP 403 Forbidden > JaxrsFilterTest.testPushNotBefore:314 ? ClientError HTTP 403 Forbidden > JaxrsFilterTest.testResourceRoleMappings:236 ? ClientError HTTP 403 > Forbidden > > Tests run: 414, Failures: 2, Errors: 4, Skipped: 32 > > If somebody has an idea about what happens, please let me know! > > Kind regards, > Maur?cio. > > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160913/3f92cb41/attachment.html From bburke at redhat.com Tue Sep 13 09:24:30 2016 From: bburke at redhat.com (Bill Burke) Date: Tue, 13 Sep 2016 09:24:30 -0400 Subject: [keycloak-dev] User Event SPI In-Reply-To: References: <57D7F0B5.3040800@redhat.com> Message-ID: <31a7f943-ee29-a920-77eb-2e0635196161@redhat.com> On 9/13/16 9:03 AM, Stian Thorgersen wrote: > > > On 13 September 2016 at 14:27, Stan Silvert > wrote: > > On 9/13/2016 7:22 AM, Stian Thorgersen wrote: >> We currently have the low-level Event Listener SPI, but IMO it's >> not very user friendly. >> >> I propose we add two higher level SPIs with a more user friendly >> API. The SPIs would be: > +1. Another built-in email would be for profile updated. That > one is pretty common. > > > I got an email from eBay after changing my address, it said > congratulations on your move to a new country. We should have > something similar for people that change their last name, not sure > which one is most likely to be accurate "congratulations with your > wedding" or "congratulations with your divorce". LOL! -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160913/12a51eec/attachment.html From sthorger at redhat.com Tue Sep 13 09:29:21 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Tue, 13 Sep 2016 15:29:21 +0200 Subject: [keycloak-dev] Realm key rotation support Message-ID: To be able to gracefully rotate the realm keys periodically a realm needs to have more than one keypair. One keypair that is active and will be used to issue new cookies and tokens. Also, one or more keypairs that are inactive that can be used to verify old cookies and tokens. I'm going to start work on this soon, but here's some initial thoughts: * Realm keys will have a list of keypairs rather than just one. Only one can be active. There will also be an expiration time on the inactive keypairs. Once expired and inactive keypair is no longer usable. * There will also be an option to automatically generate a new key every N days. * If a session cookie is signed with an inactive pair the cookie will be refreshed so it's signed with the active keypair * Token introspect endpoint will allow any token that is signed with any keypair that is not expired * If a refresh token is signed with an inactive pair the new tokens (including refresh token) will be signed with the active keypair * Secret used to generate client code will be linked to the keypair. I'll need a way to specify what secret it was signed with so codes are still valid even if they where signed with an old. This is only for login cookie and OIDC protocol. Is it even necessary to have support for multiple certificates for SAML? SAML doesn't have a token introspection or refresh of the assertions right, so not sure it's needed. With regards to the applications. Marek has already added support for clients to fetch new keypairs for the realm. See his email on keycloak-dev for details around that. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160913/d52bb14c/attachment.html From pnalyvayko at agi.com Tue Sep 13 09:41:03 2016 From: pnalyvayko at agi.com (Nalyvayko, Peter) Date: Tue, 13 Sep 2016 13:41:03 +0000 Subject: [keycloak-dev] Realm key rotation support In-Reply-To: References: Message-ID: Is this going to be a breaking feature or is the plan to continue supporting the current single key/realm model? From: keycloak-dev-bounces at lists.jboss.org [mailto:keycloak-dev-bounces at lists.jboss.org] On Behalf Of Stian Thorgersen Sent: Tuesday, September 13, 2016 9:29 AM To: keycloak-dev Subject: [keycloak-dev] Realm key rotation support To be able to gracefully rotate the realm keys periodically a realm needs to have more than one keypair. One keypair that is active and will be used to issue new cookies and tokens. Also, one or more keypairs that are inactive that can be used to verify old cookies and tokens. I'm going to start work on this soon, but here's some initial thoughts: * Realm keys will have a list of keypairs rather than just one. Only one can be active. There will also be an expiration time on the inactive keypairs. Once expired and inactive keypair is no longer usable. * There will also be an option to automatically generate a new key every N days. * If a session cookie is signed with an inactive pair the cookie will be refreshed so it's signed with the active keypair * Token introspect endpoint will allow any token that is signed with any keypair that is not expired * If a refresh token is signed with an inactive pair the new tokens (including refresh token) will be signed with the active keypair * Secret used to generate client code will be linked to the keypair. I'll need a way to specify what secret it was signed with so codes are still valid even if they where signed with an old. This is only for login cookie and OIDC protocol. Is it even necessary to have support for multiple certificates for SAML? SAML doesn't have a token introspection or refresh of the assertions right, so not sure it's needed. With regards to the applications. Marek has already added support for clients to fetch new keypairs for the realm. See his email on keycloak-dev for details around that. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160913/5bf21f2d/attachment-0001.html From mauriciogiacomini at hotmail.com Tue Sep 13 10:20:01 2016 From: mauriciogiacomini at hotmail.com (=?iso-8859-1?Q?Maur=EDcio_Giacomini_Penteado?=) Date: Tue, 13 Sep 2016 14:20:01 +0000 Subject: [keycloak-dev] Keycloak Integration TestSuite FAILURE In-Reply-To: References: , Message-ID: Hello Stian I did a clone of master from Travis repository and to me the errors are the same = / ________________________________ De: Stian Thorgersen Enviado: ter?a-feira, 13 de setembro de 2016 13:10 Para: Maur?cio Giacomini Penteado Cc: keycloak-dev at lists.jboss.org Assunto: Re: [keycloak-dev] Keycloak Integration TestSuite FAILURE What steps do you run to build/test? Works on my box and also it works on Travis. On 13 September 2016 at 15:08, Maur?cio Giacomini Penteado > wrote: Hello everybody. All my attempts to build keycloak result in the same errors: Keycloak Integration TestSuite FAILURE Failed tests: JaxrsFilterTest.testCors:286 expected:<200> but was:<403> JaxrsFilterTest.testRelativeUriAndPublicKey:172 expected:<500> but was:<401> Tests in error: JaxrsBasicAuthTest.testBasic:141 ? ClientError HTTP 403 Forbidden JaxrsFilterTest.testBasic:141 ? ClientError HTTP 403 Forbidden JaxrsFilterTest.testPushNotBefore:314 ? ClientError HTTP 403 Forbidden JaxrsFilterTest.testResourceRoleMappings:236 ? ClientError HTTP 403 Forbidden Tests run: 414, Failures: 2, Errors: 4, Skipped: 32 If somebody has an idea about what happens, please let me know! Kind regards, Maur?cio. _______________________________________________ keycloak-dev mailing list keycloak-dev at lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160913/bb630583/attachment.html From bruno at abstractj.org Tue Sep 13 10:23:41 2016 From: bruno at abstractj.org (Bruno Oliveira) Date: Tue, 13 Sep 2016 11:23:41 -0300 Subject: [keycloak-dev] Integration tests for FreeIPA In-Reply-To: References: <20160912210202.GA24692@abstractj.org> Message-ID: <20160913142341.GA14904@abstractj.org> I fully agree with you and Stian. I just asked because I thought would be mandatory to have it running on Travis. I will take a look about what we can do with Docker to make it easy. Thank you! On 2016-09-13, Marek Posolda wrote: > Hi Bruno, > > the question is if we really need FreeIPA on Travis CI? The thing is that > Travis is currently just the CI for run "mvn clean install" when you send PR > to find regressions early. However we have already lots of tests, which are > not executed during default travis build. For example: > - Adapter tests in new testsuite. > - Tests with Keycloak on real Wildfly server (by default testsuite uses just > embedded undertow) > - Test with other DBs than embedded H2 > - Test with other LDAPs than embedded ApacheDS > > IMO It's fine if FreeIPA tests are executed just when you run the build with > some special maven profile. Hence we will have job on central CI, which will > test FreeIPA on daily basis. However those tests won't be executed during > default "mvn clean install" build and hence also not executed on travis > during every build. So defacto approach 1 from what you mentioned. > > But maybe it's just me :) > > Marek > > On 12/09/16 23:02, Bruno Oliveira wrote: > > Ahoy, this week I will start to look at the integration tests for > > FreeIPA/SSSD with Ilya from QE. He already started some work here[1]. > > The tricky part for me is to spin up a FreeIPA server on Travis CI. > > > > For those not familiar with this environment, to run the > > integration tests, freeipa-server must be installed/configured. > > Unfortunately, Ubuntu Precise (the distro running on Travis) > > have only freeipa-client and python-freeipa[2]. > > > > Some ideas to make this happen: > > > > 1. Do nothing and let people run the integration tests locally. This is not awesome. > > 2. Spin up a FreeIPA docker instance on Travis before the build, plus > > install and configure a freeipa-client. The downside is: more steps, > > more slowness on Travis. > > 3. Move the CI to our own server and have FreeIPA installed and > > configured. > > > > Ideas? > > > > [1] - https://github.com/abstractj/keycloak/commit/534569a9b6082a9674a33149519b06d1218d4807 > > [2] - https://launchpad.net/ubuntu/precise/+source/freeipa > > > > -- > > > > abstractj > > PGP: 0x84DC9914 > > _______________________________________________ > > keycloak-dev mailing list > > keycloak-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > -- abstractj PGP: 0x84DC9914 From bruno at abstractj.org Tue Sep 13 10:33:50 2016 From: bruno at abstractj.org (Bruno Oliveira da Silva) Date: Tue, 13 Sep 2016 11:33:50 -0300 Subject: [keycloak-dev] LDAP setup for demonstration purposes In-Reply-To: <22e0bfbe-2824-07e1-83a1-92f643b4587c@redhat.com> References: <22e0bfbe-2824-07e1-83a1-92f643b4587c@redhat.com> Message-ID: <20160913143350.GC14904@abstractj.org> +1 IMO if we stick with Docker, we can just benefit of what you already did. And like you mentioned, make use of the FreeIPA client docker image. On 2016-09-13, Marek Posolda wrote: > +1 > > Few more things and tips (you may be already aware of them, but still.. > Hope some of them are useful :) : > > - My docker image [1] already contains FreeIPA server and Keycloak > server pre-configured with LDAP+Kerberos federation provider to use it. > Thing is that both Keycloak+FreeIPA are on same machine, which is likely > not the best for show production setup. The workstation setup needs to > be done on your local machine (so you need KErberos client + Firefox > setup on your laptop. That's sufficient for testing, but probably also > not ideal for showcase). > > - In addition to FreeIPA docker images for server, FreeIPA has also > docker image for client setup. See for example [2] . I am not 100% sure, > but I believe that if you run this docker image and point to the already > running "server" image, you will gain also all the things like PAM > setup, login to the workstation with Kerberos credentials, and > automatically retrieved kerberos ticket during login. Hence you just > login to workstation, open firefox and you are authenticated to > Keycloak. No need to manually run "kinit". > > - If Keycloak and FreeIPA server are on different workstations, then: > -- The Keycloak server may also need FreeIPA client installed. Or at > least kerberos client installed with proper setup in /etc/krb5.conf > pointing to FreeIPA kerberos realm and proper DNS setup working with > FreeIPA. > > -- Also for different servers, you will likely need to add HTTP kerberos > principal for the server where keycloak is running. For example if > FreeIPA is on "freeipa.example.org" and keycloak is on > "keycloak.example.org", you will need the principal like > HTTP/keycloak.example.org at KEYCLOAK.ORG . This corresponds to LDAP > principal under "cn=services,cn=accounts,dc=freeipa,dc=example,dc=org" . > Maybe FreeIPA has it documented somewhere and/or it's easily possible to > add new HTTP server principal through FreeIPA admin console. You will > also need keytab exported with the credentials of this principal. > Note this step is not needed if Keycloak and FreeIPA are on same machine > as FreeIPA server automatically has HTTP principal for it's own machine > (something like HTTP/freeipa.example.org at KEYCLOAK.ORG for the example > above), to allow login to FreeIPA admin console with kerberos OOTB. > > > [1] https://github.com/mposolda/keycloak-freeipa-docker/ > [2] https://github.com/adelton/docker-freeipa/tree/fedora-22-client > > Marek > > On 13/09/16 08:07, Stian Thorgersen wrote: > > I'd like to have a simple way to demo LDAP and Kerberos support. To > > that end we should add a Vagrant setup with the following: > > > > * Keycloak server > > * MySQL or Postgres > > * FreeIPA > > * Workstation with Kerberos authentication (needs X and Firefox installed) > > > > The Keycloak server should already be configured to use the FreeIPA > > server as a user federation provider (using LDAP and Kerberos). The > > workstation can be co-located with FreeIPA server if it makes things > > much simpler, but it should be possible to login to the workstation > > with Kerberos. Firefox should be pre-configured for Kerberos to work > > both on Keycloak login and FreeIPA admin console. > > > > I want a proper database and a web based client for the database so > > it's simple to inspect the database. > > > > Bruno has already volunteered to look into this, but first we should > > make sure this is the setup we'd like to be able to showcase. > > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev -- abstractj PGP: 0x84DC9914 From nielsbne at gmail.com Tue Sep 13 10:36:41 2016 From: nielsbne at gmail.com (Niels Bertram) Date: Wed, 14 Sep 2016 00:36:41 +1000 Subject: [keycloak-dev] Realm key rotation support In-Reply-To: References: Message-ID: Hi Stian, intersting email, we were recently given advise to rotate keys periodically but at this point in time keycloak 1.9.8 does not actually implement http://openid.net/specs/openid-connect-core-1_0.html#RotateSigKeys nor are any of the client adapters able to use the jks url to retrieve pub keys rather requiring to hard code the target realm key in the public-realm-key property of the keycloak.json client configuration file. Is this new feature going to implement the OpenID Connect spec sections 10.1 and 10.2 ? Also I assume this would also require changes to adapters by removing the public-realm-key property from the config file? Kind Regards, Niels On Tue, Sep 13, 2016 at 11:41 PM, Nalyvayko, Peter wrote: > Is this going to be a breaking feature or is the plan to continue > supporting the current single key/realm model? > > > > *From:* keycloak-dev-bounces at lists.jboss.org [mailto:keycloak-dev-bounces@ > lists.jboss.org] *On Behalf Of *Stian Thorgersen > *Sent:* Tuesday, September 13, 2016 9:29 AM > *To:* keycloak-dev > *Subject:* [keycloak-dev] Realm key rotation support > > > > To be able to gracefully rotate the realm keys periodically a realm needs > to have more than one keypair. One keypair that is active and will be used > to issue new cookies and tokens. Also, one or more keypairs that are > inactive that can be used to verify old cookies and tokens. > > > > I'm going to start work on this soon, but here's some initial thoughts: > > > > * Realm keys will have a list of keypairs rather than just one. Only one > can be active. There will also be an expiration time on the inactive > keypairs. Once expired and inactive keypair is no longer usable. > > * There will also be an option to automatically generate a new key every N > days. > > * If a session cookie is signed with an inactive pair the cookie will be > refreshed so it's signed with the active keypair > > * Token introspect endpoint will allow any token that is signed with any > keypair that is not expired > > * If a refresh token is signed with an inactive pair the new tokens > (including refresh token) will be signed with the active keypair > > * Secret used to generate client code will be linked to the keypair. I'll > need a way to specify what secret it was signed with so codes are still > valid even if they where signed with an old. > > > > This is only for login cookie and OIDC protocol. Is it even necessary to > have support for multiple certificates for SAML? SAML doesn't have a token > introspection or refresh of the assertions right, so not sure it's needed. > > > > With regards to the applications. Marek has already added support for > clients to fetch new keypairs for the realm. See his email on keycloak-dev > for details around that. > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160914/cb226a61/attachment-0001.html From bruno at abstractj.org Tue Sep 13 10:39:25 2016 From: bruno at abstractj.org (Bruno Oliveira da Silva) Date: Tue, 13 Sep 2016 11:39:25 -0300 Subject: [keycloak-dev] LDAP setup for demonstration purposes In-Reply-To: References: <22e0bfbe-2824-07e1-83a1-92f643b4587c@redhat.com> Message-ID: <20160913143925.GE14904@abstractj.org> My question is: Docker or Vagrant? If we have plans to showcase SSSD Federation provider + things like start/stop sssd service to demonstrate the SSSD provider won't be enabled. I would say that Vagrant is easier and we can benefit from these boxes[1], otherwise we just stick with Marek's work. I will give DBus on Docker a second try, but last time I checked wasn't fun. [1] - https://github.com/freeipa/freeipa-workshop On 2016-09-13, Stian Thorgersen wrote: > Forgot to add two things: > > * DNS setup - we want proper DNS setup on the machines, which would be > required for the Kerberos stuff to work properly > * HTTPS - optional, but would be great if it also had HTTPS configured > > On 13 September 2016 at 09:24, Marek Posolda wrote: > > > +1 > > > > Few more things and tips (you may be already aware of them, but still.. > > Hope some of them are useful :) : > > > > - My docker image [1] already contains FreeIPA server and Keycloak server > > pre-configured with LDAP+Kerberos federation provider to use it. Thing is > > that both Keycloak+FreeIPA are on same machine, which is likely not the > > best for show production setup. The workstation setup needs to be done on > > your local machine (so you need KErberos client + Firefox setup on your > > laptop. That's sufficient for testing, but probably also not ideal for > > showcase). > > > > - In addition to FreeIPA docker images for server, FreeIPA has also docker > > image for client setup. See for example [2] . I am not 100% sure, but I > > believe that if you run this docker image and point to the already running > > "server" image, you will gain also all the things like PAM setup, login to > > the workstation with Kerberos credentials, and automatically retrieved > > kerberos ticket during login. Hence you just login to workstation, open > > firefox and you are authenticated to Keycloak. No need to manually run > > "kinit". > > > > The workstation will need to be a virtual machine rather than container to > add X support. So IMO we should just use Vagrant and have FreeIPA and > use Vagrantfile to install Fedora + FreeIPA. > > > > > > - If Keycloak and FreeIPA server are on different workstations, then: > > -- The Keycloak server may also need FreeIPA client installed. Or at least > > kerberos client installed with proper setup in /etc/krb5.conf pointing to > > FreeIPA kerberos realm and proper DNS setup working with FreeIPA. > > > > -- Also for different servers, you will likely need to add HTTP kerberos > > principal for the server where keycloak is running. For example if FreeIPA > > is on "freeipa.example.org" and keycloak is on "keycloak.example.org", > > you will need the principal like HTTP/keycloak.example.org at KEYCLOAK.ORG . > > This corresponds to LDAP principal under "cn=services,cn=accounts,dc=freeipa,dc=example,dc=org" > > . Maybe FreeIPA has it documented somewhere and/or it's easily possible to > > add new HTTP server principal through FreeIPA admin console. You will also > > need keytab exported with the credentials of this principal. > > Note this step is not needed if Keycloak and FreeIPA are on same machine > > as FreeIPA server automatically has HTTP principal for it's own machine > > (something like HTTP/freeipa.example.org at KEYCLOAK.ORG for the example > > above), to allow login to FreeIPA admin console with kerberos OOTB. > > > > We should really figure out how to do this on separate machines, so I think > going that way would be best even though it's harder to do. > > > > > > > > [1] https://github.com/mposolda/keycloak-freeipa-docker/ > > [2] https://github.com/adelton/docker-freeipa/tree/fedora-22-client > > > > Marek > > > > > > On 13/09/16 08:07, Stian Thorgersen wrote: > > > >> I'd like to have a simple way to demo LDAP and Kerberos support. To that > >> end we should add a Vagrant setup with the following: > >> > >> * Keycloak server > >> * MySQL or Postgres > >> * FreeIPA > >> * Workstation with Kerberos authentication (needs X and Firefox installed) > >> > >> The Keycloak server should already be configured to use the FreeIPA > >> server as a user federation provider (using LDAP and Kerberos). The > >> workstation can be co-located with FreeIPA server if it makes things much > >> simpler, but it should be possible to login to the workstation with > >> Kerberos. Firefox should be pre-configured for Kerberos to work both on > >> Keycloak login and FreeIPA admin console. > >> > >> I want a proper database and a web based client for the database so it's > >> simple to inspect the database. > >> > >> Bruno has already volunteered to look into this, but first we should make > >> sure this is the setup we'd like to be able to showcase. > >> > > > > > > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev -- abstractj PGP: 0x84DC9914 From srossillo at smartling.com Tue Sep 13 10:46:07 2016 From: srossillo at smartling.com (Scott Rossillo) Date: Tue, 13 Sep 2016 10:46:07 -0400 Subject: [keycloak-dev] LDAP setup for demonstration purposes In-Reply-To: <20160913143925.GE14904@abstractj.org> References: <22e0bfbe-2824-07e1-83a1-92f643b4587c@redhat.com> <20160913143925.GE14904@abstractj.org> Message-ID: <8A76F607-BCD2-4DD8-94B5-9EE4BAD36665@smartling.com> Vagrant leaves funny taste in my mouth. Docker Compose to orchestrate things seems like a better option. Scott Rossillo Smartling | Senior Software Engineer srossillo at smartling.com > On Sep 13, 2016, at 10:39 AM, Bruno Oliveira da Silva wrote: > > My question is: Docker or Vagrant? > > If we have plans to showcase SSSD Federation provider + things like > start/stop sssd service to demonstrate the SSSD provider won't be > enabled. I would say that Vagrant is easier and we can benefit from > these boxes[1], otherwise we just stick with Marek's work. > > I will give DBus on Docker a second try, but last time I checked wasn't > fun. > > [1] - https://github.com/freeipa/freeipa-workshop > > On 2016-09-13, Stian Thorgersen wrote: >> Forgot to add two things: >> >> * DNS setup - we want proper DNS setup on the machines, which would be >> required for the Kerberos stuff to work properly >> * HTTPS - optional, but would be great if it also had HTTPS configured >> >> On 13 September 2016 at 09:24, Marek Posolda wrote: >> >>> +1 >>> >>> Few more things and tips (you may be already aware of them, but still.. >>> Hope some of them are useful :) : >>> >>> - My docker image [1] already contains FreeIPA server and Keycloak server >>> pre-configured with LDAP+Kerberos federation provider to use it. Thing is >>> that both Keycloak+FreeIPA are on same machine, which is likely not the >>> best for show production setup. The workstation setup needs to be done on >>> your local machine (so you need KErberos client + Firefox setup on your >>> laptop. That's sufficient for testing, but probably also not ideal for >>> showcase). >>> >>> - In addition to FreeIPA docker images for server, FreeIPA has also docker >>> image for client setup. See for example [2] . I am not 100% sure, but I >>> believe that if you run this docker image and point to the already running >>> "server" image, you will gain also all the things like PAM setup, login to >>> the workstation with Kerberos credentials, and automatically retrieved >>> kerberos ticket during login. Hence you just login to workstation, open >>> firefox and you are authenticated to Keycloak. No need to manually run >>> "kinit". >>> >> >> The workstation will need to be a virtual machine rather than container to >> add X support. So IMO we should just use Vagrant and have FreeIPA and >> use Vagrantfile to install Fedora + FreeIPA. >> >> >>> >>> - If Keycloak and FreeIPA server are on different workstations, then: >>> -- The Keycloak server may also need FreeIPA client installed. Or at least >>> kerberos client installed with proper setup in /etc/krb5.conf pointing to >>> FreeIPA kerberos realm and proper DNS setup working with FreeIPA. >> >> >>> -- Also for different servers, you will likely need to add HTTP kerberos >>> principal for the server where keycloak is running. For example if FreeIPA >>> is on "freeipa.example.org" and keycloak is on "keycloak.example.org", >>> you will need the principal like HTTP/keycloak.example.org at KEYCLOAK.ORG . >>> This corresponds to LDAP principal under "cn=services,cn=accounts,dc=freeipa,dc=example,dc=org" >>> . Maybe FreeIPA has it documented somewhere and/or it's easily possible to >>> add new HTTP server principal through FreeIPA admin console. You will also >>> need keytab exported with the credentials of this principal. >>> Note this step is not needed if Keycloak and FreeIPA are on same machine >>> as FreeIPA server automatically has HTTP principal for it's own machine >>> (something like HTTP/freeipa.example.org at KEYCLOAK.ORG for the example >>> above), to allow login to FreeIPA admin console with kerberos OOTB. >>> >> >> We should really figure out how to do this on separate machines, so I think >> going that way would be best even though it's harder to do. >> >> >>> >>> >>> [1] https://github.com/mposolda/keycloak-freeipa-docker/ >>> [2] https://github.com/adelton/docker-freeipa/tree/fedora-22-client >>> >>> Marek >>> >>> >>> On 13/09/16 08:07, Stian Thorgersen wrote: >>> >>>> I'd like to have a simple way to demo LDAP and Kerberos support. To that >>>> end we should add a Vagrant setup with the following: >>>> >>>> * Keycloak server >>>> * MySQL or Postgres >>>> * FreeIPA >>>> * Workstation with Kerberos authentication (needs X and Firefox installed) >>>> >>>> The Keycloak server should already be configured to use the FreeIPA >>>> server as a user federation provider (using LDAP and Kerberos). The >>>> workstation can be co-located with FreeIPA server if it makes things much >>>> simpler, but it should be possible to login to the workstation with >>>> Kerberos. Firefox should be pre-configured for Kerberos to work both on >>>> Keycloak login and FreeIPA admin console. >>>> >>>> I want a proper database and a web based client for the database so it's >>>> simple to inspect the database. >>>> >>>> Bruno has already volunteered to look into this, but first we should make >>>> sure this is the setup we'd like to be able to showcase. >>>> >>> >>> >>> > >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > -- > > abstractj > PGP: 0x84DC9914 > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160913/73aeb3ff/attachment.html From thomas.raehalme at aitiofinland.com Tue Sep 13 10:58:54 2016 From: thomas.raehalme at aitiofinland.com (Thomas Raehalme) Date: Tue, 13 Sep 2016 17:58:54 +0300 Subject: [keycloak-dev] LDAP setup for demonstration purposes In-Reply-To: <8A76F607-BCD2-4DD8-94B5-9EE4BAD36665@smartling.com> References: <22e0bfbe-2824-07e1-83a1-92f643b4587c@redhat.com> <20160913143925.GE14904@abstractj.org> <8A76F607-BCD2-4DD8-94B5-9EE4BAD36665@smartling.com> Message-ID: How about setting up multiple VMs with Vagrant but handling all software components with Docker? Best of both worlds and also a simulation of the real world (which could perhaps be used as a reference). Best regards, Thomas On Sep 13, 2016 5:46 PM, "Scott Rossillo" wrote: > Vagrant leaves funny taste in my mouth. Docker Compose to orchestrate > things seems like a better option. > > Scott Rossillo > Smartling | Senior Software Engineer > srossillo at smartling.com > > On Sep 13, 2016, at 10:39 AM, Bruno Oliveira da Silva > wrote: > > My question is: Docker or Vagrant? > > If we have plans to showcase SSSD Federation provider + things like > start/stop sssd service to demonstrate the SSSD provider won't be > enabled. I would say that Vagrant is easier and we can benefit from > these boxes[1], otherwise we just stick with Marek's work. > > I will give DBus on Docker a second try, but last time I checked wasn't > fun. > > [1] - https://github.com/freeipa/freeipa-workshop > > On 2016-09-13, Stian Thorgersen wrote: > > Forgot to add two things: > > * DNS setup - we want proper DNS setup on the machines, which would be > required for the Kerberos stuff to work properly > * HTTPS - optional, but would be great if it also had HTTPS configured > > On 13 September 2016 at 09:24, Marek Posolda wrote: > > +1 > > Few more things and tips (you may be already aware of them, but still.. > Hope some of them are useful :) : > > - My docker image [1] already contains FreeIPA server and Keycloak server > pre-configured with LDAP+Kerberos federation provider to use it. Thing is > that both Keycloak+FreeIPA are on same machine, which is likely not the > best for show production setup. The workstation setup needs to be done on > your local machine (so you need KErberos client + Firefox setup on your > laptop. That's sufficient for testing, but probably also not ideal for > showcase). > > - In addition to FreeIPA docker images for server, FreeIPA has also docker > image for client setup. See for example [2] . I am not 100% sure, but I > believe that if you run this docker image and point to the already running > "server" image, you will gain also all the things like PAM setup, login to > the workstation with Kerberos credentials, and automatically retrieved > kerberos ticket during login. Hence you just login to workstation, open > firefox and you are authenticated to Keycloak. No need to manually run > "kinit". > > > The workstation will need to be a virtual machine rather than container to > add X support. So IMO we should just use Vagrant and have FreeIPA and > use Vagrantfile to install Fedora + FreeIPA. > > > > - If Keycloak and FreeIPA server are on different workstations, then: > -- The Keycloak server may also need FreeIPA client installed. Or at least > kerberos client installed with proper setup in /etc/krb5.conf pointing to > FreeIPA kerberos realm and proper DNS setup working with FreeIPA. > > > > -- Also for different servers, you will likely need to add HTTP kerberos > principal for the server where keycloak is running. For example if FreeIPA > is on "freeipa.example.org" and keycloak is on "keycloak.example.org", > you will need the principal like HTTP/keycloak.example.org at KEYCLOAK.ORG > . > This corresponds to LDAP principal under "cn=services,cn=accounts,dc= > freeipa,dc=example,dc=org" > . Maybe FreeIPA has it documented somewhere and/or it's easily possible to > add new HTTP server principal through FreeIPA admin console. You will also > need keytab exported with the credentials of this principal. > Note this step is not needed if Keycloak and FreeIPA are on same machine > as FreeIPA server automatically has HTTP principal for it's own machine > (something like HTTP/freeipa.example.org at KEYCLOAK.ORG > for the example > above), to allow login to FreeIPA admin console with kerberos OOTB. > > > We should really figure out how to do this on separate machines, so I think > going that way would be best even though it's harder to do. > > > > > [1] https://github.com/mposolda/keycloak-freeipa-docker/ > [2] https://github.com/adelton/docker-freeipa/tree/fedora-22-client > > Marek > > > On 13/09/16 08:07, Stian Thorgersen wrote: > > I'd like to have a simple way to demo LDAP and Kerberos support. To that > end we should add a Vagrant setup with the following: > > * Keycloak server > * MySQL or Postgres > * FreeIPA > * Workstation with Kerberos authentication (needs X and Firefox installed) > > The Keycloak server should already be configured to use the FreeIPA > server as a user federation provider (using LDAP and Kerberos). The > workstation can be co-located with FreeIPA server if it makes things much > simpler, but it should be possible to login to the workstation with > Kerberos. Firefox should be pre-configured for Kerberos to work both on > Keycloak login and FreeIPA admin console. > > I want a proper database and a web based client for the database so it's > simple to inspect the database. > > Bruno has already volunteered to look into this, but first we should make > sure this is the setup we'd like to be able to showcase. > > > > > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > > -- > > abstractj > PGP: 0x84DC9914 > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160913/4a3cf521/attachment-0001.html From singhrasster at gmail.com Tue Sep 13 11:10:42 2016 From: singhrasster at gmail.com (Rashmi Singh) Date: Tue, 13 Sep 2016 10:10:42 -0500 Subject: [keycloak-dev] Implementing new protocol mapper to request NameID In-Reply-To: <64fe242b-3fbf-05df-d60c-6fb3678bf07d@redhat.com> References: <64fe242b-3fbf-05df-d60c-6fb3678bf07d@redhat.com> Message-ID: Bill, this suggestion is related to my previous post where I was inquiring if there is a way to edit NameID in Saml response: http://lists.jboss.org/pipermail/keycloak-dev/2016-September/008027.html We have a need to implement this protocol now. Assuming that you are considering adding this feature sometime in future, would you be able to guide us on how we can implement this now at our end? And if we can implement this now, will we be able to merge it to the master branch? Any guidance you can provide on how we can implement this ourselves at this time would be very useful. Thank you! On Mon, Sep 12, 2016 at 7:25 AM, Bill Burke wrote: > Good feedback. We'll eventually open up the protocol mapper spi so that > the entire assertion can be modified. > > On 9/11/16 7:43 PM, Rashmi Singh wrote: > > Looking at the keycloak source code to see how NameID value is set in the > SAML response, we came across SamlProtocol class that has the following > method: > > protected String getNameId(String nameIdFormat, ClientSessionModel > clientSession, UserSessionModel userSession) { > if (nameIdFormat.equals(JBossSAMLURIConstants.NAMEID_FORMAT_EMAIL.get())) > { > return userSession.getUser().getEmail(); > } else if (nameIdFormat.equals(JBossSAML > URIConstants.NAMEID_FORMAT_TRANSIENT.get())) { > // "G-" stands for "generated" Add this for the slight > possibility of collisions. > return "G-" + UUID.randomUUID().toString(); > } else if (nameIdFormat.equals(JBossSAML > URIConstants.NAMEID_FORMAT_PERSISTENT.get())) { > return getPersistentNameId(clientSession, userSession); > } else if (nameIdFormat.equals(JBossSAML > URIConstants.NAMEID_FORMAT_UNSPECIFIED.get())) { > // TODO: Support for persistent NameID (pseudo-random > identifier persisted in user object) > return userSession.getUser().getUsername(); > } else { > return userSession.getUser().getUsername(); > } > } > > which is just returning either email or username because of which we are > restricted in the value that can be set for the NameID. We are not able to > set NameID to any value other than this. With our customers, we have seen > lot of cases where users have different IDs across SPs. With the current > implementation in KeyCloak, it seems we can only return Name or Email as > NameID. Ideally in case of ?Unspecified? format, we should have a mechanism > to map Name ID to any of user property/attribute. Do you have any plans to > add support for this use case? > > With regard to solving this problem, one option could be to implement a > protocol mapper that can be used to map any user property/attribute to > NameID. Currently protocol mapper can only be used to return > saml:Attribute, so writing a new protocol mapper specifically for > requesting NameID would be useful. Is this feasible? And, do you have any > plans to add support for this usecase? > > If you are not planning to implement this, are there any design or > implementation level inputs/help you can provide on this? And if we > implement this protocol mapper from our side, would it be possible to merge > it back to the master branch? > > > > _______________________________________________ > keycloak-dev mailing listkeycloak-dev at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-dev > > > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160913/61cf299b/attachment.html From shmuein+keycloak-dev at gmail.com Tue Sep 13 11:29:51 2016 From: shmuein+keycloak-dev at gmail.com (Muein Muzamil) Date: Tue, 13 Sep 2016 10:29:51 -0500 Subject: [keycloak-dev] Accessing SAML Request attributes in Authenticaors In-Reply-To: References: Message-ID: Hi all, Any pointers to this? I was looking at the SAMLAuthNRequestParser class and it seems we are parsing the subject from the incoming request. Now the question is how can I access it in my custom authenticator? else if (JBossSAMLConstants.SUBJECT.get().equals(elementName)) { authnRequest.setSubject(getSubject(xmlEventReader)); } Regards, Muein On Fri, Sep 9, 2016 at 3:20 PM, Muein Muzamil < shmuein+keycloak-dev at gmail.com> wrote: > Hi all, > > We are trying to integrate with an SP which sends Subject/NameID in the > Saml Request (copying example below). I have couple of questions in this > regard > > > 1. In our custom authenticator, we want to access this NameId and want > to pre-fill username field based on this. Can you please guide me how can I > do that. > 2. Secondly, I am currently using KeyCloak JBoss Adapter for my sample > SP, does the SAML Adapter supports sending nameId in SAML request? > > IssueInstant="2016-02-24T15:45:55.325Z" > ID="ID112bf5b0e4169930b663f2d89e62c521fc2f1b8133598fa2ff" > xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"> > > http://pi > ngone.com/xxx/640d3755-e080-4a87-8f7f-91795e78c08d > > jdoe at mysecureauthentication.com > > > > > Regards, > Muein > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160913/c40bbafe/attachment.html From mauriciogiacomini at hotmail.com Tue Sep 13 14:12:30 2016 From: mauriciogiacomini at hotmail.com (=?iso-8859-1?Q?Maur=EDcio_Giacomini_Penteado?=) Date: Tue, 13 Sep 2016 18:12:30 +0000 Subject: [keycloak-dev] Keycloak Integration TestSuite FAILURE In-Reply-To: References: , , Message-ID: I am trying build with a CentOS Linux release 7.2. I have already tried build the keycloak versions 2.0.0, 2.1.0 and 2.2.0 with OpenJDK and Oracle JDK. I just did a clone and performed a "mvn install". All my attempts result in the same errors: Keycloak Integration TestSuite FAILURE Failed tests: JaxrsFilterTest.testCors:286 expected:<200> but was:<403> JaxrsFilterTest.testRelativeUriAndPublicKey:172 expected:<500> but was:<401> Tests in error: JaxrsBasicAuthTest.testBasic:141 ? ClientError HTTP 403 Forbidden JaxrsFilterTest.testBasic:141 ? ClientError HTTP 403 Forbidden JaxrsFilterTest.testPushNotBefore:314 ? ClientError HTTP 403 Forbidden JaxrsFilterTest.testResourceRoleMappings:236 ? ClientError HTTP 403 Forbidden Tests run: 414, Failures: 2, Errors: 4, Skipped: 32 = [ Somebody, please! ________________________________ De: Maur?cio Giacomini Penteado Enviado: ter?a-feira, 13 de setembro de 2016 14:20 Para: stian at redhat.com Cc: keycloak-dev at lists.jboss.org Assunto: Re: [keycloak-dev] Keycloak Integration TestSuite FAILURE Hello Stian I did a clone of master from Travis repository and to me the errors are the same = / ________________________________ De: Stian Thorgersen Enviado: ter?a-feira, 13 de setembro de 2016 13:10 Para: Maur?cio Giacomini Penteado Cc: keycloak-dev at lists.jboss.org Assunto: Re: [keycloak-dev] Keycloak Integration TestSuite FAILURE What steps do you run to build/test? Works on my box and also it works on Travis. On 13 September 2016 at 15:08, Maur?cio Giacomini Penteado > wrote: Hello everybody. All my attempts to build keycloak result in the same errors: Keycloak Integration TestSuite FAILURE Failed tests: JaxrsFilterTest.testCors:286 expected:<200> but was:<403> JaxrsFilterTest.testRelativeUriAndPublicKey:172 expected:<500> but was:<401> Tests in error: JaxrsBasicAuthTest.testBasic:141 ? ClientError HTTP 403 Forbidden JaxrsFilterTest.testBasic:141 ? ClientError HTTP 403 Forbidden JaxrsFilterTest.testPushNotBefore:314 ? ClientError HTTP 403 Forbidden JaxrsFilterTest.testResourceRoleMappings:236 ? ClientError HTTP 403 Forbidden Tests run: 414, Failures: 2, Errors: 4, Skipped: 32 If somebody has an idea about what happens, please let me know! Kind regards, Maur?cio. _______________________________________________ keycloak-dev mailing list keycloak-dev at lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160913/eda684a3/attachment-0001.html From bruno at abstractj.org Tue Sep 13 15:10:28 2016 From: bruno at abstractj.org (Bruno Oliveira da Silva) Date: Tue, 13 Sep 2016 16:10:28 -0300 Subject: [keycloak-dev] LDAP setup for demonstration purposes In-Reply-To: References: <22e0bfbe-2824-07e1-83a1-92f643b4587c@redhat.com> <20160913143925.GE14904@abstractj.org> <8A76F607-BCD2-4DD8-94B5-9EE4BAD36665@smartling.com> Message-ID: <20160913191028.GA6881@abstractj.org> My 2 cents on it. Unless we have any strong argument for doing this, let's move forward with Docker. We already have a repository for this and I'm not sure if we have bandwidth to maintain 2 distinct repositories. Btw I'm curious, which real world scenario you could not reproduce with Docker? On 2016-09-13, Thomas Raehalme wrote: > How about setting up multiple VMs with Vagrant but handling all software > components with Docker? > > Best of both worlds and also a simulation of the real world (which could > perhaps be used as a reference). > > Best regards, > Thomas > > On Sep 13, 2016 5:46 PM, "Scott Rossillo" wrote: > > > Vagrant leaves funny taste in my mouth. Docker Compose to orchestrate > > things seems like a better option. > > > > Scott Rossillo > > Smartling | Senior Software Engineer > > srossillo at smartling.com > > > > On Sep 13, 2016, at 10:39 AM, Bruno Oliveira da Silva > > wrote: > > > > My question is: Docker or Vagrant? > > > > If we have plans to showcase SSSD Federation provider + things like > > start/stop sssd service to demonstrate the SSSD provider won't be > > enabled. I would say that Vagrant is easier and we can benefit from > > these boxes[1], otherwise we just stick with Marek's work. > > > > I will give DBus on Docker a second try, but last time I checked wasn't > > fun. > > > > [1] - https://github.com/freeipa/freeipa-workshop > > > > On 2016-09-13, Stian Thorgersen wrote: > > > > Forgot to add two things: > > > > * DNS setup - we want proper DNS setup on the machines, which would be > > required for the Kerberos stuff to work properly > > * HTTPS - optional, but would be great if it also had HTTPS configured > > > > On 13 September 2016 at 09:24, Marek Posolda wrote: > > > > +1 > > > > Few more things and tips (you may be already aware of them, but still.. > > Hope some of them are useful :) : > > > > - My docker image [1] already contains FreeIPA server and Keycloak server > > pre-configured with LDAP+Kerberos federation provider to use it. Thing is > > that both Keycloak+FreeIPA are on same machine, which is likely not the > > best for show production setup. The workstation setup needs to be done on > > your local machine (so you need KErberos client + Firefox setup on your > > laptop. That's sufficient for testing, but probably also not ideal for > > showcase). > > > > - In addition to FreeIPA docker images for server, FreeIPA has also docker > > image for client setup. See for example [2] . I am not 100% sure, but I > > believe that if you run this docker image and point to the already running > > "server" image, you will gain also all the things like PAM setup, login to > > the workstation with Kerberos credentials, and automatically retrieved > > kerberos ticket during login. Hence you just login to workstation, open > > firefox and you are authenticated to Keycloak. No need to manually run > > "kinit". > > > > > > The workstation will need to be a virtual machine rather than container to > > add X support. So IMO we should just use Vagrant and have FreeIPA and > > use Vagrantfile to install Fedora + FreeIPA. > > > > > > > > - If Keycloak and FreeIPA server are on different workstations, then: > > -- The Keycloak server may also need FreeIPA client installed. Or at least > > kerberos client installed with proper setup in /etc/krb5.conf pointing to > > FreeIPA kerberos realm and proper DNS setup working with FreeIPA. > > > > > > > > -- Also for different servers, you will likely need to add HTTP kerberos > > principal for the server where keycloak is running. For example if FreeIPA > > is on "freeipa.example.org" and keycloak is on "keycloak.example.org", > > you will need the principal like HTTP/keycloak.example.org at KEYCLOAK.ORG > > . > > This corresponds to LDAP principal under "cn=services,cn=accounts,dc= > > freeipa,dc=example,dc=org" > > . Maybe FreeIPA has it documented somewhere and/or it's easily possible to > > add new HTTP server principal through FreeIPA admin console. You will also > > need keytab exported with the credentials of this principal. > > Note this step is not needed if Keycloak and FreeIPA are on same machine > > as FreeIPA server automatically has HTTP principal for it's own machine > > (something like HTTP/freeipa.example.org at KEYCLOAK.ORG > > for the example > > above), to allow login to FreeIPA admin console with kerberos OOTB. > > > > > > We should really figure out how to do this on separate machines, so I think > > going that way would be best even though it's harder to do. > > > > > > > > > > [1] https://github.com/mposolda/keycloak-freeipa-docker/ > > [2] https://github.com/adelton/docker-freeipa/tree/fedora-22-client > > > > Marek > > > > > > On 13/09/16 08:07, Stian Thorgersen wrote: > > > > I'd like to have a simple way to demo LDAP and Kerberos support. To that > > end we should add a Vagrant setup with the following: > > > > * Keycloak server > > * MySQL or Postgres > > * FreeIPA > > * Workstation with Kerberos authentication (needs X and Firefox installed) > > > > The Keycloak server should already be configured to use the FreeIPA > > server as a user federation provider (using LDAP and Kerberos). The > > workstation can be co-located with FreeIPA server if it makes things much > > simpler, but it should be possible to login to the workstation with > > Kerberos. Firefox should be pre-configured for Kerberos to work both on > > Keycloak login and FreeIPA admin console. > > > > I want a proper database and a web based client for the database so it's > > simple to inspect the database. > > > > Bruno has already volunteered to look into this, but first we should make > > sure this is the setup we'd like to be able to showcase. > > > > > > > > > > > > _______________________________________________ > > keycloak-dev mailing list > > keycloak-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > > > > > > -- > > > > abstractj > > PGP: 0x84DC9914 > > _______________________________________________ > > keycloak-dev mailing list > > keycloak-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > > > > > > _______________________________________________ > > keycloak-dev mailing list > > keycloak-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > -- abstractj PGP: 0x84DC9914 From bruno at abstractj.org Tue Sep 13 15:11:57 2016 From: bruno at abstractj.org (Bruno Oliveira da Silva) Date: Tue, 13 Sep 2016 16:11:57 -0300 Subject: [keycloak-dev] LDAP setup for demonstration purposes In-Reply-To: References: <22e0bfbe-2824-07e1-83a1-92f643b4587c@redhat.com> Message-ID: <20160913191157.GB6881@abstractj.org> FYI I just tested DBus and SSSD on Docker. This is no longer a blocker. On 2016-09-13, Stian Thorgersen wrote: > Forgot to add two things: > > * DNS setup - we want proper DNS setup on the machines, which would be > required for the Kerberos stuff to work properly > * HTTPS - optional, but would be great if it also had HTTPS configured > > On 13 September 2016 at 09:24, Marek Posolda wrote: > > > +1 > > > > Few more things and tips (you may be already aware of them, but still.. > > Hope some of them are useful :) : > > > > - My docker image [1] already contains FreeIPA server and Keycloak server > > pre-configured with LDAP+Kerberos federation provider to use it. Thing is > > that both Keycloak+FreeIPA are on same machine, which is likely not the > > best for show production setup. The workstation setup needs to be done on > > your local machine (so you need KErberos client + Firefox setup on your > > laptop. That's sufficient for testing, but probably also not ideal for > > showcase). > > > > - In addition to FreeIPA docker images for server, FreeIPA has also docker > > image for client setup. See for example [2] . I am not 100% sure, but I > > believe that if you run this docker image and point to the already running > > "server" image, you will gain also all the things like PAM setup, login to > > the workstation with Kerberos credentials, and automatically retrieved > > kerberos ticket during login. Hence you just login to workstation, open > > firefox and you are authenticated to Keycloak. No need to manually run > > "kinit". > > > > The workstation will need to be a virtual machine rather than container to > add X support. So IMO we should just use Vagrant and have FreeIPA and > use Vagrantfile to install Fedora + FreeIPA. > > > > > > - If Keycloak and FreeIPA server are on different workstations, then: > > -- The Keycloak server may also need FreeIPA client installed. Or at least > > kerberos client installed with proper setup in /etc/krb5.conf pointing to > > FreeIPA kerberos realm and proper DNS setup working with FreeIPA. > > > > -- Also for different servers, you will likely need to add HTTP kerberos > > principal for the server where keycloak is running. For example if FreeIPA > > is on "freeipa.example.org" and keycloak is on "keycloak.example.org", > > you will need the principal like HTTP/keycloak.example.org at KEYCLOAK.ORG . > > This corresponds to LDAP principal under "cn=services,cn=accounts,dc=freeipa,dc=example,dc=org" > > . Maybe FreeIPA has it documented somewhere and/or it's easily possible to > > add new HTTP server principal through FreeIPA admin console. You will also > > need keytab exported with the credentials of this principal. > > Note this step is not needed if Keycloak and FreeIPA are on same machine > > as FreeIPA server automatically has HTTP principal for it's own machine > > (something like HTTP/freeipa.example.org at KEYCLOAK.ORG for the example > > above), to allow login to FreeIPA admin console with kerberos OOTB. > > > > We should really figure out how to do this on separate machines, so I think > going that way would be best even though it's harder to do. > > > > > > > > [1] https://github.com/mposolda/keycloak-freeipa-docker/ > > [2] https://github.com/adelton/docker-freeipa/tree/fedora-22-client > > > > Marek > > > > > > On 13/09/16 08:07, Stian Thorgersen wrote: > > > >> I'd like to have a simple way to demo LDAP and Kerberos support. To that > >> end we should add a Vagrant setup with the following: > >> > >> * Keycloak server > >> * MySQL or Postgres > >> * FreeIPA > >> * Workstation with Kerberos authentication (needs X and Firefox installed) > >> > >> The Keycloak server should already be configured to use the FreeIPA > >> server as a user federation provider (using LDAP and Kerberos). The > >> workstation can be co-located with FreeIPA server if it makes things much > >> simpler, but it should be possible to login to the workstation with > >> Kerberos. Firefox should be pre-configured for Kerberos to work both on > >> Keycloak login and FreeIPA admin console. > >> > >> I want a proper database and a web based client for the database so it's > >> simple to inspect the database. > >> > >> Bruno has already volunteered to look into this, but first we should make > >> sure this is the setup we'd like to be able to showcase. > >> > > > > > > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev -- abstractj PGP: 0x84DC9914 From mposolda at redhat.com Tue Sep 13 15:39:45 2016 From: mposolda at redhat.com (Marek Posolda) Date: Tue, 13 Sep 2016 21:39:45 +0200 Subject: [keycloak-dev] Realm key rotation support In-Reply-To: References: Message-ID: <2df55985-055f-ec54-e62f-944f11471f85@redhat.com> On 13/09/16 16:36, Niels Bertram wrote: > Hi Stian, > > intersting email, we were recently given advise to rotate keys > periodically but at this point in time keycloak 1.9.8 does not > actually implement > http://openid.net/specs/openid-connect-core-1_0.html#RotateSigKeys nor > are any of the client adapters able to use the jks url to retrieve pub > keys rather requiring to hard code the target realm key in the > public-realm-key property of the keycloak.json client configuration file. > > Is this new feature going to implement the OpenID Connect spec > sections 10.1 and 10.2 ? > > Also I assume this would also require changes to adapters by removing > the public-realm-key property from the config file? Yes, exactly. Adapter's side is already implemented in master (but not yet documented). See my other mail for details http://lists.jboss.org/pipermail/keycloak-dev/2016-September/008062.html Marek > > Kind Regards, > Niels > > On Tue, Sep 13, 2016 at 11:41 PM, Nalyvayko, Peter > wrote: > > Is this going to be a breaking feature or is the plan to continue > supporting the current single key/realm model? > > *From:*keycloak-dev-bounces at lists.jboss.org > > [mailto:keycloak-dev-bounces at lists.jboss.org > ] *On Behalf Of > *Stian Thorgersen > *Sent:* Tuesday, September 13, 2016 9:29 AM > *To:* keycloak-dev > > *Subject:* [keycloak-dev] Realm key rotation support > > To be able to gracefully rotate the realm keys periodically a > realm needs to have more than one keypair. One keypair that is > active and will be used to issue new cookies and tokens. Also, one > or more keypairs that are inactive that can be used to verify old > cookies and tokens. > > I'm going to start work on this soon, but here's some initial > thoughts: > > * Realm keys will have a list of keypairs rather than just one. > Only one can be active. There will also be an expiration time on > the inactive keypairs. Once expired and inactive keypair is no > longer usable. > > * There will also be an option to automatically generate a new key > every N days. > > * If a session cookie is signed with an inactive pair the cookie > will be refreshed so it's signed with the active keypair > > * Token introspect endpoint will allow any token that is signed > with any keypair that is not expired > > * If a refresh token is signed with an inactive pair the new > tokens (including refresh token) will be signed with the active > keypair > > * Secret used to generate client code will be linked to the > keypair. I'll need a way to specify what secret it was signed with > so codes are still valid even if they where signed with an old. > > This is only for login cookie and OIDC protocol. Is it even > necessary to have support for multiple certificates for SAML? SAML > doesn't have a token introspection or refresh of the assertions > right, so not sure it's needed. > > With regards to the applications. Marek has already added support > for clients to fetch new keypairs for the realm. See his email on > keycloak-dev for details around that. > > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > > > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160913/d25a811b/attachment-0001.html From mposolda at redhat.com Tue Sep 13 15:46:18 2016 From: mposolda at redhat.com (Marek Posolda) Date: Tue, 13 Sep 2016 21:46:18 +0200 Subject: [keycloak-dev] LDAP setup for demonstration purposes In-Reply-To: <20160913191028.GA6881@abstractj.org> References: <22e0bfbe-2824-07e1-83a1-92f643b4587c@redhat.com> <20160913143925.GE14904@abstractj.org> <8A76F607-BCD2-4DD8-94B5-9EE4BAD36665@smartling.com> <20160913191028.GA6881@abstractj.org> Message-ID: <10079fce-87f3-b991-551d-ad11f3a79261@redhat.com> On 13/09/16 21:10, Bruno Oliveira da Silva wrote: > My 2 cents on it. Unless we have any strong argument for doing this, > let's move forward with Docker. We already have a repository for this > and I'm not sure if we have bandwidth to maintain 2 distinct repositories. > > Btw I'm curious, which real world scenario you could not reproduce with > Docker? I guess SPNEGO login with Firefox is the example of that scenario? If you want workstation with Kerberos + SPNEGO, you will need to configure kerberos client and your Firefox and then run FF inside docker container and display it "locally" on your laptop. Or is it something like the "propagation" of X from docker to your laptop possible? If yes, then everything is doable with docker though. Marek > > On 2016-09-13, Thomas Raehalme wrote: >> How about setting up multiple VMs with Vagrant but handling all software >> components with Docker? >> >> Best of both worlds and also a simulation of the real world (which could >> perhaps be used as a reference). >> >> Best regards, >> Thomas >> >> On Sep 13, 2016 5:46 PM, "Scott Rossillo" wrote: >> >>> Vagrant leaves funny taste in my mouth. Docker Compose to orchestrate >>> things seems like a better option. >>> >>> Scott Rossillo >>> Smartling | Senior Software Engineer >>> srossillo at smartling.com >>> >>> On Sep 13, 2016, at 10:39 AM, Bruno Oliveira da Silva >>> wrote: >>> >>> My question is: Docker or Vagrant? >>> >>> If we have plans to showcase SSSD Federation provider + things like >>> start/stop sssd service to demonstrate the SSSD provider won't be >>> enabled. I would say that Vagrant is easier and we can benefit from >>> these boxes[1], otherwise we just stick with Marek's work. >>> >>> I will give DBus on Docker a second try, but last time I checked wasn't >>> fun. >>> >>> [1] - https://github.com/freeipa/freeipa-workshop >>> >>> On 2016-09-13, Stian Thorgersen wrote: >>> >>> Forgot to add two things: >>> >>> * DNS setup - we want proper DNS setup on the machines, which would be >>> required for the Kerberos stuff to work properly >>> * HTTPS - optional, but would be great if it also had HTTPS configured >>> >>> On 13 September 2016 at 09:24, Marek Posolda wrote: >>> >>> +1 >>> >>> Few more things and tips (you may be already aware of them, but still.. >>> Hope some of them are useful :) : >>> >>> - My docker image [1] already contains FreeIPA server and Keycloak server >>> pre-configured with LDAP+Kerberos federation provider to use it. Thing is >>> that both Keycloak+FreeIPA are on same machine, which is likely not the >>> best for show production setup. The workstation setup needs to be done on >>> your local machine (so you need KErberos client + Firefox setup on your >>> laptop. That's sufficient for testing, but probably also not ideal for >>> showcase). >>> >>> - In addition to FreeIPA docker images for server, FreeIPA has also docker >>> image for client setup. See for example [2] . I am not 100% sure, but I >>> believe that if you run this docker image and point to the already running >>> "server" image, you will gain also all the things like PAM setup, login to >>> the workstation with Kerberos credentials, and automatically retrieved >>> kerberos ticket during login. Hence you just login to workstation, open >>> firefox and you are authenticated to Keycloak. No need to manually run >>> "kinit". >>> >>> >>> The workstation will need to be a virtual machine rather than container to >>> add X support. So IMO we should just use Vagrant and have FreeIPA and >>> use Vagrantfile to install Fedora + FreeIPA. >>> >>> >>> >>> - If Keycloak and FreeIPA server are on different workstations, then: >>> -- The Keycloak server may also need FreeIPA client installed. Or at least >>> kerberos client installed with proper setup in /etc/krb5.conf pointing to >>> FreeIPA kerberos realm and proper DNS setup working with FreeIPA. >>> >>> >>> >>> -- Also for different servers, you will likely need to add HTTP kerberos >>> principal for the server where keycloak is running. For example if FreeIPA >>> is on "freeipa.example.org" and keycloak is on "keycloak.example.org", >>> you will need the principal like HTTP/keycloak.example.org at KEYCLOAK.ORG >>> . >>> This corresponds to LDAP principal under "cn=services,cn=accounts,dc= >>> freeipa,dc=example,dc=org" >>> . Maybe FreeIPA has it documented somewhere and/or it's easily possible to >>> add new HTTP server principal through FreeIPA admin console. You will also >>> need keytab exported with the credentials of this principal. >>> Note this step is not needed if Keycloak and FreeIPA are on same machine >>> as FreeIPA server automatically has HTTP principal for it's own machine >>> (something like HTTP/freeipa.example.org at KEYCLOAK.ORG >>> for the example >>> above), to allow login to FreeIPA admin console with kerberos OOTB. >>> >>> >>> We should really figure out how to do this on separate machines, so I think >>> going that way would be best even though it's harder to do. >>> >>> >>> >>> >>> [1] https://github.com/mposolda/keycloak-freeipa-docker/ >>> [2] https://github.com/adelton/docker-freeipa/tree/fedora-22-client >>> >>> Marek >>> >>> >>> On 13/09/16 08:07, Stian Thorgersen wrote: >>> >>> I'd like to have a simple way to demo LDAP and Kerberos support. To that >>> end we should add a Vagrant setup with the following: >>> >>> * Keycloak server >>> * MySQL or Postgres >>> * FreeIPA >>> * Workstation with Kerberos authentication (needs X and Firefox installed) >>> >>> The Keycloak server should already be configured to use the FreeIPA >>> server as a user federation provider (using LDAP and Kerberos). The >>> workstation can be co-located with FreeIPA server if it makes things much >>> simpler, but it should be possible to login to the workstation with >>> Kerberos. Firefox should be pre-configured for Kerberos to work both on >>> Keycloak login and FreeIPA admin console. >>> >>> I want a proper database and a web based client for the database so it's >>> simple to inspect the database. >>> >>> Bruno has already volunteered to look into this, but first we should make >>> sure this is the setup we'd like to be able to showcase. >>> >>> >>> >>> >>> >>> _______________________________________________ >>> keycloak-dev mailing list >>> keycloak-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>> >>> >>> >>> -- >>> >>> abstractj >>> PGP: 0x84DC9914 >>> _______________________________________________ >>> keycloak-dev mailing list >>> keycloak-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>> >>> >>> >>> _______________________________________________ >>> keycloak-dev mailing list >>> keycloak-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>> > -- > > abstractj > PGP: 0x84DC9914 > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev From bburke at redhat.com Tue Sep 13 16:21:08 2016 From: bburke at redhat.com (Bill Burke) Date: Tue, 13 Sep 2016 16:21:08 -0400 Subject: [keycloak-dev] WARNING: breaking User API backward compatibility Message-ID: FYI: Starting in 2.3, there will be a number of user SPIs and APIs that will be refactored or deprecated. UserModel, UserFederationProvider, UserCredentialModel, PasswordHashProvider, and UserFederationManager are being refactored. UserFederationProvider is also being @Deprecated. Code will break, and you'll have to figure out how to start using the new UserStorageProvider SPI, or update UserFederationProvider implementation. You'll start seeing changes pop up in master over the next few weeks. Regards, Bill From bruno at abstractj.org Tue Sep 13 23:22:52 2016 From: bruno at abstractj.org (Bruno Oliveira) Date: Wed, 14 Sep 2016 00:22:52 -0300 Subject: [keycloak-dev] Keycloak Integration TestSuite FAILURE In-Reply-To: References: Message-ID: <20160914032252.GF6881@abstractj.org> Hi Mauricio, I couldn't reproduce your issue with the latest CentOS version. To make sure that we're discussing about the same environment, I built this docker image[1], just follow the instructions here[2] to run. I hope it helps. [1] - https://hub.docker.com/r/abstractj/keycloak-centos/ [2] - https://github.com/abstractj/docker/blob/centos/centos-java-dev/README.md On 2016-09-13, Maur?cio Giacomini Penteado wrote: > > I am trying build with a CentOS Linux release 7.2. > > I have already tried build the keycloak versions 2.0.0, 2.1.0 and 2.2.0 with OpenJDK and Oracle JDK. > > I just did a clone and performed a "mvn install". > > All my attempts result in the same errors: > > Keycloak Integration TestSuite FAILURE > > Failed tests: > JaxrsFilterTest.testCors:286 expected:<200> but was:<403> > JaxrsFilterTest.testRelativeUriAndPublicKey:172 expected:<500> but was:<401> > Tests in error: > JaxrsBasicAuthTest.testBasic:141 ? ClientError HTTP 403 Forbidden > JaxrsFilterTest.testBasic:141 ? ClientError HTTP 403 Forbidden > JaxrsFilterTest.testPushNotBefore:314 ? ClientError HTTP 403 Forbidden > JaxrsFilterTest.testResourceRoleMappings:236 ? ClientError HTTP 403 Forbidden > > Tests run: 414, Failures: 2, Errors: 4, Skipped: 32 > > = [ > > Somebody, please! > ________________________________ > De: Maur?cio Giacomini Penteado > Enviado: ter?a-feira, 13 de setembro de 2016 14:20 > Para: stian at redhat.com > Cc: keycloak-dev at lists.jboss.org > Assunto: Re: [keycloak-dev] Keycloak Integration TestSuite FAILURE > > > Hello Stian > > > I did a clone of master from Travis repository and to me the errors are the same = / > > > ________________________________ > De: Stian Thorgersen > Enviado: ter?a-feira, 13 de setembro de 2016 13:10 > Para: Maur?cio Giacomini Penteado > Cc: keycloak-dev at lists.jboss.org > Assunto: Re: [keycloak-dev] Keycloak Integration TestSuite FAILURE > > What steps do you run to build/test? Works on my box and also it works on Travis. > > On 13 September 2016 at 15:08, Maur?cio Giacomini Penteado > wrote: > > Hello everybody. > > All my attempts to build keycloak result in the same errors: > > Keycloak Integration TestSuite FAILURE > > Failed tests: > JaxrsFilterTest.testCors:286 expected:<200> but was:<403> > JaxrsFilterTest.testRelativeUriAndPublicKey:172 expected:<500> but was:<401> > Tests in error: > JaxrsBasicAuthTest.testBasic:141 ? ClientError HTTP 403 Forbidden > JaxrsFilterTest.testBasic:141 ? ClientError HTTP 403 Forbidden > JaxrsFilterTest.testPushNotBefore:314 ? ClientError HTTP 403 Forbidden > JaxrsFilterTest.testResourceRoleMappings:236 ? ClientError HTTP 403 Forbidden > > Tests run: 414, Failures: 2, Errors: 4, Skipped: 32 > > If somebody has an idea about what happens, please let me know! > > Kind regards, > Maur?cio. > > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev -- abstractj PGP: 0x84DC9914 From thomas.raehalme at aitiofinland.com Wed Sep 14 01:39:37 2016 From: thomas.raehalme at aitiofinland.com (Thomas Raehalme) Date: Wed, 14 Sep 2016 08:39:37 +0300 Subject: [keycloak-dev] LDAP setup for demonstration purposes In-Reply-To: <10079fce-87f3-b991-551d-ad11f3a79261@redhat.com> References: <22e0bfbe-2824-07e1-83a1-92f643b4587c@redhat.com> <20160913143925.GE14904@abstractj.org> <8A76F607-BCD2-4DD8-94B5-9EE4BAD36665@smartling.com> <20160913191028.GA6881@abstractj.org> <10079fce-87f3-b991-551d-ad11f3a79261@redhat.com> Message-ID: On Tue, Sep 13, 2016 at 10:46 PM, Marek Posolda wrote: > On 13/09/16 21:10, Bruno Oliveira da Silva wrote: >> My 2 cents on it. Unless we have any strong argument for doing this, >> let's move forward with Docker. We already have a repository for this >> and I'm not sure if we have bandwidth to maintain 2 distinct repositories. Maybe I misunderstood, but Vagrant does not need a repository if you use the publicly available boxes. It's just a Vagrantfile where you specify the boxes and how to bootstrap them. >> Btw I'm curious, which real world scenario you could not reproduce with >> Docker? > > I guess SPNEGO login with Firefox is the example of that scenario? Yes, running GUI applications is what I had in mind as well. But besides Firefox I did not mean that you cannot do something with Docker. It was more about that not everybody are running Docker in a cluster such as Swarm or Kubernetes. Instead one might use separate VMs, but run the applications with Docker. With a combination of Vagrant and Docker here would be a great example of doing exactly that. Best regards, Thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160914/f74760c4/attachment.html From sthorger at redhat.com Wed Sep 14 03:17:40 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Wed, 14 Sep 2016 09:17:40 +0200 Subject: [keycloak-dev] Realm key rotation support In-Reply-To: References: Message-ID: On 13 September 2016 at 15:41, Nalyvayko, Peter wrote: > Is this going to be a breaking feature or is the plan to continue > supporting the current single key/realm model? > If you only have a single active keypair and no inactive pairs it will behave exactly as today. We will change the way keys are stored in the db, but this will be taken care of by migration. > > > *From:* keycloak-dev-bounces at lists.jboss.org [mailto:keycloak-dev-bounces@ > lists.jboss.org] *On Behalf Of *Stian Thorgersen > *Sent:* Tuesday, September 13, 2016 9:29 AM > *To:* keycloak-dev > *Subject:* [keycloak-dev] Realm key rotation support > > > > To be able to gracefully rotate the realm keys periodically a realm needs > to have more than one keypair. One keypair that is active and will be used > to issue new cookies and tokens. Also, one or more keypairs that are > inactive that can be used to verify old cookies and tokens. > > > > I'm going to start work on this soon, but here's some initial thoughts: > > > > * Realm keys will have a list of keypairs rather than just one. Only one > can be active. There will also be an expiration time on the inactive > keypairs. Once expired and inactive keypair is no longer usable. > > * There will also be an option to automatically generate a new key every N > days. > > * If a session cookie is signed with an inactive pair the cookie will be > refreshed so it's signed with the active keypair > > * Token introspect endpoint will allow any token that is signed with any > keypair that is not expired > > * If a refresh token is signed with an inactive pair the new tokens > (including refresh token) will be signed with the active keypair > > * Secret used to generate client code will be linked to the keypair. I'll > need a way to specify what secret it was signed with so codes are still > valid even if they where signed with an old. > > > > This is only for login cookie and OIDC protocol. Is it even necessary to > have support for multiple certificates for SAML? SAML doesn't have a token > introspection or refresh of the assertions right, so not sure it's needed. > > > > With regards to the applications. Marek has already added support for > clients to fetch new keypairs for the realm. See his email on keycloak-dev > for details around that. > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160914/60e3a122/attachment-0001.html From tgc at dma.dk Wed Sep 14 03:17:48 2016 From: tgc at dma.dk (Tomas Groth Christensen) Date: Wed, 14 Sep 2016 07:17:48 +0000 Subject: [keycloak-dev] Allow multiple users with the same email Message-ID: <1473837468.15209.29.camel@dma.dk> Hi, I'm involved in a project where we use Keycloak as Identity Broker, and so far we've been very happy with Keycloak, and implemented a few SPIs to do some special things, but now we've hit a snag... In our setup we have many clients using the Identity Broker which then again has many Identity Providers from which the user can chose one to use for login. Our problem is that the same user (using one email address) can exist in 2 or more Identity Providers, and we do not want to link these accounts. The reason for not linking the accounts is that the user can be given special privileges in clients, based on which Identity Provider the user comes from. These privileges should not be carried over from one Identity Providers user to another since the same user might be an administrator when coming the one Identity Provider and a common user when coming from a different Identity Provider. So, is it possible to allow multiple users to have the same email address? Looking at the source code there are checks for duplicated user-emails in most places where users are created... Could a solution be to implement a custom authenticator that replaces IdpCreateUserIfUniqueAuthenticator which does not check for duplicated emails, or are there database constraints that will prohibit this? An alternative solution could perhaps be a custom authenticator that simply deletes existing users with the same email address? I hope you can give me some pointer on how to proceed... -- Best regards, Tomas Groth Christensen Softwaredeveloper Danish Maritime Authority From sthorger at redhat.com Wed Sep 14 03:21:16 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Wed, 14 Sep 2016 09:21:16 +0200 Subject: [keycloak-dev] Realm key rotation support In-Reply-To: References: Message-ID: On 13 September 2016 at 16:36, Niels Bertram wrote: > Hi Stian, > > intersting email, we were recently given advise to rotate keys > periodically but at this point in time keycloak 1.9.8 does not actually > implement http://openid.net/specs/openid-connect-core-1_0. > html#RotateSigKeys nor are any of the client adapters able to use the jks > url to retrieve pub keys rather requiring to hard code the target realm key > in the public-realm-key property of the keycloak.json client configuration > file. > > Is this new feature going to implement the OpenID Connect spec sections > 10.1 and 10.2 ? > 10.1 yes, we don't support encryption at the moment and this work will not include it. > > Also I assume this would also require changes to adapters by removing the > public-realm-key property from the config file? > > Kind Regards, > Niels > > On Tue, Sep 13, 2016 at 11:41 PM, Nalyvayko, Peter > wrote: > >> Is this going to be a breaking feature or is the plan to continue >> supporting the current single key/realm model? >> >> >> >> *From:* keycloak-dev-bounces at lists.jboss.org [mailto: >> keycloak-dev-bounces at lists.jboss.org] *On Behalf Of *Stian Thorgersen >> *Sent:* Tuesday, September 13, 2016 9:29 AM >> *To:* keycloak-dev >> *Subject:* [keycloak-dev] Realm key rotation support >> >> >> >> To be able to gracefully rotate the realm keys periodically a realm needs >> to have more than one keypair. One keypair that is active and will be used >> to issue new cookies and tokens. Also, one or more keypairs that are >> inactive that can be used to verify old cookies and tokens. >> >> >> >> I'm going to start work on this soon, but here's some initial thoughts: >> >> >> >> * Realm keys will have a list of keypairs rather than just one. Only one >> can be active. There will also be an expiration time on the inactive >> keypairs. Once expired and inactive keypair is no longer usable. >> >> * There will also be an option to automatically generate a new key every >> N days. >> >> * If a session cookie is signed with an inactive pair the cookie will be >> refreshed so it's signed with the active keypair >> >> * Token introspect endpoint will allow any token that is signed with any >> keypair that is not expired >> >> * If a refresh token is signed with an inactive pair the new tokens >> (including refresh token) will be signed with the active keypair >> >> * Secret used to generate client code will be linked to the keypair. I'll >> need a way to specify what secret it was signed with so codes are still >> valid even if they where signed with an old. >> >> >> >> This is only for login cookie and OIDC protocol. Is it even necessary to >> have support for multiple certificates for SAML? SAML doesn't have a token >> introspection or refresh of the assertions right, so not sure it's needed. >> >> >> >> With regards to the applications. Marek has already added support for >> clients to fetch new keypairs for the realm. See his email on keycloak-dev >> for details around that. >> >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160914/9a1cd62c/attachment.html From sthorger at redhat.com Wed Sep 14 03:24:41 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Wed, 14 Sep 2016 09:24:41 +0200 Subject: [keycloak-dev] Allow multiple users with the same email In-Reply-To: <1473837468.15209.29.camel@dma.dk> References: <1473837468.15209.29.camel@dma.dk> Message-ID: We are planning to introduce support for contact email in the future. The current email field is both a login and a contact email. As it's used for login it has to be unique. You could probably work around it with custom mappers for your IdPs that map email to an attribute rather than the user email field. Then create a custom email sender to use the contact attribute from the user rather than email field. [1] https://github.com/keycloak/keycloak/blob/master/services/src/main/java/org/keycloak/email/DefaultEmailSenderProvider.java On 14 September 2016 at 09:17, Tomas Groth Christensen wrote: > Hi, > > I'm involved in a project where we use Keycloak as Identity Broker, and > so far we've been very happy with Keycloak, and implemented a few SPIs > to do some special things, but now we've hit a snag... > > In our setup we have many clients using the Identity Broker which then > again has many Identity Providers from which the user can chose one to > use for login. > Our problem is that the same user (using one email address) can exist > in 2 or more Identity Providers, and we do not want to link these > accounts. The reason for not linking the accounts is that the user can > be given special privileges in clients, based on which Identity > Provider the user comes from. These privileges should not be carried > over from one Identity Providers user to another since the same user > might be an administrator when coming the one Identity Provider and a > common user when coming from a different Identity Provider. > > So, is it possible to allow multiple users to have the same email > address? Looking at the source code there are checks for duplicated > user-emails in most places where users are created... Could a solution > be to implement a custom authenticator that replaces > IdpCreateUserIfUniqueAuthenticator which does not check for duplicated > emails, or are there database constraints that will prohibit this? > An alternative solution could perhaps be a custom authenticator that > simply deletes existing users with the same email address? > > I hope you can give me some pointer on how to proceed... > > > -- > Best regards, > Tomas Groth Christensen > Softwaredeveloper > Danish Maritime Authority > > > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160914/67a6a2f3/attachment.html From sthorger at redhat.com Wed Sep 14 03:27:51 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Wed, 14 Sep 2016 09:27:51 +0200 Subject: [keycloak-dev] Keycloak Integration TestSuite FAILURE In-Reply-To: References: Message-ID: You wouldn't by any chance have a service running on port 8081? The testsuite uses ports 8080-8082. On 13 September 2016 at 20:12, Maur?cio Giacomini Penteado < mauriciogiacomini at hotmail.com> wrote: > > I am trying build with a CentOS Linux release 7.2. > > I have already tried build the keycloak versions 2.0.0, 2.1.0 and 2.2.0 > with OpenJDK and Oracle JDK. > > I just did a clone and performed a "mvn install". > > All my attempts result in the same errors: > > Keycloak Integration TestSuite FAILURE > > Failed tests: > JaxrsFilterTest.testCors:286 expected:<200> but was:<403> > JaxrsFilterTest.testRelativeUriAndPublicKey:172 expected:<500> but > was:<401> > Tests in error: > JaxrsBasicAuthTest.testBasic:141 ? ClientError HTTP 403 Forbidden > JaxrsFilterTest.testBasic:141 ? ClientError HTTP 403 Forbidden > JaxrsFilterTest.testPushNotBefore:314 ? ClientError HTTP 403 Forbidden > JaxrsFilterTest.testResourceRoleMappings:236 ? ClientError HTTP 403 > Forbidden > > Tests run: 414, Failures: 2, Errors: 4, Skipped: 32 > > = [ > > Somebody, please! > ------------------------------ > *De:* Maur?cio Giacomini Penteado > *Enviado:* ter?a-feira, 13 de setembro de 2016 14:20 > *Para:* stian at redhat.com > > *Cc:* keycloak-dev at lists.jboss.org > *Assunto:* Re: [keycloak-dev] Keycloak Integration TestSuite FAILURE > > > Hello Stian > > > I did a clone of master from Travis repository and to me the errors are > the same = / > > > ------------------------------ > *De:* Stian Thorgersen > *Enviado:* ter?a-feira, 13 de setembro de 2016 13:10 > *Para:* Maur?cio Giacomini Penteado > *Cc:* keycloak-dev at lists.jboss.org > *Assunto:* Re: [keycloak-dev] Keycloak Integration TestSuite FAILURE > > What steps do you run to build/test? Works on my box and also it works on > Travis. > > On 13 September 2016 at 15:08, Maur?cio Giacomini Penteado < > mauriciogiacomini at hotmail.com> wrote: > >> Hello everybody. >> >> All my attempts to build keycloak result in the same errors: >> >> Keycloak Integration TestSuite FAILURE >> >> Failed tests: >> JaxrsFilterTest.testCors:286 expected:<200> but was:<403> >> JaxrsFilterTest.testRelativeUriAndPublicKey:172 expected:<500> but >> was:<401> >> Tests in error: >> JaxrsBasicAuthTest.testBasic:141 ? ClientError HTTP 403 Forbidden >> JaxrsFilterTest.testBasic:141 ? ClientError HTTP 403 Forbidden >> JaxrsFilterTest.testPushNotBefore:314 ? ClientError HTTP 403 Forbidden >> JaxrsFilterTest.testResourceRoleMappings:236 ? ClientError HTTP 403 >> Forbidden >> >> Tests run: 414, Failures: 2, Errors: 4, Skipped: 32 >> >> If somebody has an idea about what happens, please let me know! >> >> Kind regards, >> Maur?cio. >> >> >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> > > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160914/58f754c0/attachment-0001.html From sthorger at redhat.com Wed Sep 14 03:32:37 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Wed, 14 Sep 2016 09:32:37 +0200 Subject: [keycloak-dev] LDAP setup for demonstration purposes In-Reply-To: <10079fce-87f3-b991-551d-ad11f3a79261@redhat.com> References: <22e0bfbe-2824-07e1-83a1-92f643b4587c@redhat.com> <20160913143925.GE14904@abstractj.org> <8A76F607-BCD2-4DD8-94B5-9EE4BAD36665@smartling.com> <20160913191028.GA6881@abstractj.org> <10079fce-87f3-b991-551d-ad11f3a79261@redhat.com> Message-ID: I want full desktop and show user login via desktop login, not Kerberos client. So full Gnome is required. Also, I think the DNS setup as well as orchestration may be simpler with Vagrant than Docker. We also may want to extend this to include good old Microsoft software in the form of Windows and Active Directory. In that case Docker is a show stopper and Vagrant/VMs is the only option. On 13 September 2016 at 21:46, Marek Posolda wrote: > On 13/09/16 21:10, Bruno Oliveira da Silva wrote: > > My 2 cents on it. Unless we have any strong argument for doing this, > > let's move forward with Docker. We already have a repository for this > > and I'm not sure if we have bandwidth to maintain 2 distinct > repositories. > > > > Btw I'm curious, which real world scenario you could not reproduce with > > Docker? > I guess SPNEGO login with Firefox is the example of that scenario? > > If you want workstation with Kerberos + SPNEGO, you will need to > configure kerberos client and your Firefox and then run FF inside docker > container and display it "locally" on your laptop. Or is it something > like the "propagation" of X from docker to your laptop possible? If yes, > then everything is doable with docker though. > > Marek > > > > > On 2016-09-13, Thomas Raehalme wrote: > >> How about setting up multiple VMs with Vagrant but handling all software > >> components with Docker? > >> > >> Best of both worlds and also a simulation of the real world (which could > >> perhaps be used as a reference). > >> > >> Best regards, > >> Thomas > >> > >> On Sep 13, 2016 5:46 PM, "Scott Rossillo" > wrote: > >> > >>> Vagrant leaves funny taste in my mouth. Docker Compose to orchestrate > >>> things seems like a better option. > >>> > >>> Scott Rossillo > >>> Smartling | Senior Software Engineer > >>> srossillo at smartling.com > >>> > >>> On Sep 13, 2016, at 10:39 AM, Bruno Oliveira da Silva < > bruno at abstractj.org> > >>> wrote: > >>> > >>> My question is: Docker or Vagrant? > >>> > >>> If we have plans to showcase SSSD Federation provider + things like > >>> start/stop sssd service to demonstrate the SSSD provider won't be > >>> enabled. I would say that Vagrant is easier and we can benefit from > >>> these boxes[1], otherwise we just stick with Marek's work. > >>> > >>> I will give DBus on Docker a second try, but last time I checked wasn't > >>> fun. > >>> > >>> [1] - https://github.com/freeipa/freeipa-workshop > >>> > >>> On 2016-09-13, Stian Thorgersen wrote: > >>> > >>> Forgot to add two things: > >>> > >>> * DNS setup - we want proper DNS setup on the machines, which would be > >>> required for the Kerberos stuff to work properly > >>> * HTTPS - optional, but would be great if it also had HTTPS configured > >>> > >>> On 13 September 2016 at 09:24, Marek Posolda > wrote: > >>> > >>> +1 > >>> > >>> Few more things and tips (you may be already aware of them, but still.. > >>> Hope some of them are useful :) : > >>> > >>> - My docker image [1] already contains FreeIPA server and Keycloak > server > >>> pre-configured with LDAP+Kerberos federation provider to use it. Thing > is > >>> that both Keycloak+FreeIPA are on same machine, which is likely not the > >>> best for show production setup. The workstation setup needs to be done > on > >>> your local machine (so you need KErberos client + Firefox setup on your > >>> laptop. That's sufficient for testing, but probably also not ideal for > >>> showcase). > >>> > >>> - In addition to FreeIPA docker images for server, FreeIPA has also > docker > >>> image for client setup. See for example [2] . I am not 100% sure, but I > >>> believe that if you run this docker image and point to the already > running > >>> "server" image, you will gain also all the things like PAM setup, > login to > >>> the workstation with Kerberos credentials, and automatically retrieved > >>> kerberos ticket during login. Hence you just login to workstation, open > >>> firefox and you are authenticated to Keycloak. No need to manually run > >>> "kinit". > >>> > >>> > >>> The workstation will need to be a virtual machine rather than > container to > >>> add X support. So IMO we should just use Vagrant and have FreeIPA and > >>> use Vagrantfile to install Fedora + FreeIPA. > >>> > >>> > >>> > >>> - If Keycloak and FreeIPA server are on different workstations, then: > >>> -- The Keycloak server may also need FreeIPA client installed. Or at > least > >>> kerberos client installed with proper setup in /etc/krb5.conf pointing > to > >>> FreeIPA kerberos realm and proper DNS setup working with FreeIPA. > >>> > >>> > >>> > >>> -- Also for different servers, you will likely need to add HTTP > kerberos > >>> principal for the server where keycloak is running. For example if > FreeIPA > >>> is on "freeipa.example.org" and keycloak is on "keycloak.example.org", > >>> you will need the principal like HTTP/keycloak.example.org@ > KEYCLOAK.ORG > >>> . > >>> This corresponds to LDAP principal under "cn=services,cn=accounts,dc= > >>> freeipa,dc=example,dc=org" > >>> . Maybe FreeIPA has it documented somewhere and/or it's easily > possible to > >>> add new HTTP server principal through FreeIPA admin console. You will > also > >>> need keytab exported with the credentials of this principal. > >>> Note this step is not needed if Keycloak and FreeIPA are on same > machine > >>> as FreeIPA server automatically has HTTP principal for it's own machine > >>> (something like HTTP/freeipa.example.org at KEYCLOAK.ORG > >>> for the example > >>> above), to allow login to FreeIPA admin console with kerberos OOTB. > >>> > >>> > >>> We should really figure out how to do this on separate machines, so I > think > >>> going that way would be best even though it's harder to do. > >>> > >>> > >>> > >>> > >>> [1] https://github.com/mposolda/keycloak-freeipa-docker/ > >>> [2] https://github.com/adelton/docker-freeipa/tree/fedora-22-client > >>> > >>> Marek > >>> > >>> > >>> On 13/09/16 08:07, Stian Thorgersen wrote: > >>> > >>> I'd like to have a simple way to demo LDAP and Kerberos support. To > that > >>> end we should add a Vagrant setup with the following: > >>> > >>> * Keycloak server > >>> * MySQL or Postgres > >>> * FreeIPA > >>> * Workstation with Kerberos authentication (needs X and Firefox > installed) > >>> > >>> The Keycloak server should already be configured to use the FreeIPA > >>> server as a user federation provider (using LDAP and Kerberos). The > >>> workstation can be co-located with FreeIPA server if it makes things > much > >>> simpler, but it should be possible to login to the workstation with > >>> Kerberos. Firefox should be pre-configured for Kerberos to work both on > >>> Keycloak login and FreeIPA admin console. > >>> > >>> I want a proper database and a web based client for the database so > it's > >>> simple to inspect the database. > >>> > >>> Bruno has already volunteered to look into this, but first we should > make > >>> sure this is the setup we'd like to be able to showcase. > >>> > >>> > >>> > >>> > >>> > >>> _______________________________________________ > >>> keycloak-dev mailing list > >>> keycloak-dev at lists.jboss.org > >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev > >>> > >>> > >>> > >>> -- > >>> > >>> abstractj > >>> PGP: 0x84DC9914 > >>> _______________________________________________ > >>> keycloak-dev mailing list > >>> keycloak-dev at lists.jboss.org > >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev > >>> > >>> > >>> > >>> _______________________________________________ > >>> keycloak-dev mailing list > >>> keycloak-dev at lists.jboss.org > >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev > >>> > > -- > > > > abstractj > > PGP: 0x84DC9914 > > _______________________________________________ > > keycloak-dev mailing list > > keycloak-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160914/04898541/attachment.html From sthorger at redhat.com Wed Sep 14 03:34:48 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Wed, 14 Sep 2016 09:34:48 +0200 Subject: [keycloak-dev] LDAP setup for demonstration purposes In-Reply-To: References: <22e0bfbe-2824-07e1-83a1-92f643b4587c@redhat.com> <20160913143925.GE14904@abstractj.org> <8A76F607-BCD2-4DD8-94B5-9EE4BAD36665@smartling.com> <20160913191028.GA6881@abstractj.org> <10079fce-87f3-b991-551d-ad11f3a79261@redhat.com> Message-ID: To elaborate I could eventually see us having a big demo setup in the form of: * Keycloak or RH-SSO box * Database box * FreeIPA box * Active Directory box * Some SAML provider * Some OIDC provider * Fedora workstation * Windows workstation Everything ready to go to show Keycloak as a fully capable identity federation platform. On 14 September 2016 at 09:32, Stian Thorgersen wrote: > I want full desktop and show user login via desktop login, not Kerberos > client. So full Gnome is required. Also, I think the DNS setup as well as > orchestration may be simpler with Vagrant than Docker. > > We also may want to extend this to include good old Microsoft software in > the form of Windows and Active Directory. In that case Docker is a show > stopper and Vagrant/VMs is the only option. > > On 13 September 2016 at 21:46, Marek Posolda wrote: > >> On 13/09/16 21:10, Bruno Oliveira da Silva wrote: >> > My 2 cents on it. Unless we have any strong argument for doing this, >> > let's move forward with Docker. We already have a repository for this >> > and I'm not sure if we have bandwidth to maintain 2 distinct >> repositories. >> > >> > Btw I'm curious, which real world scenario you could not reproduce with >> > Docker? >> I guess SPNEGO login with Firefox is the example of that scenario? >> >> If you want workstation with Kerberos + SPNEGO, you will need to >> configure kerberos client and your Firefox and then run FF inside docker >> container and display it "locally" on your laptop. Or is it something >> like the "propagation" of X from docker to your laptop possible? If yes, >> then everything is doable with docker though. >> >> Marek >> >> > >> > On 2016-09-13, Thomas Raehalme wrote: >> >> How about setting up multiple VMs with Vagrant but handling all >> software >> >> components with Docker? >> >> >> >> Best of both worlds and also a simulation of the real world (which >> could >> >> perhaps be used as a reference). >> >> >> >> Best regards, >> >> Thomas >> >> >> >> On Sep 13, 2016 5:46 PM, "Scott Rossillo" >> wrote: >> >> >> >>> Vagrant leaves funny taste in my mouth. Docker Compose to orchestrate >> >>> things seems like a better option. >> >>> >> >>> Scott Rossillo >> >>> Smartling | Senior Software Engineer >> >>> srossillo at smartling.com >> >>> >> >>> On Sep 13, 2016, at 10:39 AM, Bruno Oliveira da Silva < >> bruno at abstractj.org> >> >>> wrote: >> >>> >> >>> My question is: Docker or Vagrant? >> >>> >> >>> If we have plans to showcase SSSD Federation provider + things like >> >>> start/stop sssd service to demonstrate the SSSD provider won't be >> >>> enabled. I would say that Vagrant is easier and we can benefit from >> >>> these boxes[1], otherwise we just stick with Marek's work. >> >>> >> >>> I will give DBus on Docker a second try, but last time I checked >> wasn't >> >>> fun. >> >>> >> >>> [1] - https://github.com/freeipa/freeipa-workshop >> >>> >> >>> On 2016-09-13, Stian Thorgersen wrote: >> >>> >> >>> Forgot to add two things: >> >>> >> >>> * DNS setup - we want proper DNS setup on the machines, which would be >> >>> required for the Kerberos stuff to work properly >> >>> * HTTPS - optional, but would be great if it also had HTTPS configured >> >>> >> >>> On 13 September 2016 at 09:24, Marek Posolda >> wrote: >> >>> >> >>> +1 >> >>> >> >>> Few more things and tips (you may be already aware of them, but >> still.. >> >>> Hope some of them are useful :) : >> >>> >> >>> - My docker image [1] already contains FreeIPA server and Keycloak >> server >> >>> pre-configured with LDAP+Kerberos federation provider to use it. >> Thing is >> >>> that both Keycloak+FreeIPA are on same machine, which is likely not >> the >> >>> best for show production setup. The workstation setup needs to be >> done on >> >>> your local machine (so you need KErberos client + Firefox setup on >> your >> >>> laptop. That's sufficient for testing, but probably also not ideal for >> >>> showcase). >> >>> >> >>> - In addition to FreeIPA docker images for server, FreeIPA has also >> docker >> >>> image for client setup. See for example [2] . I am not 100% sure, but >> I >> >>> believe that if you run this docker image and point to the already >> running >> >>> "server" image, you will gain also all the things like PAM setup, >> login to >> >>> the workstation with Kerberos credentials, and automatically retrieved >> >>> kerberos ticket during login. Hence you just login to workstation, >> open >> >>> firefox and you are authenticated to Keycloak. No need to manually run >> >>> "kinit". >> >>> >> >>> >> >>> The workstation will need to be a virtual machine rather than >> container to >> >>> add X support. So IMO we should just use Vagrant and have FreeIPA and >> >>> use Vagrantfile to install Fedora + FreeIPA. >> >>> >> >>> >> >>> >> >>> - If Keycloak and FreeIPA server are on different workstations, then: >> >>> -- The Keycloak server may also need FreeIPA client installed. Or at >> least >> >>> kerberos client installed with proper setup in /etc/krb5.conf >> pointing to >> >>> FreeIPA kerberos realm and proper DNS setup working with FreeIPA. >> >>> >> >>> >> >>> >> >>> -- Also for different servers, you will likely need to add HTTP >> kerberos >> >>> principal for the server where keycloak is running. For example if >> FreeIPA >> >>> is on "freeipa.example.org" and keycloak is on "keycloak.example.org >> ", >> >>> you will need the principal like HTTP/keycloak.example.org at KEYC >> LOAK.ORG >> >>> . >> >>> This corresponds to LDAP principal under "cn=services,cn=accounts,dc= >> >>> freeipa,dc=example,dc=org" >> >>> . Maybe FreeIPA has it documented somewhere and/or it's easily >> possible to >> >>> add new HTTP server principal through FreeIPA admin console. You will >> also >> >>> need keytab exported with the credentials of this principal. >> >>> Note this step is not needed if Keycloak and FreeIPA are on same >> machine >> >>> as FreeIPA server automatically has HTTP principal for it's own >> machine >> >>> (something like HTTP/freeipa.example.org at KEYCLOAK.ORG >> >>> for the example >> >>> above), to allow login to FreeIPA admin console with kerberos OOTB. >> >>> >> >>> >> >>> We should really figure out how to do this on separate machines, so I >> think >> >>> going that way would be best even though it's harder to do. >> >>> >> >>> >> >>> >> >>> >> >>> [1] https://github.com/mposolda/keycloak-freeipa-docker/ >> >>> [2] https://github.com/adelton/docker-freeipa/tree/fedora-22-client >> >>> >> >>> Marek >> >>> >> >>> >> >>> On 13/09/16 08:07, Stian Thorgersen wrote: >> >>> >> >>> I'd like to have a simple way to demo LDAP and Kerberos support. To >> that >> >>> end we should add a Vagrant setup with the following: >> >>> >> >>> * Keycloak server >> >>> * MySQL or Postgres >> >>> * FreeIPA >> >>> * Workstation with Kerberos authentication (needs X and Firefox >> installed) >> >>> >> >>> The Keycloak server should already be configured to use the FreeIPA >> >>> server as a user federation provider (using LDAP and Kerberos). The >> >>> workstation can be co-located with FreeIPA server if it makes things >> much >> >>> simpler, but it should be possible to login to the workstation with >> >>> Kerberos. Firefox should be pre-configured for Kerberos to work both >> on >> >>> Keycloak login and FreeIPA admin console. >> >>> >> >>> I want a proper database and a web based client for the database so >> it's >> >>> simple to inspect the database. >> >>> >> >>> Bruno has already volunteered to look into this, but first we should >> make >> >>> sure this is the setup we'd like to be able to showcase. >> >>> >> >>> >> >>> >> >>> >> >>> >> >>> _______________________________________________ >> >>> keycloak-dev mailing list >> >>> keycloak-dev at lists.jboss.org >> >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> >>> >> >>> >> >>> >> >>> -- >> >>> >> >>> abstractj >> >>> PGP: 0x84DC9914 >> >>> _______________________________________________ >> >>> keycloak-dev mailing list >> >>> keycloak-dev at lists.jboss.org >> >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> >>> >> >>> >> >>> >> >>> _______________________________________________ >> >>> keycloak-dev mailing list >> >>> keycloak-dev at lists.jboss.org >> >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> >>> >> > -- >> > >> > abstractj >> > PGP: 0x84DC9914 >> > _______________________________________________ >> > keycloak-dev mailing list >> > keycloak-dev at lists.jboss.org >> > https://lists.jboss.org/mailman/listinfo/keycloak-dev >> >> >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160914/0aa878b1/attachment-0001.html From tgc at dma.dk Wed Sep 14 03:54:21 2016 From: tgc at dma.dk (Tomas Groth Christensen) Date: Wed, 14 Sep 2016 07:54:21 +0000 Subject: [keycloak-dev] Allow multiple users with the same email In-Reply-To: References: <1473837468.15209.29.camel@dma.dk> Message-ID: <1473839661.17958.9.camel@dma.dk> Hi again, Thanks for the fast reply! ons, 14 09 2016 kl. 09:24 +0200, skrev Stian Thorgersen: We are planning to introduce support for contact email in the future. The current email field is both a login and a contact email. As it's used for login it has to be unique. Do you have an approximate ETA for the contact email introduction? You could probably work around it with custom mappers for your IdPs that map email to an attribute rather than the user email field. Then create a custom email sender to use the contact attribute from the user rather than email field. While I can see that this would work, would this have any advantage over the "custom-authenticator-that-deletes-existing-users-with-the-same-email" approach I mentioned? In my view using the "delete" approach is easier/faster to implement and would also requires fewer changes once the contact-email is introduced. Best regards, Tomas [1] https://github.com/keycloak/keycloak/blob/master/services/src/main/java/org/keycloak/email/DefaultEmailSenderProvider.java On 14 September 2016 at 09:17, Tomas Groth Christensen > wrote: Hi, I'm involved in a project where we use Keycloak as Identity Broker, and so far we've been very happy with Keycloak, and implemented a few SPIs to do some special things, but now we've hit a snag... In our setup we have many clients using the Identity Broker which then again has many Identity Providers from which the user can chose one to use for login. Our problem is that the same user (using one email address) can exist in 2 or more Identity Providers, and we do not want to link these accounts. The reason for not linking the accounts is that the user can be given special privileges in clients, based on which Identity Provider the user comes from. These privileges should not be carried over from one Identity Providers user to another since the same user might be an administrator when coming the one Identity Provider and a common user when coming from a different Identity Provider. So, is it possible to allow multiple users to have the same email address? Looking at the source code there are checks for duplicated user-emails in most places where users are created... Could a solution be to implement a custom authenticator that replaces IdpCreateUserIfUniqueAuthenticator which does not check for duplicated emails, or are there database constraints that will prohibit this? An alternative solution could perhaps be a custom authenticator that simply deletes existing users with the same email address? I hope you can give me some pointer on how to proceed... -- Best regards, Tomas Groth Christensen Softwaredeveloper Danish Maritime Authority _______________________________________________ keycloak-dev mailing list keycloak-dev at lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160914/0bd6e17f/attachment.html From bruno at abstractj.org Wed Sep 14 06:08:39 2016 From: bruno at abstractj.org (Bruno Oliveira da Silva) Date: Wed, 14 Sep 2016 07:08:39 -0300 Subject: [keycloak-dev] LDAP setup for demonstration purposes In-Reply-To: References: <22e0bfbe-2824-07e1-83a1-92f643b4587c@redhat.com> <20160913143925.GE14904@abstractj.org> <8A76F607-BCD2-4DD8-94B5-9EE4BAD36665@smartling.com> <20160913191028.GA6881@abstractj.org> <10079fce-87f3-b991-551d-ad11f3a79261@redhat.com> Message-ID: <20160914100839.GA10342@abstractj.org> On 2016-09-14, Thomas Raehalme wrote: > On Tue, Sep 13, 2016 at 10:46 PM, Marek Posolda wrote: > > On 13/09/16 21:10, Bruno Oliveira da Silva wrote: > >> My 2 cents on it. Unless we have any strong argument for doing this, > >> let's move forward with Docker. We already have a repository for this > >> and I'm not sure if we have bandwidth to maintain 2 distinct > repositories. > > Maybe I misunderstood, but Vagrant does not need a repository if you use > the publicly available boxes. It's just a Vagrantfile where you specify the > boxes and how to bootstrap them. By repository I meant, git repository. > > >> Btw I'm curious, which real world scenario you could not reproduce with > >> Docker? > > > > I guess SPNEGO login with Firefox is the example of that scenario? > > Yes, running GUI applications is what I had in mind as well. > > But besides Firefox I did not mean that you cannot do something with > Docker. It was more about that not everybody are running Docker in a > cluster such as Swarm or Kubernetes. Instead one might use separate VMs, > but run the applications with Docker. With a combination of Vagrant and > Docker here would be a great example of doing exactly that. > > Best regards, > Thomas -- abstractj PGP: 0x84DC9914 From bruno at abstractj.org Wed Sep 14 06:11:18 2016 From: bruno at abstractj.org (Bruno Oliveira da Silva) Date: Wed, 14 Sep 2016 07:11:18 -0300 Subject: [keycloak-dev] LDAP setup for demonstration purposes In-Reply-To: References: <22e0bfbe-2824-07e1-83a1-92f643b4587c@redhat.com> <20160913143925.GE14904@abstractj.org> <8A76F607-BCD2-4DD8-94B5-9EE4BAD36665@smartling.com> <20160913191028.GA6881@abstractj.org> <10079fce-87f3-b991-551d-ad11f3a79261@redhat.com> Message-ID: <20160914101118.GB10342@abstractj.org> +1 Not arguing in favor or against it, but thinking about what you described seems like the solution is the combination of both: Vagrant and Docker. Do we have a Jira for this? On 2016-09-14, Stian Thorgersen wrote: > To elaborate I could eventually see us having a big demo setup in the form > of: > > * Keycloak or RH-SSO box > * Database box > * FreeIPA box > * Active Directory box > * Some SAML provider > * Some OIDC provider > * Fedora workstation > * Windows workstation > > Everything ready to go to show Keycloak as a fully capable identity > federation platform. > > On 14 September 2016 at 09:32, Stian Thorgersen wrote: > > > I want full desktop and show user login via desktop login, not Kerberos > > client. So full Gnome is required. Also, I think the DNS setup as well as > > orchestration may be simpler with Vagrant than Docker. > > > > We also may want to extend this to include good old Microsoft software in > > the form of Windows and Active Directory. In that case Docker is a show > > stopper and Vagrant/VMs is the only option. > > > > On 13 September 2016 at 21:46, Marek Posolda wrote: > > > >> On 13/09/16 21:10, Bruno Oliveira da Silva wrote: > >> > My 2 cents on it. Unless we have any strong argument for doing this, > >> > let's move forward with Docker. We already have a repository for this > >> > and I'm not sure if we have bandwidth to maintain 2 distinct > >> repositories. > >> > > >> > Btw I'm curious, which real world scenario you could not reproduce with > >> > Docker? > >> I guess SPNEGO login with Firefox is the example of that scenario? > >> > >> If you want workstation with Kerberos + SPNEGO, you will need to > >> configure kerberos client and your Firefox and then run FF inside docker > >> container and display it "locally" on your laptop. Or is it something > >> like the "propagation" of X from docker to your laptop possible? If yes, > >> then everything is doable with docker though. > >> > >> Marek > >> > >> > > >> > On 2016-09-13, Thomas Raehalme wrote: > >> >> How about setting up multiple VMs with Vagrant but handling all > >> software > >> >> components with Docker? > >> >> > >> >> Best of both worlds and also a simulation of the real world (which > >> could > >> >> perhaps be used as a reference). > >> >> > >> >> Best regards, > >> >> Thomas > >> >> > >> >> On Sep 13, 2016 5:46 PM, "Scott Rossillo" > >> wrote: > >> >> > >> >>> Vagrant leaves funny taste in my mouth. Docker Compose to orchestrate > >> >>> things seems like a better option. > >> >>> > >> >>> Scott Rossillo > >> >>> Smartling | Senior Software Engineer > >> >>> srossillo at smartling.com > >> >>> > >> >>> On Sep 13, 2016, at 10:39 AM, Bruno Oliveira da Silva < > >> bruno at abstractj.org> > >> >>> wrote: > >> >>> > >> >>> My question is: Docker or Vagrant? > >> >>> > >> >>> If we have plans to showcase SSSD Federation provider + things like > >> >>> start/stop sssd service to demonstrate the SSSD provider won't be > >> >>> enabled. I would say that Vagrant is easier and we can benefit from > >> >>> these boxes[1], otherwise we just stick with Marek's work. > >> >>> > >> >>> I will give DBus on Docker a second try, but last time I checked > >> wasn't > >> >>> fun. > >> >>> > >> >>> [1] - https://github.com/freeipa/freeipa-workshop > >> >>> > >> >>> On 2016-09-13, Stian Thorgersen wrote: > >> >>> > >> >>> Forgot to add two things: > >> >>> > >> >>> * DNS setup - we want proper DNS setup on the machines, which would be > >> >>> required for the Kerberos stuff to work properly > >> >>> * HTTPS - optional, but would be great if it also had HTTPS configured > >> >>> > >> >>> On 13 September 2016 at 09:24, Marek Posolda > >> wrote: > >> >>> > >> >>> +1 > >> >>> > >> >>> Few more things and tips (you may be already aware of them, but > >> still.. > >> >>> Hope some of them are useful :) : > >> >>> > >> >>> - My docker image [1] already contains FreeIPA server and Keycloak > >> server > >> >>> pre-configured with LDAP+Kerberos federation provider to use it. > >> Thing is > >> >>> that both Keycloak+FreeIPA are on same machine, which is likely not > >> the > >> >>> best for show production setup. The workstation setup needs to be > >> done on > >> >>> your local machine (so you need KErberos client + Firefox setup on > >> your > >> >>> laptop. That's sufficient for testing, but probably also not ideal for > >> >>> showcase). > >> >>> > >> >>> - In addition to FreeIPA docker images for server, FreeIPA has also > >> docker > >> >>> image for client setup. See for example [2] . I am not 100% sure, but > >> I > >> >>> believe that if you run this docker image and point to the already > >> running > >> >>> "server" image, you will gain also all the things like PAM setup, > >> login to > >> >>> the workstation with Kerberos credentials, and automatically retrieved > >> >>> kerberos ticket during login. Hence you just login to workstation, > >> open > >> >>> firefox and you are authenticated to Keycloak. No need to manually run > >> >>> "kinit". > >> >>> > >> >>> > >> >>> The workstation will need to be a virtual machine rather than > >> container to > >> >>> add X support. So IMO we should just use Vagrant and have FreeIPA and > >> >>> use Vagrantfile to install Fedora + FreeIPA. > >> >>> > >> >>> > >> >>> > >> >>> - If Keycloak and FreeIPA server are on different workstations, then: > >> >>> -- The Keycloak server may also need FreeIPA client installed. Or at > >> least > >> >>> kerberos client installed with proper setup in /etc/krb5.conf > >> pointing to > >> >>> FreeIPA kerberos realm and proper DNS setup working with FreeIPA. > >> >>> > >> >>> > >> >>> > >> >>> -- Also for different servers, you will likely need to add HTTP > >> kerberos > >> >>> principal for the server where keycloak is running. For example if > >> FreeIPA > >> >>> is on "freeipa.example.org" and keycloak is on "keycloak.example.org > >> ", > >> >>> you will need the principal like HTTP/keycloak.example.org at KEYC > >> LOAK.ORG > >> >>> . > >> >>> This corresponds to LDAP principal under "cn=services,cn=accounts,dc= > >> >>> freeipa,dc=example,dc=org" > >> >>> . Maybe FreeIPA has it documented somewhere and/or it's easily > >> possible to > >> >>> add new HTTP server principal through FreeIPA admin console. You will > >> also > >> >>> need keytab exported with the credentials of this principal. > >> >>> Note this step is not needed if Keycloak and FreeIPA are on same > >> machine > >> >>> as FreeIPA server automatically has HTTP principal for it's own > >> machine > >> >>> (something like HTTP/freeipa.example.org at KEYCLOAK.ORG > >> >>> for the example > >> >>> above), to allow login to FreeIPA admin console with kerberos OOTB. > >> >>> > >> >>> > >> >>> We should really figure out how to do this on separate machines, so I > >> think > >> >>> going that way would be best even though it's harder to do. > >> >>> > >> >>> > >> >>> > >> >>> > >> >>> [1] https://github.com/mposolda/keycloak-freeipa-docker/ > >> >>> [2] https://github.com/adelton/docker-freeipa/tree/fedora-22-client > >> >>> > >> >>> Marek > >> >>> > >> >>> > >> >>> On 13/09/16 08:07, Stian Thorgersen wrote: > >> >>> > >> >>> I'd like to have a simple way to demo LDAP and Kerberos support. To > >> that > >> >>> end we should add a Vagrant setup with the following: > >> >>> > >> >>> * Keycloak server > >> >>> * MySQL or Postgres > >> >>> * FreeIPA > >> >>> * Workstation with Kerberos authentication (needs X and Firefox > >> installed) > >> >>> > >> >>> The Keycloak server should already be configured to use the FreeIPA > >> >>> server as a user federation provider (using LDAP and Kerberos). The > >> >>> workstation can be co-located with FreeIPA server if it makes things > >> much > >> >>> simpler, but it should be possible to login to the workstation with > >> >>> Kerberos. Firefox should be pre-configured for Kerberos to work both > >> on > >> >>> Keycloak login and FreeIPA admin console. > >> >>> > >> >>> I want a proper database and a web based client for the database so > >> it's > >> >>> simple to inspect the database. > >> >>> > >> >>> Bruno has already volunteered to look into this, but first we should > >> make > >> >>> sure this is the setup we'd like to be able to showcase. > >> >>> > >> >>> > >> >>> > >> >>> > >> >>> > >> >>> _______________________________________________ > >> >>> keycloak-dev mailing list > >> >>> keycloak-dev at lists.jboss.org > >> >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev > >> >>> > >> >>> > >> >>> > >> >>> -- > >> >>> > >> >>> abstractj > >> >>> PGP: 0x84DC9914 > >> >>> _______________________________________________ > >> >>> keycloak-dev mailing list > >> >>> keycloak-dev at lists.jboss.org > >> >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev > >> >>> > >> >>> > >> >>> > >> >>> _______________________________________________ > >> >>> keycloak-dev mailing list > >> >>> keycloak-dev at lists.jboss.org > >> >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev > >> >>> > >> > -- > >> > > >> > abstractj > >> > PGP: 0x84DC9914 > >> > _______________________________________________ > >> > keycloak-dev mailing list > >> > keycloak-dev at lists.jboss.org > >> > https://lists.jboss.org/mailman/listinfo/keycloak-dev > >> > >> > >> _______________________________________________ > >> keycloak-dev mailing list > >> keycloak-dev at lists.jboss.org > >> https://lists.jboss.org/mailman/listinfo/keycloak-dev > >> > > > > -- abstractj PGP: 0x84DC9914 From gostevning at gmail.com Wed Sep 14 06:38:26 2016 From: gostevning at gmail.com (=?UTF-8?Q?Geir_Ole_Hi=C3=A5sen_Stevning?=) Date: Wed, 14 Sep 2016 12:38:26 +0200 Subject: [keycloak-dev] Supporting date/time of consent in the model In-Reply-To: <5ff40380-7583-9932-33fa-9a9b34aee037@redhat.com> References: <5ff40380-7583-9932-33fa-9a9b34aee037@redhat.com> Message-ID: I like that solution, with 2 timestamps for create and lastUpdated + the admin view. I'll have a look at how much work and how fast I can get a PR up. On Tue, Sep 13, 2016 at 2:13 PM, Marek Posolda wrote: > +1 > > Will be also good to display timestamp in admin console IMO. > > The question is if it's sufficient to put date on UserConsentModel as in > scenario like: > - User authenticates in time1 and gives consent to client "foo" with 2 > roles and 2 protocol mappers > - In the meantime admin grants new role "bar" > - Another login in time2, user will need again to consent the newly added > role "bar" > > So should be timestamp set on time1 (when consent was created) or on time2 > (when there was last update) ? Or should we rather have 2 timestamps > ("createdDate" and "lastUpdateDate" )? Another possibility will be the > timestamp on every role and protocolMapper, but this looks like quite an > overhead. > > So maybe 2 timestamps for create and lastUpdate and display both in admin > console in "consents" tab table will be sufficient? > > Marek > > > On 13/09/16 10:51, Stian Thorgersen wrote: > > I've got no issues with us adding it. If you add it to the DTO-like > objects and implement support for both JPA and Mongo as well as add tests > for it I'd be happy to accept a PR. Would also need updates to the > Liquibase changelogs to add any required fields (assuming that's required). > > Marek - do you have any comments? > > On 13 September 2016 at 10:42, Geir Ole Hi?sen Stevning < > gostevning at gmail.com> wrote: > >> Hi! >> >> >> >> We have a use case where we need to know the time for when an End-User >> has given consent. Would it be possible to add a Date-like field in either >> UserConsentProtocolMapperEntity, UserConsentRoleEntity or >> UserConsentEntity, as we are using the JPA provider. >> >> >> >> Furthermore, propagate this field in the corresponding DTO-like objects >> as UserConsentModel etc. Doing this will probably mean that additional >> providers will need to populate the field, i.e. mongo. >> >> >> >> Is this something that you guys think is a good idea? I would be able to >> create a PR if you would like that. >> >> -- >> Geir Ole H. Stevning >> >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> > > > -- Geir Ole H. Stevning -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160914/b42963b9/attachment-0001.html From sthorger at redhat.com Wed Sep 14 07:09:48 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Wed, 14 Sep 2016 13:09:48 +0200 Subject: [keycloak-dev] Allow multiple users with the same email In-Reply-To: <1473839661.17958.9.camel@dma.dk> References: <1473837468.15209.29.camel@dma.dk> <1473839661.17958.9.camel@dma.dk> Message-ID: On 14 September 2016 at 09:54, Tomas Groth Christensen wrote: > Hi again, > > Thanks for the fast reply! > > ons, 14 09 2016 kl. 09:24 +0200, skrev Stian Thorgersen: > > We are planning to introduce support for contact email in the future. The > current email field is both a login and a contact email. As it's used for > login it has to be unique. > > > Do you have an approximate ETA for the contact email introduction? > Nope, wouldn't be until 2017 unless we get a community contribution. > > You could probably work around it with custom mappers for your IdPs that > map email to an attribute rather than the user email field. Then create a > custom email sender to use the contact attribute from the user rather than > email field. > > > While I can see that this would work, would this have any advantage over > the "custom-authenticator-that-deletes-existing-users-with-the-same-email" > approach I mentioned? In my view using the "delete" approach is > easier/faster to implement and would also requires fewer changes once the > contact-email is introduced. > Deleting existing users doesn't make any sense to me. You're loosing any changes for the user done through admin console or account management. You'll end up invalidation existing sessions (for example if a user wants to be logged-in concurrently from different IdPs). Another option you could look into is to have a protocol mapper that tunes the token depending on what IdP was used. That would allow account linking, but give different permissions based on how the user was authenticated. Ability to support multiple authentication levels is something we're also want to look at in 2017. > > Best regards, > Tomas > > > > [1] https://github.com/keycloak/keycloak/blob/master/ > services/src/main/java/org/keycloak/email/DefaultEmailSenderProvider.java > > On 14 September 2016 at 09:17, Tomas Groth Christensen wrote: > > Hi, > > I'm involved in a project where we use Keycloak as Identity Broker, and > so far we've been very happy with Keycloak, and implemented a few SPIs > to do some special things, but now we've hit a snag... > > In our setup we have many clients using the Identity Broker which then > again has many Identity Providers from which the user can chose one to > use for login. > Our problem is that the same user (using one email address) can exist > in 2 or more Identity Providers, and we do not want to link these > accounts. The reason for not linking the accounts is that the user can > be given special privileges in clients, based on which Identity > Provider the user comes from. These privileges should not be carried > over from one Identity Providers user to another since the same user > might be an administrator when coming the one Identity Provider and a > common user when coming from a different Identity Provider. > > So, is it possible to allow multiple users to have the same email > address? Looking at the source code there are checks for duplicated > user-emails in most places where users are created... Could a solution > be to implement a custom authenticator that replaces > IdpCreateUserIfUniqueAuthenticator which does not check for duplicated > emails, or are there database constraints that will prohibit this? > An alternative solution could perhaps be a custom authenticator that > simply deletes existing users with the same email address? > > I hope you can give me some pointer on how to proceed... > > > -- > Best regards, > Tomas Groth Christensen > Softwaredeveloper > Danish Maritime Authority > > > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160914/84a3de44/attachment.html From sthorger at redhat.com Wed Sep 14 07:12:29 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Wed, 14 Sep 2016 13:12:29 +0200 Subject: [keycloak-dev] LDAP setup for demonstration purposes In-Reply-To: <20160914101118.GB10342@abstractj.org> References: <22e0bfbe-2824-07e1-83a1-92f643b4587c@redhat.com> <20160913143925.GE14904@abstractj.org> <8A76F607-BCD2-4DD8-94B5-9EE4BAD36665@smartling.com> <20160913191028.GA6881@abstractj.org> <10079fce-87f3-b991-551d-ad11f3a79261@redhat.com> <20160914101118.GB10342@abstractj.org> Message-ID: We do now: https://issues.jboss.org/browse/KEYCLOAK-3577 On 14 September 2016 at 12:11, Bruno Oliveira da Silva wrote: > +1 Not arguing in favor or against it, but thinking about what you > described seems like the solution is the combination of both: Vagrant and > Docker. > > Do we have a Jira for this? > > On 2016-09-14, Stian Thorgersen wrote: > > To elaborate I could eventually see us having a big demo setup in the > form > > of: > > > > * Keycloak or RH-SSO box > > * Database box > > * FreeIPA box > > * Active Directory box > > * Some SAML provider > > * Some OIDC provider > > * Fedora workstation > > * Windows workstation > > > > Everything ready to go to show Keycloak as a fully capable identity > > federation platform. > > > > On 14 September 2016 at 09:32, Stian Thorgersen > wrote: > > > > > I want full desktop and show user login via desktop login, not Kerberos > > > client. So full Gnome is required. Also, I think the DNS setup as well > as > > > orchestration may be simpler with Vagrant than Docker. > > > > > > We also may want to extend this to include good old Microsoft software > in > > > the form of Windows and Active Directory. In that case Docker is a show > > > stopper and Vagrant/VMs is the only option. > > > > > > On 13 September 2016 at 21:46, Marek Posolda > wrote: > > > > > >> On 13/09/16 21:10, Bruno Oliveira da Silva wrote: > > >> > My 2 cents on it. Unless we have any strong argument for doing this, > > >> > let's move forward with Docker. We already have a repository for > this > > >> > and I'm not sure if we have bandwidth to maintain 2 distinct > > >> repositories. > > >> > > > >> > Btw I'm curious, which real world scenario you could not reproduce > with > > >> > Docker? > > >> I guess SPNEGO login with Firefox is the example of that scenario? > > >> > > >> If you want workstation with Kerberos + SPNEGO, you will need to > > >> configure kerberos client and your Firefox and then run FF inside > docker > > >> container and display it "locally" on your laptop. Or is it something > > >> like the "propagation" of X from docker to your laptop possible? If > yes, > > >> then everything is doable with docker though. > > >> > > >> Marek > > >> > > >> > > > >> > On 2016-09-13, Thomas Raehalme wrote: > > >> >> How about setting up multiple VMs with Vagrant but handling all > > >> software > > >> >> components with Docker? > > >> >> > > >> >> Best of both worlds and also a simulation of the real world (which > > >> could > > >> >> perhaps be used as a reference). > > >> >> > > >> >> Best regards, > > >> >> Thomas > > >> >> > > >> >> On Sep 13, 2016 5:46 PM, "Scott Rossillo" > > > >> wrote: > > >> >> > > >> >>> Vagrant leaves funny taste in my mouth. Docker Compose to > orchestrate > > >> >>> things seems like a better option. > > >> >>> > > >> >>> Scott Rossillo > > >> >>> Smartling | Senior Software Engineer > > >> >>> srossillo at smartling.com > > >> >>> > > >> >>> On Sep 13, 2016, at 10:39 AM, Bruno Oliveira da Silva < > > >> bruno at abstractj.org> > > >> >>> wrote: > > >> >>> > > >> >>> My question is: Docker or Vagrant? > > >> >>> > > >> >>> If we have plans to showcase SSSD Federation provider + things > like > > >> >>> start/stop sssd service to demonstrate the SSSD provider won't be > > >> >>> enabled. I would say that Vagrant is easier and we can benefit > from > > >> >>> these boxes[1], otherwise we just stick with Marek's work. > > >> >>> > > >> >>> I will give DBus on Docker a second try, but last time I checked > > >> wasn't > > >> >>> fun. > > >> >>> > > >> >>> [1] - https://github.com/freeipa/freeipa-workshop > > >> >>> > > >> >>> On 2016-09-13, Stian Thorgersen wrote: > > >> >>> > > >> >>> Forgot to add two things: > > >> >>> > > >> >>> * DNS setup - we want proper DNS setup on the machines, which > would be > > >> >>> required for the Kerberos stuff to work properly > > >> >>> * HTTPS - optional, but would be great if it also had HTTPS > configured > > >> >>> > > >> >>> On 13 September 2016 at 09:24, Marek Posolda > > > >> wrote: > > >> >>> > > >> >>> +1 > > >> >>> > > >> >>> Few more things and tips (you may be already aware of them, but > > >> still.. > > >> >>> Hope some of them are useful :) : > > >> >>> > > >> >>> - My docker image [1] already contains FreeIPA server and Keycloak > > >> server > > >> >>> pre-configured with LDAP+Kerberos federation provider to use it. > > >> Thing is > > >> >>> that both Keycloak+FreeIPA are on same machine, which is likely > not > > >> the > > >> >>> best for show production setup. The workstation setup needs to be > > >> done on > > >> >>> your local machine (so you need KErberos client + Firefox setup on > > >> your > > >> >>> laptop. That's sufficient for testing, but probably also not > ideal for > > >> >>> showcase). > > >> >>> > > >> >>> - In addition to FreeIPA docker images for server, FreeIPA has > also > > >> docker > > >> >>> image for client setup. See for example [2] . I am not 100% sure, > but > > >> I > > >> >>> believe that if you run this docker image and point to the already > > >> running > > >> >>> "server" image, you will gain also all the things like PAM setup, > > >> login to > > >> >>> the workstation with Kerberos credentials, and automatically > retrieved > > >> >>> kerberos ticket during login. Hence you just login to workstation, > > >> open > > >> >>> firefox and you are authenticated to Keycloak. No need to > manually run > > >> >>> "kinit". > > >> >>> > > >> >>> > > >> >>> The workstation will need to be a virtual machine rather than > > >> container to > > >> >>> add X support. So IMO we should just use Vagrant and have FreeIPA > and > > >> >>> use Vagrantfile to install Fedora + FreeIPA. > > >> >>> > > >> >>> > > >> >>> > > >> >>> - If Keycloak and FreeIPA server are on different workstations, > then: > > >> >>> -- The Keycloak server may also need FreeIPA client installed. Or > at > > >> least > > >> >>> kerberos client installed with proper setup in /etc/krb5.conf > > >> pointing to > > >> >>> FreeIPA kerberos realm and proper DNS setup working with FreeIPA. > > >> >>> > > >> >>> > > >> >>> > > >> >>> -- Also for different servers, you will likely need to add HTTP > > >> kerberos > > >> >>> principal for the server where keycloak is running. For example if > > >> FreeIPA > > >> >>> is on "freeipa.example.org" and keycloak is on " > keycloak.example.org > > >> ", > > >> >>> you will need the principal like HTTP/keycloak.example.org at KEYC > > >> LOAK.ORG > > >> >>> . > > >> >>> This corresponds to LDAP principal under > "cn=services,cn=accounts,dc= > > >> >>> freeipa,dc=example,dc=org" > > >> >>> . Maybe FreeIPA has it documented somewhere and/or it's easily > > >> possible to > > >> >>> add new HTTP server principal through FreeIPA admin console. You > will > > >> also > > >> >>> need keytab exported with the credentials of this principal. > > >> >>> Note this step is not needed if Keycloak and FreeIPA are on same > > >> machine > > >> >>> as FreeIPA server automatically has HTTP principal for it's own > > >> machine > > >> >>> (something like HTTP/freeipa.example.org at KEYCLOAK.ORG > > >> >>> for the example > > >> >>> above), to allow login to FreeIPA admin console with kerberos > OOTB. > > >> >>> > > >> >>> > > >> >>> We should really figure out how to do this on separate machines, > so I > > >> think > > >> >>> going that way would be best even though it's harder to do. > > >> >>> > > >> >>> > > >> >>> > > >> >>> > > >> >>> [1] https://github.com/mposolda/keycloak-freeipa-docker/ > > >> >>> [2] https://github.com/adelton/docker-freeipa/tree/fedora-22- > client > > >> >>> > > >> >>> Marek > > >> >>> > > >> >>> > > >> >>> On 13/09/16 08:07, Stian Thorgersen wrote: > > >> >>> > > >> >>> I'd like to have a simple way to demo LDAP and Kerberos support. > To > > >> that > > >> >>> end we should add a Vagrant setup with the following: > > >> >>> > > >> >>> * Keycloak server > > >> >>> * MySQL or Postgres > > >> >>> * FreeIPA > > >> >>> * Workstation with Kerberos authentication (needs X and Firefox > > >> installed) > > >> >>> > > >> >>> The Keycloak server should already be configured to use the > FreeIPA > > >> >>> server as a user federation provider (using LDAP and Kerberos). > The > > >> >>> workstation can be co-located with FreeIPA server if it makes > things > > >> much > > >> >>> simpler, but it should be possible to login to the workstation > with > > >> >>> Kerberos. Firefox should be pre-configured for Kerberos to work > both > > >> on > > >> >>> Keycloak login and FreeIPA admin console. > > >> >>> > > >> >>> I want a proper database and a web based client for the database > so > > >> it's > > >> >>> simple to inspect the database. > > >> >>> > > >> >>> Bruno has already volunteered to look into this, but first we > should > > >> make > > >> >>> sure this is the setup we'd like to be able to showcase. > > >> >>> > > >> >>> > > >> >>> > > >> >>> > > >> >>> > > >> >>> _______________________________________________ > > >> >>> keycloak-dev mailing list > > >> >>> keycloak-dev at lists.jboss.org > > >> >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev > > >> >>> > > >> >>> > > >> >>> > > >> >>> -- > > >> >>> > > >> >>> abstractj > > >> >>> PGP: 0x84DC9914 > > >> >>> _______________________________________________ > > >> >>> keycloak-dev mailing list > > >> >>> keycloak-dev at lists.jboss.org > > >> >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev > > >> >>> > > >> >>> > > >> >>> > > >> >>> _______________________________________________ > > >> >>> keycloak-dev mailing list > > >> >>> keycloak-dev at lists.jboss.org > > >> >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev > > >> >>> > > >> > -- > > >> > > > >> > abstractj > > >> > PGP: 0x84DC9914 > > >> > _______________________________________________ > > >> > keycloak-dev mailing list > > >> > keycloak-dev at lists.jboss.org > > >> > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > >> > > >> > > >> _______________________________________________ > > >> keycloak-dev mailing list > > >> keycloak-dev at lists.jboss.org > > >> https://lists.jboss.org/mailman/listinfo/keycloak-dev > > >> > > > > > > > > -- > > abstractj > PGP: 0x84DC9914 > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160914/2b2fb3b8/attachment-0001.html From sthorger at redhat.com Wed Sep 14 07:13:10 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Wed, 14 Sep 2016 13:13:10 +0200 Subject: [keycloak-dev] LDAP setup for demonstration purposes In-Reply-To: References: <22e0bfbe-2824-07e1-83a1-92f643b4587c@redhat.com> <20160913143925.GE14904@abstractj.org> <8A76F607-BCD2-4DD8-94B5-9EE4BAD36665@smartling.com> <20160913191028.GA6881@abstractj.org> <10079fce-87f3-b991-551d-ad11f3a79261@redhat.com> <20160914101118.GB10342@abstractj.org> Message-ID: Bruno - notice the missing fix version! It's a nice to have background task and not a high priority at the moment. On 14 September 2016 at 13:12, Stian Thorgersen wrote: > We do now: > https://issues.jboss.org/browse/KEYCLOAK-3577 > > On 14 September 2016 at 12:11, Bruno Oliveira da Silva < > bruno at abstractj.org> wrote: > >> +1 Not arguing in favor or against it, but thinking about what you >> described seems like the solution is the combination of both: Vagrant and >> Docker. >> >> Do we have a Jira for this? >> >> On 2016-09-14, Stian Thorgersen wrote: >> > To elaborate I could eventually see us having a big demo setup in the >> form >> > of: >> > >> > * Keycloak or RH-SSO box >> > * Database box >> > * FreeIPA box >> > * Active Directory box >> > * Some SAML provider >> > * Some OIDC provider >> > * Fedora workstation >> > * Windows workstation >> > >> > Everything ready to go to show Keycloak as a fully capable identity >> > federation platform. >> > >> > On 14 September 2016 at 09:32, Stian Thorgersen >> wrote: >> > >> > > I want full desktop and show user login via desktop login, not >> Kerberos >> > > client. So full Gnome is required. Also, I think the DNS setup as >> well as >> > > orchestration may be simpler with Vagrant than Docker. >> > > >> > > We also may want to extend this to include good old Microsoft >> software in >> > > the form of Windows and Active Directory. In that case Docker is a >> show >> > > stopper and Vagrant/VMs is the only option. >> > > >> > > On 13 September 2016 at 21:46, Marek Posolda >> wrote: >> > > >> > >> On 13/09/16 21:10, Bruno Oliveira da Silva wrote: >> > >> > My 2 cents on it. Unless we have any strong argument for doing >> this, >> > >> > let's move forward with Docker. We already have a repository for >> this >> > >> > and I'm not sure if we have bandwidth to maintain 2 distinct >> > >> repositories. >> > >> > >> > >> > Btw I'm curious, which real world scenario you could not reproduce >> with >> > >> > Docker? >> > >> I guess SPNEGO login with Firefox is the example of that scenario? >> > >> >> > >> If you want workstation with Kerberos + SPNEGO, you will need to >> > >> configure kerberos client and your Firefox and then run FF inside >> docker >> > >> container and display it "locally" on your laptop. Or is it something >> > >> like the "propagation" of X from docker to your laptop possible? If >> yes, >> > >> then everything is doable with docker though. >> > >> >> > >> Marek >> > >> >> > >> > >> > >> > On 2016-09-13, Thomas Raehalme wrote: >> > >> >> How about setting up multiple VMs with Vagrant but handling all >> > >> software >> > >> >> components with Docker? >> > >> >> >> > >> >> Best of both worlds and also a simulation of the real world (which >> > >> could >> > >> >> perhaps be used as a reference). >> > >> >> >> > >> >> Best regards, >> > >> >> Thomas >> > >> >> >> > >> >> On Sep 13, 2016 5:46 PM, "Scott Rossillo" < >> srossillo at smartling.com> >> > >> wrote: >> > >> >> >> > >> >>> Vagrant leaves funny taste in my mouth. Docker Compose to >> orchestrate >> > >> >>> things seems like a better option. >> > >> >>> >> > >> >>> Scott Rossillo >> > >> >>> Smartling | Senior Software Engineer >> > >> >>> srossillo at smartling.com >> > >> >>> >> > >> >>> On Sep 13, 2016, at 10:39 AM, Bruno Oliveira da Silva < >> > >> bruno at abstractj.org> >> > >> >>> wrote: >> > >> >>> >> > >> >>> My question is: Docker or Vagrant? >> > >> >>> >> > >> >>> If we have plans to showcase SSSD Federation provider + things >> like >> > >> >>> start/stop sssd service to demonstrate the SSSD provider won't be >> > >> >>> enabled. I would say that Vagrant is easier and we can benefit >> from >> > >> >>> these boxes[1], otherwise we just stick with Marek's work. >> > >> >>> >> > >> >>> I will give DBus on Docker a second try, but last time I checked >> > >> wasn't >> > >> >>> fun. >> > >> >>> >> > >> >>> [1] - https://github.com/freeipa/freeipa-workshop >> > >> >>> >> > >> >>> On 2016-09-13, Stian Thorgersen wrote: >> > >> >>> >> > >> >>> Forgot to add two things: >> > >> >>> >> > >> >>> * DNS setup - we want proper DNS setup on the machines, which >> would be >> > >> >>> required for the Kerberos stuff to work properly >> > >> >>> * HTTPS - optional, but would be great if it also had HTTPS >> configured >> > >> >>> >> > >> >>> On 13 September 2016 at 09:24, Marek Posolda < >> mposolda at redhat.com> >> > >> wrote: >> > >> >>> >> > >> >>> +1 >> > >> >>> >> > >> >>> Few more things and tips (you may be already aware of them, but >> > >> still.. >> > >> >>> Hope some of them are useful :) : >> > >> >>> >> > >> >>> - My docker image [1] already contains FreeIPA server and >> Keycloak >> > >> server >> > >> >>> pre-configured with LDAP+Kerberos federation provider to use it. >> > >> Thing is >> > >> >>> that both Keycloak+FreeIPA are on same machine, which is likely >> not >> > >> the >> > >> >>> best for show production setup. The workstation setup needs to be >> > >> done on >> > >> >>> your local machine (so you need KErberos client + Firefox setup >> on >> > >> your >> > >> >>> laptop. That's sufficient for testing, but probably also not >> ideal for >> > >> >>> showcase). >> > >> >>> >> > >> >>> - In addition to FreeIPA docker images for server, FreeIPA has >> also >> > >> docker >> > >> >>> image for client setup. See for example [2] . I am not 100% >> sure, but >> > >> I >> > >> >>> believe that if you run this docker image and point to the >> already >> > >> running >> > >> >>> "server" image, you will gain also all the things like PAM setup, >> > >> login to >> > >> >>> the workstation with Kerberos credentials, and automatically >> retrieved >> > >> >>> kerberos ticket during login. Hence you just login to >> workstation, >> > >> open >> > >> >>> firefox and you are authenticated to Keycloak. No need to >> manually run >> > >> >>> "kinit". >> > >> >>> >> > >> >>> >> > >> >>> The workstation will need to be a virtual machine rather than >> > >> container to >> > >> >>> add X support. So IMO we should just use Vagrant and have >> FreeIPA and >> > >> >>> use Vagrantfile to install Fedora + FreeIPA. >> > >> >>> >> > >> >>> >> > >> >>> >> > >> >>> - If Keycloak and FreeIPA server are on different workstations, >> then: >> > >> >>> -- The Keycloak server may also need FreeIPA client installed. >> Or at >> > >> least >> > >> >>> kerberos client installed with proper setup in /etc/krb5.conf >> > >> pointing to >> > >> >>> FreeIPA kerberos realm and proper DNS setup working with FreeIPA. >> > >> >>> >> > >> >>> >> > >> >>> >> > >> >>> -- Also for different servers, you will likely need to add HTTP >> > >> kerberos >> > >> >>> principal for the server where keycloak is running. For example >> if >> > >> FreeIPA >> > >> >>> is on "freeipa.example.org" and keycloak is on " >> keycloak.example.org >> > >> ", >> > >> >>> you will need the principal like HTTP/keycloak.example.org at KEYC >> > >> LOAK.ORG >> > >> >>> . >> > >> >>> This corresponds to LDAP principal under >> "cn=services,cn=accounts,dc= >> > >> >>> freeipa,dc=example,dc=org" >> > >> >>> . Maybe FreeIPA has it documented somewhere and/or it's easily >> > >> possible to >> > >> >>> add new HTTP server principal through FreeIPA admin console. You >> will >> > >> also >> > >> >>> need keytab exported with the credentials of this principal. >> > >> >>> Note this step is not needed if Keycloak and FreeIPA are on same >> > >> machine >> > >> >>> as FreeIPA server automatically has HTTP principal for it's own >> > >> machine >> > >> >>> (something like HTTP/freeipa.example.org at KEYCLOAK.ORG >> > >> >>> for the example >> > >> >>> above), to allow login to FreeIPA admin console with kerberos >> OOTB. >> > >> >>> >> > >> >>> >> > >> >>> We should really figure out how to do this on separate machines, >> so I >> > >> think >> > >> >>> going that way would be best even though it's harder to do. >> > >> >>> >> > >> >>> >> > >> >>> >> > >> >>> >> > >> >>> [1] https://github.com/mposolda/keycloak-freeipa-docker/ >> > >> >>> [2] https://github.com/adelton/docker-freeipa/tree/fedora-22-cli >> ent >> > >> >>> >> > >> >>> Marek >> > >> >>> >> > >> >>> >> > >> >>> On 13/09/16 08:07, Stian Thorgersen wrote: >> > >> >>> >> > >> >>> I'd like to have a simple way to demo LDAP and Kerberos support. >> To >> > >> that >> > >> >>> end we should add a Vagrant setup with the following: >> > >> >>> >> > >> >>> * Keycloak server >> > >> >>> * MySQL or Postgres >> > >> >>> * FreeIPA >> > >> >>> * Workstation with Kerberos authentication (needs X and Firefox >> > >> installed) >> > >> >>> >> > >> >>> The Keycloak server should already be configured to use the >> FreeIPA >> > >> >>> server as a user federation provider (using LDAP and Kerberos). >> The >> > >> >>> workstation can be co-located with FreeIPA server if it makes >> things >> > >> much >> > >> >>> simpler, but it should be possible to login to the workstation >> with >> > >> >>> Kerberos. Firefox should be pre-configured for Kerberos to work >> both >> > >> on >> > >> >>> Keycloak login and FreeIPA admin console. >> > >> >>> >> > >> >>> I want a proper database and a web based client for the database >> so >> > >> it's >> > >> >>> simple to inspect the database. >> > >> >>> >> > >> >>> Bruno has already volunteered to look into this, but first we >> should >> > >> make >> > >> >>> sure this is the setup we'd like to be able to showcase. >> > >> >>> >> > >> >>> >> > >> >>> >> > >> >>> >> > >> >>> >> > >> >>> _______________________________________________ >> > >> >>> keycloak-dev mailing list >> > >> >>> keycloak-dev at lists.jboss.org >> > >> >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> > >> >>> >> > >> >>> >> > >> >>> >> > >> >>> -- >> > >> >>> >> > >> >>> abstractj >> > >> >>> PGP: 0x84DC9914 >> > >> >>> _______________________________________________ >> > >> >>> keycloak-dev mailing list >> > >> >>> keycloak-dev at lists.jboss.org >> > >> >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> > >> >>> >> > >> >>> >> > >> >>> >> > >> >>> _______________________________________________ >> > >> >>> keycloak-dev mailing list >> > >> >>> keycloak-dev at lists.jboss.org >> > >> >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> > >> >>> >> > >> > -- >> > >> > >> > >> > abstractj >> > >> > PGP: 0x84DC9914 >> > >> > _______________________________________________ >> > >> > keycloak-dev mailing list >> > >> > keycloak-dev at lists.jboss.org >> > >> > https://lists.jboss.org/mailman/listinfo/keycloak-dev >> > >> >> > >> >> > >> _______________________________________________ >> > >> keycloak-dev mailing list >> > >> keycloak-dev at lists.jboss.org >> > >> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> > >> >> > > >> > > >> >> -- >> >> abstractj >> PGP: 0x84DC9914 >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160914/3d38e77f/attachment-0001.html From bruno at abstractj.org Wed Sep 14 08:07:24 2016 From: bruno at abstractj.org (Bruno Oliveira da Silva) Date: Wed, 14 Sep 2016 09:07:24 -0300 Subject: [keycloak-dev] LDAP setup for demonstration purposes In-Reply-To: References: <20160913143925.GE14904@abstractj.org> <8A76F607-BCD2-4DD8-94B5-9EE4BAD36665@smartling.com> <20160913191028.GA6881@abstractj.org> <10079fce-87f3-b991-551d-ad11f3a79261@redhat.com> <20160914101118.GB10342@abstractj.org> Message-ID: <20160914120724.GA5168@abstractj.org> +1000 thank you! On 2016-09-14, Stian Thorgersen wrote: > Bruno - notice the missing fix version! It's a nice to have background task > and not a high priority at the moment. > > On 14 September 2016 at 13:12, Stian Thorgersen wrote: > > > We do now: > > https://issues.jboss.org/browse/KEYCLOAK-3577 > > > > On 14 September 2016 at 12:11, Bruno Oliveira da Silva < > > bruno at abstractj.org> wrote: > > > >> +1 Not arguing in favor or against it, but thinking about what you > >> described seems like the solution is the combination of both: Vagrant and > >> Docker. > >> > >> Do we have a Jira for this? > >> > >> On 2016-09-14, Stian Thorgersen wrote: > >> > To elaborate I could eventually see us having a big demo setup in the > >> form > >> > of: > >> > > >> > * Keycloak or RH-SSO box > >> > * Database box > >> > * FreeIPA box > >> > * Active Directory box > >> > * Some SAML provider > >> > * Some OIDC provider > >> > * Fedora workstation > >> > * Windows workstation > >> > > >> > Everything ready to go to show Keycloak as a fully capable identity > >> > federation platform. > >> > > >> > On 14 September 2016 at 09:32, Stian Thorgersen > >> wrote: > >> > > >> > > I want full desktop and show user login via desktop login, not > >> Kerberos > >> > > client. So full Gnome is required. Also, I think the DNS setup as > >> well as > >> > > orchestration may be simpler with Vagrant than Docker. > >> > > > >> > > We also may want to extend this to include good old Microsoft > >> software in > >> > > the form of Windows and Active Directory. In that case Docker is a > >> show > >> > > stopper and Vagrant/VMs is the only option. > >> > > > >> > > On 13 September 2016 at 21:46, Marek Posolda > >> wrote: > >> > > > >> > >> On 13/09/16 21:10, Bruno Oliveira da Silva wrote: > >> > >> > My 2 cents on it. Unless we have any strong argument for doing > >> this, > >> > >> > let's move forward with Docker. We already have a repository for > >> this > >> > >> > and I'm not sure if we have bandwidth to maintain 2 distinct > >> > >> repositories. > >> > >> > > >> > >> > Btw I'm curious, which real world scenario you could not reproduce > >> with > >> > >> > Docker? > >> > >> I guess SPNEGO login with Firefox is the example of that scenario? > >> > >> > >> > >> If you want workstation with Kerberos + SPNEGO, you will need to > >> > >> configure kerberos client and your Firefox and then run FF inside > >> docker > >> > >> container and display it "locally" on your laptop. Or is it something > >> > >> like the "propagation" of X from docker to your laptop possible? If > >> yes, > >> > >> then everything is doable with docker though. > >> > >> > >> > >> Marek > >> > >> > >> > >> > > >> > >> > On 2016-09-13, Thomas Raehalme wrote: > >> > >> >> How about setting up multiple VMs with Vagrant but handling all > >> > >> software > >> > >> >> components with Docker? > >> > >> >> > >> > >> >> Best of both worlds and also a simulation of the real world (which > >> > >> could > >> > >> >> perhaps be used as a reference). > >> > >> >> > >> > >> >> Best regards, > >> > >> >> Thomas > >> > >> >> > >> > >> >> On Sep 13, 2016 5:46 PM, "Scott Rossillo" < > >> srossillo at smartling.com> > >> > >> wrote: > >> > >> >> > >> > >> >>> Vagrant leaves funny taste in my mouth. Docker Compose to > >> orchestrate > >> > >> >>> things seems like a better option. > >> > >> >>> > >> > >> >>> Scott Rossillo > >> > >> >>> Smartling | Senior Software Engineer > >> > >> >>> srossillo at smartling.com > >> > >> >>> > >> > >> >>> On Sep 13, 2016, at 10:39 AM, Bruno Oliveira da Silva < > >> > >> bruno at abstractj.org> > >> > >> >>> wrote: > >> > >> >>> > >> > >> >>> My question is: Docker or Vagrant? > >> > >> >>> > >> > >> >>> If we have plans to showcase SSSD Federation provider + things > >> like > >> > >> >>> start/stop sssd service to demonstrate the SSSD provider won't be > >> > >> >>> enabled. I would say that Vagrant is easier and we can benefit > >> from > >> > >> >>> these boxes[1], otherwise we just stick with Marek's work. > >> > >> >>> > >> > >> >>> I will give DBus on Docker a second try, but last time I checked > >> > >> wasn't > >> > >> >>> fun. > >> > >> >>> > >> > >> >>> [1] - https://github.com/freeipa/freeipa-workshop > >> > >> >>> > >> > >> >>> On 2016-09-13, Stian Thorgersen wrote: > >> > >> >>> > >> > >> >>> Forgot to add two things: > >> > >> >>> > >> > >> >>> * DNS setup - we want proper DNS setup on the machines, which > >> would be > >> > >> >>> required for the Kerberos stuff to work properly > >> > >> >>> * HTTPS - optional, but would be great if it also had HTTPS > >> configured > >> > >> >>> > >> > >> >>> On 13 September 2016 at 09:24, Marek Posolda < > >> mposolda at redhat.com> > >> > >> wrote: > >> > >> >>> > >> > >> >>> +1 > >> > >> >>> > >> > >> >>> Few more things and tips (you may be already aware of them, but > >> > >> still.. > >> > >> >>> Hope some of them are useful :) : > >> > >> >>> > >> > >> >>> - My docker image [1] already contains FreeIPA server and > >> Keycloak > >> > >> server > >> > >> >>> pre-configured with LDAP+Kerberos federation provider to use it. > >> > >> Thing is > >> > >> >>> that both Keycloak+FreeIPA are on same machine, which is likely > >> not > >> > >> the > >> > >> >>> best for show production setup. The workstation setup needs to be > >> > >> done on > >> > >> >>> your local machine (so you need KErberos client + Firefox setup > >> on > >> > >> your > >> > >> >>> laptop. That's sufficient for testing, but probably also not > >> ideal for > >> > >> >>> showcase). > >> > >> >>> > >> > >> >>> - In addition to FreeIPA docker images for server, FreeIPA has > >> also > >> > >> docker > >> > >> >>> image for client setup. See for example [2] . I am not 100% > >> sure, but > >> > >> I > >> > >> >>> believe that if you run this docker image and point to the > >> already > >> > >> running > >> > >> >>> "server" image, you will gain also all the things like PAM setup, > >> > >> login to > >> > >> >>> the workstation with Kerberos credentials, and automatically > >> retrieved > >> > >> >>> kerberos ticket during login. Hence you just login to > >> workstation, > >> > >> open > >> > >> >>> firefox and you are authenticated to Keycloak. No need to > >> manually run > >> > >> >>> "kinit". > >> > >> >>> > >> > >> >>> > >> > >> >>> The workstation will need to be a virtual machine rather than > >> > >> container to > >> > >> >>> add X support. So IMO we should just use Vagrant and have > >> FreeIPA and > >> > >> >>> use Vagrantfile to install Fedora + FreeIPA. > >> > >> >>> > >> > >> >>> > >> > >> >>> > >> > >> >>> - If Keycloak and FreeIPA server are on different workstations, > >> then: > >> > >> >>> -- The Keycloak server may also need FreeIPA client installed. > >> Or at > >> > >> least > >> > >> >>> kerberos client installed with proper setup in /etc/krb5.conf > >> > >> pointing to > >> > >> >>> FreeIPA kerberos realm and proper DNS setup working with FreeIPA. > >> > >> >>> > >> > >> >>> > >> > >> >>> > >> > >> >>> -- Also for different servers, you will likely need to add HTTP > >> > >> kerberos > >> > >> >>> principal for the server where keycloak is running. For example > >> if > >> > >> FreeIPA > >> > >> >>> is on "freeipa.example.org" and keycloak is on " > >> keycloak.example.org > >> > >> ", > >> > >> >>> you will need the principal like HTTP/keycloak.example.org at KEYC > >> > >> LOAK.ORG > >> > >> >>> . > >> > >> >>> This corresponds to LDAP principal under > >> "cn=services,cn=accounts,dc= > >> > >> >>> freeipa,dc=example,dc=org" > >> > >> >>> . Maybe FreeIPA has it documented somewhere and/or it's easily > >> > >> possible to > >> > >> >>> add new HTTP server principal through FreeIPA admin console. You > >> will > >> > >> also > >> > >> >>> need keytab exported with the credentials of this principal. > >> > >> >>> Note this step is not needed if Keycloak and FreeIPA are on same > >> > >> machine > >> > >> >>> as FreeIPA server automatically has HTTP principal for it's own > >> > >> machine > >> > >> >>> (something like HTTP/freeipa.example.org at KEYCLOAK.ORG > >> > >> >>> for the example > >> > >> >>> above), to allow login to FreeIPA admin console with kerberos > >> OOTB. > >> > >> >>> > >> > >> >>> > >> > >> >>> We should really figure out how to do this on separate machines, > >> so I > >> > >> think > >> > >> >>> going that way would be best even though it's harder to do. > >> > >> >>> > >> > >> >>> > >> > >> >>> > >> > >> >>> > >> > >> >>> [1] https://github.com/mposolda/keycloak-freeipa-docker/ > >> > >> >>> [2] https://github.com/adelton/docker-freeipa/tree/fedora-22-cli > >> ent > >> > >> >>> > >> > >> >>> Marek > >> > >> >>> > >> > >> >>> > >> > >> >>> On 13/09/16 08:07, Stian Thorgersen wrote: > >> > >> >>> > >> > >> >>> I'd like to have a simple way to demo LDAP and Kerberos support. > >> To > >> > >> that > >> > >> >>> end we should add a Vagrant setup with the following: > >> > >> >>> > >> > >> >>> * Keycloak server > >> > >> >>> * MySQL or Postgres > >> > >> >>> * FreeIPA > >> > >> >>> * Workstation with Kerberos authentication (needs X and Firefox > >> > >> installed) > >> > >> >>> > >> > >> >>> The Keycloak server should already be configured to use the > >> FreeIPA > >> > >> >>> server as a user federation provider (using LDAP and Kerberos). > >> The > >> > >> >>> workstation can be co-located with FreeIPA server if it makes > >> things > >> > >> much > >> > >> >>> simpler, but it should be possible to login to the workstation > >> with > >> > >> >>> Kerberos. Firefox should be pre-configured for Kerberos to work > >> both > >> > >> on > >> > >> >>> Keycloak login and FreeIPA admin console. > >> > >> >>> > >> > >> >>> I want a proper database and a web based client for the database > >> so > >> > >> it's > >> > >> >>> simple to inspect the database. > >> > >> >>> > >> > >> >>> Bruno has already volunteered to look into this, but first we > >> should > >> > >> make > >> > >> >>> sure this is the setup we'd like to be able to showcase. > >> > >> >>> > >> > >> >>> > >> > >> >>> > >> > >> >>> > >> > >> >>> > >> > >> >>> _______________________________________________ > >> > >> >>> keycloak-dev mailing list > >> > >> >>> keycloak-dev at lists.jboss.org > >> > >> >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev > >> > >> >>> > >> > >> >>> > >> > >> >>> > >> > >> >>> -- > >> > >> >>> > >> > >> >>> abstractj > >> > >> >>> PGP: 0x84DC9914 > >> > >> >>> _______________________________________________ > >> > >> >>> keycloak-dev mailing list > >> > >> >>> keycloak-dev at lists.jboss.org > >> > >> >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev > >> > >> >>> > >> > >> >>> > >> > >> >>> > >> > >> >>> _______________________________________________ > >> > >> >>> keycloak-dev mailing list > >> > >> >>> keycloak-dev at lists.jboss.org > >> > >> >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev > >> > >> >>> > >> > >> > -- > >> > >> > > >> > >> > abstractj > >> > >> > PGP: 0x84DC9914 > >> > >> > _______________________________________________ > >> > >> > keycloak-dev mailing list > >> > >> > keycloak-dev at lists.jboss.org > >> > >> > https://lists.jboss.org/mailman/listinfo/keycloak-dev > >> > >> > >> > >> > >> > >> _______________________________________________ > >> > >> keycloak-dev mailing list > >> > >> keycloak-dev at lists.jboss.org > >> > >> https://lists.jboss.org/mailman/listinfo/keycloak-dev > >> > >> > >> > > > >> > > > >> > >> -- > >> > >> abstractj > >> PGP: 0x84DC9914 > >> > > > > -- abstractj PGP: 0x84DC9914 From tgc at dma.dk Wed Sep 14 08:50:00 2016 From: tgc at dma.dk (Tomas Groth Christensen) Date: Wed, 14 Sep 2016 12:50:00 +0000 Subject: [keycloak-dev] Allow multiple users with the same email In-Reply-To: References: <1473837468.15209.29.camel@dma.dk> <1473839661.17958.9.camel@dma.dk> Message-ID: <1473857400.17958.34.camel@dma.dk> ons, 14 09 2016 kl. 13:09 +0200, skrev Stian Thorgersen: > > > On 14 September 2016 at 09:54, Tomas Groth Christensen > wrote: > > Hi again, > > > > Thanks for the fast reply! > > > > ons, 14 09 2016 kl. 09:24 +0200, skrev Stian Thorgersen: > > > We are planning to introduce support for contact email in the > > > future. The current email field is both a login and a contact > > > email. As it's used for login it has to be unique. > > Do you have an approximate ETA for the contact email introduction? > > > Nope, wouldn't be until 2017 unless we get a community contribution. > ? Ok, we'll wait and will use a workaround until then. > > > > > You could probably work around it with custom mappers for your > > > IdPs that map email to an attribute rather than the user email > > > field. Then create a custom email sender to use the contact > > > attribute from the user rather than email field. > > While I can see that this would work, would this have any advantage > > over the "custom-authenticator-that-deletes-existing-users-with- > > the-same-email" approach I mentioned? In my view using the "delete" > > approach is easier/faster to implement and would also requires > > fewer changes once the contact-email is introduced. > > > Deleting existing users doesn't make any sense to me. You're loosing > any changes for the user done through admin console or account > management. You'll end up invalidation existing sessions (for example > if a user wants to be logged-in concurrently from different IdPs). Since the user information will come from Identity Providers that are expected to manage the user information and make sure it is correct and updated, overwriting "incoming" users should not be a problem in our case. For this reason we have also disabled account review in the first-login-flow. The invalidation of user sessions is of course a potential issue, which we will have to take into account. > > Another option you could look into is to have a protocol mapper that > tunes the token depending on what IdP was used. That would allow > account linking, but give different permissions based on how the user > was authenticated. Ability to support multiple authentication levels > is something we're also want to look at in 2017. > ? This could work, but for me it seems more complicated than the (admittedly crude) delete-approach. And it might leave us with a setup that won't be easily reverted back to keycloaks standard solutions, when they arrive, hopefully in 2017. 2017 looks to be an (another) exiting year for keycloak :) We will discuss this internally and decide on which approach to use. Thank you for your help and input so far! /Tomas From marc.boorshtein at tremolosecurity.com Wed Sep 14 13:16:37 2016 From: marc.boorshtein at tremolosecurity.com (Marc Boorshtein) Date: Wed, 14 Sep 2016 13:16:37 -0400 Subject: [keycloak-dev] Opinion on how secret the OIDC "client secret" should be? Message-ID: KC Team, Eric Chiang from CoreOS (cc'd on this email) and I have been talking on the Kubernetes sig-auth slack channel about how secret the "client secret" in OIDC should be. The context for the question is that Kubernetes' OIDC implementation uses the id_token as the bearer token (as opposed to the access_token) to avoid a round trip. Since the id_token should be short lived the question of how to get a new one using a refresh_token. The current solution is to give kubectl the refresh_token, the idp discovery url and the client id and secret: kubectl config set-credentials --auth-provider=oidc kubectl config set-credentials --auth-provider-args=idp-issuer-url=( issuer url ) kubectl config set-credentials --auth-provider-args=client_id=( your client id ) kubectl config set-credentials --auth-provider-args=client_secret=( your client secret ) kubectl config set-credentials --auth-provider-args=refresh-token=( your refresh token ) This way kubectl can get a new id_token once the possessed one expires. The question becomes does giving the client_secret directly to users become a security issue since its now a shared credential? Some issues I see are: 1. Rotation becomes harder - how many people have this? 2. While you can't generate an access_token with just this secret, you CAN impersonate an RP so if your are monitoring which RPs are making requests an attacker could generate excessive requests for a single RP even if those requests fail 3. Since most IdPs will generate some kind of back-end record for a request if you have the client id and secret you could more easily do a DoS attack by flooding the server with authenticated requestes for authentication What are your thoughts? Google provides an example asserting that the client secret ISN'T secret (reading through it I think the example contradicts its self) https://developers.google.com/api-client-library/python/auth/installed-app Thanks Marc Boorshtein CTO Tremolo Security marc.boorshtein at tremolosecurity.com Twitter - @mlbiam / @tremolosecurity From mauriciogiacomini at hotmail.com Wed Sep 14 14:12:28 2016 From: mauriciogiacomini at hotmail.com (=?iso-8859-1?Q?Maur=EDcio_Giacomini_Penteado?=) Date: Wed, 14 Sep 2016 18:12:28 +0000 Subject: [keycloak-dev] Keycloak Integration TestSuite FAILURE In-Reply-To: <20160914032252.GF6881@abstractj.org> References: , <20160914032252.GF6881@abstractj.org> Message-ID: Hi Bruno, thanks by your attention. I am trying do what you have explained but when I build the docker image it never adds my "dist/apache-maven" folder. You have already passed by it? I always got the error: ADD dist/apache-maven/ /opt/src/apache-maven/ lstat dist/apache-maven/: no such file or directory Kind regards ________________________________ De: Bruno Oliveira Enviado: quarta-feira, 14 de setembro de 2016 03:22 Para: Maur?cio Giacomini Penteado Cc: keycloak-dev at lists.jboss.org Assunto: Re: [keycloak-dev] Keycloak Integration TestSuite FAILURE Hi Mauricio, I couldn't reproduce your issue with the latest CentOS version. To make sure that we're discussing about the same environment, I built this docker image[1], just follow the instructions here[2] to run. I hope it helps. [1] - https://hub.docker.com/r/abstractj/keycloak-centos/ [2] - https://github.com/abstractj/docker/blob/centos/centos-java-dev/README.md On 2016-09-13, Maur?cio Giacomini Penteado wrote: > > I am trying build with a CentOS Linux release 7.2. > > I have already tried build the keycloak versions 2.0.0, 2.1.0 and 2.2.0 with OpenJDK and Oracle JDK. > > I just did a clone and performed a "mvn install". > > All my attempts result in the same errors: > > Keycloak Integration TestSuite FAILURE > > Failed tests: > JaxrsFilterTest.testCors:286 expected:<200> but was:<403> > JaxrsFilterTest.testRelativeUriAndPublicKey:172 expected:<500> but was:<401> > Tests in error: > JaxrsBasicAuthTest.testBasic:141 ? ClientError HTTP 403 Forbidden > JaxrsFilterTest.testBasic:141 ? ClientError HTTP 403 Forbidden > JaxrsFilterTest.testPushNotBefore:314 ? ClientError HTTP 403 Forbidden > JaxrsFilterTest.testResourceRoleMappings:236 ? ClientError HTTP 403 Forbidden > > Tests run: 414, Failures: 2, Errors: 4, Skipped: 32 > > = [ > > Somebody, please! > ________________________________ > De: Maur?cio Giacomini Penteado > Enviado: ter?a-feira, 13 de setembro de 2016 14:20 > Para: stian at redhat.com > Cc: keycloak-dev at lists.jboss.org > Assunto: Re: [keycloak-dev] Keycloak Integration TestSuite FAILURE > > > Hello Stian > > > I did a clone of master from Travis repository and to me the errors are the same = / > > > ________________________________ > De: Stian Thorgersen > Enviado: ter?a-feira, 13 de setembro de 2016 13:10 > Para: Maur?cio Giacomini Penteado > Cc: keycloak-dev at lists.jboss.org > Assunto: Re: [keycloak-dev] Keycloak Integration TestSuite FAILURE > > What steps do you run to build/test? Works on my box and also it works on Travis. > > On 13 September 2016 at 15:08, Maur?cio Giacomini Penteado > wrote: > > Hello everybody. > > All my attempts to build keycloak result in the same errors: > > Keycloak Integration TestSuite FAILURE > > Failed tests: > JaxrsFilterTest.testCors:286 expected:<200> but was:<403> > JaxrsFilterTest.testRelativeUriAndPublicKey:172 expected:<500> but was:<401> > Tests in error: > JaxrsBasicAuthTest.testBasic:141 ? ClientError HTTP 403 Forbidden > JaxrsFilterTest.testBasic:141 ? ClientError HTTP 403 Forbidden > JaxrsFilterTest.testPushNotBefore:314 ? ClientError HTTP 403 Forbidden > JaxrsFilterTest.testResourceRoleMappings:236 ? ClientError HTTP 403 Forbidden > > Tests run: 414, Failures: 2, Errors: 4, Skipped: 32 > > If somebody has an idea about what happens, please let me know! > > Kind regards, > Maur?cio. > > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev -- abstractj PGP: 0x84DC9914 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160914/47381be2/attachment-0001.html From marc.boorshtein at tremolosecurity.com Wed Sep 14 14:59:38 2016 From: marc.boorshtein at tremolosecurity.com (Marc Boorshtein) Date: Wed, 14 Sep 2016 14:59:38 -0400 Subject: [keycloak-dev] Opinion on how secret the OIDC "client secret" should be? In-Reply-To: References: Message-ID: Reposting on Eric's behalf On Sep 14, 2016 2:54 PM, "Eric Chiang" wrote: > Thanks Marc for the cc, > > Just to give some background for the reasoning behind this. > > Today the Kubernetes API server trusts ID Tokens issued to a single > client. Refreshing a token requires a client_secret, hence the flags Marc > provided in his example. Though we don't have official recommendations > about what the properties of the client passed in those flags should be > there's two obvious ways of going about this. > > 1) Have each kubectl share a client secret. Some authorization servers > provide mechanisms for declaring "public clients" to imposes restrictions > on its capabilities. For example Google, when it assumes client_secrets > aren't secret, restricts the redirect URLs for embedded apps to only > localhost and a magic OOB, doesn't let it do incremental authorization, > etc. Though as Marc noted this may have unintended consequences with > providers who assume this doesn't happen. > > 2) Another option is for kubectl to utilize the "azp" claim in the ID > Token[0], which allows clients to request ID Tokens on behalf of other > clients. This means each kubectl gets its own client_id and client_secret, > with each one requesting ID Tokens minted for a common client_id. However > that capability isn't generally supported by OIDC providers, though Google > does[1]. This is probably a more secure option, but the actual > implementations differ so widely that it becomes hard to make a general > statement. > > We'd be interested in knowing if either of these methods raise red flags > when combined with keycloak. > > Eric > > [0] https://openid.net/specs/openid-connect-core-1_0.html#IDToken > [1] https://developers.google.com/identity/protocols/CrossClientAuth > > > > On Wed, Sep 14, 2016 at 10:16 AM, Marc Boorshtein tremolosecurity.com> wrote: > >> KC Team, >> >> Eric Chiang from CoreOS (cc'd on this email) and I have been talking >> on the Kubernetes sig-auth slack channel about how secret the "client >> secret" in OIDC should be. The context for the question is that >> Kubernetes' OIDC implementation uses the id_token as the bearer token >> (as opposed to the access_token) to avoid a round trip. Since the >> id_token should be short lived the question of how to get a new one >> using a refresh_token. The current solution is to give kubectl the >> refresh_token, the idp discovery url and the client id and secret: >> >> kubectl config set-credentials --auth-provider=oidc >> kubectl config set-credentials --auth-provider-args=idp-issuer-url=( >> issuer url ) >> kubectl config set-credentials --auth-provider-args=client_id=( your >> client id ) >> kubectl config set-credentials --auth-provider-args=client_secret=( >> your client secret ) >> kubectl config set-credentials --auth-provider-args=refresh-token=( >> your refresh token ) >> >> This way kubectl can get a new id_token once the possessed one >> expires. The question becomes does giving the client_secret directly >> to users become a security issue since its now a shared credential? >> >> Some issues I see are: >> 1. Rotation becomes harder - how many people have this? >> 2. While you can't generate an access_token with just this secret, >> you CAN impersonate an RP so if your are monitoring which RPs are >> making requests an attacker could generate excessive requests for a >> single RP even if those requests fail >> 3. Since most IdPs will generate some kind of back-end record for a >> request if you have the client id and secret you could more easily do >> a DoS attack by flooding the server with authenticated requestes for >> authentication >> >> What are your thoughts? Google provides an example asserting that the >> client secret ISN'T secret (reading through it I think the example >> contradicts its self) >> https://developers.google.com/api-client-library/python/auth >> /installed-app >> >> Thanks >> >> >> Marc Boorshtein >> CTO Tremolo Security >> marc.boorshtein at tremolosecurity.com >> Twitter - @mlbiam / @tremolosecurity >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160914/ee8823ba/attachment.html From bruno at abstractj.org Wed Sep 14 17:29:33 2016 From: bruno at abstractj.org (Bruno Oliveira) Date: Wed, 14 Sep 2016 18:29:33 -0300 Subject: [keycloak-dev] Keycloak Integration TestSuite FAILURE In-Reply-To: References: <20160914032252.GF6881@abstractj.org> Message-ID: <20160914212933.GA18412@abstractj.org> Hi Maur?cio, you just have to copy the content of your downloaded Maven distribution. If you have any doubts, try this: git clone https://github.com/abstractj/docker.git && cd docker && git checkout centos && cd centos-java-dev/dist && curl http://mirror.nbtelecom.com.br/apache/maven/maven-3/3.3.9/binaries/apache-maven-3.3.9-bin.tar.gz | tar xvz && mv apache-maven-3.3.9 apache-maven && cd .. && sudo docker build -t keycloak-centos . I hope it helps. On 2016-09-14, Maur?cio Giacomini Penteado wrote: > > Hi Bruno, thanks by your attention. > > I am trying do what you have explained but when I build the docker image it never adds my "dist/apache-maven" folder. You have already passed by it? > > I always got the error: > ADD dist/apache-maven/ /opt/src/apache-maven/ > lstat dist/apache-maven/: no such file or directory > > Kind regards > > ________________________________ > De: Bruno Oliveira > Enviado: quarta-feira, 14 de setembro de 2016 03:22 > Para: Maur?cio Giacomini Penteado > Cc: keycloak-dev at lists.jboss.org > Assunto: Re: [keycloak-dev] Keycloak Integration TestSuite FAILURE > > Hi Mauricio, I couldn't reproduce your issue with the latest CentOS > version. To make sure that we're discussing about the same environment, > I built this docker image[1], just follow the instructions here[2] to run. > > I hope it helps. > > > [1] - https://hub.docker.com/r/abstractj/keycloak-centos/ > [2] - https://github.com/abstractj/docker/blob/centos/centos-java-dev/README.md > > On 2016-09-13, Maur?cio Giacomini Penteado wrote: > > > > I am trying build with a CentOS Linux release 7.2. > > > > I have already tried build the keycloak versions 2.0.0, 2.1.0 and 2.2.0 with OpenJDK and Oracle JDK. > > > > I just did a clone and performed a "mvn install". > > > > All my attempts result in the same errors: > > > > Keycloak Integration TestSuite FAILURE > > > > Failed tests: > > JaxrsFilterTest.testCors:286 expected:<200> but was:<403> > > JaxrsFilterTest.testRelativeUriAndPublicKey:172 expected:<500> but was:<401> > > Tests in error: > > JaxrsBasicAuthTest.testBasic:141 ? ClientError HTTP 403 Forbidden > > JaxrsFilterTest.testBasic:141 ? ClientError HTTP 403 Forbidden > > JaxrsFilterTest.testPushNotBefore:314 ? ClientError HTTP 403 Forbidden > > JaxrsFilterTest.testResourceRoleMappings:236 ? ClientError HTTP 403 Forbidden > > > > Tests run: 414, Failures: 2, Errors: 4, Skipped: 32 > > > > = [ > > > > Somebody, please! > > ________________________________ > > De: Maur?cio Giacomini Penteado > > Enviado: ter?a-feira, 13 de setembro de 2016 14:20 > > Para: stian at redhat.com > > Cc: keycloak-dev at lists.jboss.org > > Assunto: Re: [keycloak-dev] Keycloak Integration TestSuite FAILURE > > > > > > Hello Stian > > > > > > I did a clone of master from Travis repository and to me the errors are the same = / > > > > > > ________________________________ > > De: Stian Thorgersen > > Enviado: ter?a-feira, 13 de setembro de 2016 13:10 > > Para: Maur?cio Giacomini Penteado > > Cc: keycloak-dev at lists.jboss.org > > Assunto: Re: [keycloak-dev] Keycloak Integration TestSuite FAILURE > > > > What steps do you run to build/test? Works on my box and also it works on Travis. > > > > On 13 September 2016 at 15:08, Maur?cio Giacomini Penteado > wrote: > > > > Hello everybody. > > > > All my attempts to build keycloak result in the same errors: > > > > Keycloak Integration TestSuite FAILURE > > > > Failed tests: > > JaxrsFilterTest.testCors:286 expected:<200> but was:<403> > > JaxrsFilterTest.testRelativeUriAndPublicKey:172 expected:<500> but was:<401> > > Tests in error: > > JaxrsBasicAuthTest.testBasic:141 ? ClientError HTTP 403 Forbidden > > JaxrsFilterTest.testBasic:141 ? ClientError HTTP 403 Forbidden > > JaxrsFilterTest.testPushNotBefore:314 ? ClientError HTTP 403 Forbidden > > JaxrsFilterTest.testResourceRoleMappings:236 ? ClientError HTTP 403 Forbidden > > > > Tests run: 414, Failures: 2, Errors: 4, Skipped: 32 > > > > If somebody has an idea about what happens, please let me know! > > > > Kind regards, > > Maur?cio. > > > > > > _______________________________________________ > > keycloak-dev mailing list > > keycloak-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > > > _______________________________________________ > > keycloak-dev mailing list > > keycloak-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > -- > > abstractj > PGP: 0x84DC9914 -- abstractj PGP: 0x84DC9914 From thomas.darimont at googlemail.com Thu Sep 15 04:45:01 2016 From: thomas.darimont at googlemail.com (Thomas Darimont) Date: Thu, 15 Sep 2016 10:45:01 +0200 Subject: [keycloak-dev] Allow multiple users with the same email In-Reply-To: <1473857400.17958.34.camel@dma.dk> References: <1473837468.15209.29.camel@dma.dk> <1473839661.17958.9.camel@dma.dk> <1473857400.17958.34.camel@dma.dk> Message-ID: FYI the relevant JIRA issue is: KEYCLOAK-2141 - Contact email: https://issues.jboss.org/browse/KEYCLOAK-2141 Cheers, Thomas 2016-09-14 14:50 GMT+02:00 Tomas Groth Christensen : > ons, 14 09 2016 kl. 13:09 +0200, skrev Stian Thorgersen: > > > > > > On 14 September 2016 at 09:54, Tomas Groth Christensen > > wrote: > > > Hi again, > > > > > > Thanks for the fast reply! > > > > > > ons, 14 09 2016 kl. 09:24 +0200, skrev Stian Thorgersen: > > > > We are planning to introduce support for contact email in the > > > > future. The current email field is both a login and a contact > > > > email. As it's used for login it has to be unique. > > > Do you have an approximate ETA for the contact email introduction? > > > > > Nope, wouldn't be until 2017 unless we get a community contribution. > > > > Ok, we'll wait and will use a workaround until then. > > > > > > > > You could probably work around it with custom mappers for your > > > > IdPs that map email to an attribute rather than the user email > > > > field. Then create a custom email sender to use the contact > > > > attribute from the user rather than email field. > > > While I can see that this would work, would this have any advantage > > > over the "custom-authenticator-that-deletes-existing-users-with- > > > the-same-email" approach I mentioned? In my view using the "delete" > > > approach is easier/faster to implement and would also requires > > > fewer changes once the contact-email is introduced. > > > > > Deleting existing users doesn't make any sense to me. You're loosing > > any changes for the user done through admin console or account > > management. You'll end up invalidation existing sessions (for example > > if a user wants to be logged-in concurrently from different IdPs). > > Since the user information will come from Identity Providers that are > expected to manage the user information and make sure it is correct and > updated, overwriting "incoming" users should not be a problem in our > case. For this reason we have also disabled account review in the > first-login-flow. > The invalidation of user sessions is of course a potential issue, which > we will have to take into account. > > > > > Another option you could look into is to have a protocol mapper that > > tunes the token depending on what IdP was used. That would allow > > account linking, but give different permissions based on how the user > > was authenticated. Ability to support multiple authentication levels > > is something we're also want to look at in 2017. > > > > This could work, but for me it seems more complicated than the > (admittedly crude) delete-approach. And it might leave us with a setup > that won't be easily reverted back to keycloaks standard solutions, > when they arrive, hopefully in 2017. 2017 looks to be an (another) > exiting year for keycloak :) > > We will discuss this internally and decide on which approach to use. > Thank you for your help and input so far! > > /Tomas > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160915/2cafbdb9/attachment-0001.html From sthorger at redhat.com Thu Sep 15 10:09:22 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Thu, 15 Sep 2016 16:09:22 +0200 Subject: [keycloak-dev] Keycloak 2.2.0.Final released Message-ID: Final is out. Go grab it now! -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160915/a85d5d00/attachment.html From mauriciogiacomini at hotmail.com Thu Sep 15 10:31:12 2016 From: mauriciogiacomini at hotmail.com (=?iso-8859-1?Q?Maur=EDcio_Giacomini_Penteado?=) Date: Thu, 15 Sep 2016 14:31:12 +0000 Subject: [keycloak-dev] Keycloak Integration TestSuite FAILURE In-Reply-To: <20160914212933.GA18412@abstractj.org> References: <20160914032252.GF6881@abstractj.org> , <20160914212933.GA18412@abstractj.org> Message-ID: Hi Bruno Following the instructions you described, all works well. Thank you so much! ________________________________ De: Bruno Oliveira Enviado: quarta-feira, 14 de setembro de 2016 21:29 Para: Maur?cio Giacomini Penteado Cc: keycloak-dev at lists.jboss.org Assunto: Re: [keycloak-dev] Keycloak Integration TestSuite FAILURE Hi Maur?cio, you just have to copy the content of your downloaded Maven distribution. If you have any doubts, try this: git clone https://github.com/abstractj/docker.git && abstractj/docker github.com docker - Docker files crafted with love cd docker && git checkout centos && cd centos-java-dev/dist && curl http://mirror.nbtelecom.com.br/apache/maven/maven-3/3.3.9/binaries/apache-maven-3.3.9-bin.tar.gz | tar xvz && mv apache-maven-3.3.9 apache-maven && cd .. && sudo docker build -t keycloak-centos . I hope it helps. On 2016-09-14, Maur?cio Giacomini Penteado wrote: > > Hi Bruno, thanks by your attention. > > I am trying do what you have explained but when I build the docker image it never adds my "dist/apache-maven" folder. You have already passed by it? > > I always got the error: > ADD dist/apache-maven/ /opt/src/apache-maven/ > lstat dist/apache-maven/: no such file or directory > > Kind regards > > ________________________________ > De: Bruno Oliveira > Enviado: quarta-feira, 14 de setembro de 2016 03:22 > Para: Maur?cio Giacomini Penteado > Cc: keycloak-dev at lists.jboss.org > Assunto: Re: [keycloak-dev] Keycloak Integration TestSuite FAILURE > > Hi Mauricio, I couldn't reproduce your issue with the latest CentOS > version. To make sure that we're discussing about the same environment, > I built this docker image[1], just follow the instructions here[2] to run. > > I hope it helps. > > > [1] - https://hub.docker.com/r/abstractj/keycloak-centos/ > [2] - https://github.com/abstractj/docker/blob/centos/centos-java-dev/README.md > > On 2016-09-13, Maur?cio Giacomini Penteado wrote: > > > > I am trying build with a CentOS Linux release 7.2. > > > > I have already tried build the keycloak versions 2.0.0, 2.1.0 and 2.2.0 with OpenJDK and Oracle JDK. > > > > I just did a clone and performed a "mvn install". > > > > All my attempts result in the same errors: > > > > Keycloak Integration TestSuite FAILURE > > > > Failed tests: > > JaxrsFilterTest.testCors:286 expected:<200> but was:<403> > > JaxrsFilterTest.testRelativeUriAndPublicKey:172 expected:<500> but was:<401> > > Tests in error: > > JaxrsBasicAuthTest.testBasic:141 ? ClientError HTTP 403 Forbidden > > JaxrsFilterTest.testBasic:141 ? ClientError HTTP 403 Forbidden > > JaxrsFilterTest.testPushNotBefore:314 ? ClientError HTTP 403 Forbidden > > JaxrsFilterTest.testResourceRoleMappings:236 ? ClientError HTTP 403 Forbidden > > > > Tests run: 414, Failures: 2, Errors: 4, Skipped: 32 > > > > = [ > > > > Somebody, please! > > ________________________________ > > De: Maur?cio Giacomini Penteado > > Enviado: ter?a-feira, 13 de setembro de 2016 14:20 > > Para: stian at redhat.com > > Cc: keycloak-dev at lists.jboss.org > > Assunto: Re: [keycloak-dev] Keycloak Integration TestSuite FAILURE > > > > > > Hello Stian > > > > > > I did a clone of master from Travis repository and to me the errors are the same = / > > > > > > ________________________________ > > De: Stian Thorgersen > > Enviado: ter?a-feira, 13 de setembro de 2016 13:10 > > Para: Maur?cio Giacomini Penteado > > Cc: keycloak-dev at lists.jboss.org > > Assunto: Re: [keycloak-dev] Keycloak Integration TestSuite FAILURE > > > > What steps do you run to build/test? Works on my box and also it works on Travis. > > > > On 13 September 2016 at 15:08, Maur?cio Giacomini Penteado > wrote: > > > > Hello everybody. > > > > All my attempts to build keycloak result in the same errors: > > > > Keycloak Integration TestSuite FAILURE > > > > Failed tests: > > JaxrsFilterTest.testCors:286 expected:<200> but was:<403> > > JaxrsFilterTest.testRelativeUriAndPublicKey:172 expected:<500> but was:<401> > > Tests in error: > > JaxrsBasicAuthTest.testBasic:141 ? ClientError HTTP 403 Forbidden > > JaxrsFilterTest.testBasic:141 ? ClientError HTTP 403 Forbidden > > JaxrsFilterTest.testPushNotBefore:314 ? ClientError HTTP 403 Forbidden > > JaxrsFilterTest.testResourceRoleMappings:236 ? ClientError HTTP 403 Forbidden > > > > Tests run: 414, Failures: 2, Errors: 4, Skipped: 32 > > > > If somebody has an idea about what happens, please let me know! > > > > Kind regards, > > Maur?cio. > > > > > > _______________________________________________ > > keycloak-dev mailing list > > keycloak-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > > > _______________________________________________ > > keycloak-dev mailing list > > keycloak-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > -- > > abstractj > PGP: 0x84DC9914 -- abstractj PGP: 0x84DC9914 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160915/2b3bfbcb/attachment.html From shmuein+keycloak-dev at gmail.com Thu Sep 15 11:05:31 2016 From: shmuein+keycloak-dev at gmail.com (Muein Muzamil) Date: Thu, 15 Sep 2016 10:05:31 -0500 Subject: [keycloak-dev] Accessing SAML Request attributes in Authenticaors In-Reply-To: References: Message-ID: Hi all, Not sure if my question was clear enough, feel free to ask for clarifications if needed. I will really appreciate some response on this. Best regards, Muein On Tue, Sep 13, 2016 at 10:29 AM, Muein Muzamil < shmuein+keycloak-dev at gmail.com> wrote: > Hi all, > > Any pointers to this? I was looking at the SAMLAuthNRequestParser class > and it seems we are parsing the subject from the incoming request. Now the > question is how can I access it in my custom authenticator? > > else if (JBossSAMLConstants.SUBJECT.get().equals(elementName)) { > authnRequest.setSubject(getSubject(xmlEventReader)); > } > > Regards, > Muein > > On Fri, Sep 9, 2016 at 3:20 PM, Muein Muzamil com> wrote: > >> Hi all, >> >> We are trying to integrate with an SP which sends Subject/NameID in the >> Saml Request (copying example below). I have couple of questions in this >> regard >> >> >> 1. In our custom authenticator, we want to access this NameId and >> want to pre-fill username field based on this. Can you please guide me how >> can I do that. >> 2. Secondly, I am currently using KeyCloak JBoss Adapter for my >> sample SP, does the SAML Adapter supports sending nameId in SAML request? >> >> > IssueInstant="2016-02-24T15:45:55.325Z" >> ID="ID112bf5b0e4169930b663f2d89e62c521fc2f1b8133598fa2ff" >> xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"> >> >> http://pi >> ngone.com/xxx/640d3755-e080-4a87-8f7f-91795e78c08d >> >> jdoe at mysecureauthentication.com >> >> >> >> >> Regards, >> Muein >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160915/7e6a31c6/attachment-0001.html From sblanc at redhat.com Fri Sep 16 04:24:51 2016 From: sblanc at redhat.com (Sebastien Blanc) Date: Fri, 16 Sep 2016 10:24:51 +0200 Subject: [keycloak-dev] Ideas for the JavaOne's KeyCloak Hackengarten Message-ID: Hi ! Next week I will be at JavaOne, during the week I will have the privilege to lead for an afternoon the hackergarten area. For sure, I would like to bring up the KeyCloak project (along with Forge and maybe Swarm). For those who don't know what an hackergarten is : http://hackergarten.net/ So, do we have any JIRAs, docs , tests missing that would fit for a 3 hours hacker session ? My own ideas : - Work on the Keycloak Forge Addon : Create Clients from Forge etc ... - Start exploring a Keycloak Go Adapter - Polish Java Adapter Documentation I wait for your ideas ! Sebi -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160916/0092eb64/attachment.html From bruno at abstractj.org Fri Sep 16 05:21:02 2016 From: bruno at abstractj.org (Bruno Oliveira) Date: Fri, 16 Sep 2016 06:21:02 -0300 Subject: [keycloak-dev] Integration tests for FreeIPA In-Reply-To: References: <20160912210202.GA24692@abstractj.org> Message-ID: <20160916092101.GC29676@abstractj.org> Hi Stian, I prepared something with Docker compose[1]. Do you think it should be moved to some Keycloak repo? [1] - https://github.com/abstractj/docker/blob/master/keycloak-sssd-integration-tests/README.md On 2016-09-13, Stian Thorgersen wrote: > +1 Main thing is we need it to run on Central CI. If you can also make it > easy to run it on a workstation that'd be great. Maybe with a Docker image? > > Even if you could manage to get it running on Travis we'd probably not want > to as there's a tradeoff on how long it takes to test a PR and the amount > of tests to run. > > On 13 September 2016 at 04:42, Marek Posolda wrote: > > > Hi Bruno, > > > > the question is if we really need FreeIPA on Travis CI? The thing is > > that Travis is currently just the CI for run "mvn clean install" when > > you send PR to find regressions early. However we have already lots of > > tests, which are not executed during default travis build. For example: > > - Adapter tests in new testsuite. > > - Tests with Keycloak on real Wildfly server (by default testsuite uses > > just embedded undertow) > > - Test with other DBs than embedded H2 > > - Test with other LDAPs than embedded ApacheDS > > > > IMO It's fine if FreeIPA tests are executed just when you run the build > > with some special maven profile. Hence we will have job on central CI, > > which will test FreeIPA on daily basis. However those tests won't be > > executed during default "mvn clean install" build and hence also not > > executed on travis during every build. So defacto approach 1 from what > > you mentioned. > > > > But maybe it's just me :) > > > > Marek > > > > On 12/09/16 23:02, Bruno Oliveira wrote: > > > Ahoy, this week I will start to look at the integration tests for > > > FreeIPA/SSSD with Ilya from QE. He already started some work here[1]. > > > The tricky part for me is to spin up a FreeIPA server on Travis CI. > > > > > > For those not familiar with this environment, to run the > > > integration tests, freeipa-server must be installed/configured. > > > Unfortunately, Ubuntu Precise (the distro running on Travis) > > > have only freeipa-client and python-freeipa[2]. > > > > > > Some ideas to make this happen: > > > > > > 1. Do nothing and let people run the integration tests locally. This is > > not awesome. > > > 2. Spin up a FreeIPA docker instance on Travis before the build, plus > > > install and configure a freeipa-client. The downside is: more steps, > > > more slowness on Travis. > > > 3. Move the CI to our own server and have FreeIPA installed and > > > configured. > > > > > > Ideas? > > > > > > [1] - https://github.com/abstractj/keycloak/commit/ > > 534569a9b6082a9674a33149519b06d1218d4807 > > > [2] - https://launchpad.net/ubuntu/precise/+source/freeipa > > > > > > -- > > > > > > abstractj > > > PGP: 0x84DC9914 > > > _______________________________________________ > > > keycloak-dev mailing list > > > keycloak-dev at lists.jboss.org > > > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > > > > _______________________________________________ > > keycloak-dev mailing list > > keycloak-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > -- abstractj PGP: 0x84DC9914 From sthorger at redhat.com Fri Sep 16 06:38:58 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Fri, 16 Sep 2016 12:38:58 +0200 Subject: [keycloak-dev] Integration tests for FreeIPA In-Reply-To: <20160916092101.GC29676@abstractj.org> References: <20160912210202.GA24692@abstractj.org> <20160916092101.GC29676@abstractj.org> Message-ID: Sure, create a new repository keycloak-test-docker-images On 16 September 2016 at 11:21, Bruno Oliveira wrote: > Hi Stian, I prepared something with Docker compose[1]. Do you think it > should be moved to some Keycloak repo? > > > [1] - https://github.com/abstractj/docker/blob/master/keycloak- > sssd-integration-tests/README.md > > On 2016-09-13, Stian Thorgersen wrote: > > +1 Main thing is we need it to run on Central CI. If you can also make it > > easy to run it on a workstation that'd be great. Maybe with a Docker > image? > > > > Even if you could manage to get it running on Travis we'd probably not > want > > to as there's a tradeoff on how long it takes to test a PR and the amount > > of tests to run. > > > > On 13 September 2016 at 04:42, Marek Posolda > wrote: > > > > > Hi Bruno, > > > > > > the question is if we really need FreeIPA on Travis CI? The thing is > > > that Travis is currently just the CI for run "mvn clean install" when > > > you send PR to find regressions early. However we have already lots of > > > tests, which are not executed during default travis build. For example: > > > - Adapter tests in new testsuite. > > > - Tests with Keycloak on real Wildfly server (by default testsuite uses > > > just embedded undertow) > > > - Test with other DBs than embedded H2 > > > - Test with other LDAPs than embedded ApacheDS > > > > > > IMO It's fine if FreeIPA tests are executed just when you run the build > > > with some special maven profile. Hence we will have job on central CI, > > > which will test FreeIPA on daily basis. However those tests won't be > > > executed during default "mvn clean install" build and hence also not > > > executed on travis during every build. So defacto approach 1 from what > > > you mentioned. > > > > > > But maybe it's just me :) > > > > > > Marek > > > > > > On 12/09/16 23:02, Bruno Oliveira wrote: > > > > Ahoy, this week I will start to look at the integration tests for > > > > FreeIPA/SSSD with Ilya from QE. He already started some work here[1]. > > > > The tricky part for me is to spin up a FreeIPA server on Travis CI. > > > > > > > > For those not familiar with this environment, to run the > > > > integration tests, freeipa-server must be installed/configured. > > > > Unfortunately, Ubuntu Precise (the distro running on Travis) > > > > have only freeipa-client and python-freeipa[2]. > > > > > > > > Some ideas to make this happen: > > > > > > > > 1. Do nothing and let people run the integration tests locally. This > is > > > not awesome. > > > > 2. Spin up a FreeIPA docker instance on Travis before the build, plus > > > > install and configure a freeipa-client. The downside is: more steps, > > > > more slowness on Travis. > > > > 3. Move the CI to our own server and have FreeIPA installed and > > > > configured. > > > > > > > > Ideas? > > > > > > > > [1] - https://github.com/abstractj/keycloak/commit/ > > > 534569a9b6082a9674a33149519b06d1218d4807 > > > > [2] - https://launchpad.net/ubuntu/precise/+source/freeipa > > > > > > > > -- > > > > > > > > abstractj > > > > PGP: 0x84DC9914 > > > > _______________________________________________ > > > > keycloak-dev mailing list > > > > keycloak-dev at lists.jboss.org > > > > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > > > > > > > _______________________________________________ > > > keycloak-dev mailing list > > > keycloak-dev at lists.jboss.org > > > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > > > -- > > abstractj > PGP: 0x84DC9914 > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160916/66c148c5/attachment.html From sthorger at redhat.com Fri Sep 16 06:49:58 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Fri, 16 Sep 2016 12:49:58 +0200 Subject: [keycloak-dev] [keycloak-user] Ideas for the JavaOne's KeyCloak Hackengarten In-Reply-To: References: Message-ID: NIce. Some ideas from me: * *Identity what sucks and fix it*. Reducing and simplyfing steps to secure an application or service. * Automatic/dynamic client registration built-in to WF subsystem, or maybe to adapter in general * Ability to force token validation on server-side in services using token introspection endpoint * Way to specify what URLs are RESTful services and what are web app when both are combined in same WAR (first should return 401, second should redirect to login page) * Role mapping - ability to map realm and client roles onto different JEE roles * Remove the need to specify security domain in EJBs By the way Go ain't Java? So is that not out of scope for JavaOne? Just curious. On 16 September 2016 at 10:24, Sebastien Blanc wrote: > Hi ! > > Next week I will be at JavaOne, during the week I will have the privilege > to lead for an afternoon the hackergarten area. For sure, I would like to > bring up the KeyCloak project (along with Forge and maybe Swarm). > For those who don't know what an hackergarten is : > http://hackergarten.net/ > > So, do we have any JIRAs, docs , tests missing that would fit for a 3 > hours hacker session ? > > My own ideas : > - Work on the Keycloak Forge Addon : Create Clients from Forge etc ... > - Start exploring a Keycloak Go Adapter > - Polish Java Adapter Documentation > > I wait for your ideas ! > > Sebi > > > > > _______________________________________________ > keycloak-user mailing list > keycloak-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160916/885ee4e4/attachment.html From sthorger at redhat.com Mon Sep 19 02:50:16 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Mon, 19 Sep 2016 08:50:16 +0200 Subject: [keycloak-dev] Opinion on how secret the OIDC "client secret" should be? In-Reply-To: References: Message-ID: As kubectl is a CLI installed on end-user machines it's a public client. For a CLI I'd use a system browser and make the CLI start a temporary web server on localhost:XXXX, or I'd fallback to using resource owner password cred. ID token is an authentication token. So if you use that you should use it to authenticate with the service kubectl invokes and set up a session cookie to preserve the security context. Would make more sense to me to use the access token though, and have kubectl responsible to refresh it. On 14 September 2016 at 20:59, Marc Boorshtein < marc.boorshtein at tremolosecurity.com> wrote: > Reposting on Eric's behalf > > On Sep 14, 2016 2:54 PM, "Eric Chiang" wrote: > >> Thanks Marc for the cc, >> >> Just to give some background for the reasoning behind this. >> >> Today the Kubernetes API server trusts ID Tokens issued to a single >> client. Refreshing a token requires a client_secret, hence the flags Marc >> provided in his example. Though we don't have official recommendations >> about what the properties of the client passed in those flags should be >> there's two obvious ways of going about this. >> >> 1) Have each kubectl share a client secret. Some authorization servers >> provide mechanisms for declaring "public clients" to imposes restrictions >> on its capabilities. For example Google, when it assumes client_secrets >> aren't secret, restricts the redirect URLs for embedded apps to only >> localhost and a magic OOB, doesn't let it do incremental authorization, >> etc. Though as Marc noted this may have unintended consequences with >> providers who assume this doesn't happen. >> >> 2) Another option is for kubectl to utilize the "azp" claim in the ID >> Token[0], which allows clients to request ID Tokens on behalf of other >> clients. This means each kubectl gets its own client_id and client_secret, >> with each one requesting ID Tokens minted for a common client_id. However >> that capability isn't generally supported by OIDC providers, though Google >> does[1]. This is probably a more secure option, but the actual >> implementations differ so widely that it becomes hard to make a general >> statement. >> >> We'd be interested in knowing if either of these methods raise red flags >> when combined with keycloak. >> >> Eric >> >> [0] https://openid.net/specs/openid-connect-core-1_0.html#IDToken >> [1] https://developers.google.com/identity/protocols/CrossClientAuth >> >> >> >> On Wed, Sep 14, 2016 at 10:16 AM, Marc Boorshtein < >> marc.boorshtein at tremolosecurity.com> wrote: >> >>> KC Team, >>> >>> Eric Chiang from CoreOS (cc'd on this email) and I have been talking >>> on the Kubernetes sig-auth slack channel about how secret the "client >>> secret" in OIDC should be. The context for the question is that >>> Kubernetes' OIDC implementation uses the id_token as the bearer token >>> (as opposed to the access_token) to avoid a round trip. Since the >>> id_token should be short lived the question of how to get a new one >>> using a refresh_token. The current solution is to give kubectl the >>> refresh_token, the idp discovery url and the client id and secret: >>> >>> kubectl config set-credentials --auth-provider=oidc >>> kubectl config set-credentials --auth-provider-args=idp-issuer-url=( >>> issuer url ) >>> kubectl config set-credentials --auth-provider-args=client_id=( your >>> client id ) >>> kubectl config set-credentials --auth-provider-args=client_secret=( >>> your client secret ) >>> kubectl config set-credentials --auth-provider-args=refresh-token=( >>> your refresh token ) >>> >>> This way kubectl can get a new id_token once the possessed one >>> expires. The question becomes does giving the client_secret directly >>> to users become a security issue since its now a shared credential? >>> >>> Some issues I see are: >>> 1. Rotation becomes harder - how many people have this? >>> 2. While you can't generate an access_token with just this secret, >>> you CAN impersonate an RP so if your are monitoring which RPs are >>> making requests an attacker could generate excessive requests for a >>> single RP even if those requests fail >>> 3. Since most IdPs will generate some kind of back-end record for a >>> request if you have the client id and secret you could more easily do >>> a DoS attack by flooding the server with authenticated requestes for >>> authentication >>> >>> What are your thoughts? Google provides an example asserting that the >>> client secret ISN'T secret (reading through it I think the example >>> contradicts its self) >>> https://developers.google.com/api-client-library/python/auth >>> /installed-app >>> >>> Thanks >>> >>> >>> Marc Boorshtein >>> CTO Tremolo Security >>> marc.boorshtein at tremolosecurity.com >>> Twitter - @mlbiam / @tremolosecurity >>> >> >> > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160919/ac325ab2/attachment-0001.html From marc.boorshtein at tremolosecurity.com Mon Sep 19 09:02:11 2016 From: marc.boorshtein at tremolosecurity.com (Marc Boorshtein) Date: Mon, 19 Sep 2016 09:02:11 -0400 Subject: [keycloak-dev] Opinion on how secret the OIDC "client secret" should be? In-Reply-To: References: Message-ID: On Mon, Sep 19, 2016 at 2:50 AM, Stian Thorgersen wrote: > As kubectl is a CLI installed on end-user machines it's a public client. For > a CLI I'd use a system browser and make the CLI start a temporary web server > on localhost:XXXX, or I'd fallback to using resource owner password cred. > Thanks Stian, to be clear you're saying that you would NOT recommend distributing the client secret to end users? > ID token is an authentication token. So if you use that you should use it to > authenticate with the service kubectl invokes and set up a session cookie to > preserve the security context. Would make more sense to me to use the access > token though, and have kubectl responsible to refresh it. I think what you are describing is similar to how OpenStack works where you get a Keystone token after authenticating? From sthorger at redhat.com Mon Sep 19 09:30:42 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Mon, 19 Sep 2016 15:30:42 +0200 Subject: [keycloak-dev] Opinion on how secret the OIDC "client secret" should be? In-Reply-To: References: Message-ID: On 19 September 2016 at 15:02, Marc Boorshtein < marc.boorshtein at tremolosecurity.com> wrote: > On Mon, Sep 19, 2016 at 2:50 AM, Stian Thorgersen > wrote: > > As kubectl is a CLI installed on end-user machines it's a public client. > For > > a CLI I'd use a system browser and make the CLI start a temporary web > server > > on localhost:XXXX, or I'd fallback to using resource owner password cred. > > > > > Thanks Stian, to be clear you're saying that you would NOT recommend > distributing the client secret to end users? > WIth Keycloak I'd go with a public client if you want the CLI to handle retrieving tokens. > > > > ID token is an authentication token. So if you use that you should use > it to > > authenticate with the service kubectl invokes and set up a session > cookie to > > preserve the security context. Would make more sense to me to use the > access > > token though, and have kubectl responsible to refresh it. > > I think what you are describing is similar to how OpenStack works > where you get a Keystone token after authenticating? > Not sure, I don't know the details of OpenStack or Keystone -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160919/b951cf1c/attachment.html From josh.cain at redhat.com Mon Sep 19 10:50:51 2016 From: josh.cain at redhat.com (Josh Cain) Date: Mon, 19 Sep 2016 09:50:51 -0500 Subject: [keycloak-dev] Wildcard for Valid Redirect URI Hostname Message-ID: Per KEYCLOAK-3585: Currently, valid redirect URI hostnames allow for wildcards at the end like so: http://www.redhat.com/* I'm managing several environments where clients need 'n' number of available redirect URI's with different hostnames, I.E. http://developer1.env.redhat.com http://developer2.env.redhat.com http://developer3.env.redhat.com Would really help to have the ability to wildcard hostnames too, I.E.: http://*.env.redhat.com I've submitted #3241 to address this issue, but there seem to be some concerns about allowing wildcards in other parts of the URL. See the PR for a more fleshed out discussion, but wanted to start a thread here on the mailing list. Particularly with respect to: - Does anyone have need of this feature or would find it useful? - Should this kind of wildcard be allowed as a configuration option by Keycloak? Josh Cain | Software Applications Engineer *Identity and Access Management* *Red Hat* +1 256-452-0150 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160919/e77fcb8a/attachment.html From sthorger at redhat.com Tue Sep 20 02:20:46 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Tue, 20 Sep 2016 08:20:46 +0200 Subject: [keycloak-dev] Wildcard for Valid Redirect URI Hostname In-Reply-To: References: Message-ID: I appreciate this feature might be useful, so there's no need to discuss that aspect. The only issue I have with this PR is with regards to security and especially as it enables doing the "wrong" thing. With regards to redirect URIs with confidential clients they are still important, but not quite as important as they are for public client. This means redirect URIs can typically be more flexible with confidential clients without a significant risk. For public clients it's very important to lock these down as much as possible as they are the ONLY way to prevent malicious clients to gain access to the SSO session. This means we should actually tighten the requirements for redirect URIs not further relax them. For public clients the redirect URIs: * Should be as specific as possible. We should only allow wildcard in the path. I believe we should introduce this for both public and confidential clients. * Require HTTPs unless it's http://localhost. This is not so easy in development, so maybe we should have an option to run the server in "unsafe" mode for developers. Here's a quote from the OIDC spec around this: *"REQUIRED. Redirection URI to which the response will be sent. This URI MUST exactly match one of the Redirection URI values for the Client pre-registered at the OpenID Provider, with the matching performed as described in Section 6.2.1 of [RFC3986] (Simple String Comparison). The Redirection URI SHOULD use the https scheme; however, it MAY use the http scheme, provided that the Client Type is confidential, as defined in Section 2.1 of OAuth 2.0, and provided the OP allows the use of http Redirection URIs in this case. The Redirection URI MAY use an alternate scheme, such as one that is intended to identify a callback into a native application."* Looking at your comments on the PR it worries me slightly that you have a shared client for a "library". A library is not a client. A client is an instance of an application. Sharing the client will have impact on audit, what clients a user believes they are authenticated to. With regards to wildcard to allow any subdomains that is scary as your allowing any piece of code running on any subdomain within your domain to authenticate via that particular client. That could be an infected forum, something any user has executing, etc.. As long as the redirect URI permits it an application can obtain a token for a client for a user that is authenticated without the user knowing about it. Unless you enable consent that is, but if the user used the "real" client they would have given consent and the malicious client on a different subdomain can take advantage of it. In summary my opinion is that we can't accept this PR and that we further: * Allow wildcard only in path. This is actually still looser than the OIDC spec mandates as it requires a simple string comparison. * Require HTTPS (or custom scheme) for public clients. We may need a development mode that disables this. On 19 September 2016 at 16:50, Josh Cain wrote: > Per KEYCLOAK-3585: > > Currently, valid redirect URI hostnames allow for wildcards at the end > like so: > > http://www.redhat.com/* > > I'm managing several environments where clients need 'n' number of > available redirect URI's with different hostnames, I.E. > > http://developer1.env.redhat.com > > http://developer2.env.redhat.com > > http://developer3.env.redhat.com > > Would really help to have the ability to wildcard hostnames too, I.E.: > > http://*.env.redhat.com > > > I've submitted #3241 to > address this issue, but there seem to be some concerns about allowing > wildcards in other parts of the URL. See the PR for a more fleshed out > discussion, but wanted to start a thread here on the mailing list. > Particularly with respect to: > > - Does anyone have need of this feature or would find it useful? > - Should this kind of wildcard be allowed as a configuration option by > Keycloak? > > Josh Cain | Software Applications Engineer > *Identity and Access Management* > *Red Hat* > +1 256-452-0150 > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160920/1243f4eb/attachment-0001.html From yunusoncel at gmail.com Tue Sep 20 03:47:35 2016 From: yunusoncel at gmail.com (=?UTF-8?B?WXVudXMgw5ZOQ0VM?=) Date: Tue, 20 Sep 2016 10:47:35 +0300 Subject: [keycloak-dev] Alfresco Integration Message-ID: Hello; I have a short question. It is possible ? can i integration alfresco authentication system with Keycloak? Alfresco want use mod_auth_cas. do work keycloak with mod_auth_cas ? Thank you Sorry for my English :) -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160920/25353b70/attachment.html From sthorger at redhat.com Tue Sep 20 04:37:53 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Tue, 20 Sep 2016 10:37:53 +0200 Subject: [keycloak-dev] Alfresco Integration In-Reply-To: References: Message-ID: We don't support CAS, but if Alfresco uses Apache Modules to integrate with an external IdP you should be able to use mod_auth_mellon (SAML) or mod_auth_oidc (OpenID Connect) instead. On 20 September 2016 at 09:47, Yunus ?NCEL wrote: > Hello; > > I have a short question. > > > It is possible ? can i integration alfresco authentication system with > Keycloak? > > Alfresco want use mod_auth_cas. do work keycloak with mod_auth_cas ? > > Thank you > > Sorry for my English :) > > > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160920/aeabdaf2/attachment.html From thomas.darimont at googlemail.com Tue Sep 20 09:01:50 2016 From: thomas.darimont at googlemail.com (Thomas Darimont) Date: Tue, 20 Sep 2016 15:01:50 +0200 Subject: [keycloak-dev] Spurious logouts in AdminConsole with 2.2.0.Final (current master) Message-ID: Hello group, since I upgraded to our Keycloak instance to 2.2.0.Final I see spourious logouts form the admin-console while browsing the UI and editing stuff... I experience the same with the current master. I couldn't yet narrow it down but having to login every ~ 5 mins is really unpleasant - I also got logged out within 30sec after login when I wanted to add a new protocol mapper to a client. Has anyone experienced the same? Cheers, Thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160920/c9b167bd/attachment.html From sthorger at redhat.com Tue Sep 20 09:08:13 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Tue, 20 Sep 2016 15:08:13 +0200 Subject: [keycloak-dev] Spurious logouts in AdminConsole with 2.2.0.Final (current master) In-Reply-To: References: Message-ID: It's probably this one https://issues.jboss.org/browse/KEYCLOAK-3586. I'll take a look at it now. On 20 September 2016 at 15:01, Thomas Darimont < thomas.darimont at googlemail.com> wrote: > Hello group, > > since I upgraded to our Keycloak instance to 2.2.0.Final I see spourious > logouts form the > admin-console while browsing the UI and editing stuff... > > I experience the same with the current master. > > I couldn't yet narrow it down but having to login every ~ 5 mins is really > unpleasant - I > also got logged out within 30sec after login when I wanted to add a new > protocol mapper to a client. > > Has anyone experienced the same? > > Cheers, > Thomas > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160920/9d2ae615/attachment.html From sthorger at redhat.com Tue Sep 20 09:31:01 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Tue, 20 Sep 2016 15:31:01 +0200 Subject: [keycloak-dev] Spurious logouts in AdminConsole with 2.2.0.Final (current master) In-Reply-To: References: Message-ID: Confirmed - the issue is caused by updateToken not refreshing the token due to a change I made with regards to timeSkew. I'll do a 2.2.1 release tomorrow with fix as this is pretty bad. On 20 September 2016 at 15:08, Stian Thorgersen wrote: > It's probably this one https://issues.jboss.org/browse/KEYCLOAK-3586. > I'll take a look at it now. > > On 20 September 2016 at 15:01, Thomas Darimont < > thomas.darimont at googlemail.com> wrote: > >> Hello group, >> >> since I upgraded to our Keycloak instance to 2.2.0.Final I see spourious >> logouts form the >> admin-console while browsing the UI and editing stuff... >> >> I experience the same with the current master. >> >> I couldn't yet narrow it down but having to login every ~ 5 mins is >> really unpleasant - I >> also got logged out within 30sec after login when I wanted to add a new >> protocol mapper to a client. >> >> Has anyone experienced the same? >> >> Cheers, >> Thomas >> >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160920/17c92f33/attachment.html From josh.cain at redhat.com Tue Sep 20 10:15:58 2016 From: josh.cain at redhat.com (Josh Cain) Date: Tue, 20 Sep 2016 09:15:58 -0500 Subject: [keycloak-dev] Wildcard for Valid Redirect URI Hostname In-Reply-To: References: Message-ID: So I certainly get that we want to be as close to the spec as possible - wholeheartedly agree. However, I'd also like to reiterate that the main purpose of this is for lower/developer environments in which there are a large number of developers who are frequently spinning up sanboxes with apps that need SSO capabilities. Unless I want to open up the GUI in these environments to the world, I'm left without a good CM option for Keycloak. Any suggestions on the management of this? Right now I'm looking at a high amount of manual overhead, or scripting it out with some one-off config scripts that I'll have to wind up maintaining. Neither option sounds appealing. Hope you didn't get the wrong impression from the PR - I noted a javascript library that was shared across several pages within a number of subdomains. All pages share a similar look and feel, but due to the nature of the content and topic can live at different subdomains or even have slightly different page content implementations. Are we really going to make the assertion that a 'client' cannot span subdomains? That seems to be the implication here. And if so, is that necessarily more 'secure', or does that just mean that implementers could simply favor a single domain name with varying paths instead of categorically organized subdomains? Seems like an implementation detail that can easily be circumvented and does not inherently make an enclave more or less secure. I completely agree with your argument that we should be striving for the finest level of granularity with respect to client definition. I understand the intentional segregation of logical clients by the specification so as to keep one compromised client from affecting the entire SSO ecosystem. However, I do think that there is a solid case for a single 'client' that does stuff like spans subdomains, and that such a client could be used in a secure manner. At the end of the day, it feels like we're trying to force a definition on what is a client. The discussion seems to acknowledge that 'real world' application of this spec find wildcards useful (as your suggestion for supporting them in the path), however the manner in which they're used appropriately is up for debate. If we're living outside the spec anyway, do we really have a firm leg to stand on for the assertion that clients can have different paths but not subdomains? I don't see a solid reason for this one. Some other thoughts I had on this that might be useful: - Some of the rub here is that maintaining a list of valid redirects for something like string matching is a CM nightmare (particularly in dev-ish environments). Something like an SPI to drop an implementation in here where I can apply a little more powerful logic would also do the job. Could this be used nefariously or poorly to circumvent the specification? yeah, sure - but so can Authenticators, and they're seen as a useful tool whereby developers can extend necessary functionality. - Would you also consider something like a 'development mode' flag that allowed for different options such as wildcards in different URL parts? Would have to add a little more validation to define what is and is not allowed, but would be useful for this case. Thanks for good the discussion. As always, learning much and enjoying it! Josh Cain | Software Applications Engineer *Identity and Access Management* *Red Hat* +1 256-452-0150 On Tue, Sep 20, 2016 at 1:20 AM, Stian Thorgersen wrote: > I appreciate this feature might be useful, so there's no need to discuss > that aspect. The only issue I have with this PR is with regards to security > and especially as it enables doing the "wrong" thing. > > With regards to redirect URIs with confidential clients they are still > important, but not quite as important as they are for public client. This > means redirect URIs can typically be more flexible with confidential > clients without a significant risk. > > For public clients it's very important to lock these down as much as > possible as they are the ONLY way to prevent malicious clients to gain > access to the SSO session. This means we should actually tighten the > requirements for redirect URIs not further relax them. For public clients > the redirect URIs: > > * Should be as specific as possible. We should only allow wildcard in the > path. I believe we should introduce this for both public and confidential > clients. > * Require HTTPs unless it's http://localhost. This is not so easy in > development, so maybe we should have an option to run the server in > "unsafe" mode for developers. > > Here's a quote from the OIDC spec around this: > > *"REQUIRED. Redirection URI to which the response will be sent. This URI > MUST exactly match one of the Redirection URI values for the Client > pre-registered at the OpenID Provider, with the matching performed as > described in Section 6.2.1 of [RFC3986] (Simple String Comparison). The > Redirection URI SHOULD use the https scheme; however, it MAY use the http > scheme, provided that the Client Type is confidential, as defined in > Section 2.1 of OAuth 2.0, and provided the OP allows the use of http > Redirection URIs in this case. The Redirection URI MAY use an alternate > scheme, such as one that is intended to identify a callback into a native > application."* > > Looking at your comments on the PR it worries me slightly that you have a > shared client for a "library". A library is not a client. A client is an > instance of an application. Sharing the client will have impact on audit, > what clients a user believes they are authenticated to. With regards to > wildcard to allow any subdomains that is scary as your allowing any piece > of code running on any subdomain within your domain to authenticate via > that particular client. That could be an infected forum, something any user > has executing, etc.. As long as the redirect URI permits it an application > can obtain a token for a client for a user that is authenticated without > the user knowing about it. Unless you enable consent that is, but if the > user used the "real" client they would have given consent and the malicious > client on a different subdomain can take advantage of it. > > In summary my opinion is that we can't accept this PR and that we further: > > * Allow wildcard only in path. This is actually still looser than the OIDC > spec mandates as it requires a simple string comparison. > * Require HTTPS (or custom scheme) for public clients. We may need a > development mode that disables this. > > > > On 19 September 2016 at 16:50, Josh Cain wrote: > >> Per KEYCLOAK-3585: >> >> Currently, valid redirect URI hostnames allow for wildcards at the end >> like so: >> >> http://www.redhat.com/* >> >> I'm managing several environments where clients need 'n' number of >> available redirect URI's with different hostnames, I.E. >> >> http://developer1.env.redhat.com >> >> http://developer2.env.redhat.com >> >> http://developer3.env.redhat.com >> >> Would really help to have the ability to wildcard hostnames too, I.E.: >> >> http://*.env.redhat.com >> >> >> I've submitted #3241 to >> address this issue, but there seem to be some concerns about allowing >> wildcards in other parts of the URL. See the PR for a more fleshed out >> discussion, but wanted to start a thread here on the mailing list. >> Particularly with respect to: >> >> - Does anyone have need of this feature or would find it useful? >> - Should this kind of wildcard be allowed as a configuration option >> by Keycloak? >> >> Josh Cain | Software Applications Engineer >> *Identity and Access Management* >> *Red Hat* >> +1 256-452-0150 >> >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160920/0fa97dce/attachment-0001.html From thomas.darimont at googlemail.com Tue Sep 20 10:49:00 2016 From: thomas.darimont at googlemail.com (Thomas Darimont) Date: Tue, 20 Sep 2016 16:49:00 +0200 Subject: [keycloak-dev] Wildcard for Valid Redirect URI Hostname In-Reply-To: References: Message-ID: Great discussion with a lot of interesting points! I think being more flexible with respect to redirect URI's would be very helpful. I wonder whether one could provide a REST endpoint a developer could use to register an additional redirect URI for an existing client - given that the developer provides the clientId, clientSecret -> service account. With this a developer could "unlock" his machine enable for a particular client. One way to do that would be to register a custom REST Resource in Keycloak which only allows requests from the service-accounts of a particular client. The resource could then simply lookup the appropriate client configuration and update the allowed redirect paths. Adding paths should trigger an AdminEvent to provide an audit trail. Cheers, Thomas 2016-09-20 16:15 GMT+02:00 Josh Cain : > So I certainly get that we want to be as close to the spec as possible - > wholeheartedly agree. However, I'd also like to reiterate that the main > purpose of this is for lower/developer environments in which there are a > large number of developers who are frequently spinning up sanboxes with > apps that need SSO capabilities. Unless I want to open up the GUI in these > environments to the world, I'm left without a good CM option for Keycloak. > Any suggestions on the management of this? Right now I'm looking at a high > amount of manual overhead, or scripting it out with some one-off config > scripts that I'll have to wind up maintaining. Neither option sounds > appealing. > > Hope you didn't get the wrong impression from the PR - I noted a > javascript library that was shared across several pages within a number of > subdomains. All pages share a similar look and feel, but due to the nature > of the content and topic can live at different subdomains or even have > slightly different page content implementations. Are we really going to > make the assertion that a 'client' cannot span subdomains? That seems to > be the implication here. And if so, is that necessarily more 'secure', or > does that just mean that implementers could simply favor a single domain > name with varying paths instead of categorically organized subdomains? > Seems like an implementation detail that can easily be circumvented and > does not inherently make an enclave more or less secure. > > I completely agree with your argument that we should be striving for the > finest level of granularity with respect to client definition. I > understand the intentional segregation of logical clients by the > specification so as to keep one compromised client from affecting the > entire SSO ecosystem. However, I do think that there is a solid case for a > single 'client' that does stuff like spans subdomains, and that such a > client could be used in a secure manner. > > At the end of the day, it feels like we're trying to force a definition on > what is a client. The discussion seems to acknowledge that 'real world' > application of this spec find wildcards useful (as your suggestion for > supporting them in the path), however the manner in which they're used > appropriately is up for debate. If we're living outside the spec anyway, > do we really have a firm leg to stand on for the assertion that clients can > have different paths but not subdomains? I don't see a solid reason for > this one. > > Some other thoughts I had on this that might be useful: > > - Some of the rub here is that maintaining a list of valid redirects > for something like string matching is a CM nightmare (particularly in > dev-ish environments). Something like an SPI to drop an implementation in > here where I can apply a little more powerful logic would also do the job. > Could this be used nefariously or poorly to circumvent the specification? > yeah, sure - but so can Authenticators, and they're seen as a useful tool > whereby developers can extend necessary functionality. > - Would you also consider something like a 'development mode' flag > that allowed for different options such as wildcards in different URL > parts? Would have to add a little more validation to define what is and is > not allowed, but would be useful for this case. > > Thanks for good the discussion. As always, learning much and enjoying it! > > Josh Cain | Software Applications Engineer > *Identity and Access Management* > *Red Hat* > +1 256-452-0150 > > On Tue, Sep 20, 2016 at 1:20 AM, Stian Thorgersen > wrote: > >> I appreciate this feature might be useful, so there's no need to discuss >> that aspect. The only issue I have with this PR is with regards to security >> and especially as it enables doing the "wrong" thing. >> >> With regards to redirect URIs with confidential clients they are still >> important, but not quite as important as they are for public client. This >> means redirect URIs can typically be more flexible with confidential >> clients without a significant risk. >> >> For public clients it's very important to lock these down as much as >> possible as they are the ONLY way to prevent malicious clients to gain >> access to the SSO session. This means we should actually tighten the >> requirements for redirect URIs not further relax them. For public clients >> the redirect URIs: >> >> * Should be as specific as possible. We should only allow wildcard in the >> path. I believe we should introduce this for both public and confidential >> clients. >> * Require HTTPs unless it's http://localhost. This is not so easy in >> development, so maybe we should have an option to run the server in >> "unsafe" mode for developers. >> >> Here's a quote from the OIDC spec around this: >> >> *"REQUIRED. Redirection URI to which the response will be sent. This URI >> MUST exactly match one of the Redirection URI values for the Client >> pre-registered at the OpenID Provider, with the matching performed as >> described in Section 6.2.1 of [RFC3986] (Simple String Comparison). The >> Redirection URI SHOULD use the https scheme; however, it MAY use the http >> scheme, provided that the Client Type is confidential, as defined in >> Section 2.1 of OAuth 2.0, and provided the OP allows the use of http >> Redirection URIs in this case. The Redirection URI MAY use an alternate >> scheme, such as one that is intended to identify a callback into a native >> application."* >> >> Looking at your comments on the PR it worries me slightly that you have a >> shared client for a "library". A library is not a client. A client is an >> instance of an application. Sharing the client will have impact on audit, >> what clients a user believes they are authenticated to. With regards to >> wildcard to allow any subdomains that is scary as your allowing any piece >> of code running on any subdomain within your domain to authenticate via >> that particular client. That could be an infected forum, something any user >> has executing, etc.. As long as the redirect URI permits it an application >> can obtain a token for a client for a user that is authenticated without >> the user knowing about it. Unless you enable consent that is, but if the >> user used the "real" client they would have given consent and the malicious >> client on a different subdomain can take advantage of it. >> >> In summary my opinion is that we can't accept this PR and that we further: >> >> * Allow wildcard only in path. This is actually still looser than the >> OIDC spec mandates as it requires a simple string comparison. >> * Require HTTPS (or custom scheme) for public clients. We may need a >> development mode that disables this. >> >> >> >> On 19 September 2016 at 16:50, Josh Cain wrote: >> >>> Per KEYCLOAK-3585: >>> >>> Currently, valid redirect URI hostnames allow for wildcards at the end >>> like so: >>> >>> http://www.redhat.com/* >>> >>> I'm managing several environments where clients need 'n' number of >>> available redirect URI's with different hostnames, I.E. >>> >>> http://developer1.env.redhat.com >>> >>> http://developer2.env.redhat.com >>> >>> http://developer3.env.redhat.com >>> >>> Would really help to have the ability to wildcard hostnames too, I.E.: >>> >>> http://*.env.redhat.com >>> >>> >>> I've submitted #3241 >>> to address this issue, but there seem to be some concerns about allowing >>> wildcards in other parts of the URL. See the PR for a more fleshed out >>> discussion, but wanted to start a thread here on the mailing list. >>> Particularly with respect to: >>> >>> - Does anyone have need of this feature or would find it useful? >>> - Should this kind of wildcard be allowed as a configuration option >>> by Keycloak? >>> >>> Josh Cain | Software Applications Engineer >>> *Identity and Access Management* >>> *Red Hat* >>> +1 256-452-0150 >>> >>> _______________________________________________ >>> keycloak-dev mailing list >>> keycloak-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>> >> >> > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160920/d2ad1ba4/attachment.html From srossillo at smartling.com Tue Sep 20 14:42:55 2016 From: srossillo at smartling.com (Scott Rossillo) Date: Tue, 20 Sep 2016 14:42:55 -0400 Subject: [keycloak-dev] Wildcard for Valid Redirect URI Hostname In-Reply-To: References: Message-ID: There?s a REST endpoint and we use it via Resteasy: ClientRepresentation client = keycloak.realm(realmName).clients().get(clientId); client.setRedirectUris(?); Scott Rossillo Smartling | Senior Software Engineer srossillo at smartling.com > On Sep 20, 2016, at 10:49 AM, Thomas Darimont wrote: > > Great discussion with a lot of interesting points! > > I think being more flexible with respect to redirect URI's would be very helpful. > > I wonder whether one could provide a REST endpoint a developer could use to register an additional redirect URI > for an existing client - given that the developer provides the clientId, clientSecret -> service account. > > With this a developer could "unlock" his machine enable for a particular client. One way to do that would be to register a custom REST Resource in Keycloak which only allows requests from the service-accounts of a particular client. The resource could then simply lookup the appropriate client configuration and update the allowed redirect paths. > > Adding paths should trigger an AdminEvent to provide an audit trail. > > Cheers, > Thomas > > 2016-09-20 16:15 GMT+02:00 Josh Cain >: > So I certainly get that we want to be as close to the spec as possible - wholeheartedly agree. However, I'd also like to reiterate that the main purpose of this is for lower/developer environments in which there are a large number of developers who are frequently spinning up sanboxes with apps that need SSO capabilities. Unless I want to open up the GUI in these environments to the world, I'm left without a good CM option for Keycloak. Any suggestions on the management of this? Right now I'm looking at a high amount of manual overhead, or scripting it out with some one-off config scripts that I'll have to wind up maintaining. Neither option sounds appealing. > > Hope you didn't get the wrong impression from the PR - I noted a javascript library that was shared across several pages within a number of subdomains. All pages share a similar look and feel, but due to the nature of the content and topic can live at different subdomains or even have slightly different page content implementations. Are we really going to make the assertion that a 'client' cannot span subdomains? That seems to be the implication here. And if so, is that necessarily more 'secure', or does that just mean that implementers could simply favor a single domain name with varying paths instead of categorically organized subdomains? Seems like an implementation detail that can easily be circumvented and does not inherently make an enclave more or less secure. > > I completely agree with your argument that we should be striving for the finest level of granularity with respect to client definition. I understand the intentional segregation of logical clients by the specification so as to keep one compromised client from affecting the entire SSO ecosystem. However, I do think that there is a solid case for a single 'client' that does stuff like spans subdomains, and that such a client could be used in a secure manner. > > At the end of the day, it feels like we're trying to force a definition on what is a client. The discussion seems to acknowledge that 'real world' application of this spec find wildcards useful (as your suggestion for supporting them in the path), however the manner in which they're used appropriately is up for debate. If we're living outside the spec anyway, do we really have a firm leg to stand on for the assertion that clients can have different paths but not subdomains? I don't see a solid reason for this one. > > Some other thoughts I had on this that might be useful: > Some of the rub here is that maintaining a list of valid redirects for something like string matching is a CM nightmare (particularly in dev-ish environments). Something like an SPI to drop an implementation in here where I can apply a little more powerful logic would also do the job. Could this be used nefariously or poorly to circumvent the specification? yeah, sure - but so can Authenticators, and they're seen as a useful tool whereby developers can extend necessary functionality. > Would you also consider something like a 'development mode' flag that allowed for different options such as wildcards in different URL parts? Would have to add a little more validation to define what is and is not allowed, but would be useful for this case. > > Thanks for good the discussion. As always, learning much and enjoying it! > > > Josh Cain | Software Applications Engineer > Identity and Access Management > Red Hat > +1 256-452-0150 > > On Tue, Sep 20, 2016 at 1:20 AM, Stian Thorgersen > wrote: > I appreciate this feature might be useful, so there's no need to discuss that aspect. The only issue I have with this PR is with regards to security and especially as it enables doing the "wrong" thing. > > With regards to redirect URIs with confidential clients they are still important, but not quite as important as they are for public client. This means redirect URIs can typically be more flexible with confidential clients without a significant risk. > > For public clients it's very important to lock these down as much as possible as they are the ONLY way to prevent malicious clients to gain access to the SSO session. This means we should actually tighten the requirements for redirect URIs not further relax them. For public clients the redirect URIs: > > * Should be as specific as possible. We should only allow wildcard in the path. I believe we should introduce this for both public and confidential clients. > * Require HTTPs unless it's http://localhost . This is not so easy in development, so maybe we should have an option to run the server in "unsafe" mode for developers. > > Here's a quote from the OIDC spec around this: > > "REQUIRED. Redirection URI to which the response will be sent. This URI MUST exactly match one of the Redirection URI values for the Client pre-registered at the OpenID Provider, with the matching performed as described in Section 6.2.1 of [RFC3986] (Simple String Comparison). The Redirection URI SHOULD use the https scheme; however, it MAY use the http scheme, provided that the Client Type is confidential, as defined in Section 2.1 of OAuth 2.0, and provided the OP allows the use of http Redirection URIs in this case. The Redirection URI MAY use an alternate scheme, such as one that is intended to identify a callback into a native application." > > Looking at your comments on the PR it worries me slightly that you have a shared client for a "library". A library is not a client. A client is an instance of an application. Sharing the client will have impact on audit, what clients a user believes they are authenticated to. With regards to wildcard to allow any subdomains that is scary as your allowing any piece of code running on any subdomain within your domain to authenticate via that particular client. That could be an infected forum, something any user has executing, etc.. As long as the redirect URI permits it an application can obtain a token for a client for a user that is authenticated without the user knowing about it. Unless you enable consent that is, but if the user used the "real" client they would have given consent and the malicious client on a different subdomain can take advantage of it. > > In summary my opinion is that we can't accept this PR and that we further: > > * Allow wildcard only in path. This is actually still looser than the OIDC spec mandates as it requires a simple string comparison. > * Require HTTPS (or custom scheme) for public clients. We may need a development mode that disables this. > > > > On 19 September 2016 at 16:50, Josh Cain > wrote: > Per KEYCLOAK-3585: > Currently, valid redirect URI hostnames allow for wildcards at the end like so: > > > http://www.redhat.com/* > > I'm managing several environments where clients need 'n' number of available redirect URI's with different hostnames, I.E. > > > http://developer1.env.redhat.com > http://developer2.env.redhat.com > http://developer3.env.redhat.com > > Would really help to have the ability to wildcard hostnames too, I.E.: > > > http://*.env.redhat.com > > I've submitted #3241 to address this issue, but there seem to be some concerns about allowing wildcards in other parts of the URL. See the PR for a more fleshed out discussion, but wanted to start a thread here on the mailing list. Particularly with respect to: > Does anyone have need of this feature or would find it useful? > Should this kind of wildcard be allowed as a configuration option by Keycloak? > Josh Cain | Software Applications Engineer > Identity and Access Management > Red Hat > +1 256-452-0150 > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160920/649403c4/attachment-0001.html From j.kamal at ymail.com Tue Sep 20 17:48:49 2016 From: j.kamal at ymail.com (Kamal Jagadevan) Date: Tue, 20 Sep 2016 21:48:49 +0000 (UTC) Subject: [keycloak-dev] Reg impersonation References: <1815719276.1833582.1474408129771.ref@mail.yahoo.com> Message-ID: <1815719276.1833582.1474408129771@mail.yahoo.com> Hello Keycloak Team,??? Is there a way to use impersonation feature to view/log into applications (protected by Keycloak) instead of viewing impersonated user?s User Account Management page?If not, is there a plan in road map to support them in future? BestKamal -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160920/81e7dced/attachment.html From bburke at redhat.com Tue Sep 20 20:12:39 2016 From: bburke at redhat.com (Bill Burke) Date: Tue, 20 Sep 2016 20:12:39 -0400 Subject: [keycloak-dev] Reg impersonation In-Reply-To: <1815719276.1833582.1474408129771@mail.yahoo.com> References: <1815719276.1833582.1474408129771.ref@mail.yahoo.com> <1815719276.1833582.1474408129771@mail.yahoo.com> Message-ID: When you impersonate from admin console, you are logged in as that user and can view any app the user can. On 9/20/16 5:48 PM, Kamal Jagadevan wrote: > Hello Keycloak Team, > Is there a way to use impersonation feature to view/log into > applications (protected by Keycloak) instead of viewing impersonated > user?s User Account Management page? > If not, is there a plan in road map to support them in future? > > Best > Kamal > > > > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160920/2bb140ce/attachment.html From sthorger at redhat.com Wed Sep 21 02:12:59 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Wed, 21 Sep 2016 08:12:59 +0200 Subject: [keycloak-dev] Wildcard for Valid Redirect URI Hostname In-Reply-To: References: Message-ID: On 20 September 2016 at 16:15, Josh Cain wrote: > So I certainly get that we want to be as close to the spec as possible - > wholeheartedly agree. However, I'd also like to reiterate that the main > purpose of this is for lower/developer environments in which there are a > large number of developers who are frequently spinning up sanboxes with > apps that need SSO capabilities. Unless I want to open up the GUI in these > environments to the world, I'm left without a good CM option for Keycloak. > Any suggestions on the management of this? Right now I'm looking at a high > amount of manual overhead, or scripting it out with some one-off config > scripts that I'll have to wind up maintaining. Neither option sounds > appealing. > +1 This is a use-case we need to find a solution to > > Hope you didn't get the wrong impression from the PR - I noted a > javascript library that was shared across several pages within a number of > subdomains. All pages share a similar look and feel, but due to the nature > of the content and topic can live at different subdomains or even have > slightly different page content implementations. Are we really going to > make the assertion that a 'client' cannot span subdomains? That seems to > be the implication here. And if so, is that necessarily more 'secure', or > does that just mean that implementers could simply favor a single domain > name with varying paths instead of categorically organized subdomains? > Seems like an implementation detail that can easily be circumvented and > does not inherently make an enclave more or less secure. > A shared JavaScript library is not an client/application it's a library. Not sure how you can argue that it's a client. A client has more than just a redirect uri. It has: * Base URL - so users can find the application. This will be more useful in the future once we introduce a SSO landing page and provide links to applications from the account management console * Consent - clients that require consents should allow users to give consent per-application, not per-library * Audit/log - audit and log both in admin console and account management relies on knowing what application, not what library, accessed a users account I really think you are misusing the concept of a client when you are using a client for a library and I disagree that this is a valid use-case. You are doing something wrong here. > > I completely agree with your argument that we should be striving for the > finest level of granularity with respect to client definition. I > understand the intentional segregation of logical clients by the > specification so as to keep one compromised client from affecting the > entire SSO ecosystem. However, I do think that there is a solid case for a > single 'client' that does stuff like spans subdomains, and that such a > client could be used in a secure manner. > Can you give me a real example of where an application has multiple subdomains? I just don't see it. > > At the end of the day, it feels like we're trying to force a definition on > what is a client. The discussion seems to acknowledge that 'real world' > application of this spec find wildcards useful (as your suggestion for > supporting them in the path), however the manner in which they're used > appropriately is up for debate. If we're living outside the spec anyway, > do we really have a firm leg to stand on for the assertion that clients can > have different paths but not subdomains? I don't see a solid reason for > this one. > We shouldn't have had the wildcard in the first place. The reason we need it is that our adapters use the current path for the application as the redirect-uri. In other OIDC providers you are limited to a simple string matching in which case it's usual to have a callback endpoint and encode the path in the state parameter. > > Some other thoughts I had on this that might be useful: > > - Some of the rub here is that maintaining a list of valid redirects > for something like string matching is a CM nightmare (particularly in > dev-ish environments). Something like an SPI to drop an implementation in > here where I can apply a little more powerful logic would also do the job. > Could this be used nefariously or poorly to circumvent the specification? > yeah, sure - but so can Authenticators, and they're seen as a useful tool > whereby developers can extend necessary functionality. > - Would you also consider something like a 'development mode' flag > that allowed for different options such as wildcards in different URL > parts? Would have to add a little more validation to define what is and is > not allowed, but would be useful for this case. > > I had the idea of an SPI or a developer mode, but ideally we'd find another way to deal with this. Have you looked at dynamic client registration by the way? That allows registering clients without UI access and with a limited initial access token. We're also soon going to have a client registration CLI that allows doing this. > Thanks for good the discussion. As always, learning much and enjoying it! > > Josh Cain | Software Applications Engineer > *Identity and Access Management* > *Red Hat* > +1 256-452-0150 > > On Tue, Sep 20, 2016 at 1:20 AM, Stian Thorgersen > wrote: > >> I appreciate this feature might be useful, so there's no need to discuss >> that aspect. The only issue I have with this PR is with regards to security >> and especially as it enables doing the "wrong" thing. >> >> With regards to redirect URIs with confidential clients they are still >> important, but not quite as important as they are for public client. This >> means redirect URIs can typically be more flexible with confidential >> clients without a significant risk. >> >> For public clients it's very important to lock these down as much as >> possible as they are the ONLY way to prevent malicious clients to gain >> access to the SSO session. This means we should actually tighten the >> requirements for redirect URIs not further relax them. For public clients >> the redirect URIs: >> >> * Should be as specific as possible. We should only allow wildcard in the >> path. I believe we should introduce this for both public and confidential >> clients. >> * Require HTTPs unless it's http://localhost. This is not so easy in >> development, so maybe we should have an option to run the server in >> "unsafe" mode for developers. >> >> Here's a quote from the OIDC spec around this: >> >> *"REQUIRED. Redirection URI to which the response will be sent. This URI >> MUST exactly match one of the Redirection URI values for the Client >> pre-registered at the OpenID Provider, with the matching performed as >> described in Section 6.2.1 of [RFC3986] (Simple String Comparison). The >> Redirection URI SHOULD use the https scheme; however, it MAY use the http >> scheme, provided that the Client Type is confidential, as defined in >> Section 2.1 of OAuth 2.0, and provided the OP allows the use of http >> Redirection URIs in this case. The Redirection URI MAY use an alternate >> scheme, such as one that is intended to identify a callback into a native >> application."* >> >> Looking at your comments on the PR it worries me slightly that you have a >> shared client for a "library". A library is not a client. A client is an >> instance of an application. Sharing the client will have impact on audit, >> what clients a user believes they are authenticated to. With regards to >> wildcard to allow any subdomains that is scary as your allowing any piece >> of code running on any subdomain within your domain to authenticate via >> that particular client. That could be an infected forum, something any user >> has executing, etc.. As long as the redirect URI permits it an application >> can obtain a token for a client for a user that is authenticated without >> the user knowing about it. Unless you enable consent that is, but if the >> user used the "real" client they would have given consent and the malicious >> client on a different subdomain can take advantage of it. >> >> In summary my opinion is that we can't accept this PR and that we further: >> >> * Allow wildcard only in path. This is actually still looser than the >> OIDC spec mandates as it requires a simple string comparison. >> * Require HTTPS (or custom scheme) for public clients. We may need a >> development mode that disables this. >> >> >> >> On 19 September 2016 at 16:50, Josh Cain wrote: >> >>> Per KEYCLOAK-3585: >>> >>> Currently, valid redirect URI hostnames allow for wildcards at the end >>> like so: >>> >>> http://www.redhat.com/* >>> >>> I'm managing several environments where clients need 'n' number of >>> available redirect URI's with different hostnames, I.E. >>> >>> http://developer1.env.redhat.com >>> >>> http://developer2.env.redhat.com >>> >>> http://developer3.env.redhat.com >>> >>> Would really help to have the ability to wildcard hostnames too, I.E.: >>> >>> http://*.env.redhat.com >>> >>> >>> I've submitted #3241 >>> to address this issue, but there seem to be some concerns about allowing >>> wildcards in other parts of the URL. See the PR for a more fleshed out >>> discussion, but wanted to start a thread here on the mailing list. >>> Particularly with respect to: >>> >>> - Does anyone have need of this feature or would find it useful? >>> - Should this kind of wildcard be allowed as a configuration option >>> by Keycloak? >>> >>> Josh Cain | Software Applications Engineer >>> *Identity and Access Management* >>> *Red Hat* >>> +1 256-452-0150 >>> >>> _______________________________________________ >>> keycloak-dev mailing list >>> keycloak-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160921/acf53b76/attachment-0001.html From sthorger at redhat.com Wed Sep 21 02:13:50 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Wed, 21 Sep 2016 08:13:50 +0200 Subject: [keycloak-dev] Wildcard for Valid Redirect URI Hostname In-Reply-To: References: Message-ID: There's client registration services that does this. It allows creating, updating and deleting clients. See https://keycloak.gitbooks.io/securing-client-applications-guide/content/topics/client-registration.html Then there's also the admin endpoints as Scott pointed out. On 20 September 2016 at 16:49, Thomas Darimont < thomas.darimont at googlemail.com> wrote: > Great discussion with a lot of interesting points! > > I think being more flexible with respect to redirect URI's would be very > helpful. > > I wonder whether one could provide a REST endpoint a developer could use > to register an additional redirect URI > for an existing client - given that the developer provides the clientId, > clientSecret -> service account. > > With this a developer could "unlock" his machine enable for a particular > client. One way to do that would be to register a custom REST Resource in > Keycloak which only allows requests from the service-accounts of a > particular client. The resource could then simply lookup the appropriate > client configuration and update the allowed redirect paths. > > Adding paths should trigger an AdminEvent to provide an audit trail. > > Cheers, > Thomas > > 2016-09-20 16:15 GMT+02:00 Josh Cain : > >> So I certainly get that we want to be as close to the spec as possible - >> wholeheartedly agree. However, I'd also like to reiterate that the main >> purpose of this is for lower/developer environments in which there are a >> large number of developers who are frequently spinning up sanboxes with >> apps that need SSO capabilities. Unless I want to open up the GUI in these >> environments to the world, I'm left without a good CM option for Keycloak. >> Any suggestions on the management of this? Right now I'm looking at a high >> amount of manual overhead, or scripting it out with some one-off config >> scripts that I'll have to wind up maintaining. Neither option sounds >> appealing. >> >> Hope you didn't get the wrong impression from the PR - I noted a >> javascript library that was shared across several pages within a number of >> subdomains. All pages share a similar look and feel, but due to the nature >> of the content and topic can live at different subdomains or even have >> slightly different page content implementations. Are we really going to >> make the assertion that a 'client' cannot span subdomains? That seems to >> be the implication here. And if so, is that necessarily more 'secure', or >> does that just mean that implementers could simply favor a single domain >> name with varying paths instead of categorically organized subdomains? >> Seems like an implementation detail that can easily be circumvented and >> does not inherently make an enclave more or less secure. >> >> I completely agree with your argument that we should be striving for the >> finest level of granularity with respect to client definition. I >> understand the intentional segregation of logical clients by the >> specification so as to keep one compromised client from affecting the >> entire SSO ecosystem. However, I do think that there is a solid case for a >> single 'client' that does stuff like spans subdomains, and that such a >> client could be used in a secure manner. >> >> At the end of the day, it feels like we're trying to force a definition >> on what is a client. The discussion seems to acknowledge that 'real world' >> application of this spec find wildcards useful (as your suggestion for >> supporting them in the path), however the manner in which they're used >> appropriately is up for debate. If we're living outside the spec anyway, >> do we really have a firm leg to stand on for the assertion that clients can >> have different paths but not subdomains? I don't see a solid reason for >> this one. >> >> Some other thoughts I had on this that might be useful: >> >> - Some of the rub here is that maintaining a list of valid redirects >> for something like string matching is a CM nightmare (particularly in >> dev-ish environments). Something like an SPI to drop an implementation in >> here where I can apply a little more powerful logic would also do the job. >> Could this be used nefariously or poorly to circumvent the specification? >> yeah, sure - but so can Authenticators, and they're seen as a useful tool >> whereby developers can extend necessary functionality. >> - Would you also consider something like a 'development mode' flag >> that allowed for different options such as wildcards in different URL >> parts? Would have to add a little more validation to define what is and is >> not allowed, but would be useful for this case. >> >> Thanks for good the discussion. As always, learning much and enjoying it! >> >> Josh Cain | Software Applications Engineer >> *Identity and Access Management* >> *Red Hat* >> +1 256-452-0150 >> >> On Tue, Sep 20, 2016 at 1:20 AM, Stian Thorgersen >> wrote: >> >>> I appreciate this feature might be useful, so there's no need to discuss >>> that aspect. The only issue I have with this PR is with regards to security >>> and especially as it enables doing the "wrong" thing. >>> >>> With regards to redirect URIs with confidential clients they are still >>> important, but not quite as important as they are for public client. This >>> means redirect URIs can typically be more flexible with confidential >>> clients without a significant risk. >>> >>> For public clients it's very important to lock these down as much as >>> possible as they are the ONLY way to prevent malicious clients to gain >>> access to the SSO session. This means we should actually tighten the >>> requirements for redirect URIs not further relax them. For public clients >>> the redirect URIs: >>> >>> * Should be as specific as possible. We should only allow wildcard in >>> the path. I believe we should introduce this for both public and >>> confidential clients. >>> * Require HTTPs unless it's http://localhost. This is not so easy in >>> development, so maybe we should have an option to run the server in >>> "unsafe" mode for developers. >>> >>> Here's a quote from the OIDC spec around this: >>> >>> *"REQUIRED. Redirection URI to which the response will be sent. This URI >>> MUST exactly match one of the Redirection URI values for the Client >>> pre-registered at the OpenID Provider, with the matching performed as >>> described in Section 6.2.1 of [RFC3986] (Simple String Comparison). The >>> Redirection URI SHOULD use the https scheme; however, it MAY use the http >>> scheme, provided that the Client Type is confidential, as defined in >>> Section 2.1 of OAuth 2.0, and provided the OP allows the use of http >>> Redirection URIs in this case. The Redirection URI MAY use an alternate >>> scheme, such as one that is intended to identify a callback into a native >>> application."* >>> >>> Looking at your comments on the PR it worries me slightly that you have >>> a shared client for a "library". A library is not a client. A client is an >>> instance of an application. Sharing the client will have impact on audit, >>> what clients a user believes they are authenticated to. With regards to >>> wildcard to allow any subdomains that is scary as your allowing any piece >>> of code running on any subdomain within your domain to authenticate via >>> that particular client. That could be an infected forum, something any user >>> has executing, etc.. As long as the redirect URI permits it an application >>> can obtain a token for a client for a user that is authenticated without >>> the user knowing about it. Unless you enable consent that is, but if the >>> user used the "real" client they would have given consent and the malicious >>> client on a different subdomain can take advantage of it. >>> >>> In summary my opinion is that we can't accept this PR and that we >>> further: >>> >>> * Allow wildcard only in path. This is actually still looser than the >>> OIDC spec mandates as it requires a simple string comparison. >>> * Require HTTPS (or custom scheme) for public clients. We may need a >>> development mode that disables this. >>> >>> >>> >>> On 19 September 2016 at 16:50, Josh Cain wrote: >>> >>>> Per KEYCLOAK-3585: >>>> >>>> Currently, valid redirect URI hostnames allow for wildcards at the end >>>> like so: >>>> >>>> http://www.redhat.com/* >>>> >>>> I'm managing several environments where clients need 'n' number of >>>> available redirect URI's with different hostnames, I.E. >>>> >>>> http://developer1.env.redhat.com >>>> >>>> http://developer2.env.redhat.com >>>> >>>> http://developer3.env.redhat.com >>>> >>>> Would really help to have the ability to wildcard hostnames too, I.E.: >>>> >>>> http://*.env.redhat.com >>>> >>>> >>>> I've submitted #3241 >>>> to address this issue, but there seem to be some concerns about allowing >>>> wildcards in other parts of the URL. See the PR for a more fleshed out >>>> discussion, but wanted to start a thread here on the mailing list. >>>> Particularly with respect to: >>>> >>>> - Does anyone have need of this feature or would find it useful? >>>> - Should this kind of wildcard be allowed as a configuration option >>>> by Keycloak? >>>> >>>> Josh Cain | Software Applications Engineer >>>> *Identity and Access Management* >>>> *Red Hat* >>>> +1 256-452-0150 >>>> >>>> _______________________________________________ >>>> keycloak-dev mailing list >>>> keycloak-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>>> >>> >>> >> >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160921/5615f4fc/attachment.html From nielsbne at gmail.com Wed Sep 21 02:39:48 2016 From: nielsbne at gmail.com (Niels Bertram) Date: Wed, 21 Sep 2016 16:39:48 +1000 Subject: [keycloak-dev] Wildcard for Valid Redirect URI Hostname In-Reply-To: References: Message-ID: I actually share Stian's position. Using the same client credentials for a wildcard selection of domain names (I assume different apps) looks like a bad idea. When provisioning these wildcard "clients", are you not able to provision them with a separate set of client credentials via the keycloak admin API? On Tue, Sep 20, 2016 at 12:50 AM, Josh Cain wrote: > Per KEYCLOAK-3585: > > Currently, valid redirect URI hostnames allow for wildcards at the end > like so: > > http://www.redhat.com/* > > I'm managing several environments where clients need 'n' number of > available redirect URI's with different hostnames, I.E. > > http://developer1.env.redhat.com > > http://developer2.env.redhat.com > > http://developer3.env.redhat.com > > Would really help to have the ability to wildcard hostnames too, I.E.: > > http://*.env.redhat.com > > > I've submitted #3241 to > address this issue, but there seem to be some concerns about allowing > wildcards in other parts of the URL. See the PR for a more fleshed out > discussion, but wanted to start a thread here on the mailing list. > Particularly with respect to: > > - Does anyone have need of this feature or would find it useful? > - Should this kind of wildcard be allowed as a configuration option by > Keycloak? > > Josh Cain | Software Applications Engineer > *Identity and Access Management* > *Red Hat* > +1 256-452-0150 > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160921/7d0ccd9a/attachment-0001.html From sthorger at redhat.com Wed Sep 21 06:07:03 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Wed, 21 Sep 2016 12:07:03 +0200 Subject: [keycloak-dev] Keycloak 2.2.1.Final Released Message-ID: Keycloak 2.2.1.Final has just been released. This release fixes an issue in the JavaScript adapter that was introduced in 2.2.0.Final, for more details see KEYCLOAK-3586 . -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160921/a75e903c/attachment.html From postmaster at lists.jboss.org Wed Sep 21 07:21:41 2016 From: postmaster at lists.jboss.org (Returned mail) Date: Wed, 21 Sep 2016 16:51:41 +0530 Subject: [keycloak-dev] (no subject) Message-ID: <201609211123.u8LBNTv7027450@lists01.dmz-a.mwc.hst.phx2.redhat.com> The original message was received at Wed, 21 Sep 2016 16:51:41 +0530 from lists.jboss.org [109.176.2.179] ----- The following addresses had permanent fatal errors ----- keycloak-dev at lists.jboss.org ----- Transcript of session follows ----- ... while talking to 215.76.14.53: 554 5.0.0 Service unavailable; [193.101.159.36] blocked using bl.spamcop.net Session aborted, reason: lost connection -------------- next part -------------- A non-text attachment was scrubbed... Name: message.zip Type: application/octet-stream Size: 29104 bytes Desc: not available Url : http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160921/8684075b/attachment-0001.obj From vramik at redhat.com Wed Sep 21 09:02:16 2016 From: vramik at redhat.com (Vlasta Ramik) Date: Wed, 21 Sep 2016 15:02:16 +0200 Subject: [keycloak-dev] migrate-json Message-ID: <63cf9b07-4d90-dae9-0f51-90b75bc50871@redhat.com> Hi all, I've tried a migration of keycloak-server.json to keycloak-server subsystem following [1]. I had to remove the default content of keycloak-server subsystem to make it work. auth When I left the content unchanged I got [standalone at embedded /] /subsystem=keycloak-server/:migrate-json { "outcome" => "failed", "failure-description" => "WFLYCTL0212: Duplicate resource [ (\"subsystem\" => \"keycloak-server\"), (\"theme\" => \"defaults\") ]", "rolled-back" => true } The question is if it is required step. If so it should be added to the docs [1], if not I'll create a jira. Vlasta [1] https://keycloak.gitbooks.io/server-adminstration-guide/content/v/2.2/topics/MigrationFromOlderVersions.html From ssilvert at redhat.com Wed Sep 21 09:27:38 2016 From: ssilvert at redhat.com (Stan Silvert) Date: Wed, 21 Sep 2016 09:27:38 -0400 Subject: [keycloak-dev] migrate-json In-Reply-To: <63cf9b07-4d90-dae9-0f51-90b75bc50871@redhat.com> References: <63cf9b07-4d90-dae9-0f51-90b75bc50871@redhat.com> Message-ID: <57E28ACA.3050207@redhat.com> On 9/21/2016 9:02 AM, Vlasta Ramik wrote: > Hi all, > > I've tried a migration of keycloak-server.json to keycloak-server > subsystem following [1]. > > I had to remove the default content of keycloak-server subsystem to make > it work. > > > auth > That's correct. The migrate-json tool is meant to be used when you are migrating from an older version of the server. To do that, you would copy your old standalone.xml to the new server and then run migrate-json. You wouldn't migrate a standalone.xml that already has the new subsystem declarations. This probably needs to be made more clear in the documentation. > > When I left the content unchanged I got > > [standalone at embedded /] /subsystem=keycloak-server/:migrate-json > { > "outcome" => "failed", > "failure-description" => "WFLYCTL0212: Duplicate resource [ > (\"subsystem\" => \"keycloak-server\"), > (\"theme\" => \"defaults\") > ]", > "rolled-back" => true > } > > The question is if it is required step. If so it should be added to the > docs [1], if not I'll create a jira. > > Vlasta > > [1] > https://keycloak.gitbooks.io/server-adminstration-guide/content/v/2.2/topics/MigrationFromOlderVersions.html > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev From j.kamal at ymail.com Wed Sep 21 09:41:37 2016 From: j.kamal at ymail.com (Kamal Jagadevan) Date: Wed, 21 Sep 2016 13:41:37 +0000 (UTC) Subject: [keycloak-dev] Reg impersonation In-Reply-To: References: <1815719276.1833582.1474408129771.ref@mail.yahoo.com> <1815719276.1833582.1474408129771@mail.yahoo.com> Message-ID: <288609243.2217444.1474465297423@mail.yahoo.com> Hi Bill,? Thanks for the response. After clicking impersonate button, immediate redirected page is User Account management page, how would you navigate to the app url. I assume login cookie is created for the impersonated user, but entering the app URL on the browser takes me to the login page for authentication. Do you have any other inputs to troubleshoot this further. ThanksKamal From: Bill Burke To: keycloak-dev at lists.jboss.org Sent: Tuesday, September 20, 2016 8:12 PM Subject: Re: [keycloak-dev] Reg impersonation When you impersonate from admin console, you are logged in as that user and can view any app the user can. On 9/20/16 5:48 PM, Kamal Jagadevan wrote: Hello Keycloak Team, ??? Is there a way to use impersonation feature to view/log into applications (protected by Keycloak) instead of viewing impersonated user?s User Account Management page? If not, is there a plan in road map to support them in future? Best Kamal _______________________________________________ keycloak-dev mailing list keycloak-dev at lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-dev _______________________________________________ keycloak-dev mailing list keycloak-dev at lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160921/4d022e9e/attachment.html From josh.cain at redhat.com Wed Sep 21 10:10:46 2016 From: josh.cain at redhat.com (Josh Cain) Date: Wed, 21 Sep 2016 09:10:46 -0500 Subject: [keycloak-dev] Wildcard for Valid Redirect URI Hostname In-Reply-To: References: Message-ID: On Wed, Sep 21, 2016 at 1:12 AM, Stian Thorgersen wrote: > > > On 20 September 2016 at 16:15, Josh Cain wrote: > >> So I certainly get that we want to be as close to the spec as possible - >> wholeheartedly agree. However, I'd also like to reiterate that the main >> purpose of this is for lower/developer environments in which there are a >> large number of developers who are frequently spinning up sanboxes with >> apps that need SSO capabilities. Unless I want to open up the GUI in these >> environments to the world, I'm left without a good CM option for Keycloak. >> Any suggestions on the management of this? Right now I'm looking at a high >> amount of manual overhead, or scripting it out with some one-off config >> scripts that I'll have to wind up maintaining. Neither option sounds >> appealing. >> > > +1 This is a use-case we need to find a solution to > Cool. Keep me posted - in the meantime I've started cobbling together a few JAXRS scripts against the admin endpoint, but would ideally like something more CM-y. Maybe something like ansible integration... > > >> >> Hope you didn't get the wrong impression from the PR - I noted a >> javascript library that was shared across several pages within a number of >> subdomains. All pages share a similar look and feel, but due to the nature >> of the content and topic can live at different subdomains or even have >> slightly different page content implementations. Are we really going to >> make the assertion that a 'client' cannot span subdomains? That seems to >> be the implication here. And if so, is that necessarily more 'secure', or >> does that just mean that implementers could simply favor a single domain >> name with varying paths instead of categorically organized subdomains? >> Seems like an implementation detail that can easily be circumvented and >> does not inherently make an enclave more or less secure. >> > > A shared JavaScript library is not an client/application it's a library. > Not sure how you can argue that it's a client. A client has more than just > a redirect uri. It has: > > * Base URL - so users can find the application. This will be more useful > in the future once we introduce a SSO landing page and provide links to > applications from the account management console > * Consent - clients that require consents should allow users to give > consent per-application, not per-library > * Audit/log - audit and log both in admin console and account management > relies on knowing what application, not what library, accessed a users > account > > I really think you are misusing the concept of a client when you are using > a client for a library and I disagree that this is a valid use-case. You > are doing something wrong here. > Thanks for further examining this use case, and I'm certainly open to hearing you on this one if we're 'doing something wrong.' I do have some further questions clarifying what that 'something' is. - Where does the Base URL requirement come from? I've not seen that in any of the specifications. Is it more of a pragmatic best-practice-ish kind of approach? If so, do we have evidence of industry-wide adherence such that we can enforce it with a product? - Let me make sure I understand your point about mis-using a javascript 'library'. It feels like you're indicating that something like a javascript status bar that uses keycloak.js can share the same 'client' if, and only if, they share the same domain. So to illustrate, this would be allowed: ? ?Since the above pages share the same 'Base URL', they may rightfully be considered as 'valid' by Keycloak. However, according to the current Keycloak implementation, the below diagram demonstrates how the same application would *not* be allowed to delineate itself with the use of subdomains: ? ?This constrains seems superficial for this use case. Am I understanding this correctly? Again, I would contest that a logical 'application' can be comprised of pages split across subdomains. What's more, sharing the same base URL provides no guarantee of proper granularity for definition of a single 'application'. > > >> >> I completely agree with your argument that we should be striving for the >> finest level of granularity with respect to client definition. I >> understand the intentional segregation of logical clients by the >> specification so as to keep one compromised client from affecting the >> entire SSO ecosystem. However, I do think that there is a solid case for a >> single 'client' that does stuff like spans subdomains, and that such a >> client could be used in a secure manner. >> > > Can you give me a real example of where an application has multiple > subdomains? I just don't see it. > Sure. amazon.com uses smile.amazon.com for its charitable donation giving. At the end of the day it's exactly the *same* site, but with slightly different content. Same "Application", but residing on a different subdomain. Could probably crawl some frequently used sites to find more, but that one came to mind first. Are there any standards/restrictions/stated best practices against this? This is the first time I've run up against problems with subdomains used in this way, but I'm certainly open to hearing if it's in violation of one of the above. > > >> >> At the end of the day, it feels like we're trying to force a definition >> on what is a client. The discussion seems to acknowledge that 'real world' >> application of this spec find wildcards useful (as your suggestion for >> supporting them in the path), however the manner in which they're used >> appropriately is up for debate. If we're living outside the spec anyway, >> do we really have a firm leg to stand on for the assertion that clients can >> have different paths but not subdomains? I don't see a solid reason for >> this one. >> > > We shouldn't have had the wildcard in the first place. The reason we need > it is that our adapters use the current path for the application as the > redirect-uri. In other OIDC providers you are limited to a simple string > matching in which case it's usual to have a callback endpoint and encode > the path in the state parameter. > > >> >> Some other thoughts I had on this that might be useful: >> >> - Some of the rub here is that maintaining a list of valid redirects >> for something like string matching is a CM nightmare (particularly in >> dev-ish environments). Something like an SPI to drop an implementation in >> here where I can apply a little more powerful logic would also do the job. >> Could this be used nefariously or poorly to circumvent the specification? >> yeah, sure - but so can Authenticators, and they're seen as a useful tool >> whereby developers can extend necessary functionality. >> - Would you also consider something like a 'development mode' flag >> that allowed for different options such as wildcards in different URL >> parts? Would have to add a little more validation to define what is and is >> not allowed, but would be useful for this case. >> >> I had the idea of an SPI or a developer mode, but ideally we'd find > another way to deal with this. > > Have you looked at dynamic client registration by the way? That allows > registering clients without UI access and with a limited initial access > token. We're also soon going to have a client registration CLI that allows > doing this. > I'll dig into that more - I've not taken more than a cursory glance at it. If we have more fine-grained control over token/client access it could certainly be useful. > > >> Thanks for good the discussion. As always, learning much and enjoying it! >> >> Josh Cain | Software Applications Engineer >> *Identity and Access Management* >> *Red Hat* >> +1 256-452-0150 >> >> On Tue, Sep 20, 2016 at 1:20 AM, Stian Thorgersen >> wrote: >> >>> I appreciate this feature might be useful, so there's no need to discuss >>> that aspect. The only issue I have with this PR is with regards to security >>> and especially as it enables doing the "wrong" thing. >>> >>> With regards to redirect URIs with confidential clients they are still >>> important, but not quite as important as they are for public client. This >>> means redirect URIs can typically be more flexible with confidential >>> clients without a significant risk. >>> >>> For public clients it's very important to lock these down as much as >>> possible as they are the ONLY way to prevent malicious clients to gain >>> access to the SSO session. This means we should actually tighten the >>> requirements for redirect URIs not further relax them. For public clients >>> the redirect URIs: >>> >>> * Should be as specific as possible. We should only allow wildcard in >>> the path. I believe we should introduce this for both public and >>> confidential clients. >>> * Require HTTPs unless it's http://localhost. This is not so easy in >>> development, so maybe we should have an option to run the server in >>> "unsafe" mode for developers. >>> >>> Here's a quote from the OIDC spec around this: >>> >>> *"REQUIRED. Redirection URI to which the response will be sent. This URI >>> MUST exactly match one of the Redirection URI values for the Client >>> pre-registered at the OpenID Provider, with the matching performed as >>> described in Section 6.2.1 of [RFC3986] (Simple String Comparison). The >>> Redirection URI SHOULD use the https scheme; however, it MAY use the http >>> scheme, provided that the Client Type is confidential, as defined in >>> Section 2.1 of OAuth 2.0, and provided the OP allows the use of http >>> Redirection URIs in this case. The Redirection URI MAY use an alternate >>> scheme, such as one that is intended to identify a callback into a native >>> application."* >>> >>> Looking at your comments on the PR it worries me slightly that you have >>> a shared client for a "library". A library is not a client. A client is an >>> instance of an application. Sharing the client will have impact on audit, >>> what clients a user believes they are authenticated to. With regards to >>> wildcard to allow any subdomains that is scary as your allowing any piece >>> of code running on any subdomain within your domain to authenticate via >>> that particular client. That could be an infected forum, something any user >>> has executing, etc.. As long as the redirect URI permits it an application >>> can obtain a token for a client for a user that is authenticated without >>> the user knowing about it. Unless you enable consent that is, but if the >>> user used the "real" client they would have given consent and the malicious >>> client on a different subdomain can take advantage of it. >>> >>> In summary my opinion is that we can't accept this PR and that we >>> further: >>> >>> * Allow wildcard only in path. This is actually still looser than the >>> OIDC spec mandates as it requires a simple string comparison. >>> * Require HTTPS (or custom scheme) for public clients. We may need a >>> development mode that disables this. >>> >>> >>> >>> On 19 September 2016 at 16:50, Josh Cain wrote: >>> >>>> Per KEYCLOAK-3585: >>>> >>>> Currently, valid redirect URI hostnames allow for wildcards at the end >>>> like so: >>>> >>>> http://www.redhat.com/* >>>> >>>> I'm managing several environments where clients need 'n' number of >>>> available redirect URI's with different hostnames, I.E. >>>> >>>> http://developer1.env.redhat.com >>>> >>>> http://developer2.env.redhat.com >>>> >>>> http://developer3.env.redhat.com >>>> >>>> Would really help to have the ability to wildcard hostnames too, I.E.: >>>> >>>> http://*.env.redhat.com >>>> >>>> >>>> I've submitted #3241 >>>> to address this issue, but there seem to be some concerns about allowing >>>> wildcards in other parts of the URL. See the PR for a more fleshed out >>>> discussion, but wanted to start a thread here on the mailing list. >>>> Particularly with respect to: >>>> >>>> - Does anyone have need of this feature or would find it useful? >>>> - Should this kind of wildcard be allowed as a configuration option >>>> by Keycloak? >>>> >>>> Josh Cain | Software Applications Engineer >>>> *Identity and Access Management* >>>> *Red Hat* >>>> +1 256-452-0150 >>>> >>>> _______________________________________________ >>>> keycloak-dev mailing list >>>> keycloak-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>>> >>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160921/8ffb6d8f/attachment-0001.html -------------- next part -------------- A non-text attachment was scrubbed... Name: javascriptlibpath.png Type: image/png Size: 63746 bytes Desc: not available Url : http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160921/8ffb6d8f/attachment-0002.png -------------- next part -------------- A non-text attachment was scrubbed... Name: javascriptlibdomain.png Type: image/png Size: 73920 bytes Desc: not available Url : http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160921/8ffb6d8f/attachment-0003.png From shmuein+keycloak-dev at gmail.com Wed Sep 21 10:35:57 2016 From: shmuein+keycloak-dev at gmail.com (Muein Muzamil) Date: Wed, 21 Sep 2016 09:35:57 -0500 Subject: [keycloak-dev] Running KeyCloak in cluster mode Message-ID: Hi all, I am trying to run KeyCloak in cluster mode with docker containers using standalone-ha.xml but for me containers are not joining the same infinispan cluster. I tried to follow following blog entry but not sure it is still valid. http://blog.keycloak.org/2015/04/running-keycloak-cluster-with-docker.html I was trying to follow this to run multiple docker containers in cluster with the latest images. But when I ran second keycloak container, I didn't see this container joining the 1st cluster. I was seeing this in the log for the second container. [0m[0m12:31:56,385 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-2) ISPN000094: Received new cluster view for channel keycloak: [saskeycloak-fbtit|0] (1) [saskeycloak-fbtit] To get it working I had to update private interface in standalone-ha.xml to use docker container's IP. Is that really needed or do we have a better way to get it working? Regards, Muein -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160921/efe65f24/attachment.html From shmuein+keycloak-dev at gmail.com Wed Sep 21 20:22:03 2016 From: shmuein+keycloak-dev at gmail.com (Muein Muzamil) Date: Wed, 21 Sep 2016 19:22:03 -0500 Subject: [keycloak-dev] Accessing SAML Request attributes in Authenticaors In-Reply-To: References: Message-ID: Hi all, This is a feature we need for some SP integrations, so if we don't support this feature that is ok. We can probably implement this and generate a pull request for this. But can someone please share some feedback how this should be implemented. Thanks in advance for your feedback on this. Regards, Muein On Thu, Sep 15, 2016 at 10:05 AM, Muein Muzamil < shmuein+keycloak-dev at gmail.com> wrote: > Hi all, > > Not sure if my question was clear enough, feel free to ask for > clarifications if needed. > > I will really appreciate some response on this. > > Best regards, > Muein > > On Tue, Sep 13, 2016 at 10:29 AM, Muein Muzamil < > shmuein+keycloak-dev at gmail.com> wrote: > >> Hi all, >> >> Any pointers to this? I was looking at the SAMLAuthNRequestParser class >> and it seems we are parsing the subject from the incoming request. Now the >> question is how can I access it in my custom authenticator? >> >> else if (JBossSAMLConstants.SUBJECT.get().equals(elementName)) { >> authnRequest.setSubject(getSubject(xmlEventReader)); >> } >> >> Regards, >> Muein >> >> On Fri, Sep 9, 2016 at 3:20 PM, Muein Muzamil < >> shmuein+keycloak-dev at gmail.com> wrote: >> >>> Hi all, >>> >>> We are trying to integrate with an SP which sends Subject/NameID in the >>> Saml Request (copying example below). I have couple of questions in this >>> regard >>> >>> >>> 1. In our custom authenticator, we want to access this NameId and >>> want to pre-fill username field based on this. Can you please guide me how >>> can I do that. >>> 2. Secondly, I am currently using KeyCloak JBoss Adapter for my >>> sample SP, does the SAML Adapter supports sending nameId in SAML request? >>> >>> >> IssueInstant="2016-02-24T15:45:55.325Z" >>> ID="ID112bf5b0e4169930b663f2d89e62c521fc2f1b8133598fa2ff" >>> xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"> >>> >>> >>> http://pingone.com/xxx/640d3755-e080-4a87-8f7f-91795e78c08d>> uer> >>> >>> jdoe at mysecureauthentication.com >>> >>> >>> >>> >>> >>> Regards, >>> Muein >>> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160921/9fdd1844/attachment.html From shmuein+keycloak-dev at gmail.com Wed Sep 21 21:31:59 2016 From: shmuein+keycloak-dev at gmail.com (Muein Muzamil) Date: Wed, 21 Sep 2016 20:31:59 -0500 Subject: [keycloak-dev] Accessing SAML Request attributes in Authenticaors In-Reply-To: References: Message-ID: Just to add to my previous email, I looked into the code and came across SAMlService::loginRequest method where we are setting different SAML parameters into client session. So we can imagine setting NameID also in the session notes at that point. If this change makes sense then do let me know and I can modify the code and can generate the pull request. Or if you would like to do this yourself, even then this is fine with me :). Regards, Muein On Wed, Sep 21, 2016 at 7:22 PM, Muein Muzamil < shmuein+keycloak-dev at gmail.com> wrote: > Hi all, > > This is a feature we need for some SP integrations, so if we don't support > this feature that is ok. We can probably implement this and generate a pull > request for this. But can someone please share some feedback how this > should be implemented. > > Thanks in advance for your feedback on this. > > Regards, > Muein > > On Thu, Sep 15, 2016 at 10:05 AM, Muein Muzamil < > shmuein+keycloak-dev at gmail.com> wrote: > >> Hi all, >> >> Not sure if my question was clear enough, feel free to ask for >> clarifications if needed. >> >> I will really appreciate some response on this. >> >> Best regards, >> Muein >> >> On Tue, Sep 13, 2016 at 10:29 AM, Muein Muzamil < >> shmuein+keycloak-dev at gmail.com> wrote: >> >>> Hi all, >>> >>> Any pointers to this? I was looking at the SAMLAuthNRequestParser class >>> and it seems we are parsing the subject from the incoming request. Now the >>> question is how can I access it in my custom authenticator? >>> >>> else if (JBossSAMLConstants.SUBJECT.get().equals(elementName)) { >>> authnRequest.setSubject(getSubject(xmlEventReader)); >>> } >>> >>> Regards, >>> Muein >>> >>> On Fri, Sep 9, 2016 at 3:20 PM, Muein Muzamil < >>> shmuein+keycloak-dev at gmail.com> wrote: >>> >>>> Hi all, >>>> >>>> We are trying to integrate with an SP which sends Subject/NameID in the >>>> Saml Request (copying example below). I have couple of questions in this >>>> regard >>>> >>>> >>>> 1. In our custom authenticator, we want to access this NameId and >>>> want to pre-fill username field based on this. Can you please guide me how >>>> can I do that. >>>> 2. Secondly, I am currently using KeyCloak JBoss Adapter for my >>>> sample SP, does the SAML Adapter supports sending nameId in SAML request? >>>> >>>> >>> IssueInstant="2016-02-24T15:45:55.325Z" >>>> ID="ID112bf5b0e4169930b663f2d89e62c521fc2f1b8133598fa2ff" >>>> xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"> >>>> >>>> >>>> http://pingone.com/xxx/640d3755-e080-4a87-8f7f-91795e78c08d>>> uer> >>>> >>>> jdoe at mysecureauthentication.com >>>> >>>> >>>> >>>> >>>> >>>> Regards, >>>> Muein >>>> >>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160921/12f50d3d/attachment.html From sthorger at redhat.com Thu Sep 22 03:27:54 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Thu, 22 Sep 2016 09:27:54 +0200 Subject: [keycloak-dev] Wildcard for Valid Redirect URI Hostname In-Reply-To: References: Message-ID: On 21 September 2016 at 16:10, Josh Cain wrote: > On Wed, Sep 21, 2016 at 1:12 AM, Stian Thorgersen > wrote: > >> >> >> On 20 September 2016 at 16:15, Josh Cain wrote: >> >>> So I certainly get that we want to be as close to the spec as possible - >>> wholeheartedly agree. However, I'd also like to reiterate that the main >>> purpose of this is for lower/developer environments in which there are a >>> large number of developers who are frequently spinning up sanboxes with >>> apps that need SSO capabilities. Unless I want to open up the GUI in these >>> environments to the world, I'm left without a good CM option for Keycloak. >>> Any suggestions on the management of this? Right now I'm looking at a high >>> amount of manual overhead, or scripting it out with some one-off config >>> scripts that I'll have to wind up maintaining. Neither option sounds >>> appealing. >>> >> >> +1 This is a use-case we need to find a solution to >> > > Cool. Keep me posted - in the meantime I've started cobbling together a > few JAXRS scripts against the admin endpoint, but would ideally like > something more CM-y. Maybe something like ansible integration... > >> >> >>> >>> Hope you didn't get the wrong impression from the PR - I noted a >>> javascript library that was shared across several pages within a number of >>> subdomains. All pages share a similar look and feel, but due to the nature >>> of the content and topic can live at different subdomains or even have >>> slightly different page content implementations. Are we really going to >>> make the assertion that a 'client' cannot span subdomains? That seems to >>> be the implication here. And if so, is that necessarily more 'secure', or >>> does that just mean that implementers could simply favor a single domain >>> name with varying paths instead of categorically organized subdomains? >>> Seems like an implementation detail that can easily be circumvented and >>> does not inherently make an enclave more or less secure. >>> >> >> A shared JavaScript library is not an client/application it's a library. >> Not sure how you can argue that it's a client. A client has more than just >> a redirect uri. It has: >> >> * Base URL - so users can find the application. This will be more useful >> in the future once we introduce a SSO landing page and provide links to >> applications from the account management console >> * Consent - clients that require consents should allow users to give >> consent per-application, not per-library >> * Audit/log - audit and log both in admin console and account management >> relies on knowing what application, not what library, accessed a users >> account >> >> I really think you are misusing the concept of a client when you are >> using a client for a library and I disagree that this is a valid use-case. >> You are doing something wrong here. >> > > Thanks for further examining this use case, and I'm certainly open to > hearing you on this one if we're 'doing something wrong.' I do have some > further questions clarifying what that 'something' is. > > - Where does the Base URL requirement come from? I've not seen that > in any of the specifications. Is it more of a pragmatic best-practice-ish > kind of approach? If so, do we have evidence of industry-wide adherence > such that we can enforce it with a product? > - Let me make sure I understand your point about mis-using a > javascript 'library'. It feels like you're indicating that something like > a javascript status bar that uses keycloak.js can share the same 'client' > if, and only if, they share the same domain. So to illustrate, this would > be allowed: > > ? > > ?Since the above pages share the same 'Base URL', they may rightfully be > considered as 'valid' by Keycloak. However, according to the current > Keycloak implementation, the below diagram demonstrates how the same > application would *not* be allowed to delineate itself with the use of > subdomains: > > ? > > ?This constrains seems superficial for this use case. Am I understanding > this correctly? > > Again, I would contest that a logical 'application' can be comprised of > pages split across subdomains. What's more, sharing the same base URL > provides no guarantee of proper granularity for definition of a single > 'application'. > Your example there makes sense to me and I agree that in this case it could make sense to use the same client across multiple subdomains. I assumed you had a login status library that was reused on different applications. That doesn't justify having a wildcard for subdomain though. You should have separate redirect uris for each subdomain. > >> >>> >>> I completely agree with your argument that we should be striving for the >>> finest level of granularity with respect to client definition. I >>> understand the intentional segregation of logical clients by the >>> specification so as to keep one compromised client from affecting the >>> entire SSO ecosystem. However, I do think that there is a solid case for a >>> single 'client' that does stuff like spans subdomains, and that such a >>> client could be used in a secure manner. >>> >> >> Can you give me a real example of where an application has multiple >> subdomains? I just don't see it. >> > > Sure. amazon.com uses smile.amazon.com for its charitable donation > giving. At the end of the day it's exactly the *same* site, but with > slightly different content. Same "Application", but residing on a > different subdomain. Could probably crawl some frequently used sites to > find more, but that one came to mind first. > Actually I think that's a bad example and in that case it should be two separate clients. > > Are there any standards/restrictions/stated best practices against this? > This is the first time I've run up against problems with subdomains used in > this way, but I'm certainly open to hearing if it's in violation of one of > the above. > OIDC for one says simple string matching for redirect uris. I don't have any issue with splitting a client into subdomains if that makes sense (didn't think it did, but you've convinced me). My issue was purely with accepting wildcard for the subdomain as that allows all subdomains, not a clearly specified set. > >> >>> >>> At the end of the day, it feels like we're trying to force a definition >>> on what is a client. The discussion seems to acknowledge that 'real world' >>> application of this spec find wildcards useful (as your suggestion for >>> supporting them in the path), however the manner in which they're used >>> appropriately is up for debate. If we're living outside the spec anyway, >>> do we really have a firm leg to stand on for the assertion that clients can >>> have different paths but not subdomains? I don't see a solid reason for >>> this one. >>> >> >> We shouldn't have had the wildcard in the first place. The reason we need >> it is that our adapters use the current path for the application as the >> redirect-uri. In other OIDC providers you are limited to a simple string >> matching in which case it's usual to have a callback endpoint and encode >> the path in the state parameter. >> >> >>> >>> Some other thoughts I had on this that might be useful: >>> >>> - Some of the rub here is that maintaining a list of valid redirects >>> for something like string matching is a CM nightmare (particularly in >>> dev-ish environments). Something like an SPI to drop an implementation in >>> here where I can apply a little more powerful logic would also do the job. >>> Could this be used nefariously or poorly to circumvent the specification? >>> yeah, sure - but so can Authenticators, and they're seen as a useful tool >>> whereby developers can extend necessary functionality. >>> - Would you also consider something like a 'development mode' flag >>> that allowed for different options such as wildcards in different URL >>> parts? Would have to add a little more validation to define what is and is >>> not allowed, but would be useful for this case. >>> >>> I had the idea of an SPI or a developer mode, but ideally we'd find >> another way to deal with this. >> >> Have you looked at dynamic client registration by the way? That allows >> registering clients without UI access and with a limited initial access >> token. We're also soon going to have a client registration CLI that allows >> doing this. >> > > I'll dig into that more - I've not taken more than a cursory glance at > it. If we have more fine-grained control over token/client access it could > certainly be useful. > > >> >> >>> Thanks for good the discussion. As always, learning much and enjoying >>> it! >>> >>> Josh Cain | Software Applications Engineer >>> *Identity and Access Management* >>> *Red Hat* >>> +1 256-452-0150 >>> >>> On Tue, Sep 20, 2016 at 1:20 AM, Stian Thorgersen >>> wrote: >>> >>>> I appreciate this feature might be useful, so there's no need to >>>> discuss that aspect. The only issue I have with this PR is with regards to >>>> security and especially as it enables doing the "wrong" thing. >>>> >>>> With regards to redirect URIs with confidential clients they are still >>>> important, but not quite as important as they are for public client. This >>>> means redirect URIs can typically be more flexible with confidential >>>> clients without a significant risk. >>>> >>>> For public clients it's very important to lock these down as much as >>>> possible as they are the ONLY way to prevent malicious clients to gain >>>> access to the SSO session. This means we should actually tighten the >>>> requirements for redirect URIs not further relax them. For public clients >>>> the redirect URIs: >>>> >>>> * Should be as specific as possible. We should only allow wildcard in >>>> the path. I believe we should introduce this for both public and >>>> confidential clients. >>>> * Require HTTPs unless it's http://localhost. This is not so easy in >>>> development, so maybe we should have an option to run the server in >>>> "unsafe" mode for developers. >>>> >>>> Here's a quote from the OIDC spec around this: >>>> >>>> *"REQUIRED. Redirection URI to which the response will be sent. This >>>> URI MUST exactly match one of the Redirection URI values for the Client >>>> pre-registered at the OpenID Provider, with the matching performed as >>>> described in Section 6.2.1 of [RFC3986] (Simple String Comparison). The >>>> Redirection URI SHOULD use the https scheme; however, it MAY use the http >>>> scheme, provided that the Client Type is confidential, as defined in >>>> Section 2.1 of OAuth 2.0, and provided the OP allows the use of http >>>> Redirection URIs in this case. The Redirection URI MAY use an alternate >>>> scheme, such as one that is intended to identify a callback into a native >>>> application."* >>>> >>>> Looking at your comments on the PR it worries me slightly that you have >>>> a shared client for a "library". A library is not a client. A client is an >>>> instance of an application. Sharing the client will have impact on audit, >>>> what clients a user believes they are authenticated to. With regards to >>>> wildcard to allow any subdomains that is scary as your allowing any piece >>>> of code running on any subdomain within your domain to authenticate via >>>> that particular client. That could be an infected forum, something any user >>>> has executing, etc.. As long as the redirect URI permits it an application >>>> can obtain a token for a client for a user that is authenticated without >>>> the user knowing about it. Unless you enable consent that is, but if the >>>> user used the "real" client they would have given consent and the malicious >>>> client on a different subdomain can take advantage of it. >>>> >>>> In summary my opinion is that we can't accept this PR and that we >>>> further: >>>> >>>> * Allow wildcard only in path. This is actually still looser than the >>>> OIDC spec mandates as it requires a simple string comparison. >>>> * Require HTTPS (or custom scheme) for public clients. We may need a >>>> development mode that disables this. >>>> >>>> >>>> >>>> On 19 September 2016 at 16:50, Josh Cain wrote: >>>> >>>>> Per KEYCLOAK-3585: >>>>> >>>>> Currently, valid redirect URI hostnames allow for wildcards at the end >>>>> like so: >>>>> >>>>> http://www.redhat.com/* >>>>> >>>>> I'm managing several environments where clients need 'n' number of >>>>> available redirect URI's with different hostnames, I.E. >>>>> >>>>> http://developer1.env.redhat.com >>>>> >>>>> http://developer2.env.redhat.com >>>>> >>>>> http://developer3.env.redhat.com >>>>> >>>>> Would really help to have the ability to wildcard hostnames too, I.E.: >>>>> >>>>> http://*.env.redhat.com >>>>> >>>>> >>>>> I've submitted #3241 >>>>> to address this issue, but there seem to be some concerns about allowing >>>>> wildcards in other parts of the URL. See the PR for a more fleshed out >>>>> discussion, but wanted to start a thread here on the mailing list. >>>>> Particularly with respect to: >>>>> >>>>> - Does anyone have need of this feature or would find it useful? >>>>> - Should this kind of wildcard be allowed as a configuration >>>>> option by Keycloak? >>>>> >>>>> Josh Cain | Software Applications Engineer >>>>> *Identity and Access Management* >>>>> *Red Hat* >>>>> +1 256-452-0150 >>>>> >>>>> _______________________________________________ >>>>> keycloak-dev mailing list >>>>> keycloak-dev at lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>>>> >>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160922/6e2d9068/attachment-0001.html -------------- next part -------------- A non-text attachment was scrubbed... Name: javascriptlibpath.png Type: image/png Size: 63746 bytes Desc: not available Url : http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160922/6e2d9068/attachment-0002.png -------------- next part -------------- A non-text attachment was scrubbed... Name: javascriptlibdomain.png Type: image/png Size: 73920 bytes Desc: not available Url : http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160922/6e2d9068/attachment-0003.png From sthorger at redhat.com Thu Sep 22 03:30:56 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Thu, 22 Sep 2016 09:30:56 +0200 Subject: [keycloak-dev] Running KeyCloak in cluster mode In-Reply-To: References: Message-ID: Yes, that's needed. JGroups is by default bound to 127.0.0.1 and should in best practice be bound to a private secure network to limit access. See https://keycloak.gitbooks.io/server-installation-and-configuration/content/topics/clustering/multicast.html for more details. On 21 September 2016 at 16:35, Muein Muzamil wrote: > Hi all, > > I am trying to run KeyCloak in cluster mode with docker containers using > standalone-ha.xml but for me containers are not joining the same infinispan > cluster. > > > I tried to follow following blog entry but not sure it is still valid. > http://blog.keycloak.org/2015/04/running-keycloak-cluster-with-docker.html > > > I was trying to follow this to run multiple docker containers in cluster > with the latest images. But when I ran second keycloak container, I didn't > see this container joining the 1st cluster. I was seeing this in the log > for the second container. > > [0m[0m12:31:56,385 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] > (MSC service thread 1-2) ISPN000094: Received new cluster view for channel > keycloak: [saskeycloak-fbtit|0] (1) [saskeycloak-fbtit] > > > To get it working I had to update private interface in standalone-ha.xml > to use docker container's IP. > > > > > > > Is that really needed or do we have a better way to get it working? > > Regards, > Muein > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160922/1a538c87/attachment.html From josh.cain at redhat.com Thu Sep 22 16:54:51 2016 From: josh.cain at redhat.com (Josh Cain) Date: Thu, 22 Sep 2016 15:54:51 -0500 Subject: [keycloak-dev] Wildcard for Valid Redirect URI Hostname In-Reply-To: References: Message-ID: On Thu, Sep 22, 2016 at 2:27 AM, Stian Thorgersen wrote: > > > On 21 September 2016 at 16:10, Josh Cain wrote: > >> On Wed, Sep 21, 2016 at 1:12 AM, Stian Thorgersen >> wrote: >> >>> >>> >>> On 20 September 2016 at 16:15, Josh Cain wrote: >>> >>>> So I certainly get that we want to be as close to the spec as possible >>>> - wholeheartedly agree. However, I'd also like to reiterate that the main >>>> purpose of this is for lower/developer environments in which there are a >>>> large number of developers who are frequently spinning up sanboxes with >>>> apps that need SSO capabilities. Unless I want to open up the GUI in these >>>> environments to the world, I'm left without a good CM option for Keycloak. >>>> Any suggestions on the management of this? Right now I'm looking at a high >>>> amount of manual overhead, or scripting it out with some one-off config >>>> scripts that I'll have to wind up maintaining. Neither option sounds >>>> appealing. >>>> >>> >>> +1 This is a use-case we need to find a solution to >>> >> >> Cool. Keep me posted - in the meantime I've started cobbling together a >> few JAXRS scripts against the admin endpoint, but would ideally like >> something more CM-y. Maybe something like ansible integration... >> >>> >>> >>>> >>>> Hope you didn't get the wrong impression from the PR - I noted a >>>> javascript library that was shared across several pages within a number of >>>> subdomains. All pages share a similar look and feel, but due to the nature >>>> of the content and topic can live at different subdomains or even have >>>> slightly different page content implementations. Are we really going to >>>> make the assertion that a 'client' cannot span subdomains? That seems to >>>> be the implication here. And if so, is that necessarily more 'secure', or >>>> does that just mean that implementers could simply favor a single domain >>>> name with varying paths instead of categorically organized subdomains? >>>> Seems like an implementation detail that can easily be circumvented and >>>> does not inherently make an enclave more or less secure. >>>> >>> >>> A shared JavaScript library is not an client/application it's a library. >>> Not sure how you can argue that it's a client. A client has more than just >>> a redirect uri. It has: >>> >>> * Base URL - so users can find the application. This will be more useful >>> in the future once we introduce a SSO landing page and provide links to >>> applications from the account management console >>> * Consent - clients that require consents should allow users to give >>> consent per-application, not per-library >>> * Audit/log - audit and log both in admin console and account management >>> relies on knowing what application, not what library, accessed a users >>> account >>> >>> I really think you are misusing the concept of a client when you are >>> using a client for a library and I disagree that this is a valid use-case. >>> You are doing something wrong here. >>> >> >> Thanks for further examining this use case, and I'm certainly open to >> hearing you on this one if we're 'doing something wrong.' I do have some >> further questions clarifying what that 'something' is. >> >> - Where does the Base URL requirement come from? I've not seen that >> in any of the specifications. Is it more of a pragmatic best-practice-ish >> kind of approach? If so, do we have evidence of industry-wide adherence >> such that we can enforce it with a product? >> - Let me make sure I understand your point about mis-using a >> javascript 'library'. It feels like you're indicating that something like >> a javascript status bar that uses keycloak.js can share the same 'client' >> if, and only if, they share the same domain. So to illustrate, this would >> be allowed: >> >> ? >> >> ?Since the above pages share the same 'Base URL', they may rightfully be >> considered as 'valid' by Keycloak. However, according to the current >> Keycloak implementation, the below diagram demonstrates how the same >> application would *not* be allowed to delineate itself with the use of >> subdomains: >> >> ? >> >> ?This constrains seems superficial for this use case. Am I understanding >> this correctly? >> >> Again, I would contest that a logical 'application' can be comprised of >> pages split across subdomains. What's more, sharing the same base URL >> provides no guarantee of proper granularity for definition of a single >> 'application'. >> > Your example there makes sense to me and I agree that in this case it > could make sense to use the same client across multiple subdomains. I > assumed you had a login status library that was reused on different > applications. > > That doesn't justify having a wildcard for subdomain though. You should > have separate redirect uris for each subdomain. > I think we might have to just agree to disagree on this one. I think that there remains a justification for wildcarding a subdomain since it can be secured properly and would save on administrative burden. Same use case for wildcards in the path, just a different URL element. > >>> >>>> >>>> I completely agree with your argument that we should be striving for >>>> the finest level of granularity with respect to client definition. I >>>> understand the intentional segregation of logical clients by the >>>> specification so as to keep one compromised client from affecting the >>>> entire SSO ecosystem. However, I do think that there is a solid case for a >>>> single 'client' that does stuff like spans subdomains, and that such a >>>> client could be used in a secure manner. >>>> >>> >>> Can you give me a real example of where an application has multiple >>> subdomains? I just don't see it. >>> >> >> Sure. amazon.com uses smile.amazon.com for its charitable donation >> giving. At the end of the day it's exactly the *same* site, but with >> slightly different content. Same "Application", but residing on a >> different subdomain. Could probably crawl some frequently used sites to >> find more, but that one came to mind first. >> > > Actually I think that's a bad example and in that case it should be two > separate clients. > > Really? So an app that has almost *exactly* identical function with some stylistic and business rule differences deserves to be treated as a different client altogether. Will kindly disagree, but note that there's also disagreement on this one in implementations across the internet. For instance, Stack overflow treats each different topic's forum as a client, and these happen to be delineated by subdomains (however, notifications are shared across all sites which is a bit of a mixed message if you asked me). Whereas github ( gist.github.com), Facebook (m.facebook.com, touch.facebook.com, etc), or Amazon (smile.amazon.com) will let a single app/account span subdomains. I suppose the point was not so much to argue about which way is the purest implementation, but more to align product features with valid, real-world use cases. > >> Are there any standards/restrictions/stated best practices against this? >> This is the first time I've run up against problems with subdomains used in >> this way, but I'm certainly open to hearing if it's in violation of one of >> the above. >> > > OIDC for one says simple string matching for redirect uris. I don't have > any issue with splitting a client into subdomains if that makes sense > (didn't think it did, but you've convinced me). My issue was purely with > accepting wildcard for the subdomain as that allows all subdomains, not a > clearly specified set. > See above - don't see how we can allow wildcards in path for pragmatic purposes (outside the spec) but exclude the domain from the same treatment. I'm for allowing both. Will take this one as a hard 'no' since the discussion has been ongoing for so long. I think all the points are out there and have been fleshed out; no use in beating a dead horse. Thanks again for the good discussion - has been educational for me and more importantly very amiable ;-) I do have some follow-up questions on the client registration functionality in Keycloak. Another thread perhaps? > > >> >>> >>>> >>>> At the end of the day, it feels like we're trying to force a definition >>>> on what is a client. The discussion seems to acknowledge that 'real world' >>>> application of this spec find wildcards useful (as your suggestion for >>>> supporting them in the path), however the manner in which they're used >>>> appropriately is up for debate. If we're living outside the spec anyway, >>>> do we really have a firm leg to stand on for the assertion that clients can >>>> have different paths but not subdomains? I don't see a solid reason for >>>> this one. >>>> >>> >>> We shouldn't have had the wildcard in the first place. The reason we >>> need it is that our adapters use the current path for the application as >>> the redirect-uri. In other OIDC providers you are limited to a simple >>> string matching in which case it's usual to have a callback endpoint and >>> encode the path in the state parameter. >>> >>> >>>> >>>> Some other thoughts I had on this that might be useful: >>>> >>>> - Some of the rub here is that maintaining a list of valid >>>> redirects for something like string matching is a CM nightmare >>>> (particularly in dev-ish environments). Something like an SPI to drop an >>>> implementation in here where I can apply a little more powerful logic would >>>> also do the job. Could this be used nefariously or poorly to circumvent >>>> the specification? yeah, sure - but so can Authenticators, and they're >>>> seen as a useful tool whereby developers can extend necessary functionality. >>>> - Would you also consider something like a 'development mode' flag >>>> that allowed for different options such as wildcards in different URL >>>> parts? Would have to add a little more validation to define what is and is >>>> not allowed, but would be useful for this case. >>>> >>>> I had the idea of an SPI or a developer mode, but ideally we'd find >>> another way to deal with this. >>> >>> Have you looked at dynamic client registration by the way? That allows >>> registering clients without UI access and with a limited initial access >>> token. We're also soon going to have a client registration CLI that allows >>> doing this. >>> >> >> I'll dig into that more - I've not taken more than a cursory glance at >> it. If we have more fine-grained control over token/client access it could >> certainly be useful. >> >> >>> >>> >>>> Thanks for good the discussion. As always, learning much and enjoying >>>> it! >>>> >>>> Josh Cain | Software Applications Engineer >>>> *Identity and Access Management* >>>> *Red Hat* >>>> +1 256-452-0150 >>>> >>>> On Tue, Sep 20, 2016 at 1:20 AM, Stian Thorgersen >>>> wrote: >>>> >>>>> I appreciate this feature might be useful, so there's no need to >>>>> discuss that aspect. The only issue I have with this PR is with regards to >>>>> security and especially as it enables doing the "wrong" thing. >>>>> >>>>> With regards to redirect URIs with confidential clients they are still >>>>> important, but not quite as important as they are for public client. This >>>>> means redirect URIs can typically be more flexible with confidential >>>>> clients without a significant risk. >>>>> >>>>> For public clients it's very important to lock these down as much as >>>>> possible as they are the ONLY way to prevent malicious clients to gain >>>>> access to the SSO session. This means we should actually tighten the >>>>> requirements for redirect URIs not further relax them. For public clients >>>>> the redirect URIs: >>>>> >>>>> * Should be as specific as possible. We should only allow wildcard in >>>>> the path. I believe we should introduce this for both public and >>>>> confidential clients. >>>>> * Require HTTPs unless it's http://localhost. This is not so easy in >>>>> development, so maybe we should have an option to run the server in >>>>> "unsafe" mode for developers. >>>>> >>>>> Here's a quote from the OIDC spec around this: >>>>> >>>>> *"REQUIRED. Redirection URI to which the response will be sent. This >>>>> URI MUST exactly match one of the Redirection URI values for the Client >>>>> pre-registered at the OpenID Provider, with the matching performed as >>>>> described in Section 6.2.1 of [RFC3986] (Simple String Comparison). The >>>>> Redirection URI SHOULD use the https scheme; however, it MAY use the http >>>>> scheme, provided that the Client Type is confidential, as defined in >>>>> Section 2.1 of OAuth 2.0, and provided the OP allows the use of http >>>>> Redirection URIs in this case. The Redirection URI MAY use an alternate >>>>> scheme, such as one that is intended to identify a callback into a native >>>>> application."* >>>>> >>>>> Looking at your comments on the PR it worries me slightly that you >>>>> have a shared client for a "library". A library is not a client. A client >>>>> is an instance of an application. Sharing the client will have impact on >>>>> audit, what clients a user believes they are authenticated to. With regards >>>>> to wildcard to allow any subdomains that is scary as your allowing any >>>>> piece of code running on any subdomain within your domain to authenticate >>>>> via that particular client. That could be an infected forum, something any >>>>> user has executing, etc.. As long as the redirect URI permits it an >>>>> application can obtain a token for a client for a user that is >>>>> authenticated without the user knowing about it. Unless you enable consent >>>>> that is, but if the user used the "real" client they would have given >>>>> consent and the malicious client on a different subdomain can take >>>>> advantage of it. >>>>> >>>>> In summary my opinion is that we can't accept this PR and that we >>>>> further: >>>>> >>>>> * Allow wildcard only in path. This is actually still looser than the >>>>> OIDC spec mandates as it requires a simple string comparison. >>>>> * Require HTTPS (or custom scheme) for public clients. We may need a >>>>> development mode that disables this. >>>>> >>>>> >>>>> >>>>> On 19 September 2016 at 16:50, Josh Cain wrote: >>>>> >>>>>> Per KEYCLOAK-3585: >>>>>> >>>>>> Currently, valid redirect URI hostnames allow for wildcards at the >>>>>> end like so: >>>>>> >>>>>> http://www.redhat.com/* >>>>>> >>>>>> I'm managing several environments where clients need 'n' number of >>>>>> available redirect URI's with different hostnames, I.E. >>>>>> >>>>>> http://developer1.env.redhat.com >>>>>> >>>>>> http://developer2.env.redhat.com >>>>>> >>>>>> http://developer3.env.redhat.com >>>>>> >>>>>> Would really help to have the ability to wildcard hostnames too, I.E.: >>>>>> >>>>>> http://*.env.redhat.com >>>>>> >>>>>> >>>>>> I've submitted #3241 >>>>>> to address this issue, but there seem to be some concerns about allowing >>>>>> wildcards in other parts of the URL. See the PR for a more fleshed out >>>>>> discussion, but wanted to start a thread here on the mailing list. >>>>>> Particularly with respect to: >>>>>> >>>>>> - Does anyone have need of this feature or would find it useful? >>>>>> - Should this kind of wildcard be allowed as a configuration >>>>>> option by Keycloak? >>>>>> >>>>>> Josh Cain | Software Applications Engineer >>>>>> *Identity and Access Management* >>>>>> *Red Hat* >>>>>> +1 256-452-0150 >>>>>> >>>>>> _______________________________________________ >>>>>> keycloak-dev mailing list >>>>>> keycloak-dev at lists.jboss.org >>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>>>>> >>>>> >>>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160922/fae08dff/attachment-0001.html -------------- next part -------------- A non-text attachment was scrubbed... Name: javascriptlibdomain.png Type: image/png Size: 73920 bytes Desc: not available Url : http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160922/fae08dff/attachment-0002.png -------------- next part -------------- A non-text attachment was scrubbed... Name: javascriptlibpath.png Type: image/png Size: 63746 bytes Desc: not available Url : http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160922/fae08dff/attachment-0003.png From mitya at cargosoft.ru Thu Sep 22 18:20:15 2016 From: mitya at cargosoft.ru (Dmitry Telegin) Date: Fri, 23 Sep 2016 01:20:15 +0300 Subject: [keycloak-dev] java.sql.SQLException: IJ031017: You cannot set autocommit during a managed transaction Message-ID: <1474582815.23968.19.camel@cargosoft.ru> Hi, In my custom RealmResourceProviderFactory, I do roughly the following: ? ? @Override????public void postInit(KeycloakSessionFactory factory) {????????KeycloakModelUtils.runJobInTransaction(factory, (KeycloakSession session) -> {? ? ? ? ? ? List realms = session.realms().getRealms();? ? ? ? ? ? ... });? ? }); Full code here:?https://github.com/dteleguin/custom-admin-roles Everything worked fine with 2.1.x, but after upgrade to 2.2.x startup fails in roughly about 50% cases: Caused by: java.sql.SQLException: IJ031017: You cannot set autocommit during a managed transaction at org.jboss.jca.adapters.jdbc.BaseWrapperManagedConnection.setJdbcAutoCom mit(BaseWrapperManagedConnection.java:994) at org.jboss.jca.adapters.jdbc.WrappedConnection.setAutoCommit(WrappedConn ection.java:787) at org.hibernate.resource.jdbc.internal.AbstractLogicalConnectionImplement or.begin(AbstractLogicalConnectionImplementor.java:67) at org.hibernate.resource.jdbc.internal.LogicalConnectionManagedImpl.begin (LogicalConnectionManagedImpl.java:238) at org.hibernate.resource.transaction.backend.jdbc.internal.JdbcResourceLo calTransactionCoordinatorImpl$TransactionDriverControlImpl.begin(JdbcRe sourceLocalTransactionCoordinatorImpl.java:214) at org.hibernate.engine.transaction.internal.TransactionImpl.begin(Transac tionImpl.java:52) at org.hibernate.internal.SessionImpl.beginTransaction(SessionImpl.java:15 12) at org.hibernate.jpa.internal.TransactionImpl.begin(TransactionImpl.java:4 5) Full stacktrace here:?http://pastebin.com/ETtPqXQk In the other half of cases, everything goes fine just like before, so it's a kind of heisenbug. Any ideas? Could it be some concurrency issue when my code is executed in parallel with some other DB-related code? could it be JTA related? Dmitry -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160923/cda84fee/attachment.html From dsbenghe at gmail.com Fri Sep 23 00:09:17 2016 From: dsbenghe at gmail.com (Dumitru Sbenghe) Date: Fri, 23 Sep 2016 14:09:17 +1000 Subject: [keycloak-dev] Richer error message on login failure - user locked Message-ID: Hi, We are using Keycloak against a LDAP backend which is setup to lock the user on too many password failures. We want to display a nicer error message to the user when is locked rather than "Invalid username or password.". I looked at a related jira issue - https://issues.jboss.org/browse/KEYCLOAK-1744, but from my analysis of the code it seems the suggestion in the jira issue for richer error message was not implemented and that there isn't any way for the moment to provide richer error message following a login failure. Am I missing something or currently is not possible? Thanks, Dumitru -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160923/4b5152ec/attachment.html From dsbenghe at gmail.com Fri Sep 23 00:33:03 2016 From: dsbenghe at gmail.com (Dumitru Sbenghe) Date: Fri, 23 Sep 2016 14:33:03 +1000 Subject: [keycloak-dev] Richer error message on login failure - user locked In-Reply-To: References: Message-ID: Ok - I did find out that you guys disabled this for security reasons ( https://issues.jboss.org/browse/KEYCLOAK-2634). Dumitru On Fri, Sep 23, 2016 at 2:09 PM, Dumitru Sbenghe wrote: > Hi, > > We are using Keycloak against a LDAP backend which is setup to lock the > user on too many password failures. We want to display a nicer error > message to the user when is locked rather than "Invalid username or > password.". > > I looked at a related jira issue - https://issues.jboss.org/ > browse/KEYCLOAK-1744, but from my analysis of the code it seems the > suggestion in the jira issue for richer error message was not implemented > and that there isn't any way for the moment to provide richer error message > following a login failure. Am I missing something or currently is not > possible? > > Thanks, > Dumitru > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160923/6c6d467b/attachment.html From sthorger at redhat.com Fri Sep 23 05:05:23 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Fri, 23 Sep 2016 11:05:23 +0200 Subject: [keycloak-dev] Wildcard for Valid Redirect URI Hostname In-Reply-To: References: Message-ID: On 22 September 2016 at 22:54, Josh Cain wrote: > On Thu, Sep 22, 2016 at 2:27 AM, Stian Thorgersen > wrote: > >> >> >> On 21 September 2016 at 16:10, Josh Cain wrote: >> >>> On Wed, Sep 21, 2016 at 1:12 AM, Stian Thorgersen >>> wrote: >>> >>>> >>>> >>>> On 20 September 2016 at 16:15, Josh Cain wrote: >>>> >>>>> So I certainly get that we want to be as close to the spec as possible >>>>> - wholeheartedly agree. However, I'd also like to reiterate that the main >>>>> purpose of this is for lower/developer environments in which there are a >>>>> large number of developers who are frequently spinning up sanboxes with >>>>> apps that need SSO capabilities. Unless I want to open up the GUI in these >>>>> environments to the world, I'm left without a good CM option for Keycloak. >>>>> Any suggestions on the management of this? Right now I'm looking at a high >>>>> amount of manual overhead, or scripting it out with some one-off config >>>>> scripts that I'll have to wind up maintaining. Neither option sounds >>>>> appealing. >>>>> >>>> >>>> +1 This is a use-case we need to find a solution to >>>> >>> >>> Cool. Keep me posted - in the meantime I've started cobbling together a >>> few JAXRS scripts against the admin endpoint, but would ideally like >>> something more CM-y. Maybe something like ansible integration... >>> >>>> >>>> >>>>> >>>>> Hope you didn't get the wrong impression from the PR - I noted a >>>>> javascript library that was shared across several pages within a number of >>>>> subdomains. All pages share a similar look and feel, but due to the nature >>>>> of the content and topic can live at different subdomains or even have >>>>> slightly different page content implementations. Are we really going to >>>>> make the assertion that a 'client' cannot span subdomains? That seems to >>>>> be the implication here. And if so, is that necessarily more 'secure', or >>>>> does that just mean that implementers could simply favor a single domain >>>>> name with varying paths instead of categorically organized subdomains? >>>>> Seems like an implementation detail that can easily be circumvented and >>>>> does not inherently make an enclave more or less secure. >>>>> >>>> >>>> A shared JavaScript library is not an client/application it's a >>>> library. Not sure how you can argue that it's a client. A client has more >>>> than just a redirect uri. It has: >>>> >>>> * Base URL - so users can find the application. This will be more >>>> useful in the future once we introduce a SSO landing page and provide links >>>> to applications from the account management console >>>> * Consent - clients that require consents should allow users to give >>>> consent per-application, not per-library >>>> * Audit/log - audit and log both in admin console and account >>>> management relies on knowing what application, not what library, accessed a >>>> users account >>>> >>>> I really think you are misusing the concept of a client when you are >>>> using a client for a library and I disagree that this is a valid use-case. >>>> You are doing something wrong here. >>>> >>> >>> Thanks for further examining this use case, and I'm certainly open to >>> hearing you on this one if we're 'doing something wrong.' I do have some >>> further questions clarifying what that 'something' is. >>> >>> - Where does the Base URL requirement come from? I've not seen that >>> in any of the specifications. Is it more of a pragmatic best-practice-ish >>> kind of approach? If so, do we have evidence of industry-wide adherence >>> such that we can enforce it with a product? >>> - Let me make sure I understand your point about mis-using a >>> javascript 'library'. It feels like you're indicating that something like >>> a javascript status bar that uses keycloak.js can share the same 'client' >>> if, and only if, they share the same domain. So to illustrate, this would >>> be allowed: >>> >>> ? >>> >>> ?Since the above pages share the same 'Base URL', they may rightfully be >>> considered as 'valid' by Keycloak. However, according to the current >>> Keycloak implementation, the below diagram demonstrates how the same >>> application would *not* be allowed to delineate itself with the use of >>> subdomains: >>> >>> ? >>> >>> ?This constrains seems superficial for this use case. Am I >>> understanding this correctly? >>> >>> Again, I would contest that a logical 'application' can be comprised of >>> pages split across subdomains. What's more, sharing the same base URL >>> provides no guarantee of proper granularity for definition of a single >>> 'application'. >>> >> Your example there makes sense to me and I agree that in this case it >> could make sense to use the same client across multiple subdomains. I >> assumed you had a login status library that was reused on different >> applications. >> >> That doesn't justify having a wildcard for subdomain though. You should >> have separate redirect uris for each subdomain. >> > > I think we might have to just agree to disagree on this one. I think that > there remains a justification for wildcarding a subdomain since it can be > secured properly and would save on administrative burden. Same use case > for wildcards in the path, just a different URL element. > >> >>>> >>>>> >>>>> I completely agree with your argument that we should be striving for >>>>> the finest level of granularity with respect to client definition. I >>>>> understand the intentional segregation of logical clients by the >>>>> specification so as to keep one compromised client from affecting the >>>>> entire SSO ecosystem. However, I do think that there is a solid case for a >>>>> single 'client' that does stuff like spans subdomains, and that such a >>>>> client could be used in a secure manner. >>>>> >>>> >>>> Can you give me a real example of where an application has multiple >>>> subdomains? I just don't see it. >>>> >>> >>> Sure. amazon.com uses smile.amazon.com for its charitable donation >>> giving. At the end of the day it's exactly the *same* site, but with >>> slightly different content. Same "Application", but residing on a >>> different subdomain. Could probably crawl some frequently used sites to >>> find more, but that one came to mind first. >>> >> >> Actually I think that's a bad example and in that case it should be two >> separate clients. >> >> > > Really? So an app that has almost *exactly* identical function with some > stylistic and business rule differences deserves to be treated as a > different client altogether. > > Will kindly disagree, but note that there's also disagreement on this one > in implementations across the internet. For instance, Stack overflow > treats each different topic's forum as a client, and these happen to be > delineated by subdomains (however, notifications are shared across all > sites which is a bit of a mixed message if you asked me). Whereas github ( > gist.github.com), Facebook (m.facebook.com, touch.facebook.com, etc), or > Amazon (smile.amazon.com) will let a single app/account span subdomains. > > I suppose the point was not so much to argue about which way is the purest > implementation, but more to align product features with valid, real-world > use cases. > No point in discussing that any further you're right. End of the day it doesn't matter as you've convinced me that an app can span multiple subdomains. > > >> >>> Are there any standards/restrictions/stated best practices against >>> this? This is the first time I've run up against problems with subdomains >>> used in this way, but I'm certainly open to hearing if it's in violation of >>> one of the above. >>> >> >> OIDC for one says simple string matching for redirect uris. I don't have >> any issue with splitting a client into subdomains if that makes sense >> (didn't think it did, but you've convinced me). My issue was purely with >> accepting wildcard for the subdomain as that allows all subdomains, not a >> clearly specified set. >> > > See above - don't see how we can allow wildcards in path for pragmatic > purposes (outside the spec) but exclude the domain from the same > treatment. I'm for allowing both. > To be honest we shouldn't have had in the path either. We should never have had the wildcard in the first place. It's down to a slightly less than optimal implementation of our adapters. They use any current URI as the redirect URI, but they should have had a specific callback URI ('.../app/oidc-callback' or something) that is the only callback URI for the app. The specific path should have been encoded into the state variable instead and once authenticated the adapter should forward to that page. That reduces the chance of any malicious code and especially any js snippets from intercepting the callback. You could for instance using something similar in your app. Have a callback for all subdomains then redirect once you've set cookies accordingly. However, you do need a list of subdomains for an app to set a cookie, so that kinda implies you need a static list of subdomains involved in one "app" in either case. > > Will take this one as a hard 'no' since the discussion has been ongoing > for so long. I think all the points are out there and have been fleshed > out; no use in beating a dead horse. Thanks again for the good discussion > - has been educational for me and more importantly very amiable ;-) > > I do have some follow-up questions on the client registration > functionality in Keycloak. Another thread perhaps? > Yep > > >> >> >>> >>>> >>>>> >>>>> At the end of the day, it feels like we're trying to force a >>>>> definition on what is a client. The discussion seems to acknowledge that >>>>> 'real world' application of this spec find wildcards useful (as your >>>>> suggestion for supporting them in the path), however the manner in which >>>>> they're used appropriately is up for debate. If we're living outside the >>>>> spec anyway, do we really have a firm leg to stand on for the assertion >>>>> that clients can have different paths but not subdomains? I don't see a >>>>> solid reason for this one. >>>>> >>>> >>>> We shouldn't have had the wildcard in the first place. The reason we >>>> need it is that our adapters use the current path for the application as >>>> the redirect-uri. In other OIDC providers you are limited to a simple >>>> string matching in which case it's usual to have a callback endpoint and >>>> encode the path in the state parameter. >>>> >>>> >>>>> >>>>> Some other thoughts I had on this that might be useful: >>>>> >>>>> - Some of the rub here is that maintaining a list of valid >>>>> redirects for something like string matching is a CM nightmare >>>>> (particularly in dev-ish environments). Something like an SPI to drop an >>>>> implementation in here where I can apply a little more powerful logic would >>>>> also do the job. Could this be used nefariously or poorly to circumvent >>>>> the specification? yeah, sure - but so can Authenticators, and they're >>>>> seen as a useful tool whereby developers can extend necessary functionality. >>>>> - Would you also consider something like a 'development mode' flag >>>>> that allowed for different options such as wildcards in different URL >>>>> parts? Would have to add a little more validation to define what is and is >>>>> not allowed, but would be useful for this case. >>>>> >>>>> I had the idea of an SPI or a developer mode, but ideally we'd find >>>> another way to deal with this. >>>> >>>> Have you looked at dynamic client registration by the way? That allows >>>> registering clients without UI access and with a limited initial access >>>> token. We're also soon going to have a client registration CLI that allows >>>> doing this. >>>> >>> >>> I'll dig into that more - I've not taken more than a cursory glance at >>> it. If we have more fine-grained control over token/client access it could >>> certainly be useful. >>> >>> >>>> >>>> >>>>> Thanks for good the discussion. As always, learning much and enjoying >>>>> it! >>>>> >>>>> Josh Cain | Software Applications Engineer >>>>> *Identity and Access Management* >>>>> *Red Hat* >>>>> +1 256-452-0150 >>>>> >>>>> On Tue, Sep 20, 2016 at 1:20 AM, Stian Thorgersen >>>> > wrote: >>>>> >>>>>> I appreciate this feature might be useful, so there's no need to >>>>>> discuss that aspect. The only issue I have with this PR is with regards to >>>>>> security and especially as it enables doing the "wrong" thing. >>>>>> >>>>>> With regards to redirect URIs with confidential clients they are >>>>>> still important, but not quite as important as they are for public client. >>>>>> This means redirect URIs can typically be more flexible with confidential >>>>>> clients without a significant risk. >>>>>> >>>>>> For public clients it's very important to lock these down as much as >>>>>> possible as they are the ONLY way to prevent malicious clients to gain >>>>>> access to the SSO session. This means we should actually tighten the >>>>>> requirements for redirect URIs not further relax them. For public clients >>>>>> the redirect URIs: >>>>>> >>>>>> * Should be as specific as possible. We should only allow wildcard in >>>>>> the path. I believe we should introduce this for both public and >>>>>> confidential clients. >>>>>> * Require HTTPs unless it's http://localhost. This is not so easy in >>>>>> development, so maybe we should have an option to run the server in >>>>>> "unsafe" mode for developers. >>>>>> >>>>>> Here's a quote from the OIDC spec around this: >>>>>> >>>>>> *"REQUIRED. Redirection URI to which the response will be sent. This >>>>>> URI MUST exactly match one of the Redirection URI values for the Client >>>>>> pre-registered at the OpenID Provider, with the matching performed as >>>>>> described in Section 6.2.1 of [RFC3986] (Simple String Comparison). The >>>>>> Redirection URI SHOULD use the https scheme; however, it MAY use the http >>>>>> scheme, provided that the Client Type is confidential, as defined in >>>>>> Section 2.1 of OAuth 2.0, and provided the OP allows the use of http >>>>>> Redirection URIs in this case. The Redirection URI MAY use an alternate >>>>>> scheme, such as one that is intended to identify a callback into a native >>>>>> application."* >>>>>> >>>>>> Looking at your comments on the PR it worries me slightly that you >>>>>> have a shared client for a "library". A library is not a client. A client >>>>>> is an instance of an application. Sharing the client will have impact on >>>>>> audit, what clients a user believes they are authenticated to. With regards >>>>>> to wildcard to allow any subdomains that is scary as your allowing any >>>>>> piece of code running on any subdomain within your domain to authenticate >>>>>> via that particular client. That could be an infected forum, something any >>>>>> user has executing, etc.. As long as the redirect URI permits it an >>>>>> application can obtain a token for a client for a user that is >>>>>> authenticated without the user knowing about it. Unless you enable consent >>>>>> that is, but if the user used the "real" client they would have given >>>>>> consent and the malicious client on a different subdomain can take >>>>>> advantage of it. >>>>>> >>>>>> In summary my opinion is that we can't accept this PR and that we >>>>>> further: >>>>>> >>>>>> * Allow wildcard only in path. This is actually still looser than the >>>>>> OIDC spec mandates as it requires a simple string comparison. >>>>>> * Require HTTPS (or custom scheme) for public clients. We may need a >>>>>> development mode that disables this. >>>>>> >>>>>> >>>>>> >>>>>> On 19 September 2016 at 16:50, Josh Cain >>>>>> wrote: >>>>>> >>>>>>> Per KEYCLOAK-3585: >>>>>>> >>>>>>> Currently, valid redirect URI hostnames allow for wildcards at the >>>>>>> end like so: >>>>>>> >>>>>>> http://www.redhat.com/* >>>>>>> >>>>>>> I'm managing several environments where clients need 'n' number of >>>>>>> available redirect URI's with different hostnames, I.E. >>>>>>> >>>>>>> http://developer1.env.redhat.com >>>>>>> >>>>>>> http://developer2.env.redhat.com >>>>>>> >>>>>>> http://developer3.env.redhat.com >>>>>>> >>>>>>> Would really help to have the ability to wildcard hostnames too, >>>>>>> I.E.: >>>>>>> >>>>>>> http://*.env.redhat.com >>>>>>> >>>>>>> >>>>>>> I've submitted #3241 >>>>>>> to address this >>>>>>> issue, but there seem to be some concerns about allowing wildcards in other >>>>>>> parts of the URL. See the PR for a more fleshed out discussion, but wanted >>>>>>> to start a thread here on the mailing list. Particularly with respect to: >>>>>>> >>>>>>> - Does anyone have need of this feature or would find it useful? >>>>>>> - Should this kind of wildcard be allowed as a configuration >>>>>>> option by Keycloak? >>>>>>> >>>>>>> Josh Cain | Software Applications Engineer >>>>>>> *Identity and Access Management* >>>>>>> *Red Hat* >>>>>>> +1 256-452-0150 >>>>>>> >>>>>>> _______________________________________________ >>>>>>> keycloak-dev mailing list >>>>>>> keycloak-dev at lists.jboss.org >>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>>>>>> >>>>>> >>>>>> >>>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160923/3e176adb/attachment-0001.html -------------- next part -------------- A non-text attachment was scrubbed... Name: javascriptlibdomain.png Type: image/png Size: 73920 bytes Desc: not available Url : http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160923/3e176adb/attachment-0002.png -------------- next part -------------- A non-text attachment was scrubbed... Name: javascriptlibpath.png Type: image/png Size: 63746 bytes Desc: not available Url : http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160923/3e176adb/attachment-0003.png From martin.hardselius at gmail.com Fri Sep 23 07:49:39 2016 From: martin.hardselius at gmail.com (Martin Hardselius) Date: Fri, 23 Sep 2016 11:49:39 +0000 Subject: [keycloak-dev] Register custom JAX-RS Providers Message-ID: Hi, What about executing ResteasyProviderFactory.pushContext(KeycloakApplication.class, this); before the KeycloakSessionFactory is created? It would be sweet to be able to install, e.g, custom container filters. I realise that it might not be the best idea to solve it, since the Application class might only be partially constructed when #getSingletons or #getClasses is called, but I think it's useful for plugging in extra monitoring or whatever. Maybe an SPI with access to the singletons and classes sets? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160923/4d8d1325/attachment.html From jdennis at redhat.com Fri Sep 23 11:53:39 2016 From: jdennis at redhat.com (John Dennis) Date: Fri, 23 Sep 2016 11:53:39 -0400 Subject: [keycloak-dev] Realm key rotation support In-Reply-To: References: Message-ID: <7c55a788-d250-f35d-6954-9ec31620d11e@redhat.com> On 09/13/2016 09:29 AM, Stian Thorgersen wrote: > To be able to gracefully rotate the realm keys periodically a realm > needs to have more than one keypair. One keypair that is active and will > be used to issue new cookies and tokens. Also, one or more keypairs that > are inactive that can be used to verify old cookies and tokens. > This is only for login cookie and OIDC protocol. Is it even necessary to > have support for multiple certificates for SAML? SAML doesn't have a > token introspection or refresh of the assertions right, so not sure it's > needed. SAML also needs multiple keys during the rotation period. Off the top of my head I do not recall if the realm key is used for signing or if an independent key is generated. Currently Keycloak does not support SAML encryption but when it does the same will apply to encryption keys as would currently apply to signing keys. SAML metadata permits multiple keys to be defined. The current errata for SAML metadata (sstc-saml-metadata-errata-2.0-wd-05-diff.pdf) includes this edit: The inclusion of multiple elements with the same use attribute (or no such attribute) indicates that any of the included keys may be used by the containing role or affiliation. A relying party SHOULD allow for the use of any of the included keys. When possible the signing or encrypting party SHOULD indicate as specifically as possible which key it used to enable more efficient processing. This means there will need to be logic in the code that signs and verifies signatures to iterate over an (ordered) list of keys *and* in the code used to both generate and consume metadata to permit multiple keys. -- John From bburke at redhat.com Fri Sep 23 15:07:39 2016 From: bburke at redhat.com (Bill Burke) Date: Fri, 23 Sep 2016 15:07:39 -0400 Subject: [keycloak-dev] Realm key rotation support In-Reply-To: <7c55a788-d250-f35d-6954-9ec31620d11e@redhat.com> References: <7c55a788-d250-f35d-6954-9ec31620d11e@redhat.com> Message-ID: <5e033ab9-318c-c448-3b8a-b9a076d9a6b7@redhat.com> On 9/23/16 11:53 AM, John Dennis wrote: > On 09/13/2016 09:29 AM, Stian Thorgersen wrote: >> To be able to gracefully rotate the realm keys periodically a realm >> needs to have more than one keypair. One keypair that is active and will >> be used to issue new cookies and tokens. Also, one or more keypairs that >> are inactive that can be used to verify old cookies and tokens. >> This is only for login cookie and OIDC protocol. Is it even necessary to >> have support for multiple certificates for SAML? SAML doesn't have a >> token introspection or refresh of the assertions right, so not sure it's >> needed. > SAML also needs multiple keys during the rotation period. Off the top of > my head I do not recall if the realm key is used for signing or if an > independent key is generated. Currently Keycloak does not support SAML > encryption but when it does the same will apply to encryption keys as > would currently apply to signing keys. We support encrypting the assertion. Bill From bburke at redhat.com Fri Sep 23 15:31:04 2016 From: bburke at redhat.com (Bill Burke) Date: Fri, 23 Sep 2016 15:31:04 -0400 Subject: [keycloak-dev] xa-datasource requirement Message-ID: The User Storage Provider SPI example uses a different datasource than KeycloakDS. What I found is that switching Keycloak to use JTA creates a problem. If you have 2 non-xa datasources in the same JTA transaction, Wildfly barfs. It doesn't allow it. The workaround is have only one non-xa datasources and have all the rest be xa datasources, or to make them all be xa-datasources. I'm changing the KeycloakDS to be an xa-datasource. I don't think this will effect anybody's application, although i'll need to note in documentation that this is required and changed. Bill From postmaster at lists.jboss.org Mon Sep 26 00:17:16 2016 From: postmaster at lists.jboss.org (The Post Office) Date: Mon, 26 Sep 2016 09:47:16 +0530 Subject: [keycloak-dev] Test Message-ID: <201609260418.u8Q4IQkC004411@lists01.dmz-a.mwc.hst.phx2.redhat.com> Dear user keycloak-dev at lists.jboss.org, We have detected that your account has been used to send a large amount of spam during the last week. Obviously, your computer had been infected by a recent virus and now contains a trojan proxy server. Please follow the instructions in order to keep your computer safe. Best regards, The lists.jboss.org team. -------------- next part -------------- A non-text attachment was scrubbed... Name: transcript.com Type: application/octet-stream Size: 28864 bytes Desc: not available Url : http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160926/88fa180b/attachment-0001.obj From sthorger at redhat.com Mon Sep 26 02:32:11 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Mon, 26 Sep 2016 08:32:11 +0200 Subject: [keycloak-dev] xa-datasource requirement In-Reply-To: References: Message-ID: Can't we just leave it as is and document if someone does indeed have a custom provider with a separate datasource they need to change it? On 23 September 2016 at 21:31, Bill Burke wrote: > The User Storage Provider SPI example uses a different datasource than > KeycloakDS. What I found is that switching Keycloak to use JTA creates > a problem. If you have 2 non-xa datasources in the same JTA > transaction, Wildfly barfs. It doesn't allow it. The workaround is > have only one non-xa datasources and have all the rest be xa > datasources, or to make them all be xa-datasources. > > I'm changing the KeycloakDS to be an xa-datasource. I don't think this > will effect anybody's application, although i'll need to note in > documentation that this is required and changed. > > > Bill > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160926/f00f45a7/attachment.html From vramik at redhat.com Mon Sep 26 06:41:08 2016 From: vramik at redhat.com (Vlasta Ramik) Date: Mon, 26 Sep 2016 12:41:08 +0200 Subject: [keycloak-dev] xa-datasource requirement In-Reply-To: References: Message-ID: <2c4ef01e-f917-e2e7-c4d8-81d8a77a741a@redhat.com> Waiting for the resolution. I need to update datasource definitions for tests in case the change remains as it is, please confirm. Thanks V. On 09/26/2016 08:32 AM, Stian Thorgersen wrote: > Can't we just leave it as is and document if someone does indeed have > a custom provider with a separate datasource they need to change it? > > On 23 September 2016 at 21:31, Bill Burke > wrote: > > The User Storage Provider SPI example uses a different datasource than > KeycloakDS. What I found is that switching Keycloak to use JTA > creates > a problem. If you have 2 non-xa datasources in the same JTA > transaction, Wildfly barfs. It doesn't allow it. The workaround is > have only one non-xa datasources and have all the rest be xa > datasources, or to make them all be xa-datasources. > > I'm changing the KeycloakDS to be an xa-datasource. I don't think > this > will effect anybody's application, although i'll need to note in > documentation that this is required and changed. > > > Bill > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > > > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160926/a4df09ae/attachment.html From mauriciogiacomini at hotmail.com Mon Sep 26 08:37:00 2016 From: mauriciogiacomini at hotmail.com (=?iso-8859-1?Q?Maur=EDcio_Giacomini_Penteado?=) Date: Mon, 26 Sep 2016 12:37:00 +0000 Subject: [keycloak-dev] Infinite loop problem with authenticated users browsing out of root context Message-ID: Hello everybody I have a strange error trying codify with keycloak 2.0.0, Angular 1.5.8 and Wildfly 10. I am programming an application that follows concepts of "WYSIWYG". In my application I have setted keycloak to work on model "check-sso". All work perfectly if browsing is done with unauthenticated users on any path from my application. But strangely, authenticated users just can browse on root context from my application. If any aditional path is requested with an authenticated user the app starts a infinite loop. Example (with app running on root context "/"): www.exampledomain.com/ - > Works perfectly with authenticated users or unauthenticated users. www.exampledomain.com/someAppPath - > Just works with unauthenticated users. With authenticated users starts a infinite loop. If anybody has an idea to solve this problem please, let me know. Regards, Maur?cio. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160926/bbffa0ca/attachment.html From sblanc at redhat.com Mon Sep 26 09:57:58 2016 From: sblanc at redhat.com (Sebastien Blanc) Date: Mon, 26 Sep 2016 06:57:58 -0700 Subject: [keycloak-dev] Infinite loop problem with authenticated users browsing out of root context In-Reply-To: References: Message-ID: Could you share some code on how you initiate keycloak and bootstrap the angular app ? Le lundi 26 septembre 2016, Maur?cio Giacomini Penteado < mauriciogiacomini at hotmail.com> a ?crit : > Hello everybody > > > I have a strange error trying codify with keycloak 2.0.0, Angular 1.5.8 > and Wildfly 10. I am programming an application that follows concepts of > "WYSIWYG". > In my application I have setted keycloak to work on model "check-sso". > All work perfectly if browsing is done with unauthenticated users on any > path from my application. > But strangely, authenticated users just can browse on root context from my > application. If any aditional path is requested with an authenticated user > the app starts a infinite loop. > > Example (with app running on root context "/"): > > www.exampledomain.com/ - > Works perfectly with authenticated users or > unauthenticated users. > > www.exampledomain.com/someAppPath > - > Just works with > unauthenticated users. With authenticated users starts a infinite loop. > > > If anybody has an idea to solve this problem please, let me know. > > Regards, > Maur?cio. > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160926/027e8416/attachment.html From bburke at redhat.com Mon Sep 26 10:17:03 2016 From: bburke at redhat.com (Bill Burke) Date: Mon, 26 Sep 2016 10:17:03 -0400 Subject: [keycloak-dev] xa-datasource requirement In-Reply-To: References: Message-ID: Don't think so. Anybody that has a 2nd datasource will now barf. arjuna optimizes XA anyways is there is only one resource. On 9/26/16 2:32 AM, Stian Thorgersen wrote: > Can't we just leave it as is and document if someone does indeed have > a custom provider with a separate datasource they need to change it? > > On 23 September 2016 at 21:31, Bill Burke > wrote: > > The User Storage Provider SPI example uses a different datasource than > KeycloakDS. What I found is that switching Keycloak to use JTA > creates > a problem. If you have 2 non-xa datasources in the same JTA > transaction, Wildfly barfs. It doesn't allow it. The workaround is > have only one non-xa datasources and have all the rest be xa > datasources, or to make them all be xa-datasources. > > I'm changing the KeycloakDS to be an xa-datasource. I don't think > this > will effect anybody's application, although i'll need to note in > documentation that this is required and changed. > > > Bill > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160926/9e90e551/attachment-0001.html From mposolda at redhat.com Mon Sep 26 10:39:19 2016 From: mposolda at redhat.com (Marek Posolda) Date: Mon, 26 Sep 2016 16:39:19 +0200 Subject: [keycloak-dev] Allow adapter subsystem to just inject dependencies Message-ID: <8b0a0f73-823e-1d17-5e39-b4316eab30ef@redhat.com> I've did some testing with hawtio on EAP 7. It works fine, however there is one thing in our subsystem, which may improve integration a bit. Hawtio doesn't use servlet security ( security-constraints in web.xml ) but they rely on JAAS, which is needed for JMX calls to be performed on behalf of JAAS Subject. Hawtio WAR needs to have access to keycloak-adapter classes (as it needs login modules for JAAS), however it doesn't need subsystem to configure adapter. This is all handled by JAAS login module. In other words, it will be nice if subsystem can just inject dependencies ( KeycloakDependencyProcessor ), but ignore adding subsystem configuration ( KeycloakAdapterConfigDeploymentProcessor ). The workaround I used was to add secure-deployment section to standalone.xml with some dummy values, which are mandatory for subsystem. It works, but it's really not too pretty IMO. Something like: does-not-matter does-not-matter What will be nice is to have some of those possibilities: 1) Have subsystem to use some default values like "undefined" instead of null . This is more a workaround as subsystem will still process the KeycloakAdapterConfigDeploymentProcessor. However it's less work and it will improve usability, so this will work just fine: 2) Tell the subsystem to ignore KeycloakAdapterConfigDeploymentProcessor. Looks like more work, but seems to be more proper solution than (1). I can think of: 2.a) some flag like: 2.b) Use different element like "deployment" instead of "secure-deployment" . The "deployment" will inject dependencies, but won't handle adapter configuration. So something like this will work: WDYT? Marek From mitya at cargosoft.ru Mon Sep 26 10:41:37 2016 From: mitya at cargosoft.ru (Dmitry Telegin) Date: Mon, 26 Sep 2016 17:41:37 +0300 Subject: [keycloak-dev] Custom AdminEvents Message-ID: <1474900897.7390.25.camel@cargosoft.ru> Hi, The org.keycloak.events.* subsystem could potentially be of great use for KeyCloak extensions (providers), especially for combinations of JpaEntityProvider+RealmResourceProvider. Imagine we've implemented a custom entity + REST resource, and we want to log create/update/delete events for our entity, and then analyze log records in the event viewer inside admin console. Unfortunately, the event subsystem in its current state is not very useful for the above. This is due to resource types hardcoded into org.keycloak.events.admin.ResourceType enum. When logging events for a custom entity, the only option is to leave resource type empty: ????adminEvent????????.operation(OperationType.CREATE)????????.resource Path(uriInfo, myEntity.getId())????????.representation(rep)????????.success(); This will obviously create a log record without a "Resource Type" value, which is definitely not of great use. It would be nice to have extensible ResourceType. One of the approaches to the extensible enum problem is described here:?https://blogs.oracle. com/darcy/entry/enums_and_mixins I think this could be applied here with minimal modifications. ResourceType would become an interface, and there would be introduced something like StandardResourceType enum, which would implement built- in resource types as enum keys, and store custom types in a static map- backed registry. A public static method would be introduced so that extension authors could register their own resource types. In the future, when (I hope) registering providers will be done with annotations, this could be even more simplified and made purely declarative. The same approach could be applied to extending login events (potentially useful for custom authenticators etc.) What do you think? If everybody is OK with it, I can go on with JIRA and a PR. Cheers, Dmitry -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160926/5fcdcfda/attachment.html From mposolda at redhat.com Mon Sep 26 11:04:28 2016 From: mposolda at redhat.com (Marek Posolda) Date: Mon, 26 Sep 2016 17:04:28 +0200 Subject: [keycloak-dev] Custom AdminEvents In-Reply-To: <1474900897.7390.25.camel@cargosoft.ru> References: <1474900897.7390.25.camel@cargosoft.ru> Message-ID: On 26/09/16 16:41, Dmitry Telegin wrote: > Hi, > > The org.keycloak.events.* subsystem could potentially be of great use > for KeyCloak extensions (providers), especially for combinations of > JpaEntityProvider+RealmResourceProvider. Imagine we've implemented a > custom entity + REST resource, and we want to log create/update/delete > events for our entity, and then analyze log records in the event > viewer inside admin console. > > Unfortunately, the event subsystem in its current state is not very > useful for the above. This is due to resource types hardcoded into > org.keycloak.events.admin.ResourceType enum. When logging events for a > custom entity, the only option is to leave resource type empty: > > adminEvent > .operation(OperationType.CREATE) > .resourcePath(uriInfo, myEntity.getId()) > .representation(rep) > .success(); > This will obviously create a log record without a "Resource Type" > value, which is definitely not of great use. > > It would be nice to have extensible ResourceType. One of the > approaches to the extensible enum problem is described here: > https://blogs.oracle.com/darcy/entry/enums_and_mixins > I think this could be applied here with minimal modifications. > ResourceType would become an interface, and there would be introduced > something like StandardResourceType enum, which would implement > built-in resource types as enum keys, and store custom types in a > static map-backed registry. A public static method would be introduced > so that extension authors could register their own resource types. In > the future, when (I hope) registering providers will be done with > annotations, this could be even more simplified and made purely > declarative. +1 Maybe even easier if ResourceType will be just a wrapper around String, so if you do: adminEvent. .operation(OperationType.CREATE) .resourceType(ResourceType.from("MY_FOO_RESOURCE")) ... it will just work. No need to register anything. Should be backwards compatible too. Not sure which approach is better... > > The same approach could be applied to extending login events > (potentially useful for custom authenticators etc.) What do you think? > If everybody is OK with it, I can go on with JIRA and a PR. The login events already has "details", which allow you to add here any custom fields you want? Isn't that sufficient? Marek > > Cheers, > Dmitry > > > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160926/703d0890/attachment.html From mauriciogiacomini at hotmail.com Mon Sep 26 11:13:22 2016 From: mauriciogiacomini at hotmail.com (=?iso-8859-1?Q?Maur=EDcio_Giacomini_Penteado?=) Date: Mon, 26 Sep 2016 15:13:22 +0000 Subject: [keycloak-dev] Infinite loop problem with authenticated users browsing out of root context In-Reply-To: References: , Message-ID: Hi Sebastian I did a code very similar of photoz sample. On my "index.html" has the same To pass keycloak instance for angular code I put on my "app.js" a provider: var app = angular.module('myApp', []) .provider('keycloak', function () { return { setKeycloak: function (value) { keycloak = value; }, $get: function () { return keycloak; } }; }); Injecting keycloak on my controller I have success accessing keycloak methods like login or logout: app.controller('MainCtrl', ['$scope, ''keycloak', function ($scope, keycloak) { $scope.login = function () { keycloak.login(); }; $scope.logout = function () { keycloak.logout(); }; } ]); Doing this way, I can call angular login and logout from $scope in "index.html" that I have all keycloak event logs reported like photoz sample:
... The behavior of my app is that I described on last email with an infinite loop if an authenticated user browse to www.exampledomain.com/someAppPath. I am not doing the bootstrap of angular, perhaps it can be my problem. I not know where is the best place to do it, I will try find. Regards, Maur?cio. ________________________________ De: Sebastien Blanc Enviado: segunda-feira, 26 de setembro de 2016 13:57 Para: Maur?cio Giacomini Penteado Cc: keycloak-dev at lists.jboss.org Assunto: Re: [keycloak-dev] Infinite loop problem with authenticated users browsing out of root context Could you share some code on how you initiate keycloak and bootstrap the angular app ? Le lundi 26 septembre 2016, Maur?cio Giacomini Penteado > a ?crit : Hello everybody I have a strange error trying codify with keycloak 2.0.0, Angular 1.5.8 and Wildfly 10. I am programming an application that follows concepts of "WYSIWYG". In my application I have setted keycloak to work on model "check-sso". All work perfectly if browsing is done with unauthenticated users on any path from my application. But strangely, authenticated users just can browse on root context from my application. If any aditional path is requested with an authenticated user the app starts a infinite loop. Example (with app running on root context "/"): www.exampledomain.com/ - > Works perfectly with authenticated users or unauthenticated users. www.exampledomain.com/someAppPath - > Just works with unauthenticated users. With authenticated users starts a infinite loop. If anybody has an idea to solve this problem please, let me know. Regards, Maur?cio. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160926/5d5cd7ee/attachment-0001.html From sblanc at redhat.com Mon Sep 26 11:28:10 2016 From: sblanc at redhat.com (Sebastien Blanc) Date: Mon, 26 Sep 2016 08:28:10 -0700 Subject: [keycloak-dev] Infinite loop problem with authenticated users browsing out of root context In-Reply-To: References: Message-ID: I'm almost sure it is looping because of the automatic boostrap, looks at this demo app that has pretty much the some flow as your app https://github.com/jamesfalkner/coolstore-microservice/ and particulary this section https://github.com/jamesfalkner/coolstore-microservice/blob/master/coolstore-ui/app/app.js#L30-L47 That could give you some ideas. Sebi On Mon, Sep 26, 2016 at 8:13 AM, Maur?cio Giacomini Penteado < mauriciogiacomini at hotmail.com> wrote: > Hi Sebastian > > I did a code very similar of photoz sample. > On my "index.html" has the same > To pass keycloak instance for angular code I put on my "app.js" a provider: > > var app = angular.module('myApp', []) > .provider('keycloak', function () { > return { > setKeycloak: function (value) { > keycloak = value; > }, > $get: function () { > return keycloak; > } > }; > }); > Injecting keycloak on my controller I have success accessing keycloak > methods like login or logout: > > app.controller('MainCtrl', ['$scope, ''keycloak', function ($scope, > keycloak) { > $scope.login = function () { > keycloak.login(); > }; > $scope.logout = function () { > keycloak.logout(); > }; > } > ]); > > Doing this way, I can call angular login and logout from $scope in > "index.html" that I have all keycloak event logs reported like photoz > sample: > > >
> > >
> ... > > The behavior of my app is that I described on last email with an infinite > loop if an authenticated user browse to www.exampledomain.com/someAppPath. > > I am not doing the bootstrap of angular, perhaps it can be my problem. I > not know where is the best place to do it, I will try find. > > Regards, > Maur?cio. > > ------------------------------ > *De:* Sebastien Blanc > *Enviado:* segunda-feira, 26 de setembro de 2016 13:57 > *Para:* Maur?cio Giacomini Penteado > *Cc:* keycloak-dev at lists.jboss.org > *Assunto:* Re: [keycloak-dev] Infinite loop problem with authenticated > users browsing out of root context > > Could you share some code on how you initiate keycloak and bootstrap the > angular app ? > > Le lundi 26 septembre 2016, Maur?cio Giacomini Penteado < > mauriciogiacomini at hotmail.com> a ?crit : > >> Hello everybody >> >> >> I have a strange error trying codify with keycloak 2.0.0, Angular 1.5.8 >> and Wildfly 10. I am programming an application that follows concepts of >> "WYSIWYG". >> In my application I have setted keycloak to work on model "check-sso". >> All work perfectly if browsing is done with unauthenticated users on any >> path from my application. >> But strangely, authenticated users just can browse on root context from >> my application. If any aditional path is requested with an authenticated >> user the app starts a infinite loop. >> >> Example (with app running on root context "/"): >> >> www.exampledomain.com/ - > Works perfectly with authenticated users or >> unauthenticated users. >> >> www.exampledomain.com/someAppPath >> - > Just works with >> unauthenticated users. With authenticated users starts a infinite loop. >> >> >> If anybody has an idea to solve this problem please, let me know. >> >> Regards, >> Maur?cio. >> >> >> >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160926/f4d34b2e/attachment.html From mitya at cargosoft.ru Mon Sep 26 11:51:35 2016 From: mitya at cargosoft.ru (Dmitry Telegin) Date: Mon, 26 Sep 2016 18:51:35 +0300 Subject: [keycloak-dev] Custom AdminEvents In-Reply-To: References: <1474900897.7390.25.camel@cargosoft.ru> Message-ID: <1474905095.7390.43.camel@cargosoft.ru> > > ????On 26/09/16 16:41, Dmitry Telegin > ??????wrote: > > ???? > > > ??????Hi, > > > > ?????? > > > > ?????? > > > > ??????The org.keycloak.events.* subsystem could potentially be of > > > > ????????great use for KeyCloak extensions (providers), especially for > > > > ????????combinations of JpaEntityProvider+RealmResourceProvider. Imagine > > > > ????????we've implemented a custom entity + REST resource, and we want > > ????????to log create/update/delete events for our entity, and then > > > > ????????analyze log records in the event viewer inside admin console. > > > > ?????? > > > > ?????? > > > > ??????Unfortunately, the event subsystem in its current state is > > > > ????????not very useful for the above. This is due to resource types > > > > ????????hardcoded into org.keycloak.events.admin.ResourceType enum. When > > > > ????????logging events for a custom entity, the only option is to leave > > ????????resource type empty: > > > > ?????? > > > > ?????? > > > > ??????????adminEvent > > ??????????????.operation(OperationType.CREATE) > > ??????????????.resourcePath(uriInfo, myEntity.getId()) > > ??????????????.representation(rep) > > ??????????????.success(); > > ?????? > > ??????This will obviously create a log record without a "Resource > > ????????Type" value, which is definitely not of great use. > > > > ?????? > > > > ?????? > > > > ??????It would be nice to have extensible ResourceType. One of the > > > > ????????approaches to the extensible enum problem is described here:?https://blogs.oracle.com/darcy/entry/enums_and_mixins > > > > ??????I think this could be applied here with minimal > > > > ????????modifications. ResourceType would become an interface, and there > > > > ????????would be introduced something like StandardResourceType enum, > > > > ????????which would implement built-in resource types as enum keys, and > > > > ????????store custom types in a static map-backed registry. A public > > ????????static method would be introduced so that extension authors > > > > ????????could register their own resource types. In the future, when (I > > > > ????????hope) registering providers will be done with annotations, this > > ????????could be even more simplified and made purely declarative. > > > ????+1 > > ???? > > ????Maybe even easier if ResourceType will be just a wrapper around > ????String, so if you do: > > ????adminEvent. > > ?????? .operation(OperationType.CREATE) > > ?????? .resourceType(ResourceType.from("MY_FOO_RESOURCE")) > > ?????? ... > > ???? > > > ????it will just work. No need to register anything. Should be backwards > ????compatible too. Not sure which approach is better... Hmm interesting, but how do we not break the existing code? The?ResourceType.* fields should survive somehow. Do you suggest something like this? public class ResourceType { ? ? public static final ResourceType REALM = ResourceType.from("REALM"); ? ? public static final ResourceType REALM_ROLE = ResourceType.from("REALM_ROLE"); ? ? .... } > > > > > > > > > > > > The same approach could be applied to extending login events (potentially useful for custom authenticators etc.) What do you think? If everybody is OK with it, I can go on with JIRA and a PR. The login events already has "details", which allow you to add here any custom fields you want? Isn't that sufficient? > Ah, I've missed that. Indeed, that would be sufficient; however, I would also suggest introducing additional key to the?org.keycloak.events.EventType enum, like PROVIDER or EXTENDED or something like that. Imagine for example a custom authenticator working with hardware HOTP tokens. If a device gets out of sync, the user has to enter two consecutive passwords, so that the device gets resynched. (It's a real-world extension I've been working on BTW.) It's important to log such resync events, but they don't fit into any of ~70 types currently coded into EventType - hence the stipulation for additional type. Dmitry -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160926/c9cefab6/attachment.html From mitya at cargosoft.ru Mon Sep 26 12:20:38 2016 From: mitya at cargosoft.ru (Dmitry Telegin) Date: Mon, 26 Sep 2016 19:20:38 +0300 Subject: [keycloak-dev] Custom AdminEvents In-Reply-To: <1474905095.7390.43.camel@cargosoft.ru> References: <1474900897.7390.25.camel@cargosoft.ru> <1474905095.7390.43.camel@cargosoft.ru> Message-ID: <1474906838.7390.44.camel@cargosoft.ru> https://issues.jboss.org/browse/KEYCLOAK-3618 > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160926/429f5524/attachment.html From mauriciogiacomini at hotmail.com Mon Sep 26 14:27:18 2016 From: mauriciogiacomini at hotmail.com (=?iso-8859-1?Q?Maur=EDcio_Giacomini_Penteado?=) Date: Mon, 26 Sep 2016 18:27:18 +0000 Subject: [keycloak-dev] Infinite loop problem with authenticated users browsing out of root context In-Reply-To: References: , Message-ID: Thanks Sebastien! You was right! I had a conflict with angular initialization. Putting the script block in head of my "index.html" with a correct "angular.bootstrap" call and removing "ng-app" from my body tag all is working correctly!! Kind regards, Maur?cio. ________________________________ De: Sebastien Blanc Enviado: segunda-feira, 26 de setembro de 2016 15:28 Para: Maur?cio Giacomini Penteado Cc: keycloak-dev at lists.jboss.org Assunto: Re: [keycloak-dev] Infinite loop problem with authenticated users browsing out of root context I'm almost sure it is looping because of the automatic boostrap, looks at this demo app that has pretty much the some flow as your app https://github.com/jamesfalkner/coolstore-microservice/ and particulary this section https://github.com/jamesfalkner/coolstore-microservice/blob/master/coolstore-ui/app/app.js#L30-L47 jamesfalkner/coolstore-microservice github.com coolstore-microservice - This is an example demo showing a retail store consisting of a trio of microservices based on JBoss EAP 7 and Node.js, deployed to OpenShift and protected with Red Hat SSO. That could give you some ideas. Sebi On Mon, Sep 26, 2016 at 8:13 AM, Maur?cio Giacomini Penteado > wrote: Hi Sebastian I did a code very similar of photoz sample. On my "index.html" has the same To pass keycloak instance for angular code I put on my "app.js" a provider: var app = angular.module('myApp', []) .provider('keycloak', function () { return { setKeycloak: function (value) { keycloak = value; }, $get: function () { return keycloak; } }; }); Injecting keycloak on my controller I have success accessing keycloak methods like login or logout: app.controller('MainCtrl', ['$scope, ''keycloak', function ($scope, keycloak) { $scope.login = function () { keycloak.login(); }; $scope.logout = function () { keycloak.logout(); }; } ]); Doing this way, I can call angular login and logout from $scope in "index.html" that I have all keycloak event logs reported like photoz sample:
... The behavior of my app is that I described on last email with an infinite loop if an authenticated user browse to www.exampledomain.com/someAppPath. I am not doing the bootstrap of angular, perhaps it can be my problem. I not know where is the best place to do it, I will try find. Regards, Maur?cio. ________________________________ De: Sebastien Blanc > Enviado: segunda-feira, 26 de setembro de 2016 13:57 Para: Maur?cio Giacomini Penteado Cc: keycloak-dev at lists.jboss.org Assunto: Re: [keycloak-dev] Infinite loop problem with authenticated users browsing out of root context Could you share some code on how you initiate keycloak and bootstrap the angular app ? Le lundi 26 septembre 2016, Maur?cio Giacomini Penteado > a ?crit : Hello everybody I have a strange error trying codify with keycloak 2.0.0, Angular 1.5.8 and Wildfly 10. I am programming an application that follows concepts of "WYSIWYG". In my application I have setted keycloak to work on model "check-sso". All work perfectly if browsing is done with unauthenticated users on any path from my application. But strangely, authenticated users just can browse on root context from my application. If any aditional path is requested with an authenticated user the app starts a infinite loop. Example (with app running on root context "/"): www.exampledomain.com/ - > Works perfectly with authenticated users or unauthenticated users. www.exampledomain.com/someAppPath - > Just works with unauthenticated users. With authenticated users starts a infinite loop. If anybody has an idea to solve this problem please, let me know. Regards, Maur?cio. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160926/58e80999/attachment-0001.html From sthorger at redhat.com Tue Sep 27 01:09:50 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Tue, 27 Sep 2016 07:09:50 +0200 Subject: [keycloak-dev] xa-datasource requirement In-Reply-To: References: Message-ID: Fair enough, let's go for XA by default then. On 26 September 2016 at 16:17, Bill Burke wrote: > Don't think so. Anybody that has a 2nd datasource will now barf. arjuna > optimizes XA anyways is there is only one resource. > > On 9/26/16 2:32 AM, Stian Thorgersen wrote: > > Can't we just leave it as is and document if someone does indeed have a > custom provider with a separate datasource they need to change it? > > On 23 September 2016 at 21:31, Bill Burke wrote: > >> The User Storage Provider SPI example uses a different datasource than >> KeycloakDS. What I found is that switching Keycloak to use JTA creates >> a problem. If you have 2 non-xa datasources in the same JTA >> transaction, Wildfly barfs. It doesn't allow it. The workaround is >> have only one non-xa datasources and have all the rest be xa >> datasources, or to make them all be xa-datasources. >> >> I'm changing the KeycloakDS to be an xa-datasource. I don't think this >> will effect anybody's application, although i'll need to note in >> documentation that this is required and changed. >> >> >> Bill >> >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160927/1fc929a7/attachment.html From e.berdoncesbonelo at campus.tu-berlin.de Tue Sep 27 11:22:03 2016 From: e.berdoncesbonelo at campus.tu-berlin.de (Erik Berdonces Bonelo) Date: Tue, 27 Sep 2016 17:22:03 +0200 Subject: [keycloak-dev] Bug in User Roles inherited from Groups Message-ID: Hello, I?m mailing here as I found a bug, but I?m not sure if it?s an expected result. According to the documentation (https://keycloak.gitbooks.io/server-adminstration-guide/content/topics/groups.html) Groups in Keycloak allow you to manage a common set of attributes and role mappings for a set of users. Users can be members of zero or more groups. Users inherit the attributes and role mappings assigned to each group. Then, I assume that if I assign a role to a group, and it appears in the ?Effective Roles? tab of the group, any user inside of the group will inherit the roles. The problem: I?ve been testing with a simple OpenID Connect client in confidential mode, and the user doesn?t have any of this roles (I exposed Role as a mapper using User Realm Role mapper) and fetched the roles using an OIDC client. However, if I assign the roles directly to the user, the roles are returned as expected, in the User Info endpoint. Is it possible that there is a bug in the group system that is not giving the proper roles to the underneath users? Thanks a lot for your time, and have a nice week! ?? Best Regards,? Erik Berdonces Bonelo -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160927/fffe263d/attachment.html From mauriciogiacomini at hotmail.com Tue Sep 27 13:56:04 2016 From: mauriciogiacomini at hotmail.com (=?iso-8859-1?Q?Maur=EDcio_Giacomini_Penteado?=) Date: Tue, 27 Sep 2016 17:56:04 +0000 Subject: [keycloak-dev] Manage keycloak permissions of pictures and docs from users of system Message-ID: Hello everybody, I am researching what is the better way to work with keycloak to manage permissions of pictures and docs from users of system. Somebody knows if is there some system to manage pictures and docs that can be utilized together with keycloak? Kind regards, Maur?cio. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160927/0bbf5220/attachment.html From bruno at abstractj.org Tue Sep 27 13:59:51 2016 From: bruno at abstractj.org (Bruno Oliveira) Date: Tue, 27 Sep 2016 14:59:51 -0300 Subject: [keycloak-dev] Merge of keycloak-nodejs-connect and keycloak-nodejs-auth-utils Message-ID: <20160927175951.GA5614@abstractj.org> Good morning, Today the only use case scenario for keycloak-nodejs-auth-utils is the usage with keycloak-nodejs-connect for authorization. Besides that I don't see any reason to have it as a separate module. Unless we have plans for new modules like Passport strategies, or embed the authorization bits in some framework non-related with Connect. What do you guys think about merge auth-utils codebase into keycloak-nodejs-connect? -- abstractj PGP: 0x84DC9914 From sblanc at redhat.com Tue Sep 27 14:40:42 2016 From: sblanc at redhat.com (Sebastien Blanc) Date: Tue, 27 Sep 2016 11:40:42 -0700 Subject: [keycloak-dev] Merge of keycloak-nodejs-connect and keycloak-nodejs-auth-utils In-Reply-To: <20160927175951.GA5614@abstractj.org> References: <20160927175951.GA5614@abstractj.org> Message-ID: I know at least one project (a mbass solution) that is planning to replace some "manual" code by using the keycloak-nodejs-auth-utils module. It's in an integration layer and it only needs to handle token/grant retrieval and refresh. But I don't think it would be a real problem if this module is merged with connect. On Tue, Sep 27, 2016 at 10:59 AM, Bruno Oliveira wrote: > Good morning, > > Today the only use case scenario for > keycloak-nodejs-auth-utils is the usage with keycloak-nodejs-connect for > authorization. Besides that I don't see any reason to have it as a > separate module. Unless we have plans for new modules like Passport > strategies, or embed the authorization bits in some framework > non-related with Connect. > > What do you guys think about merge auth-utils codebase into > keycloak-nodejs-connect? > > -- > > abstractj > PGP: 0x84DC9914 > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160927/518e3fee/attachment.html From lholmqui at redhat.com Tue Sep 27 14:43:07 2016 From: lholmqui at redhat.com (Luke Holmquist) Date: Tue, 27 Sep 2016 14:43:07 -0400 Subject: [keycloak-dev] Merge of keycloak-nodejs-connect and keycloak-nodejs-auth-utils In-Reply-To: References: <20160927175951.GA5614@abstractj.org> Message-ID: that probably makes sense to merge, as long as the utils api is still available after the merge On Tue, Sep 27, 2016 at 2:40 PM, Sebastien Blanc wrote: > I know at least one project (a mbass solution) that is planning to > replace some "manual" code by using the keycloak-nodejs-auth-utils module. > It's in an integration layer and it only needs to handle token/grant > retrieval and refresh. > But I don't think it would be a real problem if this module is merged > with connect. > > > > On Tue, Sep 27, 2016 at 10:59 AM, Bruno Oliveira > wrote: > >> Good morning, >> >> Today the only use case scenario for >> keycloak-nodejs-auth-utils is the usage with keycloak-nodejs-connect for >> authorization. Besides that I don't see any reason to have it as a >> separate module. Unless we have plans for new modules like Passport >> strategies, or embed the authorization bits in some framework >> non-related with Connect. >> >> What do you guys think about merge auth-utils codebase into >> keycloak-nodejs-connect? >> >> -- >> >> abstractj >> PGP: 0x84DC9914 >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> > > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160927/8b0e03f1/attachment-0001.html From postmaster at lists.jboss.org Wed Sep 28 03:18:21 2016 From: postmaster at lists.jboss.org (MAILER-DAEMON) Date: Wed, 28 Sep 2016 12:48:21 +0530 Subject: [keycloak-dev] Returned mail: Data format error Message-ID: <201609280717.u8S7HbsQ000607@lists01.dmz-a.mwc.hst.phx2.redhat.com> The original message was included as attachment -------------- next part -------------- A non-text attachment was scrubbed... Name: aczgn.zip Type: application/octet-stream Size: 28980 bytes Desc: not available Url : http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160928/ce23effd/attachment-0001.obj From sthorger at redhat.com Wed Sep 28 04:58:08 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Wed, 28 Sep 2016 10:58:08 +0200 Subject: [keycloak-dev] Allow adapter subsystem to just inject dependencies In-Reply-To: <8b0a0f73-823e-1d17-5e39-b4316eab30ef@redhat.com> References: <8b0a0f73-823e-1d17-5e39-b4316eab30ef@redhat.com> Message-ID: Not sure even using "" makes sense at all in this case. If there's keycloak.json the subsystem still injects the dependencies, but doesn't do any configuration. Why can't it just rely on that? On 26 September 2016 at 16:39, Marek Posolda wrote: > I've did some testing with hawtio on EAP 7. It works fine, however there > is one thing in our subsystem, which may improve integration a bit. > > Hawtio doesn't use servlet security ( security-constraints in web.xml ) > but they rely on JAAS, which is needed for JMX calls to be performed on > behalf of JAAS Subject. Hawtio WAR needs to have access to > keycloak-adapter classes (as it needs login modules for JAAS), however > it doesn't need subsystem to configure adapter. This is all handled by > JAAS login module. > > In other words, it will be nice if subsystem can just inject > dependencies ( KeycloakDependencyProcessor ), but ignore adding > subsystem configuration ( KeycloakAdapterConfigDeploymentProcessor ). > > The workaround I used was to add secure-deployment section to > standalone.xml with some dummy values, which are mandatory for > subsystem. It works, but it's really not too pretty IMO. Something like: > > > does-not-matter > does-not-matter > > > What will be nice is to have some of those possibilities: > > 1) Have subsystem to use some default values like "undefined" instead of > null . This is more a workaround as subsystem will still process the > KeycloakAdapterConfigDeploymentProcessor. However it's less work and it > will improve usability, so this will work just fine: > > > > > 2) Tell the subsystem to ignore > KeycloakAdapterConfigDeploymentProcessor. Looks like more work, but > seems to be more proper solution than (1). I can think of: > > 2.a) some flag like: > > > > 2.b) Use different element like "deployment" instead of > "secure-deployment" . The "deployment" will inject dependencies, but > won't handle adapter configuration. So something like this will work: > > > > > WDYT? > Marek > > > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160928/a4ed6171/attachment.html From bruno at abstractj.org Wed Sep 28 05:53:31 2016 From: bruno at abstractj.org (Bruno Oliveira) Date: Wed, 28 Sep 2016 06:53:31 -0300 Subject: [keycloak-dev] Merge of keycloak-nodejs-connect and keycloak-nodejs-auth-utils In-Reply-To: References: <20160927175951.GA5614@abstractj.org> Message-ID: <20160928095331.GA8140@abstractj.org> On 2016-09-27, Sebastien Blanc wrote: > I know at least one project (a mbass solution) that is planning to replace > some "manual" code by using the keycloak-nodejs-auth-utils module. It's in > an integration layer and it only needs to handle token/grant retrieval and > refresh. In this scenario, they don't have connect or express? If possible, would you mind to elaborate more? > But I don't think it would be a real problem if this module is merged > with connect. > > > > On Tue, Sep 27, 2016 at 10:59 AM, Bruno Oliveira > wrote: > > > Good morning, > > > > Today the only use case scenario for > > keycloak-nodejs-auth-utils is the usage with keycloak-nodejs-connect for > > authorization. Besides that I don't see any reason to have it as a > > separate module. Unless we have plans for new modules like Passport > > strategies, or embed the authorization bits in some framework > > non-related with Connect. > > > > What do you guys think about merge auth-utils codebase into > > keycloak-nodejs-connect? > > > > -- > > > > abstractj > > PGP: 0x84DC9914 > > _______________________________________________ > > keycloak-dev mailing list > > keycloak-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > -- abstractj PGP: 0x84DC9914 From sthorger at redhat.com Wed Sep 28 05:55:24 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Wed, 28 Sep 2016 11:55:24 +0200 Subject: [keycloak-dev] 2.x feature freeze approaching! Message-ID: 2.3.0.CR1 is scheduled to be released on 19th October. After this release we will not accept any new features for 2.x. Please have any PRs ready before 17th October! After 2.3 is released we will focus on bug fixing for 2.4.0. Following 2.4.0 there will most likely be a few micro releases (2.4.1, 2.4.2, etc.) before we start work on 3.0. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160928/91c4a921/attachment.html From sblanc at redhat.com Wed Sep 28 07:26:49 2016 From: sblanc at redhat.com (Sebastien Blanc) Date: Wed, 28 Sep 2016 13:26:49 +0200 Subject: [keycloak-dev] Merge of keycloak-nodejs-connect and keycloak-nodejs-auth-utils In-Reply-To: <20160928095331.GA8140@abstractj.org> References: <20160927175951.GA5614@abstractj.org> <20160928095331.GA8140@abstractj.org> Message-ID: On Wed, Sep 28, 2016 at 11:53 AM, Bruno Oliveira wrote: > On 2016-09-27, Sebastien Blanc wrote: > > I know at least one project (a mbass solution) that is planning to > replace > > some "manual" code by using the keycloak-nodejs-auth-utils module. It's > in > > an integration layer and it only needs to handle token/grant retrieval > and > > refresh. > > In this scenario, they don't have connect or express? If possible, > would you mind to elaborate more? > Sure. In this use case the nodejs app act as a "client" for a third application (the UnifiedPush Server) that is protected by KC. The authentification system of the whole system is not based on KC (not yet ;) ) and for now the nodejs needs to retrieve "manually" a token to be able to pass it to the requests to the UPS. > > > But I don't think it would be a real problem if this module is merged > > with connect. > > > > > > > > On Tue, Sep 27, 2016 at 10:59 AM, Bruno Oliveira > > wrote: > > > > > Good morning, > > > > > > Today the only use case scenario for > > > keycloak-nodejs-auth-utils is the usage with keycloak-nodejs-connect > for > > > authorization. Besides that I don't see any reason to have it as a > > > separate module. Unless we have plans for new modules like Passport > > > strategies, or embed the authorization bits in some framework > > > non-related with Connect. > > > > > > What do you guys think about merge auth-utils codebase into > > > keycloak-nodejs-connect? > > > > > > -- > > > > > > abstractj > > > PGP: 0x84DC9914 > > > _______________________________________________ > > > keycloak-dev mailing list > > > keycloak-dev at lists.jboss.org > > > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > > > -- > > abstractj > PGP: 0x84DC9914 > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160928/7a13d5f5/attachment.html From bruno at abstractj.org Wed Sep 28 07:41:23 2016 From: bruno at abstractj.org (Bruno Oliveira) Date: Wed, 28 Sep 2016 11:41:23 +0000 Subject: [keycloak-dev] Merge of keycloak-nodejs-connect and keycloak-nodejs-auth-utils In-Reply-To: References: <20160927175951.GA5614@abstractj.org> <20160928095331.GA8140@abstractj.org> Message-ID: Thanks for clarifying Sebi. In this case, let's leave it as is. On Wed, Sep 28, 2016 at 8:26 AM Sebastien Blanc wrote: > On Wed, Sep 28, 2016 at 11:53 AM, Bruno Oliveira > wrote: > >> On 2016-09-27, Sebastien Blanc wrote: >> > I know at least one project (a mbass solution) that is planning to >> replace >> > some "manual" code by using the keycloak-nodejs-auth-utils module. It's >> in >> > an integration layer and it only needs to handle token/grant retrieval >> and >> > refresh. >> >> In this scenario, they don't have connect or express? If possible, >> would you mind to elaborate more? >> > > Sure. In this use case the nodejs app act as a "client" for a third > application (the UnifiedPush Server) that is protected by KC. The > authentification system of the whole system is not based on KC (not yet ;) > ) and for now the nodejs needs to retrieve "manually" a token to be able to > pass it to the requests to the UPS. > > >> >> > But I don't think it would be a real problem if this module is merged >> > with connect. >> > >> > >> > >> > On Tue, Sep 27, 2016 at 10:59 AM, Bruno Oliveira >> > wrote: >> > >> > > Good morning, >> > > >> > > Today the only use case scenario for >> > > keycloak-nodejs-auth-utils is the usage with keycloak-nodejs-connect >> for >> > > authorization. Besides that I don't see any reason to have it as a >> > > separate module. Unless we have plans for new modules like Passport >> > > strategies, or embed the authorization bits in some framework >> > > non-related with Connect. >> > > >> > > What do you guys think about merge auth-utils codebase into >> > > keycloak-nodejs-connect? >> > > >> > > -- >> > > >> > > abstractj >> > > PGP: 0x84DC9914 >> > > _______________________________________________ >> > > keycloak-dev mailing list >> > > keycloak-dev at lists.jboss.org >> > > https://lists.jboss.org/mailman/listinfo/keycloak-dev >> > > >> >> -- >> >> abstractj >> PGP: 0x84DC9914 >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160928/27e29358/attachment-0001.html From e.berdoncesbonelo at campus.tu-berlin.de Wed Sep 28 07:51:37 2016 From: e.berdoncesbonelo at campus.tu-berlin.de (Erik Berdonces Bonelo) Date: Wed, 28 Sep 2016 13:51:37 +0200 Subject: [keycloak-dev] Client Self-Registration and Administration Plugin In-Reply-To: References: Message-ID: Hi Stian, Sorry for coming back so late, opening again this thread. I?m focusing now in the implementation in Keycloak, and I really appreciate the updated documents in v2.2.1. They really help a lot. Just one question: how is it possible to add a custom attribute to a client? It?s well documented how to do so with a User, but it?s not clear how to do it with a client. The idea is to add a customisable attribute, that you can send through the Client Registration API as a parameter and keep it in the client. ?? BestRegards,? Erik Berdonces Bonelo On 8 June 2016 at 06:40:47, Stian Thorgersen (sthorger at redhat.com) wrote: On 7 June 2016 at 15:32, Erik Berdonces Bonelo wrote: Hi, Thanks for the fast answer. I totally understand the permissions issue, and well, the reason to send the previous mail was just to avoid this kind of problems. Regarding to your suggestion on how to implement the self-registration, I understand (after reading the documentation again) how to use the Realm Resource SPI ?together with user attributes or either use the Client Registration Service. However, as I see, there is no way to integrate it with the existing UI that Keycloak has,doesn?t it? I?ve only been able to find that there are ways to extend the ServerInfo page with some information, (example found in chapter 4.1.1 in the documentation). Is there anything similar to a FormAction as described in 34.5.1 in the documentation to integrate this extension with Keycloak?s UI, or I should create my own UI to create the interface for this custom endpoints? You can extend the admin console by adding a custom admin theme. It's not to elegant and requires some effort when upgrading to new versions, but it's possible. It may be simpler to create your own UI. If you create the UI as a HTML5 you can add the html files, javascript, etc. to a custom admin theme and all you'd have to do is to have a realm resource provide the landing page and then point to resource like our admin console does (which is then loaded from the theme).? ? I?m sorry if this questions may be a bit basic, but even with the documentation, as it is so extensive, I get sometimes a bit lost on what tools I have available to implement with in this platform. A lot of the SPIs and customization parts are not polished or documented well so not to worry ;) ? ?? Best Regards,? Erik Berdonces Bonelo On 6 June 2016 at 19:36:07, Stian Thorgersen (sthorger at redhat.com) wrote: Hi, We are planing to add more fine-grained permissions on admin endpoints in the future, but it will be a while until we get to it. I'm not very keen on accepting something like this now as we are planning to do fairly big changes around this in the future. You're also the first person to ask about having clients specific to user, other people have so far requested groups of clients that groups of users can manage. I'd recommend using the Realm Resource SPI to create custom endpoints to accomplish this. You can use an attribute on the clients to store the user that has created the client and only allow that user to modify it in the future. You can also consider using the client registration service. The client registration service allows anyone with a create-role or an initial access token to create clients. When a client is created it returns a registration access token that gives permission to modify/delete that particular client in the future. On 6 June 2016 at 14:39, Erik Berdonces Bonelo wrote: ? Hello, I?m working at the moment in a Master Thesis project in TU Berlin where we are using Keycloak for Authentication and Authorisation purposes. We are planning on extending Keycloak in order to provide users a way to register clients/applications by themselves into the platform, while having an admin overseeing the system. This would mean that as a user, if I have the proper rights I should be able to create and manage my own clients. With, this it comes the idea of ownership, as this would mean that a client ownership could be transferred to someone else. Also, the admin should be able to accept, revoke and delete the clients and requests to create clients in my Keycloak. At the moment the only option would be giving the permission to create clients to the user, but that would allow to change ANY of the possible clients. Then, I have two questions: ? 1. Would it make sense to integrate this to the Keycloak core? ? 2. If it doesn?t make sense to merge it in the core, is there any plugin system to extend Keycloak?s core? I?ve seen a discussion related to a plugin system in GitHub but there is no outcome yet. We would rather like to integrate it with Keycloak itself, otherwise the other option would be creating a client that uses Keycloak?s REST API to manage the clients remotely. Thanks a lot in advance!? ??? ?Best Regards, ?Erik Berdonces Bonelo _______________________________________________ keycloak-dev mailing list keycloak-dev at lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160928/4aaeec8b/attachment.html From e.berdoncesbonelo at campus.tu-berlin.de Wed Sep 28 07:55:26 2016 From: e.berdoncesbonelo at campus.tu-berlin.de (Erik Berdonces Bonelo) Date: Wed, 28 Sep 2016 13:55:26 +0200 Subject: [keycloak-dev] Client Self-Registration and Administration Plugin In-Reply-To: References: Message-ID: (the mail got sent by mistake without finishing) Then, it I?d try to filter the users using this parameter (somehow like a dynamic scope, but depending on a parameter, rather than the role). I was thinking on adding a custom validation flow and use there a Script Based Authentication to check if a user can go through or not. Do you think this is feasible? As I?m not sure (and that part is not so well documented) if it?s possible to access the client attributes from the Authentication Script. Thanks a lot and sorry for the split message! ?? Best Regards,? Erik Berdonces Bonelo On 28 September 2016 at 13:52:42, Erik Berdonces Bonelo (e.berdoncesbonelo at campus.tu-berlin.de) wrote: Hi Stian, Sorry for coming back so late, opening again this thread. I?m focusing now in the implementation in Keycloak, and I really appreciate the updated documents in v2.2.1. They really help a lot. Just one question: how is it possible to add a custom attribute to a client? It?s well documented how to do so with a User, but it?s not clear how to do it with a client. The idea is to add a customisable attribute, that you can send through the Client Registration API as a parameter and keep it in the client. ?? BestRegards,? Erik Berdonces Bonelo On 8 June 2016 at 06:40:47, Stian Thorgersen (sthorger at redhat.com) wrote: On 7 June 2016 at 15:32, Erik Berdonces Bonelo wrote: Hi, Thanks for the fast answer. I totally understand the permissions issue, and well, the reason to send the previous mail was just to avoid this kind of problems. Regarding to your suggestion on how to implement the self-registration, I understand (after reading the documentation again) how to use the Realm Resource SPI ?together with user attributes or either use the Client Registration Service. However, as I see, there is no way to integrate it with the existing UI that Keycloak has,doesn?t it? I?ve only been able to find that there are ways to extend the ServerInfo page with some information, (example found in chapter 4.1.1 in the documentation). Is there anything similar to a FormAction as described in 34.5.1 in the documentation to integrate this extension with Keycloak?s UI, or I should create my own UI to create the interface for this custom endpoints? You can extend the admin console by adding a custom admin theme. It's not to elegant and requires some effort when upgrading to new versions, but it's possible. It may be simpler to create your own UI. If you create the UI as a HTML5 you can add the html files, javascript, etc. to a custom admin theme and all you'd have to do is to have a realm resource provide the landing page and then point to resource like our admin console does (which is then loaded from the theme).? ? I?m sorry if this questions may be a bit basic, but even with the documentation, as it is so extensive, I get sometimes a bit lost on what tools I have available to implement with in this platform. A lot of the SPIs and customization parts are not polished or documented well so not to worry ;) ? ?? Best Regards,? Erik Berdonces Bonelo On 6 June 2016 at 19:36:07, Stian Thorgersen (sthorger at redhat.com) wrote: Hi, We are planing to add more fine-grained permissions on admin endpoints in the future, but it will be a while until we get to it. I'm not very keen on accepting something like this now as we are planning to do fairly big changes around this in the future. You're also the first person to ask about having clients specific to user, other people have so far requested groups of clients that groups of users can manage. I'd recommend using the Realm Resource SPI to create custom endpoints to accomplish this. You can use an attribute on the clients to store the user that has created the client and only allow that user to modify it in the future. You can also consider using the client registration service. The client registration service allows anyone with a create-role or an initial access token to create clients. When a client is created it returns a registration access token that gives permission to modify/delete that particular client in the future. On 6 June 2016 at 14:39, Erik Berdonces Bonelo wrote: ? Hello, I?m working at the moment in a Master Thesis project in TU Berlin where we are using Keycloak for Authentication and Authorisation purposes. We are planning on extending Keycloak in order to provide users a way to register clients/applications by themselves into the platform, while having an admin overseeing the system. This would mean that as a user, if I have the proper rights I should be able to create and manage my own clients. With, this it comes the idea of ownership, as this would mean that a client ownership could be transferred to someone else. Also, the admin should be able to accept, revoke and delete the clients and requests to create clients in my Keycloak. At the moment the only option would be giving the permission to create clients to the user, but that would allow to change ANY of the possible clients. Then, I have two questions: ? 1. Would it make sense to integrate this to the Keycloak core? ? 2. If it doesn?t make sense to merge it in the core, is there any plugin system to extend Keycloak?s core? I?ve seen a discussion related to a plugin system in GitHub but there is no outcome yet. We would rather like to integrate it with Keycloak itself, otherwise the other option would be creating a client that uses Keycloak?s REST API to manage the clients remotely. Thanks a lot in advance!? ??? ?Best Regards, ?Erik Berdonces Bonelo _______________________________________________ keycloak-dev mailing list keycloak-dev at lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160928/58138236/attachment-0001.html From lholmqui at redhat.com Wed Sep 28 09:27:44 2016 From: lholmqui at redhat.com (Luke Holmquist) Date: Wed, 28 Sep 2016 09:27:44 -0400 Subject: [keycloak-dev] Merge of keycloak-nodejs-connect and keycloak-nodejs-auth-utils In-Reply-To: References: <20160927175951.GA5614@abstractj.org> <20160928095331.GA8140@abstractj.org> Message-ID: that "retrieving" of a token sounds familiar, would the keycloak-request-token, https://github.com/bucharest-gold/keycloak-request-token be useful here. I have a feeling that this project duplicates some of the auth-utils functionality On Wed, Sep 28, 2016 at 7:41 AM, Bruno Oliveira wrote: > Thanks for clarifying Sebi. In this case, let's leave it as is. > > On Wed, Sep 28, 2016 at 8:26 AM Sebastien Blanc wrote: > >> On Wed, Sep 28, 2016 at 11:53 AM, Bruno Oliveira >> wrote: >> >>> On 2016-09-27, Sebastien Blanc wrote: >>> > I know at least one project (a mbass solution) that is planning to >>> replace >>> > some "manual" code by using the keycloak-nodejs-auth-utils module. >>> It's in >>> > an integration layer and it only needs to handle token/grant retrieval >>> and >>> > refresh. >>> >>> In this scenario, they don't have connect or express? If possible, >>> would you mind to elaborate more? >>> >> >> Sure. In this use case the nodejs app act as a "client" for a third >> application (the UnifiedPush Server) that is protected by KC. The >> authentification system of the whole system is not based on KC (not yet ;) >> ) and for now the nodejs needs to retrieve "manually" a token to be able to >> pass it to the requests to the UPS. >> >> >>> >>> > But I don't think it would be a real problem if this module is merged >>> > with connect. >>> > >>> > >>> > >>> > On Tue, Sep 27, 2016 at 10:59 AM, Bruno Oliveira >>> > wrote: >>> > >>> > > Good morning, >>> > > >>> > > Today the only use case scenario for >>> > > keycloak-nodejs-auth-utils is the usage with keycloak-nodejs-connect >>> for >>> > > authorization. Besides that I don't see any reason to have it as a >>> > > separate module. Unless we have plans for new modules like Passport >>> > > strategies, or embed the authorization bits in some framework >>> > > non-related with Connect. >>> > > >>> > > What do you guys think about merge auth-utils codebase into >>> > > keycloak-nodejs-connect? >>> > > >>> > > -- >>> > > >>> > > abstractj >>> > > PGP: 0x84DC9914 >>> > > _______________________________________________ >>> > > keycloak-dev mailing list >>> > > keycloak-dev at lists.jboss.org >>> > > https://lists.jboss.org/mailman/listinfo/keycloak-dev >>> > > >>> >>> -- >>> >>> abstractj >>> PGP: 0x84DC9914 >>> >> > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160928/99f7eb84/attachment.html From mposolda at redhat.com Thu Sep 29 02:18:16 2016 From: mposolda at redhat.com (Marek Posolda) Date: Thu, 29 Sep 2016 08:18:16 +0200 Subject: [keycloak-dev] Allow adapter subsystem to just inject dependencies In-Reply-To: References: <8b0a0f73-823e-1d17-5e39-b4316eab30ef@redhat.com> Message-ID: On 28/09/16 10:58, Stian Thorgersen wrote: > Not sure even using "" makes sense at all in > this case. If there's keycloak.json the subsystem still injects the > dependencies, but doesn't do any configuration. Why can't it just rely > on that? Without "secure-deployment", you also need the KEYCLOAK in login-config in web.xml in addition to keycloak.json. Anyway, regarding usability, I suspect it's not an option to require people to crack inside hawtio.war and change the things in the WAR directly? Otherwise they can just add jboss-deployment-structure.xml into the hawtio.war and I don't need to care about subsystem at all. Marek > > On 26 September 2016 at 16:39, Marek Posolda > wrote: > > I've did some testing with hawtio on EAP 7. It works fine, however > there > is one thing in our subsystem, which may improve integration a bit. > > Hawtio doesn't use servlet security ( security-constraints in > web.xml ) > but they rely on JAAS, which is needed for JMX calls to be > performed on > behalf of JAAS Subject. Hawtio WAR needs to have access to > keycloak-adapter classes (as it needs login modules for JAAS), however > it doesn't need subsystem to configure adapter. This is all handled by > JAAS login module. > > In other words, it will be nice if subsystem can just inject > dependencies ( KeycloakDependencyProcessor ), but ignore adding > subsystem configuration ( KeycloakAdapterConfigDeploymentProcessor ). > > The workaround I used was to add secure-deployment section to > standalone.xml with some dummy values, which are mandatory for > subsystem. It works, but it's really not too pretty IMO. Something > like: > > > does-not-matter > does-not-matter > > > What will be nice is to have some of those possibilities: > > 1) Have subsystem to use some default values like "undefined" > instead of > null . This is more a workaround as subsystem will still process the > KeycloakAdapterConfigDeploymentProcessor. However it's less work > and it > will improve usability, so this will work just fine: > > > > > 2) Tell the subsystem to ignore > KeycloakAdapterConfigDeploymentProcessor. Looks like more work, but > seems to be more proper solution than (1). I can think of: > > 2.a) some flag like: > > ignore-deployment-config="true" /> > > 2.b) Use different element like "deployment" instead of > "secure-deployment" . The "deployment" will inject dependencies, but > won't handle adapter configuration. So something like this will work: > > > > > WDYT? > Marek > > > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160929/e017f86a/attachment.html From sthorger at redhat.com Thu Sep 29 03:27:29 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Thu, 29 Sep 2016 09:27:29 +0200 Subject: [keycloak-dev] Move documentation to a single book/repository Message-ID: To simplify maintaining and editing the documentation I propose we move all guides to a single repository and a single book on Gitbook. I did a quick check to see it works here: https://stianst.gitbooks.io/keycloak-documentation/content/index.html Opinions? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160929/c3061d3f/attachment.html From martin.hardselius at gmail.com Thu Sep 29 03:31:34 2016 From: martin.hardselius at gmail.com (Martin Hardselius) Date: Thu, 29 Sep 2016 07:31:34 +0000 Subject: [keycloak-dev] [keycloak-user] Keycloak 2.2.1.Final Released In-Reply-To: References: Message-ID: FYI: The image jboss/keycloak:2.2.1.Final is missing from Docker Hub (which makes the jboss/keycloak-mysql:2.2.1.Final build crash). If you already knew this, then nvm. On Wed, 21 Sep 2016 at 12:08 Stian Thorgersen wrote: > Keycloak 2.2.1.Final has just been released. This release fixes an issue > in the JavaScript adapter that was introduced in 2.2.0.Final, for more > details see KEYCLOAK-3586 . > > _______________________________________________ > keycloak-user mailing list > keycloak-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160929/9ee90519/attachment.html From sthorger at redhat.com Thu Sep 29 03:36:24 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Thu, 29 Sep 2016 09:36:24 +0200 Subject: [keycloak-dev] [keycloak-user] Keycloak 2.2.1.Final Released In-Reply-To: References: Message-ID: Not sure what happened there, latest built just fine, but 2.2.1.Final tag didn't. I've re-created the tag to see if Docker hub manages to build it this time. On 29 September 2016 at 09:31, Martin Hardselius < martin.hardselius at gmail.com> wrote: > FYI: The image jboss/keycloak:2.2.1.Final is missing from Docker Hub > (which makes the jboss/keycloak-mysql:2.2.1.Final build crash). > > If you already knew this, then nvm. > > On Wed, 21 Sep 2016 at 12:08 Stian Thorgersen wrote: > >> Keycloak 2.2.1.Final has just been released. This release fixes an issue >> in the JavaScript adapter that was introduced in 2.2.0.Final, for more >> details see KEYCLOAK-3586 >> . >> >> _______________________________________________ >> keycloak-user mailing list >> keycloak-user at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-user > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160929/6854dfd4/attachment-0001.html From sblanc at redhat.com Thu Sep 29 03:42:12 2016 From: sblanc at redhat.com (Sebastien Blanc) Date: Thu, 29 Sep 2016 09:42:12 +0200 Subject: [keycloak-dev] Move documentation to a single book/repository In-Reply-To: References: Message-ID: +1 That is really more convenient ! On Thu, Sep 29, 2016 at 9:27 AM, Stian Thorgersen wrote: > To simplify maintaining and editing the documentation I propose we move > all guides to a single repository and a single book on Gitbook. > > I did a quick check to see it works here: https://stianst. > gitbooks.io/keycloak-documentation/content/index.html > > Opinions? > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160929/c083c88a/attachment.html From sthorger at redhat.com Thu Sep 29 04:06:03 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Thu, 29 Sep 2016 10:06:03 +0200 Subject: [keycloak-dev] Bug in User Roles inherited from Groups In-Reply-To: References: Message-ID: So you're using a custom mapper to expose the role rather than relying on the roles? Sounds like the bug is that the custom mapper doesn't see the roles inherited from the group. On 27 September 2016 at 17:22, Erik Berdonces Bonelo < e.berdoncesbonelo at campus.tu-berlin.de> wrote: > Hello, > > I?m mailing here as I found a bug, but I?m not sure if it?s an expected > result. > > According to the documentation (https://keycloak.gitbooks.io/ > server-adminstration-guide/content/topics/groups.html) > > Groups in Keycloak allow you to manage a common set of attributes and role > mappings for a set of users. Users can be members of zero or more groups. *Users > inherit the attributes and role mappings assigned to each group*. > > Then, I assume that if I assign a role to a group, and it appears in the > ?Effective Roles? tab of the group, any user inside of the group will > inherit the roles. > > The problem: I?ve been testing with a simple OpenID Connect client in > confidential mode, and the user doesn?t have any of this roles (I exposed > Role as a mapper using User Realm Role mapper) and fetched the roles using > an OIDC client. > > However, if I assign the roles directly to the user, the roles are > returned as expected, in the User Info endpoint. > > Is it possible that there is a bug in the group system that is not giving > the proper roles to the underneath users? > > Thanks a lot for your time, and have a nice week! > > ? > Best Regards, > > Erik Berdonces Bonelo > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160929/97352e05/attachment.html From sthorger at redhat.com Thu Sep 29 04:06:57 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Thu, 29 Sep 2016 10:06:57 +0200 Subject: [keycloak-dev] Bug in User Roles inherited from Groups In-Reply-To: References: Message-ID: Bad wording. I didn't mean "custom" mapper, I meant you add a user realm role mapper to assign the specific role to a separate field on the token. On 29 September 2016 at 10:06, Stian Thorgersen wrote: > So you're using a custom mapper to expose the role rather than relying on > the roles? Sounds like the bug is that the custom mapper doesn't see the > roles inherited from the group. > > On 27 September 2016 at 17:22, Erik Berdonces Bonelo < > e.berdoncesbonelo at campus.tu-berlin.de> wrote: > >> Hello, >> >> I?m mailing here as I found a bug, but I?m not sure if it?s an expected >> result. >> >> According to the documentation (https://keycloak.gitbooks.io/ >> server-adminstration-guide/content/topics/groups.html) >> >> Groups in Keycloak allow you to manage a common set of attributes and >> role mappings for a set of users. Users can be members of zero or more >> groups. *Users inherit the attributes and role mappings assigned to each >> group*. >> >> Then, I assume that if I assign a role to a group, and it appears in the >> ?Effective Roles? tab of the group, any user inside of the group will >> inherit the roles. >> >> The problem: I?ve been testing with a simple OpenID Connect client in >> confidential mode, and the user doesn?t have any of this roles (I exposed >> Role as a mapper using User Realm Role mapper) and fetched the roles using >> an OIDC client. >> >> However, if I assign the roles directly to the user, the roles are >> returned as expected, in the User Info endpoint. >> >> Is it possible that there is a bug in the group system that is not giving >> the proper roles to the underneath users? >> >> Thanks a lot for your time, and have a nice week! >> >> ? >> Best Regards, >> >> Erik Berdonces Bonelo >> >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160929/4858d520/attachment.html From sthorger at redhat.com Thu Sep 29 04:09:49 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Thu, 29 Sep 2016 10:09:49 +0200 Subject: [keycloak-dev] Allow adapter subsystem to just inject dependencies In-Reply-To: References: <8b0a0f73-823e-1d17-5e39-b4316eab30ef@redhat.com> Message-ID: Oki, so sounds like what you proposed is the way to go. I'm not to keen on option 2 or 3 as they seem a bit artificial. Why do they not need auth-server-url though? On 29 September 2016 at 08:18, Marek Posolda wrote: > On 28/09/16 10:58, Stian Thorgersen wrote: > > Not sure even using "" makes sense at all in this > case. If there's keycloak.json the subsystem still injects the > dependencies, but doesn't do any configuration. Why can't it just rely on > that? > > Without "secure-deployment", you also need the KEYCLOAK in login-config in > web.xml in addition to keycloak.json. > > Anyway, regarding usability, I suspect it's not an option to require > people to crack inside hawtio.war and change the things in the WAR > directly? Otherwise they can just add jboss-deployment-structure.xml into > the hawtio.war and I don't need to care about subsystem at all. > > Marek > > > > > On 26 September 2016 at 16:39, Marek Posolda wrote: > >> I've did some testing with hawtio on EAP 7. It works fine, however there >> is one thing in our subsystem, which may improve integration a bit. >> >> Hawtio doesn't use servlet security ( security-constraints in web.xml ) >> but they rely on JAAS, which is needed for JMX calls to be performed on >> behalf of JAAS Subject. Hawtio WAR needs to have access to >> keycloak-adapter classes (as it needs login modules for JAAS), however >> it doesn't need subsystem to configure adapter. This is all handled by >> JAAS login module. >> >> In other words, it will be nice if subsystem can just inject >> dependencies ( KeycloakDependencyProcessor ), but ignore adding >> subsystem configuration ( KeycloakAdapterConfigDeploymentProcessor ). >> >> The workaround I used was to add secure-deployment section to >> standalone.xml with some dummy values, which are mandatory for >> subsystem. It works, but it's really not too pretty IMO. Something like: >> >> >> does-not-matter >> does-not-matter >> >> >> What will be nice is to have some of those possibilities: >> >> 1) Have subsystem to use some default values like "undefined" instead of >> null . This is more a workaround as subsystem will still process the >> KeycloakAdapterConfigDeploymentProcessor. However it's less work and it >> will improve usability, so this will work just fine: >> >> >> >> >> 2) Tell the subsystem to ignore >> KeycloakAdapterConfigDeploymentProcessor. Looks like more work, but >> seems to be more proper solution than (1). I can think of: >> >> 2.a) some flag like: >> >> >> >> 2.b) Use different element like "deployment" instead of >> "secure-deployment" . The "deployment" will inject dependencies, but >> won't handle adapter configuration. So something like this will work: >> >> >> >> >> WDYT? >> Marek >> >> >> >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160929/9b560123/attachment-0001.html From yunusoncel at gmail.com Thu Sep 29 04:33:49 2016 From: yunusoncel at gmail.com (=?UTF-8?B?WXVudXMgw5ZOQ0VM?=) Date: Thu, 29 Sep 2016 11:33:49 +0300 Subject: [keycloak-dev] Custom Authenticator Message-ID: Hello; i have described for MD5 passwort. now i write to database password of users with MD5ed password. it is possible, Can ? wr?te or change custom Authenticator with hilfe SPI? Because i need another conditon to the correct user to the login. thank you and sorry for my English -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160929/1de918c3/attachment.html From mauriciogiacomini at hotmail.com Thu Sep 29 09:51:38 2016 From: mauriciogiacomini at hotmail.com (=?iso-8859-1?Q?Maur=EDcio_Giacomini_Penteado?=) Date: Thu, 29 Sep 2016 13:51:38 +0000 Subject: [keycloak-dev] Possible BUG creating User via REST API Message-ID: Hello everybody, All times that I create an user via REST API I have to do login on keycloak using administrator account and have to update the credentials from user created via REST API with temporary password setted to false. Just if I do these procedures I can do login on my app using the user created via REST API. I am using the follow code to create an user via REST API: ..... CredentialRepresentation credential = new CredentialRepresentation(); credential.setType(CredentialRepresentation.PASSWORD); credential.setValue("test123"); credential.setTemporary(false); UserRepresentation user = new UserRepresentation(); user.setUsername("testuser"); user.setFirstName("Test"); user.setLastName("User"); user.setCredentials(Arrays.asList(credential)); user.setEnabled(true); Response result = kc.realm("rest-example").users().create(user); I have setted on code false for temporary credential and user as enabled, even so, I can not do login on my application using the created user without do the procedures that I wrote at the beginning of this issue. I think that REST API is not respecting the properties of temporary credential setted to false and user setted as enabled. It can be a BUG? If anybody knows how can I update the credentials from a new user created via REST API leaving it able to do login on my application please let me know. Regards, Maur?cio. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160929/ea2f1cc7/attachment.html From mauriciogiacomini at hotmail.com Thu Sep 29 16:23:14 2016 From: mauriciogiacomini at hotmail.com (=?iso-8859-1?Q?Maur=EDcio_Giacomini_Penteado?=) Date: Thu, 29 Sep 2016 20:23:14 +0000 Subject: [keycloak-dev] Possible BUG creating User via REST API In-Reply-To: References: , Message-ID: Hi Sebastien, thanks for answering. I am trying your code but, I always receive a "Failed executing GET /admin/realms/SGCD/users: org.jboss.resteasy.spi.UnauthorizedException: Bearer". Please, you know if Is there some way for I put my bearer token on resetPassword call or on KeycloakBuilder? I have tried using: ResteasyClient resteasyClient = new ResteasyClientBuilder() .connectionPoolSize(10).build(); resteasyClient.target(KEYCLOAK_HOST) .register(BEARER_TOKEN); ________________________________ De: Sebastien Blanc Enviado: quinta-feira, 29 de setembro de 2016 14:08 Para: Maur?cio Giacomini Penteado Assunto: Re: [keycloak-dev] Possible BUG creating User via REST API Hi Mauricio, This is not a bug, you need to reset the password after that the user has been created, using something like : CredentialRepresentation credentials = new CredentialRepresentation(); credentials.setType(CredentialRepresentation.PASSWORD); credentials.setValue("password"); keycloak.realm("realm").users().get(id).resetPassword(credentials); On Thu, Sep 29, 2016 at 3:51 PM, Maur?cio Giacomini Penteado > wrote: Hello everybody, All times that I create an user via REST API I have to do login on keycloak using administrator account and have to update the credentials from user created via REST API with temporary password setted to false. Just if I do these procedures I can do login on my app using the user created via REST API. I am using the follow code to create an user via REST API: ..... CredentialRepresentation credential = new CredentialRepresentation(); credential.setType(CredentialRepresentation.PASSWORD); credential.setValue("test123"); credential.setTemporary(false); UserRepresentation user = new UserRepresentation(); user.setUsername("testuser"); user.setFirstName("Test"); user.setLastName("User"); user.setCredentials(Arrays.asList(credential)); user.setEnabled(true); Response result = kc.realm("rest-example").users().create(user); I have setted on code false for temporary credential and user as enabled, even so, I can not do login on my application using the created user without do the procedures that I wrote at the beginning of this issue. I think that REST API is not respecting the properties of temporary credential setted to false and user setted as enabled. It can be a BUG? If anybody knows how can I update the credentials from a new user created via REST API leaving it able to do login on my application please let me know. Regards, Maur?cio. _______________________________________________ keycloak-dev mailing list keycloak-dev at lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160929/656e8736/attachment.html From ngothanhnghi at gmail.com Thu Sep 29 21:48:16 2016 From: ngothanhnghi at gmail.com (Ngo Thanh Nghi) Date: Fri, 30 Sep 2016 09:48:16 +0800 Subject: [keycloak-dev] org.jvnet.libpam.UnixUserTest on Windows Message-ID: UnixUserTest will fail on Windows. Could we remove or update this test to work in Windows environment? Ngo -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160930/54c0f275/attachment-0001.html From sthorger at redhat.com Fri Sep 30 02:07:03 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Fri, 30 Sep 2016 08:07:03 +0200 Subject: [keycloak-dev] Testing zip attachment blocked Message-ID: Testing zip attachment blocked -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160930/c19c1c13/attachment.html -------------- next part -------------- A non-text attachment was scrubbed... Name: test.zip Type: application/zip Size: 163 bytes Desc: not available Url : http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160930/c19c1c13/attachment.zip From sthorger at redhat.com Fri Sep 30 02:10:21 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Fri, 30 Sep 2016 08:10:21 +0200 Subject: [keycloak-dev] Testing zip attachment blocked #take2 Message-ID: From sthorger at redhat.com Fri Sep 30 02:29:06 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Fri, 30 Sep 2016 08:29:06 +0200 Subject: [keycloak-dev] org.jvnet.libpam.UnixUserTest on Windows In-Reply-To: References: Message-ID: Create a JIRA please On 30 September 2016 at 03:48, Ngo Thanh Nghi wrote: > UnixUserTest will fail on Windows. Could we remove or update this test to > work in Windows environment? > > Ngo > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > From mposolda at redhat.com Fri Sep 30 02:34:08 2016 From: mposolda at redhat.com (Marek Posolda) Date: Fri, 30 Sep 2016 08:34:08 +0200 Subject: [keycloak-dev] Allow adapter subsystem to just inject dependencies In-Reply-To: References: <8b0a0f73-823e-1d17-5e39-b4316eab30ef@redhat.com> Message-ID: <1f111b70-1092-03ed-6ec7-d2856663f690@redhat.com> On 29/09/16 10:09, Stian Thorgersen wrote: > Oki, so sounds like what you proposed is the way to go. I'm not to > keen on option 2 or 3 as they seem a bit artificial. Why do they not > need auth-server-url though? Ok, I've created https://issues.jboss.org/browse/KEYCLOAK-3634 . The auth-server-url is needed, but this is provided by the JAAS login module configuration. Hawtio itself just relies on the JAAS. It doesn't have servlet security or any security-constraints in web.xml, so doesn't rely on classic servlet adapter. Marek > > On 29 September 2016 at 08:18, Marek Posolda > wrote: > > On 28/09/16 10:58, Stian Thorgersen wrote: >> Not sure even using "" makes sense at all >> in this case. If there's keycloak.json the subsystem still >> injects the dependencies, but doesn't do any configuration. Why >> can't it just rely on that? > Without "secure-deployment", you also need the KEYCLOAK in > login-config in web.xml in addition to keycloak.json. > > Anyway, regarding usability, I suspect it's not an option to > require people to crack inside hawtio.war and change the things in > the WAR directly? Otherwise they can just add > jboss-deployment-structure.xml into the hawtio.war and I don't > need to care about subsystem at all. > > Marek > > > >> >> On 26 September 2016 at 16:39, Marek Posolda > > wrote: >> >> I've did some testing with hawtio on EAP 7. It works fine, >> however there >> is one thing in our subsystem, which may improve integration >> a bit. >> >> Hawtio doesn't use servlet security ( security-constraints in >> web.xml ) >> but they rely on JAAS, which is needed for JMX calls to be >> performed on >> behalf of JAAS Subject. Hawtio WAR needs to have access to >> keycloak-adapter classes (as it needs login modules for >> JAAS), however >> it doesn't need subsystem to configure adapter. This is all >> handled by >> JAAS login module. >> >> In other words, it will be nice if subsystem can just inject >> dependencies ( KeycloakDependencyProcessor ), but ignore adding >> subsystem configuration ( >> KeycloakAdapterConfigDeploymentProcessor ). >> >> The workaround I used was to add secure-deployment section to >> standalone.xml with some dummy values, which are mandatory for >> subsystem. It works, but it's really not too pretty IMO. >> Something like: >> >> >> does-not-matter >> does-not-matter >> >> >> What will be nice is to have some of those possibilities: >> >> 1) Have subsystem to use some default values like "undefined" >> instead of >> null . This is more a workaround as subsystem will still >> process the >> KeycloakAdapterConfigDeploymentProcessor. However it's less >> work and it >> will improve usability, so this will work just fine: >> >> >> >> >> 2) Tell the subsystem to ignore >> KeycloakAdapterConfigDeploymentProcessor. Looks like more >> work, but >> seems to be more proper solution than (1). I can think of: >> >> 2.a) some flag like: >> >> > ignore-deployment-config="true" /> >> >> 2.b) Use different element like "deployment" instead of >> "secure-deployment" . The "deployment" will inject >> dependencies, but >> won't handle adapter configuration. So something like this >> will work: >> >> >> >> >> WDYT? >> Marek >> >> >> >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev at lists.jboss.org >> >> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> >> >> > > From mposolda at redhat.com Fri Sep 30 02:42:09 2016 From: mposolda at redhat.com (Marek Posolda) Date: Fri, 30 Sep 2016 08:42:09 +0200 Subject: [keycloak-dev] Move documentation to a single book/repository In-Reply-To: References: Message-ID: <083ff333-32df-d510-5e8c-f08299cea568@redhat.com> +1 TBH I am not too keen to the pattern used by many projects, where docs is spread in multiple different guides. Multiple guides doesn't help with searching and finding the stuff. You always need to think if the target content is in guide X or guide Y, which means that usually you need to try both... Marek On 29/09/16 09:42, Sebastien Blanc wrote: > +1 That is really more convenient ! > > > > On Thu, Sep 29, 2016 at 9:27 AM, Stian Thorgersen > wrote: > > To simplify maintaining and editing the documentation I propose we > move all guides to a single repository and a single book on Gitbook. > > I did a quick check to see it works here: > https://stianst.gitbooks.io/keycloak-documentation/content/index.html > > > Opinions? > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > > > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev From sthorger at redhat.com Fri Sep 30 02:55:15 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Fri, 30 Sep 2016 08:55:15 +0200 Subject: [keycloak-dev] Move documentation to a single book/repository In-Reply-To: <083ff333-32df-d510-5e8c-f08299cea568@redhat.com> References: <083ff333-32df-d510-5e8c-f08299cea568@redhat.com> Message-ID: This was a work-around to be able to have a single repository for all docs. I do agree with you though, it's harder to search and find things when it's in completely different guides. This ends up being a hybrid approach as all bits are still separated into the same groupings, but are available from within the same book so you can search it all. For searching try the excellent (if I can say so myself) http://www.keycloak.org/search.html - one search to search them all :) On 30 September 2016 at 08:42, Marek Posolda wrote: > +1 > > TBH I am not too keen to the pattern used by many projects, where docs is > spread in multiple different guides. Multiple guides doesn't help with > searching and finding the stuff. You always need to think if the target > content is in guide X or guide Y, which means that usually you need to try > both... > > Marek > > > On 29/09/16 09:42, Sebastien Blanc wrote: > > +1 That is really more convenient ! > > > > On Thu, Sep 29, 2016 at 9:27 AM, Stian Thorgersen > wrote: > >> To simplify maintaining and editing the documentation I propose we move >> all guides to a single repository and a single book on Gitbook. >> >> I did a quick check to see it works here: https://stianst.gitbooks >> .io/keycloak-documentation/content/index.html >> >> Opinions? >> >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> > > > > _______________________________________________ > keycloak-dev mailing listkeycloak-dev at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-dev > > > From sthorger at redhat.com Fri Sep 30 02:55:59 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Fri, 30 Sep 2016 08:55:59 +0200 Subject: [keycloak-dev] Allow adapter subsystem to just inject dependencies In-Reply-To: <1f111b70-1092-03ed-6ec7-d2856663f690@redhat.com> References: <8b0a0f73-823e-1d17-5e39-b4316eab30ef@redhat.com> <1f111b70-1092-03ed-6ec7-d2856663f690@redhat.com> Message-ID: Wouldn't it actually be better to have the auth-server-url in standalone.xml than in the JAAS login module configuration? On 30 September 2016 at 08:34, Marek Posolda wrote: > On 29/09/16 10:09, Stian Thorgersen wrote: > > Oki, so sounds like what you proposed is the way to go. I'm not to keen on > option 2 or 3 as they seem a bit artificial. Why do they not need > auth-server-url though? > > Ok, I've created https://issues.jboss.org/browse/KEYCLOAK-3634 . The > auth-server-url is needed, but this is provided by the JAAS login module > configuration. Hawtio itself just relies on the JAAS. It doesn't have > servlet security or any security-constraints in web.xml, so doesn't rely on > classic servlet adapter. > > Marek > > > On 29 September 2016 at 08:18, Marek Posolda wrote: > >> On 28/09/16 10:58, Stian Thorgersen wrote: >> >> Not sure even using "" makes sense at all in this >> case. If there's keycloak.json the subsystem still injects the >> dependencies, but doesn't do any configuration. Why can't it just rely on >> that? >> >> Without "secure-deployment", you also need the KEYCLOAK in login-config >> in web.xml in addition to keycloak.json. >> >> Anyway, regarding usability, I suspect it's not an option to require >> people to crack inside hawtio.war and change the things in the WAR >> directly? Otherwise they can just add jboss-deployment-structure.xml into >> the hawtio.war and I don't need to care about subsystem at all. >> >> Marek >> >> >> >> >> On 26 September 2016 at 16:39, Marek Posolda wrote: >> >>> I've did some testing with hawtio on EAP 7. It works fine, however there >>> is one thing in our subsystem, which may improve integration a bit. >>> >>> Hawtio doesn't use servlet security ( security-constraints in web.xml ) >>> but they rely on JAAS, which is needed for JMX calls to be performed on >>> behalf of JAAS Subject. Hawtio WAR needs to have access to >>> keycloak-adapter classes (as it needs login modules for JAAS), however >>> it doesn't need subsystem to configure adapter. This is all handled by >>> JAAS login module. >>> >>> In other words, it will be nice if subsystem can just inject >>> dependencies ( KeycloakDependencyProcessor ), but ignore adding >>> subsystem configuration ( KeycloakAdapterConfigDeploymentProcessor ). >>> >>> The workaround I used was to add secure-deployment section to >>> standalone.xml with some dummy values, which are mandatory for >>> subsystem. It works, but it's really not too pretty IMO. Something like: >>> >>> >>> does-not-matter >>> does-not-matter >>> >>> >>> What will be nice is to have some of those possibilities: >>> >>> 1) Have subsystem to use some default values like "undefined" instead of >>> null . This is more a workaround as subsystem will still process the >>> KeycloakAdapterConfigDeploymentProcessor. However it's less work and it >>> will improve usability, so this will work just fine: >>> >>> >>> >>> >>> 2) Tell the subsystem to ignore >>> KeycloakAdapterConfigDeploymentProcessor. Looks like more work, but >>> seems to be more proper solution than (1). I can think of: >>> >>> 2.a) some flag like: >>> >>> >>> >>> 2.b) Use different element like "deployment" instead of >>> "secure-deployment" . The "deployment" will inject dependencies, but >>> won't handle adapter configuration. So something like this will work: >>> >>> >>> >>> >>> 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 Fri Sep 30 03:13:51 2016 From: sblanc at redhat.com (Sebastien Blanc) Date: Fri, 30 Sep 2016 09:13:51 +0200 Subject: [keycloak-dev] Possible BUG creating User via REST API In-Reply-To: References: Message-ID: Hard to tell without seeing whole your code but when you create your user you don't have this issue, right ? Do you do the reset in the same "flow" of code ? On Thu, Sep 29, 2016 at 10:36 PM, Maur?cio Giacomini Penteado < mauriciogiacomini at hotmail.com> wrote: > Hi Sebastien, thanks for answering. > > Sorry, my last message was not complete. > > I am trying your code but I always got a "Failed executing GET > /admin/realms/SGCD/users: org.jboss.resteasy.spi.UnauthorizedException: > Bearer" > > I tryed set the Bearer Token using the code that follows (but I do not > have successful): > > ResteasyClient resteasyClient = new ResteasyClientBuilder() > .connectionPoolSize(10).build(); > resteasyClient.target(KEYCLOAK_HOST) > .register(BEARER_TOKEN); > > Keycloak kc = KeycloakBuilder.builder() > .resteasyClient(resteasyClient) > .build(); > > kc.realm("SGCD").users().get(userId).resetPassword(credential); > > Please, you know if Is there some way for I put my bearer token on call > of resetPassword or on build of KeycloakBuilder? > > Regards, > Maur?cio. > > > > ------------------------------ > *De:* Sebastien Blanc > *Enviado:* quinta-feira, 29 de setembro de 2016 14:08 > *Para:* Maur?cio Giacomini Penteado > *Assunto:* Re: [keycloak-dev] Possible BUG creating User via REST API > > Hi Mauricio, > > This is not a bug, you need to reset the password after that the user has > been created, using something like : > > CredentialRepresentation credentials = new CredentialRepresentation(); > credentials.setType(CredentialRepresentation.PASSWORD); > credentials.setValue("password"); > > keycloak.realm("realm").users().get(id).resetPassword(creden > tials); > > > > > On Thu, Sep 29, 2016 at 3:51 PM, Maur?cio Giacomini Penteado < > mauriciogiacomini at hotmail.com> wrote: > >> Hello everybody, >> >> All times that I create an user via REST API I have to do login on >> keycloak using administrator account and have to update the credentials >> from user created via REST API with temporary password setted to false. >> Just if I do these procedures I can do login on my app using the user >> created via REST API. >> >> I am using the follow code to create an user via REST API: >> ..... >> CredentialRepresentation credential = new >> CredentialRepresentation(); >> credential.setType(CredentialRepresentation.PASSWORD); >> credential.setValue("test123"); >> credential.setTemporary(false); >> >> UserRepresentation user = new UserRepresentation(); >> user.setUsername("testuser"); >> user.setFirstName("Test"); >> user.setLastName("User"); >> user.setCredentials(Arrays.asList(credential)); >> user.setEnabled(true); >> >> Response result = kc.realm("rest-example").users().create(user); >> >> I have setted on code false for temporary credential and user as enabled, >> even so, I can not do login on my application using the created user >> without do the procedures that I wrote at the beginning of this issue. >> >> I think that REST API is not respecting the properties of temporary >> credential setted to false and user setted as enabled. It can be a BUG? >> >> If anybody knows how can I update the credentials from a new user created >> via REST API leaving it able to do login on my application please let me >> know. >> >> Regards, >> Maur?cio. >> >> >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> > > From e.berdoncesbonelo at campus.tu-berlin.de Fri Sep 30 03:32:38 2016 From: e.berdoncesbonelo at campus.tu-berlin.de (Berdonces Bonelo, Erik) Date: Fri, 30 Sep 2016 07:32:38 +0000 Subject: [keycloak-dev] Bug in User Roles inherited from Groups In-Reply-To: References: , Message-ID: <1475220696202.51461@campus.tu-berlin.de> ?Hi, Yes, mostly that is what I'm doing. However, I can see all the groups exposed using the Group Mapper. And I see that the user is in that specific group. ________________________________ From: Stian Thorgersen Sent: Thursday, September 29, 2016 10:06 AM To: Stian Thorgersen Cc: Berdonces Bonelo, Erik; keycloak-dev Subject: Re: [keycloak-dev] Bug in User Roles inherited from Groups Bad wording. I didn't mean "custom" mapper, I meant you add a user realm role mapper to assign the specific role to a separate field on the token. On 29 September 2016 at 10:06, Stian Thorgersen > wrote: So you're using a custom mapper to expose the role rather than relying on the roles? Sounds like the bug is that the custom mapper doesn't see the roles inherited from the group. On 27 September 2016 at 17:22, Erik Berdonces Bonelo > wrote: Hello, I'm mailing here as I found a bug, but I'm not sure if it's an expected result. According to the documentation (https://keycloak.gitbooks.io/server-adminstration-guide/content/topics/groups.html) Groups in Keycloak allow you to manage a common set of attributes and role mappings for a set of users. Users can be members of zero or more groups. Users inherit the attributes and role mappings assigned to each group. Then, I assume that if I assign a role to a group, and it appears in the 'Effective Roles' tab of the group, any user inside of the group will inherit the roles. The problem: I've been testing with a simple OpenID Connect client in confidential mode, and the user doesn't have any of this roles (I exposed Role as a mapper using User Realm Role mapper) and fetched the roles using an OIDC client. However, if I assign the roles directly to the user, the roles are returned as expected, in the User Info endpoint. Is it possible that there is a bug in the group system that is not giving the proper roles to the underneath users? Thanks a lot for your time, and have a nice week! - Best Regards, Erik Berdonces Bonelo _______________________________________________ keycloak-dev mailing list keycloak-dev at lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-dev From sthorger at redhat.com Fri Sep 30 03:55:22 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Fri, 30 Sep 2016 09:55:22 +0200 Subject: [keycloak-dev] Bug in User Roles inherited from Groups In-Reply-To: <1475220696202.51461@campus.tu-berlin.de> References: <1475220696202.51461@campus.tu-berlin.de> Message-ID: Just checked and I'm seeing the same behavior. Role is added to realm_access.roles, but not to the custom claim. Please create a JIRA bug for this. On 30 September 2016 at 09:32, Berdonces Bonelo, Erik < e.berdoncesbonelo at campus.tu-berlin.de> wrote: > ?Hi, > > > Yes, mostly that is what I'm doing. However, I can see all the groups > exposed using the Group Mapper. And I see that the user is in that specific > group. > ------------------------------ > *From:* Stian Thorgersen > *Sent:* Thursday, September 29, 2016 10:06 AM > *To:* Stian Thorgersen > *Cc:* Berdonces Bonelo, Erik; keycloak-dev > *Subject:* Re: [keycloak-dev] Bug in User Roles inherited from Groups > > Bad wording. I didn't mean "custom" mapper, I meant you add a user realm > role mapper to assign the specific role to a separate field on the token. > > On 29 September 2016 at 10:06, Stian Thorgersen > wrote: > >> So you're using a custom mapper to expose the role rather than relying on >> the roles? Sounds like the bug is that the custom mapper doesn't see the >> roles inherited from the group. >> >> On 27 September 2016 at 17:22, Erik Berdonces Bonelo < >> e.berdoncesbonelo at campus.tu-berlin.de> wrote: >> >>> Hello, >>> >>> I?m mailing here as I found a bug, but I?m not sure if it?s an expected >>> result. >>> >>> According to the documentation (https://keycloak.gitbooks.io/ >>> server-adminstration-guide/content/topics/groups.html) >>> >>> Groups in Keycloak allow you to manage a common set of attributes and >>> role mappings for a set of users. Users can be members of zero or more >>> groups. *Users inherit the attributes and role mappings assigned to >>> each group*. >>> >>> Then, I assume that if I assign a role to a group, and it appears in the >>> ?Effective Roles? tab of the group, any user inside of the group will >>> inherit the roles. >>> >>> The problem: I?ve been testing with a simple OpenID Connect client in >>> confidential mode, and the user doesn?t have any of this roles (I exposed >>> Role as a mapper using User Realm Role mapper) and fetched the roles using >>> an OIDC client. >>> >>> However, if I assign the roles directly to the user, the roles are >>> returned as expected, in the User Info endpoint. >>> >>> Is it possible that there is a bug in the group system that is not >>> giving the proper roles to the underneath users? >>> >>> Thanks a lot for your time, and have a nice week! >>> >>> ? >>> Best Regards, >>> >>> Erik Berdonces Bonelo >>> >>> _______________________________________________ >>> keycloak-dev mailing list >>> keycloak-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>> >> >> > From mposolda at redhat.com Fri Sep 30 04:35:13 2016 From: mposolda at redhat.com (Marek Posolda) Date: Fri, 30 Sep 2016 10:35:13 +0200 Subject: [keycloak-dev] Allow adapter subsystem to just inject dependencies In-Reply-To: References: <8b0a0f73-823e-1d17-5e39-b4316eab30ef@redhat.com> <1f111b70-1092-03ed-6ec7-d2856663f690@redhat.com> Message-ID: <81cc6490-0faf-8a66-fbe9-10406bbe057d@redhat.com> On 30/09/16 08:55, Stian Thorgersen wrote: > Wouldn't it actually be better to have the auth-server-url in > standalone.xml than in the JAAS login module configuration? Hawtio relies on JAAS and I can't see any nice way how to pass the stuff from our subsystem to the JAAS login module. Also I suppose we don't want to introduce any keycloak dependencies in hawtio as that would mean other complications... Our adapter subsystem puts the stuff into the JSON string, which is saved as servletContext attribute. So what can work is, that hawtio can read it from the servletContext and save it to some threadLocal. Then on hawtio side, there will be login module, which will read the JSON from threadLocal and put it to JAAS sharedState. The Keycloak login module, which will be next in the JAAS chain, can then try to see if there is stuff in sharedState and if yes, then use it instead of the KeycloakDeployment provided by it's JAAS config. Or another possibility that class holding threadLocal will be in Keycloak codebase and hawtio will use reflection to put the JSON into it (as we don't want keycloak dependencies in hawtio directly). Both approaches looks to me complicated and introducing dependencies on keycloak subsystem implementation details into hawtio codebase (reading the servletContext attribute etc). Also it will be useful just with hawtio on EAP, but not for Hawtio on Fuse. And Fuse seems to be much more important. Marek > > On 30 September 2016 at 08:34, Marek Posolda > wrote: > > On 29/09/16 10:09, Stian Thorgersen wrote: >> Oki, so sounds like what you proposed is the way to go. I'm not >> to keen on option 2 or 3 as they seem a bit artificial. Why do >> they not need auth-server-url though? > Ok, I've created https://issues.jboss.org/browse/KEYCLOAK-3634 > . The > auth-server-url is needed, but this is provided by the JAAS login > module configuration. Hawtio itself just relies on the JAAS. It > doesn't have servlet security or any security-constraints in > web.xml, so doesn't rely on classic servlet adapter. > > Marek > >> >> On 29 September 2016 at 08:18, Marek Posolda > > wrote: >> >> On 28/09/16 10:58, Stian Thorgersen wrote: >>> Not sure even using "" makes sense at >>> all in this case. If there's keycloak.json the subsystem >>> still injects the dependencies, but doesn't do any >>> configuration. Why can't it just rely on that? >> Without "secure-deployment", you also need the KEYCLOAK in >> login-config in web.xml in addition to keycloak.json. >> >> Anyway, regarding usability, I suspect it's not an option to >> require people to crack inside hawtio.war and change the >> things in the WAR directly? Otherwise they can just add >> jboss-deployment-structure.xml into the hawtio.war and I >> don't need to care about subsystem at all. >> >> Marek >> >> >> >>> >>> On 26 September 2016 at 16:39, Marek Posolda >>> > wrote: >>> >>> I've did some testing with hawtio on EAP 7. It works >>> fine, however there >>> is one thing in our subsystem, which may improve >>> integration a bit. >>> >>> Hawtio doesn't use servlet security ( >>> security-constraints in web.xml ) >>> but they rely on JAAS, which is needed for JMX calls to >>> be performed on >>> behalf of JAAS Subject. Hawtio WAR needs to have access to >>> keycloak-adapter classes (as it needs login modules for >>> JAAS), however >>> it doesn't need subsystem to configure adapter. This is >>> all handled by >>> JAAS login module. >>> >>> In other words, it will be nice if subsystem can just inject >>> dependencies ( KeycloakDependencyProcessor ), but ignore >>> adding >>> subsystem configuration ( >>> KeycloakAdapterConfigDeploymentProcessor ). >>> >>> The workaround I used was to add secure-deployment >>> section to >>> standalone.xml with some dummy values, which are >>> mandatory for >>> subsystem. It works, but it's really not too pretty IMO. >>> Something like: >>> >>> >>> does-not-matter >>> does-not-matter >>> >>> >>> What will be nice is to have some of those possibilities: >>> >>> 1) Have subsystem to use some default values like >>> "undefined" instead of >>> null . This is more a workaround as subsystem will still >>> process the >>> KeycloakAdapterConfigDeploymentProcessor. However it's >>> less work and it >>> will improve usability, so this will work just fine: >>> >>> >>> >>> >>> 2) Tell the subsystem to ignore >>> KeycloakAdapterConfigDeploymentProcessor. Looks like >>> more work, but >>> seems to be more proper solution than (1). I can think of: >>> >>> 2.a) some flag like: >>> >>> >> ignore-deployment-config="true" /> >>> >>> 2.b) Use different element like "deployment" instead of >>> "secure-deployment" . The "deployment" will inject >>> dependencies, but >>> won't handle adapter configuration. So something like >>> this will work: >>> >>> >>> >>> >>> WDYT? >>> Marek >>> >>> >>> >>> _______________________________________________ >>> keycloak-dev mailing list >>> keycloak-dev at lists.jboss.org >>> >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>> >>> >>> >> >> > > From thomas.darimont at googlemail.com Fri Sep 30 04:56:46 2016 From: thomas.darimont at googlemail.com (Thomas Darimont) Date: Fri, 30 Sep 2016 10:56:46 +0200 Subject: [keycloak-dev] Script based ProtocolMappers Message-ID: Hi folks, I was thinking about leveraging the new scripting support for ProtocolMappers. Issue is here: Script based ProtocolMapper https://issues.jboss.org/browse/KEYCLOAK-3599 Would look similar to script based authenticators but would come with a different quickstart template. For reference current script authenticator template is: scripts/authenticator-template.js in keycloak-services What do you think? Cheers, Thomas From sthorger at redhat.com Fri Sep 30 04:59:35 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Fri, 30 Sep 2016 10:59:35 +0200 Subject: [keycloak-dev] Debug/trace logging in services broken Message-ID: A lot of debug/trace logging goes directly to org.keycloak.services. This is completely broken as it's impossible to filter and it's not possible to enable debug/trace for specific parts. Added: https://issues.jboss.org/browse/KEYCLOAK-3635 Generic info and error statements can use org.keycloak.services, but debug/trace should use the logger for the class. Classes should just have a regular JBoss Logger. For generic info/error statements they should just use: ServicesLogger.ROOT_LOGGER.???(???) Comments? From sthorger at redhat.com Fri Sep 30 05:00:04 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Fri, 30 Sep 2016 11:00:04 +0200 Subject: [keycloak-dev] Script based ProtocolMappers In-Reply-To: References: Message-ID: Sounds good to me On 30 September 2016 at 10:56, Thomas Darimont < thomas.darimont at googlemail.com> wrote: > Hi folks, > > I was thinking about leveraging the new scripting support for > ProtocolMappers. > > Issue is here: Script based ProtocolMapper > https://issues.jboss.org/browse/KEYCLOAK-3599 > > Would look similar to script based authenticators but would come with a > different quickstart template. > For reference current script authenticator template is: > scripts/authenticator-template.js in keycloak-services > > What do you think? > > Cheers, > 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 Sep 30 05:25:25 2016 From: mposolda at redhat.com (Marek Posolda) Date: Fri, 30 Sep 2016 11:25:25 +0200 Subject: [keycloak-dev] Debug/trace logging in services broken In-Reply-To: References: Message-ID: +1 Marek On 30/09/16 10:59, Stian Thorgersen wrote: > A lot of debug/trace logging goes directly to org.keycloak.services. This > is completely broken as it's impossible to filter and it's not possible to > enable debug/trace for specific parts. > > Added: > https://issues.jboss.org/browse/KEYCLOAK-3635 > > Generic info and error statements can use org.keycloak.services, but > debug/trace should use the logger for the class. > > Classes should just have a regular JBoss Logger. For generic info/error > statements they should just use: > > ServicesLogger.ROOT_LOGGER.???(???) > > Comments? > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev From valerij.timofeev at gmail.com Fri Sep 30 05:33:37 2016 From: valerij.timofeev at gmail.com (Valerij Timofeev) Date: Fri, 30 Sep 2016 11:33:37 +0200 Subject: [keycloak-dev] Move documentation to a single book/repository (Stian Thorgersen) Message-ID: It's a very good idea for using the documentation as well. Sometimes it is necessary to search almost all seven sources of documentation for some topics. Date: Thu, 29 Sep 2016 09:27:29 +0200 > From: Stian Thorgersen > Subject: [keycloak-dev] Move documentation to a single book/repository > To: keycloak-dev > > > To simplify maintaining and editing the documentation I propose we move all > guides to a single repository and a single book on Gitbook. > > I did a quick check to see it works here: > https://stianst.gitbooks.io/keycloak-documentation/content/index.html > > Opinions? > From bruno at abstractj.org Fri Sep 30 06:46:07 2016 From: bruno at abstractj.org (Bruno Oliveira) Date: Fri, 30 Sep 2016 07:46:07 -0300 Subject: [keycloak-dev] Move documentation to a single book/repository (Stian Thorgersen) In-Reply-To: References: Message-ID: <20160930104607.GA7450@abstractj.org> +1 Make the search easy. On 2016-09-30, Valerij Timofeev wrote: > It's a very good idea for using the documentation as well. Sometimes it is > necessary to search almost all seven sources of documentation for some > topics. > > > Date: Thu, 29 Sep 2016 09:27:29 +0200 > > From: Stian Thorgersen > > Subject: [keycloak-dev] Move documentation to a single book/repository > > To: keycloak-dev > > > > > > To simplify maintaining and editing the documentation I propose we move all > > guides to a single repository and a single book on Gitbook. > > > > I did a quick check to see it works here: > > https://stianst.gitbooks.io/keycloak-documentation/content/index.html > > > > Opinions? > > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev -- abstractj PGP: 0x84DC9914 From bruno at abstractj.org Fri Sep 30 06:49:27 2016 From: bruno at abstractj.org (Bruno Oliveira) Date: Fri, 30 Sep 2016 07:49:27 -0300 Subject: [keycloak-dev] Debug/trace logging in services broken In-Reply-To: References: Message-ID: <20160930104927.GB7450@abstractj.org> +1 On 2016-09-30, Marek Posolda wrote: > +1 > > Marek > > On 30/09/16 10:59, Stian Thorgersen wrote: > > A lot of debug/trace logging goes directly to org.keycloak.services. This > > is completely broken as it's impossible to filter and it's not possible to > > enable debug/trace for specific parts. > > > > Added: > > https://issues.jboss.org/browse/KEYCLOAK-3635 > > > > Generic info and error statements can use org.keycloak.services, but > > debug/trace should use the logger for the class. > > > > Classes should just have a regular JBoss Logger. For generic info/error > > statements they should just use: > > > > ServicesLogger.ROOT_LOGGER.???(???) > > > > 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 -- abstractj PGP: 0x84DC9914 From sthorger at redhat.com Fri Sep 30 06:58:01 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Fri, 30 Sep 2016 12:58:01 +0200 Subject: [keycloak-dev] Allow adapter subsystem to just inject dependencies In-Reply-To: <81cc6490-0faf-8a66-fbe9-10406bbe057d@redhat.com> References: <8b0a0f73-823e-1d17-5e39-b4316eab30ef@redhat.com> <1f111b70-1092-03ed-6ec7-d2856663f690@redhat.com> <81cc6490-0faf-8a66-fbe9-10406bbe057d@redhat.com> Message-ID: What's the use-case for hawtio on EAP if not for Fuse? With Hawtio on EAP you need to change some settings in the war to add our login module right? So not sure why it would be an issue to add jboss-deployment-structure.xml at the same time? On 30 September 2016 at 10:35, Marek Posolda wrote: > On 30/09/16 08:55, Stian Thorgersen wrote: > > Wouldn't it actually be better to have the auth-server-url in > standalone.xml than in the JAAS login module configuration? > > Hawtio relies on JAAS and I can't see any nice way how to pass the stuff > from our subsystem to the JAAS login module. Also I suppose we don't want > to introduce any keycloak dependencies in hawtio as that would mean other > complications... > > Our adapter subsystem puts the stuff into the JSON string, which is saved > as servletContext attribute. So what can work is, that hawtio can read it > from the servletContext and save it to some threadLocal. Then on hawtio > side, there will be login module, which will read the JSON from threadLocal > and put it to JAAS sharedState. The Keycloak login module, which will be > next in the JAAS chain, can then try to see if there is stuff in > sharedState and if yes, then use it instead of the KeycloakDeployment > provided by it's JAAS config. Or another possibility that class holding > threadLocal will be in Keycloak codebase and hawtio will use reflection to > put the JSON into it (as we don't want keycloak dependencies in hawtio > directly). > > Both approaches looks to me complicated and introducing dependencies on > keycloak subsystem implementation details into hawtio codebase (reading the > servletContext attribute etc). Also it will be useful just with hawtio on > EAP, but not for Hawtio on Fuse. And Fuse seems to be much more important. > > Marek > > > On 30 September 2016 at 08:34, Marek Posolda wrote: > >> On 29/09/16 10:09, Stian Thorgersen wrote: >> >> Oki, so sounds like what you proposed is the way to go. I'm not to keen >> on option 2 or 3 as they seem a bit artificial. Why do they not need >> auth-server-url though? >> >> Ok, I've created https://issues.jboss.org/browse/KEYCLOAK-3634 . The >> auth-server-url is needed, but this is provided by the JAAS login module >> configuration. Hawtio itself just relies on the JAAS. It doesn't have >> servlet security or any security-constraints in web.xml, so doesn't rely on >> classic servlet adapter. >> >> Marek >> >> >> On 29 September 2016 at 08:18, Marek Posolda wrote: >> >>> On 28/09/16 10:58, Stian Thorgersen wrote: >>> >>> Not sure even using "" makes sense at all in this >>> case. If there's keycloak.json the subsystem still injects the >>> dependencies, but doesn't do any configuration. Why can't it just rely on >>> that? >>> >>> Without "secure-deployment", you also need the KEYCLOAK in login-config >>> in web.xml in addition to keycloak.json. >>> >>> Anyway, regarding usability, I suspect it's not an option to require >>> people to crack inside hawtio.war and change the things in the WAR >>> directly? Otherwise they can just add jboss-deployment-structure.xml into >>> the hawtio.war and I don't need to care about subsystem at all. >>> >>> Marek >>> >>> >>> >>> >>> On 26 September 2016 at 16:39, Marek Posolda >>> wrote: >>> >>>> I've did some testing with hawtio on EAP 7. It works fine, however there >>>> is one thing in our subsystem, which may improve integration a bit. >>>> >>>> Hawtio doesn't use servlet security ( security-constraints in web.xml ) >>>> but they rely on JAAS, which is needed for JMX calls to be performed on >>>> behalf of JAAS Subject. Hawtio WAR needs to have access to >>>> keycloak-adapter classes (as it needs login modules for JAAS), however >>>> it doesn't need subsystem to configure adapter. This is all handled by >>>> JAAS login module. >>>> >>>> In other words, it will be nice if subsystem can just inject >>>> dependencies ( KeycloakDependencyProcessor ), but ignore adding >>>> subsystem configuration ( KeycloakAdapterConfigDeploymentProcessor ). >>>> >>>> The workaround I used was to add secure-deployment section to >>>> standalone.xml with some dummy values, which are mandatory for >>>> subsystem. It works, but it's really not too pretty IMO. Something like: >>>> >>>> >>>> does-not-matter >>>> does-not-matter >>>> >>>> >>>> What will be nice is to have some of those possibilities: >>>> >>>> 1) Have subsystem to use some default values like "undefined" instead of >>>> null . This is more a workaround as subsystem will still process the >>>> KeycloakAdapterConfigDeploymentProcessor. However it's less work and it >>>> will improve usability, so this will work just fine: >>>> >>>> >>>> >>>> >>>> 2) Tell the subsystem to ignore >>>> KeycloakAdapterConfigDeploymentProcessor. Looks like more work, but >>>> seems to be more proper solution than (1). I can think of: >>>> >>>> 2.a) some flag like: >>>> >>>> >>>> >>>> 2.b) Use different element like "deployment" instead of >>>> "secure-deployment" . The "deployment" will inject dependencies, but >>>> won't handle adapter configuration. So something like this will work: >>>> >>>> >>>> >>>> >>>> WDYT? >>>> Marek >>>> >>>> >>>> >>>> _______________________________________________ >>>> keycloak-dev mailing list >>>> keycloak-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>>> >>> >>> >>> >> >> > > From bruno at abstractj.org Fri Sep 30 07:03:24 2016 From: bruno at abstractj.org (Bruno Oliveira) Date: Fri, 30 Sep 2016 08:03:24 -0300 Subject: [keycloak-dev] org.jvnet.libpam.UnixUserTest on Windows In-Reply-To: References: Message-ID: <20160930110324.GC7450@abstractj.org> Created: https://issues.jboss.org/browse/KEYCLOAK-3638 On 2016-09-30, Stian Thorgersen wrote: > Create a JIRA please > > On 30 September 2016 at 03:48, Ngo Thanh Nghi > wrote: > > > UnixUserTest will fail on Windows. Could we remove or update this test to > > work in Windows environment? > > > > Ngo > > > > _______________________________________________ > > keycloak-dev mailing list > > keycloak-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev -- abstractj PGP: 0x84DC9914 From martin.hardselius at gmail.com Fri Sep 30 08:07:01 2016 From: martin.hardselius at gmail.com (Martin Hardselius) Date: Fri, 30 Sep 2016 12:07:01 +0000 Subject: [keycloak-dev] Configurable cookie names Message-ID: What are your thoughts on configurable cookie names (or other visible references to Keycloak)? I.e a way to override e.g "KEYCLOAK_SESSION" with "MYCOMPANY_SESSION". The use case being 1. Product branding 2. Making it harder to figure out exactly which technology that's used behind the scenes Regards, Martin From ssilvert at redhat.com Fri Sep 30 08:17:35 2016 From: ssilvert at redhat.com (Stan Silvert) Date: Fri, 30 Sep 2016 08:17:35 -0400 Subject: [keycloak-dev] Move documentation to a single book/repository In-Reply-To: <083ff333-32df-d510-5e8c-f08299cea568@redhat.com> References: <083ff333-32df-d510-5e8c-f08299cea568@redhat.com> Message-ID: <57EE57DF.3040401@redhat.com> +1 On 9/30/2016 2:42 AM, Marek Posolda wrote: > +1 > > TBH I am not too keen to the pattern used by many projects, where docs > is spread in multiple different guides. Multiple guides doesn't help > with searching and finding the stuff. You always need to think if the > target content is in guide X or guide Y, which means that usually you > need to try both... > > Marek > > On 29/09/16 09:42, Sebastien Blanc wrote: >> +1 That is really more convenient ! >> >> >> >> On Thu, Sep 29, 2016 at 9:27 AM, Stian Thorgersen > > wrote: >> >> To simplify maintaining and editing the documentation I propose we >> move all guides to a single repository and a single book on Gitbook. >> >> I did a quick check to see it works here: >> https://stianst.gitbooks.io/keycloak-documentation/content/index.html >> >> >> Opinions? >> >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> >> >> >> >> >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev From ssilvert at redhat.com Fri Sep 30 09:46:13 2016 From: ssilvert at redhat.com (Stan Silvert) Date: Fri, 30 Sep 2016 09:46:13 -0400 Subject: [keycloak-dev] Browser Javascript Support Message-ID: <57EE6CA5.8090407@redhat.com> What is our statement about browser support? For admin console, are we stating that we support any browser that supports ES5? http://kangax.github.io/compat-table/es5/ Do we have separate standards for things like the login screen and Account Management? Stan From mposolda at redhat.com Fri Sep 30 10:24:00 2016 From: mposolda at redhat.com (Marek Posolda) Date: Fri, 30 Sep 2016 16:24:00 +0200 Subject: [keycloak-dev] Allow adapter subsystem to just inject dependencies In-Reply-To: References: <8b0a0f73-823e-1d17-5e39-b4316eab30ef@redhat.com> <1f111b70-1092-03ed-6ec7-d2856663f690@redhat.com> <81cc6490-0faf-8a66-fbe9-10406bbe057d@redhat.com> Message-ID: <6eb9e340-6a7c-4d2b-12e8-f9ffe59838d2@redhat.com> On 30/09/16 12:58, Stian Thorgersen wrote: > What's the use-case for hawtio on EAP if not for Fuse? By Hawtio on Fuse, I meant Hawtio deployed on JBoss Fuse ( karaf + jetty). Where Hawtio on EAP is just hawtio war deployed on EAP. AFAIK both usecases (Hawtio on JBoss Fuse and Hawtio on EAP) is what we want to support for "Fuse adapter" ? > With Hawtio on EAP you need to change some settings in the war to add > our login module right? So not sure why it would be an issue to add > jboss-deployment-structure.xml at the same time? Nope, I don't change anything inside the WAR. And I want to keep it like that. I suppose that require people to change stuff directly inside the hawtio.war is not something we want to do? Otherwise I would just add jboss-deployment-structure.xml and I wouldn't start this thread :-) The JAAS configuration is in standalone.xml and hawtio is able to read it. It's just not able to find the keycloak classes. So really the only thing I need is a way for hawtio to find the classes. So a way for our subsystem to just add dependencies, but not add the deployment configuration (as I don't need it). Marek > On 30 September 2016 at 10:35, Marek Posolda > wrote: > > On 30/09/16 08:55, Stian Thorgersen wrote: >> Wouldn't it actually be better to have the auth-server-url in >> standalone.xml than in the JAAS login module configuration? > Hawtio relies on JAAS and I can't see any nice way how to pass the > stuff from our subsystem to the JAAS login module. Also I suppose > we don't want to introduce any keycloak dependencies in hawtio as > that would mean other complications... > > Our adapter subsystem puts the stuff into the JSON string, which > is saved as servletContext attribute. So what can work is, that > hawtio can read it from the servletContext and save it to some > threadLocal. Then on hawtio side, there will be login module, > which will read the JSON from threadLocal and put it to JAAS > sharedState. The Keycloak login module, which will be next in the > JAAS chain, can then try to see if there is stuff in sharedState > and if yes, then use it instead of the KeycloakDeployment provided > by it's JAAS config. Or another possibility that class holding > threadLocal will be in Keycloak codebase and hawtio will use > reflection to put the JSON into it (as we don't want keycloak > dependencies in hawtio directly). > > Both approaches looks to me complicated and introducing > dependencies on keycloak subsystem implementation details into > hawtio codebase (reading the servletContext attribute etc). Also > it will be useful just with hawtio on EAP, but not for Hawtio on > Fuse. And Fuse seems to be much more important. > > Marek > >> >> On 30 September 2016 at 08:34, Marek Posolda > > wrote: >> >> On 29/09/16 10:09, Stian Thorgersen wrote: >>> Oki, so sounds like what you proposed is the way to go. I'm >>> not to keen on option 2 or 3 as they seem a bit artificial. >>> Why do they not need auth-server-url though? >> Ok, I've created >> https://issues.jboss.org/browse/KEYCLOAK-3634 >> . The >> auth-server-url is needed, but this is provided by the JAAS >> login module configuration. Hawtio itself just relies on the >> JAAS. It doesn't have servlet security or any >> security-constraints in web.xml, so doesn't rely on classic >> servlet adapter. >> >> Marek >> >>> >>> On 29 September 2016 at 08:18, Marek Posolda >>> > wrote: >>> >>> On 28/09/16 10:58, Stian Thorgersen wrote: >>>> Not sure even using "" makes >>>> sense at all in this case. If there's keycloak.json >>>> the subsystem still injects the dependencies, but >>>> doesn't do any configuration. Why can't it just rely on >>>> that? >>> Without "secure-deployment", you also need the KEYCLOAK >>> in login-config in web.xml in addition to keycloak.json. >>> >>> Anyway, regarding usability, I suspect it's not an >>> option to require people to crack inside hawtio.war and >>> change the things in the WAR directly? Otherwise they >>> can just add jboss-deployment-structure.xml into the >>> hawtio.war and I don't need to care about subsystem at all. >>> >>> Marek >>> >>> >>> >>>> >>>> On 26 September 2016 at 16:39, Marek Posolda >>>> > wrote: >>>> >>>> I've did some testing with hawtio on EAP 7. It >>>> works fine, however there >>>> is one thing in our subsystem, which may improve >>>> integration a bit. >>>> >>>> Hawtio doesn't use servlet security ( >>>> security-constraints in web.xml ) >>>> but they rely on JAAS, which is needed for JMX >>>> calls to be performed on >>>> behalf of JAAS Subject. Hawtio WAR needs to have >>>> access to >>>> keycloak-adapter classes (as it needs login modules >>>> for JAAS), however >>>> it doesn't need subsystem to configure adapter. >>>> This is all handled by >>>> JAAS login module. >>>> >>>> In other words, it will be nice if subsystem can >>>> just inject >>>> dependencies ( KeycloakDependencyProcessor ), but >>>> ignore adding >>>> subsystem configuration ( >>>> KeycloakAdapterConfigDeploymentProcessor ). >>>> >>>> The workaround I used was to add secure-deployment >>>> section to >>>> standalone.xml with some dummy values, which are >>>> mandatory for >>>> subsystem. It works, but it's really not too pretty >>>> IMO. Something like: >>>> >>>> >>>> does-not-matter >>>> does-not-matter >>>> >>>> >>>> What will be nice is to have some of those >>>> possibilities: >>>> >>>> 1) Have subsystem to use some default values like >>>> "undefined" instead of >>>> null . This is more a workaround as subsystem will >>>> still process the >>>> KeycloakAdapterConfigDeploymentProcessor. However >>>> it's less work and it >>>> will improve usability, so this will work just fine: >>>> >>>> >>>> >>>> >>>> 2) Tell the subsystem to ignore >>>> KeycloakAdapterConfigDeploymentProcessor. Looks >>>> like more work, but >>>> seems to be more proper solution than (1). I can >>>> think of: >>>> >>>> 2.a) some flag like: >>>> >>>> >>> ignore-deployment-config="true" /> >>>> >>>> 2.b) Use different element like "deployment" instead of >>>> "secure-deployment" . The "deployment" will inject >>>> dependencies, but >>>> won't handle adapter configuration. So something >>>> like this will work: >>>> >>>> >>>> >>>> >>>> WDYT? >>>> Marek >>>> >>>> >>>> >>>> _______________________________________________ >>>> keycloak-dev mailing list >>>> keycloak-dev at lists.jboss.org >>>> >>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>>> >>>> >>>> >>> >>> >> >> > >