From Frank.French at causeway.com Sun Nov 2 17:10:32 2014 From: Frank.French at causeway.com (Frank French) Date: Sun, 2 Nov 2014 22:10:32 +0000 Subject: [keycloak-user] Token refresh from Android native app Message-ID: I'm currently using the browser to initially log in to my app. After the user credentials have been validated I intercept the url containing the code and use that on the resource /realms/myrealm/tokens/access/codes. To convert the code into a token. I am then able to use the embedded access token for subsequent API calls. This works fine until the access token expires. When the access token expires the service returns a 401. At present the only way I can get past this is to redirect the user back to the login page and start the above process again (creates another session). I would only expect to have to do this if the SSO idle timeout and been reached (it hasn't). I've looked through the API docs and found the resource /realms/myrealm/token/refresh. I've tried using this resource but have failed miserably. Could someone please explain how to use this resource or point me somewhere else if I've got it completely wrong. Example code below. private JWSToken refreshToken(String accessToken, String refreshToken) throws IOException, InvalidTokenException{ JWSToken token = null; String url = "http://127.0.0.1:8080/auth/realms/myrealm/tokens/refresh"; //String query = "refresh_token=" + refreshToken; //String query = "refresh_token=" + refreshToken + "client_id=" + CLIENT_ID"; String query = "refresh_token=" + refreshToken + "client_id=" + CLIENT_ID + "grant_type=refresh_token"; //Tried all the above HttpPost httppost = new HttpPost(url); httppost.addHeader("Authorization", "Bearer " + accessToken); //401 with 400 without httppost.addHeader("Content-Type", "application/x-www-form-urlencoded"); ByteArrayEntity entity = new ByteArrayEntity(query.getBytes()); httppost.setEntity(entity); HttpResponse response = httpclient.execute(httppost); int status = response.getStatusLine().getStatusCode(); if (status == HttpStatus.SC_OK){ InputStream stream = null; try{ stream = response.getEntity().getContent(); ObjectMapper mapper = new ObjectMapper(); token = mapper.readValue(stream, JWSToken.class); }finally{ if (stream != null){ stream.close(); } } }else{ throw new InvalidTokenException(); } return token; } ________________________________ Causeway is committed towards reducing its carbon footprint. Please consider the environment before printing this email. ________________________________ Disclaimer Notice :- The message and any attachments contained in this e-mail are intended for the named recipient(s) only. It may contain privileged or confidential information or information which is exempt from disclosure under the applicable laws. If you are not the intended recipient(s), you must not read, print, retain, copy distribute, forward or take any or refrain from taking any action in reliance on it or any of its attachments. If you have received or have been forwarded this e-mail in error, please notify us immediately by return e-mail or telephone (+44 (0)1628 552000) and delete this message from the computer or any other data-reading device in its entirety. Please advise us immediately if you do not or your employer does not consent to Internet e-mail for messages of this nature. Internet communications cannot be guaranteed to be secure and error-free as the information could be intercepted, corrupted, lost, arrive late or contain viruses. The sender and this Company therefore do not and shall not accept any liability or responsibility of whatsoever nature in the context of this message and its attachment(s) which arises as a result of Internet transmission. Opinions, conclusion, representations, views and such other information in this message that do not relate to the official business of this Company shall be understood as neither given nor endorsed by it. Registered Office: Comino House, Furlong Road, Bourne End, Buckinghamshire, SL8 5AQ Registered in England No: 3921897 www.causeway.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20141102/a2997fcf/attachment.html From corinnekrych at gmail.com Sun Nov 2 17:30:25 2014 From: corinnekrych at gmail.com (Corinne Krych) Date: Sun, 2 Nov 2014 23:30:25 +0100 Subject: [keycloak-user] Token refresh from Android native app In-Reply-To: References: Message-ID: On 02 Nov 2014, at 23:10, Frank French wrote: > > I?m currently using the browser to initially log in to my app. After the user credentials have been validated I intercept the url containing the code and use that on the resource /realms/myrealm/tokens/access/codes. To convert the code into a token. I am then able to use the embedded access token for subsequent API calls. This works fine until the access token expires. > > When the access token expires the service returns a 401. At present the only way I can get past this is to redirect the user back to the login page and start the above process again (creates another session). I would only expect to have to do this if the SSO idle timeout and been reached (it hasn?t). I?ve looked through the API docs and found the resource /realms/myrealm/token/refresh. I?ve tried using this resource but have failed miserably. Could someone please explain how to use this resource or point me somewhere else if I?ve got it completely wrong. > Access token expires. There is another way to track expiration (rather than the 401) thanks to the expiration date provided when the access token is delivered. Checking if the token is expired: See: https://github.com/aerogear/aerogear-android-authz/blob/master/aerogear-android-authz%2Fsrc%2Fmain%2Fjava%2Forg%2Fjboss%2Faerogear%2Fandroid%2Fimpl%2Fauthz%2Foauth2%2FOAuth2AuthzService.java#L86 Be aware that keycloak implements renewal of refresh tokens: every time you renew an access token, you get a new refresh token to update. Besides, in Keycloak, refresh token also expires. In the case of expired refresh token, the only way forward will be to ask for grant again. Here is an example on how to issue the request on android: https://github.com/aerogear/aerogear-android-authz/blob/master/aerogear-android-authz%2Fsrc%2Fmain%2Fjava%2Forg%2Fjboss%2Faerogear%2Fandroid%2Fimpl%2Fauthz%2Foauth2%2FOAuth2AuthzService.java#L214 I think you should go without adding it to header. Be cautious about the query param formatting. ++ Corinne ????? iOS dev > Example code below. > > private JWSToken refreshToken(String accessToken, String refreshToken) throws IOException, InvalidTokenException{ > JWSToken token = null; > > String url = "http://127.0.0.1:8080/auth/realms/myrealm/tokens/refresh"; > //String query = ?refresh_token=? + refreshToken; > //String query = ?refresh_token=? + refreshToken + ?client_id=" + CLIENT_ID"; > String query = "refresh_token=" + refreshToken + "client_id=" + CLIENT_ID + "grant_type=refresh_token"; > //Tried all the above > > HttpPost httppost = new HttpPost(url); > httppost.addHeader(?Authorization?, ?Bearer ? + accessToken); //401 with 400 without > httppost.addHeader("Content-Type", "application/x-www-form-urlencoded"); > > ByteArrayEntity entity = new ByteArrayEntity(query.getBytes()); > httppost.setEntity(entity); > HttpResponse response = httpclient.execute(httppost); > > int status = response.getStatusLine().getStatusCode(); > > if (status == HttpStatus.SC_OK){ > InputStream stream = null; > > try{ > stream = response.getEntity().getContent(); > > ObjectMapper mapper = new ObjectMapper(); > token = mapper.readValue(stream, JWSToken.class); > }finally{ > if (stream != null){ > stream.close(); > } > } > }else{ > throw new InvalidTokenException(); > } > > return token; > } > > > > > Causeway is committed towards reducing its carbon footprint. Please consider the environment before printing this email. > > > > Disclaimer Notice :- > > The message and any attachments contained in this e-mail are intended for the named recipient(s) only. It may contain privileged or confidential information or information which is exempt from disclosure under the applicable laws. If you are not the intended recipient(s), you must not read, print, retain, copy distribute, forward or take any or refrain from taking any action in reliance on it or any of its attachments. If you have received or have been forwarded this e-mail in error, please notify us immediately by return e-mail or telephone (+44 (0)1628 552000) and delete this message from the computer or any other data-reading device in its entirety. > > Please advise us immediately if you do not or your employer does not consent to Internet e-mail for messages of this nature. > > Internet communications cannot be guaranteed to be secure and error-free as the information could be intercepted, corrupted, lost, arrive late or contain viruses. The sender and this Company therefore do not and shall not accept any liability or responsibility of whatsoever nature in the context of this message and its attachment(s) which arises as a result of Internet transmission. Opinions, conclusion, representations, views and such other information in this message that do not relate to the official business of this Company shall be understood as neither given nor endorsed by it. > > Registered Office: Comino House, Furlong Road, Bourne End, Buckinghamshire, SL8 5AQ > Registered in England No: 3921897 www.causeway.com > _______________________________________________ > keycloak-user mailing list > keycloak-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 496 bytes Desc: Message signed with OpenPGP using GPGMail Url : http://lists.jboss.org/pipermail/keycloak-user/attachments/20141102/50771644/attachment-0001.bin From alexander.chriztopher at gmail.com Mon Nov 3 03:20:46 2014 From: alexander.chriztopher at gmail.com (Alexander Chriztopher) Date: Mon, 3 Nov 2014 09:20:46 +0100 Subject: [keycloak-user] Getting the current user name in EJB In-Reply-To: <5453DE98.6080303@redhat.com> References: <5453DE98.6080303@redhat.com> Message-ID: Great ! Works nicely ! Thank you Bill. On Fri, Oct 31, 2014 at 8:10 PM, Bill Burke wrote: > You should be able to typecast Principal to KeycloakPrincipal. > > On 10/31/2014 2:27 PM, Alexander Chriztopher wrote: > > Hi All, > > > > Am trying to get the name and surname of the currently connected user by > > doing this : > > > > import java.io.Serializable; > > import java.security.Principal; > > > > import javax.annotation.Resource; > > import javax.annotation.security.RolesAllowed; > > import javax.ejb.EJBContext; > > import javax.ejb.LocalBean; > > import javax.ejb.Stateless; > > > > import org.jboss.ejb3.annotation.SecurityDomain; > > > > > > @Stateless(name="myEJB") > > @LocalBean > > @SecurityDomain("keycloak") > > public class MyEJB implements Serializable { > > > > private static final long serialVersionUID = 1L; > > > > @Resource > > private EJBContext ejbContext; > > @RolesAllowed("ADMIN") > > public void test() { > > Principal principal = ejbContext.getCallerPrincipal(); > > System.out.println("principal.getName() = " + > principal.getName()); > > } > > } > > > > This works nicely as i get a 403 if my currently connected user does > > have the role : ADMIN. > > > > My question is : does keycloak propagate the username or any other > > information that would help me get the first name and last name of the > > currently connected user ? Unfortunately, principal.getName() returns a > > string like this : edd42240-85bf-4724-8d79-5374338506b7 which i don't > > know the interpretation ! > > > > Thanks for any help. > > > > > > _______________________________________________ > > keycloak-user mailing list > > keycloak-user at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/keycloak-user > > > > -- > Bill Burke > JBoss, a division of Red Hat > http://bill.burkecentral.com > _______________________________________________ > 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-user/attachments/20141103/8ad5014a/attachment.html From stian at redhat.com Mon Nov 3 03:27:00 2014 From: stian at redhat.com (Stian Thorgersen) Date: Mon, 3 Nov 2014 03:27:00 -0500 (EST) Subject: [keycloak-user] OpenID Connect support In-Reply-To: <20141031164952.5778dca6@akvo.org> References: <5452DD92.8020900@redhat.com> <680633017.71362.1414759297021.JavaMail.yahoo@jws100207.mail.ne1.yahoo.com> <5453ADAE.3000801@redhat.com> <20141031164952.5778dca6@akvo.org> Message-ID: <541923633.5973570.1415003220654.JavaMail.zimbra@redhat.com> +1 To changing iss to https:///auth/realms/ Realm name isn't very unique (for example all KC servers comes with a master realm by default), but a URL would be. Should also be a relatively easy fix to make adapters use the last bit of iss as the realm name. ----- Original Message ----- > From: "Iv?n Perdomo" > To: "Bill Burke" > Cc: keycloak-user at lists.jboss.org > Sent: Friday, 31 October, 2014 4:49:52 PM > Subject: Re: [keycloak-user] OpenID Connect support > > > Wouldn't just using the > https:///auth/realms/ a way to meet the > specification but also enable the multi-tenant behavior in Keycloak ? > > Just an idea > > On Fri, 31 Oct 2014 11:41:34 -0400 > Bill Burke wrote: > > > realm name by itself is a valid URL, its just not a url with a scheme. > > > > On 10/31/2014 8:41 AM, prab rrrr wrote: > > > Read the spec once again and agree to your point that access code > > > can only be used once. Regarding "iss", as long as realm name is > > > replaced by URL, it should be good. I will do some more testing > > > today, mostly on validating the signature of the token and will let > > > you know if I find any discrepancies. > > > > > > Thanks once again, for the response and explanation. > > > > > > > > > On Thursday, October 30, 2014 8:53 PM, Bill Burke > > > wrote: > > > > > > > > > Section 3 does mention that the issuer is a URL using HTTPS, but > > > this URL does not have to match the token endpoint URL. It is just > > > a unique identifier for the issuer. That's it. > > > > > > Maybe I'm just not understanding OIDC, but what you are describing > > > for "aud" and "azp" doesn't make sense to me. An ID Token is not > > > an access token. Its not something you pass around to use for > > > authz. Neither do you pass around access codes. Access codes are > > > only usable once. > > > > > > Keycloak just doesn't support multiple audiences. When an oauth > > > client is registered, a set of valid redirect uri patterns are > > > associated with it. You cannot associate a client with another > > > client. The ID Token will only ever contain one client_id in the > > > "aud" and the "azp" will always be blank because its an optional > > > setting. > > > > > > We support narrowed "trust" by role scope mappings. When an access > > > token is created for a specific client, it is only granted > > > permissions that are configured for that client's scope. For > > > example: > > > > > > * Service 'A' has roles of "user" and "admin" > > > * Service 'B' has roles of "admin" and "analyst" > > > * User has a role mapping of A.user, A.admin, B.admin, B.analyst > > > * Oauth client "C" is registered with a role scope mapping of A.user > > > * Oauth client 'C' initiates a token request on behalf of the User, > > > it gets an access token only with a permission of 'A.user' even > > > though the user has other permissions. So it wouldn't be able to > > > access Service 'B' at all. > > > > > > > > > > > > On 10/30/2014 6:42 PM, Raghuram wrote: > > > > Hi Bill - here is my understanding of the spec: > > > > > > > > Section 3.1.3.7 of the core spec says that clients must validate > > > > the > > > id tokens. The third point of the same section says that "aud" can > > > contain more than 1 element in which case the fourth point says > > > that the client should verify that "azp" is present and the fifth > > > point says azp should be verified against the client id > > > > > > > > Now when an oauth client registers, it can specify multiple > > > > redirect > > > Uris, corresponding to diff oauth clients that wish to participate > > > in a single sign on. When a user tries to access first client and > > > he is authenticated, the client just gets a code. If the code is > > > passed to the second client ( the first client could be web app and > > > the second client could be a database service) then the second > > > client could get an Idtoken. The auth server (key cloak in this > > > case) would then list all the client ids in "aud" and specify the > > > second client in "azp" which will be validated by the second client. > > > > > > > > The above is a valid use case in our organization > > > > ( authentication > > > delegation). It gives flexibility to the apps ( especially sensitive > > > ones) to pick the apps they trust rather than just participate in an > > > organization wide single sign on. > > > > > > > > Section 3 (openID provider metadata) of the discovery spec > > > > mentions > > > that issuer is a url using https. > > > > > > > > Hope I make sense. > > > > > > > > Thanks. > > > > Sent from my iPhone > > > > > > > >> On Oct 30, 2014, at 4:58 PM, Bill Burke > > > wrote: > > > >> > > > >> Ivan, btw, looking at the library you are using, validation of > > > >> the > > > ID token is optional. > > > >> > > > >>> On 10/30/2014 4:15 PM, Raghuram wrote: > > > >>> I tested with libraries based on Apache Oltu and even I noticed > > > that realm name is being sent in the Idtoken under "iss". "aud" is > > > null when I included multiple redirect Uris which is breaking the > > > validation (as per openid spec). "azp" is not being sent (it is > > > optional unless more than 1 client is registered) - expect that to > > > be sent once I register two clients. > > > >> "aud" has been fixed in master. > > > >> > > > >> "iss" still is the realm name. This is just a unique > > > >> identifier for > > > the realm. And there is nothing in the spec that I could find that > > > states that it must match the token endpoint URL. It just has to > > > be a URL that uniquely identifies the issuer. It is something that > > > is configured, or, found during OIDC discovery. > > > >> > > > >> "AZP > > > >> Your interpretation of AZP is not my interpretation of AZP. #1. > > > AZP is optional, we don't have to include it at all. #2 It would > > > only have the value of the client that requested the token. In > > > Keycloak, ID Tokens are generated and only given to one audience. > > > >> > > > >> > > > >>> Used /account for userinfo end point that didn't work. Will > > > >>> provide > > > more feedback as I continue to test > > > >> > > > >> As I said before, we do not support userinfo yet. Our access > > > >> tokens > > > are Json Web Signatures signed by the realm and the content is an > > > extended version of ID Tokens that contains additional keycloak > > > metadata. > > > >> > > > >>> Fyi -My libraries were tested completely against a server > > > implementation based on Mitre's open Id connect and they are good. > > > >> > > > >> It's on the roadmap to expand our OIDC support beyond the > > > >> minimal > > > requirements and to validate it against other implementations. Just > > > haven't gotten to it yet. > > > >> > > > >> > > > >> -- > > > >> Bill Burke > > > >> JBoss, a division of Red Hat > > > >> http://bill.burkecentral.com > > > > > > > > > -- > > > Bill Burke > > > JBoss, a division of Red Hat > > > http://bill.burkecentral.com > > > > > > > > > > > > -- > Iv?n > > _______________________________________________ > keycloak-user mailing list > keycloak-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user From stian at redhat.com Mon Nov 3 03:30:02 2014 From: stian at redhat.com (Stian Thorgersen) Date: Mon, 3 Nov 2014 03:30:02 -0500 (EST) Subject: [keycloak-user] Java API documentation In-Reply-To: References: <1314214423.165496.1414610170091.JavaMail.yahoo@jws100156.mail.ne1.yahoo.com> Message-ID: <1239690273.5975064.1415003402001.JavaMail.zimbra@redhat.com> ----- Original Message ----- > From: "Alexander Chriztopher" > To: "Kamal Jagadevan" > Cc: keycloak-user at lists.jboss.org > Sent: Friday, 31 October, 2014 4:59:24 PM > Subject: Re: [keycloak-user] Java API documentation > > I have upgraded to 1.0.4.Final but still have the issue. > > I would consider this as a bug in Keycloak -well in the client at least- as > am using Wildfly and i am embedding the Jackson dependencies with my war > anyway. These dependencies are pulled by the Keycloak ones. > > @Keycloak team : should i open an issue for this one ? Sure > > On Wed, Oct 29, 2014 at 8:16 PM, Kamal Jagadevan < j.kamal at ymail.com > wrote: > > > > Hi Alexander, > On a second look, my problem was with my tomcat application that integrates > with Keycloak. This tomcat application was using fasterxml jackson parser > whereas keycloak implementation uses codehaus jackson which gets overridden > during runtime. I was able to overcome this problem by creating > PropertyNamingStrategy and set it to ObjectMapper before deserializing the > JSON. > > Alternatively Keycloak implementation can be modified to use fasterxml > jackson databinding. > > -Kamal > > > From: Alexander Chriztopher < alexander.chriztopher at gmail.com > > To: Kamal Jagadevan < j.kamal at ymail.com > > Cc: " keycloak-user at lists.jboss.org " < keycloak-user at lists.jboss.org > > Sent: Monday, October 27, 2014 12:54 PM > Subject: Re: [keycloak-user] Java API documentation > > Hi Kamal and thanks. > > Am using the keycloak admin client which brings the following Jackson > dependency : jackson-core-asl:1.9.9 and can not override this. I also don't > have the option to change the property mapping as it comes with the Keycloak > distribution am using :-( > > > > On Mon, Oct 27, 2014 at 4:54 PM, Kamal Jagadevan < j.kamal at ymail.com > wrote: > > > > Hi Alexander, > I had faced the same problem few days back it is because of the mismatch > between JSONProperty and POJO variable name(getter method) that too with > fasterxml jackson parser. > If you use codehaus jackson parser you wouldnt get any problem. One work > around to this problem is to update the POJO variable name to reflect the > JSONProperty name. > Similar problem is observed in multiple places where deserialization kicks > in.. > > Specifically it is because of this > > @JsonProperty(" access_token ") > protected String token ; > > Hi Bill, > Do you have any other ideas besides updating POJOs member variable name > matching the JSON property? Please advise. > > Thanks > Kamal > > > > From: Alexander Chriztopher < alexander.chriztopher at gmail.com > > To: " keycloak-user at lists.jboss.org " < keycloak-user at lists.jboss.org > > Sent: Monday, October 27, 2014 11:45 AM > Subject: [keycloak-user] Java API documentation > > Hi All, > Am using Keycloak 1.0.2.Final and am getting this error when using the rest > API : > Caused by: com.fasterxml.jackson.databind.exc.UnrecognizedPropertyException : > Unrecognized field "access_token" (class > org.keycloak.representations.AccessTokenResponse), not marked as ignorable > (7 known properties: "tokenType", "notBeforePolicy", "token", "expiresIn", > "sessionState", "refreshToken", "idToken"]) > at [Source: org.apache.http.conn.EofSensorInputStream at 11b8a95d; line: 1, > column: 18] (through reference chain: > org.keycloak.representations.AccessTokenResponse["access_token"]) > at com.fasterxml.jackson.databind.exc.UnrecognizedPropertyException.from( > UnrecognizedPropertyException.java:51 ) [jackson-databind-2.3.2.jar:2.3.2] > at > com.fasterxml.jackson.databind.DeserializationContext.reportUnknownProperty( > DeserializationContext.java:671 ) [jackson-databind-2.3.2.jar:2.3.2] > at > com.fasterxml.jackson.databind.deser.std.StdDeserializer.handleUnknownProperty( > StdDeserializer.java:771 ) [jackson-databind-2.3.2.jar:2.3.2] > at > com.fasterxml.jackson.databind.deser.BeanDeserializerBase.handleUnknownProperty( > BeanDeserializerBase.java:1297 ) [jackson-databind-2.3.2.jar:2.3.2] > at > com.fasterxml.jackson.databind.deser.BeanDeserializerBase.handleUnknownVanilla( > BeanDeserializerBase.java:1275 ) [jackson-databind-2.3.2.jar:2.3.2] > at com.fasterxml.jackson.databind.deser.BeanDeserializer.vanillaDeserialize( > BeanDeserializer.java:247 ) [jackson-databind-2.3.2.jar:2.3.2] > at com.fasterxml.jackson.databind.deser.BeanDeserializer.deserialize( > BeanDeserializer.java:118 ) [jackson-databind-2.3.2.jar:2.3.2] > at com.fasterxml.jackson.databind.ObjectReader._bind( ObjectReader.java:1233 > ) [jackson-databind-2.3.2.jar:2.3.2] > at com.fasterxml.jackson.databind.ObjectReader.readValue( > ObjectReader.java:677 ) [jackson-databind-2.3.2.jar:2.3.2] > at > org.jboss.resteasy.plugins.providers.jackson.ResteasyJackson2Provider.readFrom( > ResteasyJackson2Provider.java:120 ) > [resteasy-jackson2-provider-3.0.8.Final.jar:] > at > org.jboss.resteasy.core.interception.AbstractReaderInterceptorContext.readFrom( > AbstractReaderInterceptorContext.java:59 ) [resteasy-jaxrs-3.0.8.Final.jar:] > at > org.jboss.resteasy.core.interception.AbstractReaderInterceptorContext.proceed( > AbstractReaderInterceptorContext.java:51 ) [resteasy-jaxrs-3.0.8.Final.jar:] > at > org.jboss.resteasy.security.doseta.DigitalVerificationInterceptor.aroundReadFrom( > DigitalVerificationInterceptor.java:32 ) [resteasy-crypto-3.0.8.Final.jar:] > at > org.jboss.resteasy.core.interception.AbstractReaderInterceptorContext.proceed( > AbstractReaderInterceptorContext.java:53 ) [resteasy-jaxrs-3.0.8.Final.jar:] > at > org.jboss.resteasy.plugins.interceptors.encoding.GZIPDecodingInterceptor.aroundReadFrom( > GZIPDecodingInterceptor.java:59 ) [resteasy-jaxrs-3.0.8.Final.jar:] > at > org.jboss.resteasy.core.interception.AbstractReaderInterceptorContext.proceed( > AbstractReaderInterceptorContext.java:53 ) [resteasy-jaxrs-3.0.8.Final.jar:] > at org.jboss.resteasy.client.jaxrs.internal.ClientResponse.readFrom( > ClientResponse.java:248 ) [resteasy-client-3.0.8.Final.jar:] > ... 164 more > > Was wondering where this comes from as am using the 1.0.2.Final admin api and > have updated my Wildfly Server accordingly. > > _______________________________________________ > keycloak-user mailing list > keycloak-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user > > > > > > > _______________________________________________ > keycloak-user mailing list > keycloak-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user From stian at redhat.com Mon Nov 3 03:36:35 2014 From: stian at redhat.com (Stian Thorgersen) Date: Mon, 3 Nov 2014 03:36:35 -0500 (EST) Subject: [keycloak-user] Token refresh from Android native app In-Reply-To: References: Message-ID: <1917730873.5982159.1415003795210.JavaMail.zimbra@redhat.com> Simple example of refreshing token (from our testsuite): https://github.com/keycloak/keycloak/blob/master/testsuite/integration/src/test/java/org/keycloak/testsuite/OAuthClient.java#L197 ----- Original Message ----- > From: "Frank French" > To: keycloak-user at lists.jboss.org > Sent: Sunday, 2 November, 2014 11:10:32 PM > Subject: [keycloak-user] Token refresh from Android native app > > > I?m currently using the browser to initially log in to my app. After the user > credentials have been validated I intercept the url containing the code and > use that on the resource /realms/myrealm/tokens/access/codes. To convert the > code into a token. I am then able to use the embedded access token for > subsequent API calls. This works fine until the access token expires. > > When the access token expires the service returns a 401. At present the only > way I can get past this is to redirect the user back to the login page and > start the above process again (creates another session). I would only expect > to have to do this if the SSO idle timeout and been reached (it hasn?t). > I?ve looked through the API docs and found the resource > /realms/myrealm/token/refresh. I?ve tried using this resource but have > failed miserably. Could someone please explain how to use this resource or > point me somewhere else if I?ve got it completely wrong. > > Example code below. > > > > private JWSToken refreshToken(String accessToken , String refreshToken ) > throws IOException, InvalidTokenException{ > > JWSToken token = null ; > > > > String url = " http://127.0.0.1:8080/auth/realms/myrealm/tokens/refresh " ; > > //String query = ?refresh_token=? + refreshToken ; > > //String query = ?refresh_token=? + refreshToken + ?client_id=" + CLIENT_ID " > ; > > String query = "refresh_token=" + refreshToken + "client_id=" + CLIENT_ID + > "grant_type=refresh_token" ; > > //Tried all the above > > > > > HttpPost httppost = new HttpPost( url ); > > httppost .addHeader( ?Authorization ? , ?Bearer ? + accessToken ); //401 with > 400 without > > httppost .addHeader( "Content-Type" , "application/x-www-form-urlencoded" ); > > > > ByteArrayEntity entity = new ByteArrayEntity( query .getBytes()); > > httppost .setEntity( entity ); > > HttpResponse response = httpclient .execute( httppost ); > > > > > int status = response .getStatusLine().getStatusCode(); > > > > > if ( status == HttpStatus. SC_OK ){ > > InputStream stream = null ; > > > > > try { > > stream = response .getEntity().getContent(); > > > > > ObjectMapper mapper = new ObjectMapper(); > > token = mapper .readValue( stream , JWSToken. class ); > > } finally { > > if ( stream != null ){ > > stream .close(); > > } > > } > > } else { > > throw new InvalidTokenException() ; > > } > > > > return token ; > > } > > > > > > > > Causeway is committed towards reducing its carbon footprint. Please consider > the environment before printing this email. > > > > > Disclaimer Notice :- > > The message and any attachments contained in this e-mail are intended for the > named recipient(s) only. It may contain privileged or confidential > information or information which is exempt from disclosure under the > applicable laws. If you are not the intended recipient(s), you must not > read, print, retain, copy distribute, forward or take any or refrain from > taking any action in reliance on it or any of its attachments. If you have > received or have been forwarded this e-mail in error, please notify us > immediately by return e-mail or telephone (+44 (0)1628 552000) and delete > this message from the computer or any other data-reading device in its > entirety. > > Please advise us immediately if you do not or your employer does not consent > to Internet e-mail for messages of this nature. > > Internet communications cannot be guaranteed to be secure and error-free as > the information could be intercepted, corrupted, lost, arrive late or > contain viruses. The sender and this Company therefore do not and shall not > accept any liability or responsibility of whatsoever nature in the context > of this message and its attachment(s) which arises as a result of Internet > transmission. Opinions, conclusion, representations, views and such other > information in this message that do not relate to the official business of > this Company shall be understood as neither given nor endorsed by it. > > Registered Office: Comino House, Furlong Road, Bourne End, Buckinghamshire, > SL8 5AQ > Registered in England No: 3921897 www.causeway.com > > _______________________________________________ > keycloak-user mailing list > keycloak-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user From alexander.chriztopher at gmail.com Mon Nov 3 03:45:19 2014 From: alexander.chriztopher at gmail.com (Alexander Chriztopher) Date: Mon, 3 Nov 2014 09:45:19 +0100 Subject: [keycloak-user] Fwd: Java API documentation In-Reply-To: References: <1314214423.165496.1414610170091.JavaMail.yahoo@jws100156.mail.ne1.yahoo.com> <1239690273.5975064.1415003402001.JavaMail.zimbra@redhat.com> Message-ID: ---------- Forwarded message ---------- From: Alexander Chriztopher Date: Mon, Nov 3, 2014 at 9:44 AM Subject: Re: [keycloak-user] Java API documentation To: Stian Thorgersen Hi Stian, I have opened an issue here : https://issues.jboss.org/browse/KEYCLOAK-811 Thanks for your help. On Mon, Nov 3, 2014 at 9:30 AM, Stian Thorgersen wrote: > > > ----- Original Message ----- > > From: "Alexander Chriztopher" > > To: "Kamal Jagadevan" > > Cc: keycloak-user at lists.jboss.org > > Sent: Friday, 31 October, 2014 4:59:24 PM > > Subject: Re: [keycloak-user] Java API documentation > > > > I have upgraded to 1.0.4.Final but still have the issue. > > > > I would consider this as a bug in Keycloak -well in the client at least- > as > > am using Wildfly and i am embedding the Jackson dependencies with my war > > anyway. These dependencies are pulled by the Keycloak ones. > > > > @Keycloak team : should i open an issue for this one ? > > Sure > > > > > On Wed, Oct 29, 2014 at 8:16 PM, Kamal Jagadevan < j.kamal at ymail.com > > wrote: > > > > > > > > Hi Alexander, > > On a second look, my problem was with my tomcat application that > integrates > > with Keycloak. This tomcat application was using fasterxml jackson parser > > whereas keycloak implementation uses codehaus jackson which gets > overridden > > during runtime. I was able to overcome this problem by creating > > PropertyNamingStrategy and set it to ObjectMapper before deserializing > the > > JSON. > > > > Alternatively Keycloak implementation can be modified to use fasterxml > > jackson databinding. > > > > -Kamal > > > > > > From: Alexander Chriztopher < alexander.chriztopher at gmail.com > > > To: Kamal Jagadevan < j.kamal at ymail.com > > > Cc: " keycloak-user at lists.jboss.org " < keycloak-user at lists.jboss.org > > > Sent: Monday, October 27, 2014 12:54 PM > > Subject: Re: [keycloak-user] Java API documentation > > > > Hi Kamal and thanks. > > > > Am using the keycloak admin client which brings the following Jackson > > dependency : jackson-core-asl:1.9.9 and can not override this. I also > don't > > have the option to change the property mapping as it comes with the > Keycloak > > distribution am using :-( > > > > > > > > On Mon, Oct 27, 2014 at 4:54 PM, Kamal Jagadevan < j.kamal at ymail.com > > wrote: > > > > > > > > Hi Alexander, > > I had faced the same problem few days back it is because of the mismatch > > between JSONProperty and POJO variable name(getter method) that too with > > fasterxml jackson parser. > > If you use codehaus jackson parser you wouldnt get any problem. One work > > around to this problem is to update the POJO variable name to reflect the > > JSONProperty name. > > Similar problem is observed in multiple places where deserialization > kicks > > in.. > > > > Specifically it is because of this > > > > @JsonProperty(" access_token ") > > protected String token ; > > > > Hi Bill, > > Do you have any other ideas besides updating POJOs member variable name > > matching the JSON property? Please advise. > > > > Thanks > > Kamal > > > > > > > > From: Alexander Chriztopher < alexander.chriztopher at gmail.com > > > To: " keycloak-user at lists.jboss.org " < keycloak-user at lists.jboss.org > > > Sent: Monday, October 27, 2014 11:45 AM > > Subject: [keycloak-user] Java API documentation > > > > Hi All, > > Am using Keycloak 1.0.2.Final and am getting this error when using the > rest > > API : > > Caused by: > com.fasterxml.jackson.databind.exc.UnrecognizedPropertyException : > > Unrecognized field "access_token" (class > > org.keycloak.representations.AccessTokenResponse), not marked as > ignorable > > (7 known properties: "tokenType", "notBeforePolicy", "token", > "expiresIn", > > "sessionState", "refreshToken", "idToken"]) > > at [Source: org.apache.http.conn.EofSensorInputStream at 11b8a95d; line: 1, > > column: 18] (through reference chain: > > org.keycloak.representations.AccessTokenResponse["access_token"]) > > at com.fasterxml.jackson.databind.exc.UnrecognizedPropertyException.from( > > UnrecognizedPropertyException.java:51 ) > [jackson-databind-2.3.2.jar:2.3.2] > > at > > > com.fasterxml.jackson.databind.DeserializationContext.reportUnknownProperty( > > DeserializationContext.java:671 ) [jackson-databind-2.3.2.jar:2.3.2] > > at > > > com.fasterxml.jackson.databind.deser.std.StdDeserializer.handleUnknownProperty( > > StdDeserializer.java:771 ) [jackson-databind-2.3.2.jar:2.3.2] > > at > > > com.fasterxml.jackson.databind.deser.BeanDeserializerBase.handleUnknownProperty( > > BeanDeserializerBase.java:1297 ) [jackson-databind-2.3.2.jar:2.3.2] > > at > > > com.fasterxml.jackson.databind.deser.BeanDeserializerBase.handleUnknownVanilla( > > BeanDeserializerBase.java:1275 ) [jackson-databind-2.3.2.jar:2.3.2] > > at > com.fasterxml.jackson.databind.deser.BeanDeserializer.vanillaDeserialize( > > BeanDeserializer.java:247 ) [jackson-databind-2.3.2.jar:2.3.2] > > at com.fasterxml.jackson.databind.deser.BeanDeserializer.deserialize( > > BeanDeserializer.java:118 ) [jackson-databind-2.3.2.jar:2.3.2] > > at com.fasterxml.jackson.databind.ObjectReader._bind( > ObjectReader.java:1233 > > ) [jackson-databind-2.3.2.jar:2.3.2] > > at com.fasterxml.jackson.databind.ObjectReader.readValue( > > ObjectReader.java:677 ) [jackson-databind-2.3.2.jar:2.3.2] > > at > > > org.jboss.resteasy.plugins.providers.jackson.ResteasyJackson2Provider.readFrom( > > ResteasyJackson2Provider.java:120 ) > > [resteasy-jackson2-provider-3.0.8.Final.jar:] > > at > > > org.jboss.resteasy.core.interception.AbstractReaderInterceptorContext.readFrom( > > AbstractReaderInterceptorContext.java:59 ) > [resteasy-jaxrs-3.0.8.Final.jar:] > > at > > > org.jboss.resteasy.core.interception.AbstractReaderInterceptorContext.proceed( > > AbstractReaderInterceptorContext.java:51 ) > [resteasy-jaxrs-3.0.8.Final.jar:] > > at > > > org.jboss.resteasy.security.doseta.DigitalVerificationInterceptor.aroundReadFrom( > > DigitalVerificationInterceptor.java:32 ) > [resteasy-crypto-3.0.8.Final.jar:] > > at > > > org.jboss.resteasy.core.interception.AbstractReaderInterceptorContext.proceed( > > AbstractReaderInterceptorContext.java:53 ) > [resteasy-jaxrs-3.0.8.Final.jar:] > > at > > > org.jboss.resteasy.plugins.interceptors.encoding.GZIPDecodingInterceptor.aroundReadFrom( > > GZIPDecodingInterceptor.java:59 ) [resteasy-jaxrs-3.0.8.Final.jar:] > > at > > > org.jboss.resteasy.core.interception.AbstractReaderInterceptorContext.proceed( > > AbstractReaderInterceptorContext.java:53 ) > [resteasy-jaxrs-3.0.8.Final.jar:] > > at org.jboss.resteasy.client.jaxrs.internal.ClientResponse.readFrom( > > ClientResponse.java:248 ) [resteasy-client-3.0.8.Final.jar:] > > ... 164 more > > > > Was wondering where this comes from as am using the 1.0.2.Final admin > api and > > have updated my Wildfly Server accordingly. > > > > _______________________________________________ > > keycloak-user mailing list > > keycloak-user at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/keycloak-user > > > > > > > > > > > > > > _______________________________________________ > > 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-user/attachments/20141103/66d6003d/attachment.html From Frank.French at causeway.com Mon Nov 3 08:13:18 2014 From: Frank.French at causeway.com (Frank French) Date: Mon, 3 Nov 2014 13:13:18 +0000 Subject: [keycloak-user] Token refresh from Android native app Message-ID: Thank you. That help resolved my problem. Frank Frensham House, Farnham Business Park, Weydon Lane, Farnham, Surrey, GU9 8QT T: +44 (0)1628 552000 F: +44 (0)1628 552001 W: www.causeway.com Please consider the environment before printing this emai On 03/11/2014 08:36, "Stian Thorgersen" wrote: >Simple example of refreshing token (from our testsuite): > >https://github.com/keycloak/keycloak/blob/master/testsuite/integration/src >/test/java/org/keycloak/testsuite/OAuthClient.java#L197 > > > >----- Original Message ----- >> From: "Frank French" >> To: keycloak-user at lists.jboss.org >> Sent: Sunday, 2 November, 2014 11:10:32 PM >> Subject: [keycloak-user] Token refresh from Android native app >> >> >> I?m currently using the browser to initially log in to my app. After >>the user >> credentials have been validated I intercept the url containing the code >>and >> use that on the resource /realms/myrealm/tokens/access/codes. To >>convert the >> code into a token. I am then able to use the embedded access token for >> subsequent API calls. This works fine until the access token expires. >> >> When the access token expires the service returns a 401. At present the >>only >> way I can get past this is to redirect the user back to the login page >>and >> start the above process again (creates another session). I would only >>expect >> to have to do this if the SSO idle timeout and been reached (it hasn?t). >> I?ve looked through the API docs and found the resource >> /realms/myrealm/token/refresh. I?ve tried using this resource but have >> failed miserably. Could someone please explain how to use this resource >>or >> point me somewhere else if I?ve got it completely wrong. >> >> Example code below. >> >> >> >> private JWSToken refreshToken(String accessToken , String refreshToken ) >> throws IOException, InvalidTokenException{ >> >> JWSToken token = null ; >> >> >> >> String url = " http://127.0.0.1:8080/auth/realms/myrealm/tokens/refresh >>" ; >> >> //String query = ?refresh_token=? + refreshToken ; >> >> //String query = ?refresh_token=? + refreshToken + ?client_id=" + >>CLIENT_ID " >> ; >> >> String query = "refresh_token=" + refreshToken + "client_id=" + >>CLIENT_ID + >> "grant_type=refresh_token" ; >> >> //Tried all the above >> >> >> >> >> HttpPost httppost = new HttpPost( url ); >> >> httppost .addHeader( ?Authorization ? , ?Bearer ? + accessToken ); >>//401 with >> 400 without >> >> httppost .addHeader( "Content-Type" , >>"application/x-www-form-urlencoded" ); >> >> >> >> ByteArrayEntity entity = new ByteArrayEntity( query .getBytes()); >> >> httppost .setEntity( entity ); >> >> HttpResponse response = httpclient .execute( httppost ); >> >> >> >> >> int status = response .getStatusLine().getStatusCode(); >> >> >> >> >> if ( status == HttpStatus. SC_OK ){ >> >> InputStream stream = null ; >> >> >> >> >> try { >> >> stream = response .getEntity().getContent(); >> >> >> >> >> ObjectMapper mapper = new ObjectMapper(); >> >> token = mapper .readValue( stream , JWSToken. class ); >> >> } finally { >> >> if ( stream != null ){ >> >> stream .close(); >> >> } >> >> } >> >> } else { >> >> throw new InvalidTokenException() ; >> >> } >> >> >> >> return token ; >> >> } >> >> >> >> >> >> >> >> Causeway is committed towards reducing its carbon footprint. Please >>consider >> the environment before printing this email. >> >> >> >> >> Disclaimer Notice :- >> >> The message and any attachments contained in this e-mail are intended >>for the >> named recipient(s) only. It may contain privileged or confidential >> information or information which is exempt from disclosure under the >> applicable laws. If you are not the intended recipient(s), you must not >> read, print, retain, copy distribute, forward or take any or refrain >>from >> taking any action in reliance on it or any of its attachments. If you >>have >> received or have been forwarded this e-mail in error, please notify us >> immediately by return e-mail or telephone (+44 (0)1628 552000) and >>delete >> this message from the computer or any other data-reading device in its >> entirety. >> >> Please advise us immediately if you do not or your employer does not >>consent >> to Internet e-mail for messages of this nature. >> >> Internet communications cannot be guaranteed to be secure and >>error-free as >> the information could be intercepted, corrupted, lost, arrive late or >> contain viruses. The sender and this Company therefore do not and shall >>not >> accept any liability or responsibility of whatsoever nature in the >>context >> of this message and its attachment(s) which arises as a result of >>Internet >> transmission. Opinions, conclusion, representations, views and such >>other >> information in this message that do not relate to the official business >>of >> this Company shall be understood as neither given nor endorsed by it. >> >> Registered Office: Comino House, Furlong Road, Bourne End, >>Buckinghamshire, >> SL8 5AQ >> Registered in England No: 3921897 www.causeway.com >> >> _______________________________________________ >> keycloak-user mailing list >> keycloak-user at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-user > >_______________________________________________ >keycloak-user mailing list >keycloak-user at lists.jboss.org >https://lists.jboss.org/mailman/listinfo/keycloak-user ________________________________ Causeway is committed towards reducing its carbon footprint. Please consider the environment before printing this email. ________________________________ Disclaimer Notice :- The message and any attachments contained in this e-mail are intended for the named recipient(s) only. It may contain privileged or confidential information or information which is exempt from disclosure under the applicable laws. If you are not the intended recipient(s), you must not read, print, retain, copy distribute, forward or take any or refrain from taking any action in reliance on it or any of its attachments. If you have received or have been forwarded this e-mail in error, please notify us immediately by return e-mail or telephone (+44 (0)1628 552000) and delete this message from the computer or any other data-reading device in its entirety. Please advise us immediately if you do not or your employer does not consent to Internet e-mail for messages of this nature. Internet communications cannot be guaranteed to be secure and error-free as the information could be intercepted, corrupted, lost, arrive late or contain viruses. The sender and this Company therefore do not and shall not accept any liability or responsibility of whatsoever nature in the context of this message and its attachment(s) which arises as a result of Internet transmission. Opinions, conclusion, representations, views and such other information in this message that do not relate to the official business of this Company shall be understood as neither given nor endorsed by it. Registered Office: Comino House, Furlong Road, Bourne End, Buckinghamshire, SL8 5AQ Registered in England No: 3921897 www.causeway.com From bburke at redhat.com Mon Nov 3 08:24:27 2014 From: bburke at redhat.com (Bill Burke) Date: Mon, 03 Nov 2014 08:24:27 -0500 Subject: [keycloak-user] Need your help community Message-ID: <5457820B.4040501@redhat.com> If you're using Keycloak and you like it, help us out by writing a blog about it. Anything would be great. A few sentences saying that you're uing keycloak and like it. Or, if you're ambitious, give us something more detailed on how you are deploying keycloak in your company. I would love to read some user stories just to get insight on how people are using us! Let me know if anybody does this and I'll link you from my blog. Thanks, Bill -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From pmadden at tomsawyer.com Tue Nov 4 08:50:20 2014 From: pmadden at tomsawyer.com (Patrick V. Madden) Date: Tue, 4 Nov 2014 05:50:20 -0800 (PST) Subject: [keycloak-user] LDAP Synch All Users Question Message-ID: <1153607865.260205.1415109020913.JavaMail.zimbra@tomsawyer.com> Hi, I am running a local 1.0.4.Final build on my local machine to do some testing. I have a quick question regarding an Active Directory Realm that I am trying to configure. I am able to successfully test the connection and test authentication using Bind DN and Bind Credential and Connection URL. I can connect via an external LDAP browser using same credential and browse the directory. When I click Synchronize all users button it says it is successful. However, when I go back to search page I get nothing when I enter a username. When I click show all users it shows nothing. I was hoping it would show me a list of all users in the search tree based on my settings. Lets assume my company is Acme. When I look at browser it shows: RootDSE +---DC=acme,DC=com +---OU=acmeUsers +---CN=John Doe ---CN=Jane Doe ---CN=Joe Blow I want the users to be in OU=acmeUsers,DC=acme,DC=com So what would I put in for Base DN and User DN Suffix to get it to show a list of all users in the directory? Or does it only show users that have logged into the Realm via a web app? Hope this makes sense. Regards, Patrick Madden Principal Design Engineer Tom Sawyer Software 1997 El Dorado Avenue Berkeley, CA 94707 Cell: +1 (845) 416-4629 E-mail: pmadden@ tomsawyer.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20141104/a3ef3038/attachment.html From pmadden at tomsawyer.com Tue Nov 4 08:58:09 2014 From: pmadden at tomsawyer.com (Patrick V. Madden) Date: Tue, 4 Nov 2014 05:58:09 -0800 (PST) Subject: [keycloak-user] Active Directory Realm question. Message-ID: <321656197.260447.1415109489708.JavaMail.zimbra@tomsawyer.com> Hi, Hope this doesn't post twice.... I am running a local 1.0.4.Final build on my local machine to do some testing. I have a quick question regarding an Active Directory Realm that I am trying to configure. I am able to successfully test the connection and test authentication using Bind DN and Bind Credential and Connection URL. I can connect via an external LDAP browser using same credential and browse the directory. When I click Synchronize all users button it says it is successful. However, when I go back to search page I get nothing when I enter a username. When I click show all users it shows nothing. I was hoping it would show me a list of all users in the search tree based on my settings. Lets assume my company is acme.com. When I look at browser it shows: RootDSE +---DC=acme,DC=com +---OU=acmeUsers +---CN=John Doe ---CN=Jane Doe ---CN=Joe Blow I want the users to be in OU=acmeUsers,DC=acme,DC=com And yes OU=acmeUsers is what I need... So what would I put in for Base DN and User DN Suffix to get it to show a list of all users in the directory? Or does it only show users that have logged into the Realm via a web app? Hope this makes sense. Regards, Patrick Madden Principal Design Engineer Tom Sawyer Software 1997 El Dorado Avenue Berkeley, CA 94707 Cell: +1 (845) 416-4629 E-mail: pmadden@ tomsawyer.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20141104/543a3ee9/attachment-0001.html From mposolda at redhat.com Tue Nov 4 14:58:31 2014 From: mposolda at redhat.com (Marek Posolda) Date: Tue, 04 Nov 2014 20:58:31 +0100 Subject: [keycloak-user] Active Directory Realm question. In-Reply-To: <321656197.260447.1415109489708.JavaMail.zimbra@tomsawyer.com> References: <321656197.260447.1415109489708.JavaMail.zimbra@tomsawyer.com> Message-ID: <54592FE7.7070306@redhat.com> Hi, after "Synchronize all users" you should be able to see all users from LDAP, not just those which already authenticated in Keycloak. For your LDAP tree, I believe that Base DN should be "DC=acme,DC=com" and User DN should be "OU=acmeUsers,DC=acme,DC=com" . Please let me know if it helps. Marek On 4.11.2014 14:58, Patrick V. Madden wrote: > Hi, > > Hope this doesn't post twice.... > > I am running a local 1.0.4.Final build on my local machine to do some > testing. > > I have a quick question regarding an Active Directory Realm that I am > trying to configure. I am able to successfully test the connection and > test authentication using Bind DN and Bind Credential and Connection URL. > > I can connect via an external LDAP browser using same credential and > browse the directory. > > When I click Synchronize all users button it says it is successful. > However, when I go back to search page I get nothing when I enter a > username. When I click show all users it shows nothing. I was hoping > it would show me a list of all users in the search tree based on my > settings. > > Lets assume my company is acme.com. When I look at browser it shows: > > RootDSE > +---DC=acme,DC=com > +---OU=acmeUsers > +---CN=John Doe > ---CN=Jane Doe > ---CN=Joe Blow > > I want the users to be in OU=acmeUsers,DC=acme,DC=com > > And yes OU=acmeUsers is what I need... > > So what would I put in for Base DN and User DN Suffix to get it to > show a list of all users in the directory? > > Or does it only show users that have logged into the Realm via a web app? > > Hope this makes sense. > > Regards, > > *Patrick Madden* > Principal Design Engineer > *Tom Sawyer Software * > 1997 El Dorado Avenue > Berkeley, CA 94707 > > Cell: +1 (845) 416-4629 > E-mail: pmadden at tomsawyer.com > > > > > _______________________________________________ > 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-user/attachments/20141104/3b219d9d/attachment.html From pmadden at tomsawyer.com Tue Nov 4 16:38:40 2014 From: pmadden at tomsawyer.com (Patrick V. Madden) Date: Tue, 4 Nov 2014 13:38:40 -0800 (PST) Subject: [keycloak-user] Active Directory Realm question. In-Reply-To: <1345894436.275685.1415137108275.JavaMail.zimbra@tomsawyer.com> References: <321656197.260447.1415109489708.JavaMail.zimbra@tomsawyer.com> <54592FE7.7070306@redhat.com> Message-ID: <1450514170.275689.1415137120910.JavaMail.zimbra@tomsawyer.com> Hi Marek, Wow! I was about to give up and then I decided to try to enter information into the field for User Object Classes. I was leaving that blank as it shows not required and tip seems to indicate it is for creating LDAP users via KeyCloak. I noticed in my LDAP Browser that among many others, it had 4 rows named objectClass as follows: Attribute Name Value objectClass top objectClass person objectClass organizationalPerson objectClass user Once I added these as "top,person,organizationalPerson,user" into User Object Classes field in LDAP Provider Settings it worked!!!! I was literally writing a response to say nope can't get it to work. Divine intervention made me try one more thing. This may be helpful to others. Thanks for your help. Patrick From: "Marek Posolda" To: "Patrick V. Madden" , "keycloack-users" Sent: Tuesday, November 4, 2014 1:58:31 PM Subject: Re: [keycloak-user] Active Directory Realm question. Hi, after "Synchronize all users" you should be able to see all users from LDAP, not just those which already authenticated in Keycloak. For your LDAP tree, I believe that Base DN should be "DC=acme,DC=com" and User DN should be "OU=acmeUsers,DC=acme,DC=com" . Please let me know if it helps. Marek On 4.11.2014 14:58, Patrick V. Madden wrote: Hi, Hope this doesn't post twice.... I am running a local 1.0.4.Final build on my local machine to do some testing. I have a quick question regarding an Active Directory Realm that I am trying to configure. I am able to successfully test the connection and test authentication using Bind DN and Bind Credential and Connection URL. I can connect via an external LDAP browser using same credential and browse the directory. When I click Synchronize all users button it says it is successful. However, when I go back to search page I get nothing when I enter a username. When I click show all users it shows nothing. I was hoping it would show me a list of all users in the search tree based on my settings. Lets assume my company is acme.com. When I look at browser it shows: RootDSE +---DC=acme,DC=com +---OU=acmeUsers +---CN=John Doe ---CN=Jane Doe ---CN=Joe Blow I want the users to be in OU=acmeUsers,DC=acme,DC=com And yes OU=acmeUsers is what I need... So what would I put in for Base DN and User DN Suffix to get it to show a list of all users in the directory? Or does it only show users that have logged into the Realm via a web app? Hope this makes sense. Regards, Patrick Madden Principal Design Engineer Tom Sawyer Software 1997 El Dorado Avenue Berkeley, CA 94707 Cell: +1 (845) 416-4629 E-mail: pmadden@ tomsawyer.com _______________________________________________ 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-user/attachments/20141104/c832abbb/attachment-0001.html From stian at redhat.com Wed Nov 5 04:22:32 2014 From: stian at redhat.com (Stian Thorgersen) Date: Wed, 5 Nov 2014 04:22:32 -0500 (EST) Subject: [keycloak-user] Keycloak 1.1.0.Beta1 Released In-Reply-To: <901535036.8091589.1415179344795.JavaMail.zimbra@redhat.com> Message-ID: <830066987.8091645.1415179352962.JavaMail.zimbra@redhat.com> Keycloak already supports OpenID Connect, but with this release we're also introducing support for SAML 2.0. We've also significantly improved our clustering support, for the server and application adapters. The server can now be configured to use an invalidation cache for realm meta-data and user profiles, while user-sessions can be stored in a distributed cache allowing for both increased scalability and availability. Application adapters can be configured for either sticky-session or stateless if sticky-sessions are not available. We've also added support for nodes to dynamically register with Keycloak to receive for example logout notifications. Thanks to Juraci Paix?o Kr?hling we now have multi-tenancy support in application adapters. His contribution makes it easy to use more than one realm for a single application. It's up to you to decide which realm is used for a request, but this could for example be depending on domain name or context-path. For anyone interested in this feature there's a simple example that shows how to get started. A while back Davide Ungari contributed a Tomcat 7 application adapter for Keycloak, but we haven't had time to document, test and make it a supported adapter until now. The next release of Keycloak should see the introduction of more application adapters, with support for JBoss BRMS, JBoss Fuse, UberFire, Hawt.io and Jetty. For a complete list of all features and fixes for this release check out JIRA (https://issues.jboss.org/issues/?jql=project%20%3D%20KEYCLOAK%20AND%20fixVersion%20%3D%201.1.0.Beta1%20AND%20resolution%20%3D%20Done). I'd like to especially thank all external contributors, please keep contributing! For everyone wanting to contribute Keycloak don't hesitate, it's easy to get started and we're here to help if you need any pointers. From theute at redhat.com Wed Nov 5 04:28:22 2014 From: theute at redhat.com (Thomas Heute) Date: Wed, 05 Nov 2014 10:28:22 +0100 Subject: [keycloak-user] Keycloak 1.1.0.Beta1 Released In-Reply-To: <830066987.8091645.1415179352962.JavaMail.zimbra@redhat.com> References: <830066987.8091645.1415179352962.JavaMail.zimbra@redhat.com> Message-ID: <5459EDB6.5090601@redhat.com> Awesome, congrats ! Thomas On 11/05/2014 10:22 AM, Stian Thorgersen wrote: > Keycloak already supports OpenID Connect, but with this release we're also introducing support for SAML 2.0. > > We've also significantly improved our clustering support, for the server and application adapters. The server can now be configured to use an invalidation cache for realm meta-data and user profiles, while user-sessions can be stored in a distributed cache allowing for both increased scalability and availability. Application adapters can be configured for either sticky-session or stateless if sticky-sessions are not available. We've also added support for nodes to dynamically register with Keycloak to receive for example logout notifications. > > Thanks to Juraci Paix?o Kr?hling we now have multi-tenancy support in application adapters. His contribution makes it easy to use more than one realm for a single application. It's up to you to decide which realm is used for a request, but this could for example be depending on domain name or context-path. For anyone interested in this feature there's a simple example that shows how to get started. > > A while back Davide Ungari contributed a Tomcat 7 application adapter for Keycloak, but we haven't had time to document, test and make it a supported adapter until now. > > The next release of Keycloak should see the introduction of more application adapters, with support for JBoss BRMS, JBoss Fuse, UberFire, Hawt.io and Jetty. > > For a complete list of all features and fixes for this release check out JIRA (https://issues.jboss.org/issues/?jql=project%20%3D%20KEYCLOAK%20AND%20fixVersion%20%3D%201.1.0.Beta1%20AND%20resolution%20%3D%20Done). > > I'd like to especially thank all external contributors, please keep contributing! For everyone wanting to contribute Keycloak don't hesitate, it's easy to get started and we're here to help if you need any pointers. > > _______________________________________________ > keycloak-user mailing list > keycloak-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user From ivan at akvo.org Wed Nov 5 05:30:44 2014 From: ivan at akvo.org (=?UTF-8?B?SXbDoW4=?= Perdomo) Date: Wed, 5 Nov 2014 11:30:44 +0100 Subject: [keycloak-user] Keycloak 1.1.0.Beta1 Released In-Reply-To: <830066987.8091645.1415179352962.JavaMail.zimbra@redhat.com> References: <901535036.8091589.1415179344795.JavaMail.zimbra@redhat.com> <830066987.8091645.1415179352962.JavaMail.zimbra@redhat.com> Message-ID: <20141105113044.58c8fa99@akvo.org> Congratulations to the Keycloak team! On Wed, 5 Nov 2014 04:22:32 -0500 (EST) Stian Thorgersen wrote: > I'd like to especially thank all external contributors, please keep > contributing! For everyone wanting to contribute Keycloak don't > hesitate, it's easy to get started and we're here to help if you need > any pointers. I'll be happy to contribute, in particular to the OIDC open issue :) https://issues.jboss.org/browse/KEYCLOAK-767 -- Iv?n From afroufeq at grancanaria.com Wed Nov 5 07:28:39 2014 From: afroufeq at grancanaria.com (Agustin Froufe) Date: Wed, 05 Nov 2014 12:28:39 +0000 Subject: [keycloak-user] Keycloak 1.1.0.Beta1 Released In-Reply-To: <830066987.8091645.1415179352962.JavaMail.zimbra@redhat.com> References: <830066987.8091645.1415179352962.JavaMail.zimbra@redhat.com> Message-ID: <545A17F7.6060900@grancanaria.com> Congratulations to all Keycloak team.. !! El 05/11/2014 09:22 AM, Stian Thorgersen escribi?: > Keycloak already supports OpenID Connect, but with this release we're also introducing support for SAML 2.0. > > We've also significantly improved our clustering support, for the server and application adapters. The server can now be configured to use an invalidation cache for realm meta-data and user profiles, while user-sessions can be stored in a distributed cache allowing for both increased scalability and availability. Application adapters can be configured for either sticky-session or stateless if sticky-sessions are not available. We've also added support for nodes to dynamically register with Keycloak to receive for example logout notifications. > > Thanks to Juraci Paix?o Kr?hling we now have multi-tenancy support in application adapters. His contribution makes it easy to use more than one realm for a single application. It's up to you to decide which realm is used for a request, but this could for example be depending on domain name or context-path. For anyone interested in this feature there's a simple example that shows how to get started. > > A while back Davide Ungari contributed a Tomcat 7 application adapter for Keycloak, but we haven't had time to document, test and make it a supported adapter until now. > > The next release of Keycloak should see the introduction of more application adapters, with support for JBoss BRMS, JBoss Fuse, UberFire, Hawt.io and Jetty. > > For a complete list of all features and fixes for this release check out JIRA (https://issues.jboss.org/issues/?jql=project%20%3D%20KEYCLOAK%20AND%20fixVersion%20%3D%201.1.0.Beta1%20AND%20resolution%20%3D%20Done). > > I'd like to especially thank all external contributors, please keep contributing! For everyone wanting to contribute Keycloak don't hesitate, it's easy to get started and we're here to help if you need any pointers. > > _______________________________________________ > keycloak-user mailing list > keycloak-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user -- Saludos, Agustin From rodrigopsasaki at gmail.com Wed Nov 5 09:10:55 2014 From: rodrigopsasaki at gmail.com (Rodrigo Sasaki) Date: Wed, 5 Nov 2014 12:10:55 -0200 Subject: [keycloak-user] Profile Picture Message-ID: I was going to look at Jira but it seems to be out for maintenance, so I just have a quick question. Is there already a feature request to add a profile image to the Keycloak User? Thanks! -- Rodrigo Sasaki -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20141105/32a7f6ca/attachment.html From bburke at redhat.com Wed Nov 5 09:13:10 2014 From: bburke at redhat.com (Bill Burke) Date: Wed, 05 Nov 2014 09:13:10 -0500 Subject: [keycloak-user] Profile Picture In-Reply-To: References: Message-ID: <545A3076.3050002@redhat.com> Improved Claim support is a jira task. I believe profile image is part of OIDC, so I guess implicitly it is a request :) On 11/5/2014 9:10 AM, Rodrigo Sasaki wrote: > I was going to look at Jira but it seems to be out for maintenance, so I > just have a quick question. > > Is there already a feature request to add a profile image to the > Keycloak User? > > Thanks! > > -- > Rodrigo Sasaki > > > _______________________________________________ > keycloak-user mailing list > keycloak-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user > -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From stian at redhat.com Wed Nov 5 09:13:53 2014 From: stian at redhat.com (Stian Thorgersen) Date: Wed, 5 Nov 2014 09:13:53 -0500 (EST) Subject: [keycloak-user] Profile Picture In-Reply-To: References: Message-ID: <1858931483.8303060.1415196833820.JavaMail.zimbra@redhat.com> JIRA is back up again now, if I remember correctly there's already an issue for it ----- Original Message ----- > From: "Rodrigo Sasaki" > To: keycloak-user at lists.jboss.org > Sent: Wednesday, 5 November, 2014 3:10:55 PM > Subject: [keycloak-user] Profile Picture > > I was going to look at Jira but it seems to be out for maintenance, so I just > have a quick question. > > Is there already a feature request to add a profile image to the Keycloak > User? > > Thanks! > > -- > Rodrigo Sasaki > > _______________________________________________ > keycloak-user mailing list > keycloak-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user From rodrigopsasaki at gmail.com Wed Nov 5 09:38:34 2014 From: rodrigopsasaki at gmail.com (Rodrigo Sasaki) Date: Wed, 5 Nov 2014 12:38:34 -0200 Subject: [keycloak-user] Profile Picture In-Reply-To: <1858931483.8303060.1415196833820.JavaMail.zimbra@redhat.com> References: <1858931483.8303060.1415196833820.JavaMail.zimbra@redhat.com> Message-ID: Oh, yes. It's KEYCLOAK-598 Are there plans to implement this already? Or is this a far far away feature? :) On Wed, Nov 5, 2014 at 12:13 PM, Stian Thorgersen wrote: > JIRA is back up again now, if I remember correctly there's already an > issue for it > > ----- Original Message ----- > > From: "Rodrigo Sasaki" > > To: keycloak-user at lists.jboss.org > > Sent: Wednesday, 5 November, 2014 3:10:55 PM > > Subject: [keycloak-user] Profile Picture > > > > I was going to look at Jira but it seems to be out for maintenance, so I > just > > have a quick question. > > > > Is there already a feature request to add a profile image to the Keycloak > > User? > > > > Thanks! > > > > -- > > Rodrigo Sasaki > > > > _______________________________________________ > > keycloak-user mailing list > > keycloak-user at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/keycloak-user > -- Rodrigo Sasaki -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20141105/5fe53556/attachment.html From stian at redhat.com Wed Nov 5 10:50:46 2014 From: stian at redhat.com (Stian Thorgersen) Date: Wed, 5 Nov 2014 10:50:46 -0500 (EST) Subject: [keycloak-user] Profile Picture In-Reply-To: References: <1858931483.8303060.1415196833820.JavaMail.zimbra@redhat.com> Message-ID: <1361807233.8428225.1415202646607.JavaMail.zimbra@redhat.com> We'll need custom user profiles, including support for profile pictures, in the not to distant future. We don't have any specific plans on when though. ----- Original Message ----- > From: "Rodrigo Sasaki" > To: "Stian T" > Cc: keycloak-user at lists.jboss.org > Sent: Wednesday, 5 November, 2014 3:38:34 PM > Subject: Re: [keycloak-user] Profile Picture > > Oh, yes. It's KEYCLOAK-598 > > Are there plans to implement this already? Or is this a far far away > feature? :) > > On Wed, Nov 5, 2014 at 12:13 PM, Stian Thorgersen wrote: > > > JIRA is back up again now, if I remember correctly there's already an > > issue for it > > > > ----- Original Message ----- > > > From: "Rodrigo Sasaki" > > > To: keycloak-user at lists.jboss.org > > > Sent: Wednesday, 5 November, 2014 3:10:55 PM > > > Subject: [keycloak-user] Profile Picture > > > > > > I was going to look at Jira but it seems to be out for maintenance, so I > > just > > > have a quick question. > > > > > > Is there already a feature request to add a profile image to the Keycloak > > > User? > > > > > > Thanks! > > > > > > -- > > > Rodrigo Sasaki > > > > > > _______________________________________________ > > > keycloak-user mailing list > > > keycloak-user at lists.jboss.org > > > https://lists.jboss.org/mailman/listinfo/keycloak-user > > > > > > -- > Rodrigo Sasaki > From mposolda at redhat.com Wed Nov 5 11:20:38 2014 From: mposolda at redhat.com (Marek Posolda) Date: Wed, 05 Nov 2014 17:20:38 +0100 Subject: [keycloak-user] Active Directory Realm question. In-Reply-To: <1450514170.275689.1415137120910.JavaMail.zimbra@tomsawyer.com> References: <321656197.260447.1415109489708.JavaMail.zimbra@tomsawyer.com> <54592FE7.7070306@redhat.com> <1450514170.275689.1415137120910.JavaMail.zimbra@tomsawyer.com> Message-ID: <545A4E56.2090207@redhat.com> yes, it makes sense to have Object classes mandatory in UI. I've fixed it (also change the tooltip), will be available in next version. Thanks! Marek On 4.11.2014 22:38, Patrick V. Madden wrote: > Hi Marek, > > Wow! I was about to give up and then I decided to try to enter > information into the field for User Object Classes. I was leaving that > blank as it shows not required and tip seems to indicate it is for > creating LDAP users via KeyCloak. I noticed in my LDAP Browser that > among many others, it had 4 rows named objectClass as follows: > > Attribute Name Value > objectClass top > objectClass person > objectClass organizationalPerson > objectClass user > > Once I added these as "top,person,organizationalPerson,user" into User > Object Classes field in LDAP Provider Settings it worked!!!! > > I was literally writing a response to say nope can't get it to work. > Divine intervention made me try one more thing. > > This may be helpful to others. > > Thanks for your help. > > Patrick > > ------------------------------------------------------------------------ > *From: *"Marek Posolda" > *To: *"Patrick V. Madden" , "keycloack-users" > > *Sent: *Tuesday, November 4, 2014 1:58:31 PM > *Subject: *Re: [keycloak-user] Active Directory Realm question. > > Hi, > > after "Synchronize all users" you should be able to see all users from > LDAP, not just those which already authenticated in Keycloak. For your > LDAP tree, I believe that Base DN should be "DC=acme,DC=com" and User > DN should be "OU=acmeUsers,DC=acme,DC=com" . Please let me know if it > helps. > > Marek > > On 4.11.2014 14:58, Patrick V. Madden wrote: > > Hi, > > Hope this doesn't post twice.... > > I am running a local 1.0.4.Final build on my local machine to do > some testing. > > I have a quick question regarding an Active Directory Realm that I > am trying to configure. I am able to successfully test the > connection and test authentication using Bind DN and Bind > Credential and Connection URL. > > I can connect via an external LDAP browser using same credential > and browse the directory. > > When I click Synchronize all users button it says it is > successful. However, when I go back to search page I get nothing > when I enter a username. When I click show all users it shows > nothing. I was hoping it would show me a list of all users in the > search tree based on my settings. > > Lets assume my company is acme.com. When I look at browser it shows: > > RootDSE > +---DC=acme,DC=com > +---OU=acmeUsers > +---CN=John Doe > ---CN=Jane Doe > ---CN=Joe Blow > > I want the users to be in OU=acmeUsers,DC=acme,DC=com > > And yes OU=acmeUsers is what I need... > > So what would I put in for Base DN and User DN Suffix to get it to > show a list of all users in the directory? > > Or does it only show users that have logged into the Realm via a > web app? > > Hope this makes sense. > > Regards, > > *Patrick Madden* > Principal Design Engineer > *Tom Sawyer Software * > 1997 El Dorado Avenue > > Berkeley, CA 94707 > > > > Cell: +1 (845) 416-4629 > E-mail: pmadden at tomsawyer.com > > > > > _______________________________________________ > 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-user/attachments/20141105/f19f7255/attachment-0001.html From rodrigopsasaki at gmail.com Wed Nov 5 12:42:57 2014 From: rodrigopsasaki at gmail.com (Rodrigo Sasaki) Date: Wed, 5 Nov 2014 15:42:57 -0200 Subject: [keycloak-user] Profile Picture In-Reply-To: <1361807233.8428225.1415202646607.JavaMail.zimbra@redhat.com> References: <1858931483.8303060.1415196833820.JavaMail.zimbra@redhat.com> <1361807233.8428225.1415202646607.JavaMail.zimbra@redhat.com> Message-ID: Oh, that's great :) I'll keep an eye out for it. Thanks again! On Wed, Nov 5, 2014 at 1:50 PM, Stian Thorgersen wrote: > We'll need custom user profiles, including support for profile pictures, > in the not to distant future. We don't have any specific plans on when > though. > > ----- Original Message ----- > > From: "Rodrigo Sasaki" > > To: "Stian T" > > Cc: keycloak-user at lists.jboss.org > > Sent: Wednesday, 5 November, 2014 3:38:34 PM > > Subject: Re: [keycloak-user] Profile Picture > > > > Oh, yes. It's KEYCLOAK-598 > > > > > Are there plans to implement this already? Or is this a far far away > > feature? :) > > > > On Wed, Nov 5, 2014 at 12:13 PM, Stian Thorgersen > wrote: > > > > > JIRA is back up again now, if I remember correctly there's already an > > > issue for it > > > > > > ----- Original Message ----- > > > > From: "Rodrigo Sasaki" > > > > To: keycloak-user at lists.jboss.org > > > > Sent: Wednesday, 5 November, 2014 3:10:55 PM > > > > Subject: [keycloak-user] Profile Picture > > > > > > > > I was going to look at Jira but it seems to be out for maintenance, > so I > > > just > > > > have a quick question. > > > > > > > > Is there already a feature request to add a profile image to the > Keycloak > > > > User? > > > > > > > > Thanks! > > > > > > > > -- > > > > Rodrigo Sasaki > > > > > > > > _______________________________________________ > > > > keycloak-user mailing list > > > > keycloak-user at lists.jboss.org > > > > https://lists.jboss.org/mailman/listinfo/keycloak-user > > > > > > > > > > > -- > > Rodrigo Sasaki > > > -- Rodrigo Sasaki -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20141105/69649b3d/attachment.html From alarik at zwift.com Wed Nov 5 15:25:01 2014 From: alarik at zwift.com (Alarik Myrin) Date: Wed, 5 Nov 2014 15:25:01 -0500 Subject: [keycloak-user] Changing passwords and current sessions Message-ID: Should changing a password invalidate current sessions, or at least the refresh tokens? Or would a user have to change the password AND log out current sessions to invalidate the current sessions and refresh tokens? To me it seems like the latter is the current behavior, I just wanted to make sure that it is desirable. Thanks, Alarik -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20141105/ed4a5102/attachment.html From pmadden at tomsawyer.com Wed Nov 5 18:52:03 2014 From: pmadden at tomsawyer.com (Patrick V. Madden) Date: Wed, 5 Nov 2014 15:52:03 -0800 (PST) Subject: [keycloak-user] Active Directory Realm question. In-Reply-To: <107924057.303303.1415231510077.JavaMail.zimbra@tomsawyer.com> References: <321656197.260447.1415109489708.JavaMail.zimbra@tomsawyer.com> <54592FE7.7070306@redhat.com> <1450514170.275689.1415137120910.JavaMail.zimbra@tomsawyer.com> <545A4E56.2090207@redhat.com> Message-ID: <1871686176.303307.1415231523634.JavaMail.zimbra@tomsawyer.com> Thanks Marek, Much appreciated. One more note that is not critical but perhaps relevant. Even without those Object Classes defined, the synchronize all users result showed success. Now perhaps that means there was no error. Not sure how you want to handle that but perhaps should check for at least one result? Thanks again. Patrick Madden Principal Design Engineer Tom Sawyer Software 1997 El Dorado Avenue Berkeley, CA 94707 Cell: +1 (845) 416-4629 E-mail: pmadden@ tomsawyer.com From: "Marek Posolda" To: "Patrick V. Madden" Cc: "keycloack-users" Sent: Wednesday, November 5, 2014 10:20:38 AM Subject: Re: [keycloak-user] Active Directory Realm question. yes, it makes sense to have Object classes mandatory in UI. I've fixed it (also change the tooltip), will be available in next version. Thanks! Marek On 4.11.2014 22:38, Patrick V. Madden wrote: Hi Marek, Wow! I was about to give up and then I decided to try to enter information into the field for User Object Classes. I was leaving that blank as it shows not required and tip seems to indicate it is for creating LDAP users via KeyCloak. I noticed in my LDAP Browser that among many others, it had 4 rows named objectClass as follows: Attribute Name Value objectClass top objectClass person objectClass organizationalPerson objectClass user Once I added these as "top,person,organizationalPerson,user" into User Object Classes field in LDAP Provider Settings it worked!!!! I was literally writing a response to say nope can't get it to work. Divine intervention made me try one more thing. This may be helpful to others. Thanks for your help. Patrick From: "Marek Posolda" To: "Patrick V. Madden" , "keycloack-users" Sent: Tuesday, November 4, 2014 1:58:31 PM Subject: Re: [keycloak-user] Active Directory Realm question. Hi, after "Synchronize all users" you should be able to see all users from LDAP, not just those which already authenticated in Keycloak. For your LDAP tree, I believe that Base DN should be "DC=acme,DC=com" and User DN should be "OU=acmeUsers,DC=acme,DC=com" . Please let me know if it helps. Marek On 4.11.2014 14:58, Patrick V. Madden wrote: BQ_BEGIN Hi, Hope this doesn't post twice.... I am running a local 1.0.4.Final build on my local machine to do some testing. I have a quick question regarding an Active Directory Realm that I am trying to configure. I am able to successfully test the connection and test authentication using Bind DN and Bind Credential and Connection URL. I can connect via an external LDAP browser using same credential and browse the directory. When I click Synchronize all users button it says it is successful. However, when I go back to search page I get nothing when I enter a username. When I click show all users it shows nothing. I was hoping it would show me a list of all users in the search tree based on my settings. Lets assume my company is acme.com. When I look at browser it shows: RootDSE +---DC=acme,DC=com +---OU=acmeUsers +---CN=John Doe ---CN=Jane Doe ---CN=Joe Blow I want the users to be in OU=acmeUsers,DC=acme,DC=com And yes OU=acmeUsers is what I need... So what would I put in for Base DN and User DN Suffix to get it to show a list of all users in the directory? Or does it only show users that have logged into the Realm via a web app? Hope this makes sense. Regards, Patrick Madden Principal Design Engineer Tom Sawyer Software 1997 El Dorado Avenue Berkeley, CA 94707 Cell: +1 (845) 416-4629 E-mail: pmadden@ tomsawyer.com _______________________________________________ keycloak-user mailing list keycloak-user at lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-user BQ_END -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20141105/e3c554ef/attachment-0001.html From stian at redhat.com Thu Nov 6 03:34:31 2014 From: stian at redhat.com (Stian Thorgersen) Date: Thu, 6 Nov 2014 03:34:31 -0500 (EST) Subject: [keycloak-user] Changing passwords and current sessions In-Reply-To: References: Message-ID: <527552794.8882781.1415262871920.JavaMail.zimbra@redhat.com> IMO the current behaviour is the correct and I can't see any reason to log out a user after changing the password. ----- Original Message ----- > From: "Alarik Myrin" > To: keycloak-user at lists.jboss.org > Sent: Wednesday, 5 November, 2014 9:25:01 PM > Subject: [keycloak-user] Changing passwords and current sessions > > Should changing a password invalidate current sessions, or at least the > refresh tokens? Or would a user have to change the password AND log out > current sessions to invalidate the current sessions and refresh tokens? To > me it seems like the latter is the current behavior, I just wanted to make > sure that it is desirable. > > Thanks, > > Alarik > > > _______________________________________________ > keycloak-user mailing list > keycloak-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user From alarik at zwift.com Thu Nov 6 06:46:28 2014 From: alarik at zwift.com (Alarik Myrin) Date: Thu, 6 Nov 2014 06:46:28 -0500 Subject: [keycloak-user] Changing passwords and current sessions In-Reply-To: <527552794.8882781.1415262871920.JavaMail.zimbra@redhat.com> References: <527552794.8882781.1415262871920.JavaMail.zimbra@redhat.com> Message-ID: I feel like maybe this should be a realm setting. Let's say I am a user who lost my smart phone or my laptop. I think to myself -- I should probably go and change my passwords, which I do, expecting that I am now protected. But it is a false sense of security, because the old sessions remain valid until they time out in one way or another. If your users are consumers (which mine are) and not enterprise users, it is a lot to have to educate each of them on the idea that in addition to changing their password they have to go in to the account management application and log out their sessions. On Thu, Nov 6, 2014 at 3:34 AM, Stian Thorgersen wrote: > IMO the current behaviour is the correct and I can't see any reason to log > out a user after changing the password. > > ----- Original Message ----- > > From: "Alarik Myrin" > > To: keycloak-user at lists.jboss.org > > Sent: Wednesday, 5 November, 2014 9:25:01 PM > > Subject: [keycloak-user] Changing passwords and current sessions > > > > Should changing a password invalidate current sessions, or at least the > > refresh tokens? Or would a user have to change the password AND log out > > current sessions to invalidate the current sessions and refresh tokens? > To > > me it seems like the latter is the current behavior, I just wanted to > make > > sure that it is desirable. > > > > Thanks, > > > > Alarik > > > > > > _______________________________________________ > > 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-user/attachments/20141106/921581d8/attachment.html From stian at redhat.com Thu Nov 6 06:57:03 2014 From: stian at redhat.com (Stian Thorgersen) Date: Thu, 6 Nov 2014 06:57:03 -0500 (EST) Subject: [keycloak-user] Changing passwords and current sessions In-Reply-To: References: <527552794.8882781.1415262871920.JavaMail.zimbra@redhat.com> Message-ID: <1736065735.8991515.1415275023591.JavaMail.zimbra@redhat.com> Ah, that makes sense. I was only considering the session the user was changing the password through. You're absolutely right it makes perfect sense to log out the user. Can you create a jira for please? ----- Original Message ----- > From: "Alarik Myrin" > To: "Stian Thorgersen" > Cc: keycloak-user at lists.jboss.org > Sent: Thursday, 6 November, 2014 12:46:28 PM > Subject: Re: [keycloak-user] Changing passwords and current sessions > > I feel like maybe this should be a realm setting. > > Let's say I am a user who lost my smart phone or my laptop. I think to > myself -- I should probably go and change my passwords, which I do, > expecting that I am now protected. But it is a false sense of security, > because the old sessions remain valid until they time out in one way or > another. If your users are consumers (which mine are) and not enterprise > users, it is a lot to have to educate each of them on the idea that in > addition to changing their password they have to go in to the account > management application and log out their sessions. > > On Thu, Nov 6, 2014 at 3:34 AM, Stian Thorgersen wrote: > > > IMO the current behaviour is the correct and I can't see any reason to log > > out a user after changing the password. > > > > ----- Original Message ----- > > > From: "Alarik Myrin" > > > To: keycloak-user at lists.jboss.org > > > Sent: Wednesday, 5 November, 2014 9:25:01 PM > > > Subject: [keycloak-user] Changing passwords and current sessions > > > > > > Should changing a password invalidate current sessions, or at least the > > > refresh tokens? Or would a user have to change the password AND log out > > > current sessions to invalidate the current sessions and refresh tokens? > > To > > > me it seems like the latter is the current behavior, I just wanted to > > make > > > sure that it is desirable. > > > > > > Thanks, > > > > > > Alarik > > > > > > > > > _______________________________________________ > > > keycloak-user mailing list > > > keycloak-user at lists.jboss.org > > > https://lists.jboss.org/mailman/listinfo/keycloak-user > > > From alarik at zwift.com Thu Nov 6 07:11:50 2014 From: alarik at zwift.com (Alarik Myrin) Date: Thu, 6 Nov 2014 07:11:50 -0500 Subject: [keycloak-user] Changing passwords and current sessions In-Reply-To: <1736065735.8991515.1415275023591.JavaMail.zimbra@redhat.com> References: <527552794.8882781.1415262871920.JavaMail.zimbra@redhat.com> <1736065735.8991515.1415275023591.JavaMail.zimbra@redhat.com> Message-ID: Sure thing. [KEYCLOAK-825] On Thu, Nov 6, 2014 at 6:57 AM, Stian Thorgersen wrote: > Ah, that makes sense. I was only considering the session the user was > changing the password through. > > You're absolutely right it makes perfect sense to log out the user. Can > you create a jira for please? > > ----- Original Message ----- > > From: "Alarik Myrin" > > To: "Stian Thorgersen" > > Cc: keycloak-user at lists.jboss.org > > Sent: Thursday, 6 November, 2014 12:46:28 PM > > Subject: Re: [keycloak-user] Changing passwords and current sessions > > > > I feel like maybe this should be a realm setting. > > > > Let's say I am a user who lost my smart phone or my laptop. I think to > > myself -- I should probably go and change my passwords, which I do, > > expecting that I am now protected. But it is a false sense of security, > > because the old sessions remain valid until they time out in one way or > > another. If your users are consumers (which mine are) and not enterprise > > users, it is a lot to have to educate each of them on the idea that in > > addition to changing their password they have to go in to the account > > management application and log out their sessions. > > > > On Thu, Nov 6, 2014 at 3:34 AM, Stian Thorgersen > wrote: > > > > > IMO the current behaviour is the correct and I can't see any reason to > log > > > out a user after changing the password. > > > > > > ----- Original Message ----- > > > > From: "Alarik Myrin" > > > > To: keycloak-user at lists.jboss.org > > > > Sent: Wednesday, 5 November, 2014 9:25:01 PM > > > > Subject: [keycloak-user] Changing passwords and current sessions > > > > > > > > Should changing a password invalidate current sessions, or at least > the > > > > refresh tokens? Or would a user have to change the password AND log > out > > > > current sessions to invalidate the current sessions and refresh > tokens? > > > To > > > > me it seems like the latter is the current behavior, I just wanted to > > > make > > > > sure that it is desirable. > > > > > > > > Thanks, > > > > > > > > Alarik > > > > > > > > > > > > _______________________________________________ > > > > 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-user/attachments/20141106/6927c800/attachment.html From mposolda at redhat.com Thu Nov 6 07:28:18 2014 From: mposolda at redhat.com (Marek Posolda) Date: Thu, 06 Nov 2014 13:28:18 +0100 Subject: [keycloak-user] Active Directory Realm question. In-Reply-To: <1871686176.303307.1415231523634.JavaMail.zimbra@tomsawyer.com> References: <321656197.260447.1415109489708.JavaMail.zimbra@tomsawyer.com> <54592FE7.7070306@redhat.com> <1450514170.275689.1415137120910.JavaMail.zimbra@tomsawyer.com> <545A4E56.2090207@redhat.com> <1871686176.303307.1415231523634.JavaMail.zimbra@tomsawyer.com> Message-ID: <545B6962.9030104@redhat.com> Maybe admin console can display count of inserted and updated users during sync. So it will display some message like: "Sync successful! 34 users imported from LDAP and 12 users updated from LDAP during synchronization" What do you think? I've created JIRA for that https://issues.jboss.org/browse/KEYCLOAK-826 . Marek On 6.11.2014 00:52, Patrick V. Madden wrote: > Thanks Marek, > > Much appreciated. One more note that is not critical but perhaps > relevant. Even without those Object Classes defined, the synchronize > all users result showed success. Now perhaps that means there was no > error. Not sure how you want to handle that but perhaps should check > for at least one result? > > Thanks again. > > *Patrick Madden* > Principal Design Engineer > *Tom Sawyer Software * > 1997 El Dorado Avenue > Berkeley, CA 94707 > > Cell: +1 (845) 416-4629 > E-mail: pmadden at tomsawyer.com > > > > ------------------------------------------------------------------------ > *From: *"Marek Posolda" > *To: *"Patrick V. Madden" > *Cc: *"keycloack-users" > *Sent: *Wednesday, November 5, 2014 10:20:38 AM > *Subject: *Re: [keycloak-user] Active Directory Realm question. > > yes, it makes sense to have Object classes mandatory in UI. I've fixed > it (also change the tooltip), will be available in next version. > > Thanks! > Marek > > On 4.11.2014 22:38, Patrick V. Madden wrote: > > Hi Marek, > > Wow! I was about to give up and then I decided to try to enter > information into the field for User Object Classes. I was leaving > that blank as it shows not required and tip seems to indicate it > is for creating LDAP users via KeyCloak. I noticed in my LDAP > Browser that among many others, it had 4 rows named objectClass as > follows: > > Attribute Name Value > objectClass top > objectClass person > objectClass organizationalPerson > objectClass user > > Once I added these as "top,person,organizationalPerson,user" into > User Object Classes field in LDAP Provider Settings it worked!!!! > > I was literally writing a response to say nope can't get it to > work. Divine intervention made me try one more thing. > > This may be helpful to others. > > Thanks for your help. > > Patrick > > ------------------------------------------------------------------------ > *From: *"Marek Posolda" > *To: *"Patrick V. Madden" , > "keycloack-users" > *Sent: *Tuesday, November 4, 2014 1:58:31 PM > *Subject: *Re: [keycloak-user] Active Directory Realm question. > > Hi, > > after "Synchronize all users" you should be able to see all users > from LDAP, not just those which already authenticated in Keycloak. > For your LDAP tree, I believe that Base DN should be > "DC=acme,DC=com" and User DN should be > "OU=acmeUsers,DC=acme,DC=com" . Please let me know if it helps. > > Marek > > On 4.11.2014 14:58, Patrick V. Madden wrote: > > Hi, > > Hope this doesn't post twice.... > > I am running a local 1.0.4.Final build on my local machine to > do some testing. > > I have a quick question regarding an Active Directory Realm > that I am trying to configure. I am able to successfully test > the connection and test authentication using Bind DN and Bind > Credential and Connection URL. > > I can connect via an external LDAP browser using same > credential and browse the directory. > > When I click Synchronize all users button it says it is > successful. However, when I go back to search page I get > nothing when I enter a username. When I click show all users > it shows nothing. I was hoping it would show me a list of all > users in the search tree based on my settings. > > Lets assume my company is acme.com. When I look at browser it > shows: > > RootDSE > +---DC=acme,DC=com > +---OU=acmeUsers > +---CN=John Doe > ---CN=Jane Doe > ---CN=Joe Blow > > I want the users to be in OU=acmeUsers,DC=acme,DC=com > > And yes OU=acmeUsers is what I need... > > So what would I put in for Base DN and User DN Suffix to get > it to show a list of all users in the directory? > > Or does it only show users that have logged into the Realm via > a web app? > > Hope this makes sense. > > Regards, > > *Patrick Madden* > Principal Design Engineer > *Tom Sawyer Software * > 1997 El Dorado Avenue > > Berkeley, CA 94707 > > > > Cell: +1 (845) 416-4629 > E-mail: pmadden at tomsawyer.com > > > > > _______________________________________________ > 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-user/attachments/20141106/03ae8fa6/attachment-0001.html From gbrown at redhat.com Fri Nov 7 09:16:40 2014 From: gbrown at redhat.com (Gary Brown) Date: Fri, 7 Nov 2014 09:16:40 -0500 (EST) Subject: [keycloak-user] Recommendations for protecting REST service with bearer token and basic auth In-Reply-To: <1248231564.5946709.1415369533614.JavaMail.zimbra@redhat.com> Message-ID: <1845864658.5951344.1415369800735.JavaMail.zimbra@redhat.com> Hi I've just started looking at KeyCloak to use with the Overlord governance projects. I have tried the examples, and see how we could leverage KeyCloak to protect the UI apps and the backend REST services they use. However we also need to provide the REST services as independent services using basic auth - but would like the basic auth to be performed against the users managed by KeyCloak. Is there any recommendations on how this can be achieved? Do we need to provide our own filter - is there any example code to do this? Is it possible to do something via the KeyCloak subsystem configuration approach, in case we wanted to secure the REST service without modifying the war? Thanks in advance. Regards Gary From gbrown at redhat.com Fri Nov 7 09:21:31 2014 From: gbrown at redhat.com (Gary Brown) Date: Fri, 7 Nov 2014 09:21:31 -0500 (EST) Subject: [keycloak-user] Users spanning across realms In-Reply-To: <1415395703.5951558.1415369843944.JavaMail.zimbra@redhat.com> Message-ID: <294777204.5956823.1415370091787.JavaMail.zimbra@redhat.com> Hi As mentioned in previous post, I'm looking at how to leverage KeyCloak within the Overlord governance projects. I can see how our web UIs and REST services could be defined within a single realm, with the appropriate roles, users and user/role mappings. However if we wanted to build some apps that made use of other JBoss projects, that also used KeyCloak, but with their own realms, then how would a user be defined to use our app that may at the backend need to call services provided by other projects/realms? Wondering whether the user concept needs to be defined outside of a realm, so that it could be assigned roles within a number of realms, allowing them to access the various apps in those different domains? More of a conceptual discussion, rather than an actual problem at this stage - was more curious how it could work, as not a security expert. Regards Gary From bburke at redhat.com Fri Nov 7 16:02:57 2014 From: bburke at redhat.com (Bill Burke) Date: Fri, 07 Nov 2014 16:02:57 -0500 Subject: [keycloak-user] Users spanning across realms In-Reply-To: <294777204.5956823.1415370091787.JavaMail.zimbra@redhat.com> References: <294777204.5956823.1415370091787.JavaMail.zimbra@redhat.com> Message-ID: <545D3381.8030000@redhat.com> Have one realm. Have multiple applications, each defining their own role set. On 11/7/2014 9:21 AM, Gary Brown wrote: > Hi > > As mentioned in previous post, I'm looking at how to leverage KeyCloak within the Overlord governance projects. > > I can see how our web UIs and REST services could be defined within a single realm, with the appropriate roles, users and user/role mappings. However if we wanted to build some apps that made use of other JBoss projects, that also used KeyCloak, but with their own realms, then how would a user be defined to use our app that may at the backend need to call services provided by other projects/realms? > > Wondering whether the user concept needs to be defined outside of a realm, so that it could be assigned roles within a number of realms, allowing them to access the various apps in those different domains? > > More of a conceptual discussion, rather than an actual problem at this stage - was more curious how it could work, as not a security expert. > > Regards > Gary > _______________________________________________ > keycloak-user mailing list > keycloak-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user > -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From prabhalar at yahoo.com Fri Nov 7 16:46:19 2014 From: prabhalar at yahoo.com (Raghuram) Date: Fri, 7 Nov 2014 16:46:19 -0500 Subject: [keycloak-user] Api for adding roles to users Message-ID: <20C30AC1-B2EF-49C8-8B01-054016AE20C7@yahoo.com> How do we add users to the default roles? I am using the key cloak federation api to do custom authentication for a realm. Noticed that the users are not able to login to the application after being authenticated unless roles are added manually to them. Wondering if the roles can be added within the federation provider code after authenticating the users? Sent from my iPhone From bburke at redhat.com Fri Nov 7 21:18:29 2014 From: bburke at redhat.com (Bill Burke) Date: Fri, 07 Nov 2014 21:18:29 -0500 Subject: [keycloak-user] Recommendations for protecting REST service with bearer token and basic auth In-Reply-To: <1845864658.5951344.1415369800735.JavaMail.zimbra@redhat.com> References: <1845864658.5951344.1415369800735.JavaMail.zimbra@redhat.com> Message-ID: <545D7D75.8050500@redhat.com> If you are using Keycloak, I don't understand why you would want to do basic auth. Eventually I'm going to write a JAAS plugin for simple username/password with Keycloak, but I have other stuff in my queue at the moment. For your application, you'd have to write something that obtained a admin token and verified username password and downloaded role mappings. On 11/7/2014 9:16 AM, Gary Brown wrote: > Hi > > I've just started looking at KeyCloak to use with the Overlord governance projects. > > I have tried the examples, and see how we could leverage KeyCloak to protect the UI apps and the backend REST services they use. However we also need to provide the REST services as independent services using basic auth - but would like the basic auth to be performed against the users managed by KeyCloak. > > Is there any recommendations on how this can be achieved? > > Do we need to provide our own filter - is there any example code to do this? > > Is it possible to do something via the KeyCloak subsystem configuration approach, in case we wanted to secure the REST service without modifying the war? > > Thanks in advance. > > Regards > Gary > _______________________________________________ > keycloak-user mailing list > keycloak-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user > -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From bburke at redhat.com Fri Nov 7 21:22:20 2014 From: bburke at redhat.com (Bill Burke) Date: Fri, 07 Nov 2014 21:22:20 -0500 Subject: [keycloak-user] Api for adding roles to users In-Reply-To: <20C30AC1-B2EF-49C8-8B01-054016AE20C7@yahoo.com> References: <20C30AC1-B2EF-49C8-8B01-054016AE20C7@yahoo.com> Message-ID: <545D7E5C.7000108@redhat.com> Are you writing a custom federation adapter? Two options: * Define default roles within the admin console. When your user is imported into a UserModel, the default roles will be added * Extract role mappings from your external store, and populate the user model with them when you import the user into the keycloak database. On 11/7/2014 4:46 PM, Raghuram wrote: > How do we add users to the default roles? I am using the key cloak federation api to do custom authentication for a realm. Noticed that the users are not able to login to the application after being authenticated unless roles are added manually to them. Wondering if the roles can be added within the federation provider code after authenticating the users? > > Sent from my iPhone > _______________________________________________ > keycloak-user mailing list > keycloak-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user > -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From prabhalar at yahoo.com Fri Nov 7 22:09:26 2014 From: prabhalar at yahoo.com (prab rrrr) Date: Sat, 8 Nov 2014 03:09:26 +0000 (UTC) Subject: [keycloak-user] Api for adding roles to users In-Reply-To: <545D7E5C.7000108@redhat.com> References: <545D7E5C.7000108@redhat.com> Message-ID: <1111890366.379948.1415416166970.JavaMail.yahoo@jws100205.mail.ne1.yahoo.com> Hi Bill - Yes, I am using custom federation adapter and could authenticate users successfully.?Will try out your suggestions.?Thanks. One observation though in the 1.1 Beta1 version-?Based on debugging comments, it appears that for each authentication attempt, the below methods in Federation Provider are called multiple times (10 or 12?times) 1) proxy2) isValid3) getInstance (in Federation Factory) Thanks once again.Raghu ? From: Bill Burke To: keycloak-user at lists.jboss.org Sent: Friday, November 7, 2014 9:22 PM Subject: Re: [keycloak-user] Api for adding roles to users Are you writing a custom federation adapter?? Two options: * Define default roles within the admin console.? When your user is imported into a UserModel, the default roles will be added * Extract role mappings from your external store, and populate the user model with them when you import the user into the keycloak database. On 11/7/2014 4:46 PM, Raghuram wrote: > How do we add users to the default roles? I am using the key cloak federation api to do custom authentication for a realm. Noticed that the users are not able to login to the application after being authenticated unless roles are added manually to them. Wondering if the roles can be added within the federation provider code after authenticating the users? > > Sent from my iPhone > _______________________________________________ > keycloak-user mailing list > keycloak-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user > -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com _______________________________________________ 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-user/attachments/20141108/fda2b2e6/attachment.html From gbrown at redhat.com Mon Nov 10 03:20:41 2014 From: gbrown at redhat.com (Gary Brown) Date: Mon, 10 Nov 2014 03:20:41 -0500 (EST) Subject: [keycloak-user] Recommendations for protecting REST service with bearer token and basic auth In-Reply-To: <545D7D75.8050500@redhat.com> References: <1845864658.5951344.1415369800735.JavaMail.zimbra@redhat.com> <545D7D75.8050500@redhat.com> Message-ID: <279836542.6533747.1415607641136.JavaMail.zimbra@redhat.com> Currently its for backward compatibility, maintaining the same simple authentication approach for existing clients using the REST services. However basic auth is a standard (and simple) approach, so I could see some cases where it would be preferred by app developers rather than accessing a keycloak specific service to obtain a token. One relevant case would be API management - if a backend service was protected by keycloak, I believe it would require a specific authentication module to obtain a token per request (unless the token could be cached somewhere). So I think having the basic auth support will provide flexibility. Regards Gary ----- Original Message ----- > If you are using Keycloak, I don't understand why you would want to do > basic auth. > > Eventually I'm going to write a JAAS plugin for simple username/password > with Keycloak, but I have other stuff in my queue at the moment. For > your application, you'd have to write something that obtained a admin > token and verified username password and downloaded role mappings. > > On 11/7/2014 9:16 AM, Gary Brown wrote: > > Hi > > > > I've just started looking at KeyCloak to use with the Overlord governance > > projects. > > > > I have tried the examples, and see how we could leverage KeyCloak to > > protect the UI apps and the backend REST services they use. However we > > also need to provide the REST services as independent services using basic > > auth - but would like the basic auth to be performed against the users > > managed by KeyCloak. > > > > Is there any recommendations on how this can be achieved? > > > > Do we need to provide our own filter - is there any example code to do > > this? > > > > Is it possible to do something via the KeyCloak subsystem configuration > > approach, in case we wanted to secure the REST service without modifying > > the war? > > > > Thanks in advance. > > > > Regards > > Gary > > _______________________________________________ > > keycloak-user mailing list > > keycloak-user at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/keycloak-user > > > > -- > Bill Burke > JBoss, a division of Red Hat > http://bill.burkecentral.com > _______________________________________________ > keycloak-user mailing list > keycloak-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user > From bburke at redhat.com Mon Nov 10 08:38:35 2014 From: bburke at redhat.com (Bill Burke) Date: Mon, 10 Nov 2014 08:38:35 -0500 Subject: [keycloak-user] Recommendations for protecting REST service with bearer token and basic auth In-Reply-To: <279836542.6533747.1415607641136.JavaMail.zimbra@redhat.com> References: <1845864658.5951344.1415369800735.JavaMail.zimbra@redhat.com> <545D7D75.8050500@redhat.com> <279836542.6533747.1415607641136.JavaMail.zimbra@redhat.com> Message-ID: <5460BFDB.1060606@redhat.com> With basic auth, you have zero control over the client and you're handing over credentials to that client. Simple and easy for "hello world" apps sure. On 11/10/2014 3:20 AM, Gary Brown wrote: > Currently its for backward compatibility, maintaining the same simple authentication approach for existing clients using the REST services. > > However basic auth is a standard (and simple) approach, so I could see some cases where it would be preferred by app developers rather than accessing a keycloak specific service to obtain a token. One relevant case would be API management - if a backend service was protected by keycloak, I believe it would require a specific authentication module to obtain a token per request (unless the token could be cached somewhere). > > So I think having the basic auth support will provide flexibility. > > Regards > Gary > > ----- Original Message ----- >> If you are using Keycloak, I don't understand why you would want to do >> basic auth. >> >> Eventually I'm going to write a JAAS plugin for simple username/password >> with Keycloak, but I have other stuff in my queue at the moment. For >> your application, you'd have to write something that obtained a admin >> token and verified username password and downloaded role mappings. >> >> On 11/7/2014 9:16 AM, Gary Brown wrote: >>> Hi >>> >>> I've just started looking at KeyCloak to use with the Overlord governance >>> projects. >>> >>> I have tried the examples, and see how we could leverage KeyCloak to >>> protect the UI apps and the backend REST services they use. However we >>> also need to provide the REST services as independent services using basic >>> auth - but would like the basic auth to be performed against the users >>> managed by KeyCloak. >>> >>> Is there any recommendations on how this can be achieved? >>> >>> Do we need to provide our own filter - is there any example code to do >>> this? >>> >>> Is it possible to do something via the KeyCloak subsystem configuration >>> approach, in case we wanted to secure the REST service without modifying >>> the war? >>> >>> Thanks in advance. >>> >>> Regards >>> Gary >>> _______________________________________________ >>> keycloak-user mailing list >>> keycloak-user at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/keycloak-user >>> >> >> -- >> Bill Burke >> JBoss, a division of Red Hat >> http://bill.burkecentral.com >> _______________________________________________ >> keycloak-user mailing list >> keycloak-user at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-user >> -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From ungarida at gmail.com Mon Nov 10 09:48:49 2014 From: ungarida at gmail.com (Davide Ungari) Date: Mon, 10 Nov 2014 15:48:49 +0100 Subject: [keycloak-user] Bearer Only Application and refresh token Message-ID: Hi, following some of your suggestions I designed an application composed of a: 1- frontend web application 2- backend REST API The frontend has a servlet-proxy to the backend REST API to avoid cross domain problems. The backend has a bearer-only configuration. Everything is working until the token does not expire, I tried to force refresh when I recieve 401 status but it does not work. What is supposed to be done every time the access tokes expires? -- Davide -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20141110/2a5fad20/attachment.html From bburke at redhat.com Mon Nov 10 10:51:32 2014 From: bburke at redhat.com (Bill Burke) Date: Mon, 10 Nov 2014 10:51:32 -0500 Subject: [keycloak-user] Bearer Only Application and refresh token In-Reply-To: References: Message-ID: <5460DF04.3010301@redhat.com> On 11/10/2014 9:48 AM, Davide Ungari wrote: > Hi, > following some of your suggestions I designed an application composed of a: > 1- frontend web application > 2- backend REST API > What is your frontend web app? Javascript (GWT or Angular JS or jQuery)? > The frontend has a servlet-proxy to the backend REST API to avoid cross > domain problems. > Take a look at the CORS spec and also Keycloak's support for it. You don't need a servlet proxy. > The backend has a bearer-only configuration. > > > Everything is working until the token does not expire, I tried to force > refresh when I recieve 401 status but it does not work. > Do you mean everything works until the token expires? > What is supposed to be done every time the access tokes expires? > Whoever obtained the access token is responsible for refreshing it. If your web application is a Javascript app, then you can use the keycloak.js library which will handle refreshing tokens. Combine this with CORS if you need to invoke backend REST services that are on another domain. There's a few examples in the distro that show how to do this. -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From alarik at zwift.com Mon Nov 10 19:52:21 2014 From: alarik at zwift.com (Alarik Myrin) Date: Mon, 10 Nov 2014 19:52:21 -0500 Subject: [keycloak-user] Persistent sessions Message-ID: When upgrading keycloak, I recently faced the problem that the upgrade would essentially invalidate all the current user sessions. Has anyone had any luck with using the tag in the wildfly Undertow web subsystem to try and have user sessions survive a server restart? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20141110/6db321f4/attachment.html From mposolda at redhat.com Tue Nov 11 05:31:55 2014 From: mposolda at redhat.com (Marek Posolda) Date: Tue, 11 Nov 2014 11:31:55 +0100 Subject: [keycloak-user] Persistent sessions In-Reply-To: References: Message-ID: <5461E59B.80001@redhat.com> There are 2 things here. Adding "persistent-sessions" is needed to ensure that HTTP sessions of the applications, which are secured by Keycloak, will remain persistent. But Keycloak auth-server itself doesn't rely on Http sessions. So you also need to switch UserSession provider in keycloak-server.json to either 'jpa' or 'mongo' . Default provider is 'mem', which stores UserSessions just in memory and this doesn't support server restarts. With JPA or Mongo, UserSessions will be persistent, on the other hand there is performance penalty as each login,logout or refresh token will need to load and save user sessions data in DB. From 1.1.X there is also infinispan UserSession provider, which is not persistent by default, but you can use some infinispan addons (CacheStores/CacheLoaders) to ensure data are persistent. Also note that upgrade from 1.0.X to 1.1.X will also drop existing UserSessions even if you have 'jpa' or 'mongo' as there is some change in format of UserSessions. But upgrade between minor versions (like from 1.0.3 to 1.0.4) will probably work for you. Marek On 11.11.2014 01:52, Alarik Myrin wrote: > When upgrading keycloak, I recently faced the problem that the upgrade > would essentially invalidate all the current user sessions. Has anyone > had any luck with using the tag in the wildfly > Undertow web subsystem to try and have user sessions survive a server > restart? > > > > _______________________________________________ > 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-user/attachments/20141111/4166fd82/attachment.html From mposolda at redhat.com Tue Nov 11 10:21:55 2014 From: mposolda at redhat.com (Marek Posolda) Date: Tue, 11 Nov 2014 16:21:55 +0100 Subject: [keycloak-user] Api for adding roles to users In-Reply-To: <1111890366.379948.1415416166970.JavaMail.yahoo@jws100205.mail.ne1.yahoo.com> References: <545D7E5C.7000108@redhat.com> <1111890366.379948.1415416166970.JavaMail.yahoo@jws100205.mail.ne1.yahoo.com> Message-ID: <54622993.4080509@redhat.com> Hi, I agree that performance of LDAP (and UserFederationProvider in general) have some space for improvements. I've created JIRA for it: https://issues.jboss.org/browse/KEYCLOAK-838 . Feel free to add more points. Marek On 8.11.2014 04:09, prab rrrr wrote: > Hi Bill - Yes, I am using custom federation adapter and could > authenticate users successfully. Will try out your suggestions. Thanks. > > One observation though in the 1.1 Beta1 version- Based on debugging > comments, it appears that for each authentication attempt, the below > methods in Federation Provider are called multiple times (10 or 12 times) > > 1) proxy > 2) isValid > 3) getInstance (in Federation Factory) > > Thanks once again. > Raghu > > ------------------------------------------------------------------------ > *From:* Bill Burke > *To:* keycloak-user at lists.jboss.org > *Sent:* Friday, November 7, 2014 9:22 PM > *Subject:* Re: [keycloak-user] Api for adding roles to users > > Are you writing a custom federation adapter? Two options: > > * Define default roles within the admin console. When your user is > imported into a UserModel, the default roles will be added > * Extract role mappings from your external store, and populate the user > model with them when you import the user into the keycloak database. > > > > On 11/7/2014 4:46 PM, Raghuram wrote: > > How do we add users to the default roles? I am using the key cloak > federation api to do custom authentication for a realm. Noticed that > the users are not able to login to the application after being > authenticated unless roles are added manually to them. Wondering if > the roles can be added within the federation provider code after > authenticating the users? > > > > Sent from my iPhone > > > _______________________________________________ > > keycloak-user mailing list > > keycloak-user at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/keycloak-user > > > > -- > Bill Burke > JBoss, a division of Red Hat > http://bill.burkecentral.com > _______________________________________________ > keycloak-user mailing list > keycloak-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user > > > > > > _______________________________________________ > 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-user/attachments/20141111/7fd2da5d/attachment-0001.html From Richard.Rattigan at sonos.com Tue Nov 11 19:50:40 2014 From: Richard.Rattigan at sonos.com (Richard Rattigan) Date: Wed, 12 Nov 2014 00:50:40 +0000 Subject: [keycloak-user] JWT signature verification failure Message-ID: I'm trying to verify keycloak jwt signatures in a Java/Groovy, but I'm not succeeding. I'm new to crypto, so maybe I'm doing something stupid. This is Groovy code. realmPublicKey is the publicKey string from the realm REST response. I'm using the jjwt library to parse the tokens, but I get the same result (signature verification failure) with the nimbus library: Security.addProvider(new BouncyCastleProvider()) def publicKey = KeyFactory .getInstance("RSA", "BC") .generatePublic(new X509EncodedKeySpec(realmPublicKey.decodeBase64())) def claims = Jwts.parser().setSigningKey(publicKey).parse(accessToken) I get an exception during the parse: io.jsonwebtoken.SignatureException: JWT signature does not match locally computed signature. JWT validity cannot be asserted and should not be trusted. Is anyone able to see what I'm doing wrong here? Richard Rattigan Sonos | Sr. Software Engineer | Skype: Richard.RattiganSonos -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20141112/a9b07a34/attachment.html From bburke at redhat.com Tue Nov 11 20:55:26 2014 From: bburke at redhat.com (Bill Burke) Date: Tue, 11 Nov 2014 20:55:26 -0500 Subject: [keycloak-user] JWT signature verification failure In-Reply-To: References: Message-ID: <5462BE0E.9000201@redhat.com> Looking at jjwt, they do this algorithm: sign(base64enocdedheader + "." + bsase64encodedContent) We just sign the content. Just verified that our impl is wrong. I'll fix this for next release. On 11/11/2014 7:50 PM, Richard Rattigan wrote: > I?m trying to verify keycloak jwt signatures in a Java/Groovy, but I?m > not succeeding. I?m new to crypto, so maybe I?m doing something stupid. > > This is Groovy code. realmPublicKey is the publicKey string from the > realm REST response. I?m using the jjwt library to parse the tokens, but > I get the same result (signature verification failure) with the nimbus > library: > > Security.addProvider(new BouncyCastleProvider()) > def publicKey = KeyFactory > .getInstance("RSA", "BC") > .generatePublic(new > X509EncodedKeySpec(realmPublicKey.decodeBase64())) > def claims = Jwts.parser().setSigningKey(publicKey).parse(accessToken) > > I get an exception during the parse: > > io.jsonwebtoken.SignatureException: JWT signature does not match locally > computed signature. JWT validity cannot be asserted and should not be > trusted. > > Is anyone able to see what I?m doing wrong here? > > *Richard Rattigan* > > Sonos | Sr. Software Engineer | Skype: Richard.RattiganSonos > > > > _______________________________________________ > keycloak-user mailing list > keycloak-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user > -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From bburke at redhat.com Tue Nov 11 20:58:47 2014 From: bburke at redhat.com (Bill Burke) Date: Tue, 11 Nov 2014 20:58:47 -0500 Subject: [keycloak-user] JWT signature verification failure In-Reply-To: <5462BE0E.9000201@redhat.com> References: <5462BE0E.9000201@redhat.com> Message-ID: <5462BED7.8020306@redhat.com> In the meantime, you could use our impl until I fix it. On 11/11/2014 8:55 PM, Bill Burke wrote: > Looking at jjwt, they do this algorithm: > > sign(base64enocdedheader + "." + bsase64encodedContent) > > We just sign the content. Just verified that our impl is wrong. I'll > fix this for next release. > > On 11/11/2014 7:50 PM, Richard Rattigan wrote: >> I?m trying to verify keycloak jwt signatures in a Java/Groovy, but I?m >> not succeeding. I?m new to crypto, so maybe I?m doing something stupid. >> >> This is Groovy code. realmPublicKey is the publicKey string from the >> realm REST response. I?m using the jjwt library to parse the tokens, but >> I get the same result (signature verification failure) with the nimbus >> library: >> >> Security.addProvider(new BouncyCastleProvider()) >> def publicKey = KeyFactory >> .getInstance("RSA", "BC") >> .generatePublic(new >> X509EncodedKeySpec(realmPublicKey.decodeBase64())) >> def claims = Jwts.parser().setSigningKey(publicKey).parse(accessToken) >> >> I get an exception during the parse: >> >> io.jsonwebtoken.SignatureException: JWT signature does not match locally >> computed signature. JWT validity cannot be asserted and should not be >> trusted. >> >> Is anyone able to see what I?m doing wrong here? >> >> *Richard Rattigan* >> >> Sonos | Sr. Software Engineer | Skype: Richard.RattiganSonos >> >> >> >> _______________________________________________ >> keycloak-user mailing list >> keycloak-user at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-user >> > -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From Richard.Rattigan at sonos.com Wed Nov 12 05:40:10 2014 From: Richard.Rattigan at sonos.com (Richard Rattigan) Date: Wed, 12 Nov 2014 10:40:10 +0000 Subject: [keycloak-user] JWT signature verification failure In-Reply-To: <5462BED7.8020306@redhat.com> References: <5462BE0E.9000201@redhat.com> <5462BED7.8020306@redhat.com> Message-ID: That clears that up. Thanks! On 11/11/14, 8:58 PM, "Bill Burke" wrote: >In the meantime, you could use our impl until I fix it. > >On 11/11/2014 8:55 PM, Bill Burke wrote: >> Looking at jjwt, they do this algorithm: >> >> sign(base64enocdedheader + "." + bsase64encodedContent) >> >> We just sign the content. Just verified that our impl is wrong. I'll >> fix this for next release. >> >> On 11/11/2014 7:50 PM, Richard Rattigan wrote: >>> I?m trying to verify keycloak jwt signatures in a Java/Groovy, but I?m >>> not succeeding. I?m new to crypto, so maybe I?m doing something stupid. >>> >>> This is Groovy code. realmPublicKey is the publicKey string from the >>> realm REST response. I?m using the jjwt library to parse the tokens, >>>but >>> I get the same result (signature verification failure) with the nimbus >>> library: >>> >>> Security.addProvider(new BouncyCastleProvider()) >>> def publicKey = KeyFactory >>> .getInstance("RSA", "BC") >>> .generatePublic(new >>> X509EncodedKeySpec(realmPublicKey.decodeBase64())) >>> def claims = >>>Jwts.parser().setSigningKey(publicKey).parse(accessToken) >>> >>> I get an exception during the parse: >>> >>> io.jsonwebtoken.SignatureException: JWT signature does not match >>>locally >>> computed signature. JWT validity cannot be asserted and should not be >>> trusted. >>> >>> Is anyone able to see what I?m doing wrong here? >>> >>> *Richard Rattigan* >>> >>> Sonos | Sr. Software Engineer | Skype: Richard.RattiganSonos >>> >>> >>> >>> _______________________________________________ >>> keycloak-user mailing list >>> keycloak-user at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/keycloak-user >>> >> > >-- >Bill Burke >JBoss, a division of Red Hat >http://bill.burkecentral.com >_______________________________________________ >keycloak-user mailing list >keycloak-user at lists.jboss.org >https://lists.jboss.org/mailman/listinfo/keycloak-user From bburke at redhat.com Wed Nov 12 18:56:10 2014 From: bburke at redhat.com (Bill Burke) Date: Wed, 12 Nov 2014 18:56:10 -0500 Subject: [keycloak-user] JWT signature verification failure In-Reply-To: References: <5462BE0E.9000201@redhat.com> <5462BED7.8020306@redhat.com> Message-ID: <5463F39A.4070009@redhat.com> FYI, fixed in master. Will be in next release. On 11/12/2014 5:40 AM, Richard Rattigan wrote: > That clears that up. Thanks! > > > On 11/11/14, 8:58 PM, "Bill Burke" wrote: > >> In the meantime, you could use our impl until I fix it. >> >> On 11/11/2014 8:55 PM, Bill Burke wrote: >>> Looking at jjwt, they do this algorithm: >>> >>> sign(base64enocdedheader + "." + bsase64encodedContent) >>> >>> We just sign the content. Just verified that our impl is wrong. I'll >>> fix this for next release. >>> >>> On 11/11/2014 7:50 PM, Richard Rattigan wrote: >>>> I?m trying to verify keycloak jwt signatures in a Java/Groovy, but I?m >>>> not succeeding. I?m new to crypto, so maybe I?m doing something stupid. >>>> >>>> This is Groovy code. realmPublicKey is the publicKey string from the >>>> realm REST response. I?m using the jjwt library to parse the tokens, >>>> but >>>> I get the same result (signature verification failure) with the nimbus >>>> library: >>>> >>>> Security.addProvider(new BouncyCastleProvider()) >>>> def publicKey = KeyFactory >>>> .getInstance("RSA", "BC") >>>> .generatePublic(new >>>> X509EncodedKeySpec(realmPublicKey.decodeBase64())) >>>> def claims = >>>> Jwts.parser().setSigningKey(publicKey).parse(accessToken) >>>> >>>> I get an exception during the parse: >>>> >>>> io.jsonwebtoken.SignatureException: JWT signature does not match >>>> locally >>>> computed signature. JWT validity cannot be asserted and should not be >>>> trusted. >>>> >>>> Is anyone able to see what I?m doing wrong here? >>>> >>>> *Richard Rattigan* >>>> >>>> Sonos | Sr. Software Engineer | Skype: Richard.RattiganSonos >>>> >>>> >>>> >>>> _______________________________________________ >>>> keycloak-user mailing list >>>> keycloak-user at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/keycloak-user >>>> >>> >> >> -- >> Bill Burke >> JBoss, a division of Red Hat >> http://bill.burkecentral.com >> _______________________________________________ >> keycloak-user mailing list >> keycloak-user at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-user > -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From lionelve at gmail.com Wed Nov 12 19:32:05 2014 From: lionelve at gmail.com (Lionel Orellana) Date: Thu, 13 Nov 2014 11:32:05 +1100 Subject: [keycloak-user] LDAP Groups Message-ID: Hi, I am evaluating LDAP integration in version 1.1.0.Beta1. I don't see anything in the LDAP provider settings regarding groups. I was expecting something similar to the jboss ldap login module where there are settings to populate the user principal with roles from LDAP groups. Is there an alternative way to do this with Keycloak? Thanks Lionel. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20141113/8304ee9d/attachment.html From mposolda at redhat.com Thu Nov 13 08:50:35 2014 From: mposolda at redhat.com (Marek Posolda) Date: Thu, 13 Nov 2014 14:50:35 +0100 Subject: [keycloak-user] LDAP Groups In-Reply-To: References: Message-ID: <5464B72B.8090505@redhat.com> Hi, right now users authenticated via LDAP are synced to keycloak database and they receive just default roles configured for particular realm (or realm applications). Other roles need to be done manually. Right now we don't have any support for sync LDAP groups or user memberships from LDAP. There is jira for it https://issues.jboss.org/browse/KEYCLOAK-630 Marek On 13.11.2014 01:32, Lionel Orellana wrote: > Hi, > > I am evaluating LDAP integration in version 1.1.0.Beta1. I don't see > anything in the LDAP provider settings regarding groups. I was > expecting something similar to the jboss ldap login module where there > are settings to populate the user principal with roles from LDAP > groups. Is there an alternative way to do this with Keycloak? > > Thanks > > Lionel. > > > _______________________________________________ > 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-user/attachments/20141113/354e9981/attachment-0001.html From juraci at kroehling.de Thu Nov 13 11:58:39 2014 From: juraci at kroehling.de (=?windows-1252?Q?Juraci_Paix=E3o_Kr=F6hling?=) Date: Thu, 13 Nov 2014 17:58:39 +0100 Subject: [keycloak-user] Recommendations for protecting REST service with bearer token and basic auth In-Reply-To: <5460BFDB.1060606@redhat.com> References: <1845864658.5951344.1415369800735.JavaMail.zimbra@redhat.com> <545D7D75.8050500@redhat.com> <279836542.6533747.1415607641136.JavaMail.zimbra@redhat.com> <5460BFDB.1060606@redhat.com> Message-ID: <5464E33F.9010601@kroehling.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 11/10/2014 02:38 PM, Bill Burke wrote: > With basic auth, you have zero control over the client and you're > handing over credentials to that client. Simple and easy for > "hello world" apps sure. Would it make sense to add something like Google's "Application Specific Passwords"? This way, it's not the main credentials which are being shared and those can be revoked individually if necessary. An application that is not OAuth capable for some reason could then make use of this. - - Juca. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBCgAGBQJUZOM/AAoJEDnJtskdmzLMtdAH/1tdg0ExaN6muEyAqzKEH7J4 5dRhwMa5wgmb0NBNa4eu/zM4Cze7NGM4iiJgAgyqj/BsAcacNec8lo8Ri0d2H6sH khGifXhRlbfgYOSR4rnzbc6RuaCtE9YIhzrWWlXR26bXQTRiIwIYB35onVGQpC9b 39CrQripOlhW5fR4TZdKuK2k9TeKHQL5WN6/Vw41Yzor+MzhN38WZnyYg2csTn9O wRwHO1SF2f4MzGYOgbkP8UJWg5/WQQyeVbbjzPtl+OgMoxbexJzmDSGvr/D1WFFR IZJPL2C8JdyAo9XQy8WVSEjBfU6vek2haLlfFyAHj00d/om6VT3MdpFgqz4wL+I= =5kU0 -----END PGP SIGNATURE----- From pratik.p.parikh at gmail.com Thu Nov 13 12:37:39 2014 From: pratik.p.parikh at gmail.com (Pratik Parikh) Date: Thu, 13 Nov 2014 12:37:39 -0500 Subject: [keycloak-user] No state cookie - Problem after authentication - What am i missing? Message-ID: I am trying to setup Aerogear 1.0.2 (hosted on a separate server from Keycloak) Integration with Keycloak 1.0.1-Beta1 (hosted on a separate server then Aerogear) and in doing so i am running into a problem. Could anyone provide me some direction, below is what is happening. I was able to import the aerogear realm and configure appropriate redirect URI. After doing so i am now presented with a login screen where by i was able to login but after login when it tries to do a redirect i get the following, am not sure that it mean and how to move forward. Any help will be appreciated. 2014-11-13 13:15:52,061 WARN [org.keycloak.adapters.OAuthRequestAuthenticator] (default task-60) No state cookie -- This error is on aerogear server after the authentication is done. Do i need to upgrade the adapter on Aerogear server? Regards, Thanks in advance. -- Pratik Parikh - Mantra - Keep It Simple and Straightforward -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20141113/13364abc/attachment.html From Richard.Rattigan at sonos.com Thu Nov 13 14:16:22 2014 From: Richard.Rattigan at sonos.com (Richard Rattigan) Date: Thu, 13 Nov 2014 19:16:22 +0000 Subject: [keycloak-user] oauth limited scope access tokens? Message-ID: I noticed the following comment in TokenManager: public static Set getAccess(String scopeParam, ClientModel client, UserModel user) { // todo scopeParam is ignored until we figure out a scheme that fits with openid connect ... } Am I right to assume this means it is not possible for an OAuth client to request an access token for a subset of the available scopes? I.e. The OAuth scope parameter is ignored? If this is correct, is this a feature that will be added soon? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20141113/c6942f8c/attachment.html From pratik.p.parikh at gmail.com Thu Nov 13 15:32:05 2014 From: pratik.p.parikh at gmail.com (Pratik Parikh) Date: Thu, 13 Nov 2014 15:32:05 -0500 Subject: [keycloak-user] failed verification of token Message-ID: Did you find any solution to this? I am facing the same error, below is my cry for help. http://lists.jboss.org/pipermail/keycloak-user/2014-November/001170.html Regards, Thanks in advance -- Pratik Parikh - Mantra - Keep It Simple and Straightforward -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20141113/c510f196/attachment.html From bburke at redhat.com Thu Nov 13 16:57:44 2014 From: bburke at redhat.com (Bill Burke) Date: Thu, 13 Nov 2014 16:57:44 -0500 Subject: [keycloak-user] oauth limited scope access tokens? In-Reply-To: References: Message-ID: <54652958.9050106@redhat.com> What you can do is limit the scope of a client within the admin console. On 11/13/2014 2:16 PM, Richard Rattigan wrote: > I noticed the following comment in TokenManager: > > public static Set getAccess(String scopeParam, > ClientModel client, UserModel user) { > // todo scopeParam is ignored until we figure out a scheme that > fits with openid connect > ? > } > > Am I right to assume this means it is not possible for an OAuth client > to request an access token for a subset of the available scopes? I.e. > The OAuth scope parameter is ignored? > > If this is correct, is this a feature that will be added soon? > > > > > _______________________________________________ > keycloak-user mailing list > keycloak-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user > -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From bburke at redhat.com Thu Nov 13 17:00:29 2014 From: bburke at redhat.com (Bill Burke) Date: Thu, 13 Nov 2014 17:00:29 -0500 Subject: [keycloak-user] failed verification of token In-Reply-To: References: Message-ID: <546529FD.6040704@redhat.com> You can limit the scope of a client in the admin console. On 11/13/2014 3:32 PM, Pratik Parikh wrote: > Did you find any solution to this? I am facing the same error, below is > my cry for help. > > http://lists.jboss.org/pipermail/keycloak-user/2014-November/001170.html > > Regards, Thanks in advance > -- > Pratik Parikh > - Mantra - Keep It Simple and Straightforward > > > _______________________________________________ > keycloak-user mailing list > keycloak-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user > -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From afsg77 at gmail.com Thu Nov 13 19:31:37 2014 From: afsg77 at gmail.com (=?UTF-8?Q?Fabi=C3=A1n_Silva?=) Date: Thu, 13 Nov 2014 18:31:37 -0600 Subject: [keycloak-user] Error on application log in Message-ID: I have a keycloak installed on wildfly standalone. I'm trying to deploy an application, that use this keycloak, on a separate server with wilflly running on domain mode. I tried first to deploy on a domain out of the box on my local machine, setting the keycloak-wildfly-adapter-dist-1.0.4.Final. It deploys fine and does the authentication without any issues. When I try to migrate it to the server running my wilfly (also in domain mode and the keycloak adapter set), it deploys fine and shows the keycloak login once you enter the application. But the problem is that when you login it displays a "403 - Forbidden" and on the log I'm seeing ERROR [org.keycloak.adapters.OAuthRequestAuthenticator] (default task-6) failed to turn code into token ERROR [org.keycloak.adapters.OAuthRequestAuthenticator] (default task-6) status from server: 404 The only difference between those two wildfly domain mode is that in the local I don't have the the SSL/HTTPS enabled. Have anyone seen this error? or have an idea of what this could be? Regards -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20141113/9114bd70/attachment.html From pratik.p.parikh at gmail.com Thu Nov 13 20:18:06 2014 From: pratik.p.parikh at gmail.com (Pratik Parikh) Date: Thu, 13 Nov 2014 20:18:06 -0500 Subject: [keycloak-user] failed verification of token Message-ID: Hi Bill, Thanks i turned the scope off under the application but that did not help. Could you please help us understand what is going on. I am trying to look the code but seems like it is going to take be a bit to figure it out. It seems like HttpFacade.Cookies is suppose to have state cookie which is contained in KeycloakDeployment. I did try what you suggest was that not correctly understood by me? I am new to keycloak but this is a great project would like to understand it and use it to its fullest extend. Can you help me get past this problem. Thanks in advance. Regards, -- Pratik Parikh - Mantra - Keep It Simple and Straightforward -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20141113/0aee32b6/attachment.html From pratik.p.parikh at gmail.com Thu Nov 13 22:28:39 2014 From: pratik.p.parikh at gmail.com (Pratik Parikh) Date: Thu, 13 Nov 2014 22:28:39 -0500 Subject: [keycloak-user] failed verification of token In-Reply-To: References: Message-ID: Hi Bill, Is this because both of my server (keycloak and aerogear are https). Do i need to establish trust between them? Regards, Pratik Parikh On Thu, Nov 13, 2014 at 8:18 PM, Pratik Parikh wrote: > Hi Bill, > > Thanks i turned the scope off under the application but that did not > help. Could you please help us understand what is going on. I am trying > to look the code but seems like it is going to take be a bit to figure it > out. It seems like HttpFacade.Cookies is suppose to have state cookie > which is contained in KeycloakDeployment. I did try what you suggest was > that not correctly understood by me? I am new to keycloak but this is a > great project would like to understand it and use it to its fullest extend. > Can you help me get past this problem. Thanks in advance. > > Regards, > -- > Pratik Parikh > - Mantra - Keep It Simple and Straightforward > -- Pratik Parikh - Mantra - Keep It Simple and Straightforward -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20141113/51d7f751/attachment-0001.html From mposolda at redhat.com Fri Nov 14 03:27:29 2014 From: mposolda at redhat.com (Marek Posolda) Date: Fri, 14 Nov 2014 09:27:29 +0100 Subject: [keycloak-user] Error on application log in In-Reply-To: References: Message-ID: <5465BCF1.6000304@redhat.com> Hi, it failed on the adapter (application) side and error 404 means "Not found". So adapter can't find the keycloak server to turn code into token. Make sure to configure "auth-server-url" in keycloak.json for your application properly. If relative uri doesn't work for some reason, you can rather try to use absolute uri for auth-server-url like "https://localhost:8443/auth" . Marek On 14.11.2014 01:31, Fabi?n Silva wrote: > I have a keycloak installed on wildfly standalone. I'm trying to > deploy an application, that use this keycloak, on a separate server > with wilflly running on domain mode. I tried first to deploy on a > domain out of the box on my local machine, setting the > keycloak-wildfly-adapter-dist-1.0.4.Final. It deploys fine and does > the authentication without any issues. When I try to migrate it to the > server running my wilfly (also in domain mode and the keycloak adapter > set), it deploys fine and shows the keycloak login once you enter the > application. But the problem is that when you login it displays a "403 > - Forbidden" and on the log I'm seeing > ERROR [org.keycloak.adapters.OAuthRequestAuthenticator] (default > task-6) failed to turn code into token > ERROR [org.keycloak.adapters.OAuthRequestAuthenticator] (default > task-6) status from server: 404 > The only difference between those two wildfly domain mode is that in > the local I don't have the the SSL/HTTPS enabled. > > Have anyone seen this error? or have an idea of what this could be? > > Regards > > > _______________________________________________ > 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-user/attachments/20141114/c6a35218/attachment.html From bburke at redhat.com Fri Nov 14 08:46:55 2014 From: bburke at redhat.com (Bill Burke) Date: Fri, 14 Nov 2014 08:46:55 -0500 Subject: [keycloak-user] failed verification of token In-Reply-To: References: Message-ID: <546607CF.7090205@redhat.com> Can you explain your problem again? I think I am misunderstanding what problems you are having. You linked this message: http://lists.jboss.org/pipermail/keycloak-user/2014-November/001170.html We do not support OIDC scope param, but you can limit the application's scope in the admin console. On 11/13/2014 10:28 PM, Pratik Parikh wrote: > Hi Bill, > > Is this because both of my server (keycloak and aerogear are > https). Do i need to establish trust between them? > > Regards, > Pratik Parikh > > On Thu, Nov 13, 2014 at 8:18 PM, Pratik Parikh > > wrote: > > Hi Bill, > > Thanks i turned the scope off under the application but that > did not help. Could you please help us understand what is going > on. I am trying to look the code but seems like it is going to take > be a bit to figure it out. It seems like HttpFacade.Cookies is > suppose to have state cookie which is contained in > KeycloakDeployment. I did try what you suggest was that not > correctly understood by me? I am new to keycloak but this is a great > project would like to understand it and use it to its fullest > extend. Can you help me get past this problem. Thanks in advance. > > Regards, > -- > Pratik Parikh > - Mantra - Keep It Simple and Straightforward > > > > > -- > Pratik Parikh > - Mantra - Keep It Simple and Straightforward > > > _______________________________________________ > keycloak-user mailing list > keycloak-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user > -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From juraci at kroehling.de Fri Nov 14 09:28:38 2014 From: juraci at kroehling.de (=?UTF-8?B?SnVyYWNpIFBhaXjDo28gS3LDtmhsaW5n?=) Date: Fri, 14 Nov 2014 15:28:38 +0100 Subject: [keycloak-user] "Invalid state param" for KeycloakInstalled Message-ID: <54661196.8040904@kroehling.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hello, I'm trying to use the KeycloakInstalled to authenticate an user via CLI and I'm getting a "Invalid State param" message on the URL that it asks the user to open. Code: KeycloakInstalled keycloak = new KeycloakInstalled(); keycloak.loginManual(); The generated URL is: http://localhost:8080/auth/realms/acme-roadrunner-affairs/protocol/openid-connect/login?client_id=installed&redirect_uri=urn%3Aietf%3Awg%3Aoauth%3A2.0%3Aoob "acme-roadrunner-affairs" is the realm, and "installed" is an OAuth client registered on this realm, with a "redirect URI" as "urn:ietf:wg:oauth:2.0:oob" Am I missing some configuration? - - Juca. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBCgAGBQJUZhGWAAoJEDnJtskdmzLMRrQIAIsnyvrDcPbNGnCZ5J6iyb9K yli+68XODuIvdVheihy27aODlKT5kEDPKtBF2VrcLwvnQW16ZCcsIBwKvB4DF587 +PpZZysuvvNQnXu9PY/X0THilPuIJCsCj1Pti5YK1Npp7WL1gGNn4OV7cwhsk+wT xNbbWzsCh53eRistfCGuQ4f6cD/dZkIVEwjPSwP7UQnYuT3qeftsXWHAtWXdLmIa 6zoe8X9pJ/OfAyk1TPUJjM0vzhtRnZOXk1qecRFe7g+uEUnDG1kx5Vp9Mf7ri3J/ JSmJhhxVxpJyFeSPHx1cZrZXZbyrcl88TeonqG8D//x3t2y4dJil0DE/t/5Kmtw= =qdUj -----END PGP SIGNATURE----- From pratik.p.parikh at gmail.com Fri Nov 14 09:34:35 2014 From: pratik.p.parikh at gmail.com (Pratik Parikh) Date: Fri, 14 Nov 2014 09:34:35 -0500 Subject: [keycloak-user] failed verification of token In-Reply-To: <546607CF.7090205@redhat.com> References: <546607CF.7090205@redhat.com> Message-ID: Hi Bill, My goal is get liveoak, aerogear and keycloak working on different servers. LiveOak uses Keycloak and Aerogear. Following are the steps i took. 1) Install Keycloak on one server with self signed certificate. It is accessible via https://XXX.XXX.XXX.XXX:8443/auth. Worked 2) Installed AreoGear on another server with self signed certificate. It is accessible via https://XXX.XXX.XXX.XXX:8443/ag-push. Worked 3) Imported attached JSON in as a new aerogear realm in keycloak. Worked 4) Updated Keycloak to use MongoDB. Worked 5) Update application aerogear with keycloak.json restarted wildfly server. Updated application under AreoGear to use https://XXX.XXX.XXX.XXX:8443/ag-push/* as a redirect uri. Worked. 6) Restarted both the wildfly servers. 7) After restart tried to login to https://XXX.XXX.XXX.XXX:8443/ag-push/ forwarded me to https://XXX.XXX.XXX.XXX:8443/auth login page. Successfull login was achieved. 8) PROBLEM: After login redirect to https://XXX.XXX.XXX.XXX:8443/ag-push/ where by i get error "No state cookie" in AreoGear log, which is coming from OAuthRequestAuthenticator line 116 because the adapter can not find a cookie with name " OAuth_Token_Request_State" in HTTP. Troubleshooting Try 1. 1) updated aerogear to use 1.0.1.Beta1 Adapter. Still works does not solve the problem same error. Troubleshooting Try 2. 1) updated keycloak.json by adding *"disable-trust-manager": true*. Still works does not solve the problem same error. Troubleshooting Try 2. Still have not done but will do today is 1) updated keycloak.json by adding *"disable-trust-manager": false,"truststore": "/path","truststore-password": "password"*. Will report back shortly. Regards, Pratik Parikh On Fri, Nov 14, 2014 at 8:46 AM, Bill Burke wrote: > Can you explain your problem again? I think I am misunderstanding what > problems you are having. You linked this message: > > http://lists.jboss.org/pipermail/keycloak-user/2014-November/001170.html > > We do not support OIDC scope param, but you can limit the application's > scope in the admin console. > > On 11/13/2014 10:28 PM, Pratik Parikh wrote: > > Hi Bill, > > > > Is this because both of my server (keycloak and aerogear are > > https). Do i need to establish trust between them? > > > > Regards, > > Pratik Parikh > > > > On Thu, Nov 13, 2014 at 8:18 PM, Pratik Parikh > > > wrote: > > > > Hi Bill, > > > > Thanks i turned the scope off under the application but that > > did not help. Could you please help us understand what is going > > on. I am trying to look the code but seems like it is going to take > > be a bit to figure it out. It seems like HttpFacade.Cookies is > > suppose to have state cookie which is contained in > > KeycloakDeployment. I did try what you suggest was that not > > correctly understood by me? I am new to keycloak but this is a great > > project would like to understand it and use it to its fullest > > extend. Can you help me get past this problem. Thanks in advance. > > > > Regards, > > -- > > Pratik Parikh > > - Mantra - Keep It Simple and Straightforward > > > > > > > > > > -- > > Pratik Parikh > > - Mantra - Keep It Simple and Straightforward > > > > > > _______________________________________________ > > keycloak-user mailing list > > keycloak-user at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/keycloak-user > > > > -- > Bill Burke > JBoss, a division of Red Hat > http://bill.burkecentral.com > _______________________________________________ > keycloak-user mailing list > keycloak-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user > -- Pratik Parikh - Mantra - Keep It Simple and Straightforward -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20141114/62cb6706/attachment.html -------------- next part -------------- A non-text attachment was scrubbed... Name: ups-realm.json Type: application/json Size: 2333 bytes Desc: not available Url : http://lists.jboss.org/pipermail/keycloak-user/attachments/20141114/62cb6706/attachment.bin From afsg77 at gmail.com Fri Nov 14 11:20:02 2014 From: afsg77 at gmail.com (=?UTF-8?Q?Fabi=C3=A1n_Silva?=) Date: Fri, 14 Nov 2014 10:20:02 -0600 Subject: [keycloak-user] Error on application log in In-Reply-To: <5465BCF1.6000304@redhat.com> References: <5465BCF1.6000304@redhat.com> Message-ID: Hi, It is already set to use the absolute path. And the keycloak is working when I deploy the application to my local wildfly domain. The issue is when I try to deploy to another wildfly in domain mode on a separate server. The application is the same and the only difference I can tell from the two wildflys is that the local don't have the SSL/HTTPS enabled. I have the keycloak adapter set in both domains. I'm trying to trace those errors on the keycloak code to try to understand what is happening, but I haven't been so lucky with this. Regards Alejandro Fabi?n Silva Grif? On Fri, Nov 14, 2014 at 2:27 AM, Marek Posolda wrote: > Hi, > > it failed on the adapter (application) side and error 404 means "Not > found". So adapter can't find the keycloak server to turn code into token. > Make sure to configure "auth-server-url" in keycloak.json for your > application properly. If relative uri doesn't work for some reason, you can > rather try to use absolute uri for auth-server-url like > "https://localhost:8443/auth" . > > Marek > > > On 14.11.2014 01:31, Fabi?n Silva wrote: > > I have a keycloak installed on wildfly standalone. I'm trying to deploy > an application, that use this keycloak, on a separate server with wilflly > running on domain mode. I tried first to deploy on a domain out of the box > on my local machine, setting the keycloak-wildfly-adapter-dist-1.0.4.Final. > It deploys fine and does the authentication without any issues. When I try > to migrate it to the server running my wilfly (also in domain mode and the > keycloak adapter set), it deploys fine and shows the keycloak login once > you enter the application. But the problem is that when you login it > displays a "403 - Forbidden" and on the log I'm seeing > ERROR [org.keycloak.adapters.OAuthRequestAuthenticator] (default task-6) > failed to turn code into token > ERROR [org.keycloak.adapters.OAuthRequestAuthenticator] (default task-6) > status from server: 404 > The only difference between those two wildfly domain mode is that in the > local I don't have the the SSL/HTTPS enabled. > > Have anyone seen this error? or have an idea of what this could be? > > Regards > > > _______________________________________________ > keycloak-user mailing listkeycloak-user at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-user > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20141114/83826149/attachment-0001.html From pratik.p.parikh at gmail.com Sat Nov 15 13:39:59 2014 From: pratik.p.parikh at gmail.com (Pratik Parikh) Date: Sat, 15 Nov 2014 13:39:59 -0500 Subject: [keycloak-user] failed verification of token In-Reply-To: References: <546607CF.7090205@redhat.com> Message-ID: Hi Bill, My goal is get liveoak, aerogear and keycloak working on different servers. LiveOak uses Keycloak and Aerogear. Following are the steps i took. 1) Install Keycloak on one server with self signed certificate. It is accessible via https://XXX.XXX.XXX.XXX:8443/auth . Worked 2) Installed AreoGear on another server with self signed certificate. It is accessible via https://XXX.XXX.XXX.XXX:8443/ag-push . Worked 3) Imported attached JSON in as a new aerogear realm in keycloak. Worked 4) Updated Keycloak to use MongoDB. Worked 5) Update application aerogear with keycloak.json restarted wildfly server. Updated application under AreoGear to use https://XXX.XXX.XXX.XXX:8443/ag-push/* as a redirect uri. Worked. 6) Restarted both the wildfly servers. 7) After restart tried to login to https://XXX.XXX.XXX.XXX:8443/ag-push/ forwarded me to https://XXX.XXX.XXX.XXX:8443/auth login page. Successfull login was achieved. 8) PROBLEM: After login redirect to https://XXX.XXX.XXX.XXX:8443/ag-push/ where by i get error "No state cookie" in AreoGear log, which is coming from OAuthRequestAuthenticator line 116 because the adapter can not find a cookie with name " OAuth_Token_Request_State" in HTTP. Troubleshooting Try 1. 1) updated aerogear to use 1.0.1.Beta1 Adapter. Still works does not solve the problem same error. Troubleshooting Try 2. 1) updated keycloak.json by adding *"disable-trust-manager": true*. Still works does not solve the problem same error. Troubleshooting Try 3. 1) updated keycloak.json by adding *"disable-trust-manager": false,"truststore": "/path","truststore-password": "password"*. Still works doe not solve the problem. I have a question is "*truststore*" a local path to the keycloak jks cert or this is a path to remote keycloak cert? I copied the keycloak.jks and pointed to that locally using ${jboss.server.config.dir}/trustcerts/keycloak.jks? is this correct? After doing this i tried to invoke https://XXX.XXX.XXXX.XXXX:8443/ag-push/rest/ping Get the login screen then i get Forbidden with below exception: 2014-11-15 18:31:13,664 ERROR [org.keycloak.adapters.OAuthRequestAuthenticator] (default task-6) failed to turn code into token: javax.net.ssl.SSLPeerUnverifiedException: peer not authenticated at sun.security.ssl.SSLSessionImpl.getPeerCertificates(SSLSessionImpl.java:431) [jsse.jar:1.8.0_25] at org.apache.http.conn.ssl.AbstractVerifier.verify(AbstractVerifier.java:128) [httpclient-4.2.1.jar:4.2.1] at org.apache.http.conn.ssl.SSLSocketFactory.connectSocket(SSLSocketFactory.java:572) [httpclient-4.2.1.jar:4.2.1] at org.apache.http.impl.conn.DefaultClientConnectionOperator.openConnection(DefaultClientConnectionOperator.java:180) [httpclient-4.2.1.jar:4.2.1] at org.apache.http.impl.conn.AbstractPoolEntry.open(AbstractPoolEntry.java:151) [httpclient-4.2.1.jar:4.2.1] at org.apache.http.impl.conn.AbstractPooledConnAdapter.open(AbstractPooledConnAdapter.java:125) [httpclient-4.2.1.jar:4.2.1] at org.apache.http.impl.client.DefaultRequestDirector.tryConnect(DefaultRequestDirector.java:640) [httpclient-4.2.1.jar:4.2.1] at org.apache.http.impl.client.DefaultRequestDirector.execute(DefaultRequestDirector.java:479) [httpclient-4.2.1.jar:4.2.1] at org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:906) [httpclient-4.2.1.jar:4.2.1] at org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:805) [httpclient-4.2.1.jar:4.2.1] at org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:784) [httpclient-4.2.1.jar:4.2.1] at org.keycloak.adapters.ServerRequest.invokeAccessCodeToToken(ServerRequest.java:116) [keycloak-adapter-core-1.0.4.Final.jar:] at org.keycloak.adapters.ServerRequest.invokeAccessCodeToToken(ServerRequest.java:93) [keycloak-adapter-core-1.0.4.Final.jar:] at org.keycloak.adapters.OAuthRequestAuthenticator.resolveCode(OAuthRequestAuthenticator.java:256) [keycloak-adapter-core-1.0.4.Final.jar:] at org.keycloak.adapters.OAuthRequestAuthenticator.authenticate(OAuthRequestAuthenticator.java:205) [keycloak-adapter-core-1.0.4.Final.jar:] at org.keycloak.adapters.RequestAuthenticator.authenticate(RequestAuthenticator.java:68) [keycloak-adapter-core-1.0.4.Final.jar:] at org.keycloak.adapters.undertow.UndertowKeycloakAuthMech.keycloakAuthenticate(UndertowKeycloakAuthMech.java:82) [keycloak-undertow-adapter-1.0.4.Final.jar:] at org.keycloak.adapters.undertow.ServletKeycloakAuthMech.authenticate(ServletKeycloakAuthMech.java:61) [keycloak-undertow-adapter-1.0.4.Final.jar:] at io.undertow.security.impl.SecurityContextImpl$AuthAttempter.transition(SecurityContextImpl.java:281) [undertow-core-1.0.15.Final.jar:1.0.15.Final] at io.undertow.security.impl.SecurityContextImpl$AuthAttempter.transition(SecurityContextImpl.java:298) [undertow-core-1.0.15.Final.jar:1.0.15.Final] at io.undertow.security.impl.SecurityContextImpl$AuthAttempter.access$100(SecurityContextImpl.java:268) [undertow-core-1.0.15.Final.jar:1.0.15.Final] at io.undertow.security.impl.SecurityContextImpl.attemptAuthentication(SecurityContextImpl.java:131) [undertow-core-1.0.15.Final.jar:1.0.15.Final] at io.undertow.security.impl.SecurityContextImpl.authTransition(SecurityContextImpl.java:106) [undertow-core-1.0.15.Final.jar:1.0.15.Final] at io.undertow.security.impl.SecurityContextImpl.authenticate(SecurityContextImpl.java:99) [undertow-core-1.0.15.Final.jar:1.0.15.Final] at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:54) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final] at io.undertow.server.handlers.DisableCacheHandler.handleRequest(DisableCacheHandler.java:27) [undertow-core-1.0.15.Final.jar:1.0.15.Final] at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final] at io.undertow.security.handlers.AuthenticationConstraintHandler.handleRequest(AuthenticationConstraintHandler.java:51) [undertow-core-1.0.15.Final.jar:1.0.15.Final] at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45) [undertow-core-1.0.15.Final.jar:1.0.15.Final] at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:61) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final] at io.undertow.servlet.handlers.security.ServletSecurityConstraintHandler.handleRequest(ServletSecurityConstraintHandler.java:56) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final] at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:58) [undertow-core-1.0.15.Final.jar:1.0.15.Final] at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:70) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final] at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:76) [undertow-core-1.0.15.Final.jar:1.0.15.Final] at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final] at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61) at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final] at org.keycloak.adapters.undertow.ServletPreAuthActionsHandler.handleRequest(ServletPreAuthActionsHandler.java:69) [keycloak-undertow-adapter-1.0.4.Final.jar:] at org.keycloak.adapters.undertow.ServletPreAuthActionsHandler.handleRequest(ServletPreAuthActionsHandler.java:69) [keycloak-undertow-adapter-1.0.4.Final.jar:] at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final] at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:240) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final] at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:227) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final] at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:73) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final] at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:146) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final] at io.undertow.server.Connectors.executeRootHandler(Connectors.java:177) [undertow-core-1.0.15.Final.jar:1.0.15.Final] at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:727) [undertow-core-1.0.15.Final.jar:1.0.15.Final] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_25] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_25] at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_25] Please help i feel like i am very close just missing something simple. Regards, Pratik Parikh On Fri, Nov 14, 2014 at 9:34 AM, Pratik Parikh wrote: > Hi Bill, > > My goal is get liveoak, aerogear and keycloak working on different > servers. LiveOak uses Keycloak and Aerogear. Following are the steps i > took. > > 1) Install Keycloak on one server with self signed certificate. It is > accessible via https://XXX.XXX.XXX.XXX:8443/auth. Worked > 2) Installed AreoGear on another server with self signed certificate. > It is accessible via https://XXX.XXX.XXX.XXX:8443/ag-push. Worked > 3) Imported attached JSON in as a new aerogear realm in keycloak. > Worked > 4) Updated Keycloak to use MongoDB. Worked > 5) Update application aerogear with keycloak.json restarted wildfly > server. Updated application under AreoGear to use > https://XXX.XXX.XXX.XXX:8443/ag-push/* as a redirect uri. Worked. > 6) Restarted both the wildfly servers. > 7) After restart tried to login to > https://XXX.XXX.XXX.XXX:8443/ag-push/ forwarded me to > https://XXX.XXX.XXX.XXX:8443/auth login page. Successfull login was > achieved. > 8) PROBLEM: After login redirect to > https://XXX.XXX.XXX.XXX:8443/ag-push/ where by i get error "No state > cookie" in AreoGear log, which is coming from OAuthRequestAuthenticator > line 116 because the adapter can not find a cookie with name " > OAuth_Token_Request_State" in HTTP. > > Troubleshooting Try 1. > 1) updated aerogear to use 1.0.1.Beta1 Adapter. Still works does not > solve the problem same error. > > Troubleshooting Try 2. > 1) updated keycloak.json by adding *"disable-trust-manager": true*. > Still works does not solve the problem same error. > > Troubleshooting Try 2. Still have not done but will do today is > 1) updated keycloak.json by adding *"disable-trust-manager": > false,"truststore": "/path","truststore-password": "password"*. Will > report back shortly. > > Regards, > Pratik Parikh > > On Fri, Nov 14, 2014 at 8:46 AM, Bill Burke wrote: > >> Can you explain your problem again? I think I am misunderstanding what >> problems you are having. You linked this message: >> >> http://lists.jboss.org/pipermail/keycloak-user/2014-November/001170.html >> >> We do not support OIDC scope param, but you can limit the application's >> scope in the admin console. >> >> On 11/13/2014 10:28 PM, Pratik Parikh wrote: >> > Hi Bill, >> > >> > Is this because both of my server (keycloak and aerogear are >> > https). Do i need to establish trust between them? >> > >> > Regards, >> > Pratik Parikh >> > >> > On Thu, Nov 13, 2014 at 8:18 PM, Pratik Parikh >> > > wrote: >> > >> > Hi Bill, >> > >> > Thanks i turned the scope off under the application but that >> > did not help. Could you please help us understand what is going >> > on. I am trying to look the code but seems like it is going to take >> > be a bit to figure it out. It seems like HttpFacade.Cookies is >> > suppose to have state cookie which is contained in >> > KeycloakDeployment. I did try what you suggest was that not >> > correctly understood by me? I am new to keycloak but this is a great >> > project would like to understand it and use it to its fullest >> > extend. Can you help me get past this problem. Thanks in advance. >> > >> > Regards, >> > -- >> > Pratik Parikh >> > - Mantra - Keep It Simple and Straightforward >> > >> > >> > >> > >> > -- >> > Pratik Parikh >> > - Mantra - Keep It Simple and Straightforward >> > >> > >> > _______________________________________________ >> > keycloak-user mailing list >> > keycloak-user at lists.jboss.org >> > https://lists.jboss.org/mailman/listinfo/keycloak-user >> > >> >> -- >> Bill Burke >> JBoss, a division of Red Hat >> http://bill.burkecentral.com >> _______________________________________________ >> keycloak-user mailing list >> keycloak-user at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-user >> > > > > -- > Pratik Parikh > - Mantra - Keep It Simple and Straightforward > -- Pratik Parikh - Mantra - Keep It Simple and Straightforward -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20141115/e9d3d8fa/attachment-0001.html From pratik.p.parikh at gmail.com Mon Nov 17 02:48:12 2014 From: pratik.p.parikh at gmail.com (Pratik Parikh) Date: Mon, 17 Nov 2014 02:48:12 -0500 Subject: [keycloak-user] failed verification of token In-Reply-To: References: <546607CF.7090205@redhat.com> Message-ID: Hi Bill, Another update: I was able to reslove SSL handsack issue. And can now assure that the trust between keycloak server and aerogear client is established. I am still running into an issue whereby upon login the adapter expects a cookie and does not find it? Does aerogear team have to enhance anything to obtain this "state cookie"?? below is the debug trace from aerogear side. Aerogear Log: 2014-11-17 07:40:21,804 DEBUG [org.keycloak.adapters.PreAuthActionsHandler] (default task-17) adminRequest https://XXX.XXX.XXX.XXX:8443/ag-push/index.html?code=IcrbsPykYJ5v8UeXHgmzSEldZpo58vUh2e3Ik9r6Yu8.75228531-4f07-4b99-9c4f-acd5abc111fd&state=322036a7-b0b6-40b7-852f-60aa592bce01 2014-11-17 07:40:21,804 DEBUG [org.keycloak.adapters.PreAuthActionsHandler] (default task-17) adminRequest https://XXX.XXX.XXX.XXX:8443/ag-push/index.html?code=IcrbsPykYJ5v8UeXHgmzSEldZpo58vUh2e3Ik9r6Yu8.75228531-4f07-4b99-9c4f-acd5abc111fd&state=322036a7-b0b6-40b7-852f-60aa592bce01 2014-11-17 07:40:21,804 DEBUG [org.keycloak.adapters.RequestAuthenticator] (default task-17) Account was not in session, returning null 2014-11-17 07:40:21,804 DEBUG [org.keycloak.adapters.OAuthRequestAuthenticator] (default task-17) there was a code, resolving 2014-11-17 07:40:21,804 DEBUG [org.keycloak.adapters.OAuthRequestAuthenticator] (default task-17) checking state cookie for after code 2014-11-17 07:40:21,804 WARN [org.keycloak.adapters.OAuthRequestAuthenticator] (default task-17) No state cookie Regards, Pratik Parikh On Sat, Nov 15, 2014 at 1:39 PM, Pratik Parikh wrote: > Hi Bill, > > My goal is get liveoak, aerogear and keycloak working on different > servers. LiveOak uses Keycloak and Aerogear. Following are the steps i > took. > > 1) Install Keycloak on one server with self signed certificate. It is > accessible via https://XXX.XXX.XXX.XXX:8443/auth > . Worked > 2) Installed AreoGear on another server with self signed certificate. > It is accessible via https://XXX.XXX.XXX.XXX:8443/ag-push > . Worked > 3) Imported attached JSON in as a new aerogear realm in keycloak. > Worked > 4) Updated Keycloak to use MongoDB. Worked > 5) Update application aerogear with keycloak.json restarted wildfly > server. Updated application under AreoGear to use > https://XXX.XXX.XXX.XXX:8443/ag-push/* > as a redirect uri. Worked. > 6) Restarted both the wildfly servers. > 7) After restart tried to login to > https://XXX.XXX.XXX.XXX:8443/ag-push/ > forwarded me to > https://XXX.XXX.XXX.XXX:8443/auth login > page. Successfull login was achieved. > 8) PROBLEM: After login redirect to > https://XXX.XXX.XXX.XXX:8443/ag-push/ > where by i get error "No state > cookie" in AreoGear log, which is coming from OAuthRequestAuthenticator > line 116 because the adapter can not find a cookie with name " > OAuth_Token_Request_State" in HTTP. > > Troubleshooting Try 1. > 1) updated aerogear to use 1.0.1.Beta1 Adapter. Still works does not > solve the problem same error. > > Troubleshooting Try 2. > 1) updated keycloak.json by adding *"disable-trust-manager": true*. > Still works does not solve the problem same error. > > Troubleshooting Try 3. > 1) updated keycloak.json by adding *"disable-trust-manager": > false,"truststore": "/path","truststore-password": "password"*. Still > works doe not solve the problem. I have a question is "*truststore*" a > local path to the keycloak jks cert or this is a path to remote keycloak > cert? I copied the keycloak.jks and pointed to that locally using ${jboss.server.config.dir}/trustcerts/keycloak.jks? > is this correct? After doing this i tried to invoke > > https://XXX.XXX.XXXX.XXXX:8443/ag-push/rest/ping > > Get the login screen > > then i get Forbidden with below exception: > > 2014-11-15 18:31:13,664 ERROR > [org.keycloak.adapters.OAuthRequestAuthenticator] (default task-6) failed > to turn code into token: javax.net.ssl.SSLPeerUnverifiedException: peer not > authenticated > at > sun.security.ssl.SSLSessionImpl.getPeerCertificates(SSLSessionImpl.java:431) > [jsse.jar:1.8.0_25] > at > org.apache.http.conn.ssl.AbstractVerifier.verify(AbstractVerifier.java:128) > [httpclient-4.2.1.jar:4.2.1] > at > org.apache.http.conn.ssl.SSLSocketFactory.connectSocket(SSLSocketFactory.java:572) > [httpclient-4.2.1.jar:4.2.1] > at > org.apache.http.impl.conn.DefaultClientConnectionOperator.openConnection(DefaultClientConnectionOperator.java:180) > [httpclient-4.2.1.jar:4.2.1] > at > org.apache.http.impl.conn.AbstractPoolEntry.open(AbstractPoolEntry.java:151) > [httpclient-4.2.1.jar:4.2.1] > at > org.apache.http.impl.conn.AbstractPooledConnAdapter.open(AbstractPooledConnAdapter.java:125) > [httpclient-4.2.1.jar:4.2.1] > at > org.apache.http.impl.client.DefaultRequestDirector.tryConnect(DefaultRequestDirector.java:640) > [httpclient-4.2.1.jar:4.2.1] > at > org.apache.http.impl.client.DefaultRequestDirector.execute(DefaultRequestDirector.java:479) > [httpclient-4.2.1.jar:4.2.1] > at > org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:906) > [httpclient-4.2.1.jar:4.2.1] > at > org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:805) > [httpclient-4.2.1.jar:4.2.1] > at > org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:784) > [httpclient-4.2.1.jar:4.2.1] > at > org.keycloak.adapters.ServerRequest.invokeAccessCodeToToken(ServerRequest.java:116) > [keycloak-adapter-core-1.0.4.Final.jar:] > at > org.keycloak.adapters.ServerRequest.invokeAccessCodeToToken(ServerRequest.java:93) > [keycloak-adapter-core-1.0.4.Final.jar:] > at > org.keycloak.adapters.OAuthRequestAuthenticator.resolveCode(OAuthRequestAuthenticator.java:256) > [keycloak-adapter-core-1.0.4.Final.jar:] > at > org.keycloak.adapters.OAuthRequestAuthenticator.authenticate(OAuthRequestAuthenticator.java:205) > [keycloak-adapter-core-1.0.4.Final.jar:] > at > org.keycloak.adapters.RequestAuthenticator.authenticate(RequestAuthenticator.java:68) > [keycloak-adapter-core-1.0.4.Final.jar:] > at > org.keycloak.adapters.undertow.UndertowKeycloakAuthMech.keycloakAuthenticate(UndertowKeycloakAuthMech.java:82) > [keycloak-undertow-adapter-1.0.4.Final.jar:] > at > org.keycloak.adapters.undertow.ServletKeycloakAuthMech.authenticate(ServletKeycloakAuthMech.java:61) > [keycloak-undertow-adapter-1.0.4.Final.jar:] > at > io.undertow.security.impl.SecurityContextImpl$AuthAttempter.transition(SecurityContextImpl.java:281) > [undertow-core-1.0.15.Final.jar:1.0.15.Final] > at > io.undertow.security.impl.SecurityContextImpl$AuthAttempter.transition(SecurityContextImpl.java:298) > [undertow-core-1.0.15.Final.jar:1.0.15.Final] > at > io.undertow.security.impl.SecurityContextImpl$AuthAttempter.access$100(SecurityContextImpl.java:268) > [undertow-core-1.0.15.Final.jar:1.0.15.Final] > at > io.undertow.security.impl.SecurityContextImpl.attemptAuthentication(SecurityContextImpl.java:131) > [undertow-core-1.0.15.Final.jar:1.0.15.Final] > at > io.undertow.security.impl.SecurityContextImpl.authTransition(SecurityContextImpl.java:106) > [undertow-core-1.0.15.Final.jar:1.0.15.Final] > at > io.undertow.security.impl.SecurityContextImpl.authenticate(SecurityContextImpl.java:99) > [undertow-core-1.0.15.Final.jar:1.0.15.Final] > at > io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:54) > [undertow-servlet-1.0.15.Final.jar:1.0.15.Final] > at > io.undertow.server.handlers.DisableCacheHandler.handleRequest(DisableCacheHandler.java:27) > [undertow-core-1.0.15.Final.jar:1.0.15.Final] > at > io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) > [undertow-core-1.0.15.Final.jar:1.0.15.Final] > at > io.undertow.security.handlers.AuthenticationConstraintHandler.handleRequest(AuthenticationConstraintHandler.java:51) > [undertow-core-1.0.15.Final.jar:1.0.15.Final] > at > io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45) > [undertow-core-1.0.15.Final.jar:1.0.15.Final] > at > io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:61) > [undertow-servlet-1.0.15.Final.jar:1.0.15.Final] > at > io.undertow.servlet.handlers.security.ServletSecurityConstraintHandler.handleRequest(ServletSecurityConstraintHandler.java:56) > [undertow-servlet-1.0.15.Final.jar:1.0.15.Final] > at > io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:58) > [undertow-core-1.0.15.Final.jar:1.0.15.Final] > at > io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:70) > [undertow-servlet-1.0.15.Final.jar:1.0.15.Final] > at > io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:76) > [undertow-core-1.0.15.Final.jar:1.0.15.Final] > at > io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) > [undertow-core-1.0.15.Final.jar:1.0.15.Final] > at > org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61) > at > io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) > [undertow-core-1.0.15.Final.jar:1.0.15.Final] > at > org.keycloak.adapters.undertow.ServletPreAuthActionsHandler.handleRequest(ServletPreAuthActionsHandler.java:69) > [keycloak-undertow-adapter-1.0.4.Final.jar:] > at > org.keycloak.adapters.undertow.ServletPreAuthActionsHandler.handleRequest(ServletPreAuthActionsHandler.java:69) > [keycloak-undertow-adapter-1.0.4.Final.jar:] > at > io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) > [undertow-core-1.0.15.Final.jar:1.0.15.Final] > at > io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:240) > [undertow-servlet-1.0.15.Final.jar:1.0.15.Final] > at > io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:227) > [undertow-servlet-1.0.15.Final.jar:1.0.15.Final] > at > io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:73) > [undertow-servlet-1.0.15.Final.jar:1.0.15.Final] > at > io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:146) > [undertow-servlet-1.0.15.Final.jar:1.0.15.Final] > at > io.undertow.server.Connectors.executeRootHandler(Connectors.java:177) > [undertow-core-1.0.15.Final.jar:1.0.15.Final] > at > io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:727) > [undertow-core-1.0.15.Final.jar:1.0.15.Final] > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > [rt.jar:1.8.0_25] > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > [rt.jar:1.8.0_25] > at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_25] > > Please help i feel like i am very close just missing something > simple. > > > Regards, > Pratik Parikh > > On Fri, Nov 14, 2014 at 9:34 AM, Pratik Parikh > wrote: > >> Hi Bill, >> >> My goal is get liveoak, aerogear and keycloak working on different >> servers. LiveOak uses Keycloak and Aerogear. Following are the steps i >> took. >> >> 1) Install Keycloak on one server with self signed certificate. It >> is accessible via https://XXX.XXX.XXX.XXX:8443/auth. Worked >> 2) Installed AreoGear on another server with self signed >> certificate. It is accessible via https://XXX.XXX.XXX.XXX:8443/ag-push. >> Worked >> 3) Imported attached JSON in as a new aerogear realm in keycloak. >> Worked >> 4) Updated Keycloak to use MongoDB. Worked >> 5) Update application aerogear with keycloak.json restarted wildfly >> server. Updated application under AreoGear to use >> https://XXX.XXX.XXX.XXX:8443/ag-push/* as a redirect uri. Worked. >> 6) Restarted both the wildfly servers. >> 7) After restart tried to login to >> https://XXX.XXX.XXX.XXX:8443/ag-push/ forwarded me to >> https://XXX.XXX.XXX.XXX:8443/auth login page. Successfull login was >> achieved. >> 8) PROBLEM: After login redirect to >> https://XXX.XXX.XXX.XXX:8443/ag-push/ where by i get error "No state >> cookie" in AreoGear log, which is coming from OAuthRequestAuthenticator >> line 116 because the adapter can not find a cookie with name " >> OAuth_Token_Request_State" in HTTP. >> >> Troubleshooting Try 1. >> 1) updated aerogear to use 1.0.1.Beta1 Adapter. Still works does not >> solve the problem same error. >> >> Troubleshooting Try 2. >> 1) updated keycloak.json by adding *"disable-trust-manager": true*. >> Still works does not solve the problem same error. >> >> Troubleshooting Try 2. Still have not done but will do today is >> 1) updated keycloak.json by adding *"disable-trust-manager": >> false,"truststore": "/path","truststore-password": "password"*. Will >> report back shortly. >> >> Regards, >> Pratik Parikh >> >> On Fri, Nov 14, 2014 at 8:46 AM, Bill Burke wrote: >> >>> Can you explain your problem again? I think I am misunderstanding what >>> problems you are having. You linked this message: >>> >>> http://lists.jboss.org/pipermail/keycloak-user/2014-November/001170.html >>> >>> We do not support OIDC scope param, but you can limit the application's >>> scope in the admin console. >>> >>> On 11/13/2014 10:28 PM, Pratik Parikh wrote: >>> > Hi Bill, >>> > >>> > Is this because both of my server (keycloak and aerogear are >>> > https). Do i need to establish trust between them? >>> > >>> > Regards, >>> > Pratik Parikh >>> > >>> > On Thu, Nov 13, 2014 at 8:18 PM, Pratik Parikh >>> > > wrote: >>> > >>> > Hi Bill, >>> > >>> > Thanks i turned the scope off under the application but that >>> > did not help. Could you please help us understand what is going >>> > on. I am trying to look the code but seems like it is going to >>> take >>> > be a bit to figure it out. It seems like HttpFacade.Cookies is >>> > suppose to have state cookie which is contained in >>> > KeycloakDeployment. I did try what you suggest was that not >>> > correctly understood by me? I am new to keycloak but this is a >>> great >>> > project would like to understand it and use it to its fullest >>> > extend. Can you help me get past this problem. Thanks in advance. >>> > >>> > Regards, >>> > -- >>> > Pratik Parikh >>> > - Mantra - Keep It Simple and Straightforward >>> > >>> > >>> > >>> > >>> > -- >>> > Pratik Parikh >>> > - Mantra - Keep It Simple and Straightforward >>> > >>> > >>> > _______________________________________________ >>> > keycloak-user mailing list >>> > keycloak-user at lists.jboss.org >>> > https://lists.jboss.org/mailman/listinfo/keycloak-user >>> > >>> >>> -- >>> Bill Burke >>> JBoss, a division of Red Hat >>> http://bill.burkecentral.com >>> _______________________________________________ >>> keycloak-user mailing list >>> keycloak-user at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/keycloak-user >>> >> >> >> >> -- >> Pratik Parikh >> - Mantra - Keep It Simple and Straightforward >> > > > > -- > Pratik Parikh > - Mantra - Keep It Simple and Straightforward > -- Pratik Parikh - Mantra - Keep It Simple and Straightforward -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20141117/06a3f866/attachment-0001.html From pratik.p.parikh at gmail.com Mon Nov 17 18:35:34 2014 From: pratik.p.parikh at gmail.com (Pratik Parikh) Date: Mon, 17 Nov 2014 18:35:34 -0500 Subject: [keycloak-user] keycloak.config.resolver - What example is best to understand? Message-ID: Dear All, What is the best example to understand use of keycloak.config.resolver?? Regards, -- Pratik Parikh - Mantra - Keep It Simple and Straightforward -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20141117/3e073549/attachment.html From stian at redhat.com Tue Nov 18 01:50:23 2014 From: stian at redhat.com (Stian Thorgersen) Date: Tue, 18 Nov 2014 01:50:23 -0500 (EST) Subject: [keycloak-user] keycloak.config.resolver - What example is best to understand? In-Reply-To: References: Message-ID: <489609159.779843.1416293423496.JavaMail.zimbra@redhat.com> It's for multi-tenancy support in the adapter The multi-tenant example shows how it works and also look at http://docs.jboss.org/keycloak/docs/1.1.0.Beta1/userguide/html/ch07.html#multi_tenancy ----- Original Message ----- > From: "Pratik Parikh" > To: keycloak-user at lists.jboss.org > Sent: Tuesday, November 18, 2014 12:35:34 AM > Subject: [keycloak-user] keycloak.config.resolver - What example is best to understand? > > Dear All, > > What is the best example to understand use of keycloak.config.resolver?? > > Regards, > -- > Pratik Parikh > - Mantra - Keep It Simple and Straightforward > > _______________________________________________ > keycloak-user mailing list > keycloak-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user From juraci at kroehling.de Tue Nov 18 09:31:55 2014 From: juraci at kroehling.de (=?windows-1252?Q?Juraci_Paix=E3o_Kr=F6hling?=) Date: Tue, 18 Nov 2014 15:31:55 +0100 Subject: [keycloak-user] "Invalid state param" for KeycloakInstalled In-Reply-To: <54661196.8040904@kroehling.de> References: <54661196.8040904@kroehling.de> Message-ID: <546B585B.4090908@kroehling.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 It seems that adding a simple "state=" to the end of the URL made it work. Is this a new requirement? If so, I guess the examples that uses it needs to be updated :-) - - Juca. On 11/14/2014 03:28 PM, Juraci Paix?o Kr?hling wrote: > Hello, > > I'm trying to use the KeycloakInstalled to authenticate an user > via CLI and I'm getting a "Invalid State param" message on the URL > that it asks the user to open. > > Code: KeycloakInstalled keycloak = new KeycloakInstalled(); > keycloak.loginManual(); > > The generated URL is: > > http://localhost:8080/auth/realms/acme-roadrunner-affairs/protocol/openid-connect/login?client_id=installed&redirect_uri=urn%3Aietf%3Awg%3Aoauth%3A2.0%3Aoob > > "acme-roadrunner-affairs" is the realm, and "installed" is an > OAuth client registered on this realm, with a "redirect URI" as > "urn:ietf:wg:oauth:2.0:oob" > > Am I missing some configuration? > > - Juca. _______________________________________________ > keycloak-user mailing list keycloak-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBCgAGBQJUa1hbAAoJEDnJtskdmzLMHm4H/jZbCyF3qyqijNEB1o15euhn 7fBt/8JTXxR/VQO1NDsxbAF8IhR+SE2UPe1UA8H8HF+2Rcbiew5KU1TSrVN4gm1s xwsOu5EFBhUSFqIhZtNU5AKZksJGpTTjf0zvEhJuiOu33jQoOVpvngOwtArAvsjv mUuc2fkSygY5oxl/JUaB/rF3qN2iOJPQ2FeA5U1ThkpQzq5ChzZs/hzOUcd8xH7p ijsSWDd5HYRklpjomtNBOh9q/jOE5kcdr2lwUb0wSnZKA3t6l8U5phQ4maTzJHdt B7QfDeG6KTVhdpZGHcGP2Gy3qTpIaV1UX9I+xMsgLlU7XPpbsrhhcFUaTqiaOLg= =QEXp -----END PGP SIGNATURE----- From juraci at kroehling.de Tue Nov 18 09:40:55 2014 From: juraci at kroehling.de (=?windows-1252?Q?Juraci_Paix=E3o_Kr=F6hling?=) Date: Tue, 18 Nov 2014 15:40:55 +0100 Subject: [keycloak-user] Recommendations for protecting REST service with bearer token and basic auth In-Reply-To: <5464E33F.9010601@kroehling.de> References: <1845864658.5951344.1415369800735.JavaMail.zimbra@redhat.com> <545D7D75.8050500@redhat.com> <279836542.6533747.1415607641136.JavaMail.zimbra@redhat.com> <5460BFDB.1060606@redhat.com> <5464E33F.9010601@kroehling.de> Message-ID: <546B5A77.9070408@kroehling.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Any thoughts on that? My use case is similar to a regular "SaaS", in which I'd provide an API key and API secret (or a single token, or ...) to the users, which can then use those credentials on simple bash scripts. - - Juca. On 11/13/2014 05:58 PM, Juraci Paix?o Kr?hling wrote: > On 11/10/2014 02:38 PM, Bill Burke wrote: >> With basic auth, you have zero control over the client and >> you're handing over credentials to that client. Simple and easy >> for "hello world" apps sure. > > Would it make sense to add something like Google's "Application > Specific Passwords"? This way, it's not the main credentials which > are being shared and those can be revoked individually if > necessary. > > An application that is not OAuth capable for some reason could > then make use of this. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBCgAGBQJUa1p3AAoJEDnJtskdmzLMPQoH/ijvMSaxeXY5GeDYv+Rfrrua UifH2J+bCIB+0YYM/yTCbyiLO1ohFovB4QB9iqkL77OOiFSP9obx8PfxOBTJJuN5 yDoD7ZBJlnFIUDiN9HmVeDH7x1qiVyTDmUbfo+tfoHfk/QUr0nQ4BfzfSQpe9wk7 5SNhBvCxtNRqNG9w52EujlEmLI7cXuBWOz39cKm8AYfVkKnf/2L8M6f9hd7x0uDZ y1Va/u42GrHhWXjuVwuSG2hv1xWok92i3LM8xsJst3icSu2kbB9q7WnAA38bq4CN 6kE3j/OhNRSY69MyPbPaZNVRJgAK47mcco0/K76x/2cDTai4PI+W1n/FNz4m4Fw= =9Lyk -----END PGP SIGNATURE----- From stian at redhat.com Tue Nov 18 10:19:52 2014 From: stian at redhat.com (Stian Thorgersen) Date: Tue, 18 Nov 2014 10:19:52 -0500 (EST) Subject: [keycloak-user] "Invalid state param" for KeycloakInstalled In-Reply-To: <546B585B.4090908@kroehling.de> References: <54661196.8040904@kroehling.de> <546B585B.4090908@kroehling.de> Message-ID: <1622852332.1140317.1416323992979.JavaMail.zimbra@redhat.com> The installed adapter should be generating a state variable and add it to the URL, it should also check the state when it retrieves the code. Can you JIRA please? ----- Original Message ----- > From: "Juraci Paix?o Kr?hling" > To: keycloak-user at lists.jboss.org > Sent: Tuesday, 18 November, 2014 3:31:55 PM > Subject: Re: [keycloak-user] "Invalid state param" for KeycloakInstalled > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 > > It seems that adding a simple "state=" to the end of the URL made it > work. Is this a new requirement? If so, I guess the examples that uses > it needs to be updated :-) > > - - Juca. > > On 11/14/2014 03:28 PM, Juraci Paix?o Kr?hling wrote: > > Hello, > > > > I'm trying to use the KeycloakInstalled to authenticate an user > > via CLI and I'm getting a "Invalid State param" message on the URL > > that it asks the user to open. > > > > Code: KeycloakInstalled keycloak = new KeycloakInstalled(); > > keycloak.loginManual(); > > > > The generated URL is: > > > > http://localhost:8080/auth/realms/acme-roadrunner-affairs/protocol/openid-connect/login?client_id=installed&redirect_uri=urn%3Aietf%3Awg%3Aoauth%3A2.0%3Aoob > > > > "acme-roadrunner-affairs" is the realm, and "installed" is an > > OAuth client registered on this realm, with a "redirect URI" as > > "urn:ietf:wg:oauth:2.0:oob" > > > > Am I missing some configuration? > > > > - Juca. _______________________________________________ > > keycloak-user mailing list keycloak-user at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/keycloak-user > > > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1 > > iQEcBAEBCgAGBQJUa1hbAAoJEDnJtskdmzLMHm4H/jZbCyF3qyqijNEB1o15euhn > 7fBt/8JTXxR/VQO1NDsxbAF8IhR+SE2UPe1UA8H8HF+2Rcbiew5KU1TSrVN4gm1s > xwsOu5EFBhUSFqIhZtNU5AKZksJGpTTjf0zvEhJuiOu33jQoOVpvngOwtArAvsjv > mUuc2fkSygY5oxl/JUaB/rF3qN2iOJPQ2FeA5U1ThkpQzq5ChzZs/hzOUcd8xH7p > ijsSWDd5HYRklpjomtNBOh9q/jOE5kcdr2lwUb0wSnZKA3t6l8U5phQ4maTzJHdt > B7QfDeG6KTVhdpZGHcGP2Gy3qTpIaV1UX9I+xMsgLlU7XPpbsrhhcFUaTqiaOLg= > =QEXp > -----END PGP SIGNATURE----- > _______________________________________________ > keycloak-user mailing list > keycloak-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user > From bburke at redhat.com Tue Nov 18 10:21:23 2014 From: bburke at redhat.com (Bill Burke) Date: Tue, 18 Nov 2014 10:21:23 -0500 Subject: [keycloak-user] Recommendations for protecting REST service with bearer token and basic auth In-Reply-To: <546B5A77.9070408@kroehling.de> References: <1845864658.5951344.1415369800735.JavaMail.zimbra@redhat.com> <545D7D75.8050500@redhat.com> <279836542.6533747.1415607641136.JavaMail.zimbra@redhat.com> <5460BFDB.1060606@redhat.com> <5464E33F.9010601@kroehling.de> <546B5A77.9070408@kroehling.de> Message-ID: <546B63F3.3090200@redhat.com> How is that any different than our access tokens? On 11/18/2014 9:40 AM, Juraci Paix?o Kr?hling wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 > > Any thoughts on that? > > My use case is similar to a regular "SaaS", in which I'd provide an > API key and API secret (or a single token, or ...) to the users, which > can then use those credentials on simple bash scripts. > > - - Juca. > > > On 11/13/2014 05:58 PM, Juraci Paix?o Kr?hling wrote: >> On 11/10/2014 02:38 PM, Bill Burke wrote: >>> With basic auth, you have zero control over the client and >>> you're handing over credentials to that client. Simple and easy >>> for "hello world" apps sure. >> >> Would it make sense to add something like Google's "Application >> Specific Passwords"? This way, it's not the main credentials which >> are being shared and those can be revoked individually if >> necessary. >> >> An application that is not OAuth capable for some reason could >> then make use of this. > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1 > > iQEcBAEBCgAGBQJUa1p3AAoJEDnJtskdmzLMPQoH/ijvMSaxeXY5GeDYv+Rfrrua > UifH2J+bCIB+0YYM/yTCbyiLO1ohFovB4QB9iqkL77OOiFSP9obx8PfxOBTJJuN5 > yDoD7ZBJlnFIUDiN9HmVeDH7x1qiVyTDmUbfo+tfoHfk/QUr0nQ4BfzfSQpe9wk7 > 5SNhBvCxtNRqNG9w52EujlEmLI7cXuBWOz39cKm8AYfVkKnf/2L8M6f9hd7x0uDZ > y1Va/u42GrHhWXjuVwuSG2hv1xWok92i3LM8xsJst3icSu2kbB9q7WnAA38bq4CN > 6kE3j/OhNRSY69MyPbPaZNVRJgAK47mcco0/K76x/2cDTai4PI+W1n/FNz4m4Fw= > =9Lyk > -----END PGP SIGNATURE----- > _______________________________________________ > keycloak-user mailing list > keycloak-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user > -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From juraci at kroehling.de Tue Nov 18 10:36:11 2014 From: juraci at kroehling.de (=?windows-1252?Q?Juraci_Paix=E3o_Kr=F6hling?=) Date: Tue, 18 Nov 2014 16:36:11 +0100 Subject: [keycloak-user] Recommendations for protecting REST service with bearer token and basic auth In-Reply-To: <546B63F3.3090200@redhat.com> References: <1845864658.5951344.1415369800735.JavaMail.zimbra@redhat.com> <545D7D75.8050500@redhat.com> <279836542.6533747.1415607641136.JavaMail.zimbra@redhat.com> <5460BFDB.1060606@redhat.com> <5464E33F.9010601@kroehling.de> <546B5A77.9070408@kroehling.de> <546B63F3.3090200@redhat.com> Message-ID: <546B676B.7020708@kroehling.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 11/18/2014 04:21 PM, Bill Burke wrote: > How is that any different than our access tokens? To obtain an access token, I'd still need to talk with the Auth server and then, based on the response (ie, synchronously), send a request with a bearer token to the service. This is not viable when the client sends several (thousands of) requests to the service. That without mentioning the difficulties in parsing tokens via a shell script. - - Juca. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBCgAGBQJUa2drAAoJEDnJtskdmzLMBcQH/ivngsWkJRYFDEKkhWRFnLbq QS/cm4qx6t9YeQt0fWX0hHbRKtMO9wZNDKcPotd5Schx2Rry86g2FbulBg+6Pb2p V8G4s0sTSh8jTcZZLlg8756IKwBIpX3xm05nx2TpxWg1d1MwrZb4d533vRevJkmP nZpugEIB6btE5LrnnW5XbU1GdtkowTMuXAVCCUIa8PvtpOY8UfWQCPAakPx+er7l 7Ejjv3hEyaSs2pl8kjVJ41c4skWNOymPmUfgK5CzTthltElNzi675wmHMWjuaUbd 2jnyns6savc9uOslTfugg3cs7gP0BZV5NRd7wN/LTMxxUzbp9cCuTNfKD5T3ceE= =pYMG -----END PGP SIGNATURE----- From alarik at zwift.com Tue Nov 18 12:28:51 2014 From: alarik at zwift.com (Alarik Myrin) Date: Tue, 18 Nov 2014 12:28:51 -0500 Subject: [keycloak-user] Users assigned to roles Message-ID: Is there any easy way to see which users have been assigned a given role? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20141118/a03c030a/attachment.html From alarik at zwift.com Tue Nov 18 12:37:31 2014 From: alarik at zwift.com (Alarik Myrin) Date: Tue, 18 Nov 2014 12:37:31 -0500 Subject: [keycloak-user] Users assigned to roles In-Reply-To: References: Message-ID: I was able to piece together a SQL query: SELECT u.username, u.first_name, u.last_name, role.name AS role FROM keycloak_role role INNER JOIN realm ON role.realm = realm.id INNER JOIN user_role_mapping rm ON role.id = rm.role_id INNER JOIN user_entity u ON rm.user_id = u.id WHERE realm.name=:1 AND role.name = :2 It might be nice to do this in the web console though... On Tue, Nov 18, 2014 at 12:28 PM, Alarik Myrin wrote: > Is there any easy way to see which users have been assigned a given role? > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20141118/f64c1620/attachment.html From stian at redhat.com Wed Nov 19 03:33:42 2014 From: stian at redhat.com (Stian Thorgersen) Date: Wed, 19 Nov 2014 03:33:42 -0500 (EST) Subject: [keycloak-user] Recommendations for protecting REST service with bearer token and basic auth In-Reply-To: <546B676B.7020708@kroehling.de> References: <1845864658.5951344.1415369800735.JavaMail.zimbra@redhat.com> <545D7D75.8050500@redhat.com> <279836542.6533747.1415607641136.JavaMail.zimbra@redhat.com> <5460BFDB.1060606@redhat.com> <5464E33F.9010601@kroehling.de> <546B5A77.9070408@kroehling.de> <546B63F3.3090200@redhat.com> <546B676B.7020708@kroehling.de> Message-ID: <1265926769.1688381.1416386022401.JavaMail.zimbra@redhat.com> ----- Original Message ----- > From: "Juraci Paix?o Kr?hling" > To: keycloak-user at lists.jboss.org > Sent: Tuesday, November 18, 2014 4:36:11 PM > Subject: Re: [keycloak-user] Recommendations for protecting REST service with bearer token and basic auth > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 > > On 11/18/2014 04:21 PM, Bill Burke wrote: > > How is that any different than our access tokens? > > To obtain an access token, I'd still need to talk with the Auth server > and then, based on the response (ie, synchronously), send a request > with a bearer token to the service. This is not viable when the client > sends several (thousands of) requests to the service. Why does the shell script have to talk to the auth server for every request? It should cache the token, not the users credentials. > > That without mentioning the difficulties in parsing tokens via a shell > script. Why does the shell script have to parse the token? Does it not just pass it on to the rest services it invokes. > > - - Juca. > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1 > > iQEcBAEBCgAGBQJUa2drAAoJEDnJtskdmzLMBcQH/ivngsWkJRYFDEKkhWRFnLbq > QS/cm4qx6t9YeQt0fWX0hHbRKtMO9wZNDKcPotd5Schx2Rry86g2FbulBg+6Pb2p > V8G4s0sTSh8jTcZZLlg8756IKwBIpX3xm05nx2TpxWg1d1MwrZb4d533vRevJkmP > nZpugEIB6btE5LrnnW5XbU1GdtkowTMuXAVCCUIa8PvtpOY8UfWQCPAakPx+er7l > 7Ejjv3hEyaSs2pl8kjVJ41c4skWNOymPmUfgK5CzTthltElNzi675wmHMWjuaUbd > 2jnyns6savc9uOslTfugg3cs7gP0BZV5NRd7wN/LTMxxUzbp9cCuTNfKD5T3ceE= > =pYMG > -----END PGP SIGNATURE----- > _______________________________________________ > keycloak-user mailing list > keycloak-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user > From stian at redhat.com Wed Nov 19 03:34:32 2014 From: stian at redhat.com (Stian Thorgersen) Date: Wed, 19 Nov 2014 03:34:32 -0500 (EST) Subject: [keycloak-user] Users assigned to roles In-Reply-To: References: Message-ID: <637183293.1688600.1416386072654.JavaMail.zimbra@redhat.com> ----- Original Message ----- > From: "Alarik Myrin" > To: keycloak-user at lists.jboss.org > Sent: Tuesday, November 18, 2014 6:37:31 PM > Subject: Re: [keycloak-user] Users assigned to roles > > I was able to piece together a SQL query: > > > > SELECT u.username, u.first_name, u.last_name, role.name AS role > > FROM keycloak_role role > > INNER JOIN realm ON role.realm = realm.id > > INNER JOIN user_role_mapping rm ON role.id = rm.role_id > > INNER JOIN user_entity u ON rm.user_id = u.id > > WHERE realm.name =:1 AND role.name = :2 > > It might be nice to do this in the web console though... Yep, please JIRA > > On Tue, Nov 18, 2014 at 12:28 PM, Alarik Myrin < alarik at zwift.com > wrote: > > > > Is there any easy way to see which users have been assigned a given role? > > > _______________________________________________ > keycloak-user mailing list > keycloak-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user From mposolda at redhat.com Wed Nov 19 03:39:02 2014 From: mposolda at redhat.com (Marek Posolda) Date: Wed, 19 Nov 2014 09:39:02 +0100 Subject: [keycloak-user] Users assigned to roles In-Reply-To: References: Message-ID: <546C5726.7050401@redhat.com> I don't think we have this at this moment. Feel free to create jira, but no promise if/when we provide it... btv. it seems that your query doesn't handle composite roles, but really just those roles, which are directly assigned to user in user_role_mapping table. I don't know if you care about it... Fact is that doing single SQL query including composite roles is probably not doable unless you are on Oracle, which allows some kind of hierarchical queries afaik. Marek On 18.11.2014 18:37, Alarik Myrin wrote: > I was able to piece together a SQL query: > > SELECT u.username, u.first_name, u.last_name, role.name > AS role > > FROM keycloak_role role > > INNER JOIN realm ON role.realm = realm.id > > INNER JOIN user_role_mapping rm ON role.id = rm.role_id > > INNER JOIN user_entity u ON rm.user_id = u.id > > WHERE realm.name =:1 AND role.name > = :2 > > It might be nice to do this in the web console though... > > > On Tue, Nov 18, 2014 at 12:28 PM, Alarik Myrin > wrote: > > Is there any easy way to see which users have been assigned a > given role? > > > > > _______________________________________________ > 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-user/attachments/20141119/c71e48c6/attachment.html From stian at redhat.com Wed Nov 19 03:59:35 2014 From: stian at redhat.com (Stian Thorgersen) Date: Wed, 19 Nov 2014 03:59:35 -0500 (EST) Subject: [keycloak-user] Users assigned to roles In-Reply-To: <546C5726.7050401@redhat.com> References: <546C5726.7050401@redhat.com> Message-ID: <1637251039.1697409.1416387575344.JavaMail.zimbra@redhat.com> ----- Original Message ----- > From: "Marek Posolda" > To: "Alarik Myrin" , keycloak-user at lists.jboss.org > Sent: Wednesday, November 19, 2014 9:39:02 AM > Subject: Re: [keycloak-user] Users assigned to roles > > I don't think we have this at this moment. Feel free to create jira, but no > promise if/when we provide it... > > btv. it seems that your query doesn't handle composite roles, but really just > those roles, which are directly assigned to user in user_role_mapping table. > I don't know if you care about it... Fact is that doing single SQL query > including composite roles is probably not doable unless you are on Oracle, > which allows some kind of hierarchical queries afaik. I reckon you could do it with an inner select that gets all roles that maps to the given role or is the role. > > Marek > > On 18.11.2014 18:37, Alarik Myrin wrote: > > > > I was able to piece together a SQL query: > > > > SELECT u.username, u.first_name, u.last_name, role.name AS role > > FROM keycloak_role role > > INNER JOIN realm ON role.realm = realm.id > > INNER JOIN user_role_mapping rm ON role.id = rm.role_id > > INNER JOIN user_entity u ON rm.user_id = u.id > > WHERE realm.name =:1 AND role.name = :2 > > It might be nice to do this in the web console though... > > On Tue, Nov 18, 2014 at 12:28 PM, Alarik Myrin < alarik at zwift.com > wrote: > > > > Is there any easy way to see which users have been assigned a given role? > > > > _______________________________________________ > keycloak-user mailing list keycloak-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user > > > _______________________________________________ > keycloak-user mailing list > keycloak-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user From juraci at kroehling.de Wed Nov 19 04:33:42 2014 From: juraci at kroehling.de (=?UTF-8?B?SnVyYWNpIFBhaXjDo28gS3LDtmhsaW5n?=) Date: Wed, 19 Nov 2014 10:33:42 +0100 Subject: [keycloak-user] Recommendations for protecting REST service with bearer token and basic auth In-Reply-To: <1265926769.1688381.1416386022401.JavaMail.zimbra@redhat.com> References: <1845864658.5951344.1415369800735.JavaMail.zimbra@redhat.com> <545D7D75.8050500@redhat.com> <279836542.6533747.1415607641136.JavaMail.zimbra@redhat.com> <5460BFDB.1060606@redhat.com> <5464E33F.9010601@kroehling.de> <546B5A77.9070408@kroehling.de> <546B63F3.3090200@redhat.com> <546B676B.7020708@kroehling.de> <1265926769.1688381.1416386022401.JavaMail.zimbra@redhat.com> Message-ID: <546C63F6.50406@kroehling.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 11/19/2014 09:33 AM, Stian Thorgersen wrote: > ----- Original Message ----- >> From: "Juraci Paix?o Kr?hling" To: >> keycloak-user at lists.jboss.org Sent: Tuesday, November 18, 2014 >> 4:36:11 PM Subject: Re: [keycloak-user] Recommendations for >> protecting REST service with bearer token and basic auth > > To obtain an access token, I'd still need to talk with the Auth > server and then, based on the response (ie, synchronously), send a > request with a bearer token to the service. This is not viable when > the client sends several (thousands of) requests to the service. > >> Why does the shell script have to talk to the auth server for >> every request? It should cache the token, not the users >> credentials. I have the strong feeling that I'm missing something very fundamental here, so, I'd be very glad if you could correct me if I'm wrong. I got more time thinking about this, and you are right, caching the tokens is pretty much the only solution that could make this work. But still, it's not very optimal. As I see it, if I have one "business" script, I need two extra scripts. First script: - - User runs the bash script for the first time - - Script generates an URL for the user to open in a browser - - User copies the code from the Keycloak server into the local file system - - Script exchanges this code for a refresh token and stores the refresh token in the local system. Second script: - - Runs every N minutes, where N < "the expiration in minutes of the tokens", updating the refresh and access tokens, and writing it somewhere in the local file system. Third script (my business): - - Reads the token from the local file system and calls the backend. The third script might still fail, if it tries to read the token while it's being written by the second script, but this is manageable. Now, how to handle a multi-host scenario? The user would hopefully not need to execute "first-script" at each host. For that, some sort of token-propagation among the hosts would need to exist. In other words, during peak time, when I spawn more worker hosts, the new hosts would only need to execute scripts 2 and 3. What I'm proposing is something like this: - - User access the "my account" page - - Copies a token/code/secret/key into somewhere in the system - - Bash script reads it and uses it for each backend request, knowing that it will fail only when the user actively revokes this key from his account. Thus, no need for the first script or second script, and no need for any token propagation. I can just spawn new hosts at any time, as the key could be stored in its kickstart file. > > That without mentioning the difficulties in parsing tokens via a > shell script. > >> Why does the shell script have to parse the token? Does it not >> just pass it on to the rest services it invokes. > My bad, not "parsing tokens" but "parsing JSON" (when getting the access token from a refresh token request). - - Juca. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBCgAGBQJUbGP2AAoJEDnJtskdmzLMqmQIAKrszmTAx1Ycrc9PR59SzGZc wTVsHinAREsYFYirIZ5LHVirrw5mihiy93zMmUg0FhlwMqr/vbQXpDBCr683U+ku cENofdO+RXg0TxHavNlUd1St5z+Evf1hGO6vdCczDAO0uemEcTnFujJZCTiIKrzk HNDPnCsGruxCi4IHBhGKFfTFz5mfaeh9zbKF4s7TcevOayUk8RLyCJwWMnxMhQ4u vOjw3UEpToomGkMTc7sToCA+dYOfBtMzm56YB15NdwyTNzZoY6FWiAkx8mIqI272 YMe2sb3AmddrNWZWQG0XH5Nb3dEXOOp0n/IN25uJu/qsj/pTrmbX+Qm3N1j145M= =sSDP -----END PGP SIGNATURE----- From mposolda at redhat.com Wed Nov 19 06:23:19 2014 From: mposolda at redhat.com (Marek Posolda) Date: Wed, 19 Nov 2014 12:23:19 +0100 Subject: [keycloak-user] Users assigned to roles In-Reply-To: <1637251039.1697409.1416387575344.JavaMail.zimbra@redhat.com> References: <546C5726.7050401@redhat.com> <1637251039.1697409.1416387575344.JavaMail.zimbra@redhat.com> Message-ID: <546C7DA7.4050603@redhat.com> On 19.11.2014 09:59, Stian Thorgersen wrote: > > ----- Original Message ----- >> From: "Marek Posolda" >> To: "Alarik Myrin" , keycloak-user at lists.jboss.org >> Sent: Wednesday, November 19, 2014 9:39:02 AM >> Subject: Re: [keycloak-user] Users assigned to roles >> >> I don't think we have this at this moment. Feel free to create jira, but no >> promise if/when we provide it... >> >> btv. it seems that your query doesn't handle composite roles, but really just >> those roles, which are directly assigned to user in user_role_mapping table. >> I don't know if you care about it... Fact is that doing single SQL query >> including composite roles is probably not doable unless you are on Oracle, >> which allows some kind of hierarchical queries afaik. > I reckon you could do it with an inner select that gets all roles that maps to the given role or is the role. hmm... it seems to me that this will handle just role and it's parent roles, but not whole hierarchy. Like if I have 'roleA', which has composite subrole 'roleB' and this has another one 'roleC'. Now when I want to know users with permission of 'roleC', then with inner join, I am able to find users mapped in user_role_mappings table to 'roleC' and 'roleB' but those mapped to 'roleA' won't be returned imo. Recursive hierarchical queries are supported by Oracle and I just figured from http://en.wikipedia.org/wiki/Hierarchical_and_recursive_queries_in_SQL that there are more databases like PostgreSQL and MSSQL with some support via "Common table expression" . It might be interesting SQL exercise to return all users in single query though:-) Marek > >> Marek >> >> On 18.11.2014 18:37, Alarik Myrin wrote: >> >> >> >> I was able to piece together a SQL query: >> >> >> >> SELECT u.username, u.first_name, u.last_name, role.name AS role >> >> FROM keycloak_role role >> >> INNER JOIN realm ON role.realm = realm.id >> >> INNER JOIN user_role_mapping rm ON role.id = rm.role_id >> >> INNER JOIN user_entity u ON rm.user_id = u.id >> >> WHERE realm.name =:1 AND role.name = :2 >> >> It might be nice to do this in the web console though... >> >> On Tue, Nov 18, 2014 at 12:28 PM, Alarik Myrin < alarik at zwift.com > wrote: >> >> >> >> Is there any easy way to see which users have been assigned a given role? >> >> >> >> _______________________________________________ >> keycloak-user mailing list keycloak-user at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-user >> >> >> _______________________________________________ >> keycloak-user mailing list >> keycloak-user at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-user From stian at redhat.com Wed Nov 19 07:01:18 2014 From: stian at redhat.com (Stian Thorgersen) Date: Wed, 19 Nov 2014 07:01:18 -0500 (EST) Subject: [keycloak-user] Recommendations for protecting REST service with bearer token and basic auth In-Reply-To: <546C63F6.50406@kroehling.de> References: <1845864658.5951344.1415369800735.JavaMail.zimbra@redhat.com> <5460BFDB.1060606@redhat.com> <5464E33F.9010601@kroehling.de> <546B5A77.9070408@kroehling.de> <546B63F3.3090200@redhat.com> <546B676B.7020708@kroehling.de> <1265926769.1688381.1416386022401.JavaMail.zimbra@redhat.com> <546C63F6.50406@kroehling.de> Message-ID: <1769288502.1847810.1416398478191.JavaMail.zimbra@redhat.com> First thing, is this script a CLI that a user invokes, a background process that runs on behalf of the user, or a server? If it's a CLI I'd say it should ask user for username/password and use direct grant to obtain token. The refresh token could be saved in a tmp file, or in users home directory. Next time the CLI wants to invoke this it'll need to make sure the token isn't expired, if it is refresh before invoking the service. If it's a background process you'll need a setup script that asks users for username/password or as you suggest use a browser to login. After that it's the same as above. One exception though is that in this case you probably want an offline token, which is something we don't support yet. Basically an offline token would be a token that's not associated with a specific user session, which would have a longer (possibly unlimited) lifetime. The user would also need to be able to view and revoke these tokens through the account management. If it's a server it should use a certificate to authenticate the server itself. Also, it should use a "service account" rather than a regular user account. Again, this is something we don't have atm. We only have regular user accounts and passwords. ----- Original Message ----- > From: "Juraci Paix?o Kr?hling" > To: "Stian Thorgersen" > Cc: keycloak-user at lists.jboss.org > Sent: Wednesday, November 19, 2014 10:33:42 AM > Subject: Re: [keycloak-user] Recommendations for protecting REST service with bearer token and basic auth > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 > > On 11/19/2014 09:33 AM, Stian Thorgersen wrote: > > ----- Original Message ----- > >> From: "Juraci Paix?o Kr?hling" To: > >> keycloak-user at lists.jboss.org Sent: Tuesday, November 18, 2014 > >> 4:36:11 PM Subject: Re: [keycloak-user] Recommendations for > >> protecting REST service with bearer token and basic auth > > > > To obtain an access token, I'd still need to talk with the Auth > > server and then, based on the response (ie, synchronously), send a > > request with a bearer token to the service. This is not viable when > > the client sends several (thousands of) requests to the service. > > > >> Why does the shell script have to talk to the auth server for > >> every request? It should cache the token, not the users > >> credentials. > > I have the strong feeling that I'm missing something very fundamental > here, so, I'd be very glad if you could correct me if I'm wrong. > > I got more time thinking about this, and you are right, caching the > tokens is pretty much the only solution that could make this work. But > still, it's not very optimal. As I see it, if I have one "business" > script, I need two extra scripts. > > First script: > - - User runs the bash script for the first time > - - Script generates an URL for the user to open in a browser > - - User copies the code from the Keycloak server into the local file system > - - Script exchanges this code for a refresh token and stores the > refresh token in the local system. > > Second script: > - - Runs every N minutes, where N < "the expiration in minutes of the > tokens", updating the refresh and access tokens, and writing it > somewhere in the local file system. > > Third script (my business): > - - Reads the token from the local file system and calls the backend. > > The third script might still fail, if it tries to read the token while > it's being written by the second script, but this is manageable. > > Now, how to handle a multi-host scenario? The user would hopefully not > need to execute "first-script" at each host. For that, some sort of > token-propagation among the hosts would need to exist. In other words, > during peak time, when I spawn more worker hosts, the new hosts would > only need to execute scripts 2 and 3. > > What I'm proposing is something like this: > > - - User access the "my account" page > - - Copies a token/code/secret/key into somewhere in the system > - - Bash script reads it and uses it for each backend request, knowing > that it will fail only when the user actively revokes this key from > his account. > > Thus, no need for the first script or second script, and no need for > any token propagation. I can just spawn new hosts at any time, as the > key could be stored in its kickstart file. > > > > > That without mentioning the difficulties in parsing tokens via a > > shell script. > > > >> Why does the shell script have to parse the token? Does it not > >> just pass it on to the rest services it invokes. > > > > My bad, not "parsing tokens" but "parsing JSON" (when getting the > access token from a refresh token request). > > - - Juca. > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1 > > iQEcBAEBCgAGBQJUbGP2AAoJEDnJtskdmzLMqmQIAKrszmTAx1Ycrc9PR59SzGZc > wTVsHinAREsYFYirIZ5LHVirrw5mihiy93zMmUg0FhlwMqr/vbQXpDBCr683U+ku > cENofdO+RXg0TxHavNlUd1St5z+Evf1hGO6vdCczDAO0uemEcTnFujJZCTiIKrzk > HNDPnCsGruxCi4IHBhGKFfTFz5mfaeh9zbKF4s7TcevOayUk8RLyCJwWMnxMhQ4u > vOjw3UEpToomGkMTc7sToCA+dYOfBtMzm56YB15NdwyTNzZoY6FWiAkx8mIqI272 > YMe2sb3AmddrNWZWQG0XH5Nb3dEXOOp0n/IN25uJu/qsj/pTrmbX+Qm3N1j145M= > =sSDP > -----END PGP SIGNATURE----- > From stian at redhat.com Wed Nov 19 07:02:17 2014 From: stian at redhat.com (Stian Thorgersen) Date: Wed, 19 Nov 2014 07:02:17 -0500 (EST) Subject: [keycloak-user] Users assigned to roles In-Reply-To: <546C7DA7.4050603@redhat.com> References: <546C5726.7050401@redhat.com> <1637251039.1697409.1416387575344.JavaMail.zimbra@redhat.com> <546C7DA7.4050603@redhat.com> Message-ID: <2120793844.1848074.1416398537238.JavaMail.zimbra@redhat.com> ----- Original Message ----- > From: "Marek Posolda" > To: "Stian Thorgersen" > Cc: "Alarik Myrin" , keycloak-user at lists.jboss.org > Sent: Wednesday, November 19, 2014 12:23:19 PM > Subject: Re: [keycloak-user] Users assigned to roles > > On 19.11.2014 09:59, Stian Thorgersen wrote: > > > > ----- Original Message ----- > >> From: "Marek Posolda" > >> To: "Alarik Myrin" , keycloak-user at lists.jboss.org > >> Sent: Wednesday, November 19, 2014 9:39:02 AM > >> Subject: Re: [keycloak-user] Users assigned to roles > >> > >> I don't think we have this at this moment. Feel free to create jira, but > >> no > >> promise if/when we provide it... > >> > >> btv. it seems that your query doesn't handle composite roles, but really > >> just > >> those roles, which are directly assigned to user in user_role_mapping > >> table. > >> I don't know if you care about it... Fact is that doing single SQL query > >> including composite roles is probably not doable unless you are on Oracle, > >> which allows some kind of hierarchical queries afaik. > > I reckon you could do it with an inner select that gets all roles that maps > > to the given role or is the role. > hmm... it seems to me that this will handle just role and it's parent > roles, but not whole hierarchy. Like if I have 'roleA', which has > composite subrole 'roleB' and this has another one 'roleC'. Now when I > want to know users with permission of 'roleC', then with inner join, I > am able to find users mapped in user_role_mappings table to 'roleC' and > 'roleB' but those mapped to 'roleA' won't be returned imo. > > Recursive hierarchical queries are supported by Oracle and I just > figured from > http://en.wikipedia.org/wiki/Hierarchical_and_recursive_queries_in_SQL > that there are more databases like PostgreSQL and MSSQL with some > support via "Common table expression" . It might be interesting SQL > exercise to return all users in single query though:-) Yep, you're right > > Marek > > > >> Marek > >> > >> On 18.11.2014 18:37, Alarik Myrin wrote: > >> > >> > >> > >> I was able to piece together a SQL query: > >> > >> > >> > >> SELECT u.username, u.first_name, u.last_name, role.name AS role > >> > >> FROM keycloak_role role > >> > >> INNER JOIN realm ON role.realm = realm.id > >> > >> INNER JOIN user_role_mapping rm ON role.id = rm.role_id > >> > >> INNER JOIN user_entity u ON rm.user_id = u.id > >> > >> WHERE realm.name =:1 AND role.name = :2 > >> > >> It might be nice to do this in the web console though... > >> > >> On Tue, Nov 18, 2014 at 12:28 PM, Alarik Myrin < alarik at zwift.com > wrote: > >> > >> > >> > >> Is there any easy way to see which users have been assigned a given role? > >> > >> > >> > >> _______________________________________________ > >> keycloak-user mailing list keycloak-user at lists.jboss.org > >> https://lists.jboss.org/mailman/listinfo/keycloak-user > >> > >> > >> _______________________________________________ > >> keycloak-user mailing list > >> keycloak-user at lists.jboss.org > >> https://lists.jboss.org/mailman/listinfo/keycloak-user > > From juraci at kroehling.de Wed Nov 19 08:30:02 2014 From: juraci at kroehling.de (=?UTF-8?B?SnVyYWNpIFBhaXjDo28gS3LDtmhsaW5n?=) Date: Wed, 19 Nov 2014 14:30:02 +0100 Subject: [keycloak-user] Recommendations for protecting REST service with bearer token and basic auth In-Reply-To: <1769288502.1847810.1416398478191.JavaMail.zimbra@redhat.com> References: <1845864658.5951344.1415369800735.JavaMail.zimbra@redhat.com> <5460BFDB.1060606@redhat.com> <5464E33F.9010601@kroehling.de> <546B5A77.9070408@kroehling.de> <546B63F3.3090200@redhat.com> <546B676B.7020708@kroehling.de> <1265926769.1688381.1416386022401.JavaMail.zimbra@redhat.com> <546C63F6.50406@kroehling.de> <1769288502.1847810.1416398478191.JavaMail.zimbra@redhat.com> Message-ID: <546C9B5A.8070907@kroehling.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 11/19/2014 01:01 PM, Stian Thorgersen wrote: > One exception though is that in this case you probably want an > offline token, which is something we don't support yet. Basically > an offline token would be a token that's not associated with a > specific user session, which would have a longer (possibly > unlimited) lifetime. The user would also need to be able to view > and revoke these tokens through the account management. That's exactly what I mean :-) Is there a plan for this feature already? If not, and if it's a desirable feature to have, I might be able to scratch a possible solution for it. - - Juca. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBCgAGBQJUbJtaAAoJEDnJtskdmzLMV08H/1JDyGtjdvfjuLzW1d2jblUh 1jhYMUwqoTLNm1nl3mQz6NQM5VZDffbWs3Q3e20fQu2CPuj04twaN7vOLtEJgUAL P1qzYi5w3IwP19nQbqBbkD9Kr9FihV1tYYttWMr2ZvnC+2IncPJaRJXMEN1KTy+E STz5SGvSnkaLPPql6cZutSwxJ/BCKVyP4bubZYQu87ZMzOOTvPgDFACKVvVINCQx DFBYXPCRlnMBrBVCIR1AQ9VapQ94rgjxhVuz/UkHUSYovzeENdXIUdz3HfC7nPck cbyj7R5FslCm4LszhMIh4Ir9f5MapgyVuI+NSwLeaUS8YY+MWfeOUbk4SWyU4rw= =Qdrd -----END PGP SIGNATURE----- From bburke at redhat.com Wed Nov 19 10:00:00 2014 From: bburke at redhat.com (Bill Burke) Date: Wed, 19 Nov 2014 10:00:00 -0500 Subject: [keycloak-user] Recommendations for protecting REST service with bearer token and basic auth In-Reply-To: <1769288502.1847810.1416398478191.JavaMail.zimbra@redhat.com> References: <1845864658.5951344.1415369800735.JavaMail.zimbra@redhat.com> <5460BFDB.1060606@redhat.com> <5464E33F.9010601@kroehling.de> <546B5A77.9070408@kroehling.de> <546B63F3.3090200@redhat.com> <546B676B.7020708@kroehling.de> <1265926769.1688381.1416386022401.JavaMail.zimbra@redhat.com> <546C63F6.50406@kroehling.de> <1769288502.1847810.1416398478191.JavaMail.zimbra@redhat.com> Message-ID: <546CB070.2060309@redhat.com> On 11/19/2014 7:01 AM, Stian Thorgersen wrote: > First thing, is this script a CLI that a user invokes, a background process that runs on behalf of the user, or a server? > > If it's a CLI I'd say it should ask user for username/password and use direct grant to obtain token. The refresh token could be saved in a tmp file, or in users home directory. Next time the CLI wants to invoke this it'll need to make sure the token isn't expired, if it is refresh before invoking the service. > > If it's a background process you'll need a setup script that asks users for username/password or as you suggest use a browser to login. After that it's the same as above. One exception though is that in this case you probably want an offline token, which is something we don't support yet. Basically an offline token would be a token that's not associated with a specific user session, which would have a longer (possibly unlimited) lifetime. The user would also need to be able to view and revoke these tokens through the account management. > > If it's a server it should use a certificate to authenticate the server itself. Also, it should use a "service account" rather than a regular user account. Again, this is something we don't have atm. We only have regular user accounts and passwords. > We used to have a "service account" all applications and oauth clients were users :( -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From bburke at redhat.com Wed Nov 19 10:01:36 2014 From: bburke at redhat.com (Bill Burke) Date: Wed, 19 Nov 2014 10:01:36 -0500 Subject: [keycloak-user] Recommendations for protecting REST service with bearer token and basic auth In-Reply-To: <546C9B5A.8070907@kroehling.de> References: <1845864658.5951344.1415369800735.JavaMail.zimbra@redhat.com> <5460BFDB.1060606@redhat.com> <5464E33F.9010601@kroehling.de> <546B5A77.9070408@kroehling.de> <546B63F3.3090200@redhat.com> <546B676B.7020708@kroehling.de> <1265926769.1688381.1416386022401.JavaMail.zimbra@redhat.com> <546C63F6.50406@kroehling.de> <1769288502.1847810.1416398478191.JavaMail.zimbra@redhat.com> <546C9B5A.8070907@kroehling.de> Message-ID: <546CB0D0.3080808@redhat.com> On 11/19/2014 8:30 AM, Juraci Paix?o Kr?hling wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 > > On 11/19/2014 01:01 PM, Stian Thorgersen wrote: >> One exception though is that in this case you probably want an >> offline token, which is something we don't support yet. Basically >> an offline token would be a token that's not associated with a >> specific user session, which would have a longer (possibly >> unlimited) lifetime. The user would also need to be able to view >> and revoke these tokens through the account management. > > That's exactly what I mean :-) Is there a plan for this feature > already? If not, and if it's a desirable feature to have, I might be > able to scratch a possible solution for it. > You guys are basically describing certificate auth. Bill -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From evanthomjd at gmail.com Wed Nov 19 10:12:29 2014 From: evanthomjd at gmail.com (Evan Thompson) Date: Wed, 19 Nov 2014 10:12:29 -0500 Subject: [keycloak-user] Restrict application access by role Message-ID: Howdy All, II currently have two applications in the same Realm and I was wondering if it is possible to restrict a users access to an application based on the existence of a specific role. For example: Let's call my applications: application_x and applicaiton_y. Would it be possible to only allow users to access applicaiton_x if they have role_x assigned to them. Any insight that could be offered would be greatly appreciated. Thanks, Evan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20141119/c0c51da4/attachment.html From bburke at redhat.com Wed Nov 19 10:27:10 2014 From: bburke at redhat.com (Bill Burke) Date: Wed, 19 Nov 2014 10:27:10 -0500 Subject: [keycloak-user] Restrict application access by role In-Reply-To: References: Message-ID: <546CB6CE.8010703@redhat.com> We've been letting the application handle access via role, keycloak would just pass along user role mappings. You want the auth server to deny access? We could do that. Would take a "Roles Allowed" page on the application admin console and a easy check after authentication. On 11/19/2014 10:12 AM, Evan Thompson wrote: > Howdy All, > > II currently have two applications in the same Realm and I was wondering > if it is possible to restrict a users access to an application based on > the existence of a specific role. For example: > > Let's call my applications: application_x and applicaiton_y. Would it be > possible to only allow users to access applicaiton_x if they have role_x > assigned to them. > > Any insight that could be offered would be greatly appreciated. > > Thanks, > > Evan > > > _______________________________________________ > keycloak-user mailing list > keycloak-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user > -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From stian at redhat.com Wed Nov 19 11:16:46 2014 From: stian at redhat.com (Stian Thorgersen) Date: Wed, 19 Nov 2014 11:16:46 -0500 (EST) Subject: [keycloak-user] Recommendations for protecting REST service with bearer token and basic auth In-Reply-To: <546CB0D0.3080808@redhat.com> References: <1845864658.5951344.1415369800735.JavaMail.zimbra@redhat.com> <546B63F3.3090200@redhat.com> <546B676B.7020708@kroehling.de> <1265926769.1688381.1416386022401.JavaMail.zimbra@redhat.com> <546C63F6.50406@kroehling.de> <1769288502.1847810.1416398478191.JavaMail.zimbra@redhat.com> <546C9B5A.8070907@kroehling.de> <546CB0D0.3080808@redhat.com> Message-ID: <1789419203.2102266.1416413806324.JavaMail.zimbra@redhat.com> ----- Original Message ----- > From: "Bill Burke" > To: keycloak-user at lists.jboss.org > Sent: Wednesday, 19 November, 2014 4:01:36 PM > Subject: Re: [keycloak-user] Recommendations for protecting REST service with bearer token and basic auth > > > > On 11/19/2014 8:30 AM, Juraci Paix?o Kr?hling wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA512 > > > > On 11/19/2014 01:01 PM, Stian Thorgersen wrote: > >> One exception though is that in this case you probably want an > >> offline token, which is something we don't support yet. Basically > >> an offline token would be a token that's not associated with a > >> specific user session, which would have a longer (possibly > >> unlimited) lifetime. The user would also need to be able to view > >> and revoke these tokens through the account management. > > > > That's exactly what I mean :-) Is there a plan for this feature > > already? If not, and if it's a desirable feature to have, I might be > > able to scratch a possible solution for it. > > > > You guys are basically describing certificate auth. Yes for the one use-case I described (where the app is the user). There's also the case where a user gives an application permanent (offline) access to their account. In Google they have a special scope you can request for this (https://developers.google.com/accounts/docs/OAuth2WebServer#offline). > > Bill > > -- > Bill Burke > JBoss, a division of Red Hat > http://bill.burkecentral.com > _______________________________________________ > keycloak-user mailing list > keycloak-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user > From gbrown at redhat.com Wed Nov 19 11:20:17 2014 From: gbrown at redhat.com (Gary Brown) Date: Wed, 19 Nov 2014 11:20:17 -0500 (EST) Subject: [keycloak-user] Obtaining the user name from the security context In-Reply-To: <837918009.11459602.1416413898391.JavaMail.zimbra@redhat.com> Message-ID: <1869846893.11462243.1416414017373.JavaMail.zimbra@redhat.com> Hi When I access getUserPrincipal().getName() in javax.ws.rs.core.SecurityContext I get the UID. Is it possible to obtain the actual user name? Regards Gary From afsg77 at gmail.com Wed Nov 19 11:29:51 2014 From: afsg77 at gmail.com (=?UTF-8?Q?Fabi=C3=A1n_Silva?=) Date: Wed, 19 Nov 2014 10:29:51 -0600 Subject: [keycloak-user] Error on application log in In-Reply-To: References: <5465BCF1.6000304@redhat.com> Message-ID: Hi, I'm running out of ideas in here. In simple terms I got a Wildfly running on domain on a server and a keycloak on another server. I set the adapters on my wildfly and deploy, to this wildfly, a web app that uses keycloak. When I try to access the web app it displays the keycloak login, it validates the users ok, but when you access with a correct user and password it shows the "403 - Forbidden". At first I thought it was some issue with the roles, but that didn't fix it. Regards On Fri, Nov 14, 2014 at 10:20 AM, Fabi?n Silva wrote: > Hi, > It is already set to use the absolute path. And the keycloak is working > when I deploy the application to my local wildfly domain. The issue is when > I try to deploy to another wildfly in domain mode on a separate server. The > application is the same and the only difference I can tell from the two > wildflys is that the local don't have the SSL/HTTPS enabled. I have the > keycloak adapter set in both domains. > > I'm trying to trace those errors on the keycloak code to try to understand > what is happening, but I haven't been so lucky with this. > > Regards > Alejandro Fabi?n Silva Grif? > > On Fri, Nov 14, 2014 at 2:27 AM, Marek Posolda > wrote: > >> Hi, >> >> it failed on the adapter (application) side and error 404 means "Not >> found". So adapter can't find the keycloak server to turn code into token. >> Make sure to configure "auth-server-url" in keycloak.json for your >> application properly. If relative uri doesn't work for some reason, you can >> rather try to use absolute uri for auth-server-url like >> "https://localhost:8443/auth" . >> >> Marek >> >> >> On 14.11.2014 01:31, Fabi?n Silva wrote: >> >> I have a keycloak installed on wildfly standalone. I'm trying to deploy >> an application, that use this keycloak, on a separate server with wilflly >> running on domain mode. I tried first to deploy on a domain out of the box >> on my local machine, setting the keycloak-wildfly-adapter-dist-1.0.4.Final. >> It deploys fine and does the authentication without any issues. When I try >> to migrate it to the server running my wilfly (also in domain mode and the >> keycloak adapter set), it deploys fine and shows the keycloak login once >> you enter the application. But the problem is that when you login it >> displays a "403 - Forbidden" and on the log I'm seeing >> ERROR [org.keycloak.adapters.OAuthRequestAuthenticator] (default task-6) >> failed to turn code into token >> ERROR [org.keycloak.adapters.OAuthRequestAuthenticator] (default task-6) >> status from server: 404 >> The only difference between those two wildfly domain mode is that in the >> local I don't have the the SSL/HTTPS enabled. >> >> Have anyone seen this error? or have an idea of what this could be? >> >> Regards >> >> >> _______________________________________________ >> keycloak-user mailing listkeycloak-user at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-user >> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20141119/8f8160ec/attachment-0001.html From ssilvert at redhat.com Wed Nov 19 12:28:27 2014 From: ssilvert at redhat.com (Stan Silvert) Date: Wed, 19 Nov 2014 12:28:27 -0500 Subject: [keycloak-user] Error on application log in In-Reply-To: References: <5465BCF1.6000304@redhat.com> Message-ID: <546CD33B.1020607@redhat.com> Have you tried it using the two servers but without SSL? You can set ssl-required to "none" on the adapter (application) side. Also on the Keycloak server side, try setting Access Type to "public". Do one of those at a time and see if either causes it to work. That might narrow it down a bit. On 11/19/2014 11:29 AM, Fabi?n Silva wrote: > Hi, > I'm running out of ideas in here. In simple terms I got a Wildfly > running on domain on a server and a keycloak on another server. I set > the adapters on my wildfly and deploy, to this wildfly, a web app that > uses keycloak. When I try to access the web app it displays the > keycloak login, it validates the users ok, but when you access with a > correct user and password it shows the "403 - Forbidden". At first I > thought it was some issue with the roles, but that didn't fix it. > > Regards > > On Fri, Nov 14, 2014 at 10:20 AM, Fabi?n Silva > wrote: > > Hi, > It is already set to use the absolute path. And the keycloak is > working when I deploy the application to my local wildfly domain. > The issue is when I try to deploy to another wildfly in domain > mode on a separate server. The application is the same and the > only difference I can tell from the two wildflys is that the local > don't have the SSL/HTTPS enabled. I have the keycloak adapter set > in both domains. > > I'm trying to trace those errors on the keycloak code to try to > understand what is happening, but I haven't been so lucky with this. > > Regards > Alejandro Fabi?n Silva Grif? > > On Fri, Nov 14, 2014 at 2:27 AM, Marek Posolda > > wrote: > > Hi, > > it failed on the adapter (application) side and error 404 > means "Not found". So adapter can't find the keycloak server > to turn code into token. Make sure to configure > "auth-server-url" in keycloak.json for your application > properly. If relative uri doesn't work for some reason, you > can rather try to use absolute uri for auth-server-url like > "https://localhost:8443/auth" . > > Marek > > > On 14.11.2014 01:31, Fabi?n Silva wrote: >> I have a keycloak installed on wildfly standalone. I'm trying >> to deploy an application, that use this keycloak, on a >> separate server with wilflly running on domain mode. I tried >> first to deploy on a domain out of the box on my local >> machine, setting the >> keycloak-wildfly-adapter-dist-1.0.4.Final. It deploys fine >> and does the authentication without any issues. When I try to >> migrate it to the server running my wilfly (also in domain >> mode and the keycloak adapter set), it deploys fine and shows >> the keycloak login once you enter the application. But the >> problem is that when you login it displays a "403 - >> Forbidden" and on the log I'm seeing >> ERROR [org.keycloak.adapters.OAuthRequestAuthenticator] >> (default task-6) failed to turn code into token >> ERROR [org.keycloak.adapters.OAuthRequestAuthenticator] >> (default task-6) status from server: 404 >> The only difference between those two wildfly domain mode is >> that in the local I don't have the the SSL/HTTPS enabled. >> >> Have anyone seen this error? or have an idea of what this >> could be? >> >> Regards >> >> >> _______________________________________________ >> keycloak-user mailing list >> keycloak-user at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-user > > > > > > _______________________________________________ > 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-user/attachments/20141119/d51a54e7/attachment.html From afsg77 at gmail.com Wed Nov 19 12:35:15 2014 From: afsg77 at gmail.com (=?UTF-8?Q?Fabi=C3=A1n_Silva?=) Date: Wed, 19 Nov 2014 11:35:15 -0600 Subject: [keycloak-user] Error on application log in In-Reply-To: <546CD33B.1020607@redhat.com> References: <5465BCF1.6000304@redhat.com> <546CD33B.1020607@redhat.com> Message-ID: I tried deploying it onto a local wildfly in domain without the SSL enabled and it worked. What I can't figure it out is why the SSL is causing conflict and how to solve this, I can't simply disable the SSL. Regards On Wed, Nov 19, 2014 at 11:28 AM, Stan Silvert wrote: > Have you tried it using the two servers but without SSL? > > You can set ssl-required to "none" on the adapter (application) side. > Also on the Keycloak server side, try setting Access Type to "public". Do > one of those at a time and see if either causes it to work. That might > narrow it down a bit. > > > On 11/19/2014 11:29 AM, Fabi?n Silva wrote: > > Hi, > I'm running out of ideas in here. In simple terms I got a Wildfly running > on domain on a server and a keycloak on another server. I set the adapters > on my wildfly and deploy, to this wildfly, a web app that uses keycloak. > When I try to access the web app it displays the keycloak login, it > validates the users ok, but when you access with a correct user and > password it shows the "403 - Forbidden". At first I thought it was some > issue with the roles, but that didn't fix it. > > Regards > > On Fri, Nov 14, 2014 at 10:20 AM, Fabi?n Silva wrote: > >> Hi, >> It is already set to use the absolute path. And the keycloak is working >> when I deploy the application to my local wildfly domain. The issue is when >> I try to deploy to another wildfly in domain mode on a separate server. The >> application is the same and the only difference I can tell from the two >> wildflys is that the local don't have the SSL/HTTPS enabled. I have the >> keycloak adapter set in both domains. >> >> I'm trying to trace those errors on the keycloak code to try to >> understand what is happening, but I haven't been so lucky with this. >> >> Regards >> Alejandro Fabi?n Silva Grif? >> >> On Fri, Nov 14, 2014 at 2:27 AM, Marek Posolda >> wrote: >> >>> Hi, >>> >>> it failed on the adapter (application) side and error 404 means "Not >>> found". So adapter can't find the keycloak server to turn code into token. >>> Make sure to configure "auth-server-url" in keycloak.json for your >>> application properly. If relative uri doesn't work for some reason, you can >>> rather try to use absolute uri for auth-server-url like >>> "https://localhost:8443/auth" . >>> >>> Marek >>> >>> >>> On 14.11.2014 01:31, Fabi?n Silva wrote: >>> >>> I have a keycloak installed on wildfly standalone. I'm trying to >>> deploy an application, that use this keycloak, on a separate server with >>> wilflly running on domain mode. I tried first to deploy on a domain out of >>> the box on my local machine, setting the >>> keycloak-wildfly-adapter-dist-1.0.4.Final. It deploys fine and does the >>> authentication without any issues. When I try to migrate it to the server >>> running my wilfly (also in domain mode and the keycloak adapter set), it >>> deploys fine and shows the keycloak login once you enter the application. >>> But the problem is that when you login it displays a "403 - Forbidden" and >>> on the log I'm seeing >>> ERROR [org.keycloak.adapters.OAuthRequestAuthenticator] (default task-6) >>> failed to turn code into token >>> ERROR [org.keycloak.adapters.OAuthRequestAuthenticator] (default task-6) >>> status from server: 404 >>> The only difference between those two wildfly domain mode is that in the >>> local I don't have the the SSL/HTTPS enabled. >>> >>> Have anyone seen this error? or have an idea of what this could be? >>> >>> Regards >>> >>> >>> _______________________________________________ >>> keycloak-user mailing listkeycloak-user at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-user >>> >>> >>> >> > > > _______________________________________________ > keycloak-user mailing listkeycloak-user at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-user > > > > _______________________________________________ > 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-user/attachments/20141119/53568895/attachment-0001.html From mposolda at redhat.com Wed Nov 19 12:55:37 2014 From: mposolda at redhat.com (Marek Posolda) Date: Wed, 19 Nov 2014 18:55:37 +0100 Subject: [keycloak-user] Obtaining the user name from the security context In-Reply-To: <1869846893.11462243.1416414017373.JavaMail.zimbra@redhat.com> References: <1869846893.11462243.1416414017373.JavaMail.zimbra@redhat.com> Message-ID: <546CD999.9000808@redhat.com> If you have 1.1.0.Beta1, you can try to use "principal-attribute" with value "|preferred_username" in the configuration of your adapter. More info in |http://docs.jboss.org/keycloak/docs/1.1.0.Beta1/userguide /html/ch07.html#adapter-config . It should also work to cast getUserPrincipal() to KeycloakPrincipal and use something like: ((KeycloakPrincipal)getUserPrincipal()).getKeycloakSecurityContext().getToken().getPreferredUsername() this should also work on older versions, but your code may need to have dependencies on keycloak. Marek On 19.11.2014 17:20, Gary Brown wrote: > Hi > > When I access getUserPrincipal().getName() in javax.ws.rs.core.SecurityContext I get the UID. > > Is it possible to obtain the actual user name? > > Regards > Gary > _______________________________________________ > 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-user/attachments/20141119/abb2213a/attachment.html From ungarida at gmail.com Wed Nov 19 18:33:15 2014 From: ungarida at gmail.com (Davide Ungari) Date: Thu, 20 Nov 2014 00:33:15 +0100 Subject: [keycloak-user] Authentication throw a proxy on Undertow Message-ID: Hi everybody, this is the big picture: a. frontend application with Undertow b. backend application with Undertow and Resteasy for REST API Both are using Keycloak as SSO. I'm trying to configure a proxy from A to B in order to expose backend API without CORS problems to the frontend. I asked support also to Undertow guys but the issue seems around the integration of Keycloack in Undertow. My proxy is implemented like: final ProxyClient proxyClient = new SimpleProxyClientProvider(new URI("http://localhost:8181")); final ProxyHandler proxyHandler = new ProxyHandler(proxyClient, servletHandler); proxyHandler.addRequestHeader(new HttpString("Authorization"), new ExchangeAttribute() { @Override public String readAttribute(HttpServerExchange exchange) { exchange. RefreshableKeycloakSecurityContext context = (RefreshableKeycloakSecurityContext) exchange.getSecurityContext(); return "Bearer " + context.getTokenString(); } @Override public void writeAttribute(HttpServerExchange exchange, String newValue) throws ReadOnlyAttributeException { // TODO Auto-generated method stub } }); The problem is that the exchange.getSecurityContext() is always null. Any ideas? Thanks -- Davide -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20141120/a1bb31a2/attachment.html From bburke at redhat.com Wed Nov 19 19:02:52 2014 From: bburke at redhat.com (Bill Burke) Date: Wed, 19 Nov 2014 19:02:52 -0500 Subject: [keycloak-user] Authentication throw a proxy on Undertow In-Reply-To: References: Message-ID: <546D2FAC.1070604@redhat.com> Weird... I'm actually screwing around with writing a security proxy right now. I just started like an hour or so ago so I'm not exactly sure...but I don't think you can implement this with the current codebase. You need a Undertow only (no servlet) authentication mechanism and to set up the security handler chain correctly. (See the BasicAuthServer example in Undertow). I should have something working in master by the end of the week. On 11/19/2014 6:33 PM, Davide Ungari wrote: > Hi everybody, > this is the big picture: > a. frontend application with Undertow > b. backend application with Undertow and Resteasy for REST API > > Both are using Keycloak as SSO. > > I'm trying to configure a proxy from A to B in order to expose backend > API without CORS problems to the frontend. > > I asked support also to Undertow guys but the issue seems around the > integration of Keycloack in Undertow. My proxy is implemented like: > > final ProxyClient proxyClient = new > SimpleProxyClientProvider(new URI("http://localhost:8181 > ")); > final ProxyHandler proxyHandler = new > ProxyHandler(proxyClient, servletHandler); > proxyHandler.addRequestHeader(new > HttpString("Authorization"), new ExchangeAttribute() { > @Override > public String readAttribute(HttpServerExchange > exchange) { > exchange. > RefreshableKeycloakSecurityContext context = > (RefreshableKeycloakSecurityContext) exchange.getSecurityContext(); > return "Bearer " + context.getTokenString(); > } > > @Override > public void writeAttribute(HttpServerExchange > exchange, String newValue) throws ReadOnlyAttributeException { > // TODO Auto-generated method stub > } > }); > > The problem is that the exchange.getSecurityContext() is always null. > Any ideas? > > Thanks > > > > -- > Davide > > > _______________________________________________ > keycloak-user mailing list > keycloak-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user > -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From stian at redhat.com Thu Nov 20 03:25:31 2014 From: stian at redhat.com (Stian Thorgersen) Date: Thu, 20 Nov 2014 03:25:31 -0500 (EST) Subject: [keycloak-user] Error on application log in In-Reply-To: References: <5465BCF1.6000304@redhat.com> <546CD33B.1020607@redhat.com> Message-ID: <1823273882.2484255.1416471931969.JavaMail.zimbra@redhat.com> Are there no errors or warning in the server log? Try enabling debug for org.keycloak and see if there's anything interesting. First thing try the exact same setup (two servers), but without ssl. If that works disable enable ssl, but disable the trust manager in the adapter (disable-trust-manager option on adapter, see http://docs.jboss.org/keycloak/docs/1.1.0.Beta1/userguide/html/ch07.html#adapter-config). If it still works create a truststore and import your certificate. Then set truststore and truststore-password on the adapter. ----- Original Message ----- > From: "Fabi?n Silva" > To: "Stan Silvert" > Cc: keycloak-user at lists.jboss.org > Sent: Wednesday, 19 November, 2014 6:35:15 PM > Subject: Re: [keycloak-user] Error on application log in > > I tried deploying it onto a local wildfly in domain without the SSL enabled > and it worked. What I can't figure it out is why the SSL is causing conflict > and how to solve this, I can't simply disable the SSL. > > Regards > > On Wed, Nov 19, 2014 at 11:28 AM, Stan Silvert < ssilvert at redhat.com > wrote: > > > > Have you tried it using the two servers but without SSL? > > You can set ssl-required to "none" on the adapter (application) side. Also on > the Keycloak server side, try setting Access Type to "public". Do one of > those at a time and see if either causes it to work. That might narrow it > down a bit. > > > On 11/19/2014 11:29 AM, Fabi?n Silva wrote: > > > > Hi, > I'm running out of ideas in here. In simple terms I got a Wildfly running on > domain on a server and a keycloak on another server. I set the adapters on > my wildfly and deploy, to this wildfly, a web app that uses keycloak. When I > try to access the web app it displays the keycloak login, it validates the > users ok, but when you access with a correct user and password it shows the > "403 - Forbidden". At first I thought it was some issue with the roles, but > that didn't fix it. > > Regards > > On Fri, Nov 14, 2014 at 10:20 AM, Fabi?n Silva < afsg77 at gmail.com > wrote: > > > > Hi, > It is already set to use the absolute path. And the keycloak is working when > I deploy the application to my local wildfly domain. The issue is when I try > to deploy to another wildfly in domain mode on a separate server. The > application is the same and the only difference I can tell from the two > wildflys is that the local don't have the SSL/HTTPS enabled. I have the > keycloak adapter set in both domains. > > I'm trying to trace those errors on the keycloak code to try to understand > what is happening, but I haven't been so lucky with this. > > Regards > Alejandro Fabi?n Silva Grif? > > On Fri, Nov 14, 2014 at 2:27 AM, Marek Posolda < mposolda at redhat.com > wrote: > > > > Hi, > > it failed on the adapter (application) side and error 404 means "Not found". > So adapter can't find the keycloak server to turn code into token. Make sure > to configure "auth-server-url" in keycloak.json for your application > properly. If relative uri doesn't work for some reason, you can rather try > to use absolute uri for auth-server-url like "https://localhost:8443/auth" . > > Marek > > > On 14.11.2014 01:31, Fabi?n Silva wrote: > > > > I have a keycloak installed on wildfly standalone. I'm trying to deploy an > application, that use this keycloak, on a separate server with wilflly > running on domain mode. I tried first to deploy on a domain out of the box > on my local machine, setting the keycloak-wildfly-adapter-dist-1.0.4.Final. > It deploys fine and does the authentication without any issues. When I try > to migrate it to the server running my wilfly (also in domain mode and the > keycloak adapter set), it deploys fine and shows the keycloak login once you > enter the application. But the problem is that when you login it displays a > "403 - Forbidden" and on the log I'm seeing > ERROR [org.keycloak.adapters.OAuthRequestAuthenticator] (default task-6) > failed to turn code into token > ERROR [org.keycloak.adapters.OAuthRequestAuthenticator] (default task-6) > status from server: 404 > The only difference between those two wildfly domain mode is that in the > local I don't have the the SSL/HTTPS enabled. > > Have anyone seen this error? or have an idea of what this could be? > > Regards > > > _______________________________________________ > keycloak-user mailing list keycloak-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user > > > > > > _______________________________________________ > keycloak-user mailing list keycloak-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user > > > _______________________________________________ > keycloak-user mailing list > keycloak-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user > > > _______________________________________________ > keycloak-user mailing list > keycloak-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user From gbrown at redhat.com Thu Nov 20 05:25:22 2014 From: gbrown at redhat.com (Gary Brown) Date: Thu, 20 Nov 2014 05:25:22 -0500 (EST) Subject: [keycloak-user] Obtaining the user name from the security context In-Reply-To: <546CD999.9000808@redhat.com> References: <1869846893.11462243.1416414017373.JavaMail.zimbra@redhat.com> <546CD999.9000808@redhat.com> Message-ID: <1510952577.11835794.1416479122326.JavaMail.zimbra@redhat.com> Hi Thanks for the information. However, I've tried it without success - I also tried using this attribute in the keycloak unconfigured-demo and preconfigured-demo examples for customer-app/product-app, and didn't have an effect on them either. Just wondering whether the text in the doc "OpenID Connection ID Token attribute to populate the UserPrincipal name with" implies that this attribute only works for OpenID? With the unconfigured version, it wasn't clear whether this attribute would be set under the realm or secure-deployment elements, so initially I tried just under the realm but then eventually defined the attribute under both. Attached the wildfly standalone-full.xml. Regards Gary ----- Original Message ----- > If you have 1.1.0.Beta1, you can try to use "principal-attribute" with > value "|preferred_username" in the configuration of your adapter. More > info in |http://docs.jboss.org/keycloak/docs/1.1.0.Beta1/userguide > /html/ch07.html#adapter-config . > > It should also work to cast getUserPrincipal() to KeycloakPrincipal and > use something like: > > ((KeycloakPrincipal)getUserPrincipal()).getKeycloakSecurityContext().getToken().getPreferredUsername() > > this should also work on older versions, but your code may need to have > dependencies on keycloak. > > Marek > > On 19.11.2014 17:20, Gary Brown wrote: > > Hi > > > > When I access getUserPrincipal().getName() in > > javax.ws.rs.core.SecurityContext I get the UID. > > > > Is it possible to obtain the actual user name? > > > > Regards > > Gary > > _______________________________________________ > > keycloak-user mailing list > > keycloak-user at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/keycloak-user > > -------------- next part -------------- A non-text attachment was scrubbed... Name: standalone-full.xml Type: application/xml Size: 30314 bytes Desc: not available Url : http://lists.jboss.org/pipermail/keycloak-user/attachments/20141120/8ccc4011/attachment-0001.rdf From ungarida at gmail.com Fri Nov 21 02:38:29 2014 From: ungarida at gmail.com (Davide Ungari) Date: Fri, 21 Nov 2014 08:38:29 +0100 Subject: [keycloak-user] (no subject) Message-ID: Hi Bill, I see you have pushed some changes. Tell me as soon as you need me to test it. Thank you, Davide. > Weird... I'm actually screwing around with writing a security proxy > right now. I just started like an hour or so ago so I'm not exactly > sure...but I don't think you can implement this with the current > codebase. You need a Undertow only (no servlet) authentication > mechanism and to set up the security handler chain correctly. (See the > BasicAuthServer example in Undertow). > I should have something working in master by the end of the week. > On 11/19/2014 6:33 PM, Davide Ungari wrote: > >* Hi everybody, > *>* this is the big picture: > *>* a. frontend application with Undertow > *>* b. backend application with Undertow and Resteasy for REST API > *> > >* Both are using Keycloak as SSO. > *> > >* I'm trying to configure a proxy from A to B in order to expose backend > *>* API without CORS problems to the frontend. > *> > >* I asked support also to Undertow guys but the issue seems around the > *>* integration of Keycloack in Undertow. My proxy is implemented like: > *> > >* final ProxyClient proxyClient = new > *>* SimpleProxyClientProvider(new URI("http://localhost:8181 > *>* >")); > *>* final ProxyHandler proxyHandler = new > *>* ProxyHandler(proxyClient, servletHandler); > *>* proxyHandler.addRequestHeader(new > *>* HttpString("Authorization"), new ExchangeAttribute() { > *>* @Override > *>* public String readAttribute(HttpServerExchange > *>* exchange) { > *>* exchange. > *>* RefreshableKeycloakSecurityContext context = > *>* (RefreshableKeycloakSecurityContext) exchange.getSecurityContext(); > *>* return "Bearer " + context.getTokenString(); > *>* } > *> > >* @Override > *>* public void writeAttribute(HttpServerExchange > *>* exchange, String newValue) throws ReadOnlyAttributeException { > *>* // TODO Auto-generated method stub > *>* } > *>* }); > *> > >* The problem is that the exchange.getSecurityContext() is always null. > *>* Any ideas? > *> > >* Thanks > *> > > > > > >* -- > *>* Davide > *> > > > >* _______________________________________________ > *>* keycloak-user mailing list > *>* keycloak-user at lists.jboss.org > *>* https://lists.jboss.org/mailman/listinfo/keycloak-user > *> > -- > Bill Burke > JBoss, a division of Red Hat > http://bill.burkecentral.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20141121/695f7c7f/attachment.html From ungarida at gmail.com Fri Nov 21 02:47:21 2014 From: ungarida at gmail.com (Davide Ungari) Date: Fri, 21 Nov 2014 08:47:21 +0100 Subject: [keycloak-user] Authentication throw a proxy on Undertow Message-ID: Hi Bill, I see you have pushed some changes. Tell me as soon as you need me to test it. Thank you, Davide. > Weird... I'm actually screwing around with writing a security proxy > right now. I just started like an hour or so ago so I'm not exactly > sure...but I don't think you can implement this with the current > codebase. You need a Undertow only (no servlet) authentication > mechanism and to set up the security handler chain correctly. (See the > BasicAuthServer example in Undertow). > I should have something working in master by the end of the week. > On 11/19/2014 6:33 PM, Davide Ungari wrote: > >* Hi everybody, > *>* this is the big picture: > *>* a. frontend application with Undertow > *>* b. backend application with Undertow and Resteasy for REST API > *> > >* Both are using Keycloak as SSO. > *> > >* I'm trying to configure a proxy from A to B in order to expose backend > *>* API without CORS problems to the frontend. > *> > >* I asked support also to Undertow guys but the issue seems around the > *>* integration of Keycloack in Undertow. My proxy is implemented like: > *> > >* final ProxyClient proxyClient = new > *>* SimpleProxyClientProvider(new URI("http://localhost:8181 > *>* >")); > *>* final ProxyHandler proxyHandler = new > *>* ProxyHandler(proxyClient, servletHandler); > *>* proxyHandler.addRequestHeader(new > *>* HttpString("Authorization"), new ExchangeAttribute() { > *>* @Override > *>* public String readAttribute(HttpServerExchange > *>* exchange) { > *>* exchange. > *>* RefreshableKeycloakSecurityContext context = > *>* (RefreshableKeycloakSecurityContext) exchange.getSecurityContext(); > *>* return "Bearer " + context.getTokenString(); > *>* } > *> > >* @Override > *>* public void writeAttribute(HttpServerExchange > *>* exchange, String newValue) throws ReadOnlyAttributeException { > *>* // TODO Auto-generated method stub > *>* } > *>* }); > *> > >* The problem is that the exchange.getSecurityContext() is always null. > *>* Any ideas? > *> > >* Thanks > *> > > > > > >* -- > *>* Davide > *> > > > >* _______________________________________________ > *>* keycloak-user mailing list > *>* keycloak-user at lists.jboss.org > *>* https://lists.jboss.org/mailman/listinfo/keycloak-user > *> > -- > Bill Burke > JBoss, a division of Red Hat > http://bill.burkecentral.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20141121/c3f42056/attachment.html From juraci at kroehling.de Fri Nov 21 05:29:09 2014 From: juraci at kroehling.de (=?UTF-8?B?SnVyYWNpIFBhaXjDo28gS3LDtmhsaW5n?=) Date: Fri, 21 Nov 2014 11:29:09 +0100 Subject: [keycloak-user] Recommendations for protecting REST service with bearer token and basic auth In-Reply-To: <1789419203.2102266.1416413806324.JavaMail.zimbra@redhat.com> References: <1845864658.5951344.1415369800735.JavaMail.zimbra@redhat.com> <546B63F3.3090200@redhat.com> <546B676B.7020708@kroehling.de> <1265926769.1688381.1416386022401.JavaMail.zimbra@redhat.com> <546C63F6.50406@kroehling.de> <1769288502.1847810.1416398478191.JavaMail.zimbra@redhat.com> <546C9B5A.8070907@kroehling.de> <546CB0D0.3080808@redhat.com> <1789419203.2102266.1416413806324.JavaMail.zimbra@redhat.com> Message-ID: <546F13F5.9020807@kroehling.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 11/19/2014 05:16 PM, Stian Thorgersen wrote: > ----- Original Message ----- >> From: "Bill Burke" To: >> keycloak-user at lists.jboss.org Sent: Wednesday, 19 November, 2014 >> 4:01:36 PM Subject: Re: [keycloak-user] Recommendations for >> protecting REST service with bearer token and basic auth >> >> You guys are basically describing certificate auth. > > Yes for the one use-case I described (where the app is the user). > There's also the case where a user gives an application permanent > (offline) access to their account. In Google they have a special > scope you can request for this > (https://developers.google.com/accounts/docs/OAuth2WebServer#offline). > > If there are no objections, I'll start scratching an implementation of this offline mode, as something on this direction will be needed for the project I'm helping with. Ideally, the project would benefit from using service accounts instead of acting on behalf of an specific user, but as there will be only one account per user/realm, this would do for now :-) - - Juca. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBCgAGBQJUbxP1AAoJEDnJtskdmzLM7IQH/RFJ5Cf0reec9CgMjxO1D1tt lgS20P6d17Ki0UocoNidp59YdP5TRKycYbCMchbfTZu4In+9gEBzsdxK+4acprPF sp6WCa1Comc8vFCX8Or9gxUEDRH+axWR4t/bIsBf23IvXQ1BUIVg0s21RxFoMhPP fGHoaAEGthez6Dhr7GSwr46FEO2xP94jHJ7nAs67DNeh0vvZmQ1iynBkF3NmfQzP dMCjny4i2D/UZCcSr72ud0DnoAi//vIQ86KObrqsiHV2eOhWYfHB9TozC/P1lKVM 5D8qByrnxtmgA/nYNuRFmKTYf2n6MZTU5AlSFJZr4svU6isl2zwkpczhwDRshjc= =x/UK -----END PGP SIGNATURE----- From stian at redhat.com Fri Nov 21 06:22:46 2014 From: stian at redhat.com (Stian Thorgersen) Date: Fri, 21 Nov 2014 06:22:46 -0500 (EST) Subject: [keycloak-user] Recommendations for protecting REST service with bearer token and basic auth In-Reply-To: <546F13F5.9020807@kroehling.de> References: <1845864658.5951344.1415369800735.JavaMail.zimbra@redhat.com> <1265926769.1688381.1416386022401.JavaMail.zimbra@redhat.com> <546C63F6.50406@kroehling.de> <1769288502.1847810.1416398478191.JavaMail.zimbra@redhat.com> <546C9B5A.8070907@kroehling.de> <546CB0D0.3080808@redhat.com> <1789419203.2102266.1416413806324.JavaMail.zimbra@redhat.com> <546F13F5.9020807@kroehling.de> Message-ID: <1532398938.3278849.1416568966388.JavaMail.zimbra@redhat.com> ----- Original Message ----- > From: "Juraci Paix?o Kr?hling" > To: keycloak-user at lists.jboss.org > Sent: Friday, 21 November, 2014 11:29:09 AM > Subject: Re: [keycloak-user] Recommendations for protecting REST service with bearer token and basic auth > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 > > On 11/19/2014 05:16 PM, Stian Thorgersen wrote: > > ----- Original Message ----- > >> From: "Bill Burke" To: > >> keycloak-user at lists.jboss.org Sent: Wednesday, 19 November, 2014 > >> 4:01:36 PM Subject: Re: [keycloak-user] Recommendations for > >> protecting REST service with bearer token and basic auth > >> > >> You guys are basically describing certificate auth. > > > > Yes for the one use-case I described (where the app is the user). > > There's also the case where a user gives an application permanent > > (offline) access to their account. In Google they have a special > > scope you can request for this > > (https://developers.google.com/accounts/docs/OAuth2WebServer#offline). > > > > > If there are no objections, I'll start scratching an implementation of > this offline mode, as something on this direction will be needed for > the project I'm helping with. Sure, that would be great. There's a fair amount of work here though: 1. Account management needs to view clients with access and allow revoking individual clients 2. Need some built-in special role for apps to request offline tokens 3. Need to support scope param to actually request the above role 4. Need to support client sessions that are not connected to a user session - and also clean-up of these 5. Probably need an expiration for offline tokens, which needs to be configurable through the admin console > > Ideally, the project would benefit from using service accounts instead > of acting on behalf of an specific user, but as there will be only one > account per user/realm, this would do for now :-) > > - - Juca. > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1 > > iQEcBAEBCgAGBQJUbxP1AAoJEDnJtskdmzLM7IQH/RFJ5Cf0reec9CgMjxO1D1tt > lgS20P6d17Ki0UocoNidp59YdP5TRKycYbCMchbfTZu4In+9gEBzsdxK+4acprPF > sp6WCa1Comc8vFCX8Or9gxUEDRH+axWR4t/bIsBf23IvXQ1BUIVg0s21RxFoMhPP > fGHoaAEGthez6Dhr7GSwr46FEO2xP94jHJ7nAs67DNeh0vvZmQ1iynBkF3NmfQzP > dMCjny4i2D/UZCcSr72ud0DnoAi//vIQ86KObrqsiHV2eOhWYfHB9TozC/P1lKVM > 5D8qByrnxtmgA/nYNuRFmKTYf2n6MZTU5AlSFJZr4svU6isl2zwkpczhwDRshjc= > =x/UK > -----END PGP SIGNATURE----- > _______________________________________________ > keycloak-user mailing list > keycloak-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user > From bburke at redhat.com Fri Nov 21 08:27:03 2014 From: bburke at redhat.com (Bill Burke) Date: Fri, 21 Nov 2014 08:27:03 -0500 Subject: [keycloak-user] Authentication throw a proxy on Undertow In-Reply-To: References: Message-ID: <546F3DA7.1060008@redhat.com> Still needs some work, testing, and also to make it a distribution. On 11/21/2014 2:47 AM, Davide Ungari wrote: > Hi Bill, > I see you have pushed some changes. > Tell me as soon as you need me to test it. > > Thank you, > Davide. > > Weird... I'm actually screwing around with writing a security proxy > right now. I just started like an hour or so ago so I'm not exactly > sure...but I don't think you can implement this with the current > codebase. You need a Undertow only (no servlet) authentication > mechanism and to set up the security handler chain correctly. (See the > BasicAuthServer example in Undertow). I should have something > working in master by the end of the week. On 11/19/2014 6:33 PM, > Davide Ungari wrote: > >/Hi everybody, />/this is the big picture: />/a. frontend > application with Undertow />/b. backend application with Undertow > and Resteasy for REST API /> > >/Both are using Keycloak as SSO. /> > >/I'm trying to configure a proxy from A to B in order to expose > backend />/API without CORS problems to the frontend. /> > >/I asked support also to Undertow guys but the issue seems around > the />/integration of Keycloack in Undertow. My proxy is implemented > like: /> > >/final ProxyClient proxyClient = new > />/SimpleProxyClientProvider(new URI("http://localhost:8181 > />/")); />/final > ProxyHandler proxyHandler = new />/ProxyHandler(proxyClient, > servletHandler); />/proxyHandler.addRequestHeader(new > />/HttpString("Authorization"), new ExchangeAttribute() { > />/@Override />/public String readAttribute(HttpServerExchange > />/exchange) { />/exchange. />/RefreshableKeycloakSecurityContext > context = />/(RefreshableKeycloakSecurityContext) > exchange.getSecurityContext(); />/return "Bearer " + > context.getTokenString(); />/} /> > >/@Override />/public void writeAttribute(HttpServerExchange > />/exchange, String newValue) throws ReadOnlyAttributeException { > />/// TODO Auto-generated method stub />/} />/}); /> > >/The problem is that the exchange.getSecurityContext() is always > null. />/Any ideas? /> > >/Thanks /> > > > > > >/-- />/Davide /> > > > >/_______________________________________________ />/keycloak-user > mailing list />/keycloak-user at lists.jboss.org > > />/https://lists.jboss.org/mailman/listinfo/keycloak-user /> -- > Bill Burke > JBoss, a division of Red Hat > http://bill.burkecentral.com > > > > _______________________________________________ > keycloak-user mailing list > keycloak-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user > -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From bburke at redhat.com Fri Nov 21 08:47:39 2014 From: bburke at redhat.com (Bill Burke) Date: Fri, 21 Nov 2014 08:47:39 -0500 Subject: [keycloak-user] Recommendations for protecting REST service with bearer token and basic auth In-Reply-To: <1532398938.3278849.1416568966388.JavaMail.zimbra@redhat.com> References: <1845864658.5951344.1415369800735.JavaMail.zimbra@redhat.com> <1265926769.1688381.1416386022401.JavaMail.zimbra@redhat.com> <546C63F6.50406@kroehling.de> <1769288502.1847810.1416398478191.JavaMail.zimbra@redhat.com> <546C9B5A.8070907@kroehling.de> <546CB0D0.3080808@redhat.com> <1789419203.2102266.1416413806324.JavaMail.zimbra@redhat.com> <546F13F5.9020807@kroehling.de> <1532398938.3278849.1416568966388.JavaMail.zimbra@redhat.com> Message-ID: <546F427B.6080608@redhat.com> Why do you need to do something that complicated? You could have per-app/oauth-client token policies. The token policy could have a refresh token expiration policy of never. Then everything just hooks into existing screens and architecture. On 11/21/2014 6:22 AM, Stian Thorgersen wrote: > > > ----- Original Message ----- >> From: "Juraci Paix?o Kr?hling" >> To: keycloak-user at lists.jboss.org >> Sent: Friday, 21 November, 2014 11:29:09 AM >> Subject: Re: [keycloak-user] Recommendations for protecting REST service with bearer token and basic auth >> >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA512 >> >> On 11/19/2014 05:16 PM, Stian Thorgersen wrote: >>> ----- Original Message ----- >>>> From: "Bill Burke" To: >>>> keycloak-user at lists.jboss.org Sent: Wednesday, 19 November, 2014 >>>> 4:01:36 PM Subject: Re: [keycloak-user] Recommendations for >>>> protecting REST service with bearer token and basic auth >>>> >>>> You guys are basically describing certificate auth. >>> >>> Yes for the one use-case I described (where the app is the user). >>> There's also the case where a user gives an application permanent >>> (offline) access to their account. In Google they have a special >>> scope you can request for this >>> (https://developers.google.com/accounts/docs/OAuth2WebServer#offline). >>> >>> >> If there are no objections, I'll start scratching an implementation of >> this offline mode, as something on this direction will be needed for >> the project I'm helping with. > > Sure, that would be great. There's a fair amount of work here though: > > 1. Account management needs to view clients with access and allow revoking individual clients > 2. Need some built-in special role for apps to request offline tokens > 3. Need to support scope param to actually request the above role > 4. Need to support client sessions that are not connected to a user session - and also clean-up of these > 5. Probably need an expiration for offline tokens, which needs to be configurable through the admin console > >> >> Ideally, the project would benefit from using service accounts instead >> of acting on behalf of an specific user, but as there will be only one >> account per user/realm, this would do for now :-) >> >> - - Juca. >> >> -----BEGIN PGP SIGNATURE----- >> Version: GnuPG v1 >> >> iQEcBAEBCgAGBQJUbxP1AAoJEDnJtskdmzLM7IQH/RFJ5Cf0reec9CgMjxO1D1tt >> lgS20P6d17Ki0UocoNidp59YdP5TRKycYbCMchbfTZu4In+9gEBzsdxK+4acprPF >> sp6WCa1Comc8vFCX8Or9gxUEDRH+axWR4t/bIsBf23IvXQ1BUIVg0s21RxFoMhPP >> fGHoaAEGthez6Dhr7GSwr46FEO2xP94jHJ7nAs67DNeh0vvZmQ1iynBkF3NmfQzP >> dMCjny4i2D/UZCcSr72ud0DnoAi//vIQ86KObrqsiHV2eOhWYfHB9TozC/P1lKVM >> 5D8qByrnxtmgA/nYNuRFmKTYf2n6MZTU5AlSFJZr4svU6isl2zwkpczhwDRshjc= >> =x/UK >> -----END PGP SIGNATURE----- >> _______________________________________________ >> keycloak-user mailing list >> keycloak-user at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-user >> > > _______________________________________________ > keycloak-user mailing list > keycloak-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user > -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From stian at redhat.com Fri Nov 21 10:37:37 2014 From: stian at redhat.com (Stian Thorgersen) Date: Fri, 21 Nov 2014 10:37:37 -0500 (EST) Subject: [keycloak-user] Recommendations for protecting REST service with bearer token and basic auth In-Reply-To: <546F427B.6080608@redhat.com> References: <1845864658.5951344.1415369800735.JavaMail.zimbra@redhat.com> <1769288502.1847810.1416398478191.JavaMail.zimbra@redhat.com> <546C9B5A.8070907@kroehling.de> <546CB0D0.3080808@redhat.com> <1789419203.2102266.1416413806324.JavaMail.zimbra@redhat.com> <546F13F5.9020807@kroehling.de> <1532398938.3278849.1416568966388.JavaMail.zimbra@redhat.com> <546F427B.6080608@redhat.com> Message-ID: <1649680612.3476547.1416584257521.JavaMail.zimbra@redhat.com> ----- Original Message ----- > From: "Bill Burke" > To: keycloak-user at lists.jboss.org > Sent: Friday, 21 November, 2014 2:47:39 PM > Subject: Re: [keycloak-user] Recommendations for protecting REST service with bearer token and basic auth > > Why do you need to do something that complicated? You could have > per-app/oauth-client token policies. The token policy could have a > refresh token expiration policy of never. Then everything just hooks > into existing screens and architecture. That'd be good as well, but it would still expire when user session expires. You need to have an option to let a client create tokens that are not linked to the user session. Also, for oauth clients the grant page should say that the app is requesting offline access. Having an offline toggle and per-app expiration would work at least initially, but I think in the future we'll have to support scope query param. > > On 11/21/2014 6:22 AM, Stian Thorgersen wrote: > > > > > > ----- Original Message ----- > >> From: "Juraci Paix?o Kr?hling" > >> To: keycloak-user at lists.jboss.org > >> Sent: Friday, 21 November, 2014 11:29:09 AM > >> Subject: Re: [keycloak-user] Recommendations for protecting REST service > >> with bearer token and basic auth > >> > >> -----BEGIN PGP SIGNED MESSAGE----- > >> Hash: SHA512 > >> > >> On 11/19/2014 05:16 PM, Stian Thorgersen wrote: > >>> ----- Original Message ----- > >>>> From: "Bill Burke" To: > >>>> keycloak-user at lists.jboss.org Sent: Wednesday, 19 November, 2014 > >>>> 4:01:36 PM Subject: Re: [keycloak-user] Recommendations for > >>>> protecting REST service with bearer token and basic auth > >>>> > >>>> You guys are basically describing certificate auth. > >>> > >>> Yes for the one use-case I described (where the app is the user). > >>> There's also the case where a user gives an application permanent > >>> (offline) access to their account. In Google they have a special > >>> scope you can request for this > >>> (https://developers.google.com/accounts/docs/OAuth2WebServer#offline). > >>> > >>> > >> If there are no objections, I'll start scratching an implementation of > >> this offline mode, as something on this direction will be needed for > >> the project I'm helping with. > > > > Sure, that would be great. There's a fair amount of work here though: > > > > 1. Account management needs to view clients with access and allow revoking > > individual clients > > 2. Need some built-in special role for apps to request offline tokens > > 3. Need to support scope param to actually request the above role > > 4. Need to support client sessions that are not connected to a user session > > - and also clean-up of these > > 5. Probably need an expiration for offline tokens, which needs to be > > configurable through the admin console > > > >> > >> Ideally, the project would benefit from using service accounts instead > >> of acting on behalf of an specific user, but as there will be only one > >> account per user/realm, this would do for now :-) > >> > >> - - Juca. > >> > >> -----BEGIN PGP SIGNATURE----- > >> Version: GnuPG v1 > >> > >> iQEcBAEBCgAGBQJUbxP1AAoJEDnJtskdmzLM7IQH/RFJ5Cf0reec9CgMjxO1D1tt > >> lgS20P6d17Ki0UocoNidp59YdP5TRKycYbCMchbfTZu4In+9gEBzsdxK+4acprPF > >> sp6WCa1Comc8vFCX8Or9gxUEDRH+axWR4t/bIsBf23IvXQ1BUIVg0s21RxFoMhPP > >> fGHoaAEGthez6Dhr7GSwr46FEO2xP94jHJ7nAs67DNeh0vvZmQ1iynBkF3NmfQzP > >> dMCjny4i2D/UZCcSr72ud0DnoAi//vIQ86KObrqsiHV2eOhWYfHB9TozC/P1lKVM > >> 5D8qByrnxtmgA/nYNuRFmKTYf2n6MZTU5AlSFJZr4svU6isl2zwkpczhwDRshjc= > >> =x/UK > >> -----END PGP SIGNATURE----- > >> _______________________________________________ > >> keycloak-user mailing list > >> keycloak-user at lists.jboss.org > >> https://lists.jboss.org/mailman/listinfo/keycloak-user > >> > > > > _______________________________________________ > > keycloak-user mailing list > > keycloak-user at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/keycloak-user > > > > -- > Bill Burke > JBoss, a division of Red Hat > http://bill.burkecentral.com > _______________________________________________ > keycloak-user mailing list > keycloak-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user From bburke at redhat.com Fri Nov 21 11:09:08 2014 From: bburke at redhat.com (Bill Burke) Date: Fri, 21 Nov 2014 11:09:08 -0500 Subject: [keycloak-user] Recommendations for protecting REST service with bearer token and basic auth In-Reply-To: <1649680612.3476547.1416584257521.JavaMail.zimbra@redhat.com> References: <1845864658.5951344.1415369800735.JavaMail.zimbra@redhat.com> <1769288502.1847810.1416398478191.JavaMail.zimbra@redhat.com> <546C9B5A.8070907@kroehling.de> <546CB0D0.3080808@redhat.com> <1789419203.2102266.1416413806324.JavaMail.zimbra@redhat.com> <546F13F5.9020807@kroehling.de> <1532398938.3278849.1416568966388.JavaMail.zimbra@redhat.com> <546F427B.6080608@redhat.com> <1649680612.3476547.1416584257521.JavaMail.zimbra@redhat.com> Message-ID: <546F63A4.8040108@redhat.com> On 11/21/2014 10:37 AM, Stian Thorgersen wrote: > > > ----- Original Message ----- >> From: "Bill Burke" >> To: keycloak-user at lists.jboss.org >> Sent: Friday, 21 November, 2014 2:47:39 PM >> Subject: Re: [keycloak-user] Recommendations for protecting REST service with bearer token and basic auth >> >> Why do you need to do something that complicated? You could have >> per-app/oauth-client token policies. The token policy could have a >> refresh token expiration policy of never. Then everything just hooks >> into existing screens and architecture. > > That'd be good as well, but it would still expire when user session expires. You need to have an option to let a client create tokens that are not linked to the user session. Also, for oauth clients the grant page should say that the app is requesting offline access. Having an offline toggle and per-app expiration would work at least initially, but I think in the future we'll have to support scope query param. > I don't think we ever want to separate the token from the user session. User and client session contains information about: * how the user logged in (auth method) * IP address * When they logged in. All information you'll want to display to the user and admin. Instead, maybe a specific REST api for creating long-lived user sessions/refresh tokens? A client would make an authenticated request to this admin api, provide the refresh token it obtain through normal mechanisms, server would check to make sure the client is allowed to "upgrade" the refresh token, create a new UserSession/ClientSession, create a new refresh token, send back the refresh token. -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From juraci at kroehling.de Fri Nov 21 11:35:17 2014 From: juraci at kroehling.de (=?windows-1252?Q?Juraci_Paix=E3o_Kr=F6hling?=) Date: Fri, 21 Nov 2014 17:35:17 +0100 Subject: [keycloak-user] Recommendations for protecting REST service with bearer token and basic auth In-Reply-To: <546F63A4.8040108@redhat.com> References: <1845864658.5951344.1415369800735.JavaMail.zimbra@redhat.com> <1769288502.1847810.1416398478191.JavaMail.zimbra@redhat.com> <546C9B5A.8070907@kroehling.de> <546CB0D0.3080808@redhat.com> <1789419203.2102266.1416413806324.JavaMail.zimbra@redhat.com> <546F13F5.9020807@kroehling.de> <1532398938.3278849.1416568966388.JavaMail.zimbra@redhat.com> <546F427B.6080608@redhat.com> <1649680612.3476547.1416584257521.JavaMail.zimbra@redhat.com> <546F63A4.8040108@redhat.com> Message-ID: <546F69C5.9000107@kroehling.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 11/21/2014 05:09 PM, Bill Burke wrote: > I don't think we ever want to separate the token from the user > session. So, this means that all hosts using an offline refresh token created for the user "jdoe1" will have to be replaced if said employee is fired? This would be the advantage (and main purpose, IMO) of having service accounts. - - Juca. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBCgAGBQJUb2nFAAoJEDnJtskdmzLMxiAH/ArOh1x2S23w+ReM/PHu55ri vu5KfeNdKqUG0an/ot57lhVBgPFmk5UAU6D1+rCniNXpBMHhhv7Ww0KK2XnMF1S0 im08ZYBLjgvDLo9gpyJ/OF33TEThmFePhdKBU0ZnOOR5xGKqsS5A6J6DKOJjUgCp kYQDINFRT2Cak+10hCDZAt4gZa8+FlCpk9KpbBQHhocN5R7wz4c/K4NXaWNImjsv f/TquJmtT0wUZ9hqjKmZRzCeXRCaS3lT7/PMO9lQE8wyXg5yyRhqCz1yG5zDooOG 07Y72csj8pVYDLmtTlhrapsu9648vC2bh5KxwFikieQjR30Z//ictWshT3lQAK4= =jmT4 -----END PGP SIGNATURE----- From bburke at redhat.com Fri Nov 21 11:55:14 2014 From: bburke at redhat.com (Bill Burke) Date: Fri, 21 Nov 2014 11:55:14 -0500 Subject: [keycloak-user] Recommendations for protecting REST service with bearer token and basic auth In-Reply-To: <546F69C5.9000107@kroehling.de> References: <1845864658.5951344.1415369800735.JavaMail.zimbra@redhat.com> <1769288502.1847810.1416398478191.JavaMail.zimbra@redhat.com> <546C9B5A.8070907@kroehling.de> <546CB0D0.3080808@redhat.com> <1789419203.2102266.1416413806324.JavaMail.zimbra@redhat.com> <546F13F5.9020807@kroehling.de> <1532398938.3278849.1416568966388.JavaMail.zimbra@redhat.com> <546F427B.6080608@redhat.com> <1649680612.3476547.1416584257521.JavaMail.zimbra@redhat.com> <546F63A4.8040108@redhat.com> <546F69C5.9000107@kroehling.de> Message-ID: <546F6E72.3050407@redhat.com> On 11/21/2014 11:35 AM, Juraci Paix?o Kr?hling wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 > > On 11/21/2014 05:09 PM, Bill Burke wrote: >> I don't think we ever want to separate the token from the user >> session. > > So, this means that all hosts using an offline refresh token created > for the user "jdoe1" will have to be replaced if said employee is > fired? This would be the advantage (and main purpose, IMO) of having > service accounts. > Why does a "service account" have to be anything special? Why can't it be a regular user? -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From juraci at kroehling.de Fri Nov 21 12:15:24 2014 From: juraci at kroehling.de (=?windows-1252?Q?Juraci_Paix=E3o_Kr=F6hling?=) Date: Fri, 21 Nov 2014 18:15:24 +0100 Subject: [keycloak-user] Recommendations for protecting REST service with bearer token and basic auth In-Reply-To: <546F6E72.3050407@redhat.com> References: <1845864658.5951344.1415369800735.JavaMail.zimbra@redhat.com> <1769288502.1847810.1416398478191.JavaMail.zimbra@redhat.com> <546C9B5A.8070907@kroehling.de> <546CB0D0.3080808@redhat.com> <1789419203.2102266.1416413806324.JavaMail.zimbra@redhat.com> <546F13F5.9020807@kroehling.de> <1532398938.3278849.1416568966388.JavaMail.zimbra@redhat.com> <546F427B.6080608@redhat.com> <1649680612.3476547.1416584257521.JavaMail.zimbra@redhat.com> <546F63A4.8040108@redhat.com> <546F69C5.9000107@kroehling.de> <546F6E72.3050407@redhat.com> Message-ID: <546F732C.20301@kroehling.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 11/21/2014 05:55 PM, Bill Burke wrote: > Why does a "service account" have to be anything special? Why > can't it be a regular user? I don't know much about the internals and the implementation of the user model in KC, but from where I'm standing, it can very well be. So, to recap, this is how the flow for an external client (bash script) would be: - - user creates an oauth client with refresh token policy set to never expire - - bash reads the keycloak.json and refresh token from somewhere - - bash uses the refresh token to obtain an access token from KC server - - bash uses the access token to make the request to the backend On the first run: - - bash (or another CLI) builds an URL - - user opens this URL, logs in and gets a code from KC server - - user adds this code to the bash/CLI - - bash/CLI exchanges this code for a refresh token, persisting it afterwards It seems that the only change required then is to move the token policy to the apps/oauth clients. If so, I'll then start scratching a proposal for this change. And perhaps a shell/native (Linux) client that would handle the boiler plate above. - - Juca. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBCgAGBQJUb3MrAAoJEDnJtskdmzLMwNoIAIHQ+NyhU+liv7D/oLIcNW4w 4mF4tFqXpmWxU989aND6XbsShmAIL67TvzNidtKEdSjUMkvYNTsgZtYEv9o5CPPt nanUmLMUEbrWJ9+Dmv4l5t83CJY4P1kSBojRzvjBeBG1FVh4sPbZfp1cXtBSccvU c0uJ/Fx7KUvvkvTUqpcy/hC72rujLor38/BVxK+MtLRPG93sFfYHN1o4FWDF+GYv t35hX6+ARANeA9c9Pqy9Rywa+y2kFRLat6rSIC5wcJO7qF9YCwUlyMiCE4seBNJC WjFmh8eVuMVryLDBZtbHpOs0N9XmM7QvI4ydM7EmWQQ9TWbs/I1TmPqPEjacGGs= =n6oJ -----END PGP SIGNATURE----- From mposolda at redhat.com Fri Nov 21 16:57:07 2014 From: mposolda at redhat.com (Marek Posolda) Date: Fri, 21 Nov 2014 22:57:07 +0100 Subject: [keycloak-user] Obtaining the user name from the security context In-Reply-To: <1510952577.11835794.1416479122326.JavaMail.zimbra@redhat.com> References: <1869846893.11462243.1416414017373.JavaMail.zimbra@redhat.com> <546CD999.9000808@redhat.com> <1510952577.11835794.1416479122326.JavaMail.zimbra@redhat.com> Message-ID: <546FB533.3020601@redhat.com> Hi, I've just tried it and figured that it doesn't work due to bug https://issues.jboss.org/browse/KEYCLOAK-857 . It's fixed in latest keycloak master and will be available in next release 1.1.0.Beta2 . The easiest workaround is to configure absolute URI for auth-server-url . So instead of "/auth", you can use "http://localhost:8080/auth" or something like that according to your env. Hope it helps, Marek On 20.11.2014 11:25, Gary Brown wrote: > Hi > > Thanks for the information. > > However, I've tried it without success - I also tried using this attribute in the keycloak unconfigured-demo and preconfigured-demo examples for customer-app/product-app, and didn't have an effect on them either. > > Just wondering whether the text in the doc "OpenID Connection ID Token attribute to populate the UserPrincipal name with" implies that this attribute only works for OpenID? > > With the unconfigured version, it wasn't clear whether this attribute would be set under the realm or secure-deployment elements, so initially I tried just under the realm but then eventually defined the attribute under both. Attached the wildfly standalone-full.xml. > > Regards > Gary > > ----- Original Message ----- >> If you have 1.1.0.Beta1, you can try to use "principal-attribute" with >> value "|preferred_username" in the configuration of your adapter. More >> info in |http://docs.jboss.org/keycloak/docs/1.1.0.Beta1/userguide >> /html/ch07.html#adapter-config . >> >> It should also work to cast getUserPrincipal() to KeycloakPrincipal and >> use something like: >> >> ((KeycloakPrincipal)getUserPrincipal()).getKeycloakSecurityContext().getToken().getPreferredUsername() >> >> this should also work on older versions, but your code may need to have >> dependencies on keycloak. >> >> Marek >> >> On 19.11.2014 17:20, Gary Brown wrote: >>> Hi >>> >>> When I access getUserPrincipal().getName() in >>> javax.ws.rs.core.SecurityContext I get the UID. >>> >>> Is it possible to obtain the actual user name? >>> >>> Regards >>> Gary >>> _______________________________________________ >>> keycloak-user mailing list >>> keycloak-user at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/keycloak-user >> From afsg77 at gmail.com Fri Nov 21 18:58:16 2014 From: afsg77 at gmail.com (=?UTF-8?Q?Fabi=C3=A1n_Silva?=) Date: Fri, 21 Nov 2014 17:58:16 -0600 Subject: [keycloak-user] Error on application log in In-Reply-To: <1823273882.2484255.1416471931969.JavaMail.zimbra@redhat.com> References: <5465BCF1.6000304@redhat.com> <546CD33B.1020607@redhat.com> <1823273882.2484255.1416471931969.JavaMail.zimbra@redhat.com> Message-ID: http://docs.jboss.org/keycloak/docs/1.1.0.Beta1/userguide/html/ch07.html#adapter-config "client-keystore Not supported yet, but we will support in future versions." So if my adapter has SSL enabled is not supported yet? Or how do I configure it to work if my adapter has the SSL enabled? I tried with an adapter without SSL enabled and the keycloak with the SSL enabled and it worked. But when I tried it with both, the adapter and the keycloak with SSL enabled, it doesn't work. I got the following logs on the adapter: ERROR [org.keycloak.adapters.OAuthRequestAuthenticator] (default task-6) failed to turn code into token ERROR [org.keycloak.adapters.OAuthRequestAuthenticator] (default task-6) status from server: 404 Regards On Thu, Nov 20, 2014 at 2:25 AM, Stian Thorgersen wrote: > Are there no errors or warning in the server log? Try enabling debug for > org.keycloak and see if there's anything interesting. > > First thing try the exact same setup (two servers), but without ssl. > > If that works disable enable ssl, but disable the trust manager in the > adapter (disable-trust-manager option on adapter, see > http://docs.jboss.org/keycloak/docs/1.1.0.Beta1/userguide/html/ch07.html#adapter-config > ). > > If it still works create a truststore and import your certificate. Then > set truststore and truststore-password on the adapter. > > ----- Original Message ----- > > From: "Fabi?n Silva" > > To: "Stan Silvert" > > Cc: keycloak-user at lists.jboss.org > > Sent: Wednesday, 19 November, 2014 6:35:15 PM > > Subject: Re: [keycloak-user] Error on application log in > > > > I tried deploying it onto a local wildfly in domain without the SSL > enabled > > and it worked. What I can't figure it out is why the SSL is causing > conflict > > and how to solve this, I can't simply disable the SSL. > > > > Regards > > > > On Wed, Nov 19, 2014 at 11:28 AM, Stan Silvert < ssilvert at redhat.com > > wrote: > > > > > > > > Have you tried it using the two servers but without SSL? > > > > You can set ssl-required to "none" on the adapter (application) side. > Also on > > the Keycloak server side, try setting Access Type to "public". Do one of > > those at a time and see if either causes it to work. That might narrow it > > down a bit. > > > > > > On 11/19/2014 11:29 AM, Fabi?n Silva wrote: > > > > > > > > Hi, > > I'm running out of ideas in here. In simple terms I got a Wildfly > running on > > domain on a server and a keycloak on another server. I set the adapters > on > > my wildfly and deploy, to this wildfly, a web app that uses keycloak. > When I > > try to access the web app it displays the keycloak login, it validates > the > > users ok, but when you access with a correct user and password it shows > the > > "403 - Forbidden". At first I thought it was some issue with the roles, > but > > that didn't fix it. > > > > Regards > > > > On Fri, Nov 14, 2014 at 10:20 AM, Fabi?n Silva < afsg77 at gmail.com > > wrote: > > > > > > > > Hi, > > It is already set to use the absolute path. And the keycloak is working > when > > I deploy the application to my local wildfly domain. The issue is when I > try > > to deploy to another wildfly in domain mode on a separate server. The > > application is the same and the only difference I can tell from the two > > wildflys is that the local don't have the SSL/HTTPS enabled. I have the > > keycloak adapter set in both domains. > > > > I'm trying to trace those errors on the keycloak code to try to > understand > > what is happening, but I haven't been so lucky with this. > > > > Regards > > Alejandro Fabi?n Silva Grif? > > > > On Fri, Nov 14, 2014 at 2:27 AM, Marek Posolda < mposolda at redhat.com > > wrote: > > > > > > > > Hi, > > > > it failed on the adapter (application) side and error 404 means "Not > found". > > So adapter can't find the keycloak server to turn code into token. Make > sure > > to configure "auth-server-url" in keycloak.json for your application > > properly. If relative uri doesn't work for some reason, you can rather > try > > to use absolute uri for auth-server-url like " > https://localhost:8443/auth" . > > > > Marek > > > > > > On 14.11.2014 01:31, Fabi?n Silva wrote: > > > > > > > > I have a keycloak installed on wildfly standalone. I'm trying to deploy > an > > application, that use this keycloak, on a separate server with wilflly > > running on domain mode. I tried first to deploy on a domain out of the > box > > on my local machine, setting the > keycloak-wildfly-adapter-dist-1.0.4.Final. > > It deploys fine and does the authentication without any issues. When I > try > > to migrate it to the server running my wilfly (also in domain mode and > the > > keycloak adapter set), it deploys fine and shows the keycloak login once > you > > enter the application. But the problem is that when you login it > displays a > > "403 - Forbidden" and on the log I'm seeing > > ERROR [org.keycloak.adapters.OAuthRequestAuthenticator] (default task-6) > > failed to turn code into token > > ERROR [org.keycloak.adapters.OAuthRequestAuthenticator] (default task-6) > > status from server: 404 > > The only difference between those two wildfly domain mode is that in the > > local I don't have the the SSL/HTTPS enabled. > > > > Have anyone seen this error? or have an idea of what this could be? > > > > Regards > > > > > > _______________________________________________ > > keycloak-user mailing list keycloak-user at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/keycloak-user > > > > > > > > > > > > _______________________________________________ > > keycloak-user mailing list keycloak-user at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/keycloak-user > > > > > > _______________________________________________ > > keycloak-user mailing list > > keycloak-user at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/keycloak-user > > > > > > _______________________________________________ > > 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-user/attachments/20141121/f49e76ad/attachment-0001.html From stian at redhat.com Mon Nov 24 03:27:42 2014 From: stian at redhat.com (Stian Thorgersen) Date: Mon, 24 Nov 2014 03:27:42 -0500 (EST) Subject: [keycloak-user] Recommendations for protecting REST service with bearer token and basic auth In-Reply-To: <546F732C.20301@kroehling.de> References: <1845864658.5951344.1415369800735.JavaMail.zimbra@redhat.com> <1532398938.3278849.1416568966388.JavaMail.zimbra@redhat.com> <546F427B.6080608@redhat.com> <1649680612.3476547.1416584257521.JavaMail.zimbra@redhat.com> <546F63A4.8040108@redhat.com> <546F69C5.9000107@kroehling.de> <546F6E72.3050407@redhat.com> <546F732C.20301@kroehling.de> Message-ID: <173481606.4076153.1416817662027.JavaMail.zimbra@redhat.com> There's two separate issues here: * Offline tokens - the ability for a client to obtain a token that is long lived and survives a user logout * Service accounts - an account for non-humans, if an application can authenticate as itself (to swap code-to-token) using a secret or certificate it shouldn't need to also authenticate as the "user" ----- Original Message ----- > From: "Juraci Paix?o Kr?hling" > To: keycloak-user at lists.jboss.org > Sent: Friday, 21 November, 2014 6:15:24 PM > Subject: Re: [keycloak-user] Recommendations for protecting REST service with bearer token and basic auth > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 > > On 11/21/2014 05:55 PM, Bill Burke wrote: > > Why does a "service account" have to be anything special? Why > > can't it be a regular user? > > I don't know much about the internals and the implementation of the > user model in KC, but from where I'm standing, it can very well be. > > So, to recap, this is how the flow for an external client (bash > script) would be: > > - - user creates an oauth client with refresh token policy set to never > expire > - - bash reads the keycloak.json and refresh token from somewhere > - - bash uses the refresh token to obtain an access token from KC server > - - bash uses the access token to make the request to the backend > > On the first run: > - - bash (or another CLI) builds an URL > - - user opens this URL, logs in and gets a code from KC server > - - user adds this code to the bash/CLI > - - bash/CLI exchanges this code for a refresh token, persisting it > afterwards > > It seems that the only change required then is to move the token > policy to the apps/oauth clients. If so, I'll then start scratching a > proposal for this change. And perhaps a shell/native (Linux) client > that would handle the boiler plate above. > > - - Juca. > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1 > > iQEcBAEBCgAGBQJUb3MrAAoJEDnJtskdmzLMwNoIAIHQ+NyhU+liv7D/oLIcNW4w > 4mF4tFqXpmWxU989aND6XbsShmAIL67TvzNidtKEdSjUMkvYNTsgZtYEv9o5CPPt > nanUmLMUEbrWJ9+Dmv4l5t83CJY4P1kSBojRzvjBeBG1FVh4sPbZfp1cXtBSccvU > c0uJ/Fx7KUvvkvTUqpcy/hC72rujLor38/BVxK+MtLRPG93sFfYHN1o4FWDF+GYv > t35hX6+ARANeA9c9Pqy9Rywa+y2kFRLat6rSIC5wcJO7qF9YCwUlyMiCE4seBNJC > WjFmh8eVuMVryLDBZtbHpOs0N9XmM7QvI4ydM7EmWQQ9TWbs/I1TmPqPEjacGGs= > =n6oJ > -----END PGP SIGNATURE----- > _______________________________________________ > keycloak-user mailing list > keycloak-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user > From stian at redhat.com Mon Nov 24 03:29:46 2014 From: stian at redhat.com (Stian Thorgersen) Date: Mon, 24 Nov 2014 03:29:46 -0500 (EST) Subject: [keycloak-user] Error on application log in In-Reply-To: References: <5465BCF1.6000304@redhat.com> <546CD33B.1020607@redhat.com> <1823273882.2484255.1416471931969.JavaMail.zimbra@redhat.com> Message-ID: <1453102381.4076575.1416817786988.JavaMail.zimbra@redhat.com> The options you're after are truststore, truststore-password and disable-trust-manager, not client-keystore. ----- Original Message ----- > From: "Fabi?n Silva" > To: "Stian Thorgersen" > Cc: "Stan Silvert" , keycloak-user at lists.jboss.org > Sent: Saturday, 22 November, 2014 12:58:16 AM > Subject: Re: [keycloak-user] Error on application log in > > http://docs.jboss.org/keycloak/docs/1.1.0.Beta1/userguide/html/ch07.html#adapter-config > "client-keystore > Not supported yet, but we will support in future versions." > So if my adapter has SSL enabled is not supported yet? Or how do I > configure it to work if my adapter has the SSL enabled? > I tried with an adapter without SSL enabled and the keycloak with the SSL > enabled and it worked. But when I tried it with both, the adapter and the > keycloak with SSL enabled, it doesn't work. I got the following logs on the > adapter: > ERROR [org.keycloak.adapters.OAuthRequestAuthenticator] (default task-6) > failed to turn code into token > ERROR [org.keycloak.adapters.OAuthRequestAuthenticator] (default task-6) > status from server: 404 > > Regards > > On Thu, Nov 20, 2014 at 2:25 AM, Stian Thorgersen wrote: > > > Are there no errors or warning in the server log? Try enabling debug for > > org.keycloak and see if there's anything interesting. > > > > First thing try the exact same setup (two servers), but without ssl. > > > > If that works disable enable ssl, but disable the trust manager in the > > adapter (disable-trust-manager option on adapter, see > > http://docs.jboss.org/keycloak/docs/1.1.0.Beta1/userguide/html/ch07.html#adapter-config > > ). > > > > If it still works create a truststore and import your certificate. Then > > set truststore and truststore-password on the adapter. > > > > ----- Original Message ----- > > > From: "Fabi?n Silva" > > > To: "Stan Silvert" > > > Cc: keycloak-user at lists.jboss.org > > > Sent: Wednesday, 19 November, 2014 6:35:15 PM > > > Subject: Re: [keycloak-user] Error on application log in > > > > > > I tried deploying it onto a local wildfly in domain without the SSL > > enabled > > > and it worked. What I can't figure it out is why the SSL is causing > > conflict > > > and how to solve this, I can't simply disable the SSL. > > > > > > Regards > > > > > > On Wed, Nov 19, 2014 at 11:28 AM, Stan Silvert < ssilvert at redhat.com > > > wrote: > > > > > > > > > > > > Have you tried it using the two servers but without SSL? > > > > > > You can set ssl-required to "none" on the adapter (application) side. > > Also on > > > the Keycloak server side, try setting Access Type to "public". Do one of > > > those at a time and see if either causes it to work. That might narrow it > > > down a bit. > > > > > > > > > On 11/19/2014 11:29 AM, Fabi?n Silva wrote: > > > > > > > > > > > > Hi, > > > I'm running out of ideas in here. In simple terms I got a Wildfly > > running on > > > domain on a server and a keycloak on another server. I set the adapters > > on > > > my wildfly and deploy, to this wildfly, a web app that uses keycloak. > > When I > > > try to access the web app it displays the keycloak login, it validates > > the > > > users ok, but when you access with a correct user and password it shows > > the > > > "403 - Forbidden". At first I thought it was some issue with the roles, > > but > > > that didn't fix it. > > > > > > Regards > > > > > > On Fri, Nov 14, 2014 at 10:20 AM, Fabi?n Silva < afsg77 at gmail.com > > > wrote: > > > > > > > > > > > > Hi, > > > It is already set to use the absolute path. And the keycloak is working > > when > > > I deploy the application to my local wildfly domain. The issue is when I > > try > > > to deploy to another wildfly in domain mode on a separate server. The > > > application is the same and the only difference I can tell from the two > > > wildflys is that the local don't have the SSL/HTTPS enabled. I have the > > > keycloak adapter set in both domains. > > > > > > I'm trying to trace those errors on the keycloak code to try to > > understand > > > what is happening, but I haven't been so lucky with this. > > > > > > Regards > > > Alejandro Fabi?n Silva Grif? > > > > > > On Fri, Nov 14, 2014 at 2:27 AM, Marek Posolda < mposolda at redhat.com > > > wrote: > > > > > > > > > > > > Hi, > > > > > > it failed on the adapter (application) side and error 404 means "Not > > found". > > > So adapter can't find the keycloak server to turn code into token. Make > > sure > > > to configure "auth-server-url" in keycloak.json for your application > > > properly. If relative uri doesn't work for some reason, you can rather > > try > > > to use absolute uri for auth-server-url like " > > https://localhost:8443/auth" . > > > > > > Marek > > > > > > > > > On 14.11.2014 01:31, Fabi?n Silva wrote: > > > > > > > > > > > > I have a keycloak installed on wildfly standalone. I'm trying to deploy > > an > > > application, that use this keycloak, on a separate server with wilflly > > > running on domain mode. I tried first to deploy on a domain out of the > > box > > > on my local machine, setting the > > keycloak-wildfly-adapter-dist-1.0.4.Final. > > > It deploys fine and does the authentication without any issues. When I > > try > > > to migrate it to the server running my wilfly (also in domain mode and > > the > > > keycloak adapter set), it deploys fine and shows the keycloak login once > > you > > > enter the application. But the problem is that when you login it > > displays a > > > "403 - Forbidden" and on the log I'm seeing > > > ERROR [org.keycloak.adapters.OAuthRequestAuthenticator] (default task-6) > > > failed to turn code into token > > > ERROR [org.keycloak.adapters.OAuthRequestAuthenticator] (default task-6) > > > status from server: 404 > > > The only difference between those two wildfly domain mode is that in the > > > local I don't have the the SSL/HTTPS enabled. > > > > > > Have anyone seen this error? or have an idea of what this could be? > > > > > > Regards > > > > > > > > > _______________________________________________ > > > keycloak-user mailing list keycloak-user at lists.jboss.org > > > https://lists.jboss.org/mailman/listinfo/keycloak-user > > > > > > > > > > > > > > > > > > _______________________________________________ > > > keycloak-user mailing list keycloak-user at lists.jboss.org > > > https://lists.jboss.org/mailman/listinfo/keycloak-user > > > > > > > > > _______________________________________________ > > > keycloak-user mailing list > > > keycloak-user at lists.jboss.org > > > https://lists.jboss.org/mailman/listinfo/keycloak-user > > > > > > > > > _______________________________________________ > > > keycloak-user mailing list > > > keycloak-user at lists.jboss.org > > > https://lists.jboss.org/mailman/listinfo/keycloak-user > > > From stian at redhat.com Mon Nov 24 03:44:08 2014 From: stian at redhat.com (Stian Thorgersen) Date: Mon, 24 Nov 2014 03:44:08 -0500 (EST) Subject: [keycloak-user] Recommendations for protecting REST service with bearer token and basic auth In-Reply-To: <546F732C.20301@kroehling.de> References: <1845864658.5951344.1415369800735.JavaMail.zimbra@redhat.com> <1532398938.3278849.1416568966388.JavaMail.zimbra@redhat.com> <546F427B.6080608@redhat.com> <1649680612.3476547.1416584257521.JavaMail.zimbra@redhat.com> <546F63A4.8040108@redhat.com> <546F69C5.9000107@kroehling.de> <546F6E72.3050407@redhat.com> <546F732C.20301@kroehling.de> Message-ID: <1208983762.4082409.1416818648645.JavaMail.zimbra@redhat.com> There's still some unresolved issues here: * Never expire isn't good - it should be a longer expiration time * Grant page should ask the user to give the application offline access * User needs some way to revoke the access to the application in the future * Should tokens be unlinked to a user session, or should it be associated with a special user session (just setting a long expiration time for refresh tokens has no effect if user session expires) I'm also not sure what your use-case is, is this a bash script that acts on behalf of the user? or is it a server backend script? If it's the first the flow you're suggesting works, but if it's the other it's not the correct flow. ----- Original Message ----- > From: "Juraci Paix?o Kr?hling" > To: keycloak-user at lists.jboss.org > Sent: Friday, 21 November, 2014 6:15:24 PM > Subject: Re: [keycloak-user] Recommendations for protecting REST service with bearer token and basic auth > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 > > On 11/21/2014 05:55 PM, Bill Burke wrote: > > Why does a "service account" have to be anything special? Why > > can't it be a regular user? > > I don't know much about the internals and the implementation of the > user model in KC, but from where I'm standing, it can very well be. > > So, to recap, this is how the flow for an external client (bash > script) would be: > > - - user creates an oauth client with refresh token policy set to never > expire > - - bash reads the keycloak.json and refresh token from somewhere > - - bash uses the refresh token to obtain an access token from KC server > - - bash uses the access token to make the request to the backend > > On the first run: > - - bash (or another CLI) builds an URL > - - user opens this URL, logs in and gets a code from KC server > - - user adds this code to the bash/CLI > - - bash/CLI exchanges this code for a refresh token, persisting it > afterwards > > It seems that the only change required then is to move the token > policy to the apps/oauth clients. If so, I'll then start scratching a > proposal for this change. And perhaps a shell/native (Linux) client > that would handle the boiler plate above. > > - - Juca. > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1 > > iQEcBAEBCgAGBQJUb3MrAAoJEDnJtskdmzLMwNoIAIHQ+NyhU+liv7D/oLIcNW4w > 4mF4tFqXpmWxU989aND6XbsShmAIL67TvzNidtKEdSjUMkvYNTsgZtYEv9o5CPPt > nanUmLMUEbrWJ9+Dmv4l5t83CJY4P1kSBojRzvjBeBG1FVh4sPbZfp1cXtBSccvU > c0uJ/Fx7KUvvkvTUqpcy/hC72rujLor38/BVxK+MtLRPG93sFfYHN1o4FWDF+GYv > t35hX6+ARANeA9c9Pqy9Rywa+y2kFRLat6rSIC5wcJO7qF9YCwUlyMiCE4seBNJC > WjFmh8eVuMVryLDBZtbHpOs0N9XmM7QvI4ydM7EmWQQ9TWbs/I1TmPqPEjacGGs= > =n6oJ > -----END PGP SIGNATURE----- > _______________________________________________ > keycloak-user mailing list > keycloak-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user > From juraci at kroehling.de Mon Nov 24 04:12:06 2014 From: juraci at kroehling.de (=?UTF-8?B?SnVyYWNpIFBhaXjDo28gS3LDtmhsaW5n?=) Date: Mon, 24 Nov 2014 10:12:06 +0100 Subject: [keycloak-user] Recommendations for protecting REST service with bearer token and basic auth In-Reply-To: <1208983762.4082409.1416818648645.JavaMail.zimbra@redhat.com> References: <1845864658.5951344.1415369800735.JavaMail.zimbra@redhat.com> <1532398938.3278849.1416568966388.JavaMail.zimbra@redhat.com> <546F427B.6080608@redhat.com> <1649680612.3476547.1416584257521.JavaMail.zimbra@redhat.com> <546F63A4.8040108@redhat.com> <546F69C5.9000107@kroehling.de> <546F6E72.3050407@redhat.com> <546F732C.20301@kroehling.de> <1208983762.4082409.1416818648645.JavaMail.zimbra@redhat.com> Message-ID: <5472F666.9050202@kroehling.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 11/24/2014 09:44 AM, Stian Thorgersen wrote: > There's still some unresolved issues here: > > * Never expire isn't good - it should be a longer expiration time * > Grant page should ask the user to give the application offline > access * User needs some way to revoke the access to the > application in the future * Should tokens be unlinked to a user > session, or should it be associated with a special user session > (just setting a long expiration time for refresh tokens has no > effect if user session expires) > > I'm also not sure what your use-case is, is this a bash script that > acts on behalf of the user? or is it a server backend script? If > it's the first the flow you're suggesting works, but if it's the > other it's not the correct flow. My concrete case is for RHQ Metrics. A system administrator would install RHQ Metrics backend on a server and deploy a number of nodes on a cloud or a farm. Each node would send metrics to the backend. Out of the box, we'll provide some metrics collectors, like an Agent for Wildfly. But the system administrator could also build shell scripts that would gather custom information from their systems. For instance, they might have a in-house daemon for "foo" and would parse the foo.log for some data, sending it to the Metrics backend. Ideally, this would be done with a simple curl call, but I'm getting hopeless on this :) Ideally, a token/key/secret/code that I have on the nodes wouldn't expire. I'm fine with exchanging the code/secret with a token, but requiring a refresh of this "stable" code from time to time could cause some troubles. For instance, a node that hasn't received this updated stable code would stop reporting data. About service accounts vs. user specific offline access: for me, as a consumer of this feature, I couldn't care less. I'd *prefer* to have it as a service account, as I could possibly better manage it, but any solution would be fine. - - Juca. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBCgAGBQJUcvZmAAoJEDnJtskdmzLM+o8H/jTAlNhnsSJTt842ThpRNcql mTDzfGRMXMcyFJBK8kYWRFY3NY/B2n42ux8S6q/ZvxKLKye5CtbrP7rKwQuoIFZ5 BK+KQisPgYGw3CSwjB0TRW/5BawKXIoLgMRmV/fNGx8D/BeTOordyfrhBKULdKpk +fPAsh1JdXDMV9EieQQGuX9HLhp5makG0FRVnMmw+NA967vgcPEHLBz0/NQO23I1 6HlobrH/07Z64bjcdYanxlGidJ2LIYh47lYnXHPhUSjoaK9uz5ZNZ8WQ3GW0Xg36 A/kEtexkMITmNamExnJw2E1xAMvX9lso5UjTmxH9AgMPZGFZ4Znybc7ecm+V7mE= =6yHk -----END PGP SIGNATURE----- From stian at redhat.com Mon Nov 24 04:30:59 2014 From: stian at redhat.com (Stian Thorgersen) Date: Mon, 24 Nov 2014 04:30:59 -0500 (EST) Subject: [keycloak-user] Recommendations for protecting REST service with bearer token and basic auth In-Reply-To: <5472F666.9050202@kroehling.de> References: <1845864658.5951344.1415369800735.JavaMail.zimbra@redhat.com> <1649680612.3476547.1416584257521.JavaMail.zimbra@redhat.com> <546F63A4.8040108@redhat.com> <546F69C5.9000107@kroehling.de> <546F6E72.3050407@redhat.com> <546F732C.20301@kroehling.de> <1208983762.4082409.1416818648645.JavaMail.zimbra@redhat.com> <5472F666.9050202@kroehling.de> Message-ID: <253448059.4104226.1416821459765.JavaMail.zimbra@redhat.com> ----- Original Message ----- > From: "Juraci Paix?o Kr?hling" > To: "Stian Thorgersen" > Cc: keycloak-user at lists.jboss.org > Sent: Monday, 24 November, 2014 10:12:06 AM > Subject: Re: [keycloak-user] Recommendations for protecting REST service with bearer token and basic auth > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 > > On 11/24/2014 09:44 AM, Stian Thorgersen wrote: > > There's still some unresolved issues here: > > > > * Never expire isn't good - it should be a longer expiration time * > > Grant page should ask the user to give the application offline > > access * User needs some way to revoke the access to the > > application in the future * Should tokens be unlinked to a user > > session, or should it be associated with a special user session > > (just setting a long expiration time for refresh tokens has no > > effect if user session expires) > > > > I'm also not sure what your use-case is, is this a bash script that > > acts on behalf of the user? or is it a server backend script? If > > it's the first the flow you're suggesting works, but if it's the > > other it's not the correct flow. > > My concrete case is for RHQ Metrics. A system administrator would > install RHQ Metrics backend on a server and deploy a number of nodes > on a cloud or a farm. Each node would send metrics to the backend. Out > of the box, we'll provide some metrics collectors, like an Agent for > Wildfly. But the system administrator could also build shell scripts > that would gather custom information from their systems. For instance, > they might have a in-house daemon for "foo" and would parse the > foo.log for some data, sending it to the Metrics backend. Ideally, > this would be done with a simple curl call, but I'm getting hopeless > on this :) > > Ideally, a token/key/secret/code that I have on the nodes wouldn't > expire. I'm fine with exchanging the code/secret with a token, but > requiring a refresh of this "stable" code from time to time could > cause some troubles. For instance, a node that hasn't received this > updated stable code would stop reporting data. > > About service accounts vs. user specific offline access: for me, as a > consumer of this feature, I couldn't care less. I'd *prefer* to have > it as a service account, as I could possibly better manage it, but any > solution would be fine. There's a pretty big difference. Offline access gives applications permissions to act on behalf of a user, while service accounts allows users to act on behalf of themselves. Offline access is not the way to go for your use-case. We should add some sort of service accounts to Keycloak, they would: * Enable authenticating with secret, certificate or jwt/jws (also shouldn't require a client to authenticate twice) * Probably have different semantics for user sessions. It makes sense that a regular user is logged-out after a few days, but does that make sense for an service account? I'd say a service account should be a "special" user rather than something completely different. You can get this use-case to work relatively well with Keycloak as is for now though. Just use a regular user with a longish random password (or even better set the password to the client secret). Your bash script will have to be able to deal with obtaining a token through the direct grant mechanism in either case, and it'll also have to deal with expiration of tokens and refreshing tokens. Long term it may even make sense to allow KC to manage registration of devices like this. A node could generate a certificate, post some info to Keycloak to request authenticating, then an admin could grant the access. This same mechanism could be useful for IoT. > > - - Juca. > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1 > > iQEcBAEBCgAGBQJUcvZmAAoJEDnJtskdmzLM+o8H/jTAlNhnsSJTt842ThpRNcql > mTDzfGRMXMcyFJBK8kYWRFY3NY/B2n42ux8S6q/ZvxKLKye5CtbrP7rKwQuoIFZ5 > BK+KQisPgYGw3CSwjB0TRW/5BawKXIoLgMRmV/fNGx8D/BeTOordyfrhBKULdKpk > +fPAsh1JdXDMV9EieQQGuX9HLhp5makG0FRVnMmw+NA967vgcPEHLBz0/NQO23I1 > 6HlobrH/07Z64bjcdYanxlGidJ2LIYh47lYnXHPhUSjoaK9uz5ZNZ8WQ3GW0Xg36 > A/kEtexkMITmNamExnJw2E1xAMvX9lso5UjTmxH9AgMPZGFZ4Znybc7ecm+V7mE= > =6yHk > -----END PGP SIGNATURE----- > From gbrown at redhat.com Mon Nov 24 06:22:59 2014 From: gbrown at redhat.com (Gary Brown) Date: Mon, 24 Nov 2014 06:22:59 -0500 (EST) Subject: [keycloak-user] Obtaining the user name from the security context In-Reply-To: <546FB533.3020601@redhat.com> References: <1869846893.11462243.1416414017373.JavaMail.zimbra@redhat.com> <546CD999.9000808@redhat.com> <1510952577.11835794.1416479122326.JavaMail.zimbra@redhat.com> <546FB533.3020601@redhat.com> Message-ID: <33553618.13189506.1416828179585.JavaMail.zimbra@redhat.com> Thanks that works fine now. Any idea when beta2 will be released? Regards Gary ----- Original Message ----- > Hi, > > I've just tried it and figured that it doesn't work due to bug > https://issues.jboss.org/browse/KEYCLOAK-857 . It's fixed in latest > keycloak master and will be available in next release 1.1.0.Beta2 . The > easiest workaround is to configure absolute URI for auth-server-url . So > instead of "/auth", you can use "http://localhost:8080/auth" or > something like that according to your env. > > Hope it helps, > Marek > > On 20.11.2014 11:25, Gary Brown wrote: > > Hi > > > > Thanks for the information. > > > > However, I've tried it without success - I also tried using this attribute > > in the keycloak unconfigured-demo and preconfigured-demo examples for > > customer-app/product-app, and didn't have an effect on them either. > > > > Just wondering whether the text in the doc "OpenID Connection ID Token > > attribute to populate the UserPrincipal name with" implies that this > > attribute only works for OpenID? > > > > With the unconfigured version, it wasn't clear whether this attribute would > > be set under the realm or secure-deployment elements, so initially I tried > > just under the realm but then eventually defined the attribute under both. > > Attached the wildfly standalone-full.xml. > > > > Regards > > Gary > > > > ----- Original Message ----- > >> If you have 1.1.0.Beta1, you can try to use "principal-attribute" with > >> value "|preferred_username" in the configuration of your adapter. More > >> info in |http://docs.jboss.org/keycloak/docs/1.1.0.Beta1/userguide > >> /html/ch07.html#adapter-config . > >> > >> It should also work to cast getUserPrincipal() to KeycloakPrincipal and > >> use something like: > >> > >> ((KeycloakPrincipal)getUserPrincipal()).getKeycloakSecurityContext().getToken().getPreferredUsername() > >> > >> this should also work on older versions, but your code may need to have > >> dependencies on keycloak. > >> > >> Marek > >> > >> On 19.11.2014 17:20, Gary Brown wrote: > >>> Hi > >>> > >>> When I access getUserPrincipal().getName() in > >>> javax.ws.rs.core.SecurityContext I get the UID. > >>> > >>> Is it possible to obtain the actual user name? > >>> > >>> Regards > >>> Gary > >>> _______________________________________________ > >>> keycloak-user mailing list > >>> keycloak-user at lists.jboss.org > >>> https://lists.jboss.org/mailman/listinfo/keycloak-user > >> > > From bburke at redhat.com Mon Nov 24 08:44:33 2014 From: bburke at redhat.com (Bill Burke) Date: Mon, 24 Nov 2014 08:44:33 -0500 Subject: [keycloak-user] Recommendations for protecting REST service with bearer token and basic auth In-Reply-To: <1208983762.4082409.1416818648645.JavaMail.zimbra@redhat.com> References: <1845864658.5951344.1415369800735.JavaMail.zimbra@redhat.com> <1532398938.3278849.1416568966388.JavaMail.zimbra@redhat.com> <546F427B.6080608@redhat.com> <1649680612.3476547.1416584257521.JavaMail.zimbra@redhat.com> <546F63A4.8040108@redhat.com> <546F69C5.9000107@kroehling.de> <546F6E72.3050407@redhat.com> <546F732C.20301@kroehling.de> <1208983762.4082409.1416818648645.JavaMail.zimbra@redhat.com> Message-ID: <54733641.5070802@redhat.com> On 11/24/2014 3:44 AM, Stian Thorgersen wrote: > There's still some unresolved issues here: > > * Never expire isn't good - it should be a longer expiration time > * Grant page should ask the user to give the application offline access > * User needs some way to revoke the access to the application in the future > * Should tokens be unlinked to a user session, or should it be associated with a special user session (just setting a long expiration time for refresh tokens has no effect if user session expires) > IMO, it should be a new user session either consented to by the user or a specific permission that the client has. > I'm also not sure what your use-case is, is this a bash script that acts on behalf of the user? or is it a server backend script? If it's the first the flow you're suggesting works, but if it's the other it's not the correct flow. > > ----- Original Message ----- >> From: "Juraci Paix?o Kr?hling" >> To: keycloak-user at lists.jboss.org >> Sent: Friday, 21 November, 2014 6:15:24 PM >> Subject: Re: [keycloak-user] Recommendations for protecting REST service with bearer token and basic auth >> >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA512 >> >> On 11/21/2014 05:55 PM, Bill Burke wrote: >>> Why does a "service account" have to be anything special? Why >>> can't it be a regular user? >> >> I don't know much about the internals and the implementation of the >> user model in KC, but from where I'm standing, it can very well be. >> >> So, to recap, this is how the flow for an external client (bash >> script) would be: >> >> - - user creates an oauth client with refresh token policy set to never >> expire >> - - bash reads the keycloak.json and refresh token from somewhere >> - - bash uses the refresh token to obtain an access token from KC server >> - - bash uses the access token to make the request to the backend >> >> On the first run: >> - - bash (or another CLI) builds an URL >> - - user opens this URL, logs in and gets a code from KC server >> - - user adds this code to the bash/CLI >> - - bash/CLI exchanges this code for a refresh token, persisting it >> afterwards >> >> It seems that the only change required then is to move the token >> policy to the apps/oauth clients. If so, I'll then start scratching a >> proposal for this change. And perhaps a shell/native (Linux) client >> that would handle the boiler plate above. >> >> - - Juca. >> >> -----BEGIN PGP SIGNATURE----- >> Version: GnuPG v1 >> >> iQEcBAEBCgAGBQJUb3MrAAoJEDnJtskdmzLMwNoIAIHQ+NyhU+liv7D/oLIcNW4w >> 4mF4tFqXpmWxU989aND6XbsShmAIL67TvzNidtKEdSjUMkvYNTsgZtYEv9o5CPPt >> nanUmLMUEbrWJ9+Dmv4l5t83CJY4P1kSBojRzvjBeBG1FVh4sPbZfp1cXtBSccvU >> c0uJ/Fx7KUvvkvTUqpcy/hC72rujLor38/BVxK+MtLRPG93sFfYHN1o4FWDF+GYv >> t35hX6+ARANeA9c9Pqy9Rywa+y2kFRLat6rSIC5wcJO7qF9YCwUlyMiCE4seBNJC >> WjFmh8eVuMVryLDBZtbHpOs0N9XmM7QvI4ydM7EmWQQ9TWbs/I1TmPqPEjacGGs= >> =n6oJ >> -----END PGP SIGNATURE----- >> _______________________________________________ >> keycloak-user mailing list >> keycloak-user at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-user >> > > _______________________________________________ > keycloak-user mailing list > keycloak-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user > -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From stian at redhat.com Mon Nov 24 09:01:33 2014 From: stian at redhat.com (Stian Thorgersen) Date: Mon, 24 Nov 2014 09:01:33 -0500 (EST) Subject: [keycloak-user] Recommendations for protecting REST service with bearer token and basic auth In-Reply-To: <54733641.5070802@redhat.com> References: <1845864658.5951344.1415369800735.JavaMail.zimbra@redhat.com> <1649680612.3476547.1416584257521.JavaMail.zimbra@redhat.com> <546F63A4.8040108@redhat.com> <546F69C5.9000107@kroehling.de> <546F6E72.3050407@redhat.com> <546F732C.20301@kroehling.de> <1208983762.4082409.1416818648645.JavaMail.zimbra@redhat.com> <54733641.5070802@redhat.com> Message-ID: <1533496631.4262635.1416837693117.JavaMail.zimbra@redhat.com> ----- Original Message ----- > From: "Bill Burke" > To: keycloak-user at lists.jboss.org > Sent: Monday, 24 November, 2014 2:44:33 PM > Subject: Re: [keycloak-user] Recommendations for protecting REST service with bearer token and basic auth > > > > On 11/24/2014 3:44 AM, Stian Thorgersen wrote: > > There's still some unresolved issues here: > > > > * Never expire isn't good - it should be a longer expiration time > > * Grant page should ask the user to give the application offline access > > * User needs some way to revoke the access to the application in the future > > * Should tokens be unlinked to a user session, or should it be associated > > with a special user session (just setting a long expiration time for > > refresh tokens has no effect if user session expires) > > > > IMO, it should be a new user session either consented to by the user or > a specific permission that the client has. I think you're right, but it should be possible to configure a different expiration time than for a "regular" user session. Also, should they be listed in a different section in account management, or just have a label on them? > > > I'm also not sure what your use-case is, is this a bash script that acts on > > behalf of the user? or is it a server backend script? If it's the first > > the flow you're suggesting works, but if it's the other it's not the > > correct flow. > > > > ----- Original Message ----- > >> From: "Juraci Paix?o Kr?hling" > >> To: keycloak-user at lists.jboss.org > >> Sent: Friday, 21 November, 2014 6:15:24 PM > >> Subject: Re: [keycloak-user] Recommendations for protecting REST service > >> with bearer token and basic auth > >> > >> -----BEGIN PGP SIGNED MESSAGE----- > >> Hash: SHA512 > >> > >> On 11/21/2014 05:55 PM, Bill Burke wrote: > >>> Why does a "service account" have to be anything special? Why > >>> can't it be a regular user? > >> > >> I don't know much about the internals and the implementation of the > >> user model in KC, but from where I'm standing, it can very well be. > >> > >> So, to recap, this is how the flow for an external client (bash > >> script) would be: > >> > >> - - user creates an oauth client with refresh token policy set to never > >> expire > >> - - bash reads the keycloak.json and refresh token from somewhere > >> - - bash uses the refresh token to obtain an access token from KC server > >> - - bash uses the access token to make the request to the backend > >> > >> On the first run: > >> - - bash (or another CLI) builds an URL > >> - - user opens this URL, logs in and gets a code from KC server > >> - - user adds this code to the bash/CLI > >> - - bash/CLI exchanges this code for a refresh token, persisting it > >> afterwards > >> > >> It seems that the only change required then is to move the token > >> policy to the apps/oauth clients. If so, I'll then start scratching a > >> proposal for this change. And perhaps a shell/native (Linux) client > >> that would handle the boiler plate above. > >> > >> - - Juca. > >> > >> -----BEGIN PGP SIGNATURE----- > >> Version: GnuPG v1 > >> > >> iQEcBAEBCgAGBQJUb3MrAAoJEDnJtskdmzLMwNoIAIHQ+NyhU+liv7D/oLIcNW4w > >> 4mF4tFqXpmWxU989aND6XbsShmAIL67TvzNidtKEdSjUMkvYNTsgZtYEv9o5CPPt > >> nanUmLMUEbrWJ9+Dmv4l5t83CJY4P1kSBojRzvjBeBG1FVh4sPbZfp1cXtBSccvU > >> c0uJ/Fx7KUvvkvTUqpcy/hC72rujLor38/BVxK+MtLRPG93sFfYHN1o4FWDF+GYv > >> t35hX6+ARANeA9c9Pqy9Rywa+y2kFRLat6rSIC5wcJO7qF9YCwUlyMiCE4seBNJC > >> WjFmh8eVuMVryLDBZtbHpOs0N9XmM7QvI4ydM7EmWQQ9TWbs/I1TmPqPEjacGGs= > >> =n6oJ > >> -----END PGP SIGNATURE----- > >> _______________________________________________ > >> keycloak-user mailing list > >> keycloak-user at lists.jboss.org > >> https://lists.jboss.org/mailman/listinfo/keycloak-user > >> > > > > _______________________________________________ > > keycloak-user mailing list > > keycloak-user at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/keycloak-user > > > > -- > Bill Burke > JBoss, a division of Red Hat > http://bill.burkecentral.com > _______________________________________________ > keycloak-user mailing list > keycloak-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user From mposolda at redhat.com Mon Nov 24 14:22:10 2014 From: mposolda at redhat.com (Marek Posolda) Date: Mon, 24 Nov 2014 20:22:10 +0100 Subject: [keycloak-user] Obtaining the user name from the security context In-Reply-To: <33553618.13189506.1416828179585.JavaMail.zimbra@redhat.com> References: <1869846893.11462243.1416414017373.JavaMail.zimbra@redhat.com> <546CD999.9000808@redhat.com> <1510952577.11835794.1416479122326.JavaMail.zimbra@redhat.com> <546FB533.3020601@redhat.com> <33553618.13189506.1416828179585.JavaMail.zimbra@redhat.com> Message-ID: <54738562.2050409@redhat.com> Not sure, probably this or next week. Marek On 24.11.2014 12:22, Gary Brown wrote: > Thanks that works fine now. > > Any idea when beta2 will be released? > > Regards > Gary > > ----- Original Message ----- >> Hi, >> >> I've just tried it and figured that it doesn't work due to bug >> https://issues.jboss.org/browse/KEYCLOAK-857 . It's fixed in latest >> keycloak master and will be available in next release 1.1.0.Beta2 . The >> easiest workaround is to configure absolute URI for auth-server-url . So >> instead of "/auth", you can use "http://localhost:8080/auth" or >> something like that according to your env. >> >> Hope it helps, >> Marek >> >> On 20.11.2014 11:25, Gary Brown wrote: >>> Hi >>> >>> Thanks for the information. >>> >>> However, I've tried it without success - I also tried using this attribute >>> in the keycloak unconfigured-demo and preconfigured-demo examples for >>> customer-app/product-app, and didn't have an effect on them either. >>> >>> Just wondering whether the text in the doc "OpenID Connection ID Token >>> attribute to populate the UserPrincipal name with" implies that this >>> attribute only works for OpenID? >>> >>> With the unconfigured version, it wasn't clear whether this attribute would >>> be set under the realm or secure-deployment elements, so initially I tried >>> just under the realm but then eventually defined the attribute under both. >>> Attached the wildfly standalone-full.xml. >>> >>> Regards >>> Gary >>> >>> ----- Original Message ----- >>>> If you have 1.1.0.Beta1, you can try to use "principal-attribute" with >>>> value "|preferred_username" in the configuration of your adapter. More >>>> info in |http://docs.jboss.org/keycloak/docs/1.1.0.Beta1/userguide >>>> /html/ch07.html#adapter-config . >>>> >>>> It should also work to cast getUserPrincipal() to KeycloakPrincipal and >>>> use something like: >>>> >>>> ((KeycloakPrincipal)getUserPrincipal()).getKeycloakSecurityContext().getToken().getPreferredUsername() >>>> >>>> this should also work on older versions, but your code may need to have >>>> dependencies on keycloak. >>>> >>>> Marek >>>> >>>> On 19.11.2014 17:20, Gary Brown wrote: >>>>> Hi >>>>> >>>>> When I access getUserPrincipal().getName() in >>>>> javax.ws.rs.core.SecurityContext I get the UID. >>>>> >>>>> Is it possible to obtain the actual user name? >>>>> >>>>> Regards >>>>> Gary >>>>> _______________________________________________ >>>>> keycloak-user mailing list >>>>> keycloak-user at lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/keycloak-user >> From alexander.chriztopher at gmail.com Tue Nov 25 05:48:54 2014 From: alexander.chriztopher at gmail.com (Alexander Chriztopher) Date: Tue, 25 Nov 2014 11:48:54 +0100 Subject: [keycloak-user] Can not access applications on realm master or any other realm Message-ID: Hi, I just downloaded the latest appliance version of Keycloak and started using it. When i go to the master realm or any other realm i have create i can not acess any application. When i click on the application link nothing happens. I have also created new applications but can't manage to access them. Is there a workaround/solution to this ? Regards. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20141125/1f600080/attachment.html From stian at redhat.com Tue Nov 25 07:07:34 2014 From: stian at redhat.com (Stian Thorgersen) Date: Tue, 25 Nov 2014 07:07:34 -0500 (EST) Subject: [keycloak-user] Can not access applications on realm master or any other realm In-Reply-To: References: Message-ID: <2029959236.4826004.1416917254008.JavaMail.zimbra@redhat.com> Hi, This may be caused by your cache holding old versions of pages, please try clearing your cache and try again. If that doesn't work please write the exact steps to reproduce the issue as this is not a known problem. ----- Original Message ----- > From: "Alexander Chriztopher" > To: keycloak-user at lists.jboss.org > Sent: Tuesday, 25 November, 2014 11:48:54 AM > Subject: [keycloak-user] Can not access applications on realm master or any other realm > > Hi, > > I just downloaded the latest appliance version of Keycloak and started using > it. > > When i go to the master realm or any other realm i have create i can not > acess any application. When i click on the application link nothing happens. > > I have also created new applications but can't manage to access them. > > Is there a workaround/solution to this ? > > Regards. > > _______________________________________________ > keycloak-user mailing list > keycloak-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user From alexander.chriztopher at gmail.com Tue Nov 25 08:22:59 2014 From: alexander.chriztopher at gmail.com (Alexander Chriztopher) Date: Tue, 25 Nov 2014 14:22:59 +0100 Subject: [keycloak-user] Can not access applications on realm master or any other realm In-Reply-To: <2029959236.4826004.1416917254008.JavaMail.zimbra@redhat.com> References: <2029959236.4826004.1416917254008.JavaMail.zimbra@redhat.com> Message-ID: that was the thing. thank you Stian. On Tue, Nov 25, 2014 at 1:07 PM, Stian Thorgersen wrote: > Hi, > > This may be caused by your cache holding old versions of pages, please try > clearing your cache and try again. > > If that doesn't work please write the exact steps to reproduce the issue > as this is not a known problem. > > ----- Original Message ----- > > From: "Alexander Chriztopher" > > To: keycloak-user at lists.jboss.org > > Sent: Tuesday, 25 November, 2014 11:48:54 AM > > Subject: [keycloak-user] Can not access applications on realm master or > any other realm > > > > Hi, > > > > I just downloaded the latest appliance version of Keycloak and started > using > > it. > > > > When i go to the master realm or any other realm i have create i can not > > acess any application. When i click on the application link nothing > happens. > > > > I have also created new applications but can't manage to access them. > > > > Is there a workaround/solution to this ? > > > > Regards. > > > > _______________________________________________ > > 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-user/attachments/20141125/fc11989c/attachment.html From alexander.chriztopher at gmail.com Tue Nov 25 08:30:01 2014 From: alexander.chriztopher at gmail.com (Alexander Chriztopher) Date: Tue, 25 Nov 2014 14:30:01 +0100 Subject: [keycloak-user] Unable to find a MessageBodyReader of content-type application/json and type AccessTokenResponse Message-ID: Hi All, Am trying to execute this call : Keycloak keycloak = Keycloak.getInstance("http://localhost:9080/auth", "master", "admin", "admin", "security-admin-console"); But am getting the following error : Exception in thread "main" javax.ws.rs.client.ResponseProcessingException: javax.ws.rs.ProcessingException: Unable to find a MessageBodyReader of content-type application/json and type class org.keycloak.representations.AccessTokenResponse at org.jboss.resteasy.client.jaxrs.internal.ClientInvocation.extractResult(ClientInvocation.java:140) at org.jboss.resteasy.client.jaxrs.internal.proxy.extractors.BodyEntityExtractor.extractEntity(BodyEntityExtractor.java:58) at org.jboss.resteasy.client.jaxrs.internal.proxy.ClientInvoker.invoke(ClientInvoker.java:104) at org.jboss.resteasy.client.jaxrs.internal.proxy.ClientProxy.invoke(ClientProxy.java:62) at com.sun.proxy.$Proxy19.grantToken(Unknown Source) at org.keycloak.admin.client.token.TokenManager.grantToken(TokenManager.java:56) at org.keycloak.admin.client.token.TokenManager.getAccessToken(TokenManager.java:33) at org.keycloak.admin.client.token.TokenManager.getAccessTokenString(TokenManager.java:28) at org.keycloak.admin.client.Keycloak.(Keycloak.java:28) at org.keycloak.admin.client.Keycloak.getInstance(Keycloak.java:32) at fr.klee.test.RestTest.main(RestTest.java:22) Caused by: javax.ws.rs.ProcessingException: Unable to find a MessageBodyReader of content-type application/json and type class org.keycloak.representations.AccessTokenResponse at org.jboss.resteasy.core.interception.ClientReaderInterceptorContext.throwReaderNotFound(ClientReaderInterceptorContext.java:39) at org.jboss.resteasy.core.interception.AbstractReaderInterceptorContext.getReader(AbstractReaderInterceptorContext.java:73) at org.jboss.resteasy.core.interception.AbstractReaderInterceptorContext.proceed(AbstractReaderInterceptorContext.java:50) at org.jboss.resteasy.plugins.interceptors.encoding.GZIPDecodingInterceptor.aroundReadFrom(GZIPDecodingInterceptor.java:59) at org.jboss.resteasy.core.interception.AbstractReaderInterceptorContext.proceed(AbstractReaderInterceptorContext.java:53) at org.jboss.resteasy.client.jaxrs.internal.ClientResponse.readFrom(ClientResponse.java:248) at org.jboss.resteasy.client.jaxrs.internal.ClientResponse.readEntity(ClientResponse.java:181) at org.jboss.resteasy.specimpl.BuiltResponse.readEntity(BuiltResponse.java:211) at org.jboss.resteasy.client.jaxrs.internal.ClientInvocation.extractResult(ClientInvocation.java:104) ... 10 more What can cause this error ? Am running this in the admin-client example (the master one) application by the way in order to have the right dependencies etc. Thanks for any help. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20141125/93dc0a8a/attachment-0001.html From christinalau28 at icloud.com Tue Nov 25 08:58:54 2014 From: christinalau28 at icloud.com (Christina Lau) Date: Tue, 25 Nov 2014 08:58:54 -0500 Subject: [keycloak-user] Which action hook should I use to run Keycloak import on Openshift? Message-ID: <6541CA7C-F42B-4F58-ADDE-C07D4C11B71D@icloud.com> Hi, I am trying to import realm into my Openshift Keycloak. I can import successfully in my build action hook, but something is quite strange. Because I am running ./standalone.sh to start the server, the openshift ssh window is sitting in a strange state where it cannot carry on to finish the rest of its life cycle. $OPENSHIFT_HOMEDIR/wildfly/bin/standalone.sh -Dkeycloak.migration.action=import -Dkeycloak.migration.provider=singleFile -Dkeycloak.migration.file=$OPENSHIFT_HOMEDIR/app-root/repo/src/dsgapi.json -Dkeycloak.migration.strategy=OVERWRITE_EXISTING I think I am doing something wrong. Can you tell me how I should do this? I like to create a Keycloak on Openshift using the Keycloak cartridge and then automatically populate its realm. Should I kill the startup in the action hook? It seems a little strange. Thx. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20141125/00d62105/attachment.html From stian at redhat.com Tue Nov 25 09:40:05 2014 From: stian at redhat.com (Stian Thorgersen) Date: Tue, 25 Nov 2014 09:40:05 -0500 (EST) Subject: [keycloak-user] Which action hook should I use to run Keycloak import on Openshift? In-Reply-To: <6541CA7C-F42B-4F58-ADDE-C07D4C11B71D@icloud.com> References: <6541CA7C-F42B-4F58-ADDE-C07D4C11B71D@icloud.com> Message-ID: <766684328.4933025.1416926405451.JavaMail.zimbra@redhat.com> It's not a particular elegant way to import the realm, but it's the only way I can think of unless we improve things in KC. Your problem is that you're starting the server in the foreground, which causes the "command" to never complete. If you look at for example bin/control the start() function executes standalone.sh in the background, then it waits until the http port is ready. ----- Original Message ----- > From: "Christina Lau" > To: keycloak-user at lists.jboss.org > Sent: Tuesday, 25 November, 2014 2:58:54 PM > Subject: [keycloak-user] Which action hook should I use to run Keycloak import on Openshift? > > Hi, I am trying to import realm into my Openshift Keycloak. I can import > successfully in my build action hook, but something is quite strange. > Because I am running ./standalone.sh to start the server, the openshift ssh > window is sitting in a strange state where it cannot carry on to finish the > rest of its life cycle. > > $OPENSHIFT_HOMEDIR/wildfly/bin/standalone.sh > -Dkeycloak.migration.action=import -Dkeycloak.migration.provider=singleFile > -Dkeycloak.migration.file=$OPENSHIFT_HOMEDIR/app-root/repo/src/dsgapi.json > -Dkeycloak.migration.strategy=OVERWRITE_EXISTING > > I think I am doing something wrong. Can you tell me how I should do this? I > like to create a Keycloak on Openshift using the Keycloak cartridge and then > automatically populate its realm. Should I kill the startup in the action > hook? It seems a little strange. > > Thx. > > _______________________________________________ > keycloak-user mailing list > keycloak-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user From stian at redhat.com Tue Nov 25 09:42:52 2014 From: stian at redhat.com (Stian Thorgersen) Date: Tue, 25 Nov 2014 09:42:52 -0500 (EST) Subject: [keycloak-user] Unable to find a MessageBodyReader of content-type application/json and type AccessTokenResponse In-Reply-To: References: Message-ID: <894528541.4936457.1416926572933.JavaMail.zimbra@redhat.com> Looks like you haven't included the RestEasy Jackson Provider. Try adding a dependency on org.jboss.resteasy:resteasy-jackson-provider ----- Original Message ----- > From: "Alexander Chriztopher" > To: keycloak-user at lists.jboss.org > Sent: Tuesday, 25 November, 2014 2:30:01 PM > Subject: [keycloak-user] Unable to find a MessageBodyReader of content-type application/json and type > AccessTokenResponse > > Hi All, > > Am trying to execute this call : > > Keycloak keycloak = Keycloak.getInstance(" http://localhost:9080/auth ", > "master", "admin", "admin", "security-admin-console"); > > But am getting the following error : > > Exception in thread "main" javax.ws.rs.client.ResponseProcessingException: > javax.ws.rs.ProcessingException: Unable to find a MessageBodyReader of > content-type application/json and type class > org.keycloak.representations.AccessTokenResponse > at > org.jboss.resteasy.client.jaxrs.internal.ClientInvocation.extractResult(ClientInvocation.java:140) > at > org.jboss.resteasy.client.jaxrs.internal.proxy.extractors.BodyEntityExtractor.extractEntity(BodyEntityExtractor.java:58) > at > org.jboss.resteasy.client.jaxrs.internal.proxy.ClientInvoker.invoke(ClientInvoker.java:104) > at > org.jboss.resteasy.client.jaxrs.internal.proxy.ClientProxy.invoke(ClientProxy.java:62) > at com.sun.proxy.$Proxy19.grantToken(Unknown Source) > at > org.keycloak.admin.client.token.TokenManager.grantToken(TokenManager.java:56) > at > org.keycloak.admin.client.token.TokenManager.getAccessToken(TokenManager.java:33) > at > org.keycloak.admin.client.token.TokenManager.getAccessTokenString(TokenManager.java:28) > at org.keycloak.admin.client.Keycloak.(Keycloak.java:28) > at org.keycloak.admin.client.Keycloak.getInstance(Keycloak.java:32) > at fr.klee.test.RestTest.main(RestTest.java:22) > Caused by: javax.ws.rs.ProcessingException: Unable to find a > MessageBodyReader of content-type application/json and type class > org.keycloak.representations.AccessTokenResponse > at > org.jboss.resteasy.core.interception.ClientReaderInterceptorContext.throwReaderNotFound(ClientReaderInterceptorContext.java:39) > at > org.jboss.resteasy.core.interception.AbstractReaderInterceptorContext.getReader(AbstractReaderInterceptorContext.java:73) > at > org.jboss.resteasy.core.interception.AbstractReaderInterceptorContext.proceed(AbstractReaderInterceptorContext.java:50) > at > org.jboss.resteasy.plugins.interceptors.encoding.GZIPDecodingInterceptor.aroundReadFrom(GZIPDecodingInterceptor.java:59) > at > org.jboss.resteasy.core.interception.AbstractReaderInterceptorContext.proceed(AbstractReaderInterceptorContext.java:53) > at > org.jboss.resteasy.client.jaxrs.internal.ClientResponse.readFrom(ClientResponse.java:248) > at > org.jboss.resteasy.client.jaxrs.internal.ClientResponse.readEntity(ClientResponse.java:181) > at > org.jboss.resteasy.specimpl.BuiltResponse.readEntity(BuiltResponse.java:211) > at > org.jboss.resteasy.client.jaxrs.internal.ClientInvocation.extractResult(ClientInvocation.java:104) > ... 10 more > > What can cause this error ? > > Am running this in the admin-client example (the master one) application by > the way in order to have the right dependencies etc. > > Thanks for any help. > > _______________________________________________ > keycloak-user mailing list > keycloak-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user From alexander.chriztopher at gmail.com Tue Nov 25 10:02:27 2014 From: alexander.chriztopher at gmail.com (Alexander Chriztopher) Date: Tue, 25 Nov 2014 16:02:27 +0100 Subject: [keycloak-user] Unable to find a MessageBodyReader of content-type application/json and type AccessTokenResponse In-Reply-To: <894528541.4936457.1416926572933.JavaMail.zimbra@redhat.com> References: <894528541.4936457.1416926572933.JavaMail.zimbra@redhat.com> Message-ID: great that was it ! thanks mate. On Tue, Nov 25, 2014 at 3:42 PM, Stian Thorgersen wrote: > Looks like you haven't included the RestEasy Jackson Provider. Try adding > a dependency on org.jboss.resteasy:resteasy-jackson-provider > > ----- Original Message ----- > > From: "Alexander Chriztopher" > > To: keycloak-user at lists.jboss.org > > Sent: Tuesday, 25 November, 2014 2:30:01 PM > > Subject: [keycloak-user] Unable to find a MessageBodyReader of > content-type application/json and type > > AccessTokenResponse > > > > Hi All, > > > > Am trying to execute this call : > > > > Keycloak keycloak = Keycloak.getInstance(" http://localhost:9080/auth ", > > "master", "admin", "admin", "security-admin-console"); > > > > But am getting the following error : > > > > Exception in thread "main" > javax.ws.rs.client.ResponseProcessingException: > > javax.ws.rs.ProcessingException: Unable to find a MessageBodyReader of > > content-type application/json and type class > > org.keycloak.representations.AccessTokenResponse > > at > > > org.jboss.resteasy.client.jaxrs.internal.ClientInvocation.extractResult(ClientInvocation.java:140) > > at > > > org.jboss.resteasy.client.jaxrs.internal.proxy.extractors.BodyEntityExtractor.extractEntity(BodyEntityExtractor.java:58) > > at > > > org.jboss.resteasy.client.jaxrs.internal.proxy.ClientInvoker.invoke(ClientInvoker.java:104) > > at > > > org.jboss.resteasy.client.jaxrs.internal.proxy.ClientProxy.invoke(ClientProxy.java:62) > > at com.sun.proxy.$Proxy19.grantToken(Unknown Source) > > at > > > org.keycloak.admin.client.token.TokenManager.grantToken(TokenManager.java:56) > > at > > > org.keycloak.admin.client.token.TokenManager.getAccessToken(TokenManager.java:33) > > at > > > org.keycloak.admin.client.token.TokenManager.getAccessTokenString(TokenManager.java:28) > > at org.keycloak.admin.client.Keycloak.(Keycloak.java:28) > > at org.keycloak.admin.client.Keycloak.getInstance(Keycloak.java:32) > > at fr.klee.test.RestTest.main(RestTest.java:22) > > Caused by: javax.ws.rs.ProcessingException: Unable to find a > > MessageBodyReader of content-type application/json and type class > > org.keycloak.representations.AccessTokenResponse > > at > > > org.jboss.resteasy.core.interception.ClientReaderInterceptorContext.throwReaderNotFound(ClientReaderInterceptorContext.java:39) > > at > > > org.jboss.resteasy.core.interception.AbstractReaderInterceptorContext.getReader(AbstractReaderInterceptorContext.java:73) > > at > > > org.jboss.resteasy.core.interception.AbstractReaderInterceptorContext.proceed(AbstractReaderInterceptorContext.java:50) > > at > > > org.jboss.resteasy.plugins.interceptors.encoding.GZIPDecodingInterceptor.aroundReadFrom(GZIPDecodingInterceptor.java:59) > > at > > > org.jboss.resteasy.core.interception.AbstractReaderInterceptorContext.proceed(AbstractReaderInterceptorContext.java:53) > > at > > > org.jboss.resteasy.client.jaxrs.internal.ClientResponse.readFrom(ClientResponse.java:248) > > at > > > org.jboss.resteasy.client.jaxrs.internal.ClientResponse.readEntity(ClientResponse.java:181) > > at > > > org.jboss.resteasy.specimpl.BuiltResponse.readEntity(BuiltResponse.java:211) > > at > > > org.jboss.resteasy.client.jaxrs.internal.ClientInvocation.extractResult(ClientInvocation.java:104) > > ... 10 more > > > > What can cause this error ? > > > > Am running this in the admin-client example (the master one) application > by > > the way in order to have the right dependencies etc. > > > > Thanks for any help. > > > > _______________________________________________ > > 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-user/attachments/20141125/8def2277/attachment.html From alexander.chriztopher at gmail.com Tue Nov 25 12:32:30 2014 From: alexander.chriztopher at gmail.com (Alexander Chriztopher) Date: Tue, 25 Nov 2014 18:32:30 +0100 Subject: [keycloak-user] Brut force attack questions Message-ID: Hi, I have a some question with regards to Brut Force Attack Protection : # 1 / When brut force attack protection is enabled is there a way to know when a user account is locked ? I am thinking about the admin console. # 2 / When a user account is locked is there a way to unlock it from the admin console ? # 3 / What is the difference between wait increment (When failure threshold has been met, how much time should the user be locked out?) and max wait (Max time a user will be locked out.). Thanks for your help. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20141125/c5492c14/attachment.html From bburke at redhat.com Tue Nov 25 14:05:45 2014 From: bburke at redhat.com (Bill Burke) Date: Tue, 25 Nov 2014 14:05:45 -0500 Subject: [keycloak-user] Brut force attack questions In-Reply-To: References: Message-ID: <5474D309.2090609@redhat.com> On 11/25/2014 12:32 PM, Alexander Chriztopher wrote: > Hi, > > I have a some question with regards to Brut Force Attack Protection : > > # 1 / When brut force attack protection is enabled is there a way to > know when a user account is locked ? I am thinking about the admin console. > > # 2 / When a user account is locked is there a way to unlock it from the > admin console ? > Unfortunately no for the above. I'll log a jira. > # 3 / What is the difference between wait increment (When failure > threshold has been met, how much time should the user be locked out?) > and max wait (Max time a user will be locked out.). > correct on both. -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From c.rued at xsb.com Tue Nov 25 17:45:32 2014 From: c.rued at xsb.com (Christopher Rued) Date: Tue, 25 Nov 2014 17:45:32 -0500 Subject: [keycloak-user] Accessing Google+ APIs Message-ID: <7100B93E-E0EB-44E2-A60D-60653223A2E8@xsb.com> Hi all, I?m just getting started with Keycloak. So far it?s been really easy to work with and seems to have nearly all of the features I need. Recently, I?ve been testing out the ?Social Login? feature with google. It seems to work well for logging in, but now I?m looking to try to do a bit more. One question I have is how to access Google APIs to get profile information. This is the call I?m trying to use: https://www.googleapis.com/plus/v1/people/{userId}?key={YOUR_API_KEY} What I?ve found is that the Google+ API userId is a large decimal number, but I cannot find this number anywhere in Keycloak?s database. Any way to do this? Thanks, -Chris -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20141125/4dc5d7ca/attachment-0001.html From c.rued at xsb.com Tue Nov 25 17:48:53 2014 From: c.rued at xsb.com (Christopher Rued) Date: Tue, 25 Nov 2014 17:48:53 -0500 Subject: [keycloak-user] Client Certificate Authentication Message-ID: <35B0B0A4-BB58-42E7-82A5-B211CC4BB3B6@xsb.com> Hi all, I see in the login configuration section of the realm admin an option for ?Cert? authentication (which I assume this means client certificate authentication?). I?ve enabled it, accessed it over SSL, but haven?t been able to get a prompt for a client certificate. Is this supported yet? Is there a tutorial? Am I missing an option in the configuration of the SSL listener? Any help is appreciated. Thanks, -Chris From bburke at redhat.com Tue Nov 25 18:14:06 2014 From: bburke at redhat.com (Bill Burke) Date: Tue, 25 Nov 2014 18:14:06 -0500 Subject: [keycloak-user] Client Certificate Authentication In-Reply-To: <35B0B0A4-BB58-42E7-82A5-B211CC4BB3B6@xsb.com> References: <35B0B0A4-BB58-42E7-82A5-B211CC4BB3B6@xsb.com> Message-ID: <54750D3E.6040000@redhat.com> not suppoted yet, sorry. On 11/25/2014 5:48 PM, Christopher Rued wrote: > Hi all, > > I see in the login configuration section of the realm admin an option for ?Cert? authentication (which I assume this means client certificate authentication?). I?ve enabled it, accessed it over SSL, but haven?t been able to get a prompt for a client certificate. Is this supported yet? Is there a tutorial? Am I missing an option in the configuration of the SSL listener? > > Any help is appreciated. > > Thanks, > -Chris > > > _______________________________________________ > keycloak-user mailing list > keycloak-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user > -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From alexander.chriztopher at gmail.com Wed Nov 26 03:45:42 2014 From: alexander.chriztopher at gmail.com (Alexander Chriztopher) Date: Wed, 26 Nov 2014 09:45:42 +0100 Subject: [keycloak-user] Brut force attack questions In-Reply-To: <42A05865-7DF6-4F44-BD0B-537F028FD5A6@gmail.com> References: <5474D309.2090609@redhat.com> <03E07955-9132-4478-91CD-B93018FCCC6E@gmail.com> <5474E8E7.8030300@redhat.com> <42A05865-7DF6-4F44-BD0B-537F028FD5A6@gmail.com> Message-ID: Am to find a workaround in order to be able to unlock a user account. So far i have tried to disable then enable the user account but this does not do the trick apparently. I have also tried to tweek the database but it looks like the lock information is not stored in the db even though there is the table : USERNAME_LOGIN_FAILURE. Is it normal that this table stays empty even on login failures ? Do you think of any other good workaround ? On Tue, Nov 25, 2014 at 11:03 PM, Alexander Chriztopher < alexander.chriztopher at gmail.com> wrote: > Nice ! Again, thank you. > > > > > On 25 Nov 2014, at 21:39, Bill Burke wrote: > > > > > > > >> On 11/25/2014 3:27 PM, Alexander Chriztopher wrote: > >> Hi Bill and thanks. > >> > >> Do you think we will be able to have this within a short period of time > (4-6 weeks) or is it going to be planned for the long run ? > > > > Not sure on the priority of this. We have face to face meetings in a > couple of weeks to discuss priority, then of course, its christmas vacation. > > > >> When is the value of max wait used as there is already a wait increment > out there ? > > > > Correct. It will increase the wait after each failure until the max is > hit. > > > >> > >> > >>> On 25 Nov 2014, at 20:05, Bill Burke wrote: > >>> > >>> > >>> > >>>> On 11/25/2014 12:32 PM, Alexander Chriztopher wrote: > >>>> Hi, > >>>> > >>>> I have a some question with regards to Brut Force Attack Protection : > >>>> > >>>> # 1 / When brut force attack protection is enabled is there a way to > >>>> know when a user account is locked ? I am thinking about the admin > console. > >>>> > >>>> # 2 / When a user account is locked is there a way to unlock it from > the > >>>> admin console ? > >>> > >>> Unfortunately no for the above. I'll log a jira. > >>> > >>>> # 3 / What is the difference between wait increment (When failure > >>>> threshold has been met, how much time should the user be locked out?) > >>>> and max wait (Max time a user will be locked out.). > >>> > >>> correct on both. > >>> > >>> > >>> -- > >>> Bill Burke > >>> JBoss, a division of Red Hat > >>> http://bill.burkecentral.com > >>> _______________________________________________ > >>> keycloak-user mailing list > >>> keycloak-user at lists.jboss.org > >>> https://lists.jboss.org/mailman/listinfo/keycloak-user > > > > -- > > Bill Burke > > JBoss, a division of Red Hat > > http://bill.burkecentral.com > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20141126/6d9cb387/attachment.html From stian at redhat.com Wed Nov 26 04:39:59 2014 From: stian at redhat.com (Stian Thorgersen) Date: Wed, 26 Nov 2014 04:39:59 -0500 (EST) Subject: [keycloak-user] Brut force attack questions In-Reply-To: References: <5474D309.2090609@redhat.com> <03E07955-9132-4478-91CD-B93018FCCC6E@gmail.com> <5474E8E7.8030300@redhat.com> <42A05865-7DF6-4F44-BD0B-537F028FD5A6@gmail.com> Message-ID: <1027232603.5396740.1416994799655.JavaMail.zimbra@redhat.com> By default user sessions (and login failures) are stored in-memory not in the database. Unless you specify JPA for the userSession provider those tables will stay empty. You could either do what you're trying to do, which should work if you use the jpa userSession provider. The other if you're worried about the performance of storing user sessions in the db is to use the Infinispan provider, then you can manually delete login failures from the userSession cache from another application. We should add a mechanism to both view and remove login-failure entries to the admin console though. ----- Original Message ----- > From: "Alexander Chriztopher" > To: "Bill Burke" , keycloak-user at lists.jboss.org > Sent: Wednesday, 26 November, 2014 9:45:42 AM > Subject: Re: [keycloak-user] Brut force attack questions > > Am to find a workaround in order to be able to unlock a user account. So far > i have tried to disable then enable the user account but this does not do > the trick apparently. > > I have also tried to tweek the database but it looks like the lock > information is not stored in the db even though there is the table : > USERNAME_LOGIN_FAILURE. Is it normal that this table stays empty even on > login failures ? > > Do you think of any other good workaround ? > > > On Tue, Nov 25, 2014 at 11:03 PM, Alexander Chriztopher < > alexander.chriztopher at gmail.com > wrote: > > > Nice ! Again, thank you. > > > > > On 25 Nov 2014, at 21:39, Bill Burke < bburke at redhat.com > wrote: > > > > > > > >> On 11/25/2014 3:27 PM, Alexander Chriztopher wrote: > >> Hi Bill and thanks. > >> > >> Do you think we will be able to have this within a short period of time > >> (4-6 weeks) or is it going to be planned for the long run ? > > > > Not sure on the priority of this. We have face to face meetings in a couple > > of weeks to discuss priority, then of course, its christmas vacation. > > > >> When is the value of max wait used as there is already a wait increment > >> out there ? > > > > Correct. It will increase the wait after each failure until the max is hit. > > > >> > >> > >>> On 25 Nov 2014, at 20:05, Bill Burke < bburke at redhat.com > wrote: > >>> > >>> > >>> > >>>> On 11/25/2014 12:32 PM, Alexander Chriztopher wrote: > >>>> Hi, > >>>> > >>>> I have a some question with regards to Brut Force Attack Protection : > >>>> > >>>> # 1 / When brut force attack protection is enabled is there a way to > >>>> know when a user account is locked ? I am thinking about the admin > >>>> console. > >>>> > >>>> # 2 / When a user account is locked is there a way to unlock it from the > >>>> admin console ? > >>> > >>> Unfortunately no for the above. I'll log a jira. > >>> > >>>> # 3 / What is the difference between wait increment (When failure > >>>> threshold has been met, how much time should the user be locked out?) > >>>> and max wait (Max time a user will be locked out.). > >>> > >>> correct on both. > >>> > >>> > >>> -- > >>> Bill Burke > >>> JBoss, a division of Red Hat > >>> http://bill.burkecentral.com > >>> _______________________________________________ > >>> keycloak-user mailing list > >>> keycloak-user at lists.jboss.org > >>> https://lists.jboss.org/mailman/listinfo/keycloak-user > > > > -- > > Bill Burke > > JBoss, a division of Red Hat > > http://bill.burkecentral.com > > > _______________________________________________ > keycloak-user mailing list > keycloak-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user From alexander.chriztopher at gmail.com Wed Nov 26 04:51:11 2014 From: alexander.chriztopher at gmail.com (Alexander Chriztopher) Date: Wed, 26 Nov 2014 10:51:11 +0100 Subject: [keycloak-user] Brut force attack questions In-Reply-To: <1027232603.5396740.1416994799655.JavaMail.zimbra@redhat.com> References: <5474D309.2090609@redhat.com> <03E07955-9132-4478-91CD-B93018FCCC6E@gmail.com> <5474E8E7.8030300@redhat.com> <42A05865-7DF6-4F44-BD0B-537F028FD5A6@gmail.com> <1027232603.5396740.1416994799655.JavaMail.zimbra@redhat.com> Message-ID: nice ! is there a way to play with this via rest -regardless to wether am jpa, infinispan or in-memory ? On Wed, Nov 26, 2014 at 10:39 AM, Stian Thorgersen wrote: > By default user sessions (and login failures) are stored in-memory not in > the database. Unless you specify JPA for the userSession provider those > tables will stay empty. > > You could either do what you're trying to do, which should work if you use > the jpa userSession provider. The other if you're worried about the > performance of storing user sessions in the db is to use the Infinispan > provider, then you can manually delete login failures from the userSession > cache from another application. > > We should add a mechanism to both view and remove login-failure entries to > the admin console though. > > ----- Original Message ----- > > From: "Alexander Chriztopher" > > To: "Bill Burke" , keycloak-user at lists.jboss.org > > Sent: Wednesday, 26 November, 2014 9:45:42 AM > > Subject: Re: [keycloak-user] Brut force attack questions > > > > Am to find a workaround in order to be able to unlock a user account. So > far > > i have tried to disable then enable the user account but this does not do > > the trick apparently. > > > > I have also tried to tweek the database but it looks like the lock > > information is not stored in the db even though there is the table : > > USERNAME_LOGIN_FAILURE. Is it normal that this table stays empty even on > > login failures ? > > > > Do you think of any other good workaround ? > > > > > > On Tue, Nov 25, 2014 at 11:03 PM, Alexander Chriztopher < > > alexander.chriztopher at gmail.com > wrote: > > > > > > Nice ! Again, thank you. > > > > > > > > > On 25 Nov 2014, at 21:39, Bill Burke < bburke at redhat.com > wrote: > > > > > > > > > > > >> On 11/25/2014 3:27 PM, Alexander Chriztopher wrote: > > >> Hi Bill and thanks. > > >> > > >> Do you think we will be able to have this within a short period of > time > > >> (4-6 weeks) or is it going to be planned for the long run ? > > > > > > Not sure on the priority of this. We have face to face meetings in a > couple > > > of weeks to discuss priority, then of course, its christmas vacation. > > > > > >> When is the value of max wait used as there is already a wait > increment > > >> out there ? > > > > > > Correct. It will increase the wait after each failure until the max is > hit. > > > > > >> > > >> > > >>> On 25 Nov 2014, at 20:05, Bill Burke < bburke at redhat.com > wrote: > > >>> > > >>> > > >>> > > >>>> On 11/25/2014 12:32 PM, Alexander Chriztopher wrote: > > >>>> Hi, > > >>>> > > >>>> I have a some question with regards to Brut Force Attack Protection > : > > >>>> > > >>>> # 1 / When brut force attack protection is enabled is there a way to > > >>>> know when a user account is locked ? I am thinking about the admin > > >>>> console. > > >>>> > > >>>> # 2 / When a user account is locked is there a way to unlock it > from the > > >>>> admin console ? > > >>> > > >>> Unfortunately no for the above. I'll log a jira. > > >>> > > >>>> # 3 / What is the difference between wait increment (When failure > > >>>> threshold has been met, how much time should the user be locked > out?) > > >>>> and max wait (Max time a user will be locked out.). > > >>> > > >>> correct on both. > > >>> > > >>> > > >>> -- > > >>> Bill Burke > > >>> JBoss, a division of Red Hat > > >>> http://bill.burkecentral.com > > >>> _______________________________________________ > > >>> keycloak-user mailing list > > >>> keycloak-user at lists.jboss.org > > >>> https://lists.jboss.org/mailman/listinfo/keycloak-user > > > > > > -- > > > Bill Burke > > > JBoss, a division of Red Hat > > > http://bill.burkecentral.com > > > > > > _______________________________________________ > > 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-user/attachments/20141126/69a1e69a/attachment-0001.html From stian at redhat.com Wed Nov 26 05:02:42 2014 From: stian at redhat.com (Stian Thorgersen) Date: Wed, 26 Nov 2014 05:02:42 -0500 (EST) Subject: [keycloak-user] Brut force attack questions In-Reply-To: References: <5474D309.2090609@redhat.com> <03E07955-9132-4478-91CD-B93018FCCC6E@gmail.com> <5474E8E7.8030300@redhat.com> <42A05865-7DF6-4F44-BD0B-537F028FD5A6@gmail.com> <1027232603.5396740.1416994799655.JavaMail.zimbra@redhat.com> Message-ID: <1565568349.5407824.1416996162495.JavaMail.zimbra@redhat.com> ----- Original Message ----- > From: "Alexander Chriztopher" > To: "Stian Thorgersen" > Cc: "Bill Burke" , keycloak-user at lists.jboss.org > Sent: Wednesday, 26 November, 2014 10:51:11 AM > Subject: Re: [keycloak-user] Brut force attack questions > > nice ! > > is there a way to play with this via rest -regardless to wether am jpa, > infinispan or in-memory ? Afraid not, that's what we'll need to add. Not sure when we get time though. If you're up for it we would be more than happy to accept a contribution, I can give you some pointers on how to do it. Alternatively, you can create your own app that uses JAX-RS and either JPA or the Infinispan subsystem to remove login-failure entries. > > On Wed, Nov 26, 2014 at 10:39 AM, Stian Thorgersen wrote: > > > By default user sessions (and login failures) are stored in-memory not in > > the database. Unless you specify JPA for the userSession provider those > > tables will stay empty. > > > > You could either do what you're trying to do, which should work if you use > > the jpa userSession provider. The other if you're worried about the > > performance of storing user sessions in the db is to use the Infinispan > > provider, then you can manually delete login failures from the userSession > > cache from another application. > > > > We should add a mechanism to both view and remove login-failure entries to > > the admin console though. > > > > ----- Original Message ----- > > > From: "Alexander Chriztopher" > > > To: "Bill Burke" , keycloak-user at lists.jboss.org > > > Sent: Wednesday, 26 November, 2014 9:45:42 AM > > > Subject: Re: [keycloak-user] Brut force attack questions > > > > > > Am to find a workaround in order to be able to unlock a user account. So > > far > > > i have tried to disable then enable the user account but this does not do > > > the trick apparently. > > > > > > I have also tried to tweek the database but it looks like the lock > > > information is not stored in the db even though there is the table : > > > USERNAME_LOGIN_FAILURE. Is it normal that this table stays empty even on > > > login failures ? > > > > > > Do you think of any other good workaround ? > > > > > > > > > On Tue, Nov 25, 2014 at 11:03 PM, Alexander Chriztopher < > > > alexander.chriztopher at gmail.com > wrote: > > > > > > > > > Nice ! Again, thank you. > > > > > > > > > > > > > On 25 Nov 2014, at 21:39, Bill Burke < bburke at redhat.com > wrote: > > > > > > > > > > > > > > > >> On 11/25/2014 3:27 PM, Alexander Chriztopher wrote: > > > >> Hi Bill and thanks. > > > >> > > > >> Do you think we will be able to have this within a short period of > > time > > > >> (4-6 weeks) or is it going to be planned for the long run ? > > > > > > > > Not sure on the priority of this. We have face to face meetings in a > > couple > > > > of weeks to discuss priority, then of course, its christmas vacation. > > > > > > > >> When is the value of max wait used as there is already a wait > > increment > > > >> out there ? > > > > > > > > Correct. It will increase the wait after each failure until the max is > > hit. > > > > > > > >> > > > >> > > > >>> On 25 Nov 2014, at 20:05, Bill Burke < bburke at redhat.com > wrote: > > > >>> > > > >>> > > > >>> > > > >>>> On 11/25/2014 12:32 PM, Alexander Chriztopher wrote: > > > >>>> Hi, > > > >>>> > > > >>>> I have a some question with regards to Brut Force Attack Protection > > : > > > >>>> > > > >>>> # 1 / When brut force attack protection is enabled is there a way to > > > >>>> know when a user account is locked ? I am thinking about the admin > > > >>>> console. > > > >>>> > > > >>>> # 2 / When a user account is locked is there a way to unlock it > > from the > > > >>>> admin console ? > > > >>> > > > >>> Unfortunately no for the above. I'll log a jira. > > > >>> > > > >>>> # 3 / What is the difference between wait increment (When failure > > > >>>> threshold has been met, how much time should the user be locked > > out?) > > > >>>> and max wait (Max time a user will be locked out.). > > > >>> > > > >>> correct on both. > > > >>> > > > >>> > > > >>> -- > > > >>> Bill Burke > > > >>> JBoss, a division of Red Hat > > > >>> http://bill.burkecentral.com > > > >>> _______________________________________________ > > > >>> keycloak-user mailing list > > > >>> keycloak-user at lists.jboss.org > > > >>> https://lists.jboss.org/mailman/listinfo/keycloak-user > > > > > > > > -- > > > > Bill Burke > > > > JBoss, a division of Red Hat > > > > http://bill.burkecentral.com > > > > > > > > > _______________________________________________ > > > keycloak-user mailing list > > > keycloak-user at lists.jboss.org > > > https://lists.jboss.org/mailman/listinfo/keycloak-user > > > From alexander.chriztopher at gmail.com Wed Nov 26 05:46:21 2014 From: alexander.chriztopher at gmail.com (Alexander Chriztopher) Date: Wed, 26 Nov 2014 11:46:21 +0100 Subject: [keycloak-user] Brut force attack questions In-Reply-To: <1565568349.5407824.1416996162495.JavaMail.zimbra@redhat.com> References: <5474D309.2090609@redhat.com> <03E07955-9132-4478-91CD-B93018FCCC6E@gmail.com> <5474E8E7.8030300@redhat.com> <42A05865-7DF6-4F44-BD0B-537F028FD5A6@gmail.com> <1027232603.5396740.1416994799655.JavaMail.zimbra@redhat.com> <1565568349.5407824.1416996162495.JavaMail.zimbra@redhat.com> Message-ID: i think we will go for Infinispan or jpa for roadmap reasons ! how would we access the infinispan data ? are there any documents on this integration aspect within keycloak ? On Wed, Nov 26, 2014 at 11:02 AM, Stian Thorgersen wrote: > > > ----- Original Message ----- > > From: "Alexander Chriztopher" > > To: "Stian Thorgersen" > > Cc: "Bill Burke" , keycloak-user at lists.jboss.org > > Sent: Wednesday, 26 November, 2014 10:51:11 AM > > Subject: Re: [keycloak-user] Brut force attack questions > > > > nice ! > > > > is there a way to play with this via rest -regardless to wether am jpa, > > infinispan or in-memory ? > > Afraid not, that's what we'll need to add. Not sure when we get time > though. If you're up for it we would be more than happy to accept a > contribution, I can give you some pointers on how to do it. Alternatively, > you can create your own app that uses JAX-RS and either JPA or the > Infinispan subsystem to remove login-failure entries. > > > > > On Wed, Nov 26, 2014 at 10:39 AM, Stian Thorgersen > wrote: > > > > > By default user sessions (and login failures) are stored in-memory not > in > > > the database. Unless you specify JPA for the userSession provider those > > > tables will stay empty. > > > > > > You could either do what you're trying to do, which should work if you > use > > > the jpa userSession provider. The other if you're worried about the > > > performance of storing user sessions in the db is to use the Infinispan > > > provider, then you can manually delete login failures from the > userSession > > > cache from another application. > > > > > > We should add a mechanism to both view and remove login-failure > entries to > > > the admin console though. > > > > > > ----- Original Message ----- > > > > From: "Alexander Chriztopher" > > > > To: "Bill Burke" , keycloak-user at lists.jboss.org > > > > Sent: Wednesday, 26 November, 2014 9:45:42 AM > > > > Subject: Re: [keycloak-user] Brut force attack questions > > > > > > > > Am to find a workaround in order to be able to unlock a user > account. So > > > far > > > > i have tried to disable then enable the user account but this does > not do > > > > the trick apparently. > > > > > > > > I have also tried to tweek the database but it looks like the lock > > > > information is not stored in the db even though there is the table : > > > > USERNAME_LOGIN_FAILURE. Is it normal that this table stays empty > even on > > > > login failures ? > > > > > > > > Do you think of any other good workaround ? > > > > > > > > > > > > On Tue, Nov 25, 2014 at 11:03 PM, Alexander Chriztopher < > > > > alexander.chriztopher at gmail.com > wrote: > > > > > > > > > > > > Nice ! Again, thank you. > > > > > > > > > > > > > > > > > On 25 Nov 2014, at 21:39, Bill Burke < bburke at redhat.com > wrote: > > > > > > > > > > > > > > > > > > > >> On 11/25/2014 3:27 PM, Alexander Chriztopher wrote: > > > > >> Hi Bill and thanks. > > > > >> > > > > >> Do you think we will be able to have this within a short period of > > > time > > > > >> (4-6 weeks) or is it going to be planned for the long run ? > > > > > > > > > > Not sure on the priority of this. We have face to face meetings in > a > > > couple > > > > > of weeks to discuss priority, then of course, its christmas > vacation. > > > > > > > > > >> When is the value of max wait used as there is already a wait > > > increment > > > > >> out there ? > > > > > > > > > > Correct. It will increase the wait after each failure until the > max is > > > hit. > > > > > > > > > >> > > > > >> > > > > >>> On 25 Nov 2014, at 20:05, Bill Burke < bburke at redhat.com > > wrote: > > > > >>> > > > > >>> > > > > >>> > > > > >>>> On 11/25/2014 12:32 PM, Alexander Chriztopher wrote: > > > > >>>> Hi, > > > > >>>> > > > > >>>> I have a some question with regards to Brut Force Attack > Protection > > > : > > > > >>>> > > > > >>>> # 1 / When brut force attack protection is enabled is there a > way to > > > > >>>> know when a user account is locked ? I am thinking about the > admin > > > > >>>> console. > > > > >>>> > > > > >>>> # 2 / When a user account is locked is there a way to unlock it > > > from the > > > > >>>> admin console ? > > > > >>> > > > > >>> Unfortunately no for the above. I'll log a jira. > > > > >>> > > > > >>>> # 3 / What is the difference between wait increment (When > failure > > > > >>>> threshold has been met, how much time should the user be locked > > > out?) > > > > >>>> and max wait (Max time a user will be locked out.). > > > > >>> > > > > >>> correct on both. > > > > >>> > > > > >>> > > > > >>> -- > > > > >>> Bill Burke > > > > >>> JBoss, a division of Red Hat > > > > >>> http://bill.burkecentral.com > > > > >>> _______________________________________________ > > > > >>> keycloak-user mailing list > > > > >>> keycloak-user at lists.jboss.org > > > > >>> https://lists.jboss.org/mailman/listinfo/keycloak-user > > > > > > > > > > -- > > > > > Bill Burke > > > > > JBoss, a division of Red Hat > > > > > http://bill.burkecentral.com > > > > > > > > > > > > _______________________________________________ > > > > 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-user/attachments/20141126/b6558824/attachment.html From stian at redhat.com Wed Nov 26 06:01:41 2014 From: stian at redhat.com (Stian Thorgersen) Date: Wed, 26 Nov 2014 06:01:41 -0500 (EST) Subject: [keycloak-user] Brut force attack questions In-Reply-To: References: <5474E8E7.8030300@redhat.com> <42A05865-7DF6-4F44-BD0B-537F028FD5A6@gmail.com> <1027232603.5396740.1416994799655.JavaMail.zimbra@redhat.com> <1565568349.5407824.1416996162495.JavaMail.zimbra@redhat.com> Message-ID: <638180951.5436181.1416999701830.JavaMail.zimbra@redhat.com> ----- Original Message ----- > From: "Alexander Chriztopher" > To: "Stian Thorgersen" > Cc: "Bill Burke" , keycloak-user at lists.jboss.org > Sent: Wednesday, 26 November, 2014 11:46:21 AM > Subject: Re: [keycloak-user] Brut force attack questions > > i think we will go for Infinispan or jpa for roadmap reasons ! > > how would we access the infinispan data ? You'll need to use 1.1.0.Beta1 as it's not available in 1.0.x. Have a look at http://docs.jboss.org/keycloak/docs/1.1.0.Beta1/userguide/html/clustering.html#d4e1662 You can inject the cache into your own application with: @Resource(lookup="java:jboss/infinispan/Keycloak") private CacheContainer container; You'll want to remove/change entries in the loginFailures cache. Look at the source for model/sessions-infinispan for more info on how the Infinispan userSession provider works. Have a look at www.mastertheboss.com/jboss-frameworks/infinispan/develop-a-clustered-application-with-infinispan-data-grid for more info on using the Infinispan subsystem from your app. > > are there any documents on this integration aspect within keycloak ? What integration aspect are you referring to? The work around proposed with accessing JPA or Infinispan directly is not recommended so won't be documented. > > On Wed, Nov 26, 2014 at 11:02 AM, Stian Thorgersen wrote: > > > > > > > ----- Original Message ----- > > > From: "Alexander Chriztopher" > > > To: "Stian Thorgersen" > > > Cc: "Bill Burke" , keycloak-user at lists.jboss.org > > > Sent: Wednesday, 26 November, 2014 10:51:11 AM > > > Subject: Re: [keycloak-user] Brut force attack questions > > > > > > nice ! > > > > > > is there a way to play with this via rest -regardless to wether am jpa, > > > infinispan or in-memory ? > > > > Afraid not, that's what we'll need to add. Not sure when we get time > > though. If you're up for it we would be more than happy to accept a > > contribution, I can give you some pointers on how to do it. Alternatively, > > you can create your own app that uses JAX-RS and either JPA or the > > Infinispan subsystem to remove login-failure entries. > > > > > > > > On Wed, Nov 26, 2014 at 10:39 AM, Stian Thorgersen > > wrote: > > > > > > > By default user sessions (and login failures) are stored in-memory not > > in > > > > the database. Unless you specify JPA for the userSession provider those > > > > tables will stay empty. > > > > > > > > You could either do what you're trying to do, which should work if you > > use > > > > the jpa userSession provider. The other if you're worried about the > > > > performance of storing user sessions in the db is to use the Infinispan > > > > provider, then you can manually delete login failures from the > > userSession > > > > cache from another application. > > > > > > > > We should add a mechanism to both view and remove login-failure > > entries to > > > > the admin console though. > > > > > > > > ----- Original Message ----- > > > > > From: "Alexander Chriztopher" > > > > > To: "Bill Burke" , keycloak-user at lists.jboss.org > > > > > Sent: Wednesday, 26 November, 2014 9:45:42 AM > > > > > Subject: Re: [keycloak-user] Brut force attack questions > > > > > > > > > > Am to find a workaround in order to be able to unlock a user > > account. So > > > > far > > > > > i have tried to disable then enable the user account but this does > > not do > > > > > the trick apparently. > > > > > > > > > > I have also tried to tweek the database but it looks like the lock > > > > > information is not stored in the db even though there is the table : > > > > > USERNAME_LOGIN_FAILURE. Is it normal that this table stays empty > > even on > > > > > login failures ? > > > > > > > > > > Do you think of any other good workaround ? > > > > > > > > > > > > > > > On Tue, Nov 25, 2014 at 11:03 PM, Alexander Chriztopher < > > > > > alexander.chriztopher at gmail.com > wrote: > > > > > > > > > > > > > > > Nice ! Again, thank you. > > > > > > > > > > > > > > > > > > > > > On 25 Nov 2014, at 21:39, Bill Burke < bburke at redhat.com > wrote: > > > > > > > > > > > > > > > > > > > > > > > >> On 11/25/2014 3:27 PM, Alexander Chriztopher wrote: > > > > > >> Hi Bill and thanks. > > > > > >> > > > > > >> Do you think we will be able to have this within a short period of > > > > time > > > > > >> (4-6 weeks) or is it going to be planned for the long run ? > > > > > > > > > > > > Not sure on the priority of this. We have face to face meetings in > > a > > > > couple > > > > > > of weeks to discuss priority, then of course, its christmas > > vacation. > > > > > > > > > > > >> When is the value of max wait used as there is already a wait > > > > increment > > > > > >> out there ? > > > > > > > > > > > > Correct. It will increase the wait after each failure until the > > max is > > > > hit. > > > > > > > > > > > >> > > > > > >> > > > > > >>> On 25 Nov 2014, at 20:05, Bill Burke < bburke at redhat.com > > > wrote: > > > > > >>> > > > > > >>> > > > > > >>> > > > > > >>>> On 11/25/2014 12:32 PM, Alexander Chriztopher wrote: > > > > > >>>> Hi, > > > > > >>>> > > > > > >>>> I have a some question with regards to Brut Force Attack > > Protection > > > > : > > > > > >>>> > > > > > >>>> # 1 / When brut force attack protection is enabled is there a > > way to > > > > > >>>> know when a user account is locked ? I am thinking about the > > admin > > > > > >>>> console. > > > > > >>>> > > > > > >>>> # 2 / When a user account is locked is there a way to unlock it > > > > from the > > > > > >>>> admin console ? > > > > > >>> > > > > > >>> Unfortunately no for the above. I'll log a jira. > > > > > >>> > > > > > >>>> # 3 / What is the difference between wait increment (When > > failure > > > > > >>>> threshold has been met, how much time should the user be locked > > > > out?) > > > > > >>>> and max wait (Max time a user will be locked out.). > > > > > >>> > > > > > >>> correct on both. > > > > > >>> > > > > > >>> > > > > > >>> -- > > > > > >>> Bill Burke > > > > > >>> JBoss, a division of Red Hat > > > > > >>> http://bill.burkecentral.com > > > > > >>> _______________________________________________ > > > > > >>> keycloak-user mailing list > > > > > >>> keycloak-user at lists.jboss.org > > > > > >>> https://lists.jboss.org/mailman/listinfo/keycloak-user > > > > > > > > > > > > -- > > > > > > Bill Burke > > > > > > JBoss, a division of Red Hat > > > > > > http://bill.burkecentral.com > > > > > > > > > > > > > > > _______________________________________________ > > > > > keycloak-user mailing list > > > > > keycloak-user at lists.jboss.org > > > > > https://lists.jboss.org/mailman/listinfo/keycloak-user > > > > > > > > > > From alexander.chriztopher at gmail.com Wed Nov 26 08:17:33 2014 From: alexander.chriztopher at gmail.com (Alexander Chriztopher) Date: Wed, 26 Nov 2014 14:17:33 +0100 Subject: [keycloak-user] Brut force attack questions In-Reply-To: <638180951.5436181.1416999701830.JavaMail.zimbra@redhat.com> References: <5474E8E7.8030300@redhat.com> <42A05865-7DF6-4F44-BD0B-537F028FD5A6@gmail.com> <1027232603.5396740.1416994799655.JavaMail.zimbra@redhat.com> <1565568349.5407824.1416996162495.JavaMail.zimbra@redhat.com> <638180951.5436181.1416999701830.JavaMail.zimbra@redhat.com> Message-ID: thank you for this ! i'll have a look at infinispan .. On Wed, Nov 26, 2014 at 12:01 PM, Stian Thorgersen wrote: > > > ----- Original Message ----- > > From: "Alexander Chriztopher" > > To: "Stian Thorgersen" > > Cc: "Bill Burke" , keycloak-user at lists.jboss.org > > Sent: Wednesday, 26 November, 2014 11:46:21 AM > > Subject: Re: [keycloak-user] Brut force attack questions > > > > i think we will go for Infinispan or jpa for roadmap reasons ! > > > > how would we access the infinispan data ? > > You'll need to use 1.1.0.Beta1 as it's not available in 1.0.x. Have a look > at > http://docs.jboss.org/keycloak/docs/1.1.0.Beta1/userguide/html/clustering.html#d4e1662 > > You can inject the cache into your own application with: > > @Resource(lookup="java:jboss/infinispan/Keycloak") > private CacheContainer container; > > You'll want to remove/change entries in the loginFailures cache. Look at > the source for model/sessions-infinispan for more info on how the > Infinispan userSession provider works. > > Have a look at > www.mastertheboss.com/jboss-frameworks/infinispan/develop-a-clustered-application-with-infinispan-data-grid > for more info on using the Infinispan subsystem from your app. > > > > > are there any documents on this integration aspect within keycloak ? > > What integration aspect are you referring to? The work around proposed > with accessing JPA or Infinispan directly is not recommended so won't be > documented. > > > > > On Wed, Nov 26, 2014 at 11:02 AM, Stian Thorgersen > wrote: > > > > > > > > > > > ----- Original Message ----- > > > > From: "Alexander Chriztopher" > > > > To: "Stian Thorgersen" > > > > Cc: "Bill Burke" , keycloak-user at lists.jboss.org > > > > Sent: Wednesday, 26 November, 2014 10:51:11 AM > > > > Subject: Re: [keycloak-user] Brut force attack questions > > > > > > > > nice ! > > > > > > > > is there a way to play with this via rest -regardless to wether am > jpa, > > > > infinispan or in-memory ? > > > > > > Afraid not, that's what we'll need to add. Not sure when we get time > > > though. If you're up for it we would be more than happy to accept a > > > contribution, I can give you some pointers on how to do it. > Alternatively, > > > you can create your own app that uses JAX-RS and either JPA or the > > > Infinispan subsystem to remove login-failure entries. > > > > > > > > > > > On Wed, Nov 26, 2014 at 10:39 AM, Stian Thorgersen > > > > wrote: > > > > > > > > > By default user sessions (and login failures) are stored in-memory > not > > > in > > > > > the database. Unless you specify JPA for the userSession provider > those > > > > > tables will stay empty. > > > > > > > > > > You could either do what you're trying to do, which should work if > you > > > use > > > > > the jpa userSession provider. The other if you're worried about the > > > > > performance of storing user sessions in the db is to use the > Infinispan > > > > > provider, then you can manually delete login failures from the > > > userSession > > > > > cache from another application. > > > > > > > > > > We should add a mechanism to both view and remove login-failure > > > entries to > > > > > the admin console though. > > > > > > > > > > ----- Original Message ----- > > > > > > From: "Alexander Chriztopher" > > > > > > To: "Bill Burke" , > keycloak-user at lists.jboss.org > > > > > > Sent: Wednesday, 26 November, 2014 9:45:42 AM > > > > > > Subject: Re: [keycloak-user] Brut force attack questions > > > > > > > > > > > > Am to find a workaround in order to be able to unlock a user > > > account. So > > > > > far > > > > > > i have tried to disable then enable the user account but this > does > > > not do > > > > > > the trick apparently. > > > > > > > > > > > > I have also tried to tweek the database but it looks like the > lock > > > > > > information is not stored in the db even though there is the > table : > > > > > > USERNAME_LOGIN_FAILURE. Is it normal that this table stays empty > > > even on > > > > > > login failures ? > > > > > > > > > > > > Do you think of any other good workaround ? > > > > > > > > > > > > > > > > > > On Tue, Nov 25, 2014 at 11:03 PM, Alexander Chriztopher < > > > > > > alexander.chriztopher at gmail.com > wrote: > > > > > > > > > > > > > > > > > > Nice ! Again, thank you. > > > > > > > > > > > > > > > > > > > > > > > > > On 25 Nov 2014, at 21:39, Bill Burke < bburke at redhat.com > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > >> On 11/25/2014 3:27 PM, Alexander Chriztopher wrote: > > > > > > >> Hi Bill and thanks. > > > > > > >> > > > > > > >> Do you think we will be able to have this within a short > period of > > > > > time > > > > > > >> (4-6 weeks) or is it going to be planned for the long run ? > > > > > > > > > > > > > > Not sure on the priority of this. We have face to face > meetings in > > > a > > > > > couple > > > > > > > of weeks to discuss priority, then of course, its christmas > > > vacation. > > > > > > > > > > > > > >> When is the value of max wait used as there is already a wait > > > > > increment > > > > > > >> out there ? > > > > > > > > > > > > > > Correct. It will increase the wait after each failure until the > > > max is > > > > > hit. > > > > > > > > > > > > > >> > > > > > > >> > > > > > > >>> On 25 Nov 2014, at 20:05, Bill Burke < bburke at redhat.com > > > > wrote: > > > > > > >>> > > > > > > >>> > > > > > > >>> > > > > > > >>>> On 11/25/2014 12:32 PM, Alexander Chriztopher wrote: > > > > > > >>>> Hi, > > > > > > >>>> > > > > > > >>>> I have a some question with regards to Brut Force Attack > > > Protection > > > > > : > > > > > > >>>> > > > > > > >>>> # 1 / When brut force attack protection is enabled is there > a > > > way to > > > > > > >>>> know when a user account is locked ? I am thinking about the > > > admin > > > > > > >>>> console. > > > > > > >>>> > > > > > > >>>> # 2 / When a user account is locked is there a way to > unlock it > > > > > from the > > > > > > >>>> admin console ? > > > > > > >>> > > > > > > >>> Unfortunately no for the above. I'll log a jira. > > > > > > >>> > > > > > > >>>> # 3 / What is the difference between wait increment (When > > > failure > > > > > > >>>> threshold has been met, how much time should the user be > locked > > > > > out?) > > > > > > >>>> and max wait (Max time a user will be locked out.). > > > > > > >>> > > > > > > >>> correct on both. > > > > > > >>> > > > > > > >>> > > > > > > >>> -- > > > > > > >>> Bill Burke > > > > > > >>> JBoss, a division of Red Hat > > > > > > >>> http://bill.burkecentral.com > > > > > > >>> _______________________________________________ > > > > > > >>> keycloak-user mailing list > > > > > > >>> keycloak-user at lists.jboss.org > > > > > > >>> https://lists.jboss.org/mailman/listinfo/keycloak-user > > > > > > > > > > > > > > -- > > > > > > > Bill Burke > > > > > > > JBoss, a division of Red Hat > > > > > > > http://bill.burkecentral.com > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > 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-user/attachments/20141126/dde80502/attachment.html From gbrown at redhat.com Wed Nov 26 08:54:18 2014 From: gbrown at redhat.com (Gary Brown) Date: Wed, 26 Nov 2014 08:54:18 -0500 (EST) Subject: [keycloak-user] REST services supporting basic auth and bearer tokens In-Reply-To: <547144205.14661357.1417009582019.JavaMail.zimbra@redhat.com> Message-ID: <648294658.14664021.1417010058756.JavaMail.zimbra@redhat.com> Hi Concrete use case - we have implemented the OASIS S-RAMP specification, in which it requires basic auth support (http://docs.oasis-open.org/s-ramp/s-ramp/v1.0/s-ramp-v1.0-part2-atom-binding.html section 5 "The S-RAMP Specification does not attempt to define a security model for products that implement it. For the Atom Binding, the only security requirement is that at a minimum, client and server implementations MUST be capable of being configured to use HTTP Basic Authentication in conjunction with a connection made with TLS."). However we also need the same service to support bearer token, for use within our KeyCloak SSO session. I've implemented a possible solution, details defined on https://issues.jboss.org/browse/KEYCLOAK-861. If this solution is on the right path, I would appreciate any feedback on any changes that might be required before submitting a PR. Currently there are no tests, but would aim to provide some with the PR. Regards Gary From rodrigopsasaki at gmail.com Wed Nov 26 13:13:02 2014 From: rodrigopsasaki at gmail.com (Rodrigo Sasaki) Date: Wed, 26 Nov 2014 16:13:02 -0200 Subject: [keycloak-user] Mobile Authentication API Message-ID: Hello, I was wondering if there is a plan (or maybe something already built) for native mobile authentication with Keycloak. Right now we need to redirect the user to a web view so he can interface with Keycloak to login, and from there on he can use the app normally, but is there something native for this? We're trying to find ways to use the smartphone's native authentication systems to login the users, and so far we haven't been able to make it work. Have you thought of something along those lines? Thank you. -- Rodrigo Sasaki -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20141126/9a5b547d/attachment.html From rodrigopsasaki at gmail.com Wed Nov 26 13:32:38 2014 From: rodrigopsasaki at gmail.com (Rodrigo Sasaki) Date: Wed, 26 Nov 2014 16:32:38 -0200 Subject: [keycloak-user] Mobile Authentication API In-Reply-To: References: Message-ID: Sorry, I wasn't clear enough. The problem we're having is with social logins When we have to login a user via social links (Google or Facebook) we need to send him to a webview, because Keycloak communicates with the social networks via the default flows we already have implemented. But from a mobile standpoint this could be improved, because the user can alerady have a Google account and/or a Facebook account on his mobile device. So that could be used instead of making the user login again on a webview. The idea is to send the social information we already have on the mobile device to Keycloak and get a token in return (we can do this with username/password today). The ideal thing would be a SDK for this that would (for example) be instantiated with URI and client_id, and would provide a method for login. I know this might not be in your roadmap for any time soon, but I'd like to know if you have thought about any of this. This provides a very different user experience for the user, and I think this feature would be appreciated by many. Thank you all again! Rodrigo Sasaki On Wed, Nov 26, 2014 at 4:13 PM, Rodrigo Sasaki wrote: > Hello, > > I was wondering if there is a plan (or maybe something already built) for > native mobile authentication with Keycloak. > > Right now we need to redirect the user to a web view so he can interface > with Keycloak to login, and from there on he can use the app normally, but > is there something native for this? We're trying to find ways to use the > smartphone's native authentication systems to login the users, and so far > we haven't been able to make it work. > > Have you thought of something along those lines? > > Thank you. > > -- > Rodrigo Sasaki > -- Rodrigo Sasaki -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20141126/775b8c14/attachment-0001.html From stian at redhat.com Thu Nov 27 02:39:45 2014 From: stian at redhat.com (Stian Thorgersen) Date: Thu, 27 Nov 2014 02:39:45 -0500 (EST) Subject: [keycloak-user] Mobile Authentication API In-Reply-To: References: Message-ID: <374335332.6310564.1417073985438.JavaMail.zimbra@redhat.com> Hi, It's something we've discussed in the past. It would work, but it's not very elegant as a lot of the logic would be pushed onto the native app. Our core aim with Keycloak is to make security easy for folks. That being said are you using the direct grant api to exchange a username/password for a token? We could probably allow using the direct grant api and pass a token instead of a username/password. Added AeroGear mailing list as they're working on mobile adapters for Keycloak. ----- Original Message ----- > From: "Rodrigo Sasaki" > To: keycloak-user at lists.jboss.org > Sent: Wednesday, 26 November, 2014 7:32:38 PM > Subject: Re: [keycloak-user] Mobile Authentication API > > Sorry, I wasn't clear enough. The problem we're having is with social logins > > When we have to login a user via social links (Google or Facebook) we need to > send him to a webview, because Keycloak communicates with the social > networks via the default flows we already have implemented. > > But from a mobile standpoint this could be improved, because the user can > alerady have a Google account and/or a Facebook account on his mobile > device. So that could be used instead of making the user login again on a > webview. > > The idea is to send the social information we already have on the mobile > device to Keycloak and get a token in return (we can do this with > username/password today). > > The ideal thing would be a SDK for this that would (for example) be > instantiated with URI and client_id, and would provide a method for login. I > know this might not be in your roadmap for any time soon, but I'd like to > know if you have thought about any of this. > > This provides a very different user experience for the user, and I think this > feature would be appreciated by many. > > Thank you all again! > > Rodrigo Sasaki > > On Wed, Nov 26, 2014 at 4:13 PM, Rodrigo Sasaki < rodrigopsasaki at gmail.com > > wrote: > > > > Hello, > > I was wondering if there is a plan (or maybe something already built) for > native mobile authentication with Keycloak. > > Right now we need to redirect the user to a web view so he can interface with > Keycloak to login, and from there on he can use the app normally, but is > there something native for this? We're trying to find ways to use the > smartphone's native authentication systems to login the users, and so far we > haven't been able to make it work. > > Have you thought of something along those lines? > > Thank you. > > -- > Rodrigo Sasaki > > > > -- > Rodrigo Sasaki > > _______________________________________________ > keycloak-user mailing list > keycloak-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user From mposolda at redhat.com Thu Nov 27 04:46:21 2014 From: mposolda at redhat.com (Marek Posolda) Date: Thu, 27 Nov 2014 10:46:21 +0100 Subject: [keycloak-user] REST services supporting basic auth and bearer tokens In-Reply-To: <648294658.14664021.1417010058756.JavaMail.zimbra@redhat.com> References: <648294658.14664021.1417010058756.JavaMail.zimbra@redhat.com> Message-ID: <5476F2ED.60401@redhat.com> Hi, I am not 100% sure if having basic auth with direct grant directly in our adapters is way to go. Probably yes as for your use-case it makes sense, so I am slightly for push your change as PR. But maybe others from team have different opinion. Earlier this week I've added DirectAccessGrantsLoginModule to KC codebase, which is quite similar and is intended to be used for non-web applications (like SSH), which rely on JAAS. But I guess that using this one is not good option for you as you want support for Basic and Bearer authentication in same web application, right? Few more minor points to your changes: - Is it possible to use net.iharder.Base64 instead of org.apache.commons.codec.binary.Base64? Whole KC code has dependency on net.iharder, so would be likely better to use this one to avoid possible dependency issues in adapters. - Wonder if it's possible to simplify a bit, like have single "completeAuthentication" method for both bearer and basic authenticator (afaik only difference among them is different authMethod right?). But this is really minor. Marek On 26.11.2014 14:54, Gary Brown wrote: > Hi > > Concrete use case - we have implemented the OASIS S-RAMP specification, in which it requires basic auth support (http://docs.oasis-open.org/s-ramp/s-ramp/v1.0/s-ramp-v1.0-part2-atom-binding.html section 5 "The S-RAMP Specification does not attempt to define a security model for products that implement it. For the Atom Binding, the only security requirement is that at a minimum, client and server implementations MUST be capable of being configured to use HTTP Basic Authentication in conjunction with a connection made with TLS."). > > However we also need the same service to support bearer token, for use within our KeyCloak SSO session. > > I've implemented a possible solution, details defined on https://issues.jboss.org/browse/KEYCLOAK-861. > > If this solution is on the right path, I would appreciate any feedback on any changes that might be required before submitting a PR. Currently there are no tests, but would aim to provide some with the PR. > > Regards > Gary > _______________________________________________ > keycloak-user mailing list > keycloak-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user From gbrown at redhat.com Thu Nov 27 04:58:21 2014 From: gbrown at redhat.com (Gary Brown) Date: Thu, 27 Nov 2014 04:58:21 -0500 (EST) Subject: [keycloak-user] REST services supporting basic auth and bearer tokens In-Reply-To: <5476F2ED.60401@redhat.com> References: <648294658.14664021.1417010058756.JavaMail.zimbra@redhat.com> <5476F2ED.60401@redhat.com> Message-ID: <1011678021.15105884.1417082301249.JavaMail.zimbra@redhat.com> Hi Marek ----- Original Message ----- > Hi, > > I am not 100% sure if having basic auth with direct grant directly in > our adapters is way to go. Probably yes as for your use-case it makes > sense, so I am slightly for push your change as PR. But maybe others > from team have different opinion. > > Earlier this week I've added DirectAccessGrantsLoginModule to KC > codebase, which is quite similar and is intended to be used for non-web > applications (like SSH), which rely on JAAS. But I guess that using this > one is not good option for you as you want support for Basic and Bearer > authentication in same web application, right? Thats correct. > > Few more minor points to your changes: > - Is it possible to use net.iharder.Base64 instead of > org.apache.commons.codec.binary.Base64? Whole KC code has dependency on > net.iharder, so would be likely better to use this one to avoid possible > dependency issues in adapters. That shouldn't be a problem. > > - Wonder if it's possible to simplify a bit, like have single > "completeAuthentication" method for both bearer and basic authenticator > (afaik only difference among them is different authMethod right?). But > this is really minor. Will do. I'll wait until mid next week before doing any more on this, to see whether others have an opinion. If the PR was accepted, any chance it could go into 1.1 even though in beta? If no, any idea what the timescale is for 1.2.beta1? Thanks for your feedback. Regards Gary > > Marek > > On 26.11.2014 14:54, Gary Brown wrote: > > Hi > > > > Concrete use case - we have implemented the OASIS S-RAMP specification, in > > which it requires basic auth support > > (http://docs.oasis-open.org/s-ramp/s-ramp/v1.0/s-ramp-v1.0-part2-atom-binding.html > > section 5 "The S-RAMP Specification does not attempt to define a security > > model for products that implement it. For the Atom Binding, the only > > security requirement is that at a minimum, client and server > > implementations MUST be capable of being configured to use HTTP Basic > > Authentication in conjunction with a connection made with TLS."). > > > > However we also need the same service to support bearer token, for use > > within our KeyCloak SSO session. > > > > I've implemented a possible solution, details defined on > > https://issues.jboss.org/browse/KEYCLOAK-861. > > > > If this solution is on the right path, I would appreciate any feedback on > > any changes that might be required before submitting a PR. Currently there > > are no tests, but would aim to provide some with the PR. > > > > Regards > > Gary > > _______________________________________________ > > keycloak-user mailing list > > keycloak-user at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/keycloak-user > > From stian at redhat.com Thu Nov 27 06:06:09 2014 From: stian at redhat.com (Stian Thorgersen) Date: Thu, 27 Nov 2014 06:06:09 -0500 (EST) Subject: [keycloak-user] REST services supporting basic auth and bearer tokens In-Reply-To: <1011678021.15105884.1417082301249.JavaMail.zimbra@redhat.com> References: <648294658.14664021.1417010058756.JavaMail.zimbra@redhat.com> <5476F2ED.60401@redhat.com> <1011678021.15105884.1417082301249.JavaMail.zimbra@redhat.com> Message-ID: <96258862.6486814.1417086369447.JavaMail.zimbra@redhat.com> Looks good to me, but I'd like it to be an optional feature that is enabled in keycloak.json (should be disabled by default). Another thing is that we should add an example + documentation for this feature. ----- Original Message ----- > From: "Gary Brown" > To: "Marek Posolda" > Cc: keycloak-user at lists.jboss.org > Sent: Thursday, 27 November, 2014 10:58:21 AM > Subject: Re: [keycloak-user] REST services supporting basic auth and bearer tokens > > Hi Marek > > ----- Original Message ----- > > Hi, > > > > I am not 100% sure if having basic auth with direct grant directly in > > our adapters is way to go. Probably yes as for your use-case it makes > > sense, so I am slightly for push your change as PR. But maybe others > > from team have different opinion. > > > > Earlier this week I've added DirectAccessGrantsLoginModule to KC > > codebase, which is quite similar and is intended to be used for non-web > > applications (like SSH), which rely on JAAS. But I guess that using this > > one is not good option for you as you want support for Basic and Bearer > > authentication in same web application, right? > > Thats correct. > > > > > Few more minor points to your changes: > > - Is it possible to use net.iharder.Base64 instead of > > org.apache.commons.codec.binary.Base64? Whole KC code has dependency on > > net.iharder, so would be likely better to use this one to avoid possible > > dependency issues in adapters. > > That shouldn't be a problem. > > > > > - Wonder if it's possible to simplify a bit, like have single > > "completeAuthentication" method for both bearer and basic authenticator > > (afaik only difference among them is different authMethod right?). But > > this is really minor. > > Will do. > > I'll wait until mid next week before doing any more on this, to see whether > others have an opinion. > > If the PR was accepted, any chance it could go into 1.1 even though in beta? > If no, any idea what the timescale is for 1.2.beta1? > > Thanks for your feedback. > > Regards > Gary > > > > > Marek > > > > On 26.11.2014 14:54, Gary Brown wrote: > > > Hi > > > > > > Concrete use case - we have implemented the OASIS S-RAMP specification, > > > in > > > which it requires basic auth support > > > (http://docs.oasis-open.org/s-ramp/s-ramp/v1.0/s-ramp-v1.0-part2-atom-binding.html > > > section 5 "The S-RAMP Specification does not attempt to define a security > > > model for products that implement it. For the Atom Binding, the only > > > security requirement is that at a minimum, client and server > > > implementations MUST be capable of being configured to use HTTP Basic > > > Authentication in conjunction with a connection made with TLS."). > > > > > > However we also need the same service to support bearer token, for use > > > within our KeyCloak SSO session. > > > > > > I've implemented a possible solution, details defined on > > > https://issues.jboss.org/browse/KEYCLOAK-861. > > > > > > If this solution is on the right path, I would appreciate any feedback on > > > any changes that might be required before submitting a PR. Currently > > > there > > > are no tests, but would aim to provide some with the PR. > > > > > > Regards > > > Gary > > > _______________________________________________ > > > keycloak-user mailing list > > > keycloak-user at lists.jboss.org > > > https://lists.jboss.org/mailman/listinfo/keycloak-user > > > > > _______________________________________________ > keycloak-user mailing list > keycloak-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user > From rodrigopsasaki at gmail.com Thu Nov 27 06:34:32 2014 From: rodrigopsasaki at gmail.com (Rodrigo Sasaki) Date: Thu, 27 Nov 2014 09:34:32 -0200 Subject: [keycloak-user] Mobile Authentication API In-Reply-To: <374335332.6310564.1417073985438.JavaMail.zimbra@redhat.com> References: <374335332.6310564.1417073985438.JavaMail.zimbra@redhat.com> Message-ID: That's exactly the case, we're using the direct grant API to exchange username/password for a token. If there was an endpoint to do the same with tokens from social links that would be fantastic. That would already be flexible enough for us to develop the activities the way we want. On Thu, Nov 27, 2014 at 5:39 AM, Stian Thorgersen wrote: > Hi, > > It's something we've discussed in the past. It would work, but it's not > very elegant as a lot of the logic would be pushed onto the native app. Our > core aim with Keycloak is to make security easy for folks. > > That being said are you using the direct grant api to exchange a > username/password for a token? We could probably allow using the direct > grant api and pass a token instead of a username/password. > > Added AeroGear mailing list as they're working on mobile adapters for > Keycloak. > > ----- Original Message ----- > > From: "Rodrigo Sasaki" > > To: keycloak-user at lists.jboss.org > > Sent: Wednesday, 26 November, 2014 7:32:38 PM > > Subject: Re: [keycloak-user] Mobile Authentication API > > > > Sorry, I wasn't clear enough. The problem we're having is with social > logins > > > > When we have to login a user via social links (Google or Facebook) we > need to > > send him to a webview, because Keycloak communicates with the social > > networks via the default flows we already have implemented. > > > > But from a mobile standpoint this could be improved, because the user can > > alerady have a Google account and/or a Facebook account on his mobile > > device. So that could be used instead of making the user login again on a > > webview. > > > > The idea is to send the social information we already have on the mobile > > device to Keycloak and get a token in return (we can do this with > > username/password today). > > > > The ideal thing would be a SDK for this that would (for example) be > > instantiated with URI and client_id, and would provide a method for > login. I > > know this might not be in your roadmap for any time soon, but I'd like to > > know if you have thought about any of this. > > > > This provides a very different user experience for the user, and I think > this > > feature would be appreciated by many. > > > > Thank you all again! > > > > Rodrigo Sasaki > > > > On Wed, Nov 26, 2014 at 4:13 PM, Rodrigo Sasaki < > rodrigopsasaki at gmail.com > > > wrote: > > > > > > > > Hello, > > > > I was wondering if there is a plan (or maybe something already built) for > > native mobile authentication with Keycloak. > > > > Right now we need to redirect the user to a web view so he can interface > with > > Keycloak to login, and from there on he can use the app normally, but is > > there something native for this? We're trying to find ways to use the > > smartphone's native authentication systems to login the users, and so > far we > > haven't been able to make it work. > > > > Have you thought of something along those lines? > > > > Thank you. > > > > -- > > Rodrigo Sasaki > > > > > > > > -- > > Rodrigo Sasaki > > > > _______________________________________________ > > keycloak-user mailing list > > keycloak-user at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/keycloak-user > -- Rodrigo Sasaki -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20141127/d9d050bf/attachment.html From gbrown at redhat.com Thu Nov 27 07:48:55 2014 From: gbrown at redhat.com (Gary Brown) Date: Thu, 27 Nov 2014 07:48:55 -0500 (EST) Subject: [keycloak-user] REST services supporting basic auth and bearer tokens In-Reply-To: <96258862.6486814.1417086369447.JavaMail.zimbra@redhat.com> References: <648294658.14664021.1417010058756.JavaMail.zimbra@redhat.com> <5476F2ED.60401@redhat.com> <1011678021.15105884.1417082301249.JavaMail.zimbra@redhat.com> <96258862.6486814.1417086369447.JavaMail.zimbra@redhat.com> Message-ID: <1676107994.15149522.1417092535843.JavaMail.zimbra@redhat.com> ----- Original Message ----- > Looks good to me, but I'd like it to be an optional feature that is enabled > in keycloak.json (should be disabled by default). Sounds reasonable - I'll call the property 'enableBasicAuth'. > > Another thing is that we should add an example + documentation for this > feature. Will do. > > ----- Original Message ----- > > From: "Gary Brown" > > To: "Marek Posolda" > > Cc: keycloak-user at lists.jboss.org > > Sent: Thursday, 27 November, 2014 10:58:21 AM > > Subject: Re: [keycloak-user] REST services supporting basic auth and bearer > > tokens > > > > Hi Marek > > > > ----- Original Message ----- > > > Hi, > > > > > > I am not 100% sure if having basic auth with direct grant directly in > > > our adapters is way to go. Probably yes as for your use-case it makes > > > sense, so I am slightly for push your change as PR. But maybe others > > > from team have different opinion. > > > > > > Earlier this week I've added DirectAccessGrantsLoginModule to KC > > > codebase, which is quite similar and is intended to be used for non-web > > > applications (like SSH), which rely on JAAS. But I guess that using this > > > one is not good option for you as you want support for Basic and Bearer > > > authentication in same web application, right? > > > > Thats correct. > > > > > > > > Few more minor points to your changes: > > > - Is it possible to use net.iharder.Base64 instead of > > > org.apache.commons.codec.binary.Base64? Whole KC code has dependency on > > > net.iharder, so would be likely better to use this one to avoid possible > > > dependency issues in adapters. > > > > That shouldn't be a problem. > > > > > > > > - Wonder if it's possible to simplify a bit, like have single > > > "completeAuthentication" method for both bearer and basic authenticator > > > (afaik only difference among them is different authMethod right?). But > > > this is really minor. > > > > Will do. > > > > I'll wait until mid next week before doing any more on this, to see whether > > others have an opinion. > > > > If the PR was accepted, any chance it could go into 1.1 even though in > > beta? > > If no, any idea what the timescale is for 1.2.beta1? > > > > Thanks for your feedback. > > > > Regards > > Gary > > > > > > > > Marek > > > > > > On 26.11.2014 14:54, Gary Brown wrote: > > > > Hi > > > > > > > > Concrete use case - we have implemented the OASIS S-RAMP specification, > > > > in > > > > which it requires basic auth support > > > > (http://docs.oasis-open.org/s-ramp/s-ramp/v1.0/s-ramp-v1.0-part2-atom-binding.html > > > > section 5 "The S-RAMP Specification does not attempt to define a > > > > security > > > > model for products that implement it. For the Atom Binding, the only > > > > security requirement is that at a minimum, client and server > > > > implementations MUST be capable of being configured to use HTTP Basic > > > > Authentication in conjunction with a connection made with TLS."). > > > > > > > > However we also need the same service to support bearer token, for use > > > > within our KeyCloak SSO session. > > > > > > > > I've implemented a possible solution, details defined on > > > > https://issues.jboss.org/browse/KEYCLOAK-861. > > > > > > > > If this solution is on the right path, I would appreciate any feedback > > > > on > > > > any changes that might be required before submitting a PR. Currently > > > > there > > > > are no tests, but would aim to provide some with the PR. > > > > > > > > Regards > > > > Gary > > > > _______________________________________________ > > > > keycloak-user mailing list > > > > keycloak-user at lists.jboss.org > > > > https://lists.jboss.org/mailman/listinfo/keycloak-user > > > > > > > > _______________________________________________ > > keycloak-user mailing list > > keycloak-user at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/keycloak-user > > > From stian at redhat.com Thu Nov 27 07:54:03 2014 From: stian at redhat.com (Stian Thorgersen) Date: Thu, 27 Nov 2014 07:54:03 -0500 (EST) Subject: [keycloak-user] REST services supporting basic auth and bearer tokens In-Reply-To: <1676107994.15149522.1417092535843.JavaMail.zimbra@redhat.com> References: <648294658.14664021.1417010058756.JavaMail.zimbra@redhat.com> <5476F2ED.60401@redhat.com> <1011678021.15105884.1417082301249.JavaMail.zimbra@redhat.com> <96258862.6486814.1417086369447.JavaMail.zimbra@redhat.com> <1676107994.15149522.1417092535843.JavaMail.zimbra@redhat.com> Message-ID: <1607831918.6553021.1417092843731.JavaMail.zimbra@redhat.com> Great, if you do a PR include an example we can merge it before a 1.1.0.Beta2 release (probably next week) ----- Original Message ----- > From: "Gary Brown" > To: "Stian Thorgersen" > Cc: "Marek Posolda" , keycloak-user at lists.jboss.org > Sent: Thursday, 27 November, 2014 1:48:55 PM > Subject: Re: [keycloak-user] REST services supporting basic auth and bearer tokens > > > > ----- Original Message ----- > > Looks good to me, but I'd like it to be an optional feature that is enabled > > in keycloak.json (should be disabled by default). > > Sounds reasonable - I'll call the property 'enableBasicAuth'. > > > > > Another thing is that we should add an example + documentation for this > > feature. > > Will do. > > > > > ----- Original Message ----- > > > From: "Gary Brown" > > > To: "Marek Posolda" > > > Cc: keycloak-user at lists.jboss.org > > > Sent: Thursday, 27 November, 2014 10:58:21 AM > > > Subject: Re: [keycloak-user] REST services supporting basic auth and > > > bearer > > > tokens > > > > > > Hi Marek > > > > > > ----- Original Message ----- > > > > Hi, > > > > > > > > I am not 100% sure if having basic auth with direct grant directly in > > > > our adapters is way to go. Probably yes as for your use-case it makes > > > > sense, so I am slightly for push your change as PR. But maybe others > > > > from team have different opinion. > > > > > > > > Earlier this week I've added DirectAccessGrantsLoginModule to KC > > > > codebase, which is quite similar and is intended to be used for non-web > > > > applications (like SSH), which rely on JAAS. But I guess that using > > > > this > > > > one is not good option for you as you want support for Basic and Bearer > > > > authentication in same web application, right? > > > > > > Thats correct. > > > > > > > > > > > Few more minor points to your changes: > > > > - Is it possible to use net.iharder.Base64 instead of > > > > org.apache.commons.codec.binary.Base64? Whole KC code has dependency on > > > > net.iharder, so would be likely better to use this one to avoid > > > > possible > > > > dependency issues in adapters. > > > > > > That shouldn't be a problem. > > > > > > > > > > > - Wonder if it's possible to simplify a bit, like have single > > > > "completeAuthentication" method for both bearer and basic authenticator > > > > (afaik only difference among them is different authMethod right?). But > > > > this is really minor. > > > > > > Will do. > > > > > > I'll wait until mid next week before doing any more on this, to see > > > whether > > > others have an opinion. > > > > > > If the PR was accepted, any chance it could go into 1.1 even though in > > > beta? > > > If no, any idea what the timescale is for 1.2.beta1? > > > > > > Thanks for your feedback. > > > > > > Regards > > > Gary > > > > > > > > > > > Marek > > > > > > > > On 26.11.2014 14:54, Gary Brown wrote: > > > > > Hi > > > > > > > > > > Concrete use case - we have implemented the OASIS S-RAMP > > > > > specification, > > > > > in > > > > > which it requires basic auth support > > > > > (http://docs.oasis-open.org/s-ramp/s-ramp/v1.0/s-ramp-v1.0-part2-atom-binding.html > > > > > section 5 "The S-RAMP Specification does not attempt to define a > > > > > security > > > > > model for products that implement it. For the Atom Binding, the only > > > > > security requirement is that at a minimum, client and server > > > > > implementations MUST be capable of being configured to use HTTP Basic > > > > > Authentication in conjunction with a connection made with TLS."). > > > > > > > > > > However we also need the same service to support bearer token, for > > > > > use > > > > > within our KeyCloak SSO session. > > > > > > > > > > I've implemented a possible solution, details defined on > > > > > https://issues.jboss.org/browse/KEYCLOAK-861. > > > > > > > > > > If this solution is on the right path, I would appreciate any > > > > > feedback > > > > > on > > > > > any changes that might be required before submitting a PR. Currently > > > > > there > > > > > are no tests, but would aim to provide some with the PR. > > > > > > > > > > Regards > > > > > Gary > > > > > _______________________________________________ > > > > > keycloak-user mailing list > > > > > keycloak-user at lists.jboss.org > > > > > https://lists.jboss.org/mailman/listinfo/keycloak-user > > > > > > > > > > > _______________________________________________ > > > keycloak-user mailing list > > > keycloak-user at lists.jboss.org > > > https://lists.jboss.org/mailman/listinfo/keycloak-user > > > > > > From gbrown at redhat.com Thu Nov 27 08:59:46 2014 From: gbrown at redhat.com (Gary Brown) Date: Thu, 27 Nov 2014 08:59:46 -0500 (EST) Subject: [keycloak-user] REST services supporting basic auth and bearer tokens In-Reply-To: <1607831918.6553021.1417092843731.JavaMail.zimbra@redhat.com> References: <648294658.14664021.1417010058756.JavaMail.zimbra@redhat.com> <5476F2ED.60401@redhat.com> <1011678021.15105884.1417082301249.JavaMail.zimbra@redhat.com> <96258862.6486814.1417086369447.JavaMail.zimbra@redhat.com> <1676107994.15149522.1417092535843.JavaMail.zimbra@redhat.com> <1607831918.6553021.1417092843731.JavaMail.zimbra@redhat.com> Message-ID: <4705717.15181747.1417096786699.JavaMail.zimbra@redhat.com> In terms of example, was thinking the database-service is ideal - however I'm guessing it also needs to be shown as a 'bearer-only' example (as now). In the same way that there is multiple customer-apps, one approach could be to have an alternate database-service supporting basic auth as well, but then would also need a separate copy of the testrealm.json. Thoughts? ----- Original Message ----- > Great, if you do a PR include an example we can merge it before a 1.1.0.Beta2 > release (probably next week) > > ----- Original Message ----- > > From: "Gary Brown" > > To: "Stian Thorgersen" > > Cc: "Marek Posolda" , keycloak-user at lists.jboss.org > > Sent: Thursday, 27 November, 2014 1:48:55 PM > > Subject: Re: [keycloak-user] REST services supporting basic auth and bearer > > tokens > > > > > > > > ----- Original Message ----- > > > Looks good to me, but I'd like it to be an optional feature that is > > > enabled > > > in keycloak.json (should be disabled by default). > > > > Sounds reasonable - I'll call the property 'enableBasicAuth'. > > > > > > > > Another thing is that we should add an example + documentation for this > > > feature. > > > > Will do. > > > > > > > > ----- Original Message ----- > > > > From: "Gary Brown" > > > > To: "Marek Posolda" > > > > Cc: keycloak-user at lists.jboss.org > > > > Sent: Thursday, 27 November, 2014 10:58:21 AM > > > > Subject: Re: [keycloak-user] REST services supporting basic auth and > > > > bearer > > > > tokens > > > > > > > > Hi Marek > > > > > > > > ----- Original Message ----- > > > > > Hi, > > > > > > > > > > I am not 100% sure if having basic auth with direct grant directly in > > > > > our adapters is way to go. Probably yes as for your use-case it makes > > > > > sense, so I am slightly for push your change as PR. But maybe others > > > > > from team have different opinion. > > > > > > > > > > Earlier this week I've added DirectAccessGrantsLoginModule to KC > > > > > codebase, which is quite similar and is intended to be used for > > > > > non-web > > > > > applications (like SSH), which rely on JAAS. But I guess that using > > > > > this > > > > > one is not good option for you as you want support for Basic and > > > > > Bearer > > > > > authentication in same web application, right? > > > > > > > > Thats correct. > > > > > > > > > > > > > > Few more minor points to your changes: > > > > > - Is it possible to use net.iharder.Base64 instead of > > > > > org.apache.commons.codec.binary.Base64? Whole KC code has dependency > > > > > on > > > > > net.iharder, so would be likely better to use this one to avoid > > > > > possible > > > > > dependency issues in adapters. > > > > > > > > That shouldn't be a problem. > > > > > > > > > > > > > > - Wonder if it's possible to simplify a bit, like have single > > > > > "completeAuthentication" method for both bearer and basic > > > > > authenticator > > > > > (afaik only difference among them is different authMethod right?). > > > > > But > > > > > this is really minor. > > > > > > > > Will do. > > > > > > > > I'll wait until mid next week before doing any more on this, to see > > > > whether > > > > others have an opinion. > > > > > > > > If the PR was accepted, any chance it could go into 1.1 even though in > > > > beta? > > > > If no, any idea what the timescale is for 1.2.beta1? > > > > > > > > Thanks for your feedback. > > > > > > > > Regards > > > > Gary > > > > > > > > > > > > > > Marek > > > > > > > > > > On 26.11.2014 14:54, Gary Brown wrote: > > > > > > Hi > > > > > > > > > > > > Concrete use case - we have implemented the OASIS S-RAMP > > > > > > specification, > > > > > > in > > > > > > which it requires basic auth support > > > > > > (http://docs.oasis-open.org/s-ramp/s-ramp/v1.0/s-ramp-v1.0-part2-atom-binding.html > > > > > > section 5 "The S-RAMP Specification does not attempt to define a > > > > > > security > > > > > > model for products that implement it. For the Atom Binding, the > > > > > > only > > > > > > security requirement is that at a minimum, client and server > > > > > > implementations MUST be capable of being configured to use HTTP > > > > > > Basic > > > > > > Authentication in conjunction with a connection made with TLS."). > > > > > > > > > > > > However we also need the same service to support bearer token, for > > > > > > use > > > > > > within our KeyCloak SSO session. > > > > > > > > > > > > I've implemented a possible solution, details defined on > > > > > > https://issues.jboss.org/browse/KEYCLOAK-861. > > > > > > > > > > > > If this solution is on the right path, I would appreciate any > > > > > > feedback > > > > > > on > > > > > > any changes that might be required before submitting a PR. > > > > > > Currently > > > > > > there > > > > > > are no tests, but would aim to provide some with the PR. > > > > > > > > > > > > Regards > > > > > > Gary > > > > > > _______________________________________________ > > > > > > keycloak-user mailing list > > > > > > keycloak-user at lists.jboss.org > > > > > > https://lists.jboss.org/mailman/listinfo/keycloak-user > > > > > > > > > > > > > > _______________________________________________ > > > > keycloak-user mailing list > > > > keycloak-user at lists.jboss.org > > > > https://lists.jboss.org/mailman/listinfo/keycloak-user > > > > > > > > > > From stian at redhat.com Thu Nov 27 09:20:22 2014 From: stian at redhat.com (Stian Thorgersen) Date: Thu, 27 Nov 2014 09:20:22 -0500 (EST) Subject: [keycloak-user] REST services supporting basic auth and bearer tokens In-Reply-To: <4705717.15181747.1417096786699.JavaMail.zimbra@redhat.com> References: <648294658.14664021.1417010058756.JavaMail.zimbra@redhat.com> <5476F2ED.60401@redhat.com> <1011678021.15105884.1417082301249.JavaMail.zimbra@redhat.com> <96258862.6486814.1417086369447.JavaMail.zimbra@redhat.com> <1676107994.15149522.1417092535843.JavaMail.zimbra@redhat.com> <1607831918.6553021.1417092843731.JavaMail.zimbra@redhat.com> <4705717.15181747.1417096786699.JavaMail.zimbra@redhat.com> Message-ID: <560122619.6615545.1417098022956.JavaMail.zimbra@redhat.com> Another option is to add a separate basic example outside of the demo, like what was done for multi-tenancy. A single jax-rs endpoint that supports basic auth and an example curl command to invoke it? ----- Original Message ----- > From: "Gary Brown" > To: "Stian Thorgersen" > Cc: "Marek Posolda" , keycloak-user at lists.jboss.org > Sent: Thursday, 27 November, 2014 2:59:46 PM > Subject: Re: [keycloak-user] REST services supporting basic auth and bearer tokens > > In terms of example, was thinking the database-service is ideal - however I'm > guessing it also needs to be shown as a 'bearer-only' example (as now). > > In the same way that there is multiple customer-apps, one approach could be > to have an alternate database-service supporting basic auth as well, but > then would also need a separate copy of the testrealm.json. > > Thoughts? > > ----- Original Message ----- > > Great, if you do a PR include an example we can merge it before a > > 1.1.0.Beta2 > > release (probably next week) > > > > ----- Original Message ----- > > > From: "Gary Brown" > > > To: "Stian Thorgersen" > > > Cc: "Marek Posolda" , keycloak-user at lists.jboss.org > > > Sent: Thursday, 27 November, 2014 1:48:55 PM > > > Subject: Re: [keycloak-user] REST services supporting basic auth and > > > bearer > > > tokens > > > > > > > > > > > > ----- Original Message ----- > > > > Looks good to me, but I'd like it to be an optional feature that is > > > > enabled > > > > in keycloak.json (should be disabled by default). > > > > > > Sounds reasonable - I'll call the property 'enableBasicAuth'. > > > > > > > > > > > Another thing is that we should add an example + documentation for this > > > > feature. > > > > > > Will do. > > > > > > > > > > > ----- Original Message ----- > > > > > From: "Gary Brown" > > > > > To: "Marek Posolda" > > > > > Cc: keycloak-user at lists.jboss.org > > > > > Sent: Thursday, 27 November, 2014 10:58:21 AM > > > > > Subject: Re: [keycloak-user] REST services supporting basic auth and > > > > > bearer > > > > > tokens > > > > > > > > > > Hi Marek > > > > > > > > > > ----- Original Message ----- > > > > > > Hi, > > > > > > > > > > > > I am not 100% sure if having basic auth with direct grant directly > > > > > > in > > > > > > our adapters is way to go. Probably yes as for your use-case it > > > > > > makes > > > > > > sense, so I am slightly for push your change as PR. But maybe > > > > > > others > > > > > > from team have different opinion. > > > > > > > > > > > > Earlier this week I've added DirectAccessGrantsLoginModule to KC > > > > > > codebase, which is quite similar and is intended to be used for > > > > > > non-web > > > > > > applications (like SSH), which rely on JAAS. But I guess that using > > > > > > this > > > > > > one is not good option for you as you want support for Basic and > > > > > > Bearer > > > > > > authentication in same web application, right? > > > > > > > > > > Thats correct. > > > > > > > > > > > > > > > > > Few more minor points to your changes: > > > > > > - Is it possible to use net.iharder.Base64 instead of > > > > > > org.apache.commons.codec.binary.Base64? Whole KC code has > > > > > > dependency > > > > > > on > > > > > > net.iharder, so would be likely better to use this one to avoid > > > > > > possible > > > > > > dependency issues in adapters. > > > > > > > > > > That shouldn't be a problem. > > > > > > > > > > > > > > > > > - Wonder if it's possible to simplify a bit, like have single > > > > > > "completeAuthentication" method for both bearer and basic > > > > > > authenticator > > > > > > (afaik only difference among them is different authMethod right?). > > > > > > But > > > > > > this is really minor. > > > > > > > > > > Will do. > > > > > > > > > > I'll wait until mid next week before doing any more on this, to see > > > > > whether > > > > > others have an opinion. > > > > > > > > > > If the PR was accepted, any chance it could go into 1.1 even though > > > > > in > > > > > beta? > > > > > If no, any idea what the timescale is for 1.2.beta1? > > > > > > > > > > Thanks for your feedback. > > > > > > > > > > Regards > > > > > Gary > > > > > > > > > > > > > > > > > Marek > > > > > > > > > > > > On 26.11.2014 14:54, Gary Brown wrote: > > > > > > > Hi > > > > > > > > > > > > > > Concrete use case - we have implemented the OASIS S-RAMP > > > > > > > specification, > > > > > > > in > > > > > > > which it requires basic auth support > > > > > > > (http://docs.oasis-open.org/s-ramp/s-ramp/v1.0/s-ramp-v1.0-part2-atom-binding.html > > > > > > > section 5 "The S-RAMP Specification does not attempt to define a > > > > > > > security > > > > > > > model for products that implement it. For the Atom Binding, the > > > > > > > only > > > > > > > security requirement is that at a minimum, client and server > > > > > > > implementations MUST be capable of being configured to use HTTP > > > > > > > Basic > > > > > > > Authentication in conjunction with a connection made with TLS."). > > > > > > > > > > > > > > However we also need the same service to support bearer token, > > > > > > > for > > > > > > > use > > > > > > > within our KeyCloak SSO session. > > > > > > > > > > > > > > I've implemented a possible solution, details defined on > > > > > > > https://issues.jboss.org/browse/KEYCLOAK-861. > > > > > > > > > > > > > > If this solution is on the right path, I would appreciate any > > > > > > > feedback > > > > > > > on > > > > > > > any changes that might be required before submitting a PR. > > > > > > > Currently > > > > > > > there > > > > > > > are no tests, but would aim to provide some with the PR. > > > > > > > > > > > > > > Regards > > > > > > > Gary > > > > > > > _______________________________________________ > > > > > > > keycloak-user mailing list > > > > > > > keycloak-user at lists.jboss.org > > > > > > > https://lists.jboss.org/mailman/listinfo/keycloak-user > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > keycloak-user mailing list > > > > > keycloak-user at lists.jboss.org > > > > > https://lists.jboss.org/mailman/listinfo/keycloak-user > > > > > > > > > > > > > > > From gbrown at redhat.com Thu Nov 27 09:26:11 2014 From: gbrown at redhat.com (Gary Brown) Date: Thu, 27 Nov 2014 09:26:11 -0500 (EST) Subject: [keycloak-user] REST services supporting basic auth and bearer tokens In-Reply-To: <560122619.6615545.1417098022956.JavaMail.zimbra@redhat.com> References: <648294658.14664021.1417010058756.JavaMail.zimbra@redhat.com> <5476F2ED.60401@redhat.com> <1011678021.15105884.1417082301249.JavaMail.zimbra@redhat.com> <96258862.6486814.1417086369447.JavaMail.zimbra@redhat.com> <1676107994.15149522.1417092535843.JavaMail.zimbra@redhat.com> <1607831918.6553021.1417092843731.JavaMail.zimbra@redhat.com> <4705717.15181747.1417096786699.JavaMail.zimbra@redhat.com> <560122619.6615545.1417098022956.JavaMail.zimbra@redhat.com> Message-ID: <602281263.15207272.1417098371862.JavaMail.zimbra@redhat.com> Ok sounds good. ----- Original Message ----- > Another option is to add a separate basic example outside of the demo, like > what was done for multi-tenancy. A single jax-rs endpoint that supports > basic auth and an example curl command to invoke it? > > ----- Original Message ----- > > From: "Gary Brown" > > To: "Stian Thorgersen" > > Cc: "Marek Posolda" , keycloak-user at lists.jboss.org > > Sent: Thursday, 27 November, 2014 2:59:46 PM > > Subject: Re: [keycloak-user] REST services supporting basic auth and bearer > > tokens > > > > In terms of example, was thinking the database-service is ideal - however > > I'm > > guessing it also needs to be shown as a 'bearer-only' example (as now). > > > > In the same way that there is multiple customer-apps, one approach could be > > to have an alternate database-service supporting basic auth as well, but > > then would also need a separate copy of the testrealm.json. > > > > Thoughts? > > > > ----- Original Message ----- > > > Great, if you do a PR include an example we can merge it before a > > > 1.1.0.Beta2 > > > release (probably next week) > > > > > > ----- Original Message ----- > > > > From: "Gary Brown" > > > > To: "Stian Thorgersen" > > > > Cc: "Marek Posolda" , > > > > keycloak-user at lists.jboss.org > > > > Sent: Thursday, 27 November, 2014 1:48:55 PM > > > > Subject: Re: [keycloak-user] REST services supporting basic auth and > > > > bearer > > > > tokens > > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > Looks good to me, but I'd like it to be an optional feature that is > > > > > enabled > > > > > in keycloak.json (should be disabled by default). > > > > > > > > Sounds reasonable - I'll call the property 'enableBasicAuth'. > > > > > > > > > > > > > > Another thing is that we should add an example + documentation for > > > > > this > > > > > feature. > > > > > > > > Will do. > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > From: "Gary Brown" > > > > > > To: "Marek Posolda" > > > > > > Cc: keycloak-user at lists.jboss.org > > > > > > Sent: Thursday, 27 November, 2014 10:58:21 AM > > > > > > Subject: Re: [keycloak-user] REST services supporting basic auth > > > > > > and > > > > > > bearer > > > > > > tokens > > > > > > > > > > > > Hi Marek > > > > > > > > > > > > ----- Original Message ----- > > > > > > > Hi, > > > > > > > > > > > > > > I am not 100% sure if having basic auth with direct grant > > > > > > > directly > > > > > > > in > > > > > > > our adapters is way to go. Probably yes as for your use-case it > > > > > > > makes > > > > > > > sense, so I am slightly for push your change as PR. But maybe > > > > > > > others > > > > > > > from team have different opinion. > > > > > > > > > > > > > > Earlier this week I've added DirectAccessGrantsLoginModule to KC > > > > > > > codebase, which is quite similar and is intended to be used for > > > > > > > non-web > > > > > > > applications (like SSH), which rely on JAAS. But I guess that > > > > > > > using > > > > > > > this > > > > > > > one is not good option for you as you want support for Basic and > > > > > > > Bearer > > > > > > > authentication in same web application, right? > > > > > > > > > > > > Thats correct. > > > > > > > > > > > > > > > > > > > > Few more minor points to your changes: > > > > > > > - Is it possible to use net.iharder.Base64 instead of > > > > > > > org.apache.commons.codec.binary.Base64? Whole KC code has > > > > > > > dependency > > > > > > > on > > > > > > > net.iharder, so would be likely better to use this one to avoid > > > > > > > possible > > > > > > > dependency issues in adapters. > > > > > > > > > > > > That shouldn't be a problem. > > > > > > > > > > > > > > > > > > > > - Wonder if it's possible to simplify a bit, like have single > > > > > > > "completeAuthentication" method for both bearer and basic > > > > > > > authenticator > > > > > > > (afaik only difference among them is different authMethod > > > > > > > right?). > > > > > > > But > > > > > > > this is really minor. > > > > > > > > > > > > Will do. > > > > > > > > > > > > I'll wait until mid next week before doing any more on this, to see > > > > > > whether > > > > > > others have an opinion. > > > > > > > > > > > > If the PR was accepted, any chance it could go into 1.1 even though > > > > > > in > > > > > > beta? > > > > > > If no, any idea what the timescale is for 1.2.beta1? > > > > > > > > > > > > Thanks for your feedback. > > > > > > > > > > > > Regards > > > > > > Gary > > > > > > > > > > > > > > > > > > > > Marek > > > > > > > > > > > > > > On 26.11.2014 14:54, Gary Brown wrote: > > > > > > > > Hi > > > > > > > > > > > > > > > > Concrete use case - we have implemented the OASIS S-RAMP > > > > > > > > specification, > > > > > > > > in > > > > > > > > which it requires basic auth support > > > > > > > > (http://docs.oasis-open.org/s-ramp/s-ramp/v1.0/s-ramp-v1.0-part2-atom-binding.html > > > > > > > > section 5 "The S-RAMP Specification does not attempt to define > > > > > > > > a > > > > > > > > security > > > > > > > > model for products that implement it. For the Atom Binding, > > > > > > > > the > > > > > > > > only > > > > > > > > security requirement is that at a minimum, client and server > > > > > > > > implementations MUST be capable of being configured to use HTTP > > > > > > > > Basic > > > > > > > > Authentication in conjunction with a connection made with > > > > > > > > TLS."). > > > > > > > > > > > > > > > > However we also need the same service to support bearer token, > > > > > > > > for > > > > > > > > use > > > > > > > > within our KeyCloak SSO session. > > > > > > > > > > > > > > > > I've implemented a possible solution, details defined on > > > > > > > > https://issues.jboss.org/browse/KEYCLOAK-861. > > > > > > > > > > > > > > > > If this solution is on the right path, I would appreciate any > > > > > > > > feedback > > > > > > > > on > > > > > > > > any changes that might be required before submitting a PR. > > > > > > > > Currently > > > > > > > > there > > > > > > > > are no tests, but would aim to provide some with the PR. > > > > > > > > > > > > > > > > Regards > > > > > > > > Gary > > > > > > > > _______________________________________________ > > > > > > > > keycloak-user mailing list > > > > > > > > keycloak-user at lists.jboss.org > > > > > > > > https://lists.jboss.org/mailman/listinfo/keycloak-user > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > keycloak-user mailing list > > > > > > keycloak-user at lists.jboss.org > > > > > > https://lists.jboss.org/mailman/listinfo/keycloak-user > > > > > > > > > > > > > > > > > > > > > From mposolda at redhat.com Thu Nov 27 09:27:13 2014 From: mposolda at redhat.com (Marek Posolda) Date: Thu, 27 Nov 2014 15:27:13 +0100 Subject: [keycloak-user] REST services supporting basic auth and bearer tokens In-Reply-To: <4705717.15181747.1417096786699.JavaMail.zimbra@redhat.com> References: <648294658.14664021.1417010058756.JavaMail.zimbra@redhat.com> <5476F2ED.60401@redhat.com> <1011678021.15105884.1417082301249.JavaMail.zimbra@redhat.com> <96258862.6486814.1417086369447.JavaMail.zimbra@redhat.com> <1676107994.15149522.1417092535843.JavaMail.zimbra@redhat.com> <1607831918.6553021.1417092843731.JavaMail.zimbra@redhat.com> <4705717.15181747.1417096786699.JavaMail.zimbra@redhat.com> Message-ID: <547734C1.9080408@redhat.com> Your patch allows to both bearer and basic in single application, so maybe just enable-basic-auth for database-service and then it can be accessed from both 'bearer' and 'basic' requests? No need to add another variant of database-service then? For UI, it may be possible to create example like 'customer-portal-basic-auth' or something like that, which will be same like customer-portal, but just access customers via 'Basic auth' request. Or maybe it's also possible to just extend existing example instead of adding new one (like just add new JSP page to existing example, which will access customers via basic request). Maybe add new example (customer-portal-basic-auth) is slightly better option.. Marek On 27.11.2014 14:59, Gary Brown wrote: > In terms of example, was thinking the database-service is ideal - however I'm guessing it also needs to be shown as a 'bearer-only' example (as now). > > In the same way that there is multiple customer-apps, one approach could be to have an alternate database-service supporting basic auth as well, but then would also need a separate copy of the testrealm.json. > > Thoughts? > > ----- Original Message ----- >> Great, if you do a PR include an example we can merge it before a 1.1.0.Beta2 >> release (probably next week) >> >> ----- Original Message ----- >>> From: "Gary Brown" >>> To: "Stian Thorgersen" >>> Cc: "Marek Posolda" , keycloak-user at lists.jboss.org >>> Sent: Thursday, 27 November, 2014 1:48:55 PM >>> Subject: Re: [keycloak-user] REST services supporting basic auth and bearer >>> tokens >>> >>> >>> >>> ----- Original Message ----- >>>> Looks good to me, but I'd like it to be an optional feature that is >>>> enabled >>>> in keycloak.json (should be disabled by default). >>> Sounds reasonable - I'll call the property 'enableBasicAuth'. >>> >>>> Another thing is that we should add an example + documentation for this >>>> feature. >>> Will do. >>> >>>> ----- Original Message ----- >>>>> From: "Gary Brown" >>>>> To: "Marek Posolda" >>>>> Cc: keycloak-user at lists.jboss.org >>>>> Sent: Thursday, 27 November, 2014 10:58:21 AM >>>>> Subject: Re: [keycloak-user] REST services supporting basic auth and >>>>> bearer >>>>> tokens >>>>> >>>>> Hi Marek >>>>> >>>>> ----- Original Message ----- >>>>>> Hi, >>>>>> >>>>>> I am not 100% sure if having basic auth with direct grant directly in >>>>>> our adapters is way to go. Probably yes as for your use-case it makes >>>>>> sense, so I am slightly for push your change as PR. But maybe others >>>>>> from team have different opinion. >>>>>> >>>>>> Earlier this week I've added DirectAccessGrantsLoginModule to KC >>>>>> codebase, which is quite similar and is intended to be used for >>>>>> non-web >>>>>> applications (like SSH), which rely on JAAS. But I guess that using >>>>>> this >>>>>> one is not good option for you as you want support for Basic and >>>>>> Bearer >>>>>> authentication in same web application, right? >>>>> Thats correct. >>>>> >>>>>> Few more minor points to your changes: >>>>>> - Is it possible to use net.iharder.Base64 instead of >>>>>> org.apache.commons.codec.binary.Base64? Whole KC code has dependency >>>>>> on >>>>>> net.iharder, so would be likely better to use this one to avoid >>>>>> possible >>>>>> dependency issues in adapters. >>>>> That shouldn't be a problem. >>>>> >>>>>> - Wonder if it's possible to simplify a bit, like have single >>>>>> "completeAuthentication" method for both bearer and basic >>>>>> authenticator >>>>>> (afaik only difference among them is different authMethod right?). >>>>>> But >>>>>> this is really minor. >>>>> Will do. >>>>> >>>>> I'll wait until mid next week before doing any more on this, to see >>>>> whether >>>>> others have an opinion. >>>>> >>>>> If the PR was accepted, any chance it could go into 1.1 even though in >>>>> beta? >>>>> If no, any idea what the timescale is for 1.2.beta1? >>>>> >>>>> Thanks for your feedback. >>>>> >>>>> Regards >>>>> Gary >>>>> >>>>>> Marek >>>>>> >>>>>> On 26.11.2014 14:54, Gary Brown wrote: >>>>>>> Hi >>>>>>> >>>>>>> Concrete use case - we have implemented the OASIS S-RAMP >>>>>>> specification, >>>>>>> in >>>>>>> which it requires basic auth support >>>>>>> (http://docs.oasis-open.org/s-ramp/s-ramp/v1.0/s-ramp-v1.0-part2-atom-binding.html >>>>>>> section 5 "The S-RAMP Specification does not attempt to define a >>>>>>> security >>>>>>> model for products that implement it. For the Atom Binding, the >>>>>>> only >>>>>>> security requirement is that at a minimum, client and server >>>>>>> implementations MUST be capable of being configured to use HTTP >>>>>>> Basic >>>>>>> Authentication in conjunction with a connection made with TLS."). >>>>>>> >>>>>>> However we also need the same service to support bearer token, for >>>>>>> use >>>>>>> within our KeyCloak SSO session. >>>>>>> >>>>>>> I've implemented a possible solution, details defined on >>>>>>> https://issues.jboss.org/browse/KEYCLOAK-861. >>>>>>> >>>>>>> If this solution is on the right path, I would appreciate any >>>>>>> feedback >>>>>>> on >>>>>>> any changes that might be required before submitting a PR. >>>>>>> Currently >>>>>>> there >>>>>>> are no tests, but would aim to provide some with the PR. >>>>>>> >>>>>>> Regards >>>>>>> Gary >>>>>>> _______________________________________________ >>>>>>> keycloak-user mailing list >>>>>>> keycloak-user at lists.jboss.org >>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-user >>>>>> >>>>> _______________________________________________ >>>>> keycloak-user mailing list >>>>> keycloak-user at lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/keycloak-user >>>>> From mposolda at redhat.com Thu Nov 27 09:31:11 2014 From: mposolda at redhat.com (Marek Posolda) Date: Thu, 27 Nov 2014 15:31:11 +0100 Subject: [keycloak-user] REST services supporting basic auth and bearer tokens In-Reply-To: <602281263.15207272.1417098371862.JavaMail.zimbra@redhat.com> References: <648294658.14664021.1417010058756.JavaMail.zimbra@redhat.com> <5476F2ED.60401@redhat.com> <1011678021.15105884.1417082301249.JavaMail.zimbra@redhat.com> <96258862.6486814.1417086369447.JavaMail.zimbra@redhat.com> <1676107994.15149522.1417092535843.JavaMail.zimbra@redhat.com> <1607831918.6553021.1417092843731.JavaMail.zimbra@redhat.com> <4705717.15181747.1417096786699.JavaMail.zimbra@redhat.com> <560122619.6615545.1417098022956.JavaMail.zimbra@redhat.com> <602281263.15207272.1417098371862.JavaMail.zimbra@redhat.com> Message-ID: <547735AF.90608@redhat.com> Sent previous email before I figured that you guys already decide on something, so feel free to ignore me:-) On the other hand, it may be nice to show in the example that particular jaxrs endpoint is able to support both bearer and basic auth in same application imo. Marek On 27.11.2014 15:26, Gary Brown wrote: > Ok sounds good. > > ----- Original Message ----- >> Another option is to add a separate basic example outside of the demo, like >> what was done for multi-tenancy. A single jax-rs endpoint that supports >> basic auth and an example curl command to invoke it? >> >> ----- Original Message ----- >>> From: "Gary Brown" >>> To: "Stian Thorgersen" >>> Cc: "Marek Posolda" , keycloak-user at lists.jboss.org >>> Sent: Thursday, 27 November, 2014 2:59:46 PM >>> Subject: Re: [keycloak-user] REST services supporting basic auth and bearer >>> tokens >>> >>> In terms of example, was thinking the database-service is ideal - however >>> I'm >>> guessing it also needs to be shown as a 'bearer-only' example (as now). >>> >>> In the same way that there is multiple customer-apps, one approach could be >>> to have an alternate database-service supporting basic auth as well, but >>> then would also need a separate copy of the testrealm.json. >>> >>> Thoughts? >>> >>> ----- Original Message ----- >>>> Great, if you do a PR include an example we can merge it before a >>>> 1.1.0.Beta2 >>>> release (probably next week) >>>> >>>> ----- Original Message ----- >>>>> From: "Gary Brown" >>>>> To: "Stian Thorgersen" >>>>> Cc: "Marek Posolda" , >>>>> keycloak-user at lists.jboss.org >>>>> Sent: Thursday, 27 November, 2014 1:48:55 PM >>>>> Subject: Re: [keycloak-user] REST services supporting basic auth and >>>>> bearer >>>>> tokens >>>>> >>>>> >>>>> >>>>> ----- Original Message ----- >>>>>> Looks good to me, but I'd like it to be an optional feature that is >>>>>> enabled >>>>>> in keycloak.json (should be disabled by default). >>>>> Sounds reasonable - I'll call the property 'enableBasicAuth'. >>>>> >>>>>> Another thing is that we should add an example + documentation for >>>>>> this >>>>>> feature. >>>>> Will do. >>>>> >>>>>> ----- Original Message ----- >>>>>>> From: "Gary Brown" >>>>>>> To: "Marek Posolda" >>>>>>> Cc: keycloak-user at lists.jboss.org >>>>>>> Sent: Thursday, 27 November, 2014 10:58:21 AM >>>>>>> Subject: Re: [keycloak-user] REST services supporting basic auth >>>>>>> and >>>>>>> bearer >>>>>>> tokens >>>>>>> >>>>>>> Hi Marek >>>>>>> >>>>>>> ----- Original Message ----- >>>>>>>> Hi, >>>>>>>> >>>>>>>> I am not 100% sure if having basic auth with direct grant >>>>>>>> directly >>>>>>>> in >>>>>>>> our adapters is way to go. Probably yes as for your use-case it >>>>>>>> makes >>>>>>>> sense, so I am slightly for push your change as PR. But maybe >>>>>>>> others >>>>>>>> from team have different opinion. >>>>>>>> >>>>>>>> Earlier this week I've added DirectAccessGrantsLoginModule to KC >>>>>>>> codebase, which is quite similar and is intended to be used for >>>>>>>> non-web >>>>>>>> applications (like SSH), which rely on JAAS. But I guess that >>>>>>>> using >>>>>>>> this >>>>>>>> one is not good option for you as you want support for Basic and >>>>>>>> Bearer >>>>>>>> authentication in same web application, right? >>>>>>> Thats correct. >>>>>>> >>>>>>>> Few more minor points to your changes: >>>>>>>> - Is it possible to use net.iharder.Base64 instead of >>>>>>>> org.apache.commons.codec.binary.Base64? Whole KC code has >>>>>>>> dependency >>>>>>>> on >>>>>>>> net.iharder, so would be likely better to use this one to avoid >>>>>>>> possible >>>>>>>> dependency issues in adapters. >>>>>>> That shouldn't be a problem. >>>>>>> >>>>>>>> - Wonder if it's possible to simplify a bit, like have single >>>>>>>> "completeAuthentication" method for both bearer and basic >>>>>>>> authenticator >>>>>>>> (afaik only difference among them is different authMethod >>>>>>>> right?). >>>>>>>> But >>>>>>>> this is really minor. >>>>>>> Will do. >>>>>>> >>>>>>> I'll wait until mid next week before doing any more on this, to see >>>>>>> whether >>>>>>> others have an opinion. >>>>>>> >>>>>>> If the PR was accepted, any chance it could go into 1.1 even though >>>>>>> in >>>>>>> beta? >>>>>>> If no, any idea what the timescale is for 1.2.beta1? >>>>>>> >>>>>>> Thanks for your feedback. >>>>>>> >>>>>>> Regards >>>>>>> Gary >>>>>>> >>>>>>>> Marek >>>>>>>> >>>>>>>> On 26.11.2014 14:54, Gary Brown wrote: >>>>>>>>> Hi >>>>>>>>> >>>>>>>>> Concrete use case - we have implemented the OASIS S-RAMP >>>>>>>>> specification, >>>>>>>>> in >>>>>>>>> which it requires basic auth support >>>>>>>>> (http://docs.oasis-open.org/s-ramp/s-ramp/v1.0/s-ramp-v1.0-part2-atom-binding.html >>>>>>>>> section 5 "The S-RAMP Specification does not attempt to define >>>>>>>>> a >>>>>>>>> security >>>>>>>>> model for products that implement it. For the Atom Binding, >>>>>>>>> the >>>>>>>>> only >>>>>>>>> security requirement is that at a minimum, client and server >>>>>>>>> implementations MUST be capable of being configured to use HTTP >>>>>>>>> Basic >>>>>>>>> Authentication in conjunction with a connection made with >>>>>>>>> TLS."). >>>>>>>>> >>>>>>>>> However we also need the same service to support bearer token, >>>>>>>>> for >>>>>>>>> use >>>>>>>>> within our KeyCloak SSO session. >>>>>>>>> >>>>>>>>> I've implemented a possible solution, details defined on >>>>>>>>> https://issues.jboss.org/browse/KEYCLOAK-861. >>>>>>>>> >>>>>>>>> If this solution is on the right path, I would appreciate any >>>>>>>>> feedback >>>>>>>>> on >>>>>>>>> any changes that might be required before submitting a PR. >>>>>>>>> Currently >>>>>>>>> there >>>>>>>>> are no tests, but would aim to provide some with the PR. >>>>>>>>> >>>>>>>>> Regards >>>>>>>>> Gary >>>>>>>>> _______________________________________________ >>>>>>>>> keycloak-user mailing list >>>>>>>>> keycloak-user at lists.jboss.org >>>>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-user >>>>>>>> >>>>>>> _______________________________________________ >>>>>>> keycloak-user mailing list >>>>>>> keycloak-user at lists.jboss.org >>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-user >>>>>>> From gbrown at redhat.com Thu Nov 27 09:37:12 2014 From: gbrown at redhat.com (Gary Brown) Date: Thu, 27 Nov 2014 09:37:12 -0500 (EST) Subject: [keycloak-user] REST services supporting basic auth and bearer tokens In-Reply-To: <547735AF.90608@redhat.com> References: <648294658.14664021.1417010058756.JavaMail.zimbra@redhat.com> <96258862.6486814.1417086369447.JavaMail.zimbra@redhat.com> <1676107994.15149522.1417092535843.JavaMail.zimbra@redhat.com> <1607831918.6553021.1417092843731.JavaMail.zimbra@redhat.com> <4705717.15181747.1417096786699.JavaMail.zimbra@redhat.com> <560122619.6615545.1417098022956.JavaMail.zimbra@redhat.com> <602281263.15207272.1417098371862.JavaMail.zimbra@redhat.com> <547735AF.90608@redhat.com> Message-ID: <1308843455.15212297.1417099032933.JavaMail.zimbra@redhat.com> Hi Marek I was originally thinking the same - but it would complicate the demo more. Its possible that the database-service could simply be changed to support both bearer and basic auth, and then provide curl instructions to demonstrate basic auth access, but then there wouldn't be an example showing a bearer-only configuration. So assuming that a 'bearer-only' example is still required, then having a completely independent basic auth example may be the next best thing - and then leave it as an exercise for the user to enable basic auth on the database-service? Regards Gary ----- Original Message ----- > Sent previous email before I figured that you guys already decide on > something, so feel free to ignore me:-) > > On the other hand, it may be nice to show in the example that particular > jaxrs endpoint is able to support both bearer and basic auth in same > application imo. > > Marek > > On 27.11.2014 15:26, Gary Brown wrote: > > Ok sounds good. > > > > ----- Original Message ----- > >> Another option is to add a separate basic example outside of the demo, > >> like > >> what was done for multi-tenancy. A single jax-rs endpoint that supports > >> basic auth and an example curl command to invoke it? > >> > >> ----- Original Message ----- > >>> From: "Gary Brown" > >>> To: "Stian Thorgersen" > >>> Cc: "Marek Posolda" , keycloak-user at lists.jboss.org > >>> Sent: Thursday, 27 November, 2014 2:59:46 PM > >>> Subject: Re: [keycloak-user] REST services supporting basic auth and > >>> bearer > >>> tokens > >>> > >>> In terms of example, was thinking the database-service is ideal - however > >>> I'm > >>> guessing it also needs to be shown as a 'bearer-only' example (as now). > >>> > >>> In the same way that there is multiple customer-apps, one approach could > >>> be > >>> to have an alternate database-service supporting basic auth as well, but > >>> then would also need a separate copy of the testrealm.json. > >>> > >>> Thoughts? > >>> > >>> ----- Original Message ----- > >>>> Great, if you do a PR include an example we can merge it before a > >>>> 1.1.0.Beta2 > >>>> release (probably next week) > >>>> > >>>> ----- Original Message ----- > >>>>> From: "Gary Brown" > >>>>> To: "Stian Thorgersen" > >>>>> Cc: "Marek Posolda" , > >>>>> keycloak-user at lists.jboss.org > >>>>> Sent: Thursday, 27 November, 2014 1:48:55 PM > >>>>> Subject: Re: [keycloak-user] REST services supporting basic auth and > >>>>> bearer > >>>>> tokens > >>>>> > >>>>> > >>>>> > >>>>> ----- Original Message ----- > >>>>>> Looks good to me, but I'd like it to be an optional feature that is > >>>>>> enabled > >>>>>> in keycloak.json (should be disabled by default). > >>>>> Sounds reasonable - I'll call the property 'enableBasicAuth'. > >>>>> > >>>>>> Another thing is that we should add an example + documentation for > >>>>>> this > >>>>>> feature. > >>>>> Will do. > >>>>> > >>>>>> ----- Original Message ----- > >>>>>>> From: "Gary Brown" > >>>>>>> To: "Marek Posolda" > >>>>>>> Cc: keycloak-user at lists.jboss.org > >>>>>>> Sent: Thursday, 27 November, 2014 10:58:21 AM > >>>>>>> Subject: Re: [keycloak-user] REST services supporting basic auth > >>>>>>> and > >>>>>>> bearer > >>>>>>> tokens > >>>>>>> > >>>>>>> Hi Marek > >>>>>>> > >>>>>>> ----- Original Message ----- > >>>>>>>> Hi, > >>>>>>>> > >>>>>>>> I am not 100% sure if having basic auth with direct grant > >>>>>>>> directly > >>>>>>>> in > >>>>>>>> our adapters is way to go. Probably yes as for your use-case it > >>>>>>>> makes > >>>>>>>> sense, so I am slightly for push your change as PR. But maybe > >>>>>>>> others > >>>>>>>> from team have different opinion. > >>>>>>>> > >>>>>>>> Earlier this week I've added DirectAccessGrantsLoginModule to KC > >>>>>>>> codebase, which is quite similar and is intended to be used for > >>>>>>>> non-web > >>>>>>>> applications (like SSH), which rely on JAAS. But I guess that > >>>>>>>> using > >>>>>>>> this > >>>>>>>> one is not good option for you as you want support for Basic and > >>>>>>>> Bearer > >>>>>>>> authentication in same web application, right? > >>>>>>> Thats correct. > >>>>>>> > >>>>>>>> Few more minor points to your changes: > >>>>>>>> - Is it possible to use net.iharder.Base64 instead of > >>>>>>>> org.apache.commons.codec.binary.Base64? Whole KC code has > >>>>>>>> dependency > >>>>>>>> on > >>>>>>>> net.iharder, so would be likely better to use this one to avoid > >>>>>>>> possible > >>>>>>>> dependency issues in adapters. > >>>>>>> That shouldn't be a problem. > >>>>>>> > >>>>>>>> - Wonder if it's possible to simplify a bit, like have single > >>>>>>>> "completeAuthentication" method for both bearer and basic > >>>>>>>> authenticator > >>>>>>>> (afaik only difference among them is different authMethod > >>>>>>>> right?). > >>>>>>>> But > >>>>>>>> this is really minor. > >>>>>>> Will do. > >>>>>>> > >>>>>>> I'll wait until mid next week before doing any more on this, to see > >>>>>>> whether > >>>>>>> others have an opinion. > >>>>>>> > >>>>>>> If the PR was accepted, any chance it could go into 1.1 even though > >>>>>>> in > >>>>>>> beta? > >>>>>>> If no, any idea what the timescale is for 1.2.beta1? > >>>>>>> > >>>>>>> Thanks for your feedback. > >>>>>>> > >>>>>>> Regards > >>>>>>> Gary > >>>>>>> > >>>>>>>> Marek > >>>>>>>> > >>>>>>>> On 26.11.2014 14:54, Gary Brown wrote: > >>>>>>>>> Hi > >>>>>>>>> > >>>>>>>>> Concrete use case - we have implemented the OASIS S-RAMP > >>>>>>>>> specification, > >>>>>>>>> in > >>>>>>>>> which it requires basic auth support > >>>>>>>>> (http://docs.oasis-open.org/s-ramp/s-ramp/v1.0/s-ramp-v1.0-part2-atom-binding.html > >>>>>>>>> section 5 "The S-RAMP Specification does not attempt to define > >>>>>>>>> a > >>>>>>>>> security > >>>>>>>>> model for products that implement it. For the Atom Binding, > >>>>>>>>> the > >>>>>>>>> only > >>>>>>>>> security requirement is that at a minimum, client and server > >>>>>>>>> implementations MUST be capable of being configured to use HTTP > >>>>>>>>> Basic > >>>>>>>>> Authentication in conjunction with a connection made with > >>>>>>>>> TLS."). > >>>>>>>>> > >>>>>>>>> However we also need the same service to support bearer token, > >>>>>>>>> for > >>>>>>>>> use > >>>>>>>>> within our KeyCloak SSO session. > >>>>>>>>> > >>>>>>>>> I've implemented a possible solution, details defined on > >>>>>>>>> https://issues.jboss.org/browse/KEYCLOAK-861. > >>>>>>>>> > >>>>>>>>> If this solution is on the right path, I would appreciate any > >>>>>>>>> feedback > >>>>>>>>> on > >>>>>>>>> any changes that might be required before submitting a PR. > >>>>>>>>> Currently > >>>>>>>>> there > >>>>>>>>> are no tests, but would aim to provide some with the PR. > >>>>>>>>> > >>>>>>>>> Regards > >>>>>>>>> Gary > >>>>>>>>> _______________________________________________ > >>>>>>>>> keycloak-user mailing list > >>>>>>>>> keycloak-user at lists.jboss.org > >>>>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-user > >>>>>>>> > >>>>>>> _______________________________________________ > >>>>>>> keycloak-user mailing list > >>>>>>> keycloak-user at lists.jboss.org > >>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-user > >>>>>>> > > From rubenlop88 at gmail.com Thu Nov 27 10:21:15 2014 From: rubenlop88 at gmail.com (Ruben Lopez) Date: Thu, 27 Nov 2014 12:21:15 -0300 Subject: [keycloak-user] Questions about keycloak Message-ID: Hi, Our organization is currently evaluating the use of Keycloak and we have some questions: 1 - Is there any way to obtain an access token for an OAuth Client via Client Credentials[1]? 2 - If we make a request to an Application (Resource Server) with an access token and this Application needs to talk to another protected Application to form the response to the client, how does the first Application authenticates to the second Application? Does Keycloak implements something like Chain Grant Type Profile[2]? Thanks in advance. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20141127/363172cd/attachment-0001.html From mposolda at redhat.com Thu Nov 27 10:22:23 2014 From: mposolda at redhat.com (Marek Posolda) Date: Thu, 27 Nov 2014 16:22:23 +0100 Subject: [keycloak-user] REST services supporting basic auth and bearer tokens In-Reply-To: <1308843455.15212297.1417099032933.JavaMail.zimbra@redhat.com> References: <648294658.14664021.1417010058756.JavaMail.zimbra@redhat.com> <96258862.6486814.1417086369447.JavaMail.zimbra@redhat.com> <1676107994.15149522.1417092535843.JavaMail.zimbra@redhat.com> <1607831918.6553021.1417092843731.JavaMail.zimbra@redhat.com> <4705717.15181747.1417096786699.JavaMail.zimbra@redhat.com> <560122619.6615545.1417098022956.JavaMail.zimbra@redhat.com> <602281263.15207272.1417098371862.JavaMail.zimbra@redhat.com> <547735AF.90608@redhat.com> <1308843455.15212297.1417099032933.JavaMail.zimbra@redhat.com> Message-ID: <547741AF.1000606@redhat.com> Oki, sounds good to me. Marek On 27.11.2014 15:37, Gary Brown wrote: > Hi Marek > > I was originally thinking the same - but it would complicate the demo more. > > Its possible that the database-service could simply be changed to support both bearer and basic auth, and then provide curl instructions to demonstrate basic auth access, but then there wouldn't be an example showing a bearer-only configuration. > > So assuming that a 'bearer-only' example is still required, then having a completely independent basic auth example may be the next best thing - and then leave it as an exercise for the user to enable basic auth on the database-service? > > Regards > Gary > > ----- Original Message ----- >> Sent previous email before I figured that you guys already decide on >> something, so feel free to ignore me:-) >> >> On the other hand, it may be nice to show in the example that particular >> jaxrs endpoint is able to support both bearer and basic auth in same >> application imo. >> >> Marek >> >> On 27.11.2014 15:26, Gary Brown wrote: >>> Ok sounds good. >>> >>> ----- Original Message ----- >>>> Another option is to add a separate basic example outside of the demo, >>>> like >>>> what was done for multi-tenancy. A single jax-rs endpoint that supports >>>> basic auth and an example curl command to invoke it? >>>> >>>> ----- Original Message ----- >>>>> From: "Gary Brown" >>>>> To: "Stian Thorgersen" >>>>> Cc: "Marek Posolda" , keycloak-user at lists.jboss.org >>>>> Sent: Thursday, 27 November, 2014 2:59:46 PM >>>>> Subject: Re: [keycloak-user] REST services supporting basic auth and >>>>> bearer >>>>> tokens >>>>> >>>>> In terms of example, was thinking the database-service is ideal - however >>>>> I'm >>>>> guessing it also needs to be shown as a 'bearer-only' example (as now). >>>>> >>>>> In the same way that there is multiple customer-apps, one approach could >>>>> be >>>>> to have an alternate database-service supporting basic auth as well, but >>>>> then would also need a separate copy of the testrealm.json. >>>>> >>>>> Thoughts? >>>>> >>>>> ----- Original Message ----- >>>>>> Great, if you do a PR include an example we can merge it before a >>>>>> 1.1.0.Beta2 >>>>>> release (probably next week) >>>>>> >>>>>> ----- Original Message ----- >>>>>>> From: "Gary Brown" >>>>>>> To: "Stian Thorgersen" >>>>>>> Cc: "Marek Posolda" , >>>>>>> keycloak-user at lists.jboss.org >>>>>>> Sent: Thursday, 27 November, 2014 1:48:55 PM >>>>>>> Subject: Re: [keycloak-user] REST services supporting basic auth and >>>>>>> bearer >>>>>>> tokens >>>>>>> >>>>>>> >>>>>>> >>>>>>> ----- Original Message ----- >>>>>>>> Looks good to me, but I'd like it to be an optional feature that is >>>>>>>> enabled >>>>>>>> in keycloak.json (should be disabled by default). >>>>>>> Sounds reasonable - I'll call the property 'enableBasicAuth'. >>>>>>> >>>>>>>> Another thing is that we should add an example + documentation for >>>>>>>> this >>>>>>>> feature. >>>>>>> Will do. >>>>>>> >>>>>>>> ----- Original Message ----- >>>>>>>>> From: "Gary Brown" >>>>>>>>> To: "Marek Posolda" >>>>>>>>> Cc: keycloak-user at lists.jboss.org >>>>>>>>> Sent: Thursday, 27 November, 2014 10:58:21 AM >>>>>>>>> Subject: Re: [keycloak-user] REST services supporting basic auth >>>>>>>>> and >>>>>>>>> bearer >>>>>>>>> tokens >>>>>>>>> >>>>>>>>> Hi Marek >>>>>>>>> >>>>>>>>> ----- Original Message ----- >>>>>>>>>> Hi, >>>>>>>>>> >>>>>>>>>> I am not 100% sure if having basic auth with direct grant >>>>>>>>>> directly >>>>>>>>>> in >>>>>>>>>> our adapters is way to go. Probably yes as for your use-case it >>>>>>>>>> makes >>>>>>>>>> sense, so I am slightly for push your change as PR. But maybe >>>>>>>>>> others >>>>>>>>>> from team have different opinion. >>>>>>>>>> >>>>>>>>>> Earlier this week I've added DirectAccessGrantsLoginModule to KC >>>>>>>>>> codebase, which is quite similar and is intended to be used for >>>>>>>>>> non-web >>>>>>>>>> applications (like SSH), which rely on JAAS. But I guess that >>>>>>>>>> using >>>>>>>>>> this >>>>>>>>>> one is not good option for you as you want support for Basic and >>>>>>>>>> Bearer >>>>>>>>>> authentication in same web application, right? >>>>>>>>> Thats correct. >>>>>>>>> >>>>>>>>>> Few more minor points to your changes: >>>>>>>>>> - Is it possible to use net.iharder.Base64 instead of >>>>>>>>>> org.apache.commons.codec.binary.Base64? Whole KC code has >>>>>>>>>> dependency >>>>>>>>>> on >>>>>>>>>> net.iharder, so would be likely better to use this one to avoid >>>>>>>>>> possible >>>>>>>>>> dependency issues in adapters. >>>>>>>>> That shouldn't be a problem. >>>>>>>>> >>>>>>>>>> - Wonder if it's possible to simplify a bit, like have single >>>>>>>>>> "completeAuthentication" method for both bearer and basic >>>>>>>>>> authenticator >>>>>>>>>> (afaik only difference among them is different authMethod >>>>>>>>>> right?). >>>>>>>>>> But >>>>>>>>>> this is really minor. >>>>>>>>> Will do. >>>>>>>>> >>>>>>>>> I'll wait until mid next week before doing any more on this, to see >>>>>>>>> whether >>>>>>>>> others have an opinion. >>>>>>>>> >>>>>>>>> If the PR was accepted, any chance it could go into 1.1 even though >>>>>>>>> in >>>>>>>>> beta? >>>>>>>>> If no, any idea what the timescale is for 1.2.beta1? >>>>>>>>> >>>>>>>>> Thanks for your feedback. >>>>>>>>> >>>>>>>>> Regards >>>>>>>>> Gary >>>>>>>>> >>>>>>>>>> Marek >>>>>>>>>> >>>>>>>>>> On 26.11.2014 14:54, Gary Brown wrote: >>>>>>>>>>> Hi >>>>>>>>>>> >>>>>>>>>>> Concrete use case - we have implemented the OASIS S-RAMP >>>>>>>>>>> specification, >>>>>>>>>>> in >>>>>>>>>>> which it requires basic auth support >>>>>>>>>>> (http://docs.oasis-open.org/s-ramp/s-ramp/v1.0/s-ramp-v1.0-part2-atom-binding.html >>>>>>>>>>> section 5 "The S-RAMP Specification does not attempt to define >>>>>>>>>>> a >>>>>>>>>>> security >>>>>>>>>>> model for products that implement it. For the Atom Binding, >>>>>>>>>>> the >>>>>>>>>>> only >>>>>>>>>>> security requirement is that at a minimum, client and server >>>>>>>>>>> implementations MUST be capable of being configured to use HTTP >>>>>>>>>>> Basic >>>>>>>>>>> Authentication in conjunction with a connection made with >>>>>>>>>>> TLS."). >>>>>>>>>>> >>>>>>>>>>> However we also need the same service to support bearer token, >>>>>>>>>>> for >>>>>>>>>>> use >>>>>>>>>>> within our KeyCloak SSO session. >>>>>>>>>>> >>>>>>>>>>> I've implemented a possible solution, details defined on >>>>>>>>>>> https://issues.jboss.org/browse/KEYCLOAK-861. >>>>>>>>>>> >>>>>>>>>>> If this solution is on the right path, I would appreciate any >>>>>>>>>>> feedback >>>>>>>>>>> on >>>>>>>>>>> any changes that might be required before submitting a PR. >>>>>>>>>>> Currently >>>>>>>>>>> there >>>>>>>>>>> are no tests, but would aim to provide some with the PR. >>>>>>>>>>> >>>>>>>>>>> Regards >>>>>>>>>>> Gary >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> keycloak-user mailing list >>>>>>>>>>> keycloak-user at lists.jboss.org >>>>>>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-user >>>>>>>>> _______________________________________________ >>>>>>>>> keycloak-user mailing list >>>>>>>>> keycloak-user at lists.jboss.org >>>>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-user >>>>>>>>> >> From mposolda at redhat.com Thu Nov 27 10:38:08 2014 From: mposolda at redhat.com (Marek Posolda) Date: Thu, 27 Nov 2014 16:38:08 +0100 Subject: [keycloak-user] Questions about keycloak In-Reply-To: References: Message-ID: <54774560.8050809@redhat.com> Hi, On 27.11.2014 16:21, Ruben Lopez wrote: > Hi, > > Our organization is currently evaluating the use of Keycloak and we > have some questions: > > 1 - Is there any way to obtain an access token for an OAuth Client via > Client Credentials[1]? You mean something like Service account like this from OAuth2 specs http://tools.ietf.org/html/rfc6749#page-40 ? We don't have that yet, but there are plans to support it afaik. > > 2 - If we make a request to an Application (Resource Server) with an > access token and this Application needs to talk to another protected > Application to form the response to the client, how does the first > Application authenticates to the second Application? Does Keycloak > implements something like Chain Grant Type Profile[2]? yes, that is doable. We have an example where we have frontend application like 'customer-portal', which is able to retrieve accessToken from keycloak like here: https://github.com/keycloak/keycloak/blob/master/examples/demo-template/customer-app/src/main/java/org/keycloak/example/CustomerDatabaseClient.java#L48 and then use this accessToken to send request to backend application 'database-service' in Authorization header https://github.com/keycloak/keycloak/blob/master/examples/demo-template/customer-app/src/main/java/org/keycloak/example/CustomerDatabaseClient.java#L54 . Database-service is then able to authenticate the token. Currently our database-service is directly serving requests and send back data, but it shouldn't be a problem to add another application to the chain, so that database-service will send the token again to another app like 'real-database-service', which will return data and those data will be sent back to the original frontent requestor (customer-portal). Is it something what you meant? Marek > > Thanks in advance. > > > _______________________________________________ > 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-user/attachments/20141127/6b1eda09/attachment.html From rubenlop88 at gmail.com Thu Nov 27 11:37:45 2014 From: rubenlop88 at gmail.com (Ruben Lopez) Date: Thu, 27 Nov 2014 13:37:45 -0300 Subject: [keycloak-user] Questions about keycloak In-Reply-To: <54774560.8050809@redhat.com> References: <54774560.8050809@redhat.com> Message-ID: Hi Marek, 2014-11-27 12:38 GMT-03:00 Marek Posolda : > > 1 - Is there any way to obtain an access token for an OAuth Client via > Client Credentials[1]? > > You mean something like Service account like this from OAuth2 specs > http://tools.ietf.org/html/rfc6749#page-40 ? We don't have that yet, but > there are plans to support it afaik. > > > Yes, I was talking about secction 4.4 Client Credentials Grant. Any idea about when it will be implemented? > 2 - If we make a request to an Application (Resource Server) with an > access token and this Application needs to talk to another protected > Application to form the response to the client, how does the first > Application authenticates to the second Application? Does Keycloak > implements something like Chain Grant Type Profile[2]? > > yes, that is doable. We have an example where we have frontend application > like 'customer-portal', which is able to retrieve accessToken from keycloak > like here: > https://github.com/keycloak/keycloak/blob/master/examples/demo-template/customer-app/src/main/java/org/keycloak/example/CustomerDatabaseClient.java#L48 > and then use this accessToken to send request to backend application > 'database-service' in Authorization header > https://github.com/keycloak/keycloak/blob/master/examples/demo-template/customer-app/src/main/java/org/keycloak/example/CustomerDatabaseClient.java#L54 > . Database-service is then able to authenticate the token. > > Currently our database-service is directly serving requests and send back > data, but it shouldn't be a problem to add another application to the > chain, so that database-service will send the token again to another app > like 'real-database-service', which will return data and those data will be > sent back to the original frontent requestor (customer-portal). Is it > something what you meant? > Thats exactly what I meant. I will take a look at the example. Thank you very much. > Marek > > > Thanks in advance. > > > _______________________________________________ > keycloak-user mailing listkeycloak-user at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-user > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20141127/5c731536/attachment.html From afsg77 at gmail.com Thu Nov 27 13:05:07 2014 From: afsg77 at gmail.com (=?UTF-8?Q?Fabi=C3=A1n_Silva?=) Date: Thu, 27 Nov 2014 12:05:07 -0600 Subject: [keycloak-user] Error on application log in In-Reply-To: <1453102381.4076575.1416817786988.JavaMail.zimbra@redhat.com> References: <5465BCF1.6000304@redhat.com> <546CD33B.1020607@redhat.com> <1823273882.2484255.1416471931969.JavaMail.zimbra@redhat.com> <1453102381.4076575.1416817786988.JavaMail.zimbra@redhat.com> Message-ID: I have tried "disable-trust-manager": true, but did not worked. I still get the "403 - Forbidden". I tried also to set the "truststore" : "path/to/truststore.jks" and "truststore-password" : "pass" and also did not worked. The only thing that has worked is to deploy it with a wildfly without the SSL enabled. Is there another thing I can try, to make it worked with a domain wildfly with SSL enabled? Regards On Mon, Nov 24, 2014 at 2:29 AM, Stian Thorgersen wrote: > The options you're after are truststore, truststore-password and > disable-trust-manager, not client-keystore. > > ----- Original Message ----- > > From: "Fabi?n Silva" > > To: "Stian Thorgersen" > > Cc: "Stan Silvert" , keycloak-user at lists.jboss.org > > Sent: Saturday, 22 November, 2014 12:58:16 AM > > Subject: Re: [keycloak-user] Error on application log in > > > > > http://docs.jboss.org/keycloak/docs/1.1.0.Beta1/userguide/html/ch07.html#adapter-config > > "client-keystore > > Not supported yet, but we will support in future versions." > > So if my adapter has SSL enabled is not supported yet? Or how do I > > configure it to work if my adapter has the SSL enabled? > > I tried with an adapter without SSL enabled and the keycloak with the SSL > > enabled and it worked. But when I tried it with both, the adapter and the > > keycloak with SSL enabled, it doesn't work. I got the following logs on > the > > adapter: > > ERROR [org.keycloak.adapters.OAuthRequestAuthenticator] (default task-6) > > failed to turn code into token > > ERROR [org.keycloak.adapters.OAuthRequestAuthenticator] (default task-6) > > status from server: 404 > > > > Regards > > > > On Thu, Nov 20, 2014 at 2:25 AM, Stian Thorgersen > wrote: > > > > > Are there no errors or warning in the server log? Try enabling debug > for > > > org.keycloak and see if there's anything interesting. > > > > > > First thing try the exact same setup (two servers), but without ssl. > > > > > > If that works disable enable ssl, but disable the trust manager in the > > > adapter (disable-trust-manager option on adapter, see > > > > http://docs.jboss.org/keycloak/docs/1.1.0.Beta1/userguide/html/ch07.html#adapter-config > > > ). > > > > > > If it still works create a truststore and import your certificate. Then > > > set truststore and truststore-password on the adapter. > > > > > > ----- Original Message ----- > > > > From: "Fabi?n Silva" > > > > To: "Stan Silvert" > > > > Cc: keycloak-user at lists.jboss.org > > > > Sent: Wednesday, 19 November, 2014 6:35:15 PM > > > > Subject: Re: [keycloak-user] Error on application log in > > > > > > > > I tried deploying it onto a local wildfly in domain without the SSL > > > enabled > > > > and it worked. What I can't figure it out is why the SSL is causing > > > conflict > > > > and how to solve this, I can't simply disable the SSL. > > > > > > > > Regards > > > > > > > > On Wed, Nov 19, 2014 at 11:28 AM, Stan Silvert < ssilvert at redhat.com > > > > > wrote: > > > > > > > > > > > > > > > > Have you tried it using the two servers but without SSL? > > > > > > > > You can set ssl-required to "none" on the adapter (application) side. > > > Also on > > > > the Keycloak server side, try setting Access Type to "public". Do > one of > > > > those at a time and see if either causes it to work. That might > narrow it > > > > down a bit. > > > > > > > > > > > > On 11/19/2014 11:29 AM, Fabi?n Silva wrote: > > > > > > > > > > > > > > > > Hi, > > > > I'm running out of ideas in here. In simple terms I got a Wildfly > > > running on > > > > domain on a server and a keycloak on another server. I set the > adapters > > > on > > > > my wildfly and deploy, to this wildfly, a web app that uses keycloak. > > > When I > > > > try to access the web app it displays the keycloak login, it > validates > > > the > > > > users ok, but when you access with a correct user and password it > shows > > > the > > > > "403 - Forbidden". At first I thought it was some issue with the > roles, > > > but > > > > that didn't fix it. > > > > > > > > Regards > > > > > > > > On Fri, Nov 14, 2014 at 10:20 AM, Fabi?n Silva < afsg77 at gmail.com > > > > wrote: > > > > > > > > > > > > > > > > Hi, > > > > It is already set to use the absolute path. And the keycloak is > working > > > when > > > > I deploy the application to my local wildfly domain. The issue is > when I > > > try > > > > to deploy to another wildfly in domain mode on a separate server. The > > > > application is the same and the only difference I can tell from the > two > > > > wildflys is that the local don't have the SSL/HTTPS enabled. I have > the > > > > keycloak adapter set in both domains. > > > > > > > > I'm trying to trace those errors on the keycloak code to try to > > > understand > > > > what is happening, but I haven't been so lucky with this. > > > > > > > > Regards > > > > Alejandro Fabi?n Silva Grif? > > > > > > > > On Fri, Nov 14, 2014 at 2:27 AM, Marek Posolda < mposolda at redhat.com > > > > > wrote: > > > > > > > > > > > > > > > > Hi, > > > > > > > > it failed on the adapter (application) side and error 404 means "Not > > > found". > > > > So adapter can't find the keycloak server to turn code into token. > Make > > > sure > > > > to configure "auth-server-url" in keycloak.json for your application > > > > properly. If relative uri doesn't work for some reason, you can > rather > > > try > > > > to use absolute uri for auth-server-url like " > > > https://localhost:8443/auth" . > > > > > > > > Marek > > > > > > > > > > > > On 14.11.2014 01:31, Fabi?n Silva wrote: > > > > > > > > > > > > > > > > I have a keycloak installed on wildfly standalone. I'm trying to > deploy > > > an > > > > application, that use this keycloak, on a separate server with > wilflly > > > > running on domain mode. I tried first to deploy on a domain out of > the > > > box > > > > on my local machine, setting the > > > keycloak-wildfly-adapter-dist-1.0.4.Final. > > > > It deploys fine and does the authentication without any issues. When > I > > > try > > > > to migrate it to the server running my wilfly (also in domain mode > and > > > the > > > > keycloak adapter set), it deploys fine and shows the keycloak login > once > > > you > > > > enter the application. But the problem is that when you login it > > > displays a > > > > "403 - Forbidden" and on the log I'm seeing > > > > ERROR [org.keycloak.adapters.OAuthRequestAuthenticator] (default > task-6) > > > > failed to turn code into token > > > > ERROR [org.keycloak.adapters.OAuthRequestAuthenticator] (default > task-6) > > > > status from server: 404 > > > > The only difference between those two wildfly domain mode is that in > the > > > > local I don't have the the SSL/HTTPS enabled. > > > > > > > > Have anyone seen this error? or have an idea of what this could be? > > > > > > > > Regards > > > > > > > > > > > > _______________________________________________ > > > > keycloak-user mailing list keycloak-user at lists.jboss.org > > > > https://lists.jboss.org/mailman/listinfo/keycloak-user > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > keycloak-user mailing list keycloak-user at lists.jboss.org > > > > https://lists.jboss.org/mailman/listinfo/keycloak-user > > > > > > > > > > > > _______________________________________________ > > > > keycloak-user mailing list > > > > keycloak-user at lists.jboss.org > > > > https://lists.jboss.org/mailman/listinfo/keycloak-user > > > > > > > > > > > > _______________________________________________ > > > > 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-user/attachments/20141127/1319e6fe/attachment-0001.html From stian at redhat.com Fri Nov 28 02:19:51 2014 From: stian at redhat.com (Stian Thorgersen) Date: Fri, 28 Nov 2014 02:19:51 -0500 (EST) Subject: [keycloak-user] REST services supporting basic auth and bearer tokens In-Reply-To: <547741AF.1000606@redhat.com> References: <648294658.14664021.1417010058756.JavaMail.zimbra@redhat.com> <1607831918.6553021.1417092843731.JavaMail.zimbra@redhat.com> <4705717.15181747.1417096786699.JavaMail.zimbra@redhat.com> <560122619.6615545.1417098022956.JavaMail.zimbra@redhat.com> <602281263.15207272.1417098371862.JavaMail.zimbra@redhat.com> <547735AF.90608@redhat.com> <1308843455.15212297.1417099032933.JavaMail.zimbra@redhat.com> <547741AF.1000606@redhat.com> Message-ID: <2119641692.7035795.1417159191128.JavaMail.zimbra@redhat.com> I think in the long run if we try to show all features in the demo it'll end up getting to bloated. It's probably best to keep the demo to the core features (SSO, etc) and have separate basic examples (quickstarts?) for the rest. ----- Original Message ----- > From: "Marek Posolda" > To: "Gary Brown" > Cc: "Stian Thorgersen" , keycloak-user at lists.jboss.org > Sent: Thursday, 27 November, 2014 4:22:23 PM > Subject: Re: [keycloak-user] REST services supporting basic auth and bearer tokens > > Oki, sounds good to me. > > Marek > > On 27.11.2014 15:37, Gary Brown wrote: > > Hi Marek > > > > I was originally thinking the same - but it would complicate the demo more. > > > > Its possible that the database-service could simply be changed to support > > both bearer and basic auth, and then provide curl instructions to > > demonstrate basic auth access, but then there wouldn't be an example > > showing a bearer-only configuration. > > > > So assuming that a 'bearer-only' example is still required, then having a > > completely independent basic auth example may be the next best thing - and > > then leave it as an exercise for the user to enable basic auth on the > > database-service? > > > > Regards > > Gary > > > > ----- Original Message ----- > >> Sent previous email before I figured that you guys already decide on > >> something, so feel free to ignore me:-) > >> > >> On the other hand, it may be nice to show in the example that particular > >> jaxrs endpoint is able to support both bearer and basic auth in same > >> application imo. > >> > >> Marek > >> > >> On 27.11.2014 15:26, Gary Brown wrote: > >>> Ok sounds good. > >>> > >>> ----- Original Message ----- > >>>> Another option is to add a separate basic example outside of the demo, > >>>> like > >>>> what was done for multi-tenancy. A single jax-rs endpoint that supports > >>>> basic auth and an example curl command to invoke it? > >>>> > >>>> ----- Original Message ----- > >>>>> From: "Gary Brown" > >>>>> To: "Stian Thorgersen" > >>>>> Cc: "Marek Posolda" , > >>>>> keycloak-user at lists.jboss.org > >>>>> Sent: Thursday, 27 November, 2014 2:59:46 PM > >>>>> Subject: Re: [keycloak-user] REST services supporting basic auth and > >>>>> bearer > >>>>> tokens > >>>>> > >>>>> In terms of example, was thinking the database-service is ideal - > >>>>> however > >>>>> I'm > >>>>> guessing it also needs to be shown as a 'bearer-only' example (as now). > >>>>> > >>>>> In the same way that there is multiple customer-apps, one approach > >>>>> could > >>>>> be > >>>>> to have an alternate database-service supporting basic auth as well, > >>>>> but > >>>>> then would also need a separate copy of the testrealm.json. > >>>>> > >>>>> Thoughts? > >>>>> > >>>>> ----- Original Message ----- > >>>>>> Great, if you do a PR include an example we can merge it before a > >>>>>> 1.1.0.Beta2 > >>>>>> release (probably next week) > >>>>>> > >>>>>> ----- Original Message ----- > >>>>>>> From: "Gary Brown" > >>>>>>> To: "Stian Thorgersen" > >>>>>>> Cc: "Marek Posolda" , > >>>>>>> keycloak-user at lists.jboss.org > >>>>>>> Sent: Thursday, 27 November, 2014 1:48:55 PM > >>>>>>> Subject: Re: [keycloak-user] REST services supporting basic auth and > >>>>>>> bearer > >>>>>>> tokens > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> ----- Original Message ----- > >>>>>>>> Looks good to me, but I'd like it to be an optional feature that is > >>>>>>>> enabled > >>>>>>>> in keycloak.json (should be disabled by default). > >>>>>>> Sounds reasonable - I'll call the property 'enableBasicAuth'. > >>>>>>> > >>>>>>>> Another thing is that we should add an example + documentation for > >>>>>>>> this > >>>>>>>> feature. > >>>>>>> Will do. > >>>>>>> > >>>>>>>> ----- Original Message ----- > >>>>>>>>> From: "Gary Brown" > >>>>>>>>> To: "Marek Posolda" > >>>>>>>>> Cc: keycloak-user at lists.jboss.org > >>>>>>>>> Sent: Thursday, 27 November, 2014 10:58:21 AM > >>>>>>>>> Subject: Re: [keycloak-user] REST services supporting basic auth > >>>>>>>>> and > >>>>>>>>> bearer > >>>>>>>>> tokens > >>>>>>>>> > >>>>>>>>> Hi Marek > >>>>>>>>> > >>>>>>>>> ----- Original Message ----- > >>>>>>>>>> Hi, > >>>>>>>>>> > >>>>>>>>>> I am not 100% sure if having basic auth with direct grant > >>>>>>>>>> directly > >>>>>>>>>> in > >>>>>>>>>> our adapters is way to go. Probably yes as for your use-case it > >>>>>>>>>> makes > >>>>>>>>>> sense, so I am slightly for push your change as PR. But maybe > >>>>>>>>>> others > >>>>>>>>>> from team have different opinion. > >>>>>>>>>> > >>>>>>>>>> Earlier this week I've added DirectAccessGrantsLoginModule to KC > >>>>>>>>>> codebase, which is quite similar and is intended to be used for > >>>>>>>>>> non-web > >>>>>>>>>> applications (like SSH), which rely on JAAS. But I guess that > >>>>>>>>>> using > >>>>>>>>>> this > >>>>>>>>>> one is not good option for you as you want support for Basic and > >>>>>>>>>> Bearer > >>>>>>>>>> authentication in same web application, right? > >>>>>>>>> Thats correct. > >>>>>>>>> > >>>>>>>>>> Few more minor points to your changes: > >>>>>>>>>> - Is it possible to use net.iharder.Base64 instead of > >>>>>>>>>> org.apache.commons.codec.binary.Base64? Whole KC code has > >>>>>>>>>> dependency > >>>>>>>>>> on > >>>>>>>>>> net.iharder, so would be likely better to use this one to avoid > >>>>>>>>>> possible > >>>>>>>>>> dependency issues in adapters. > >>>>>>>>> That shouldn't be a problem. > >>>>>>>>> > >>>>>>>>>> - Wonder if it's possible to simplify a bit, like have single > >>>>>>>>>> "completeAuthentication" method for both bearer and basic > >>>>>>>>>> authenticator > >>>>>>>>>> (afaik only difference among them is different authMethod > >>>>>>>>>> right?). > >>>>>>>>>> But > >>>>>>>>>> this is really minor. > >>>>>>>>> Will do. > >>>>>>>>> > >>>>>>>>> I'll wait until mid next week before doing any more on this, to see > >>>>>>>>> whether > >>>>>>>>> others have an opinion. > >>>>>>>>> > >>>>>>>>> If the PR was accepted, any chance it could go into 1.1 even though > >>>>>>>>> in > >>>>>>>>> beta? > >>>>>>>>> If no, any idea what the timescale is for 1.2.beta1? > >>>>>>>>> > >>>>>>>>> Thanks for your feedback. > >>>>>>>>> > >>>>>>>>> Regards > >>>>>>>>> Gary > >>>>>>>>> > >>>>>>>>>> Marek > >>>>>>>>>> > >>>>>>>>>> On 26.11.2014 14:54, Gary Brown wrote: > >>>>>>>>>>> Hi > >>>>>>>>>>> > >>>>>>>>>>> Concrete use case - we have implemented the OASIS S-RAMP > >>>>>>>>>>> specification, > >>>>>>>>>>> in > >>>>>>>>>>> which it requires basic auth support > >>>>>>>>>>> (http://docs.oasis-open.org/s-ramp/s-ramp/v1.0/s-ramp-v1.0-part2-atom-binding.html > >>>>>>>>>>> section 5 "The S-RAMP Specification does not attempt to define > >>>>>>>>>>> a > >>>>>>>>>>> security > >>>>>>>>>>> model for products that implement it. For the Atom Binding, > >>>>>>>>>>> the > >>>>>>>>>>> only > >>>>>>>>>>> security requirement is that at a minimum, client and server > >>>>>>>>>>> implementations MUST be capable of being configured to use HTTP > >>>>>>>>>>> Basic > >>>>>>>>>>> Authentication in conjunction with a connection made with > >>>>>>>>>>> TLS."). > >>>>>>>>>>> > >>>>>>>>>>> However we also need the same service to support bearer token, > >>>>>>>>>>> for > >>>>>>>>>>> use > >>>>>>>>>>> within our KeyCloak SSO session. > >>>>>>>>>>> > >>>>>>>>>>> I've implemented a possible solution, details defined on > >>>>>>>>>>> https://issues.jboss.org/browse/KEYCLOAK-861. > >>>>>>>>>>> > >>>>>>>>>>> If this solution is on the right path, I would appreciate any > >>>>>>>>>>> feedback > >>>>>>>>>>> on > >>>>>>>>>>> any changes that might be required before submitting a PR. > >>>>>>>>>>> Currently > >>>>>>>>>>> there > >>>>>>>>>>> are no tests, but would aim to provide some with the PR. > >>>>>>>>>>> > >>>>>>>>>>> Regards > >>>>>>>>>>> Gary > >>>>>>>>>>> _______________________________________________ > >>>>>>>>>>> keycloak-user mailing list > >>>>>>>>>>> keycloak-user at lists.jboss.org > >>>>>>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-user > >>>>>>>>> _______________________________________________ > >>>>>>>>> keycloak-user mailing list > >>>>>>>>> keycloak-user at lists.jboss.org > >>>>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-user > >>>>>>>>> > >> > > From stian at redhat.com Fri Nov 28 02:55:47 2014 From: stian at redhat.com (Stian Thorgersen) Date: Fri, 28 Nov 2014 02:55:47 -0500 (EST) Subject: [keycloak-user] Error on application log in In-Reply-To: References: <546CD33B.1020607@redhat.com> <1823273882.2484255.1416471931969.JavaMail.zimbra@redhat.com> <1453102381.4076575.1416817786988.JavaMail.zimbra@redhat.com> Message-ID: <2044037609.7046012.1417161347883.JavaMail.zimbra@redhat.com> Hi, I've just verified that it works fine to connect to a remote Keycloak server with SSL enabled. Without a trustore configured I get: 08:38:46,584 ERROR [org.keycloak.adapters.OAuthRequestAuthenticator] (default task-12) failed to turn code into token: javax.net.ssl.SSLPeerUnverifiedException: peer not authenticated Is this the same error you're seeing? Then I added disable-trust-manager to the applications keycloak.json: { ... "disable-trust-manager": true } Which works fine, but obviously you want to use a truststore: { "truststore": "cacerts.jks", "truststore-password" : "password" } If you still can't get things to work you can send me the following things and I'll look into it: * Server logs * Complete steps to reproduce issue - Configuration of SSL (including how you generate your certificate and keystore) - Any changes to Keycloak configuration - Sample application (including keycloak.json and how you generate your truststore) ----- Original Message ----- > From: "Fabi?n Silva" > To: "Stian Thorgersen" > Cc: "Stan Silvert" , keycloak-user at lists.jboss.org > Sent: Thursday, 27 November, 2014 7:05:07 PM > Subject: Re: [keycloak-user] Error on application log in > > I have tried "disable-trust-manager": true, but did not worked. I still get > the "403 - Forbidden". > I tried also to set the "truststore" : "path/to/truststore.jks" and > "truststore-password" : "pass" and also did not worked. > The only thing that has worked is to deploy it with a wildfly without the > SSL enabled. > Is there another thing I can try, to make it worked with a domain wildfly > with SSL enabled? > > Regards > > On Mon, Nov 24, 2014 at 2:29 AM, Stian Thorgersen wrote: > > > The options you're after are truststore, truststore-password and > > disable-trust-manager, not client-keystore. > > > > ----- Original Message ----- > > > From: "Fabi?n Silva" > > > To: "Stian Thorgersen" > > > Cc: "Stan Silvert" , keycloak-user at lists.jboss.org > > > Sent: Saturday, 22 November, 2014 12:58:16 AM > > > Subject: Re: [keycloak-user] Error on application log in > > > > > > > > http://docs.jboss.org/keycloak/docs/1.1.0.Beta1/userguide/html/ch07.html#adapter-config > > > "client-keystore > > > Not supported yet, but we will support in future versions." > > > So if my adapter has SSL enabled is not supported yet? Or how do I > > > configure it to work if my adapter has the SSL enabled? > > > I tried with an adapter without SSL enabled and the keycloak with the SSL > > > enabled and it worked. But when I tried it with both, the adapter and the > > > keycloak with SSL enabled, it doesn't work. I got the following logs on > > the > > > adapter: > > > ERROR [org.keycloak.adapters.OAuthRequestAuthenticator] (default task-6) > > > failed to turn code into token > > > ERROR [org.keycloak.adapters.OAuthRequestAuthenticator] (default task-6) > > > status from server: 404 > > > > > > Regards > > > > > > On Thu, Nov 20, 2014 at 2:25 AM, Stian Thorgersen > > wrote: > > > > > > > Are there no errors or warning in the server log? Try enabling debug > > for > > > > org.keycloak and see if there's anything interesting. > > > > > > > > First thing try the exact same setup (two servers), but without ssl. > > > > > > > > If that works disable enable ssl, but disable the trust manager in the > > > > adapter (disable-trust-manager option on adapter, see > > > > > > http://docs.jboss.org/keycloak/docs/1.1.0.Beta1/userguide/html/ch07.html#adapter-config > > > > ). > > > > > > > > If it still works create a truststore and import your certificate. Then > > > > set truststore and truststore-password on the adapter. > > > > > > > > ----- Original Message ----- > > > > > From: "Fabi?n Silva" > > > > > To: "Stan Silvert" > > > > > Cc: keycloak-user at lists.jboss.org > > > > > Sent: Wednesday, 19 November, 2014 6:35:15 PM > > > > > Subject: Re: [keycloak-user] Error on application log in > > > > > > > > > > I tried deploying it onto a local wildfly in domain without the SSL > > > > enabled > > > > > and it worked. What I can't figure it out is why the SSL is causing > > > > conflict > > > > > and how to solve this, I can't simply disable the SSL. > > > > > > > > > > Regards > > > > > > > > > > On Wed, Nov 19, 2014 at 11:28 AM, Stan Silvert < ssilvert at redhat.com > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > Have you tried it using the two servers but without SSL? > > > > > > > > > > You can set ssl-required to "none" on the adapter (application) side. > > > > Also on > > > > > the Keycloak server side, try setting Access Type to "public". Do > > one of > > > > > those at a time and see if either causes it to work. That might > > narrow it > > > > > down a bit. > > > > > > > > > > > > > > > On 11/19/2014 11:29 AM, Fabi?n Silva wrote: > > > > > > > > > > > > > > > > > > > > Hi, > > > > > I'm running out of ideas in here. In simple terms I got a Wildfly > > > > running on > > > > > domain on a server and a keycloak on another server. I set the > > adapters > > > > on > > > > > my wildfly and deploy, to this wildfly, a web app that uses keycloak. > > > > When I > > > > > try to access the web app it displays the keycloak login, it > > validates > > > > the > > > > > users ok, but when you access with a correct user and password it > > shows > > > > the > > > > > "403 - Forbidden". At first I thought it was some issue with the > > roles, > > > > but > > > > > that didn't fix it. > > > > > > > > > > Regards > > > > > > > > > > On Fri, Nov 14, 2014 at 10:20 AM, Fabi?n Silva < afsg77 at gmail.com > > > > > wrote: > > > > > > > > > > > > > > > > > > > > Hi, > > > > > It is already set to use the absolute path. And the keycloak is > > working > > > > when > > > > > I deploy the application to my local wildfly domain. The issue is > > when I > > > > try > > > > > to deploy to another wildfly in domain mode on a separate server. The > > > > > application is the same and the only difference I can tell from the > > two > > > > > wildflys is that the local don't have the SSL/HTTPS enabled. I have > > the > > > > > keycloak adapter set in both domains. > > > > > > > > > > I'm trying to trace those errors on the keycloak code to try to > > > > understand > > > > > what is happening, but I haven't been so lucky with this. > > > > > > > > > > Regards > > > > > Alejandro Fabi?n Silva Grif? > > > > > > > > > > On Fri, Nov 14, 2014 at 2:27 AM, Marek Posolda < mposolda at redhat.com > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > Hi, > > > > > > > > > > it failed on the adapter (application) side and error 404 means "Not > > > > found". > > > > > So adapter can't find the keycloak server to turn code into token. > > Make > > > > sure > > > > > to configure "auth-server-url" in keycloak.json for your application > > > > > properly. If relative uri doesn't work for some reason, you can > > rather > > > > try > > > > > to use absolute uri for auth-server-url like " > > > > https://localhost:8443/auth" . > > > > > > > > > > Marek > > > > > > > > > > > > > > > On 14.11.2014 01:31, Fabi?n Silva wrote: > > > > > > > > > > > > > > > > > > > > I have a keycloak installed on wildfly standalone. I'm trying to > > deploy > > > > an > > > > > application, that use this keycloak, on a separate server with > > wilflly > > > > > running on domain mode. I tried first to deploy on a domain out of > > the > > > > box > > > > > on my local machine, setting the > > > > keycloak-wildfly-adapter-dist-1.0.4.Final. > > > > > It deploys fine and does the authentication without any issues. When > > I > > > > try > > > > > to migrate it to the server running my wilfly (also in domain mode > > and > > > > the > > > > > keycloak adapter set), it deploys fine and shows the keycloak login > > once > > > > you > > > > > enter the application. But the problem is that when you login it > > > > displays a > > > > > "403 - Forbidden" and on the log I'm seeing > > > > > ERROR [org.keycloak.adapters.OAuthRequestAuthenticator] (default > > task-6) > > > > > failed to turn code into token > > > > > ERROR [org.keycloak.adapters.OAuthRequestAuthenticator] (default > > task-6) > > > > > status from server: 404 > > > > > The only difference between those two wildfly domain mode is that in > > the > > > > > local I don't have the the SSL/HTTPS enabled. > > > > > > > > > > Have anyone seen this error? or have an idea of what this could be? > > > > > > > > > > Regards > > > > > > > > > > > > > > > _______________________________________________ > > > > > keycloak-user mailing list keycloak-user at lists.jboss.org > > > > > https://lists.jboss.org/mailman/listinfo/keycloak-user > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > keycloak-user mailing list keycloak-user at lists.jboss.org > > > > > https://lists.jboss.org/mailman/listinfo/keycloak-user > > > > > > > > > > > > > > > _______________________________________________ > > > > > keycloak-user mailing list > > > > > keycloak-user at lists.jboss.org > > > > > https://lists.jboss.org/mailman/listinfo/keycloak-user > > > > > > > > > > > > > > > _______________________________________________ > > > > > keycloak-user mailing list > > > > > keycloak-user at lists.jboss.org > > > > > https://lists.jboss.org/mailman/listinfo/keycloak-user > > > > > > > > > > From stian at redhat.com Fri Nov 28 03:04:09 2014 From: stian at redhat.com (Stian Thorgersen) Date: Fri, 28 Nov 2014 03:04:09 -0500 (EST) Subject: [keycloak-user] Questions about keycloak In-Reply-To: References: <54774560.8050809@redhat.com> Message-ID: <2084644196.7048027.1417161849834.JavaMail.zimbra@redhat.com> ----- Original Message ----- > From: "Ruben Lopez" > To: "Marek Posolda" > Cc: keycloak-user at lists.jboss.org > Sent: Thursday, 27 November, 2014 5:37:45 PM > Subject: Re: [keycloak-user] Questions about keycloak > > Hi Marek, > > 2014-11-27 12:38 GMT-03:00 Marek Posolda < mposolda at redhat.com > : > > > > > > 1 - Is there any way to obtain an access token for an OAuth Client via Client > Credentials[1]? > You mean something like Service account like this from OAuth2 specs > http://tools.ietf.org/html/rfc6749#page-40 ? We don't have that yet, but > there are plans to support it afaik. > > > > > Yes, I was talking about secction 4.4 Client Credentials Grant. Any idea > about when it will be implemented? I can't give you and exact date, but it's becoming more and more of a priority so should be within a few months. We also plan to add cert based authentication for clients. In the mean-time you can work-around this issue by creating a user on behalf of the client and use Resource Owner Password Credentials Grant (section #4.3). Look at 'examples/preconfigured-demo/admin-access' in the download for an example. > > > > > > > 2 - If we make a request to an Application (Resource Server) with an access > token and this Application needs to talk to another protected Application to > form the response to the client, how does the first Application > authenticates to the second Application? Does Keycloak implements something > like Chain Grant Type Profile[2]? > yes, that is doable. We have an example where we have frontend application > like 'customer-portal', which is able to retrieve accessToken from keycloak > like here: > https://github.com/keycloak/keycloak/blob/master/examples/demo-template/customer-app/src/main/java/org/keycloak/example/CustomerDatabaseClient.java#L48 > and then use this accessToken to send request to backend application > 'database-service' in Authorization header > https://github.com/keycloak/keycloak/blob/master/examples/demo-template/customer-app/src/main/java/org/keycloak/example/CustomerDatabaseClient.java#L54 > . Database-service is then able to authenticate the token. > > Currently our database-service is directly serving requests and send back > data, but it shouldn't be a problem to add another application to the chain, > so that database-service will send the token again to another app like > 'real-database-service', which will return data and those data will be sent > back to the original frontent requestor (customer-portal). Is it something > what you meant? > > Thats exactly what I meant. I will take a look at the example. > > Thank you very much. > > > > > > Marek > > > > > Thanks in advance. > > > _______________________________________________ > keycloak-user mailing list keycloak-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user > > > > _______________________________________________ > keycloak-user mailing list > keycloak-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user From alexander.chriztopher at gmail.com Fri Nov 28 04:14:32 2014 From: alexander.chriztopher at gmail.com (Alexander Chriztopher) Date: Fri, 28 Nov 2014 10:14:32 +0100 Subject: [keycloak-user] Providers with CDI Message-ID: Hi All, I there a way to get providers to be managed by CDI. The aim is to get access to services such as entity manager injection and lifecycle management which would be done manually today. Thanks for any help. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20141128/7da6d807/attachment.html From stian at redhat.com Fri Nov 28 04:54:59 2014 From: stian at redhat.com (Stian Thorgersen) Date: Fri, 28 Nov 2014 04:54:59 -0500 (EST) Subject: [keycloak-user] Providers with CDI In-Reply-To: References: Message-ID: <1248453717.7109247.1417168499202.JavaMail.zimbra@redhat.com> No, afraid we don't support CDI (or any other managed features such as EJBs) in our providers. They are just POJO's and Keycloak manages their life-cycle. In the future we may make it simpler to create providers, but this is not a priority atm. ----- Original Message ----- > From: "Alexander Chriztopher" > To: keycloak-user at lists.jboss.org > Sent: Friday, 28 November, 2014 10:14:32 AM > Subject: [keycloak-user] Providers with CDI > > Hi All, > > I there a way to get providers to be managed by CDI. > > The aim is to get access to services such as entity manager injection and > lifecycle management which would be done manually today. > > Thanks for any help. > > _______________________________________________ > keycloak-user mailing list > keycloak-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user From alexander.chriztopher at gmail.com Fri Nov 28 05:01:46 2014 From: alexander.chriztopher at gmail.com (Alexander Chriztopher) Date: Fri, 28 Nov 2014 11:01:46 +0100 Subject: [keycloak-user] Providers with CDI In-Reply-To: <1248453717.7109247.1417168499202.JavaMail.zimbra@redhat.com> References: <1248453717.7109247.1417168499202.JavaMail.zimbra@redhat.com> Message-ID: ok ! Are there any examples of using JPA ? On Fri, Nov 28, 2014 at 10:54 AM, Stian Thorgersen wrote: > No, afraid we don't support CDI (or any other managed features such as > EJBs) in our providers. They are just POJO's and Keycloak manages their > life-cycle. > > In the future we may make it simpler to create providers, but this is not > a priority atm. > > ----- Original Message ----- > > From: "Alexander Chriztopher" > > To: keycloak-user at lists.jboss.org > > Sent: Friday, 28 November, 2014 10:14:32 AM > > Subject: [keycloak-user] Providers with CDI > > > > Hi All, > > > > I there a way to get providers to be managed by CDI. > > > > The aim is to get access to services such as entity manager injection and > > lifecycle management which would be done manually today. > > > > Thanks for any help. > > > > _______________________________________________ > > 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-user/attachments/20141128/780a5f87/attachment.html From stian at redhat.com Fri Nov 28 05:10:43 2014 From: stian at redhat.com (Stian Thorgersen) Date: Fri, 28 Nov 2014 05:10:43 -0500 (EST) Subject: [keycloak-user] Providers with CDI In-Reply-To: References: <1248453717.7109247.1417168499202.JavaMail.zimbra@redhat.com> Message-ID: <1254244340.7113754.1417169443920.JavaMail.zimbra@redhat.com> No, there's no example for this, but you can look at the Keycloak source as we use JPA ourselves. You have two options: a) Shared EntityManager instance with internal Keycloak providers - if you're using the same db for both this is a good option b) Separate EntityManager instance For option a) you should look at extending the default connectionJpa provider to add your own persistence.xml (you need to copy/modify Keycloak's persistence.xml). Look at https://github.com/keycloak/keycloak/tree/master/connections/jpa/src/main/java/org/keycloak/connections/jpa and https://github.com/keycloak/keycloak/tree/master/model/jpa. For option b) you can just have your ProviderFactory create the EntityManagerFactory and pass it to the Provider instance. For this you only need to look at https://github.com/keycloak/keycloak/tree/master/connections/jpa/src/main/java/org/keycloak/connections/jpa. ----- Original Message ----- > From: "Alexander Chriztopher" > To: "Stian Thorgersen" > Cc: keycloak-user at lists.jboss.org > Sent: Friday, 28 November, 2014 11:01:46 AM > Subject: Re: [keycloak-user] Providers with CDI > > ok ! Are there any examples of using JPA ? > > On Fri, Nov 28, 2014 at 10:54 AM, Stian Thorgersen wrote: > > > No, afraid we don't support CDI (or any other managed features such as > > EJBs) in our providers. They are just POJO's and Keycloak manages their > > life-cycle. > > > > In the future we may make it simpler to create providers, but this is not > > a priority atm. > > > > ----- Original Message ----- > > > From: "Alexander Chriztopher" > > > To: keycloak-user at lists.jboss.org > > > Sent: Friday, 28 November, 2014 10:14:32 AM > > > Subject: [keycloak-user] Providers with CDI > > > > > > Hi All, > > > > > > I there a way to get providers to be managed by CDI. > > > > > > The aim is to get access to services such as entity manager injection and > > > lifecycle management which would be done manually today. > > > > > > Thanks for any help. > > > > > > _______________________________________________ > > > keycloak-user mailing list > > > keycloak-user at lists.jboss.org > > > https://lists.jboss.org/mailman/listinfo/keycloak-user > > > From alexander.chriztopher at gmail.com Fri Nov 28 08:53:42 2014 From: alexander.chriztopher at gmail.com (Alexander Chriztopher) Date: Fri, 28 Nov 2014 14:53:42 +0100 Subject: [keycloak-user] Providers with CDI In-Reply-To: <1254244340.7113754.1417169443920.JavaMail.zimbra@redhat.com> References: <1248453717.7109247.1417168499202.JavaMail.zimbra@redhat.com> <1254244340.7113754.1417169443920.JavaMail.zimbra@redhat.com> Message-ID: thank you Stian. I have found my error. I was using a JTA transaction provider and changed that to a local one and it is now working. Just in case anyone is interested this is how my persistence.xml is : java:jboss/datasources/security And this how i create my entity manager to handle the transaction : EntityManagerFactory emf = Persistence.createEntityManagerFactory("security"); EntityManager em = emf.createEntityManager(); em.getTransaction().begin(); // some code to save data to the db em.getTransaction().commit(); On Fri, Nov 28, 2014 at 11:10 AM, Stian Thorgersen wrote: > No, there's no example for this, but you can look at the Keycloak source > as we use JPA ourselves. > > You have two options: > > a) Shared EntityManager instance with internal Keycloak providers - if > you're using the same db for both this is a good option > b) Separate EntityManager instance > > For option a) you should look at extending the default connectionJpa > provider to add your own persistence.xml (you need to copy/modify > Keycloak's persistence.xml). Look at > https://github.com/keycloak/keycloak/tree/master/connections/jpa/src/main/java/org/keycloak/connections/jpa > and https://github.com/keycloak/keycloak/tree/master/model/jpa. > > For option b) you can just have your ProviderFactory create the > EntityManagerFactory and pass it to the Provider instance. For this you > only need to look at > https://github.com/keycloak/keycloak/tree/master/connections/jpa/src/main/java/org/keycloak/connections/jpa > . > > ----- Original Message ----- > > From: "Alexander Chriztopher" > > To: "Stian Thorgersen" > > Cc: keycloak-user at lists.jboss.org > > Sent: Friday, 28 November, 2014 11:01:46 AM > > Subject: Re: [keycloak-user] Providers with CDI > > > > ok ! Are there any examples of using JPA ? > > > > On Fri, Nov 28, 2014 at 10:54 AM, Stian Thorgersen > wrote: > > > > > No, afraid we don't support CDI (or any other managed features such as > > > EJBs) in our providers. They are just POJO's and Keycloak manages their > > > life-cycle. > > > > > > In the future we may make it simpler to create providers, but this is > not > > > a priority atm. > > > > > > ----- Original Message ----- > > > > From: "Alexander Chriztopher" > > > > To: keycloak-user at lists.jboss.org > > > > Sent: Friday, 28 November, 2014 10:14:32 AM > > > > Subject: [keycloak-user] Providers with CDI > > > > > > > > Hi All, > > > > > > > > I there a way to get providers to be managed by CDI. > > > > > > > > The aim is to get access to services such as entity manager > injection and > > > > lifecycle management which would be done manually today. > > > > > > > > Thanks for any help. > > > > > > > > _______________________________________________ > > > > 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-user/attachments/20141128/0416d495/attachment.html From alexander.chriztopher at gmail.com Fri Nov 28 10:11:25 2014 From: alexander.chriztopher at gmail.com (Alexander Chriztopher) Date: Fri, 28 Nov 2014 16:11:25 +0100 Subject: [keycloak-user] Internationalisation Message-ID: Hi All, Do you have any plans for Internationalisation in Keycloak ? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20141128/6a26f9b1/attachment.html From stian at redhat.com Fri Nov 28 10:16:01 2014 From: stian at redhat.com (Stian Thorgersen) Date: Fri, 28 Nov 2014 10:16:01 -0500 (EST) Subject: [keycloak-user] Internationalisation In-Reply-To: References: Message-ID: <500246093.7278535.1417187761837.JavaMail.zimbra@redhat.com> Yes, can't tell you exactly when it'll be added though ----- Original Message ----- > From: "Alexander Chriztopher" > To: keycloak-user at lists.jboss.org > Sent: Friday, 28 November, 2014 4:11:25 PM > Subject: [keycloak-user] Internationalisation > > Hi All, > > Do you have any plans for Internationalisation in Keycloak ? > > _______________________________________________ > keycloak-user mailing list > keycloak-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user From gbrown at redhat.com Fri Nov 28 10:19:43 2014 From: gbrown at redhat.com (Gary Brown) Date: Fri, 28 Nov 2014 10:19:43 -0500 (EST) Subject: [keycloak-user] REST services supporting basic auth and bearer tokens In-Reply-To: <2119641692.7035795.1417159191128.JavaMail.zimbra@redhat.com> References: <648294658.14664021.1417010058756.JavaMail.zimbra@redhat.com> <4705717.15181747.1417096786699.JavaMail.zimbra@redhat.com> <560122619.6615545.1417098022956.JavaMail.zimbra@redhat.com> <602281263.15207272.1417098371862.JavaMail.zimbra@redhat.com> <547735AF.90608@redhat.com> <1308843455.15212297.1417099032933.JavaMail.zimbra@redhat.com> <547741AF.1000606@redhat.com> <2119641692.7035795.1417159191128.JavaMail.zimbra@redhat.com> Message-ID: <2102923959.15427560.1417187983153.JavaMail.zimbra@redhat.com> Hi Stian and Marek PR submitted: https://github.com/keycloak/keycloak/pull/874 I've added a comment to the jira (https://issues.jboss.org/browse/KEYCLOAK-861) about roles - if whoever reviews the PR could let me know. Thanks. Regards Gary ----- Original Message ----- > I think in the long run if we try to show all features in the demo it'll end > up getting to bloated. It's probably best to keep the demo to the core > features (SSO, etc) and have separate basic examples (quickstarts?) for the > rest. > > ----- Original Message ----- > > From: "Marek Posolda" > > To: "Gary Brown" > > Cc: "Stian Thorgersen" , keycloak-user at lists.jboss.org > > Sent: Thursday, 27 November, 2014 4:22:23 PM > > Subject: Re: [keycloak-user] REST services supporting basic auth and bearer > > tokens > > > > Oki, sounds good to me. > > > > Marek > > > > On 27.11.2014 15:37, Gary Brown wrote: > > > Hi Marek > > > > > > I was originally thinking the same - but it would complicate the demo > > > more. > > > > > > Its possible that the database-service could simply be changed to support > > > both bearer and basic auth, and then provide curl instructions to > > > demonstrate basic auth access, but then there wouldn't be an example > > > showing a bearer-only configuration. > > > > > > So assuming that a 'bearer-only' example is still required, then having a > > > completely independent basic auth example may be the next best thing - > > > and > > > then leave it as an exercise for the user to enable basic auth on the > > > database-service? > > > > > > Regards > > > Gary > > > > > > ----- Original Message ----- > > >> Sent previous email before I figured that you guys already decide on > > >> something, so feel free to ignore me:-) > > >> > > >> On the other hand, it may be nice to show in the example that particular > > >> jaxrs endpoint is able to support both bearer and basic auth in same > > >> application imo. > > >> > > >> Marek > > >> > > >> On 27.11.2014 15:26, Gary Brown wrote: > > >>> Ok sounds good. > > >>> > > >>> ----- Original Message ----- > > >>>> Another option is to add a separate basic example outside of the demo, > > >>>> like > > >>>> what was done for multi-tenancy. A single jax-rs endpoint that > > >>>> supports > > >>>> basic auth and an example curl command to invoke it? > > >>>> > > >>>> ----- Original Message ----- > > >>>>> From: "Gary Brown" > > >>>>> To: "Stian Thorgersen" > > >>>>> Cc: "Marek Posolda" , > > >>>>> keycloak-user at lists.jboss.org > > >>>>> Sent: Thursday, 27 November, 2014 2:59:46 PM > > >>>>> Subject: Re: [keycloak-user] REST services supporting basic auth and > > >>>>> bearer > > >>>>> tokens > > >>>>> > > >>>>> In terms of example, was thinking the database-service is ideal - > > >>>>> however > > >>>>> I'm > > >>>>> guessing it also needs to be shown as a 'bearer-only' example (as > > >>>>> now). > > >>>>> > > >>>>> In the same way that there is multiple customer-apps, one approach > > >>>>> could > > >>>>> be > > >>>>> to have an alternate database-service supporting basic auth as well, > > >>>>> but > > >>>>> then would also need a separate copy of the testrealm.json. > > >>>>> > > >>>>> Thoughts? > > >>>>> > > >>>>> ----- Original Message ----- > > >>>>>> Great, if you do a PR include an example we can merge it before a > > >>>>>> 1.1.0.Beta2 > > >>>>>> release (probably next week) > > >>>>>> > > >>>>>> ----- Original Message ----- > > >>>>>>> From: "Gary Brown" > > >>>>>>> To: "Stian Thorgersen" > > >>>>>>> Cc: "Marek Posolda" , > > >>>>>>> keycloak-user at lists.jboss.org > > >>>>>>> Sent: Thursday, 27 November, 2014 1:48:55 PM > > >>>>>>> Subject: Re: [keycloak-user] REST services supporting basic auth > > >>>>>>> and > > >>>>>>> bearer > > >>>>>>> tokens > > >>>>>>> > > >>>>>>> > > >>>>>>> > > >>>>>>> ----- Original Message ----- > > >>>>>>>> Looks good to me, but I'd like it to be an optional feature that > > >>>>>>>> is > > >>>>>>>> enabled > > >>>>>>>> in keycloak.json (should be disabled by default). > > >>>>>>> Sounds reasonable - I'll call the property 'enableBasicAuth'. > > >>>>>>> > > >>>>>>>> Another thing is that we should add an example + documentation for > > >>>>>>>> this > > >>>>>>>> feature. > > >>>>>>> Will do. > > >>>>>>> > > >>>>>>>> ----- Original Message ----- > > >>>>>>>>> From: "Gary Brown" > > >>>>>>>>> To: "Marek Posolda" > > >>>>>>>>> Cc: keycloak-user at lists.jboss.org > > >>>>>>>>> Sent: Thursday, 27 November, 2014 10:58:21 AM > > >>>>>>>>> Subject: Re: [keycloak-user] REST services supporting basic auth > > >>>>>>>>> and > > >>>>>>>>> bearer > > >>>>>>>>> tokens > > >>>>>>>>> > > >>>>>>>>> Hi Marek > > >>>>>>>>> > > >>>>>>>>> ----- Original Message ----- > > >>>>>>>>>> Hi, > > >>>>>>>>>> > > >>>>>>>>>> I am not 100% sure if having basic auth with direct grant > > >>>>>>>>>> directly > > >>>>>>>>>> in > > >>>>>>>>>> our adapters is way to go. Probably yes as for your use-case it > > >>>>>>>>>> makes > > >>>>>>>>>> sense, so I am slightly for push your change as PR. But maybe > > >>>>>>>>>> others > > >>>>>>>>>> from team have different opinion. > > >>>>>>>>>> > > >>>>>>>>>> Earlier this week I've added DirectAccessGrantsLoginModule to KC > > >>>>>>>>>> codebase, which is quite similar and is intended to be used for > > >>>>>>>>>> non-web > > >>>>>>>>>> applications (like SSH), which rely on JAAS. But I guess that > > >>>>>>>>>> using > > >>>>>>>>>> this > > >>>>>>>>>> one is not good option for you as you want support for Basic and > > >>>>>>>>>> Bearer > > >>>>>>>>>> authentication in same web application, right? > > >>>>>>>>> Thats correct. > > >>>>>>>>> > > >>>>>>>>>> Few more minor points to your changes: > > >>>>>>>>>> - Is it possible to use net.iharder.Base64 instead of > > >>>>>>>>>> org.apache.commons.codec.binary.Base64? Whole KC code has > > >>>>>>>>>> dependency > > >>>>>>>>>> on > > >>>>>>>>>> net.iharder, so would be likely better to use this one to avoid > > >>>>>>>>>> possible > > >>>>>>>>>> dependency issues in adapters. > > >>>>>>>>> That shouldn't be a problem. > > >>>>>>>>> > > >>>>>>>>>> - Wonder if it's possible to simplify a bit, like have single > > >>>>>>>>>> "completeAuthentication" method for both bearer and basic > > >>>>>>>>>> authenticator > > >>>>>>>>>> (afaik only difference among them is different authMethod > > >>>>>>>>>> right?). > > >>>>>>>>>> But > > >>>>>>>>>> this is really minor. > > >>>>>>>>> Will do. > > >>>>>>>>> > > >>>>>>>>> I'll wait until mid next week before doing any more on this, to > > >>>>>>>>> see > > >>>>>>>>> whether > > >>>>>>>>> others have an opinion. > > >>>>>>>>> > > >>>>>>>>> If the PR was accepted, any chance it could go into 1.1 even > > >>>>>>>>> though > > >>>>>>>>> in > > >>>>>>>>> beta? > > >>>>>>>>> If no, any idea what the timescale is for 1.2.beta1? > > >>>>>>>>> > > >>>>>>>>> Thanks for your feedback. > > >>>>>>>>> > > >>>>>>>>> Regards > > >>>>>>>>> Gary > > >>>>>>>>> > > >>>>>>>>>> Marek > > >>>>>>>>>> > > >>>>>>>>>> On 26.11.2014 14:54, Gary Brown wrote: > > >>>>>>>>>>> Hi > > >>>>>>>>>>> > > >>>>>>>>>>> Concrete use case - we have implemented the OASIS S-RAMP > > >>>>>>>>>>> specification, > > >>>>>>>>>>> in > > >>>>>>>>>>> which it requires basic auth support > > >>>>>>>>>>> (http://docs.oasis-open.org/s-ramp/s-ramp/v1.0/s-ramp-v1.0-part2-atom-binding.html > > >>>>>>>>>>> section 5 "The S-RAMP Specification does not attempt to define > > >>>>>>>>>>> a > > >>>>>>>>>>> security > > >>>>>>>>>>> model for products that implement it. For the Atom Binding, > > >>>>>>>>>>> the > > >>>>>>>>>>> only > > >>>>>>>>>>> security requirement is that at a minimum, client and server > > >>>>>>>>>>> implementations MUST be capable of being configured to use HTTP > > >>>>>>>>>>> Basic > > >>>>>>>>>>> Authentication in conjunction with a connection made with > > >>>>>>>>>>> TLS."). > > >>>>>>>>>>> > > >>>>>>>>>>> However we also need the same service to support bearer token, > > >>>>>>>>>>> for > > >>>>>>>>>>> use > > >>>>>>>>>>> within our KeyCloak SSO session. > > >>>>>>>>>>> > > >>>>>>>>>>> I've implemented a possible solution, details defined on > > >>>>>>>>>>> https://issues.jboss.org/browse/KEYCLOAK-861. > > >>>>>>>>>>> > > >>>>>>>>>>> If this solution is on the right path, I would appreciate any > > >>>>>>>>>>> feedback > > >>>>>>>>>>> on > > >>>>>>>>>>> any changes that might be required before submitting a PR. > > >>>>>>>>>>> Currently > > >>>>>>>>>>> there > > >>>>>>>>>>> are no tests, but would aim to provide some with the PR. > > >>>>>>>>>>> > > >>>>>>>>>>> Regards > > >>>>>>>>>>> Gary > > >>>>>>>>>>> _______________________________________________ > > >>>>>>>>>>> keycloak-user mailing list > > >>>>>>>>>>> keycloak-user at lists.jboss.org > > >>>>>>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-user > > >>>>>>>>> _______________________________________________ > > >>>>>>>>> keycloak-user mailing list > > >>>>>>>>> keycloak-user at lists.jboss.org > > >>>>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-user > > >>>>>>>>> > > >> > > > > >