From bburke at redhat.com Sun Mar 1 18:40:47 2015 From: bburke at redhat.com (Bill Burke) Date: Sun, 01 Mar 2015 18:40:47 -0500 Subject: [keycloak-dev] mongo tests really slow Message-ID: <54F3A37F.1000502@redhat.com> I'm fixing the mongo tests, and I've noticed that they are *REALLY* slow. Testsuite Takes like 15 minutes to run on my machine. -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From mposolda at redhat.com Mon Mar 2 07:27:20 2015 From: mposolda at redhat.com (Marek Posolda) Date: Mon, 02 Mar 2015 13:27:20 +0100 Subject: [keycloak-dev] apps access to and refresh of facebook tokens In-Reply-To: <54F0A82C.5030104@redhat.com> References: <54EF3EDB.4060903@redhat.com> <1946967211.20445048.1424966958888.JavaMail.zimbra@redhat.com> <54EF5335.6010501@redhat.com> <1952677297.20565895.1424974594063.JavaMail.zimbra@redhat.com> <54EF68D1.5020504@redhat.com> <999442242.20609060.1424977452320.JavaMail.zimbra@redhat.com> <54EF77BE.3020901@redhat.com> <764234478.20641140.1424980123285.JavaMail.zimbra@redhat.com> <1162494918.16931566.1425017298440.JavaMail.zimbra@redhat.com> <54F093DC.3070702@redhat.com> <54F0A4B7.5090908@redhat.com> <54F0A82C.5030104@redhat.com> Message-ID: <54F45728.7080303@redhat.com> On 27.2.2015 18:23, Bill Burke wrote: > A few more thoughts: > > * Why wouldn't we just ask for long-lived tokens with a social login? > Why wouldn't we set the max SSO session to be shorter than the > long-lived token timeout? Then there is no refresh logic required > > * Google uses refresh tokens. > > * I don't think Twitter expires access tokens :) > > * You could handle this generically without specific broker knowledge. > AccessTokenResponse from a refreshToken call could just state that the > adapter must redirect back to the auth server in order to execute the > refresh. Yeah, however if you are brokering for example to 2nd Keycloak server, you probably don't want to redirect. As accessTokenTimeout in 2nd Keycloak would be like 1 minute, so adapter will need to redirect very often... I was thinking that identity provider can specify if it supports refreshing of tokens or not. Then: * For providers supporting refreshing token, adapter can handle it by Out-of-bound request to auth-server and auth-server can send out-of-band request to brokered provider to refresh 3rdp party token * For providers not supporting refreshing token (like Facebook) adapter would need to redirect But I don't know, maybe we don't need redirection support at all? If all other providers instead of Facebook supports refreshing tokens, we can handle all of those by OOB request and for Facebook use long-lived tokens? Marek > > On 2/27/2015 12:09 PM, Bill Burke wrote: >> FYI, Facebook has 2 types of tokens: >> >> * short lived..usually last for hours >> * long lived usually lasts for 60 days >> >> As Marek pointed out, token refreshes require a browser redirect for >> Facebook. Knowing that, a REST service is not going to be able to >> refresh a facebook token. Let's take this further with an example. >> >> You have a "Contact-List" service that obtains a list of contacts from a >> social provider. You have a separate Javascript application that wants >> to display a list of contacts. The "Contact-List" service has to know >> the token and the social provider type. >> >> So given the above, the Javascript application would have to manage >> facebook tokens. How would that even work? It would have to be done >> without the Javascript app losing its state. >> >> On 2/27/2015 10:57 AM, Bill Burke wrote: >>> On 2/27/2015 1:08 AM, Stian Thorgersen wrote: >>>> I just think we're making something quite simple into something a lot more complex for no benefit. >>>> >>> I think you are making our design more complex or less performant than >>> it needs to be. I don't want a specific endpoint just to refresh a >>> token for a specific broker. We're also going to want to embed nested >>> access tokens for specific keycloak nested application invocations. I >>> don't want a separate REST service just for that too. >>> >>> I also want nested REST invocations to work without having to invoke on >>> the auth server for every request. The access token should have >>> everything the application needs so that it can reduce traffic with the >>> server. What if a stateless, bearer-only REST services needs the >>> facebook token? If we're talking Javascript apps, then the backend will >>> be entirely bearer-only stateless REST services. >>> >>> I don't want to require adapter specific configuration. >>> >>> I the vast majority of cases, I think facebook token refreshing can be >>> handled automatically by the adapter and the auth-server-side configured >>> token policies. We can make the facebook token policy have different >>> configuration options to: >>> >>> * never to refresh the token >>> * modify the access token's expiration to sync with the facebook one. >>> >>> We could add a "scope" parameter to refreshToken endpoint to give a hint >>> to the facebook token policy on whether it needs to refresh or not. >>> >>> Finally, every refreshAccessToken invocation gives the auth-server the >>> opportunity to recheck revocation policies and upgrade/downgrade the >>> user's and application's permissions. >>> From mposolda at redhat.com Mon Mar 2 07:37:18 2015 From: mposolda at redhat.com (Marek Posolda) Date: Mon, 02 Mar 2015 13:37:18 +0100 Subject: [keycloak-dev] mongo tests really slow In-Reply-To: <54F3A37F.1000502@redhat.com> References: <54F3A37F.1000502@redhat.com> Message-ID: <54F4597E.1010608@redhat.com> I've fixed few minor things and mongo testsuite should pass now. But not sure why it's so slow. I've created https://issues.jboss.org/browse/KEYCLOAK-1067 and will take a look what's going on... Marek On 2.3.2015 00:40, Bill Burke wrote: > I'm fixing the mongo tests, and I've noticed that they are*REALLY* > slow. Testsuite Takes like 15 minutes to run on my machine. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150302/a8c96883/attachment.html From bburke at redhat.com Mon Mar 2 09:01:01 2015 From: bburke at redhat.com (Bill Burke) Date: Mon, 02 Mar 2015 09:01:01 -0500 Subject: [keycloak-dev] mongo tests really slow In-Reply-To: <54F4597E.1010608@redhat.com> References: <54F3A37F.1000502@redhat.com> <54F4597E.1010608@redhat.com> Message-ID: <54F46D1D.9050609@redhat.com> Sorry you had to make the fixes too. I was actually tracking build failure problems down too, just didn't commit them. On 3/2/2015 7:37 AM, Marek Posolda wrote: > I've fixed few minor things and mongo testsuite should pass now. But not > sure why it's so slow. I've created > https://issues.jboss.org/browse/KEYCLOAK-1067 and will take a look > what's going on... > > Marek > > On 2.3.2015 00:40, Bill Burke wrote: >> I'm fixing the mongo tests, and I've noticed that they are*REALLY* >> slow. Testsuite Takes like 15 minutes to run on my machine. > -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From mposolda at redhat.com Mon Mar 2 10:18:58 2015 From: mposolda at redhat.com (Marek Posolda) Date: Mon, 02 Mar 2015 16:18:58 +0100 Subject: [keycloak-dev] mongo tests really slow In-Reply-To: <54F46D1D.9050609@redhat.com> References: <54F3A37F.1000502@redhat.com> <54F4597E.1010608@redhat.com> <54F46D1D.9050609@redhat.com> Message-ID: <54F47F62.7040503@redhat.com> oops, ok. Anyway it was an opportunity to look a bit at ProtocolMapper stuff, looks cool! Marek On 2.3.2015 15:01, Bill Burke wrote: > Sorry you had to make the fixes too. I was actually tracking build > failure problems down too, just didn't commit them. > > On 3/2/2015 7:37 AM, Marek Posolda wrote: >> I've fixed few minor things and mongo testsuite should pass now. But not >> sure why it's so slow. I've created >> https://issues.jboss.org/browse/KEYCLOAK-1067 and will take a look >> what's going on... >> >> Marek >> >> On 2.3.2015 00:40, Bill Burke wrote: >>> I'm fixing the mongo tests, and I've noticed that they are*REALLY* >>> slow. Testsuite Takes like 15 minutes to run on my machine. >> > From bburke at redhat.com Mon Mar 2 10:48:36 2015 From: bburke at redhat.com (Bill Burke) Date: Mon, 02 Mar 2015 10:48:36 -0500 Subject: [keycloak-dev] internationalized property references in Javascript Message-ID: <54F48654.60306@redhat.com> Some things are dynamically rendered and configured in the admin console. i.e. identity broker plugins, user federation plugins, and my new protocol claim mapper plugins. For protocol claim mappers each "mapper type" can provide a list of config options, the option's label and help text. To internationalize this, we would need a way to turn a i18n property reference to a value within Javascript as these types of things will be painted by angular js, and not freemarker. -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From stian at redhat.com Mon Mar 2 22:35:16 2015 From: stian at redhat.com (Stian Thorgersen) Date: Mon, 2 Mar 2015 22:35:16 -0500 (EST) Subject: [keycloak-dev] Updating user through Admin rest api In-Reply-To: References: Message-ID: <1860990364.18842141.1425353716418.JavaMail.zimbra@redhat.com> That should work, please create a jira ----- Original Message ----- > From: "Reza Rasouli" > To: keycloak-dev at lists.jboss.org > Sent: Friday, 27 February, 2015 10:28:05 AM > Subject: Re: [keycloak-dev] Updating user through Admin rest api > > ( I am sorry I hit Tab+Enter on mistake) > > hi all, > > when I attemp to update user through the following api call : > > > PUT /admin/realms/{realm}/users/{username} > > with the following request body : > it seems other user information such as email, firstname and lastname gets > wiped : > > > > {"enabled":true} > > shoud the request body on updating the user provide all necessary user field > such as username , email , first and last name ? > > > Thanks. > > On Fri, Feb 27, 2015 at 12:54 PM, Reza Rasouli < ramtinova at gmail.com > wrote: > > > > hi, > > when I attemp to update user through the following api call : > PUT /admin/realms/{realm}/users/{username} > > > > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev From stian at redhat.com Mon Mar 2 22:51:30 2015 From: stian at redhat.com (Stian Thorgersen) Date: Mon, 2 Mar 2015 22:51:30 -0500 (EST) Subject: [keycloak-dev] Fwd: AeroGear OAuth2 - Screencast In-Reply-To: <4CDAC001-717C-4453-BC83-F340CDEA5860@redhat.com> References: <54EC9E23.9050303@redhat.com> <395112279.14759560.1424843157918.JavaMail.zimbra@redhat.com> <8E076C0E-FB33-4D9A-844E-429CA479A5A6@redhat.com> <4CDAC001-717C-4453-BC83-F340CDEA5860@redhat.com> Message-ID: <1749900182.18844349.1425354690808.JavaMail.zimbra@redhat.com> ----- Forwarded Message ----- > From: "Erik Jan de Wit" > To: "Mobile Internal" , "jboss-mobile-internal" > Sent: Friday, 27 February, 2015 1:15:33 PM > Subject: Re: AeroGear OAuth2 - Screencast > > Due to popular demand here is a screen share of keycloak, oauth2 and cordova: > > http://youtu.be/3SHtpQSjGOg > > > On 25 Feb,2015, at 9:14 , Corinne Krych wrote: > > > > Don?t want to spoil Eriks?s surprise but i?ve heard of another video > > picturing Cordova and Keycloak? > > Note we?ll do this demo for your presentation next week: > > http://mdevcon.com/posts/2015/01/09/erik-jan-de-wit-corinne-krych/ > > ++ > > Corinne > >> On 25 Feb 2015, at 06:45, Stian Thorgersen wrote: > >> > >> Really nice, I'd love one that shows using Keycloak instead of Google ;) > >> > >> ----- Original Message ----- > >>> From: "Matthias Wessendorf" > >>> To: "Mobile Internal" , > >>> "jboss-mobile-internal" > >>> Sent: Tuesday, February 24, 2015 4:52:03 PM > >>> Subject: AeroGear OAuth2 - Screencast > >>> > >>> Hello, > >>> > >>> Erik did a nice and short screencast, showing our OAuth2 support for > >>> Windows, Android and iOS: > >>> > >>> https://twitter.com/AeroGears/status/570168411998834688 > >>> > >>> Cheers, > >>> Matthias > >>> > >>> -- > >>> AeroGear project lead > >>> JBoss by Red Hat > >>> > >>> > >> > > > > > > > From stian at redhat.com Mon Mar 2 23:21:51 2015 From: stian at redhat.com (Stian Thorgersen) Date: Mon, 2 Mar 2015 23:21:51 -0500 (EST) Subject: [keycloak-dev] apps access to and refresh of facebook tokens In-Reply-To: <54F45728.7080303@redhat.com> References: <54EF3EDB.4060903@redhat.com> <54EF77BE.3020901@redhat.com> <764234478.20641140.1424980123285.JavaMail.zimbra@redhat.com> <1162494918.16931566.1425017298440.JavaMail.zimbra@redhat.com> <54F093DC.3070702@redhat.com> <54F0A4B7.5090908@redhat.com> <54F0A82C.5030104@redhat.com> <54F45728.7080303@redhat.com> Message-ID: <1010560382.18851129.1425356510994.JavaMail.zimbra@redhat.com> I really think it would be a mistake to include the external tokens into the KC token. It'll make it more complex, especially around refreshing. I don't think it works with what the use-cases of these tokens will be. This is for advanced use-cases and there will be distinct parts of the application that needs the external token, which may not even be called (for example Facebook token is only used when I click the import contact button). A final and to me the strongest argument is that one user account may be linked to many external identities, this would imply that we may end up refreshing many external token each time the internal token is refreshed, which most likely would be pointless as I've stressed before an application will most likely only be using one token at a time and only the token that is required should be refreshed not all of them. ----- Original Message ----- > From: "Marek Posolda" > To: "Bill Burke" , keycloak-dev at lists.jboss.org > Sent: Monday, 2 March, 2015 1:27:20 PM > Subject: Re: [keycloak-dev] apps access to and refresh of facebook tokens > > On 27.2.2015 18:23, Bill Burke wrote: > > A few more thoughts: > > > > * Why wouldn't we just ask for long-lived tokens with a social login? > > Why wouldn't we set the max SSO session to be shorter than the > > long-lived token timeout? Then there is no refresh logic required > > > > * Google uses refresh tokens. > > > > * I don't think Twitter expires access tokens :) > > > > * You could handle this generically without specific broker knowledge. > > AccessTokenResponse from a refreshToken call could just state that the > > adapter must redirect back to the auth server in order to execute the > > refresh. > Yeah, however if you are brokering for example to 2nd Keycloak server, > you probably don't want to redirect. As accessTokenTimeout in 2nd > Keycloak would be like 1 minute, so adapter will need to redirect very > often... > > I was thinking that identity provider can specify if it supports > refreshing of tokens or not. Then: > * For providers supporting refreshing token, adapter can handle it by > Out-of-bound request to auth-server and auth-server can send out-of-band > request to brokered provider to refresh 3rdp party token > * For providers not supporting refreshing token (like Facebook) adapter > would need to redirect > > But I don't know, maybe we don't need redirection support at all? If all > other providers instead of Facebook supports refreshing tokens, we can > handle all of those by OOB request and for Facebook use long-lived tokens? > > Marek > > > > On 2/27/2015 12:09 PM, Bill Burke wrote: > >> FYI, Facebook has 2 types of tokens: > >> > >> * short lived..usually last for hours > >> * long lived usually lasts for 60 days > >> > >> As Marek pointed out, token refreshes require a browser redirect for > >> Facebook. Knowing that, a REST service is not going to be able to > >> refresh a facebook token. Let's take this further with an example. > >> > >> You have a "Contact-List" service that obtains a list of contacts from a > >> social provider. You have a separate Javascript application that wants > >> to display a list of contacts. The "Contact-List" service has to know > >> the token and the social provider type. > >> > >> So given the above, the Javascript application would have to manage > >> facebook tokens. How would that even work? It would have to be done > >> without the Javascript app losing its state. > >> > >> On 2/27/2015 10:57 AM, Bill Burke wrote: > >>> On 2/27/2015 1:08 AM, Stian Thorgersen wrote: > >>>> I just think we're making something quite simple into something a lot > >>>> more complex for no benefit. > >>>> > >>> I think you are making our design more complex or less performant than > >>> it needs to be. I don't want a specific endpoint just to refresh a > >>> token for a specific broker. We're also going to want to embed nested > >>> access tokens for specific keycloak nested application invocations. I > >>> don't want a separate REST service just for that too. > >>> > >>> I also want nested REST invocations to work without having to invoke on > >>> the auth server for every request. The access token should have > >>> everything the application needs so that it can reduce traffic with the > >>> server. What if a stateless, bearer-only REST services needs the > >>> facebook token? If we're talking Javascript apps, then the backend will > >>> be entirely bearer-only stateless REST services. > >>> > >>> I don't want to require adapter specific configuration. > >>> > >>> I the vast majority of cases, I think facebook token refreshing can be > >>> handled automatically by the adapter and the auth-server-side configured > >>> token policies. We can make the facebook token policy have different > >>> configuration options to: > >>> > >>> * never to refresh the token > >>> * modify the access token's expiration to sync with the facebook one. > >>> > >>> We could add a "scope" parameter to refreshToken endpoint to give a hint > >>> to the facebook token policy on whether it needs to refresh or not. > >>> > >>> Finally, every refreshAccessToken invocation gives the auth-server the > >>> opportunity to recheck revocation policies and upgrade/downgrade the > >>> user's and application's permissions. > >>> > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > From stian at redhat.com Tue Mar 3 07:11:12 2015 From: stian at redhat.com (Stian Thorgersen) Date: Tue, 3 Mar 2015 07:11:12 -0500 (EST) Subject: [keycloak-dev] Move Identity Providers and User Federation In-Reply-To: <756308105.19158768.1425384629474.JavaMail.zimbra@redhat.com> Message-ID: <1388169943.19159015.1425384672755.JavaMail.zimbra@redhat.com> I propose we move Identity Providers from Settings and User Federation from Users to the left menu after OAuth Clients. From mposolda at redhat.com Tue Mar 3 09:33:30 2015 From: mposolda at redhat.com (Marek Posolda) Date: Tue, 03 Mar 2015 15:33:30 +0100 Subject: [keycloak-dev] Move Identity Providers and User Federation In-Reply-To: <1388169943.19159015.1425384672755.JavaMail.zimbra@redhat.com> References: <1388169943.19159015.1425384672755.JavaMail.zimbra@redhat.com> Message-ID: <54F5C63A.2090504@redhat.com> +1 On 3.3.2015 13:11, Stian Thorgersen wrote: > I propose we move Identity Providers from Settings and User Federation from Users to the left menu after OAuth Clients. > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev From mposolda at redhat.com Tue Mar 3 09:32:02 2015 From: mposolda at redhat.com (Marek Posolda) Date: Tue, 03 Mar 2015 15:32:02 +0100 Subject: [keycloak-dev] apps access to and refresh of facebook tokens In-Reply-To: <1010560382.18851129.1425356510994.JavaMail.zimbra@redhat.com> References: <54EF3EDB.4060903@redhat.com> <54EF77BE.3020901@redhat.com> <764234478.20641140.1424980123285.JavaMail.zimbra@redhat.com> <1162494918.16931566.1425017298440.JavaMail.zimbra@redhat.com> <54F093DC.3070702@redhat.com> <54F0A4B7.5090908@redhat.com> <54F0A82C.5030104@redhat.com> <54F45728.7080303@redhat.com> <1010560382.18851129.1425356510994.JavaMail.zimbra@redhat.com> Message-ID: <54F5C5E2.6050206@redhat.com> I will try to summary what I had in mind. Looks like hybrid of your approaches: * KC accessToken sent to application will contain all 3rd party tokens and the info when are these 3rd party tokens going to expire * Refreshing KC accessToken from application *will not* refresh 3rd party tokens. Just sent the current 3rd party tokens back again in accessToken * Adapters will have method like "updateThirdpartyToken(String providerId, int maxRemainingExpiration)" . The semantics is similar to the method "updateToken" from keycloak.js (ie. Give me facebook token just if it's not going to expire in next 10 seconds. Otherwise trigger refresh). So refreshing of 3rd party tokens will be triggered just if current 3rd party token is really going to expire. Refreshing will happen through the endpoint on broker (if provider supports refreshing tokens) or through redirect to KC with "idpHint" . Actually I don't know if redirect support is needed as Facebook seem to be only provider, which doesn't support token refreshing, but it has support for long-lived tokens instead. This should ensure minimum amount of HTTP requests between application, auth-server and 3rd party provider. Disadvantage is bigger accessToken, but I assume that it's better to send 1 request with 10 KBytes response instead of 3 separate HTTP request with 1 KByte response each. Isn't it? Marek On 3.3.2015 05:21, Stian Thorgersen wrote: > I really think it would be a mistake to include the external tokens into the KC token. It'll make it more complex, especially around refreshing. I don't think it works with what the use-cases of these tokens will be. This is for advanced use-cases and there will be distinct parts of the application that needs the external token, which may not even be called (for example Facebook token is only used when I click the import contact button). A final and to me the strongest argument is that one user account may be linked to many external identities, this would imply that we may end up refreshing many external token each time the internal token is refreshed, which most likely would be pointless as I've stressed before an application will most likely only be using one token at a time and only the token that is required should be refreshed not all of them. > > ----- Original Message ----- >> From: "Marek Posolda" >> To: "Bill Burke" , keycloak-dev at lists.jboss.org >> Sent: Monday, 2 March, 2015 1:27:20 PM >> Subject: Re: [keycloak-dev] apps access to and refresh of facebook tokens >> >> On 27.2.2015 18:23, Bill Burke wrote: >>> A few more thoughts: >>> >>> * Why wouldn't we just ask for long-lived tokens with a social login? >>> Why wouldn't we set the max SSO session to be shorter than the >>> long-lived token timeout? Then there is no refresh logic required >>> >>> * Google uses refresh tokens. >>> >>> * I don't think Twitter expires access tokens :) >>> >>> * You could handle this generically without specific broker knowledge. >>> AccessTokenResponse from a refreshToken call could just state that the >>> adapter must redirect back to the auth server in order to execute the >>> refresh. >> Yeah, however if you are brokering for example to 2nd Keycloak server, >> you probably don't want to redirect. As accessTokenTimeout in 2nd >> Keycloak would be like 1 minute, so adapter will need to redirect very >> often... >> >> I was thinking that identity provider can specify if it supports >> refreshing of tokens or not. Then: >> * For providers supporting refreshing token, adapter can handle it by >> Out-of-bound request to auth-server and auth-server can send out-of-band >> request to brokered provider to refresh 3rdp party token >> * For providers not supporting refreshing token (like Facebook) adapter >> would need to redirect >> >> But I don't know, maybe we don't need redirection support at all? If all >> other providers instead of Facebook supports refreshing tokens, we can >> handle all of those by OOB request and for Facebook use long-lived tokens? >> >> Marek >>> On 2/27/2015 12:09 PM, Bill Burke wrote: >>>> FYI, Facebook has 2 types of tokens: >>>> >>>> * short lived..usually last for hours >>>> * long lived usually lasts for 60 days >>>> >>>> As Marek pointed out, token refreshes require a browser redirect for >>>> Facebook. Knowing that, a REST service is not going to be able to >>>> refresh a facebook token. Let's take this further with an example. >>>> >>>> You have a "Contact-List" service that obtains a list of contacts from a >>>> social provider. You have a separate Javascript application that wants >>>> to display a list of contacts. The "Contact-List" service has to know >>>> the token and the social provider type. >>>> >>>> So given the above, the Javascript application would have to manage >>>> facebook tokens. How would that even work? It would have to be done >>>> without the Javascript app losing its state. >>>> >>>> On 2/27/2015 10:57 AM, Bill Burke wrote: >>>>> On 2/27/2015 1:08 AM, Stian Thorgersen wrote: >>>>>> I just think we're making something quite simple into something a lot >>>>>> more complex for no benefit. >>>>>> >>>>> I think you are making our design more complex or less performant than >>>>> it needs to be. I don't want a specific endpoint just to refresh a >>>>> token for a specific broker. We're also going to want to embed nested >>>>> access tokens for specific keycloak nested application invocations. I >>>>> don't want a separate REST service just for that too. >>>>> >>>>> I also want nested REST invocations to work without having to invoke on >>>>> the auth server for every request. The access token should have >>>>> everything the application needs so that it can reduce traffic with the >>>>> server. What if a stateless, bearer-only REST services needs the >>>>> facebook token? If we're talking Javascript apps, then the backend will >>>>> be entirely bearer-only stateless REST services. >>>>> >>>>> I don't want to require adapter specific configuration. >>>>> >>>>> I the vast majority of cases, I think facebook token refreshing can be >>>>> handled automatically by the adapter and the auth-server-side configured >>>>> token policies. We can make the facebook token policy have different >>>>> configuration options to: >>>>> >>>>> * never to refresh the token >>>>> * modify the access token's expiration to sync with the facebook one. >>>>> >>>>> We could add a "scope" parameter to refreshToken endpoint to give a hint >>>>> to the facebook token policy on whether it needs to refresh or not. >>>>> >>>>> Finally, every refreshAccessToken invocation gives the auth-server the >>>>> opportunity to recheck revocation policies and upgrade/downgrade the >>>>> user's and application's permissions. >>>>> >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> From bburke at redhat.com Tue Mar 3 10:59:43 2015 From: bburke at redhat.com (Bill Burke) Date: Tue, 03 Mar 2015 10:59:43 -0500 Subject: [keycloak-dev] apps access to and refresh of facebook tokens In-Reply-To: <54F5C5E2.6050206@redhat.com> References: <54EF3EDB.4060903@redhat.com> <54EF77BE.3020901@redhat.com> <764234478.20641140.1424980123285.JavaMail.zimbra@redhat.com> <1162494918.16931566.1425017298440.JavaMail.zimbra@redhat.com> <54F093DC.3070702@redhat.com> <54F0A4B7.5090908@redhat.com> <54F0A82C.5030104@redhat.com> <54F45728.7080303@redhat.com> <1010560382.18851129.1425356510994.JavaMail.zimbra@redhat.com> <54F5C5E2.6050206@redhat.com> Message-ID: <54F5DA6F.1070908@redhat.com> Stateless, bearer-only, REST services will often need a fully populated access token so that they don't have to hit the auth-server each and every request they process. I also see that these REST services will often aggregate calls to other services. Because these services might be a mix of trusted, semi-trusted, untrusted, and anonymous, we will the ability to craft specific access tokens that contain more or less information. Access tokens could even be encrypted and specific to each client. Once I get my claim mappers in place, we can set up any policy we want and the user can choose exactly what they want placed in a token. On 3/3/2015 9:32 AM, Marek Posolda wrote: > I will try to summary what I had in mind. Looks like hybrid of your > approaches: > > * KC accessToken sent to application will contain all 3rd party tokens > and the info when are these 3rd party tokens going to expire > > * Refreshing KC accessToken from application *will not* refresh 3rd > party tokens. Just sent the current 3rd party tokens back again in > accessToken > > * Adapters will have method like "updateThirdpartyToken(String > providerId, int maxRemainingExpiration)" . The semantics is similar to > the method "updateToken" from keycloak.js (ie. Give me facebook token > just if it's not going to expire in next 10 seconds. Otherwise trigger > refresh). So refreshing of 3rd party tokens will be triggered just if > current 3rd party token is really going to expire. Refreshing will > happen through the endpoint on broker (if provider supports refreshing > tokens) or through redirect to KC with "idpHint" . Actually I don't know > if redirect support is needed as Facebook seem to be only provider, > which doesn't support token refreshing, but it has support for > long-lived tokens instead. > > This should ensure minimum amount of HTTP requests between application, > auth-server and 3rd party provider. Disadvantage is bigger accessToken, > but I assume that it's better to send 1 request with 10 KBytes response > instead of 3 separate HTTP request with 1 KByte response each. Isn't it? > > Marek > > On 3.3.2015 05:21, Stian Thorgersen wrote: >> I really think it would be a mistake to include the external tokens >> into the KC token. It'll make it more complex, especially around >> refreshing. I don't think it works with what the use-cases of these >> tokens will be. This is for advanced use-cases and there will be >> distinct parts of the application that needs the external token, which >> may not even be called (for example Facebook token is only used when I >> click the import contact button). A final and to me the strongest >> argument is that one user account may be linked to many external >> identities, this would imply that we may end up refreshing many >> external token each time the internal token is refreshed, which most >> likely would be pointless as I've stressed before an application will >> most likely only be using one token at a time and only the token that >> is required should be refreshed not all of them. >> >> ----- Original Message ----- >>> From: "Marek Posolda" >>> To: "Bill Burke" , keycloak-dev at lists.jboss.org >>> Sent: Monday, 2 March, 2015 1:27:20 PM >>> Subject: Re: [keycloak-dev] apps access to and refresh of facebook >>> tokens >>> >>> On 27.2.2015 18:23, Bill Burke wrote: >>>> A few more thoughts: >>>> >>>> * Why wouldn't we just ask for long-lived tokens with a social login? >>>> Why wouldn't we set the max SSO session to be shorter than the >>>> long-lived token timeout? Then there is no refresh logic required >>>> >>>> * Google uses refresh tokens. >>>> >>>> * I don't think Twitter expires access tokens :) >>>> >>>> * You could handle this generically without specific broker knowledge. >>>> AccessTokenResponse from a refreshToken call could just state that the >>>> adapter must redirect back to the auth server in order to execute the >>>> refresh. >>> Yeah, however if you are brokering for example to 2nd Keycloak server, >>> you probably don't want to redirect. As accessTokenTimeout in 2nd >>> Keycloak would be like 1 minute, so adapter will need to redirect very >>> often... >>> >>> I was thinking that identity provider can specify if it supports >>> refreshing of tokens or not. Then: >>> * For providers supporting refreshing token, adapter can handle it by >>> Out-of-bound request to auth-server and auth-server can send out-of-band >>> request to brokered provider to refresh 3rdp party token >>> * For providers not supporting refreshing token (like Facebook) adapter >>> would need to redirect >>> >>> But I don't know, maybe we don't need redirection support at all? If all >>> other providers instead of Facebook supports refreshing tokens, we can >>> handle all of those by OOB request and for Facebook use long-lived >>> tokens? >>> >>> Marek >>>> On 2/27/2015 12:09 PM, Bill Burke wrote: >>>>> FYI, Facebook has 2 types of tokens: >>>>> >>>>> * short lived..usually last for hours >>>>> * long lived usually lasts for 60 days >>>>> >>>>> As Marek pointed out, token refreshes require a browser redirect for >>>>> Facebook. Knowing that, a REST service is not going to be able to >>>>> refresh a facebook token. Let's take this further with an example. >>>>> >>>>> You have a "Contact-List" service that obtains a list of contacts >>>>> from a >>>>> social provider. You have a separate Javascript application that >>>>> wants >>>>> to display a list of contacts. The "Contact-List" service has to know >>>>> the token and the social provider type. >>>>> >>>>> So given the above, the Javascript application would have to manage >>>>> facebook tokens. How would that even work? It would have to be done >>>>> without the Javascript app losing its state. >>>>> >>>>> On 2/27/2015 10:57 AM, Bill Burke wrote: >>>>>> On 2/27/2015 1:08 AM, Stian Thorgersen wrote: >>>>>>> I just think we're making something quite simple into something a >>>>>>> lot >>>>>>> more complex for no benefit. >>>>>>> >>>>>> I think you are making our design more complex or less performant >>>>>> than >>>>>> it needs to be. I don't want a specific endpoint just to refresh a >>>>>> token for a specific broker. We're also going to want to embed >>>>>> nested >>>>>> access tokens for specific keycloak nested application >>>>>> invocations. I >>>>>> don't want a separate REST service just for that too. >>>>>> >>>>>> I also want nested REST invocations to work without having to >>>>>> invoke on >>>>>> the auth server for every request. The access token should have >>>>>> everything the application needs so that it can reduce traffic >>>>>> with the >>>>>> server. What if a stateless, bearer-only REST services needs the >>>>>> facebook token? If we're talking Javascript apps, then the >>>>>> backend will >>>>>> be entirely bearer-only stateless REST services. >>>>>> >>>>>> I don't want to require adapter specific configuration. >>>>>> >>>>>> I the vast majority of cases, I think facebook token refreshing >>>>>> can be >>>>>> handled automatically by the adapter and the auth-server-side >>>>>> configured >>>>>> token policies. We can make the facebook token policy have different >>>>>> configuration options to: >>>>>> >>>>>> * never to refresh the token >>>>>> * modify the access token's expiration to sync with the facebook one. >>>>>> >>>>>> We could add a "scope" parameter to refreshToken endpoint to give >>>>>> a hint >>>>>> to the facebook token policy on whether it needs to refresh or not. >>>>>> >>>>>> Finally, every refreshAccessToken invocation gives the auth-server >>>>>> the >>>>>> opportunity to recheck revocation policies and upgrade/downgrade the >>>>>> user's and application's permissions. >>>>>> >>> _______________________________________________ >>> keycloak-dev mailing list >>> keycloak-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>> > -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From bburke at redhat.com Tue Mar 3 11:01:41 2015 From: bburke at redhat.com (Bill Burke) Date: Tue, 03 Mar 2015 11:01:41 -0500 Subject: [keycloak-dev] Move Identity Providers and User Federation In-Reply-To: <54F5C63A.2090504@redhat.com> References: <1388169943.19159015.1425384672755.JavaMail.zimbra@redhat.com> <54F5C63A.2090504@redhat.com> Message-ID: <54F5DAE5.1080508@redhat.com> Starting to have too many left menu items. On 3/3/2015 9:33 AM, Marek Posolda wrote: > +1 > > On 3.3.2015 13:11, Stian Thorgersen wrote: >> I propose we move Identity Providers from Settings and User Federation from Users to the left menu after OAuth Clients. >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From guydavis.ca at gmail.com Tue Mar 3 19:10:52 2015 From: guydavis.ca at gmail.com (Guy Davis) Date: Tue, 3 Mar 2015 17:10:52 -0700 Subject: [keycloak-dev] Issue with latest Github master and SAML IDP providers? Message-ID: Good day, I've been using a sample Picketlink IDP locally for testing the SAML v2.0 ID brokering, however after updating to latest master and re-deploying components, I'm getting the following error. Any tips? [image: Inline image 1] Thanks in advance, Guy -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150303/6669310d/attachment-0001.html -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 130637 bytes Desc: not available Url : http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150303/6669310d/attachment-0001.png From stian at redhat.com Wed Mar 4 01:05:16 2015 From: stian at redhat.com (Stian Thorgersen) Date: Wed, 4 Mar 2015 01:05:16 -0500 (EST) Subject: [keycloak-dev] apps access to and refresh of facebook tokens In-Reply-To: <54F5C5E2.6050206@redhat.com> References: <54EF3EDB.4060903@redhat.com> <1162494918.16931566.1425017298440.JavaMail.zimbra@redhat.com> <54F093DC.3070702@redhat.com> <54F0A4B7.5090908@redhat.com> <54F0A82C.5030104@redhat.com> <54F45728.7080303@redhat.com> <1010560382.18851129.1425356510994.JavaMail.zimbra@redhat.com> <54F5C5E2.6050206@redhat.com> Message-ID: <1351514775.20239175.1425449116194.JavaMail.zimbra@redhat.com> ----- Original Message ----- > From: "Marek Posolda" > To: "Stian Thorgersen" > Cc: "Bill Burke" , keycloak-dev at lists.jboss.org > Sent: Tuesday, March 3, 2015 3:32:02 PM > Subject: Re: [keycloak-dev] apps access to and refresh of facebook tokens > > I will try to summary what I had in mind. Looks like hybrid of your > approaches: > > * KC accessToken sent to application will contain all 3rd party tokens > and the info when are these 3rd party tokens going to expire That's a good option to have, but IMO by default no 3rd party tokens should be in there and a user should be able to add those that are needed on a case-by-case. We still need to the endpoint to obtain the access token as well though. A user may want to have a clean token to invoke REST endpoints secured by Keycloak, but still be able to get the Facebook token to use in the web layer. > > * Refreshing KC accessToken from application *will not* refresh 3rd > party tokens. Just sent the current 3rd party tokens back again in > accessToken +10000 To this > > * Adapters will have method like "updateThirdpartyToken(String > providerId, int maxRemainingExpiration)" . The semantics is similar to > the method "updateToken" from keycloak.js (ie. Give me facebook token > just if it's not going to expire in next 10 seconds. Otherwise trigger > refresh). So refreshing of 3rd party tokens will be triggered just if > current 3rd party token is really going to expire. Refreshing will > happen through the endpoint on broker (if provider supports refreshing > tokens) or through redirect to KC with "idpHint" . Actually I don't know > if redirect support is needed as Facebook seem to be only provider, > which doesn't support token refreshing, but it has support for > long-lived tokens instead. +1 Not sure how we'd add that to the servlet adapters though, maybe this is where JEE/CDI support comes in > > This should ensure minimum amount of HTTP requests between application, > auth-server and 3rd party provider. Disadvantage is bigger accessToken, > but I assume that it's better to send 1 request with 10 KBytes response > instead of 3 separate HTTP request with 1 KByte response each. Isn't it? Depends on the scenario. A user should be able to choose between embedding or using separate requests. > > Marek > > On 3.3.2015 05:21, Stian Thorgersen wrote: > > I really think it would be a mistake to include the external tokens into > > the KC token. It'll make it more complex, especially around refreshing. I > > don't think it works with what the use-cases of these tokens will be. This > > is for advanced use-cases and there will be distinct parts of the > > application that needs the external token, which may not even be called > > (for example Facebook token is only used when I click the import contact > > button). A final and to me the strongest argument is that one user account > > may be linked to many external identities, this would imply that we may > > end up refreshing many external token each time the internal token is > > refreshed, which most likely would be pointless as I've stressed before an > > application will most likely only be using one token at a time and only > > the token that is required should be refreshed not all of them. > > > > ----- Original Message ----- > >> From: "Marek Posolda" > >> To: "Bill Burke" , keycloak-dev at lists.jboss.org > >> Sent: Monday, 2 March, 2015 1:27:20 PM > >> Subject: Re: [keycloak-dev] apps access to and refresh of facebook tokens > >> > >> On 27.2.2015 18:23, Bill Burke wrote: > >>> A few more thoughts: > >>> > >>> * Why wouldn't we just ask for long-lived tokens with a social login? > >>> Why wouldn't we set the max SSO session to be shorter than the > >>> long-lived token timeout? Then there is no refresh logic required > >>> > >>> * Google uses refresh tokens. > >>> > >>> * I don't think Twitter expires access tokens :) > >>> > >>> * You could handle this generically without specific broker knowledge. > >>> AccessTokenResponse from a refreshToken call could just state that the > >>> adapter must redirect back to the auth server in order to execute the > >>> refresh. > >> Yeah, however if you are brokering for example to 2nd Keycloak server, > >> you probably don't want to redirect. As accessTokenTimeout in 2nd > >> Keycloak would be like 1 minute, so adapter will need to redirect very > >> often... > >> > >> I was thinking that identity provider can specify if it supports > >> refreshing of tokens or not. Then: > >> * For providers supporting refreshing token, adapter can handle it by > >> Out-of-bound request to auth-server and auth-server can send out-of-band > >> request to brokered provider to refresh 3rdp party token > >> * For providers not supporting refreshing token (like Facebook) adapter > >> would need to redirect > >> > >> But I don't know, maybe we don't need redirection support at all? If all > >> other providers instead of Facebook supports refreshing tokens, we can > >> handle all of those by OOB request and for Facebook use long-lived tokens? > >> > >> Marek > >>> On 2/27/2015 12:09 PM, Bill Burke wrote: > >>>> FYI, Facebook has 2 types of tokens: > >>>> > >>>> * short lived..usually last for hours > >>>> * long lived usually lasts for 60 days > >>>> > >>>> As Marek pointed out, token refreshes require a browser redirect for > >>>> Facebook. Knowing that, a REST service is not going to be able to > >>>> refresh a facebook token. Let's take this further with an example. > >>>> > >>>> You have a "Contact-List" service that obtains a list of contacts from a > >>>> social provider. You have a separate Javascript application that wants > >>>> to display a list of contacts. The "Contact-List" service has to know > >>>> the token and the social provider type. > >>>> > >>>> So given the above, the Javascript application would have to manage > >>>> facebook tokens. How would that even work? It would have to be done > >>>> without the Javascript app losing its state. > >>>> > >>>> On 2/27/2015 10:57 AM, Bill Burke wrote: > >>>>> On 2/27/2015 1:08 AM, Stian Thorgersen wrote: > >>>>>> I just think we're making something quite simple into something a lot > >>>>>> more complex for no benefit. > >>>>>> > >>>>> I think you are making our design more complex or less performant than > >>>>> it needs to be. I don't want a specific endpoint just to refresh a > >>>>> token for a specific broker. We're also going to want to embed nested > >>>>> access tokens for specific keycloak nested application invocations. I > >>>>> don't want a separate REST service just for that too. > >>>>> > >>>>> I also want nested REST invocations to work without having to invoke on > >>>>> the auth server for every request. The access token should have > >>>>> everything the application needs so that it can reduce traffic with the > >>>>> server. What if a stateless, bearer-only REST services needs the > >>>>> facebook token? If we're talking Javascript apps, then the backend > >>>>> will > >>>>> be entirely bearer-only stateless REST services. > >>>>> > >>>>> I don't want to require adapter specific configuration. > >>>>> > >>>>> I the vast majority of cases, I think facebook token refreshing can be > >>>>> handled automatically by the adapter and the auth-server-side > >>>>> configured > >>>>> token policies. We can make the facebook token policy have different > >>>>> configuration options to: > >>>>> > >>>>> * never to refresh the token > >>>>> * modify the access token's expiration to sync with the facebook one. > >>>>> > >>>>> We could add a "scope" parameter to refreshToken endpoint to give a > >>>>> hint > >>>>> to the facebook token policy on whether it needs to refresh or not. > >>>>> > >>>>> Finally, every refreshAccessToken invocation gives the auth-server the > >>>>> opportunity to recheck revocation policies and upgrade/downgrade the > >>>>> user's and application's permissions. > >>>>> > >> _______________________________________________ > >> keycloak-dev mailing list > >> keycloak-dev at lists.jboss.org > >> https://lists.jboss.org/mailman/listinfo/keycloak-dev > >> > > From stian at redhat.com Wed Mar 4 01:09:34 2015 From: stian at redhat.com (Stian Thorgersen) Date: Wed, 4 Mar 2015 01:09:34 -0500 (EST) Subject: [keycloak-dev] Move Identity Providers and User Federation In-Reply-To: <54F5DAE5.1080508@redhat.com> References: <1388169943.19159015.1425384672755.JavaMail.zimbra@redhat.com> <54F5C63A.2090504@redhat.com> <54F5DAE5.1080508@redhat.com> Message-ID: <1418950288.20239857.1425449374537.JavaMail.zimbra@redhat.com> ----- Original Message ----- > From: "Bill Burke" > To: keycloak-dev at lists.jboss.org > Sent: Tuesday, March 3, 2015 5:01:41 PM > Subject: Re: [keycloak-dev] Move Identity Providers and User Federation > > Starting to have too many left menu items. They really are first class citizens and should not be hidden away. Besides, as the left menu is vertical it can take a lot more items than the horizontal menu under realm settings. > > On 3/3/2015 9:33 AM, Marek Posolda wrote: > > +1 > > > > On 3.3.2015 13:11, Stian Thorgersen wrote: > >> I propose we move Identity Providers from Settings and User Federation > >> from Users to the left menu after OAuth Clients. > >> _______________________________________________ > >> keycloak-dev mailing list > >> keycloak-dev at lists.jboss.org > >> https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > > _______________________________________________ > > keycloak-dev mailing list > > keycloak-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > > -- > Bill Burke > JBoss, a division of Red Hat > http://bill.burkecentral.com > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > From mposolda at redhat.com Wed Mar 4 03:07:26 2015 From: mposolda at redhat.com (Marek Posolda) Date: Wed, 04 Mar 2015 09:07:26 +0100 Subject: [keycloak-dev] apps access to and refresh of facebook tokens In-Reply-To: <1351514775.20239175.1425449116194.JavaMail.zimbra@redhat.com> References: <54EF3EDB.4060903@redhat.com> <1162494918.16931566.1425017298440.JavaMail.zimbra@redhat.com> <54F093DC.3070702@redhat.com> <54F0A4B7.5090908@redhat.com> <54F0A82C.5030104@redhat.com> <54F45728.7080303@redhat.com> <1010560382.18851129.1425356510994.JavaMail.zimbra@redhat.com> <54F5C5E2.6050206@redhat.com> <1351514775.20239175.1425449116194.JavaMail.zimbra@redhat.com> Message-ID: <54F6BD3E.9050500@redhat.com> On 4.3.2015 07:05, Stian Thorgersen wrote: > > ----- Original Message ----- >> From: "Marek Posolda" >> To: "Stian Thorgersen" >> Cc: "Bill Burke" , keycloak-dev at lists.jboss.org >> Sent: Tuesday, March 3, 2015 3:32:02 PM >> Subject: Re: [keycloak-dev] apps access to and refresh of facebook tokens >> >> I will try to summary what I had in mind. Looks like hybrid of your >> approaches: >> >> * KC accessToken sent to application will contain all 3rd party tokens >> and the info when are these 3rd party tokens going to expire > That's a good option to have, but IMO by default no 3rd party tokens should be in there and a user should be able to add those that are needed on a case-by-case. We still need to the endpoint to obtain the access token as well though. A user may want to have a clean token to invoke REST endpoints secured by Keycloak, but still be able to get the Facebook token to use in the web layer. yeah, 3rd party tokens will be included just if it's allowed by claims mapping though. So if realm supports facebook authentication, but application doesn't need facebook token, there is no reason to include facebook token in the KC access token. > >> * Refreshing KC accessToken from application *will not* refresh 3rd >> party tokens. Just sent the current 3rd party tokens back again in >> accessToken > +10000 To this > >> * Adapters will have method like "updateThirdpartyToken(String >> providerId, int maxRemainingExpiration)" . The semantics is similar to >> the method "updateToken" from keycloak.js (ie. Give me facebook token >> just if it's not going to expire in next 10 seconds. Otherwise trigger >> refresh). So refreshing of 3rd party tokens will be triggered just if >> current 3rd party token is really going to expire. Refreshing will >> happen through the endpoint on broker (if provider supports refreshing >> tokens) or through redirect to KC with "idpHint" . Actually I don't know >> if redirect support is needed as Facebook seem to be only provider, >> which doesn't support token refreshing, but it has support for >> long-lived tokens instead. > +1 Not sure how we'd add that to the servlet adapters though, maybe this is where JEE/CDI support comes in It could be a method on RefreshableKeycloakSecurityContext? Current methods like getToken on RefreshableKeycloakSecurityContext already works in similar way. It should work fine if we need to support just refreshing by backend requests. If we also need to support redirecting, it could be more tricky as we would need to pass servletResponse to the method somehow as well... On non-related note, I've just noticed potential bug on RefreshableKeycloakSecurityContext;-) It seems there is no time window, so if user calls KeycloakSecurityContext.getToken and it returns him token, which is going to expire soon, the token might be expired before user invokes bearer REST service. Marek > >> This should ensure minimum amount of HTTP requests between application, >> auth-server and 3rd party provider. Disadvantage is bigger accessToken, >> but I assume that it's better to send 1 request with 10 KBytes response >> instead of 3 separate HTTP request with 1 KByte response each. Isn't it? > Depends on the scenario. A user should be able to choose between embedding or using separate requests. > >> Marek >> >> On 3.3.2015 05:21, Stian Thorgersen wrote: >>> I really think it would be a mistake to include the external tokens into >>> the KC token. It'll make it more complex, especially around refreshing. I >>> don't think it works with what the use-cases of these tokens will be. This >>> is for advanced use-cases and there will be distinct parts of the >>> application that needs the external token, which may not even be called >>> (for example Facebook token is only used when I click the import contact >>> button). A final and to me the strongest argument is that one user account >>> may be linked to many external identities, this would imply that we may >>> end up refreshing many external token each time the internal token is >>> refreshed, which most likely would be pointless as I've stressed before an >>> application will most likely only be using one token at a time and only >>> the token that is required should be refreshed not all of them. >>> >>> ----- Original Message ----- >>>> From: "Marek Posolda" >>>> To: "Bill Burke" , keycloak-dev at lists.jboss.org >>>> Sent: Monday, 2 March, 2015 1:27:20 PM >>>> Subject: Re: [keycloak-dev] apps access to and refresh of facebook tokens >>>> >>>> On 27.2.2015 18:23, Bill Burke wrote: >>>>> A few more thoughts: >>>>> >>>>> * Why wouldn't we just ask for long-lived tokens with a social login? >>>>> Why wouldn't we set the max SSO session to be shorter than the >>>>> long-lived token timeout? Then there is no refresh logic required >>>>> >>>>> * Google uses refresh tokens. >>>>> >>>>> * I don't think Twitter expires access tokens :) >>>>> >>>>> * You could handle this generically without specific broker knowledge. >>>>> AccessTokenResponse from a refreshToken call could just state that the >>>>> adapter must redirect back to the auth server in order to execute the >>>>> refresh. >>>> Yeah, however if you are brokering for example to 2nd Keycloak server, >>>> you probably don't want to redirect. As accessTokenTimeout in 2nd >>>> Keycloak would be like 1 minute, so adapter will need to redirect very >>>> often... >>>> >>>> I was thinking that identity provider can specify if it supports >>>> refreshing of tokens or not. Then: >>>> * For providers supporting refreshing token, adapter can handle it by >>>> Out-of-bound request to auth-server and auth-server can send out-of-band >>>> request to brokered provider to refresh 3rdp party token >>>> * For providers not supporting refreshing token (like Facebook) adapter >>>> would need to redirect >>>> >>>> But I don't know, maybe we don't need redirection support at all? If all >>>> other providers instead of Facebook supports refreshing tokens, we can >>>> handle all of those by OOB request and for Facebook use long-lived tokens? >>>> >>>> Marek >>>>> On 2/27/2015 12:09 PM, Bill Burke wrote: >>>>>> FYI, Facebook has 2 types of tokens: >>>>>> >>>>>> * short lived..usually last for hours >>>>>> * long lived usually lasts for 60 days >>>>>> >>>>>> As Marek pointed out, token refreshes require a browser redirect for >>>>>> Facebook. Knowing that, a REST service is not going to be able to >>>>>> refresh a facebook token. Let's take this further with an example. >>>>>> >>>>>> You have a "Contact-List" service that obtains a list of contacts from a >>>>>> social provider. You have a separate Javascript application that wants >>>>>> to display a list of contacts. The "Contact-List" service has to know >>>>>> the token and the social provider type. >>>>>> >>>>>> So given the above, the Javascript application would have to manage >>>>>> facebook tokens. How would that even work? It would have to be done >>>>>> without the Javascript app losing its state. >>>>>> >>>>>> On 2/27/2015 10:57 AM, Bill Burke wrote: >>>>>>> On 2/27/2015 1:08 AM, Stian Thorgersen wrote: >>>>>>>> I just think we're making something quite simple into something a lot >>>>>>>> more complex for no benefit. >>>>>>>> >>>>>>> I think you are making our design more complex or less performant than >>>>>>> it needs to be. I don't want a specific endpoint just to refresh a >>>>>>> token for a specific broker. We're also going to want to embed nested >>>>>>> access tokens for specific keycloak nested application invocations. I >>>>>>> don't want a separate REST service just for that too. >>>>>>> >>>>>>> I also want nested REST invocations to work without having to invoke on >>>>>>> the auth server for every request. The access token should have >>>>>>> everything the application needs so that it can reduce traffic with the >>>>>>> server. What if a stateless, bearer-only REST services needs the >>>>>>> facebook token? If we're talking Javascript apps, then the backend >>>>>>> will >>>>>>> be entirely bearer-only stateless REST services. >>>>>>> >>>>>>> I don't want to require adapter specific configuration. >>>>>>> >>>>>>> I the vast majority of cases, I think facebook token refreshing can be >>>>>>> handled automatically by the adapter and the auth-server-side >>>>>>> configured >>>>>>> token policies. We can make the facebook token policy have different >>>>>>> configuration options to: >>>>>>> >>>>>>> * never to refresh the token >>>>>>> * modify the access token's expiration to sync with the facebook one. >>>>>>> >>>>>>> We could add a "scope" parameter to refreshToken endpoint to give a >>>>>>> hint >>>>>>> to the facebook token policy on whether it needs to refresh or not. >>>>>>> >>>>>>> Finally, every refreshAccessToken invocation gives the auth-server the >>>>>>> opportunity to recheck revocation policies and upgrade/downgrade the >>>>>>> user's and application's permissions. >>>>>>> >>>> _______________________________________________ >>>> keycloak-dev mailing list >>>> keycloak-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>>> >> From stian at redhat.com Wed Mar 4 03:18:08 2015 From: stian at redhat.com (Stian Thorgersen) Date: Wed, 4 Mar 2015 03:18:08 -0500 (EST) Subject: [keycloak-dev] apps access to and refresh of facebook tokens In-Reply-To: <54F6BD3E.9050500@redhat.com> References: <54EF3EDB.4060903@redhat.com> <54F0A4B7.5090908@redhat.com> <54F0A82C.5030104@redhat.com> <54F45728.7080303@redhat.com> <1010560382.18851129.1425356510994.JavaMail.zimbra@redhat.com> <54F5C5E2.6050206@redhat.com> <1351514775.20239175.1425449116194.JavaMail.zimbra@redhat.com> <54F6BD3E.9050500@redhat.com> Message-ID: <1541029134.20281868.1425457088695.JavaMail.zimbra@redhat.com> ----- Original Message ----- > From: "Marek Posolda" > To: "Stian Thorgersen" > Cc: "Bill Burke" , keycloak-dev at lists.jboss.org > Sent: Wednesday, March 4, 2015 9:07:26 AM > Subject: Re: [keycloak-dev] apps access to and refresh of facebook tokens > > On 4.3.2015 07:05, Stian Thorgersen wrote: > > > > ----- Original Message ----- > >> From: "Marek Posolda" > >> To: "Stian Thorgersen" > >> Cc: "Bill Burke" , keycloak-dev at lists.jboss.org > >> Sent: Tuesday, March 3, 2015 3:32:02 PM > >> Subject: Re: [keycloak-dev] apps access to and refresh of facebook tokens > >> > >> I will try to summary what I had in mind. Looks like hybrid of your > >> approaches: > >> > >> * KC accessToken sent to application will contain all 3rd party tokens > >> and the info when are these 3rd party tokens going to expire > > That's a good option to have, but IMO by default no 3rd party tokens should > > be in there and a user should be able to add those that are needed on a > > case-by-case. We still need to the endpoint to obtain the access token as > > well though. A user may want to have a clean token to invoke REST > > endpoints secured by Keycloak, but still be able to get the Facebook token > > to use in the web layer. > yeah, 3rd party tokens will be included just if it's allowed by claims > mapping though. So if realm supports facebook authentication, but > application doesn't need facebook token, there is no reason to include > facebook token in the KC access token. > > > >> * Refreshing KC accessToken from application *will not* refresh 3rd > >> party tokens. Just sent the current 3rd party tokens back again in > >> accessToken > > +10000 To this > > > >> * Adapters will have method like "updateThirdpartyToken(String > >> providerId, int maxRemainingExpiration)" . The semantics is similar to > >> the method "updateToken" from keycloak.js (ie. Give me facebook token > >> just if it's not going to expire in next 10 seconds. Otherwise trigger > >> refresh). So refreshing of 3rd party tokens will be triggered just if > >> current 3rd party token is really going to expire. Refreshing will > >> happen through the endpoint on broker (if provider supports refreshing > >> tokens) or through redirect to KC with "idpHint" . Actually I don't know > >> if redirect support is needed as Facebook seem to be only provider, > >> which doesn't support token refreshing, but it has support for > >> long-lived tokens instead. > > +1 Not sure how we'd add that to the servlet adapters though, maybe this is > > where JEE/CDI support comes in > It could be a method on RefreshableKeycloakSecurityContext? Current > methods like getToken on RefreshableKeycloakSecurityContext already > works in similar way. > It should work fine if we need to support just refreshing by backend > requests. If we also need to support redirecting, it could be more > tricky as we would need to pass servletResponse to the method somehow as > well... -1 To refreshing by redirect > > On non-related note, I've just noticed potential bug on > RefreshableKeycloakSecurityContext;-) > It seems there is no time window, so if user calls > KeycloakSecurityContext.getToken and it returns him token, which is > going to expire soon, the token might be expired before user invokes > bearer REST service. Yep, another thing I've thought about is what about if time is different on KC server and app? That's even worse in keycloak.js > > Marek > > > >> This should ensure minimum amount of HTTP requests between application, > >> auth-server and 3rd party provider. Disadvantage is bigger accessToken, > >> but I assume that it's better to send 1 request with 10 KBytes response > >> instead of 3 separate HTTP request with 1 KByte response each. Isn't it? > > Depends on the scenario. A user should be able to choose between embedding > > or using separate requests. > > > >> Marek > >> > >> On 3.3.2015 05:21, Stian Thorgersen wrote: > >>> I really think it would be a mistake to include the external tokens into > >>> the KC token. It'll make it more complex, especially around refreshing. I > >>> don't think it works with what the use-cases of these tokens will be. > >>> This > >>> is for advanced use-cases and there will be distinct parts of the > >>> application that needs the external token, which may not even be called > >>> (for example Facebook token is only used when I click the import contact > >>> button). A final and to me the strongest argument is that one user > >>> account > >>> may be linked to many external identities, this would imply that we may > >>> end up refreshing many external token each time the internal token is > >>> refreshed, which most likely would be pointless as I've stressed before > >>> an > >>> application will most likely only be using one token at a time and only > >>> the token that is required should be refreshed not all of them. > >>> > >>> ----- Original Message ----- > >>>> From: "Marek Posolda" > >>>> To: "Bill Burke" , keycloak-dev at lists.jboss.org > >>>> Sent: Monday, 2 March, 2015 1:27:20 PM > >>>> Subject: Re: [keycloak-dev] apps access to and refresh of facebook > >>>> tokens > >>>> > >>>> On 27.2.2015 18:23, Bill Burke wrote: > >>>>> A few more thoughts: > >>>>> > >>>>> * Why wouldn't we just ask for long-lived tokens with a social login? > >>>>> Why wouldn't we set the max SSO session to be shorter than the > >>>>> long-lived token timeout? Then there is no refresh logic required > >>>>> > >>>>> * Google uses refresh tokens. > >>>>> > >>>>> * I don't think Twitter expires access tokens :) > >>>>> > >>>>> * You could handle this generically without specific broker knowledge. > >>>>> AccessTokenResponse from a refreshToken call could just state that the > >>>>> adapter must redirect back to the auth server in order to execute the > >>>>> refresh. > >>>> Yeah, however if you are brokering for example to 2nd Keycloak server, > >>>> you probably don't want to redirect. As accessTokenTimeout in 2nd > >>>> Keycloak would be like 1 minute, so adapter will need to redirect very > >>>> often... > >>>> > >>>> I was thinking that identity provider can specify if it supports > >>>> refreshing of tokens or not. Then: > >>>> * For providers supporting refreshing token, adapter can handle it by > >>>> Out-of-bound request to auth-server and auth-server can send out-of-band > >>>> request to brokered provider to refresh 3rdp party token > >>>> * For providers not supporting refreshing token (like Facebook) adapter > >>>> would need to redirect > >>>> > >>>> But I don't know, maybe we don't need redirection support at all? If all > >>>> other providers instead of Facebook supports refreshing tokens, we can > >>>> handle all of those by OOB request and for Facebook use long-lived > >>>> tokens? > >>>> > >>>> Marek > >>>>> On 2/27/2015 12:09 PM, Bill Burke wrote: > >>>>>> FYI, Facebook has 2 types of tokens: > >>>>>> > >>>>>> * short lived..usually last for hours > >>>>>> * long lived usually lasts for 60 days > >>>>>> > >>>>>> As Marek pointed out, token refreshes require a browser redirect for > >>>>>> Facebook. Knowing that, a REST service is not going to be able to > >>>>>> refresh a facebook token. Let's take this further with an example. > >>>>>> > >>>>>> You have a "Contact-List" service that obtains a list of contacts from > >>>>>> a > >>>>>> social provider. You have a separate Javascript application that > >>>>>> wants > >>>>>> to display a list of contacts. The "Contact-List" service has to know > >>>>>> the token and the social provider type. > >>>>>> > >>>>>> So given the above, the Javascript application would have to manage > >>>>>> facebook tokens. How would that even work? It would have to be done > >>>>>> without the Javascript app losing its state. > >>>>>> > >>>>>> On 2/27/2015 10:57 AM, Bill Burke wrote: > >>>>>>> On 2/27/2015 1:08 AM, Stian Thorgersen wrote: > >>>>>>>> I just think we're making something quite simple into something a > >>>>>>>> lot > >>>>>>>> more complex for no benefit. > >>>>>>>> > >>>>>>> I think you are making our design more complex or less performant > >>>>>>> than > >>>>>>> it needs to be. I don't want a specific endpoint just to refresh a > >>>>>>> token for a specific broker. We're also going to want to embed > >>>>>>> nested > >>>>>>> access tokens for specific keycloak nested application invocations. > >>>>>>> I > >>>>>>> don't want a separate REST service just for that too. > >>>>>>> > >>>>>>> I also want nested REST invocations to work without having to invoke > >>>>>>> on > >>>>>>> the auth server for every request. The access token should have > >>>>>>> everything the application needs so that it can reduce traffic with > >>>>>>> the > >>>>>>> server. What if a stateless, bearer-only REST services needs the > >>>>>>> facebook token? If we're talking Javascript apps, then the backend > >>>>>>> will > >>>>>>> be entirely bearer-only stateless REST services. > >>>>>>> > >>>>>>> I don't want to require adapter specific configuration. > >>>>>>> > >>>>>>> I the vast majority of cases, I think facebook token refreshing can > >>>>>>> be > >>>>>>> handled automatically by the adapter and the auth-server-side > >>>>>>> configured > >>>>>>> token policies. We can make the facebook token policy have different > >>>>>>> configuration options to: > >>>>>>> > >>>>>>> * never to refresh the token > >>>>>>> * modify the access token's expiration to sync with the facebook one. > >>>>>>> > >>>>>>> We could add a "scope" parameter to refreshToken endpoint to give a > >>>>>>> hint > >>>>>>> to the facebook token policy on whether it needs to refresh or not. > >>>>>>> > >>>>>>> Finally, every refreshAccessToken invocation gives the auth-server > >>>>>>> the > >>>>>>> opportunity to recheck revocation policies and upgrade/downgrade the > >>>>>>> user's and application's permissions. > >>>>>>> > >>>> _______________________________________________ > >>>> keycloak-dev mailing list > >>>> keycloak-dev at lists.jboss.org > >>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev > >>>> > >> > > From bburke at redhat.com Wed Mar 4 09:11:26 2015 From: bburke at redhat.com (Bill Burke) Date: Wed, 04 Mar 2015 09:11:26 -0500 Subject: [keycloak-dev] apps access to and refresh of facebook tokens In-Reply-To: <1541029134.20281868.1425457088695.JavaMail.zimbra@redhat.com> References: <54EF3EDB.4060903@redhat.com> <54F0A4B7.5090908@redhat.com> <54F0A82C.5030104@redhat.com> <54F45728.7080303@redhat.com> <1010560382.18851129.1425356510994.JavaMail.zimbra@redhat.com> <54F5C5E2.6050206@redhat.com> <1351514775.20239175.1425449116194.JavaMail.zimbra@redhat.com> <54F6BD3E.9050500@redhat.com> <1541029134.20281868.1425457088695.JavaMail.zimbra@redhat.com> Message-ID: <54F7128E.1050309@redhat.com> On 3/4/2015 3:18 AM, Stian Thorgersen wrote: >> It should work fine if we need to support just refreshing by backend >> requests. If we also need to support redirecting, it could be more >> tricky as we would need to pass servletResponse to the method somehow as >> well... > > -1 To refreshing by redirect > I think you're missing a lot of how external tokens will be used and what environments they will be deployed into. Futhermore I think your refresh and token embedding concerns are either overblown, non-existent, add extra complexity to the user, or hurt performance for common setups. Finally, automatic refreshing needs to happen in order for logout to work propoerly. * Facebook tokens can only be refreshed by redirect. * REST services will not be able to refresh Facebook tokens because of the redirect requirement * Facebook short-lived tokens last for hours. Long-lived tokens last for 60 days. * Twitter tokens don't expire. * OIDC does not have a Single Logout Service like SAML does. This means that the only way to determine if a parent OIDC Broker has logged out the user is to try and refresh the token. * REST services should not have to hit the auth-server for *EVERY REQUEST*. * clients should not have to manage external tokens, unless of course they want to. Consider a pure OAuth example where you have a OAuth client that doesn't know anything about the access token format. This OAuth client is talking to a REST service. Your proposed default set up requires the REST service to hit the auth server every single request. * Keycloak controlled external tokens can be refreshed automatically without network calls. I guess we need the token exchange service, but such a service is something that will only be needed in rare cases otherwise. Letting Keycloak handle external tokens automatically reduces code the user has to write and takes request load off of the Keycloak auth server. Your concern that refreshing tokens automatically will hurt performance is just bogus. Automatic token refresh can't even be done with Facebook. You don't even need token refresh for Facebook because long-lived tokens last 60 days. Refresh isn't even needed for Twitter as their tokens last forever. OIDC brokered tokens need to have refresh called to determine if the session has been logged out from the parent broker. -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From daniel.baxter at cira.ca Wed Mar 4 11:47:07 2015 From: daniel.baxter at cira.ca (Daniel Baxter) Date: Wed, 4 Mar 2015 16:47:07 +0000 Subject: [keycloak-dev] POST to /realms/{realm}/account/password results in server 500 Message-ID: <152ADF7679FD37488EE24A3FB5CA9AE1D4F42A49@EXCH-01.CORP.CIRA.CA> Hi, I am trying to implement a remote user password change for the logged in user. This is a requirement for the protocol we are required to support which accepts xml formatted commands over a network port, one of which is a password change request. The user is logged in via a Direct Grant from the Remoting application and we have a full KeycloakPrincipal attached to each remote session. When I POST to the form at /realms/{realm}/account/password using a Bearer Auth the password does reset but I get a 500 status back from Keycloak. The issue is that it is trying to rebuild an html response from the 'password.ftl' template and it does not have a value for 'stateChecker'. After reviewing the code on github I found that if you use Bearer Auth, AccountService.init() never initializes a value to stateChecker. So even though I passed one in as a cookie on the POST and inside the form itself it never gets read. The workaround is to use cookies only to handle the authentication mechanism; specifically KEYCLOAK_STATE_CHECKER and KEYCLOAK_IDENTITY and not include Bearer authentication at all. So there is a workaround and it requires the use of cookies only and not Bearer Auth. I know this is not really the intended use of the POST to this form (eg: using it like a REST endpoint), but if anyone else runs into this issue at least they can learn from what I found by searching the mailing list archives. So this leaves me with a couple of questions Why does using Bearer Auth not initialize some sort of value for stateChecker here (ie: Is this a bug)? When you use cookies it appears to even generate a value for stateChecker if none is found in the cookie. What is the purpose of embedding it as a hidden input on the password change form? It appears to never get read when the form is processed anyways. Thanks, Daniel -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150304/acc511fa/attachment.html From bburke at redhat.com Wed Mar 4 11:59:38 2015 From: bburke at redhat.com (Bill Burke) Date: Wed, 04 Mar 2015 11:59:38 -0500 Subject: [keycloak-dev] POST to /realms/{realm}/account/password results in server 500 In-Reply-To: <152ADF7679FD37488EE24A3FB5CA9AE1D4F42A49@EXCH-01.CORP.CIRA.CA> References: <152ADF7679FD37488EE24A3FB5CA9AE1D4F42A49@EXCH-01.CORP.CIRA.CA> Message-ID: <54F739FA.4020603@redhat.com> The stateChecker exists to protect against CSRF browser attacks. I think we can ignore this check if the request is bearer authenticated. Submit a JIRA please? On 3/4/2015 11:47 AM, Daniel Baxter wrote: > Hi, > > I am trying to implement a remote user password change for the logged > in user. This is a requirement for the protocol we are required to > support which accepts xml formatted commands over a network port, one of > which is a password change request. The user is logged in via a Direct > Grant from the Remoting application and we have a full KeycloakPrincipal > attached to each remote session. When I POST to the form at > /realms/{realm}/account/password using a Bearer Auth the password does > reset but I get a 500 status back from Keycloak. The issue is that it is > trying to rebuild an html response from the ?password.ftl? template and > it does not have a value for ?stateChecker?. > > After reviewing the code on github I found that if you use Bearer Auth, > AccountService.init() never initializes a value to stateChecker. So even > though I passed one in as a cookie on the POST and inside the form > itself it never gets read. The workaround is to use cookies only to > handle the authentication mechanism; specifically KEYCLOAK_STATE_CHECKER > and KEYCLOAK_IDENTITY and not include Bearer authentication at all. So > there is a workaround and it requires the use of cookies only and not > Bearer Auth. I know this is not really the intended use of the POST to > this form (eg: using it like a REST endpoint), but if anyone else runs > into this issue at least they can learn from what I found by searching > the mailing list archives. > > So this leaves me with a couple of questions > > Why does using Bearer Auth not initialize some sort of value for > stateChecker here (ie: Is this a bug)? When you use cookies it appears > to even generate a value for stateChecker if none is found in the cookie. > > What is the purpose of embedding it as a hidden input on the password > change form? It appears to never get read when the form is processed > anyways. > > Thanks, > > Daniel > > > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From daniel.baxter at cira.ca Wed Mar 4 13:31:06 2015 From: daniel.baxter at cira.ca (Daniel Baxter) Date: Wed, 4 Mar 2015 18:31:06 +0000 Subject: [keycloak-dev] POST to /realms/{realm}/account/password results in server 500 In-Reply-To: <54F739FA.4020603@redhat.com> References: <152ADF7679FD37488EE24A3FB5CA9AE1D4F42A49@EXCH-01.CORP.CIRA.CA> <54F739FA.4020603@redhat.com> Message-ID: <152ADF7679FD37488EE24A3FB5CA9AE1D4F45AC0@EXCH-01.CORP.CIRA.CA> Thanks for the reply Bill. Raised as https://issues.jboss.org/browse/KEYCLOAK-1081 -----Original Message----- From: keycloak-dev-bounces at lists.jboss.org [mailto:keycloak-dev-bounces at lists.jboss.org] On Behalf Of Bill Burke Sent: Wednesday, March 04, 2015 12:00 PM To: keycloak-dev at lists.jboss.org Subject: Re: [keycloak-dev] POST to /realms/{realm}/account/password results in server 500 The stateChecker exists to protect against CSRF browser attacks. I think we can ignore this check if the request is bearer authenticated. Submit a JIRA please? On 3/4/2015 11:47 AM, Daniel Baxter wrote: > Hi, > > I am trying to implement a remote user password change for the logged > in user. This is a requirement for the protocol we are required to > support which accepts xml formatted commands over a network port, one > of which is a password change request. The user is logged in via a > Direct Grant from the Remoting application and we have a full > KeycloakPrincipal attached to each remote session. When I POST to the > form at /realms/{realm}/account/password using a Bearer Auth the > password does reset but I get a 500 status back from Keycloak. The > issue is that it is trying to rebuild an html response from the > 'password.ftl' template and it does not have a value for 'stateChecker'. > > After reviewing the code on github I found that if you use Bearer > Auth, > AccountService.init() never initializes a value to stateChecker. So > even though I passed one in as a cookie on the POST and inside the > form itself it never gets read. The workaround is to use cookies only > to handle the authentication mechanism; specifically > KEYCLOAK_STATE_CHECKER and KEYCLOAK_IDENTITY and not include Bearer > authentication at all. So there is a workaround and it requires the > use of cookies only and not Bearer Auth. I know this is not really the > intended use of the POST to this form (eg: using it like a REST > endpoint), but if anyone else runs into this issue at least they can > learn from what I found by searching the mailing list archives. > > So this leaves me with a couple of questions > > Why does using Bearer Auth not initialize some sort of value for > stateChecker here (ie: Is this a bug)? When you use cookies it appears > to even generate a value for stateChecker if none is found in the cookie. > > What is the purpose of embedding it as a hidden input on the password > change form? It appears to never get read when the form is processed > anyways. > > Thanks, > > Daniel > > > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com _______________________________________________ keycloak-dev mailing list keycloak-dev at lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-dev From muditsaxena77 at gmail.com Wed Mar 4 14:20:06 2015 From: muditsaxena77 at gmail.com (MUDIT SAXENA) Date: Thu, 5 Mar 2015 00:50:06 +0530 Subject: [keycloak-dev] Introduction- GSOC 2015 Message-ID: Hello, I am Mudit Saxena from India. I am pursuing B.Tech in Computer Science & Engineering . I am a java developer and have commited myself to different projects in JAVA. I looking forward to GSOC-2015 and want be a part of the open source community. Thank you, Regard, Mudit Saxena -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150305/690b4556/attachment.html From stian at redhat.com Thu Mar 5 00:27:46 2015 From: stian at redhat.com (Stian Thorgersen) Date: Thu, 5 Mar 2015 00:27:46 -0500 (EST) Subject: [keycloak-dev] POST to /realms/{realm}/account/password results in server 500 In-Reply-To: <152ADF7679FD37488EE24A3FB5CA9AE1D4F45AC0@EXCH-01.CORP.CIRA.CA> References: <152ADF7679FD37488EE24A3FB5CA9AE1D4F42A49@EXCH-01.CORP.CIRA.CA> <54F739FA.4020603@redhat.com> <152ADF7679FD37488EE24A3FB5CA9AE1D4F45AC0@EXCH-01.CORP.CIRA.CA> Message-ID: <52917668.21042115.1425533266336.JavaMail.zimbra@redhat.com> We should add proper REST support to account, see https://issues.jboss.org/browse/KEYCLOAK-943 ----- Original Message ----- > From: "Daniel Baxter" > To: "Bill Burke" , keycloak-dev at lists.jboss.org > Sent: Wednesday, March 4, 2015 7:31:06 PM > Subject: Re: [keycloak-dev] POST to /realms/{realm}/account/password results in server 500 > > Thanks for the reply Bill. Raised as > https://issues.jboss.org/browse/KEYCLOAK-1081 > > -----Original Message----- > From: keycloak-dev-bounces at lists.jboss.org > [mailto:keycloak-dev-bounces at lists.jboss.org] On Behalf Of Bill Burke > Sent: Wednesday, March 04, 2015 12:00 PM > To: keycloak-dev at lists.jboss.org > Subject: Re: [keycloak-dev] POST to /realms/{realm}/account/password results > in server 500 > > The stateChecker exists to protect against CSRF browser attacks. I think we > can ignore this check if the request is bearer authenticated. > Submit a JIRA please? > > On 3/4/2015 11:47 AM, Daniel Baxter wrote: > > Hi, > > > > I am trying to implement a remote user password change for the logged > > in user. This is a requirement for the protocol we are required to > > support which accepts xml formatted commands over a network port, one > > of which is a password change request. The user is logged in via a > > Direct Grant from the Remoting application and we have a full > > KeycloakPrincipal attached to each remote session. When I POST to the > > form at /realms/{realm}/account/password using a Bearer Auth the > > password does reset but I get a 500 status back from Keycloak. The > > issue is that it is trying to rebuild an html response from the > > 'password.ftl' template and it does not have a value for 'stateChecker'. > > > > After reviewing the code on github I found that if you use Bearer > > Auth, > > AccountService.init() never initializes a value to stateChecker. So > > even though I passed one in as a cookie on the POST and inside the > > form itself it never gets read. The workaround is to use cookies only > > to handle the authentication mechanism; specifically > > KEYCLOAK_STATE_CHECKER and KEYCLOAK_IDENTITY and not include Bearer > > authentication at all. So there is a workaround and it requires the > > use of cookies only and not Bearer Auth. I know this is not really the > > intended use of the POST to this form (eg: using it like a REST > > endpoint), but if anyone else runs into this issue at least they can > > learn from what I found by searching the mailing list archives. > > > > So this leaves me with a couple of questions > > > > Why does using Bearer Auth not initialize some sort of value for > > stateChecker here (ie: Is this a bug)? When you use cookies it appears > > to even generate a value for stateChecker if none is found in the cookie. > > > > What is the purpose of embedding it as a hidden input on the password > > change form? It appears to never get read when the form is processed > > anyways. > > > > Thanks, > > > > Daniel > > > > > > > > _______________________________________________ > > keycloak-dev mailing list > > keycloak-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > > -- > Bill Burke > JBoss, a division of Red Hat > http://bill.burkecentral.com > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > From stian at redhat.com Thu Mar 5 01:05:06 2015 From: stian at redhat.com (Stian Thorgersen) Date: Thu, 5 Mar 2015 01:05:06 -0500 (EST) Subject: [keycloak-dev] apps access to and refresh of facebook tokens In-Reply-To: <54F7128E.1050309@redhat.com> References: <54EF3EDB.4060903@redhat.com> <54F45728.7080303@redhat.com> <1010560382.18851129.1425356510994.JavaMail.zimbra@redhat.com> <54F5C5E2.6050206@redhat.com> <1351514775.20239175.1425449116194.JavaMail.zimbra@redhat.com> <54F6BD3E.9050500@redhat.com> <1541029134.20281868.1425457088695.JavaMail.zimbra@redhat.com> <54F7128E.1050309@redhat.com> Message-ID: <1685748807.21051150.1425535506233.JavaMail.zimbra@redhat.com> Some comments in-line below, but I'm happy if we do the following: * Don't include any external tokens by default, but make it easy to add those that are required. This should probably be on a per-app basis * We can drop the token exchange service. If this is required we can add it when someone asks for it * In the future add a feature to retrieve multiple tokens, for example a HTML5 app that invokes both Facebook and another REST service should be able not to expose the Facebook token to the REST service. I'd also like to see the token downgrade feature we discussed, or maybe the downgrade feature can support both ----- Original Message ----- > From: "Bill Burke" > To: "Stian Thorgersen" , "Marek Posolda" > Cc: keycloak-dev at lists.jboss.org > Sent: Wednesday, March 4, 2015 3:11:26 PM > Subject: Re: [keycloak-dev] apps access to and refresh of facebook tokens > > > > On 3/4/2015 3:18 AM, Stian Thorgersen wrote: > >> It should work fine if we need to support just refreshing by backend > >> requests. If we also need to support redirecting, it could be more > >> tricky as we would need to pass servletResponse to the method somehow as > >> well... > > > > -1 To refreshing by redirect > > > > I think you're missing a lot of how external tokens will be used and > what environments they will be deployed into. Futhermore I think your > refresh and token embedding concerns are either overblown, non-existent, > add extra complexity to the user, or hurt performance for common setups. > Finally, automatic refreshing needs to happen in order for logout to > work propoerly. Common setups won't need the external tokens, the most common use-case will be login only. So that means refreshing them all the time is a waste of external requests and more traffic which hurts performance. > > * Facebook tokens can only be refreshed by redirect. > * REST services will not be able to refresh Facebook tokens because of > the redirect requirement > * Facebook short-lived tokens last for hours. Long-lived tokens last > for 60 days. Neither the flow I propose or the flow you propose can refresh a Facebook token if it doesn't support refreshing it, so this is an invalid argument IMO > * Twitter tokens don't expire. > * OIDC does not have a Single Logout Service like SAML does. This means > that the only way to determine if a parent OIDC Broker has logged out > the user is to try and refresh the token. That argument is only valid for a single token, which is the token that was used to login the current user session. This approach would only work if the external token has a shortish timeout. Also, that doesn't mean the external token has to be included in internal token. > * REST services should not have to hit the auth-server for *EVERY REQUEST*. > * clients should not have to manage external tokens, unless of course > they want to. Consider a pure OAuth example where you have a OAuth > client that doesn't know anything about the access token format. This > OAuth client is talking to a REST service. Your proposed default set up > requires the REST service to hit the auth server every single request. Ok, that's a very good point, but still only the external tokens that are required should be added to the token. > * Keycloak controlled external tokens can be refreshed automatically > without network calls. How can Keycloak refresh external tokens without network calls? > > I guess we need the token exchange service, but such a service is > something that will only be needed in rare cases otherwise. Letting > Keycloak handle external tokens automatically reduces code the user has > to write and takes request load off of the Keycloak auth server. > > Your concern that refreshing tokens automatically will hurt performance > is just bogus. Automatic token refresh can't even be done with > Facebook. You don't even need token refresh for Facebook because > long-lived tokens last 60 days. Refresh isn't even needed for Twitter > as their tokens last forever. OIDC brokered tokens need to have refresh > called to determine if the session has been logged out from the parent > broker. Again, that's only valid for the external token that was used to login the current session, not for all tokens. Also, it doesn't require including the external token. I think the more common scenario is that a user logs-in with one or more external providers and the external tokens are never used, so why refresh the tokens all the time unnecessary? > > -- > Bill Burke > JBoss, a division of Red Hat > http://bill.burkecentral.com > From lvadali at cisco.com Thu Mar 5 08:12:35 2015 From: lvadali at cisco.com (Lakshmi Narayana VADALI (lvadali)) Date: Thu, 5 Mar 2015 13:12:35 +0000 Subject: [keycloak-dev] Application clustering Issue with Keycloak 1.1.0_Final Message-ID: Hi, We are using keycloak 1.1.0_Final. We are trying Application clustering using jboss (domain mode). We Tested clustering setup (with cluster-demo application provided by jboss) which is working. But With Latest keycloak-adapter looks like keycloak-sessions are not replicated. We are always redirected to Keycloak when the request lands new node of cluster. We are able to make our setup work if we use cookie store, But we wanted to use Session store rather than cookie store. When we bringup our nodes we are able to receive below logs INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (Incoming-10,shared=udp) ISPN000094: Received new cluster view: [node1/web|1] (2) [node1/web, node2/web] Thanks, Lakshmi Narayana V -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150305/604aa189/attachment.html From mposolda at redhat.com Thu Mar 5 10:25:22 2015 From: mposolda at redhat.com (Marek Posolda) Date: Thu, 05 Mar 2015 16:25:22 +0100 Subject: [keycloak-dev] Application clustering Issue with Keycloak 1.1.0_Final In-Reply-To: References: Message-ID: <54F87562.4060408@redhat.com> Hi, do you have "" tag in web.xml? Do you have Wildfly or EAP6 for your application and which version? Thanks, Marek On 5.3.2015 14:12, Lakshmi Narayana VADALI (lvadali) wrote: > > Hi, > > We are using keycloak 1.1.0_Final. We are trying Application > clustering using jboss (domain mode). We Tested clustering setup (with > cluster-demo application provided by jboss) which is working. But With > Latest keycloak-adapter looks like keycloak-sessions are not > replicated. We are always redirected to Keycloak when the request > lands new node of cluster. > > We are able to make our setup work if we use cookie store, But we > wanted to use Session store rather than cookie store. > > When we bringup our nodes we are able to receive below logs > INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (Incoming-10,shared=udp) > ISPN000094: Received new cluster view: [node1/web|1] (2) [node1/web, node2/web] > > Thanks, > > Lakshmi Narayana V > > > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150305/52728899/attachment.html From lvadali at cisco.com Thu Mar 5 11:18:21 2015 From: lvadali at cisco.com (Lakshmi Narayana VADALI (lvadali)) Date: Thu, 5 Mar 2015 16:18:21 +0000 Subject: [keycloak-dev] Application clustering Issue with Keycloak 1.1.0_Final In-Reply-To: <54F87562.4060408@redhat.com> References: <54F87562.4060408@redhat.com> Message-ID: Hi Marek, Yes we have "" tag in web.xml. We are using EAP 6.3.0-1. Thanks, Lakshmi Narayana V From: Marek Posolda [mailto:mposolda at redhat.com] Sent: Thursday, March 05, 2015 8:55 PM To: Lakshmi Narayana VADALI (lvadali); keycloak-dev at lists.jboss.org Subject: Re: [keycloak-dev] Application clustering Issue with Keycloak 1.1.0_Final Hi, do you have "" tag in web.xml? Do you have Wildfly or EAP6 for your application and which version? Thanks, Marek On 5.3.2015 14:12, Lakshmi Narayana VADALI (lvadali) wrote: Hi, We are using keycloak 1.1.0_Final. We are trying Application clustering using jboss (domain mode). We Tested clustering setup (with cluster-demo application provided by jboss) which is working. But With Latest keycloak-adapter looks like keycloak-sessions are not replicated. We are always redirected to Keycloak when the request lands new node of cluster. We are able to make our setup work if we use cookie store, But we wanted to use Session store rather than cookie store. When we bringup our nodes we are able to receive below logs INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (Incoming-10,shared=udp) ISPN000094: Received new cluster view: [node1/web|1] (2) [node1/web, node2/web] Thanks, Lakshmi Narayana V _______________________________________________ keycloak-dev mailing list keycloak-dev at lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150305/5f326cf0/attachment-0001.html From juan.escot at cdtec.es Thu Mar 5 14:04:53 2015 From: juan.escot at cdtec.es (Juan Escot) Date: Thu, 5 Mar 2015 20:04:53 +0100 Subject: [keycloak-dev] (no subject) Message-ID: Hi, I just updated my jboss eap 6.3 server to keycloak 1.10 final. When i try to make a call to a Rest service authenticated with keycloak, i get this exception: "ERROR [org.keycloak.adapters.BearerTokenRequestAuthenticator] (http-/0.0.0.0:8080-1) Failed to verify token: org.keycloak.VerificationException: Invalid token signature." I'm trying preconfigured demo project to test my server and, when I run 'angular product example' I take this error too when it calls a rest service on "database service" demo project. I have configured my realm, added the projects and updated keycloak.json file for each project. I have revised all keycloak configuration and seems to be ok. The full stack trace for the exception is this: ERROR [org.keycloak.adapters.BearerTokenRequestAuthenticator] (http-/0.0.0.0:8080-1) Failed to verify token: org.keycloak.VerificationException: Invalid token signature. at org.keycloak.RSATokenVerifier.verifyToken(RSATokenVerifier.java:26) [keycloak-core-1.1.0.Final.jar:1.1.0.Final] at org.keycloak.RSATokenVerifier.verifyToken(RSATokenVerifier.java:16) [keycloak-core-1.1.0.Final.jar:1.1.0.Final] at org.keycloak.adapters.BearerTokenRequestAuthenticator.authenticateToken(BearerTokenRequestAuthenticator.java:67) [keycloak-adapter-core-1.1.0.Final.jar:1.1.0.Final] at org.keycloak.adapters.BearerTokenRequestAuthenticator.authenticate(BearerTokenRequestAuthenticator.java:62) [keycloak-adapter-core-1.1.0.Final.jar:1.1.0.Final] at org.keycloak.adapters.RequestAuthenticator.authenticate(RequestAuthenticator.java:45) [keycloak-adapter-core-1.1.0.Final.jar:1.1.0.Final] at org.keycloak.adapters.tomcat.AbstractKeycloakAuthenticatorValve.authenticateInternal(AbstractKeycloakAuthenticatorValve.java:192) [keycloak-tomcat-core-adapter-1.1.0.Final.jar:1.1.0.Final] at org.keycloak.adapters.jbossweb.KeycloakAuthenticatorValve.authenticate(KeycloakAuthenticatorValve.java:26) [keycloak-as7-adapter-1.1.0.Final.jar:1.1.0.Final] at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:478) [jbossweb-7.4.8.Final-redhat-4.jar:7.4.8.Final-redhat-4] at org.keycloak.adapters.tomcat.AbstractKeycloakAuthenticatorValve.invoke(AbstractKeycloakAuthenticatorValve.java:173) [keycloak-tomcat-core-adapter-1.1.0.Final.jar:1.1.0.Final] at org.jboss.as.web.security.SecurityContextAssociationValve.invoke(SecurityContextAssociationValve.java:169) [jboss-as-web-7.4.0.Final-redhat-19.jar:7.4.0.Final-redhat-19] at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:145) [jbossweb-7.4.8.Final-redhat-4.jar:7.4.8.Final-redhat-4] at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:97) [jbossweb-7.4.8.Final-redhat-4.jar:7.4.8.Final-redhat-4] at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:102) [jbossweb-7.4.8.Final-redhat-4.jar:7.4.8.Final-redhat-4] at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:344) [jbossweb-7.4.8.Final-redhat-4.jar:7.4.8.Final-redhat-4] at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:856) [jbossweb-7.4.8.Final-redhat-4.jar:7.4.8.Final-redhat-4] at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:653) [jbossweb-7.4.8.Final-redhat-4.jar:7.4.8.Final-redhat-4] at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:926) [jbossweb-7.4.8.Final-redhat-4.jar:7.4.8.Final-redhat-4] at java.lang.Thread.run(Thread.java:745) [rt.jar:1.7.0_75] What's wrong? Thanks in advance, Juan Escot -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150305/7e387baf/attachment.html From stian at redhat.com Thu Mar 5 23:58:06 2015 From: stian at redhat.com (Stian Thorgersen) Date: Thu, 5 Mar 2015 23:58:06 -0500 (EST) Subject: [keycloak-dev] Introduction- GSOC 2015 In-Reply-To: References: Message-ID: <775554892.22065633.1425617886684.JavaMail.zimbra@redhat.com> Hi, What project are you interested in? ----- Original Message ----- > From: "MUDIT SAXENA" > To: keycloak-dev at lists.jboss.org > Sent: Wednesday, 4 March, 2015 8:20:06 PM > Subject: [keycloak-dev] Introduction- GSOC 2015 > > Hello, > I am Mudit Saxena from India. I am pursuing B.Tech in Computer Science & > Engineering . I am a java developer and have commited myself to different > projects in JAVA. I looking forward to GSOC-2015 and want be a part of the > open source community. > > Thank you, > > Regard, > > Mudit Saxena > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev From stian at redhat.com Fri Mar 6 00:51:04 2015 From: stian at redhat.com (Stian Thorgersen) Date: Fri, 6 Mar 2015 00:51:04 -0500 (EST) Subject: [keycloak-dev] (no subject) In-Reply-To: References: Message-ID: <182334916.22082753.1425621064541.JavaMail.zimbra@redhat.com> Looks like there's a miss-match between the realms keys. Have you updated the keycloak.json with the correct realm public key? ----- Original Message ----- > From: "Juan Escot" > To: keycloak-dev at lists.jboss.org > Sent: Thursday, 5 March, 2015 8:04:53 PM > Subject: [keycloak-dev] (no subject) > > Hi, > > I just updated my jboss eap 6.3 server to keycloak 1.10 final. When i try to > make a call to a Rest service authenticated with keycloak, i get this > exception: > > "ERROR [org.keycloak.adapters.BearerTokenRequestAuthenticator] > (http-/0.0.0.0:8080-1) Failed to verify token: > org.keycloak.VerificationException: Invalid token signature." > > I'm trying preconfigured demo project to test my server and, when I run > 'angular product example' I take this error too when it calls a rest service > on "database service" demo project. > I have configured my realm, added the projects and updated keycloak.json file > for each project. > > I have revised all keycloak configuration and seems to be ok. The full stack > trace for the exception is this: > ERROR [org.keycloak.adapters.BearerTokenRequestAuthenticator] > (http-/0.0.0.0:8080-1) Failed to verify token: > org.keycloak.VerificationException: Invalid token signature. > at org.keycloak.RSATokenVerifier.verifyToken(RSATokenVerifier.java:26) > [keycloak-core-1.1.0.Final.jar:1.1.0.Final] > at org.keycloak.RSATokenVerifier.verifyToken(RSATokenVerifier.java:16) > [keycloak-core-1.1.0.Final.jar:1.1.0.Final] > at > org.keycloak.adapters.BearerTokenRequestAuthenticator.authenticateToken(BearerTokenRequestAuthenticator.java:67) > [keycloak-adapter-core-1.1.0.Final.jar:1.1.0.Final] > at > org.keycloak.adapters.BearerTokenRequestAuthenticator.authenticate(BearerTokenRequestAuthenticator.java:62) > [keycloak-adapter-core-1.1.0.Final.jar:1.1.0.Final] > at > org.keycloak.adapters.RequestAuthenticator.authenticate(RequestAuthenticator.java:45) > [keycloak-adapter-core-1.1.0.Final.jar:1.1.0.Final] > at > org.keycloak.adapters.tomcat.AbstractKeycloakAuthenticatorValve.authenticateInternal(AbstractKeycloakAuthenticatorValve.java:192) > [keycloak-tomcat-core-adapter-1.1.0.Final.jar:1.1.0.Final] > at > org.keycloak.adapters.jbossweb.KeycloakAuthenticatorValve.authenticate(KeycloakAuthenticatorValve.java:26) > [keycloak-as7-adapter-1.1.0.Final.jar:1.1.0.Final] > at > org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:478) > [jbossweb-7.4.8.Final-redhat-4.jar:7.4.8.Final-redhat-4] > at > org.keycloak.adapters.tomcat.AbstractKeycloakAuthenticatorValve.invoke(AbstractKeycloakAuthenticatorValve.java:173) > [keycloak-tomcat-core-adapter-1.1.0.Final.jar:1.1.0.Final] > at > org.jboss.as.web.security.SecurityContextAssociationValve.invoke(SecurityContextAssociationValve.java:169) > [jboss-as-web-7.4.0.Final-redhat-19.jar:7.4.0.Final-redhat-19] > at > org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:145) > [jbossweb-7.4.8.Final-redhat-4.jar:7.4.8.Final-redhat-4] > at > org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:97) > [jbossweb-7.4.8.Final-redhat-4.jar:7.4.8.Final-redhat-4] > at > org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:102) > [jbossweb-7.4.8.Final-redhat-4.jar:7.4.8.Final-redhat-4] > at > org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:344) > [jbossweb-7.4.8.Final-redhat-4.jar:7.4.8.Final-redhat-4] > at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:856) > [jbossweb-7.4.8.Final-redhat-4.jar:7.4.8.Final-redhat-4] > at > org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:653) > [jbossweb-7.4.8.Final-redhat-4.jar:7.4.8.Final-redhat-4] > at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:926) > [jbossweb-7.4.8.Final-redhat-4.jar:7.4.8.Final-redhat-4] > at java.lang.Thread.run(Thread.java:745) [rt.jar:1.7.0_75] > > What's wrong? > > Thanks in advance, > Juan Escot > > > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev From mposolda at redhat.com Fri Mar 6 03:17:17 2015 From: mposolda at redhat.com (Marek Posolda) Date: Fri, 06 Mar 2015 09:17:17 +0100 Subject: [keycloak-dev] Application clustering Issue with Keycloak 1.1.0_Final In-Reply-To: References: <54F87562.4060408@redhat.com> Message-ID: <54F9628D.9020100@redhat.com> Hi Lakshmi, EAP 6.3.0 should work, but I've tested with "standalone" mode so far, not domain mode yet.. Not sure if it's keycloak bug specific to domain or just some issue in your environment. Could you try to test if HTTP session replication works for you in domain mode with some simple servlet application (not keycloak authentication enabled) ? If you don't have any, take a look at this for example: https://github.com/keycloak/keycloak/blob/master/testsuite/integration/src/test/java/org/keycloak/testsuite/adapter/SessionServlet.java Thanks, Marek On 5.3.2015 17:18, Lakshmi Narayana VADALI (lvadali) wrote: > > Hi Marek, > > Yes we have "" tag in web.xml. > > We are using EAP 6.3.0-1. > > Thanks, > > Lakshmi Narayana V > > *From:*Marek Posolda [mailto:mposolda at redhat.com] > *Sent:* Thursday, March 05, 2015 8:55 PM > *To:* Lakshmi Narayana VADALI (lvadali); keycloak-dev at lists.jboss.org > *Subject:* Re: [keycloak-dev] Application clustering Issue with > Keycloak 1.1.0_Final > > Hi, > > do you have "" tag in web.xml? Do you have Wildfly or > EAP6 for your application and which version? > > Thanks, > Marek > > On 5.3.2015 14:12, Lakshmi Narayana VADALI (lvadali) wrote: > > Hi, > > We are using keycloak 1.1.0_Final. We are trying Application > clustering using jboss (domain mode). We Tested clustering setup > (with cluster-demo application provided by jboss) which is > working. But With Latest keycloak-adapter looks like > keycloak-sessions are not replicated. We are always redirected to > Keycloak when the request lands new node of cluster. > > We are able to make our setup work if we use cookie store, But we > wanted to use Session store rather than cookie store. > > When we bringup our nodes we are able to receive below logs > > INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (Incoming-10,shared=udp) > > ISPN000094: Received new cluster view: [node1/web|1] (2) [node1/web, node2/web] > > Thanks, > > Lakshmi Narayana V > > > > > _______________________________________________ > > keycloak-dev mailing list > > keycloak-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/keycloak-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150306/9c8a8201/attachment-0001.html From mposolda at redhat.com Fri Mar 6 07:38:01 2015 From: mposolda at redhat.com (Marek Posolda) Date: Fri, 06 Mar 2015 13:38:01 +0100 Subject: [keycloak-dev] Kerberos progress In-Reply-To: <54E3030C.5020100@redhat.com> References: <54DBADB2.40300@redhat.com> <54DBBDD2.3050509@redhat.com> <54DC6934.4070902@redhat.com> <54DCAF51.90509@redhat.com> <54DCD649.3050107@redhat.com> <54DCD81E.4020800@redhat.com> <54E2625D.1020506@redhat.com> <54E2668C.5010003@redhat.com> <54E3030C.5020100@redhat.com> Message-ID: <54F99FA9.3030104@redhat.com> I've pushed the Kerberos credential delegation stuff including documentation and example, so I hope the kerberos stuff is finished for now. As discussed before, I've used federation providers for Kerberos authentication support. The credential delegation works in similar way like 3rd party social providers. Despite it's easier as credential is valid just for the session and doesn't need to support refreshing;-) So user authenticates to Keycloak with kerberos ticket and Keycloak transmits the kerberos credential to the example application, which can use it for further calls to other kerberized services. The only difference is that kerberos credential is valid just for given UserSession, it's not attribute of UserModel. So I've added new OIDCUserSessionNoteMapper to map UserSession notes to the access token claims. I hope to show more in the demo next week, let me know if you think that something should be improved. ATM I am considering kerberos as finished and going to look at other tasks I have - removing PL IDM dependency (hope I am able to catch the train for 1.2.0.Beta1 with this) and then other LDAP improvements and some other minor JIRAs related to export/import, mongo etc. Marek On 17.2.2015 09:59, Marek Posolda wrote: > On 16.2.2015 22:52, Bill Burke wrote: >> >> On 2/16/2015 4:34 PM, Marek Posolda wrote: >>> Still thinking whether it's better to use federation SPI or identity >>> broker SPI for kerberos integration. I am finally much more inclined to >>> Federation SPI ;-) >>> >> That's why I brought it up before...I wasn't sure what the right SPI >> to use would be, or if our SPIs needed to improve and be refactored. >> Maybe the answer is use both??? *shrug* > Yeah, the fact you pointed it and some feedback from users in JIRA > https://issues.jboss.org/browse/KEYCLOAK-828 makes me think that > federation suits better:-) Was also thinking about keep both, but as you > mentioned few months back, every possibility we offer also adds > complexity and potential error-proness. > > ATM I am more to use federation SPI. And Kerberos identity broker can be > restored later if there are usecases from community? > >> I don't know if this makes sense, but a kerberos broker would import >> users from information from the kerberos ticket. A Kerberos >> Federation Provider interacts directly with an LDAP server to provide >> a more complete integration point??? I don't know...just thinking. I >> don't know enough about kerberos or how people want to use it with us >> to make a decision. > ATM I am thinking about 2 possibilities: > > * Integration with Kerberos not backed by LDAP: For this case there will > be KerberosFederationProvider. Kerberos ticket contains just username, > so once user authenticated for the first time, he will usually need to > update a profile (that would be configurable on/off switch). Same > required action "Update_profile", which is used for social/identity > brokering, will be used for this too > > * Integration with Kerberos backed by LDAP: For this case, > LDAPFederationProvider will be enhanced. There will be configuration > possibility on LDAP provider screen "Allow kerberos authentication". > When user is first authenticated with Kerberos ticket, his profile data > (firstName, lastName, email ...) are imported from LDAP. There is single > federation link, so once I authenticate with Kerberos principal or with > username/password from LDAP, Keycloak knows that it's same user. > > Marek > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev From stian at redhat.com Fri Mar 6 08:30:52 2015 From: stian at redhat.com (Stian Thorgersen) Date: Fri, 6 Mar 2015 08:30:52 -0500 (EST) Subject: [keycloak-dev] Started adding OpenID Connect Discovery Message-ID: <1272089014.22318235.1425648652957.JavaMail.zimbra@redhat.com> FIY I've started on OpenID Connect Discovery From muditsaxena77 at gmail.com Sat Mar 7 10:29:19 2015 From: muditsaxena77 at gmail.com (MUDIT SAXENA) Date: Sat, 7 Mar 2015 20:59:19 +0530 Subject: [keycloak-dev] Regarding Keycloak - Internationalization support Message-ID: Hello, I was looking forward to work on this particular idea in GSOC-2015. But today as I checked out on the ideapage that this this idea has been taken off. Any specific reasons for it? Regard, Mudit Saxena -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150307/34aef287/attachment.html From giriraj.sharma27 at gmail.com Sat Mar 7 10:32:13 2015 From: giriraj.sharma27 at gmail.com (Giriraj Sharma) Date: Sat, 7 Mar 2015 21:02:13 +0530 Subject: [keycloak-dev] Regarding Keycloak - Internationalization support In-Reply-To: References: Message-ID: Hi Mudit. The idea has been taken off probably because we already have someone internally from Keycloak community working on it. Feel free to look into other proposals from the ideas page. Thanks, On Sat, Mar 7, 2015 at 8:59 PM, MUDIT SAXENA wrote: > Hello, > I was looking forward to work on this particular idea in GSOC-2015. But > today as I checked out on the ideapage that this this idea has been taken > off. Any specific reasons for it? > > > > > Regard, > Mudit Saxena > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > -- Giriraj Sharma, Department of Computer Science National Institute of Technology Hamirpur Himachal Pradesh, India -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150307/e0ea3928/attachment.html From tom9729 at gmail.com Sun Mar 8 00:44:31 2015 From: tom9729 at gmail.com (Tom Arnold) Date: Sun, 8 Mar 2015 00:44:31 -0500 Subject: [keycloak-dev] Client cert authentication Message-ID: Hey all, First, just wanted to say that Keycloak looks great. It seems like the project has come a long way in a very short time! Are there plans to support client cert (X.509) authentication? Thanks, Tom -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150308/e508bdfa/attachment.html From lvadali at cisco.com Mon Mar 9 06:09:53 2015 From: lvadali at cisco.com (Lakshmi Narayana VADALI (lvadali)) Date: Mon, 9 Mar 2015 10:09:53 +0000 Subject: [keycloak-dev] Application clustering Issue with Keycloak 1.1.0_Final In-Reply-To: <54F9628D.9020100@redhat.com> References: <54F87562.4060408@redhat.com> <54F9628D.9020100@redhat.com> Message-ID: Hi Marek, We are thinking may be session replication for keycloak application alone ( in domain mode) is not working because of below reasons 1. The application you provided is working fine in our environment . (Conclusion:: session replication working for other applications) 2. If only one node in the cluster(domain mode) is up its working. (Conclusion:: keycloak setup is fine in my environment , as session replication is not needed) Please let us know if you think otherwise. Thanks, Lakshmi Narayana V From: Marek Posolda [mailto:mposolda at redhat.com] Sent: Friday, March 06, 2015 1:47 PM To: Lakshmi Narayana VADALI (lvadali); keycloak-dev at lists.jboss.org Subject: Re: [keycloak-dev] Application clustering Issue with Keycloak 1.1.0_Final Hi Lakshmi, EAP 6.3.0 should work, but I've tested with "standalone" mode so far, not domain mode yet.. Not sure if it's keycloak bug specific to domain or just some issue in your environment. Could you try to test if HTTP session replication works for you in domain mode with some simple servlet application (not keycloak authentication enabled) ? If you don't have any, take a look at this for example: https://github.com/keycloak/keycloak/blob/master/testsuite/integration/src/test/java/org/keycloak/testsuite/adapter/SessionServlet.java Thanks, Marek On 5.3.2015 17:18, Lakshmi Narayana VADALI (lvadali) wrote: Hi Marek, Yes we have "" tag in web.xml. We are using EAP 6.3.0-1. Thanks, Lakshmi Narayana V From: Marek Posolda [mailto:mposolda at redhat.com] Sent: Thursday, March 05, 2015 8:55 PM To: Lakshmi Narayana VADALI (lvadali); keycloak-dev at lists.jboss.org Subject: Re: [keycloak-dev] Application clustering Issue with Keycloak 1.1.0_Final Hi, do you have "" tag in web.xml? Do you have Wildfly or EAP6 for your application and which version? Thanks, Marek On 5.3.2015 14:12, Lakshmi Narayana VADALI (lvadali) wrote: Hi, We are using keycloak 1.1.0_Final. We are trying Application clustering using jboss (domain mode). We Tested clustering setup (with cluster-demo application provided by jboss) which is working. But With Latest keycloak-adapter looks like keycloak-sessions are not replicated. We are always redirected to Keycloak when the request lands new node of cluster. We are able to make our setup work if we use cookie store, But we wanted to use Session store rather than cookie store. When we bringup our nodes we are able to receive below logs INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (Incoming-10,shared=udp) ISPN000094: Received new cluster view: [node1/web|1] (2) [node1/web, node2/web] Thanks, Lakshmi Narayana V _______________________________________________ keycloak-dev mailing list keycloak-dev at lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150309/954b5259/attachment-0001.html From giriraj.sharma27 at gmail.com Mon Mar 9 09:33:50 2015 From: giriraj.sharma27 at gmail.com (Giriraj Sharma) Date: Mon, 9 Mar 2015 19:03:50 +0530 Subject: [keycloak-dev] Log Admin associated (edit/modify) Events. Message-ID: I propose, as recommended by stian, that all admin activities (edited/modified) shall be logged in other than just user related admin events. User related events will continue to be logged in all cases as is currently. In addition, #1. We can simply log in all other activities too by admin. OR #2. Provide an option (on/off) for the admin to choose if he wishes to log in all other admin events too. -- Giriraj Sharma about.me/girirajsharma Giriraj Sharma, Department of Computer Science National Institute of Technology Hamirpur Himachal Pradesh, India 177005 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150309/694eb08d/attachment.html From siddiquimuhammadusman at gmail.com Tue Mar 10 02:25:06 2015 From: siddiquimuhammadusman at gmail.com (Muhammad Usman Siddiqui) Date: Tue, 10 Mar 2015 11:25:06 +0500 Subject: [keycloak-dev] Request for Help Message-ID: <54FE8E42.4050506@GMAIL.COM> Dear Mentors/Seniors, I am really interested in your Keycloak-IoT security,because it had always attracted me.I had a passion for hacking and i think its time to become a white hat. Can't wait to contribute my skills in this projoect at GSOC-15.Could Anyone please help me out? Cheers, M.Usman Siddiqui. From mposolda at redhat.com Tue Mar 10 04:19:43 2015 From: mposolda at redhat.com (Marek Posolda) Date: Tue, 10 Mar 2015 09:19:43 +0100 Subject: [keycloak-dev] Application clustering Issue with Keycloak 1.1.0_Final In-Reply-To: References: <54F87562.4060408@redhat.com> <54F9628D.9020100@redhat.com> Message-ID: <54FEA91F.7060505@redhat.com> Can you please try to test cluster with your application in standalone mode? Just curious if it's bug specific just to domain mode... Thanks, Marek On 9.3.2015 11:09, Lakshmi Narayana VADALI (lvadali) wrote: > > Hi Marek, > > We are thinking may be *session replication for keycloak application > alone ( in domain mode)* *is not working* because of below reasons > > 1.The application you provided is working fine in our environment . > (*Conclusion::* session replication working for other applications) > > 2.If only one node in the cluster(domain mode) is up its working. > (*Conclusion::* keycloak setup is fine in my environment , as session > replication is not needed) > > Please let us know if you think otherwise. > > Thanks, > > Lakshmi Narayana V > > *From:*Marek Posolda [mailto:mposolda at redhat.com] > *Sent:* Friday, March 06, 2015 1:47 PM > *To:* Lakshmi Narayana VADALI (lvadali); keycloak-dev at lists.jboss.org > *Subject:* Re: [keycloak-dev] Application clustering Issue with > Keycloak 1.1.0_Final > > Hi Lakshmi, > > EAP 6.3.0 should work, but I've tested with "standalone" mode so far, > not domain mode yet.. Not sure if it's keycloak bug specific to domain > or just some issue in your environment. > > Could you try to test if HTTP session replication works for you in > domain mode with some simple servlet application (not keycloak > authentication enabled) ? If you don't have any, take a look at this > for example: > https://github.com/keycloak/keycloak/blob/master/testsuite/integration/src/test/java/org/keycloak/testsuite/adapter/SessionServlet.java > > > Thanks, > Marek > > On 5.3.2015 17:18, Lakshmi Narayana VADALI (lvadali) wrote: > > Hi Marek, > > Yes we have "" tag in web.xml. > > We are using EAP 6.3.0-1. > > Thanks, > > Lakshmi Narayana V > > *From:*Marek Posolda [mailto:mposolda at redhat.com] > *Sent:* Thursday, March 05, 2015 8:55 PM > *To:* Lakshmi Narayana VADALI (lvadali); > keycloak-dev at lists.jboss.org > *Subject:* Re: [keycloak-dev] Application clustering Issue with > Keycloak 1.1.0_Final > > Hi, > > do you have "" tag in web.xml? Do you have > Wildfly or EAP6 for your application and which version? > > Thanks, > Marek > > On 5.3.2015 14:12, Lakshmi Narayana VADALI (lvadali) wrote: > > Hi, > > We are using keycloak 1.1.0_Final. We are trying Application > clustering using jboss (domain mode). We Tested clustering > setup (with cluster-demo application provided by jboss) which > is working. But With Latest keycloak-adapter looks like > keycloak-sessions are not replicated. We are always redirected > to Keycloak when the request lands new node of cluster. > > We are able to make our setup work if we use cookie store, > But we wanted to use Session store rather than cookie store. > > When we bringup our nodes we are able to receive below logs > > INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (Incoming-10,shared=udp) > > ISPN000094: Received new cluster view: [node1/web|1] (2) [node1/web, node2/web] > > Thanks, > > Lakshmi Narayana V > > > > > > _______________________________________________ > > keycloak-dev mailing list > > keycloak-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/keycloak-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150310/361e1d82/attachment.html From mposolda at redhat.com Tue Mar 10 04:22:36 2015 From: mposolda at redhat.com (Marek Posolda) Date: Tue, 10 Mar 2015 09:22:36 +0100 Subject: [keycloak-dev] Client cert authentication In-Reply-To: References: Message-ID: <54FEA9CC.7030608@redhat.com> Hi, we have plans to support it. It should be in couple of months though, no promise of exact date at this moment. Marek On 8.3.2015 06:44, Tom Arnold wrote: > Hey all, > > First, just wanted to say that Keycloak looks great. It seems like the > project has come a long way in a very short time! > > Are there plans to support client cert (X.509) authentication? > > Thanks, > Tom > > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150310/27bd25fe/attachment-0001.html From mposolda at redhat.com Tue Mar 10 04:29:30 2015 From: mposolda at redhat.com (Marek Posolda) Date: Tue, 10 Mar 2015 09:29:30 +0100 Subject: [keycloak-dev] Log Admin associated (edit/modify) Events. In-Reply-To: References: Message-ID: <54FEAB6A.2050202@redhat.com> +1 On 9.3.2015 14:33, Giriraj Sharma wrote: > I propose, as recommended by stian, that all admin activities > (edited/modified) shall be logged in other than just user related > admin events. > > User related events will continue to be logged in all cases as is > currently. > In addition, > #1. We can simply log in all other activities too by admin. > OR > #2. Provide an option (on/off) for the admin to choose if he wishes to > log in all other admin events too. > > -- > Giriraj Sharma > about.me/girirajsharma > > > > Giriraj Sharma, > Department of Computer Science > National Institute of Technology Hamirpur > Himachal Pradesh, India 177005 > > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150310/04ce7041/attachment.html From stian at redhat.com Tue Mar 10 04:46:36 2015 From: stian at redhat.com (Stian Thorgersen) Date: Tue, 10 Mar 2015 04:46:36 -0400 (EDT) Subject: [keycloak-dev] Request for Help In-Reply-To: <54FE8E42.4050506@GMAIL.COM> References: <54FE8E42.4050506@GMAIL.COM> Message-ID: <1475555978.2913311.1425977196345.JavaMail.zimbra@redhat.com> ----- Original Message ----- > From: "Muhammad Usman Siddiqui" > To: keycloak-dev at lists.jboss.org > Sent: Tuesday, 10 March, 2015 7:25:06 AM > Subject: [keycloak-dev] Request for Help > > Dear Mentors/Seniors, > I am really interested in your Keycloak-IoT security,because it had > always attracted me.I had a passion for hacking and i think its time to > become a white hat. Can't wait to contribute my skills in this projoect > at GSOC-15.Could Anyone please help me out? Sure, What would you like to know? > Cheers, > M.Usman Siddiqui. > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > From bdawidow at redhat.com Tue Mar 10 06:00:02 2015 From: bdawidow at redhat.com (Boleslaw Dawidowicz) Date: Tue, 10 Mar 2015 11:00:02 +0100 Subject: [keycloak-dev] PicketLink and Keycloak projects are merging! Message-ID: <54FEC0A2.1020904@redhat.com> We would like to announce that PicketLink and Keycloak projects will be merging their efforts. Code base of both will get unified and new features will be developed in a single place. DZone link: http://www.dzone.com/links/picketlink_and_keycloak_projects_are_merging.html Blog post: http://blog.keycloak.org/2015/03/picketlink-and-keycloak-projects-are.html FAQ covering most important questions: http://picketlink.org/keycloak-merge-faq/ -- Boles?aw Dawidowicz From velias at redhat.com Wed Mar 11 05:45:06 2015 From: velias at redhat.com (Vlastimil Elias) Date: Wed, 11 Mar 2015 10:45:06 +0100 Subject: [keycloak-dev] Improvements of registration over Social Login providers Message-ID: <55000EA2.1060106@redhat.com> Hi great Keycloak dev team, during implementation of https://issues.jboss.org/browse/KEYCLOAK-1074 I found few things which should be improved in area of registration over Social Login providers. I'd like to discuss them here before creating JIRAs. I believe I should implement these changes if you will be interested. 1. It is not possible to disable registration over Social provider ====================================== Once provider is created then it is always possible to register over it, even if "User registration" is disabled in realm "Login Settings". I think it should be possible to disable social registrations and allow only to link social logins to existing accounts (eg. loaded from other system). Marek Posolda pointed me to https://issues.jboss.org/browse/KEYCLOAK-1036 which is rejected without any comment. I understand that this global setting is probably not a good solution, so my proposal is to add independent "User registration" switch into configuration of each Identity provider, so admin will get fine grained control. 2. Username from Social provider is used as Keycloak username during registration =================================================== This can lead to the situation that user registering eg. over Twitter will not be able to register as other user eg. from Facebook will use same username there and occupy it in Keycloak as first. My proposal is to extend configuration of each Identity provider by new option "Username type" which will be select from these options: * provided username exact - works as now, username is got from provider, user can't register if occupied in KC already * provided username unique - KC will take username from provider, if occupied then it adds some random number to it to create unique username and allow user to register * provided email - this is related to KEYCLOAK-1074, I need this option for my project. I know that email is not provided by some providers (eg Twitter) so I can't use them until KEYCLOAK-1053 is resolved somehow So let me know what you think about my proposals, can I implement them? Cheers Vlastimil -- Vlastimil Elias Principal Software Engineer jboss.org Development Team -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150311/6df72870/attachment.html From stian at redhat.com Wed Mar 11 06:24:53 2015 From: stian at redhat.com (Stian Thorgersen) Date: Wed, 11 Mar 2015 06:24:53 -0400 (EDT) Subject: [keycloak-dev] Improvements of registration over Social Login providers In-Reply-To: <55000EA2.1060106@redhat.com> References: <55000EA2.1060106@redhat.com> Message-ID: <1890728201.3815264.1426069493109.JavaMail.zimbra@redhat.com> ----- Original Message ----- > From: "Vlastimil Elias" > To: keycloak-dev at lists.jboss.org > Sent: Wednesday, 11 March, 2015 10:45:06 AM > Subject: [keycloak-dev] Improvements of registration over Social Login providers > > Hi great Keycloak dev team, > > during implementation of https://issues.jboss.org/browse/KEYCLOAK-1074 I > found few things which should be improved in area of registration over > Social Login providers. > I'd like to discuss them here before creating JIRAs. I believe I should > implement these changes if you will be interested. > > 1. It is not possible to disable registration over Social provider > ====================================== > Once provider is created then it is always possible to register over it, even > if "User registration" is disabled in realm "Login Settings". I think it > should be possible to disable social registrations and allow only to link > social logins to existing accounts (eg. loaded from other system). > > Marek Posolda pointed me to https://issues.jboss.org/browse/KEYCLOAK-1036 > which is rejected without any comment. I understand that this global setting > is probably not a good solution, so my proposal is to add independent "User > registration" switch into configuration of each Identity provider, so admin > will get fine grained control. -1 IMO when you add a identity broker (or social provider) you are allowing all those users to login. When a user logs in the first time using a identity broker we're not really registering the user, just creating an internal representation. > > 2. Username from Social provider is used as Keycloak username during > registration > =================================================== > This can lead to the situation that user registering eg. over Twitter will > not be able to register as other user eg. from Facebook will use same > username there and occupy it in Keycloak as first. > My proposal is to extend configuration of each Identity provider by new > option "Username type" which will be select from these options: > > > * provided username exact - works as now, username is got from provider, > user can't register if occupied in KC already > * provided username unique - KC will take username from provider, if > occupied then it adds some random number to it to create unique username > and allow user to register > * provided email - this is related to KEYCLOAK-1074, I need this option > for my project. I know that email is not provided by some providers (eg > Twitter) so I can't use them until KEYCLOAK-1053 is resolved somehow > > So let me know what you think about my proposals, can I implement them? -1 If it's using the username from the identity provider that's not correct, it should just be set to something unique (could be set to same as user id), that's how it used to be before the identity brokering was introduced. We have an open issue to allow users to change their username. This would then be used by a user that wants to enable regular logins in the above scenario. We could improve the account management around this, for example it should not display username if it's the same as user id, but have an option for a user to "enable regular login" by providing a username and password. > > Cheers > > Vlastimil > > -- > Vlastimil Elias > Principal Software Engineer > jboss.org Development Team > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev From stian at redhat.com Wed Mar 11 06:30:18 2015 From: stian at redhat.com (Stian Thorgersen) Date: Wed, 11 Mar 2015 06:30:18 -0400 (EDT) Subject: [keycloak-dev] Improvements of registration over Social Login providers In-Reply-To: <1890728201.3815264.1426069493109.JavaMail.zimbra@redhat.com> References: <55000EA2.1060106@redhat.com> <1890728201.3815264.1426069493109.JavaMail.zimbra@redhat.com> Message-ID: <1406310153.3818601.1426069818031.JavaMail.zimbra@redhat.com> We can also add some more required actions: * Set email if missing * Set username/password It would then be possible to set one or more required actions for a first social login. ----- Original Message ----- > From: "Stian Thorgersen" > To: "Vlastimil Elias" > Cc: keycloak-dev at lists.jboss.org > Sent: Wednesday, 11 March, 2015 11:24:53 AM > Subject: Re: [keycloak-dev] Improvements of registration over Social Login providers > > > > ----- Original Message ----- > > From: "Vlastimil Elias" > > To: keycloak-dev at lists.jboss.org > > Sent: Wednesday, 11 March, 2015 10:45:06 AM > > Subject: [keycloak-dev] Improvements of registration over Social Login > > providers > > > > Hi great Keycloak dev team, > > > > during implementation of https://issues.jboss.org/browse/KEYCLOAK-1074 I > > found few things which should be improved in area of registration over > > Social Login providers. > > I'd like to discuss them here before creating JIRAs. I believe I should > > implement these changes if you will be interested. > > > > 1. It is not possible to disable registration over Social provider > > ====================================== > > Once provider is created then it is always possible to register over it, > > even > > if "User registration" is disabled in realm "Login Settings". I think it > > should be possible to disable social registrations and allow only to link > > social logins to existing accounts (eg. loaded from other system). > > > > Marek Posolda pointed me to https://issues.jboss.org/browse/KEYCLOAK-1036 > > which is rejected without any comment. I understand that this global > > setting > > is probably not a good solution, so my proposal is to add independent "User > > registration" switch into configuration of each Identity provider, so admin > > will get fine grained control. > > -1 > > IMO when you add a identity broker (or social provider) you are allowing all > those users to login. When a user logs in the first time using a identity > broker we're not really registering the user, just creating an internal > representation. > > > > > 2. Username from Social provider is used as Keycloak username during > > registration > > =================================================== > > This can lead to the situation that user registering eg. over Twitter will > > not be able to register as other user eg. from Facebook will use same > > username there and occupy it in Keycloak as first. > > My proposal is to extend configuration of each Identity provider by new > > option "Username type" which will be select from these options: > > > > > > * provided username exact - works as now, username is got from > > provider, > > user can't register if occupied in KC already > > * provided username unique - KC will take username from provider, if > > occupied then it adds some random number to it to create unique > > username > > and allow user to register > > * provided email - this is related to KEYCLOAK-1074, I need this option > > for my project. I know that email is not provided by some providers (eg > > Twitter) so I can't use them until KEYCLOAK-1053 is resolved somehow > > > > So let me know what you think about my proposals, can I implement them? > > -1 > > If it's using the username from the identity provider that's not correct, it > should just be set to something unique (could be set to same as user id), > that's how it used to be before the identity brokering was introduced. > > We have an open issue to allow users to change their username. This would > then be used by a user that wants to enable regular logins in the above > scenario. We could improve the account management around this, for example > it should not display username if it's the same as user id, but have an > option for a user to "enable regular login" by providing a username and > password. > > > > > Cheers > > > > Vlastimil > > > > -- > > Vlastimil Elias > > Principal Software Engineer > > jboss.org Development Team > > > > _______________________________________________ > > keycloak-dev mailing list > > keycloak-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/keycloak-dev > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > From velias at redhat.com Wed Mar 11 08:41:39 2015 From: velias at redhat.com (Vlastimil Elias) Date: Wed, 11 Mar 2015 13:41:39 +0100 Subject: [keycloak-dev] Improvements of registration over Social Login providers In-Reply-To: <1406310153.3818601.1426069818031.JavaMail.zimbra@redhat.com> References: <55000EA2.1060106@redhat.com> <1890728201.3815264.1426069493109.JavaMail.zimbra@redhat.com> <1406310153.3818601.1426069818031.JavaMail.zimbra@redhat.com> Message-ID: <55003803.5000905@redhat.com> Hi I see your points and understand them if you take KC as primary system for identity. But things change a bit if you use UserFederationProvider SPI and primary user database is some other backend, and KC is used primarily to add some missing features (eg social logins, modern SSO protocols) at top of this backend. I'm in this position and I have to propagate new users to the backend (even one created due social login) and must reflect some constraints from the backend (like username must be email in my case). Feature proposal from point 1 is not critical for me, I think it should be useful for some KC installations to be able to disable social registrations, but I do not need it, so we can let it be. Feature proposal 2 is more important for me. I need email to be used as username in KC due my backend restrictions, so I implemented some basic solution as part of KEYCLOAK-1074 pull request. If you accept it and keep it in the code then I can use KC for my project (or we have to find some other solution, eg some extension of UserFederationProvider SPI to allow it to select username in case of social registration). But this solution is only partial and I want to help you make KC generally better for all use cases, so I did this proposal. I also think that current way how KC reuses username from social providers is wrong as it may prevent some users from login, so what to do with this? Create a bug in JIRA? But I don't think solution with some randomly generated username, which will be changed later, is a good one. This may bring problems to other systems which use KC for SSO and store data related to users. They typically rely on usernames to store these data, but change of username in KC may break data integrity (hide data for the user who changed username). How do you plan to prevent those problems if you implement username change in KC? I understand that correct solution should be using 'User ID' in these systems instead of username, but I fear it is not possible in many cases. From my experience integration of existing applications like Atlassian JIRA into SSO system may be problematic in this area, you are forced to use usernames there, username changes are typically a problem. So I think that username changes should be possible in KC for systems who need it, but no any important feature like social registrations should rely on them so heavily. Thanks Vlastimil On 11.3.2015 11:30, Stian Thorgersen wrote: > We can also add some more required actions: > > * Set email if missing > * Set username/password > > It would then be possible to set one or more required actions for a first social login. > > ----- Original Message ----- >> From: "Stian Thorgersen" >> To: "Vlastimil Elias" >> Cc: keycloak-dev at lists.jboss.org >> Sent: Wednesday, 11 March, 2015 11:24:53 AM >> Subject: Re: [keycloak-dev] Improvements of registration over Social Login providers >> >> >> >> ----- Original Message ----- >>> From: "Vlastimil Elias" >>> To: keycloak-dev at lists.jboss.org >>> Sent: Wednesday, 11 March, 2015 10:45:06 AM >>> Subject: [keycloak-dev] Improvements of registration over Social Login >>> providers >>> >>> Hi great Keycloak dev team, >>> >>> during implementation of https://issues.jboss.org/browse/KEYCLOAK-1074 I >>> found few things which should be improved in area of registration over >>> Social Login providers. >>> I'd like to discuss them here before creating JIRAs. I believe I should >>> implement these changes if you will be interested. >>> >>> 1. It is not possible to disable registration over Social provider >>> ====================================== >>> Once provider is created then it is always possible to register over it, >>> even >>> if "User registration" is disabled in realm "Login Settings". I think it >>> should be possible to disable social registrations and allow only to link >>> social logins to existing accounts (eg. loaded from other system). >>> >>> Marek Posolda pointed me to https://issues.jboss.org/browse/KEYCLOAK-1036 >>> which is rejected without any comment. I understand that this global >>> setting >>> is probably not a good solution, so my proposal is to add independent "User >>> registration" switch into configuration of each Identity provider, so admin >>> will get fine grained control. >> -1 >> >> IMO when you add a identity broker (or social provider) you are allowing all >> those users to login. When a user logs in the first time using a identity >> broker we're not really registering the user, just creating an internal >> representation. >> >>> 2. Username from Social provider is used as Keycloak username during >>> registration >>> =================================================== >>> This can lead to the situation that user registering eg. over Twitter will >>> not be able to register as other user eg. from Facebook will use same >>> username there and occupy it in Keycloak as first. >>> My proposal is to extend configuration of each Identity provider by new >>> option "Username type" which will be select from these options: >>> >>> >>> * provided username exact - works as now, username is got from >>> provider, >>> user can't register if occupied in KC already >>> * provided username unique - KC will take username from provider, if >>> occupied then it adds some random number to it to create unique >>> username >>> and allow user to register >>> * provided email - this is related to KEYCLOAK-1074, I need this option >>> for my project. I know that email is not provided by some providers (eg >>> Twitter) so I can't use them until KEYCLOAK-1053 is resolved somehow >>> >>> So let me know what you think about my proposals, can I implement them? >> -1 >> >> If it's using the username from the identity provider that's not correct, it >> should just be set to something unique (could be set to same as user id), >> that's how it used to be before the identity brokering was introduced. >> >> We have an open issue to allow users to change their username. This would >> then be used by a user that wants to enable regular logins in the above >> scenario. We could improve the account management around this, for example >> it should not display username if it's the same as user id, but have an >> option for a user to "enable regular login" by providing a username and >> password. >> >>> Cheers >>> >>> Vlastimil >>> >>> -- >>> Vlastimil Elias >>> Principal Software Engineer >>> jboss.org Development Team >>> >>> _______________________________________________ >>> keycloak-dev mailing list >>> keycloak-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> -- Vlastimil Elias Principal Software Engineer jboss.org Development Team From stian at redhat.com Wed Mar 11 11:10:21 2015 From: stian at redhat.com (Stian Thorgersen) Date: Wed, 11 Mar 2015 11:10:21 -0400 (EDT) Subject: [keycloak-dev] Refactoring to OIDCLoginProtocolService due to single endpoints for authorization and token In-Reply-To: <217392080.4068611.1426086449572.JavaMail.zimbra@redhat.com> Message-ID: <1847122792.4070324.1426086621113.JavaMail.zimbra@redhat.com> OIDCLoginProtocolService was becoming very bloated, especially once I added single for authorization and token endpoints. So I've extracted the logic into a few sub-resources: * AuthorizationEndpoint - login + registration * LoginStatusIframeEndpoint * LogoutEndpoint * TokenEndpoint * UserInfoEndpoint * ValidateTokenEndpoint I've not committed it yet as I need to do a bit more testing first, but wanted to give everyone a heads up. If anyone wants to review it before I commit have a look at https://github.com/stianst/keycloak/tree/oidc From bburke at redhat.com Wed Mar 11 15:06:04 2015 From: bburke at redhat.com (Bill Burke) Date: Wed, 11 Mar 2015 15:06:04 -0400 Subject: [keycloak-dev] 1.2.beta1 planning, need you to defer things Message-ID: <5500921C.8090605@redhat.com> I'd like to do 1.2.beta1 by end of month or earlier. Please go through the jira list and defer things you are not going to get to in the next 1-2 weeks. Thanks. I'm going to try and close existing bugs and implement features needed for jboss.org guys over the next 2 weeks as well as test out master to make sure things still work. Bill -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From stian at redhat.com Thu Mar 12 01:40:34 2015 From: stian at redhat.com (Stian Thorgersen) Date: Thu, 12 Mar 2015 01:40:34 -0400 (EDT) Subject: [keycloak-dev] 1.2.beta1 planning, need you to defer things In-Reply-To: <5500921C.8090605@redhat.com> References: <5500921C.8090605@redhat.com> Message-ID: <1632062033.4404645.1426138834278.JavaMail.zimbra@redhat.com> I'd like to reopen KEYCLOAK-311 as IMO it's not solved. This is not referring to the claim mapping work you've done, it's something else. Before we can do a release we need to make sure that database migration works (I know they don't atm as social providers and social links are lost). We also need to add transformation of JSON exports and representations so older versions can be imported into 1.2.0.Beta1. With all the changes we've done for this release (modules, claim mapping, identity brokering, oidc endpoints, ...) we need to do more testing this time around! ----- Original Message ----- > From: "Bill Burke" > To: keycloak-dev at lists.jboss.org > Sent: Wednesday, 11 March, 2015 8:06:04 PM > Subject: [keycloak-dev] 1.2.beta1 planning, need you to defer things > > I'd like to do 1.2.beta1 by end of month or earlier. Please go through > the jira list and defer things you are not going to get to in the next > 1-2 weeks. Thanks. Done > > I'm going to try and close existing bugs and implement features needed > for jboss.org guys over the next 2 weeks as well as test out master to > make sure things still work. With regards to jboss.org guys we shouldn't just add features because they request it. Take for example KEYCLOAK-1045, which was easily solved with we already have. Another one is KEYCLOAK-1051, which I think is a horrible idea. > > Bill > > -- > Bill Burke > JBoss, a division of Red Hat > http://bill.burkecentral.com > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > From stian at redhat.com Thu Mar 12 05:36:20 2015 From: stian at redhat.com (Stian Thorgersen) Date: Thu, 12 Mar 2015 05:36:20 -0400 (EDT) Subject: [keycloak-dev] Improvements of registration over Social Login providers In-Reply-To: <55003803.5000905@redhat.com> References: <55000EA2.1060106@redhat.com> <1890728201.3815264.1426069493109.JavaMail.zimbra@redhat.com> <1406310153.3818601.1426069818031.JavaMail.zimbra@redhat.com> <55003803.5000905@redhat.com> Message-ID: <1566209466.4485464.1426152980166.JavaMail.zimbra@redhat.com> ----- Original Message ----- > From: "Vlastimil Elias" > To: keycloak-dev at lists.jboss.org > Sent: Wednesday, 11 March, 2015 1:41:39 PM > Subject: Re: [keycloak-dev] Improvements of registration over Social Login providers > > Hi > > I see your points and understand them if you take KC as primary system > for identity. > > But things change a bit if you use UserFederationProvider SPI and > primary user database is some other backend, and KC is used primarily to > add some missing features (eg social logins, modern SSO protocols) at > top of this backend. I'm in this position and I have to propagate new > users to the backend (even one created due social login) and must > reflect some constraints from the backend (like username must be email > in my case). > > Feature proposal from point 1 is not critical for me, I think it should > be useful for some KC installations to be able to disable social > registrations, but I do not need it, so we can let it be. If you don't need it I suggest we don't add it, as we haven't had anyone else request it. > > Feature proposal 2 is more important for me. > I need email to be used as username in KC due my backend restrictions, > so I implemented some basic solution as part of KEYCLOAK-1074 pull > request. If you accept it and keep it in the code then I can use KC for > my project (or we have to find some other solution, eg some extension of > UserFederationProvider SPI to allow it to select username in case of > social registration). > > But this solution is only partial and I want to help you make KC > generally better for all use cases, so I did this proposal. I appreciate it, but if possible IMO it would be better to make it work by default rather than introducing configuration options. > > I also think that current way how KC reuses username from social > providers is wrong as it may prevent some users from login, so what to > do with this? Create a bug in JIRA? Agree - using username from social providers isn't a good approach. > > But I don't think solution with some randomly generated username, which > will be changed later, is a good one. > This may bring problems to other systems which use KC for SSO and store > data related to users. They typically rely on usernames to store these > data, but change of username in KC may break data integrity (hide data > for the user who changed username). How do you plan to prevent those > problems if you implement username change in KC? > > I understand that correct solution should be using 'User ID' in these > systems instead of username, but I fear it is not possible in many cases. > From my experience integration of existing applications like Atlassian > JIRA into SSO system may be problematic in this area, you are forced to > use usernames there, username changes are typically a problem. > So I think that username changes should be possible in KC for systems > who need it, but no any important feature like social registrations > should rely on them so heavily. Yeah, you're right we need a solution to this that doesn't require allowing usernames to be changed. How about: 1. We allow username to be null and users created through social login has a null username - this would change the login with email only feature you're implementing slightly 2. We add validation support to user profiles and if any required attributes are missing the user is required to add the missing attributes on login (before redirecting to application) 3. We add a require username/password option on social login - if this is enabled the user will have to add a username/password on first login. If not enable the same feature will be available through account management. In your use-case it would work by: * On social login if user is missing email (for example twitter) the user is shown a insert your email form as email would be marked as required. This would also work if you need other required attributes that are not available from social, for example a DOB * In the case of applications that require a username you can use the new claim mapping feature to map email to the username claim, or just make sure the application uses the email claim > > Thanks > > Vlastimil > > On 11.3.2015 11:30, Stian Thorgersen wrote: > > We can also add some more required actions: > > > > * Set email if missing > > * Set username/password > > > > It would then be possible to set one or more required actions for a first > > social login. > > > > ----- Original Message ----- > >> From: "Stian Thorgersen" > >> To: "Vlastimil Elias" > >> Cc: keycloak-dev at lists.jboss.org > >> Sent: Wednesday, 11 March, 2015 11:24:53 AM > >> Subject: Re: [keycloak-dev] Improvements of registration over Social Login > >> providers > >> > >> > >> > >> ----- Original Message ----- > >>> From: "Vlastimil Elias" > >>> To: keycloak-dev at lists.jboss.org > >>> Sent: Wednesday, 11 March, 2015 10:45:06 AM > >>> Subject: [keycloak-dev] Improvements of registration over Social Login > >>> providers > >>> > >>> Hi great Keycloak dev team, > >>> > >>> during implementation of https://issues.jboss.org/browse/KEYCLOAK-1074 I > >>> found few things which should be improved in area of registration over > >>> Social Login providers. > >>> I'd like to discuss them here before creating JIRAs. I believe I should > >>> implement these changes if you will be interested. > >>> > >>> 1. It is not possible to disable registration over Social provider > >>> ====================================== > >>> Once provider is created then it is always possible to register over it, > >>> even > >>> if "User registration" is disabled in realm "Login Settings". I think it > >>> should be possible to disable social registrations and allow only to link > >>> social logins to existing accounts (eg. loaded from other system). > >>> > >>> Marek Posolda pointed me to https://issues.jboss.org/browse/KEYCLOAK-1036 > >>> which is rejected without any comment. I understand that this global > >>> setting > >>> is probably not a good solution, so my proposal is to add independent > >>> "User > >>> registration" switch into configuration of each Identity provider, so > >>> admin > >>> will get fine grained control. > >> -1 > >> > >> IMO when you add a identity broker (or social provider) you are allowing > >> all > >> those users to login. When a user logs in the first time using a identity > >> broker we're not really registering the user, just creating an internal > >> representation. > >> > >>> 2. Username from Social provider is used as Keycloak username during > >>> registration > >>> =================================================== > >>> This can lead to the situation that user registering eg. over Twitter > >>> will > >>> not be able to register as other user eg. from Facebook will use same > >>> username there and occupy it in Keycloak as first. > >>> My proposal is to extend configuration of each Identity provider by new > >>> option "Username type" which will be select from these options: > >>> > >>> > >>> * provided username exact - works as now, username is got from > >>> provider, > >>> user can't register if occupied in KC already > >>> * provided username unique - KC will take username from provider, if > >>> occupied then it adds some random number to it to create unique > >>> username > >>> and allow user to register > >>> * provided email - this is related to KEYCLOAK-1074, I need this > >>> option > >>> for my project. I know that email is not provided by some providers > >>> (eg > >>> Twitter) so I can't use them until KEYCLOAK-1053 is resolved somehow > >>> > >>> So let me know what you think about my proposals, can I implement them? > >> -1 > >> > >> If it's using the username from the identity provider that's not correct, > >> it > >> should just be set to something unique (could be set to same as user id), > >> that's how it used to be before the identity brokering was introduced. > >> > >> We have an open issue to allow users to change their username. This would > >> then be used by a user that wants to enable regular logins in the above > >> scenario. We could improve the account management around this, for example > >> it should not display username if it's the same as user id, but have an > >> option for a user to "enable regular login" by providing a username and > >> password. > >> > >>> Cheers > >>> > >>> Vlastimil > >>> > >>> -- > >>> Vlastimil Elias > >>> Principal Software Engineer > >>> jboss.org Development Team > >>> > >>> _______________________________________________ > >>> keycloak-dev mailing list > >>> keycloak-dev at lists.jboss.org > >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev > >> _______________________________________________ > >> keycloak-dev mailing list > >> keycloak-dev at lists.jboss.org > >> https://lists.jboss.org/mailman/listinfo/keycloak-dev > >> > > -- > Vlastimil Elias > Principal Software Engineer > jboss.org Development Team > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > From mposolda at redhat.com Thu Mar 12 05:48:53 2015 From: mposolda at redhat.com (Marek Posolda) Date: Thu, 12 Mar 2015 10:48:53 +0100 Subject: [keycloak-dev] 1.2.beta1 planning, need you to defer things In-Reply-To: <1632062033.4404645.1426138834278.JavaMail.zimbra@redhat.com> References: <5500921C.8090605@redhat.com> <1632062033.4404645.1426138834278.JavaMail.zimbra@redhat.com> Message-ID: <55016105.7020700@redhat.com> On 12.3.2015 06:40, Stian Thorgersen wrote: > I'd like to reopen KEYCLOAK-311 as IMO it's not solved. This is not referring to the claim mapping work you've done, it's something else. > > Before we can do a release we need to make sure that database migration works (I know they don't atm as social providers and social links are lost). We also need to add transformation of JSON exports and representations so older versions can be imported into 1.2.0.Beta1. I did migration of social stuff for Mongo but not for jpa/liquibase though. I guess migration of protocol mappers would be needed too? As in 1.1.0.Final accessToken automatically has all the basic claims like username, email etc. So when people migrate to 1.2.0.Beta1, they would expect the same, which means that default builtin mappers for basic claims will need to be added for all the existing clients? I have also some fear if export/import would work well together with protocol mappers. During import of previously exported application, the import shouldn't try to add all default mappers, but just those which were previously exported. Currently import invokes realm.addApplication(), which will trigger listeners for adding all default builtin mappers. I did not test it yet, but my bet is that it won't work well atm... Marek > > With all the changes we've done for this release (modules, claim mapping, identity brokering, oidc endpoints, ...) we need to do more testing this time around! > > ----- Original Message ----- >> From: "Bill Burke" >> To: keycloak-dev at lists.jboss.org >> Sent: Wednesday, 11 March, 2015 8:06:04 PM >> Subject: [keycloak-dev] 1.2.beta1 planning, need you to defer things >> >> I'd like to do 1.2.beta1 by end of month or earlier. Please go through >> the jira list and defer things you are not going to get to in the next >> 1-2 weeks. Thanks. > Done > >> I'm going to try and close existing bugs and implement features needed >> for jboss.org guys over the next 2 weeks as well as test out master to >> make sure things still work. > With regards to jboss.org guys we shouldn't just add features because they request it. Take for example KEYCLOAK-1045, which was easily solved with we already have. Another one is KEYCLOAK-1051, which I think is a horrible idea. > >> Bill >> >> -- >> Bill Burke >> JBoss, a division of Red Hat >> http://bill.burkecentral.com >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev From stian at redhat.com Thu Mar 12 05:49:38 2015 From: stian at redhat.com (Stian Thorgersen) Date: Thu, 12 Mar 2015 05:49:38 -0400 (EDT) Subject: [keycloak-dev] Issue with latest Github master and SAML IDP providers? In-Reply-To: References: Message-ID: <404035330.4495455.1426153778301.JavaMail.zimbra@redhat.com> Are you still having issues or did you figure it out? ----- Original Message ----- > From: "Guy Davis" > To: keycloak-dev at lists.jboss.org > Sent: Wednesday, 4 March, 2015 1:10:52 AM > Subject: [keycloak-dev] Issue with latest Github master and SAML IDP providers? > > Good day, > > I've been using a sample Picketlink IDP locally for testing the SAML v2.0 ID > brokering, however after updating to latest master and re-deploying > components, I'm getting the following error. Any tips? > > > > Thanks in advance, > Guy > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev From stian at redhat.com Thu Mar 12 05:51:54 2015 From: stian at redhat.com (Stian Thorgersen) Date: Thu, 12 Mar 2015 05:51:54 -0400 (EDT) Subject: [keycloak-dev] 1.2.beta1 planning, need you to defer things In-Reply-To: <55016105.7020700@redhat.com> References: <5500921C.8090605@redhat.com> <1632062033.4404645.1426138834278.JavaMail.zimbra@redhat.com> <55016105.7020700@redhat.com> Message-ID: <1987968226.4496128.1426153914935.JavaMail.zimbra@redhat.com> ----- Original Message ----- > From: "Marek Posolda" > To: "Stian Thorgersen" , "Bill Burke" > Cc: keycloak-dev at lists.jboss.org > Sent: Thursday, 12 March, 2015 10:48:53 AM > Subject: Re: [keycloak-dev] 1.2.beta1 planning, need you to defer things > > On 12.3.2015 06:40, Stian Thorgersen wrote: > > I'd like to reopen KEYCLOAK-311 as IMO it's not solved. This is not > > referring to the claim mapping work you've done, it's something else. > > > > Before we can do a release we need to make sure that database migration > > works (I know they don't atm as social providers and social links are > > lost). We also need to add transformation of JSON exports and > > representations so older versions can be imported into 1.2.0.Beta1. > I did migration of social stuff for Mongo but not for jpa/liquibase > though. I guess migration of protocol mappers would be needed too? As in > 1.1.0.Final accessToken automatically has all the basic claims like > username, email etc. So when people migrate to 1.2.0.Beta1, they would > expect the same, which means that default builtin mappers for basic > claims will need to be added for all the existing clients? +1 Can you create a jira so we don't forget? > > I have also some fear if export/import would work well together with > protocol mappers. During import of previously exported application, the > import shouldn't try to add all default mappers, but just those which > were previously exported. Currently import invokes > realm.addApplication(), which will trigger listeners for adding all > default builtin mappers. I did not test it yet, but my bet is that it > won't work well atm... +1 Can you test and jira please? > > Marek > > > > With all the changes we've done for this release (modules, claim mapping, > > identity brokering, oidc endpoints, ...) we need to do more testing this > > time around! > > > > ----- Original Message ----- > >> From: "Bill Burke" > >> To: keycloak-dev at lists.jboss.org > >> Sent: Wednesday, 11 March, 2015 8:06:04 PM > >> Subject: [keycloak-dev] 1.2.beta1 planning, need you to defer things > >> > >> I'd like to do 1.2.beta1 by end of month or earlier. Please go through > >> the jira list and defer things you are not going to get to in the next > >> 1-2 weeks. Thanks. > > Done > > > >> I'm going to try and close existing bugs and implement features needed > >> for jboss.org guys over the next 2 weeks as well as test out master to > >> make sure things still work. > > With regards to jboss.org guys we shouldn't just add features because they > > request it. Take for example KEYCLOAK-1045, which was easily solved with > > we already have. Another one is KEYCLOAK-1051, which I think is a horrible > > idea. > > > >> Bill > >> > >> -- > >> Bill Burke > >> JBoss, a division of Red Hat > >> http://bill.burkecentral.com > >> _______________________________________________ > >> keycloak-dev mailing list > >> keycloak-dev at lists.jboss.org > >> https://lists.jboss.org/mailman/listinfo/keycloak-dev > >> > > _______________________________________________ > > keycloak-dev mailing list > > keycloak-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > From mposolda at redhat.com Thu Mar 12 06:03:56 2015 From: mposolda at redhat.com (Marek Posolda) Date: Thu, 12 Mar 2015 11:03:56 +0100 Subject: [keycloak-dev] 1.2.beta1 planning, need you to defer things In-Reply-To: <1987968226.4496128.1426153914935.JavaMail.zimbra@redhat.com> References: <5500921C.8090605@redhat.com> <1632062033.4404645.1426138834278.JavaMail.zimbra@redhat.com> <55016105.7020700@redhat.com> <1987968226.4496128.1426153914935.JavaMail.zimbra@redhat.com> Message-ID: <5501648C.1060502@redhat.com> On 12.3.2015 10:51, Stian Thorgersen wrote: > > ----- Original Message ----- >> From: "Marek Posolda" >> To: "Stian Thorgersen" , "Bill Burke" >> Cc: keycloak-dev at lists.jboss.org >> Sent: Thursday, 12 March, 2015 10:48:53 AM >> Subject: Re: [keycloak-dev] 1.2.beta1 planning, need you to defer things >> >> On 12.3.2015 06:40, Stian Thorgersen wrote: >>> I'd like to reopen KEYCLOAK-311 as IMO it's not solved. This is not >>> referring to the claim mapping work you've done, it's something else. >>> >>> Before we can do a release we need to make sure that database migration >>> works (I know they don't atm as social providers and social links are >>> lost). We also need to add transformation of JSON exports and >>> representations so older versions can be imported into 1.2.0.Beta1. >> I did migration of social stuff for Mongo but not for jpa/liquibase >> though. I guess migration of protocol mappers would be needed too? As in >> 1.1.0.Final accessToken automatically has all the basic claims like >> username, email etc. So when people migrate to 1.2.0.Beta1, they would >> expect the same, which means that default builtin mappers for basic >> claims will need to be added for all the existing clients? > +1 Can you create a jira so we don't forget? Done https://issues.jboss.org/browse/KEYCLOAK-1098 JIRA for social migration of JPA model is https://issues.jboss.org/browse/KEYCLOAK-1004 . I will retest mongo migration again before release (there may be some additional changes in the identityProvider model in the meantime) > >> I have also some fear if export/import would work well together with >> protocol mappers. During import of previously exported application, the >> import shouldn't try to add all default mappers, but just those which >> were previously exported. Currently import invokes >> realm.addApplication(), which will trigger listeners for adding all >> default builtin mappers. I did not test it yet, but my bet is that it >> won't work well atm... > +1 Can you test and jira please? Done https://issues.jboss.org/browse/KEYCLOAK-1099 > >> Marek >>> With all the changes we've done for this release (modules, claim mapping, >>> identity brokering, oidc endpoints, ...) we need to do more testing this >>> time around! >>> >>> ----- Original Message ----- >>>> From: "Bill Burke" >>>> To: keycloak-dev at lists.jboss.org >>>> Sent: Wednesday, 11 March, 2015 8:06:04 PM >>>> Subject: [keycloak-dev] 1.2.beta1 planning, need you to defer things >>>> >>>> I'd like to do 1.2.beta1 by end of month or earlier. Please go through >>>> the jira list and defer things you are not going to get to in the next >>>> 1-2 weeks. Thanks. >>> Done >>> >>>> I'm going to try and close existing bugs and implement features needed >>>> for jboss.org guys over the next 2 weeks as well as test out master to >>>> make sure things still work. >>> With regards to jboss.org guys we shouldn't just add features because they >>> request it. Take for example KEYCLOAK-1045, which was easily solved with >>> we already have. Another one is KEYCLOAK-1051, which I think is a horrible >>> idea. >>> >>>> Bill >>>> >>>> -- >>>> Bill Burke >>>> JBoss, a division of Red Hat >>>> http://bill.burkecentral.com >>>> _______________________________________________ >>>> keycloak-dev mailing list >>>> keycloak-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>>> >>> _______________________________________________ >>> keycloak-dev mailing list >>> keycloak-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> From mposolda at redhat.com Thu Mar 12 06:18:58 2015 From: mposolda at redhat.com (Marek Posolda) Date: Thu, 12 Mar 2015 11:18:58 +0100 Subject: [keycloak-dev] 1.2.beta1 planning, need you to defer things In-Reply-To: <5501648C.1060502@redhat.com> References: <5500921C.8090605@redhat.com> <1632062033.4404645.1426138834278.JavaMail.zimbra@redhat.com> <55016105.7020700@redhat.com> <1987968226.4496128.1426153914935.JavaMail.zimbra@redhat.com> <5501648C.1060502@redhat.com> Message-ID: <55016812.3060208@redhat.com> I've assigned KEYCLOAK-1004 (jpa migration of social) to myself. Should I take a look at the same time on KEYCLOAK-1098 when I am looking at migration? Marek On 12.3.2015 11:03, Marek Posolda wrote: > On 12.3.2015 10:51, Stian Thorgersen wrote: >> ----- Original Message ----- >>> From: "Marek Posolda" >>> To: "Stian Thorgersen" , "Bill Burke" >>> Cc: keycloak-dev at lists.jboss.org >>> Sent: Thursday, 12 March, 2015 10:48:53 AM >>> Subject: Re: [keycloak-dev] 1.2.beta1 planning, need you to defer things >>> >>> On 12.3.2015 06:40, Stian Thorgersen wrote: >>>> I'd like to reopen KEYCLOAK-311 as IMO it's not solved. This is not >>>> referring to the claim mapping work you've done, it's something else. >>>> >>>> Before we can do a release we need to make sure that database migration >>>> works (I know they don't atm as social providers and social links are >>>> lost). We also need to add transformation of JSON exports and >>>> representations so older versions can be imported into 1.2.0.Beta1. >>> I did migration of social stuff for Mongo but not for jpa/liquibase >>> though. I guess migration of protocol mappers would be needed too? As in >>> 1.1.0.Final accessToken automatically has all the basic claims like >>> username, email etc. So when people migrate to 1.2.0.Beta1, they would >>> expect the same, which means that default builtin mappers for basic >>> claims will need to be added for all the existing clients? >> +1 Can you create a jira so we don't forget? > Done https://issues.jboss.org/browse/KEYCLOAK-1098 > > JIRA for social migration of JPA model is > https://issues.jboss.org/browse/KEYCLOAK-1004 . I will retest mongo > migration again before release (there may be some additional changes in > the identityProvider model in the meantime) >>> I have also some fear if export/import would work well together with >>> protocol mappers. During import of previously exported application, the >>> import shouldn't try to add all default mappers, but just those which >>> were previously exported. Currently import invokes >>> realm.addApplication(), which will trigger listeners for adding all >>> default builtin mappers. I did not test it yet, but my bet is that it >>> won't work well atm... >> +1 Can you test and jira please? > Done https://issues.jboss.org/browse/KEYCLOAK-1099 >>> Marek >>>> With all the changes we've done for this release (modules, claim mapping, >>>> identity brokering, oidc endpoints, ...) we need to do more testing this >>>> time around! >>>> >>>> ----- Original Message ----- >>>>> From: "Bill Burke" >>>>> To: keycloak-dev at lists.jboss.org >>>>> Sent: Wednesday, 11 March, 2015 8:06:04 PM >>>>> Subject: [keycloak-dev] 1.2.beta1 planning, need you to defer things >>>>> >>>>> I'd like to do 1.2.beta1 by end of month or earlier. Please go through >>>>> the jira list and defer things you are not going to get to in the next >>>>> 1-2 weeks. Thanks. >>>> Done >>>> >>>>> I'm going to try and close existing bugs and implement features needed >>>>> for jboss.org guys over the next 2 weeks as well as test out master to >>>>> make sure things still work. >>>> With regards to jboss.org guys we shouldn't just add features because they >>>> request it. Take for example KEYCLOAK-1045, which was easily solved with >>>> we already have. Another one is KEYCLOAK-1051, which I think is a horrible >>>> idea. >>>> >>>>> Bill >>>>> >>>>> -- >>>>> Bill Burke >>>>> JBoss, a division of Red Hat >>>>> http://bill.burkecentral.com >>>>> _______________________________________________ >>>>> keycloak-dev mailing list >>>>> keycloak-dev at lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>>>> >>>> _______________________________________________ >>>> keycloak-dev mailing list >>>> keycloak-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev From bburke at redhat.com Thu Mar 12 08:57:21 2015 From: bburke at redhat.com (Bill Burke) Date: Thu, 12 Mar 2015 08:57:21 -0400 Subject: [keycloak-dev] 1.2.beta1 planning, need you to defer things In-Reply-To: <1632062033.4404645.1426138834278.JavaMail.zimbra@redhat.com> References: <5500921C.8090605@redhat.com> <1632062033.4404645.1426138834278.JavaMail.zimbra@redhat.com> Message-ID: <55018D31.5090200@redhat.com> On 3/12/2015 1:40 AM, Stian Thorgersen wrote: > I'd like to reopen KEYCLOAK-311 as IMO it's not solved. This is not referring to the claim mapping work you've done, it's something else. > I opened two jiras. One, a "claim validation" jira and another broker->Usermodel mappers. That should have covered what 311 is not doing. > Before we can do a release we need to make sure that database migration works (I know they don't atm as social providers and social links are lost). We also need to add transformation of JSON exports and representations so older versions can be imported into 1.2.0.Beta1. > Not sure, but json imports from older versions should be backwards compatible. We're just doing migrations via json export/import right? >> >> I'm going to try and close existing bugs and implement features needed >> for jboss.org guys over the next 2 weeks as well as test out master to >> make sure things still work. > > With regards to jboss.org guys we shouldn't just add features because they request it. Take for example KEYCLOAK-1045, which was easily solved with we already have. Another one is KEYCLOAK-1051, which I think is a horrible idea. > I don't want to just add features either, but some of their things are valid...i.e. finding out if a user is logged and who they are without doing all the token stuff. -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From bburke at redhat.com Thu Mar 12 09:07:52 2015 From: bburke at redhat.com (Bill Burke) Date: Thu, 12 Mar 2015 09:07:52 -0400 Subject: [keycloak-dev] 1.2.beta1 planning, need you to defer things In-Reply-To: <1987968226.4496128.1426153914935.JavaMail.zimbra@redhat.com> References: <5500921C.8090605@redhat.com> <1632062033.4404645.1426138834278.JavaMail.zimbra@redhat.com> <55016105.7020700@redhat.com> <1987968226.4496128.1426153914935.JavaMail.zimbra@redhat.com> Message-ID: <55018FA8.70200@redhat.com> On 3/12/2015 5:51 AM, Stian Thorgersen wrote: > > > ----- Original Message ----- >> From: "Marek Posolda" >> To: "Stian Thorgersen" , "Bill Burke" >> Cc: keycloak-dev at lists.jboss.org >> Sent: Thursday, 12 March, 2015 10:48:53 AM >> Subject: Re: [keycloak-dev] 1.2.beta1 planning, need you to defer things >> >> On 12.3.2015 06:40, Stian Thorgersen wrote: >>> I'd like to reopen KEYCLOAK-311 as IMO it's not solved. This is not >>> referring to the claim mapping work you've done, it's something else. >>> >>> Before we can do a release we need to make sure that database migration >>> works (I know they don't atm as social providers and social links are >>> lost). We also need to add transformation of JSON exports and >>> representations so older versions can be imported into 1.2.0.Beta1. >> I did migration of social stuff for Mongo but not for jpa/liquibase >> though. I guess migration of protocol mappers would be needed too? As in >> 1.1.0.Final accessToken automatically has all the basic claims like >> username, email etc. So when people migrate to 1.2.0.Beta1, they would >> expect the same, which means that default builtin mappers for basic >> claims will need to be added for all the existing clients? > > +1 Can you create a jira so we don't forget? > Protocol mappers should already automatically be set up if the user exports Keycloak 1.1 json and re-imports it. >> >> I have also some fear if export/import would work well together with >> protocol mappers. During import of previously exported application, the >> import shouldn't try to add all default mappers, but just those which >> were previously exported. Currently import invokes >> realm.addApplication(), which will trigger listeners for adding all >> default builtin mappers. I did not test it yet, but my bet is that it >> won't work well atm... > > +1 Can you test and jira please? > The way it works is: 1. realm.addApplication() 2. builtin mappers installed 3. If application json has mappers, then current mappers are cleared and the mappers defined in the json file are used. I can add a test for this quite easily as I'm already importing json with exported mappers. Doing this right now. Bill -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From bburke at redhat.com Thu Mar 12 09:17:10 2015 From: bburke at redhat.com (Bill Burke) Date: Thu, 12 Mar 2015 09:17:10 -0400 Subject: [keycloak-dev] JWK Message-ID: <550191D6.7090604@redhat.com> Not sure why we have JWK support and I hope it is not on by default. JWK is really only useful in the case where the client needs to identify the key needed to use to decrypt or validate an ID token/access token. In our implementation we do not have the ability to have different signers. This knowledge is expected to be provided in configuration. -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From stian at redhat.com Thu Mar 12 10:41:51 2015 From: stian at redhat.com (Stian Thorgersen) Date: Thu, 12 Mar 2015 10:41:51 -0400 (EDT) Subject: [keycloak-dev] 1.2.beta1 planning, need you to defer things In-Reply-To: <55018D31.5090200@redhat.com> References: <5500921C.8090605@redhat.com> <1632062033.4404645.1426138834278.JavaMail.zimbra@redhat.com> <55018D31.5090200@redhat.com> Message-ID: <1308740292.4822787.1426171311061.JavaMail.zimbra@redhat.com> ----- Original Message ----- > From: "Bill Burke" > To: "Stian Thorgersen" > Cc: keycloak-dev at lists.jboss.org > Sent: Thursday, 12 March, 2015 1:57:21 PM > Subject: Re: [keycloak-dev] 1.2.beta1 planning, need you to defer things > > > > On 3/12/2015 1:40 AM, Stian Thorgersen wrote: > > I'd like to reopen KEYCLOAK-311 as IMO it's not solved. This is not > > referring to the claim mapping work you've done, it's something else. > > > > I opened two jiras. One, a "claim validation" jira and another > broker->Usermodel mappers. That should have covered what 311 is not doing. Not IMO. We really need to have something that defines how the internal user profile looks like, attribute validation, what attributes are required, etc.. Also, I really don't think we should require users to modify registration screens and admin console if all they want to do is for example to add a DOB field. > > > Before we can do a release we need to make sure that database migration > > works (I know they don't atm as social providers and social links are > > lost). We also need to add transformation of JSON exports and > > representations so older versions can be imported into 1.2.0.Beta1. > > > > Not sure, but json imports from older versions should be backwards > compatible. We're just doing migrations via json export/import right? No, we migrate the database directly. https://github.com/keycloak/keycloak/blob/master/misc/UpdatingDatabaseSchema.md > > >> > >> I'm going to try and close existing bugs and implement features needed > >> for jboss.org guys over the next 2 weeks as well as test out master to > >> make sure things still work. > > > > With regards to jboss.org guys we shouldn't just add features because they > > request it. Take for example KEYCLOAK-1045, which was easily solved with > > we already have. Another one is KEYCLOAK-1051, which I think is a horrible > > idea. > > > > I don't want to just add features either, but some of their things are > valid...i.e. finding out if a user is logged and who they are without > doing all the token stuff. That's exactly one of the things that are not necessary, I've added a POC that uses keycloak.js, which they where happy with. See KEYCLOAK-1045 and http://stianst.github.io/jbossorg/index.html. > > > -- > Bill Burke > JBoss, a division of Red Hat > http://bill.burkecentral.com > From stian at redhat.com Thu Mar 12 10:45:04 2015 From: stian at redhat.com (Stian Thorgersen) Date: Thu, 12 Mar 2015 10:45:04 -0400 (EDT) Subject: [keycloak-dev] JWK In-Reply-To: <550191D6.7090604@redhat.com> References: <550191D6.7090604@redhat.com> Message-ID: <921481207.4825144.1426171504884.JavaMail.zimbra@redhat.com> It's required by OpenID Connect Discovery and is useful to 3rd party libraries, we'll need it to pass OIDC interoperability. Why should it not be enabled by default? It's just the public realm key in a reusable json format. We should have used JWK in keycloak.json files as well. ----- Original Message ----- > From: "Bill Burke" > To: keycloak-dev at lists.jboss.org > Sent: Thursday, 12 March, 2015 2:17:10 PM > Subject: [keycloak-dev] JWK > > Not sure why we have JWK support and I hope it is not on by default. > JWK is really only useful in the case where the client needs to identify > the key needed to use to decrypt or validate an ID token/access token. > In our implementation we do not have the ability to have different > signers. This knowledge is expected to be provided in configuration. > -- > Bill Burke > JBoss, a division of Red Hat > http://bill.burkecentral.com > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > From bburke at redhat.com Thu Mar 12 10:48:46 2015 From: bburke at redhat.com (Bill Burke) Date: Thu, 12 Mar 2015 10:48:46 -0400 Subject: [keycloak-dev] 1.2.beta1 planning, need you to defer things In-Reply-To: <1308740292.4822787.1426171311061.JavaMail.zimbra@redhat.com> References: <5500921C.8090605@redhat.com> <1632062033.4404645.1426138834278.JavaMail.zimbra@redhat.com> <55018D31.5090200@redhat.com> <1308740292.4822787.1426171311061.JavaMail.zimbra@redhat.com> Message-ID: <5501A74E.1030200@redhat.com> On 3/12/2015 10:41 AM, Stian Thorgersen wrote: > > > ----- Original Message ----- >> From: "Bill Burke" >> To: "Stian Thorgersen" >> Cc: keycloak-dev at lists.jboss.org >> Sent: Thursday, 12 March, 2015 1:57:21 PM >> Subject: Re: [keycloak-dev] 1.2.beta1 planning, need you to defer things >> >> >> >> On 3/12/2015 1:40 AM, Stian Thorgersen wrote: >>> I'd like to reopen KEYCLOAK-311 as IMO it's not solved. This is not >>> referring to the claim mapping work you've done, it's something else. >>> >> >> I opened two jiras. One, a "claim validation" jira and another >> broker->Usermodel mappers. That should have covered what 311 is not doing. > > Not IMO. We really need to have something that defines how the internal user profile looks like, attribute validation, what attributes are required, etc.. Also, I really don't think we should require users to modify registration screens and admin console if all they want to do is for example to add a DOB field. > I disagree. They will be editing these pages anyways to get the look and feel they want. As i said over and over, you'll just be re-creating HTML within the data model. >> >>> Before we can do a release we need to make sure that database migration >>> works (I know they don't atm as social providers and social links are >>> lost). We also need to add transformation of JSON exports and >>> representations so older versions can be imported into 1.2.0.Beta1. >>> >> >> Not sure, but json imports from older versions should be backwards >> compatible. We're just doing migrations via json export/import right? > > No, we migrate the database directly. https://github.com/keycloak/keycloak/blob/master/misc/UpdatingDatabaseSchema.md > >> >>>> >>>> I'm going to try and close existing bugs and implement features needed >>>> for jboss.org guys over the next 2 weeks as well as test out master to >>>> make sure things still work. >>> >>> With regards to jboss.org guys we shouldn't just add features because they >>> request it. Take for example KEYCLOAK-1045, which was easily solved with >>> we already have. Another one is KEYCLOAK-1051, which I think is a horrible >>> idea. >>> >> >> I don't want to just add features either, but some of their things are >> valid...i.e. finding out if a user is logged and who they are without >> doing all the token stuff. > > That's exactly one of the things that are not necessary, I've added a POC that uses keycloak.js, which they where happy with. See KEYCLOAK-1045 and http://stianst.github.io/jbossorg/index.html. > I'll take a look, but IIRC there was a different issue described (not 1045), where a static home page shouldn't have to perform a full login and obtain a token just to know whether or not a user is logged in and who they are. -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From bburke at redhat.com Thu Mar 12 10:50:39 2015 From: bburke at redhat.com (Bill Burke) Date: Thu, 12 Mar 2015 10:50:39 -0400 Subject: [keycloak-dev] JWK In-Reply-To: <921481207.4825144.1426171504884.JavaMail.zimbra@redhat.com> References: <550191D6.7090604@redhat.com> <921481207.4825144.1426171504884.JavaMail.zimbra@redhat.com> Message-ID: <5501A7BF.8010703@redhat.com> JWK shouldn't be transmitted with ID Token and/or access token by default is what I mean. If I remember the specs correctly. Bloats the tokens and requires more parsing time. On 3/12/2015 10:45 AM, Stian Thorgersen wrote: > It's required by OpenID Connect Discovery and is useful to 3rd party libraries, we'll need it to pass OIDC interoperability. > > Why should it not be enabled by default? It's just the public realm key in a reusable json format. > > We should have used JWK in keycloak.json files as well. > > ----- Original Message ----- >> From: "Bill Burke" >> To: keycloak-dev at lists.jboss.org >> Sent: Thursday, 12 March, 2015 2:17:10 PM >> Subject: [keycloak-dev] JWK >> >> Not sure why we have JWK support and I hope it is not on by default. >> JWK is really only useful in the case where the client needs to identify >> the key needed to use to decrypt or validate an ID token/access token. >> In our implementation we do not have the ability to have different >> signers. This knowledge is expected to be provided in configuration. >> -- >> Bill Burke >> JBoss, a division of Red Hat >> http://bill.burkecentral.com >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From stian at redhat.com Thu Mar 12 10:56:24 2015 From: stian at redhat.com (Stian Thorgersen) Date: Thu, 12 Mar 2015 10:56:24 -0400 (EDT) Subject: [keycloak-dev] JWK In-Reply-To: <5501A7BF.8010703@redhat.com> References: <550191D6.7090604@redhat.com> <921481207.4825144.1426171504884.JavaMail.zimbra@redhat.com> <5501A7BF.8010703@redhat.com> Message-ID: <107320048.4836039.1426172184044.JavaMail.zimbra@redhat.com> ----- Original Message ----- > From: "Bill Burke" > To: "Stian Thorgersen" > Cc: keycloak-dev at lists.jboss.org > Sent: Thursday, 12 March, 2015 3:50:39 PM > Subject: Re: [keycloak-dev] JWK > > JWK shouldn't be transmitted with ID Token and/or access token by > default is what I mean. If I remember the specs correctly. Bloats the > tokens and requires more parsing time. That's how we sign the access token isn't it? Is there an option to include it in the token itself? > > On 3/12/2015 10:45 AM, Stian Thorgersen wrote: > > It's required by OpenID Connect Discovery and is useful to 3rd party > > libraries, we'll need it to pass OIDC interoperability. > > > > Why should it not be enabled by default? It's just the public realm key in > > a reusable json format. > > > > We should have used JWK in keycloak.json files as well. > > > > ----- Original Message ----- > >> From: "Bill Burke" > >> To: keycloak-dev at lists.jboss.org > >> Sent: Thursday, 12 March, 2015 2:17:10 PM > >> Subject: [keycloak-dev] JWK > >> > >> Not sure why we have JWK support and I hope it is not on by default. > >> JWK is really only useful in the case where the client needs to identify > >> the key needed to use to decrypt or validate an ID token/access token. > >> In our implementation we do not have the ability to have different > >> signers. This knowledge is expected to be provided in configuration. > >> -- > >> Bill Burke > >> JBoss, a division of Red Hat > >> http://bill.burkecentral.com > >> _______________________________________________ > >> keycloak-dev mailing list > >> keycloak-dev at lists.jboss.org > >> https://lists.jboss.org/mailman/listinfo/keycloak-dev > >> > > -- > Bill Burke > JBoss, a division of Red Hat > http://bill.burkecentral.com > From bburke at redhat.com Thu Mar 12 10:57:30 2015 From: bburke at redhat.com (Bill Burke) Date: Thu, 12 Mar 2015 10:57:30 -0400 Subject: [keycloak-dev] 1.2.beta1 planning, need you to defer things In-Reply-To: <1308740292.4822787.1426171311061.JavaMail.zimbra@redhat.com> References: <5500921C.8090605@redhat.com> <1632062033.4404645.1426138834278.JavaMail.zimbra@redhat.com> <55018D31.5090200@redhat.com> <1308740292.4822787.1426171311061.JavaMail.zimbra@redhat.com> Message-ID: <5501A95A.50308@redhat.com> On 3/12/2015 10:41 AM, Stian Thorgersen wrote: >> >>> Before we can do a release we need to make sure that database migration >>> works (I know they don't atm as social providers and social links are >>> lost). We also need to add transformation of JSON exports and >>> representations so older versions can be imported into 1.2.0.Beta1. >>> >> >> Not sure, but json imports from older versions should be backwards >> compatible. We're just doing migrations via json export/import right? > > No, we migrate the database directly. https://github.com/keycloak/keycloak/blob/master/misc/UpdatingDatabaseSchema.md > This direct database migration is just schema changes correct? I already updated the 1.2.x liquibase migrater to put in my db schema changes for protocol mappers. -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From stian at redhat.com Thu Mar 12 11:01:32 2015 From: stian at redhat.com (Stian Thorgersen) Date: Thu, 12 Mar 2015 11:01:32 -0400 (EDT) Subject: [keycloak-dev] 1.2.beta1 planning, need you to defer things In-Reply-To: <5501A74E.1030200@redhat.com> References: <5500921C.8090605@redhat.com> <1632062033.4404645.1426138834278.JavaMail.zimbra@redhat.com> <55018D31.5090200@redhat.com> <1308740292.4822787.1426171311061.JavaMail.zimbra@redhat.com> <5501A74E.1030200@redhat.com> Message-ID: <1343522364.4840378.1426172492478.JavaMail.zimbra@redhat.com> ----- Original Message ----- > From: "Bill Burke" > To: "Stian Thorgersen" > Cc: keycloak-dev at lists.jboss.org > Sent: Thursday, 12 March, 2015 3:48:46 PM > Subject: Re: [keycloak-dev] 1.2.beta1 planning, need you to defer things > > > > On 3/12/2015 10:41 AM, Stian Thorgersen wrote: > > > > > > ----- Original Message ----- > >> From: "Bill Burke" > >> To: "Stian Thorgersen" > >> Cc: keycloak-dev at lists.jboss.org > >> Sent: Thursday, 12 March, 2015 1:57:21 PM > >> Subject: Re: [keycloak-dev] 1.2.beta1 planning, need you to defer things > >> > >> > >> > >> On 3/12/2015 1:40 AM, Stian Thorgersen wrote: > >>> I'd like to reopen KEYCLOAK-311 as IMO it's not solved. This is not > >>> referring to the claim mapping work you've done, it's something else. > >>> > >> > >> I opened two jiras. One, a "claim validation" jira and another > >> broker->Usermodel mappers. That should have covered what 311 is not > >> doing. > > > > Not IMO. We really need to have something that defines how the internal > > user profile looks like, attribute validation, what attributes are > > required, etc.. Also, I really don't think we should require users to > > modify registration screens and admin console if all they want to do is > > for example to add a DOB field. > > > > I disagree. They will be editing these pages anyways to get the look > and feel they want. As i said over and over, you'll just be re-creating > HTML within the data model. As I've said several times they don't need to change the pages to modify the l&f that's the whole purpose of CSS. Have you looked at cengarden that I sent you links to? Have you looked at the sunset theme example I've added? I have no idea what you mean about re-creating HTML within the data model. What I'm talking about is something like A user profile is defined as something like: Name Type Required Validation -------------------------------------------- First name string required ... Last name string required Email string required DOB - date - optional Address address We then populate the registration field using those values. We can have templates for how to display individual types. That means users only have to edit a small snippet of html instead of editing and maintaining the whole registration template. > > >> > >>> Before we can do a release we need to make sure that database migration > >>> works (I know they don't atm as social providers and social links are > >>> lost). We also need to add transformation of JSON exports and > >>> representations so older versions can be imported into 1.2.0.Beta1. > >>> > >> > >> Not sure, but json imports from older versions should be backwards > >> compatible. We're just doing migrations via json export/import right? > > > > No, we migrate the database directly. > > https://github.com/keycloak/keycloak/blob/master/misc/UpdatingDatabaseSchema.md > > > >> > >>>> > >>>> I'm going to try and close existing bugs and implement features needed > >>>> for jboss.org guys over the next 2 weeks as well as test out master to > >>>> make sure things still work. > >>> > >>> With regards to jboss.org guys we shouldn't just add features because > >>> they > >>> request it. Take for example KEYCLOAK-1045, which was easily solved with > >>> we already have. Another one is KEYCLOAK-1051, which I think is a > >>> horrible > >>> idea. > >>> > >> > >> I don't want to just add features either, but some of their things are > >> valid...i.e. finding out if a user is logged and who they are without > >> doing all the token stuff. > > > > That's exactly one of the things that are not necessary, I've added a POC > > that uses keycloak.js, which they where happy with. See KEYCLOAK-1045 and > > http://stianst.github.io/jbossorg/index.html. > > > > I'll take a look, but IIRC there was a different issue described (not > 1045), where a static home page shouldn't have to perform a full login > and obtain a token just to know whether or not a user is logged in and > who they are. > > -- > Bill Burke > JBoss, a division of Red Hat > http://bill.burkecentral.com > From stian at redhat.com Thu Mar 12 11:02:50 2015 From: stian at redhat.com (Stian Thorgersen) Date: Thu, 12 Mar 2015 11:02:50 -0400 (EDT) Subject: [keycloak-dev] 1.2.beta1 planning, need you to defer things In-Reply-To: <5501A95A.50308@redhat.com> References: <5500921C.8090605@redhat.com> <1632062033.4404645.1426138834278.JavaMail.zimbra@redhat.com> <55018D31.5090200@redhat.com> <1308740292.4822787.1426171311061.JavaMail.zimbra@redhat.com> <5501A95A.50308@redhat.com> Message-ID: <1934188996.4841316.1426172570916.JavaMail.zimbra@redhat.com> ----- Original Message ----- > From: "Bill Burke" > To: "Stian Thorgersen" > Cc: keycloak-dev at lists.jboss.org > Sent: Thursday, 12 March, 2015 3:57:30 PM > Subject: Re: [keycloak-dev] 1.2.beta1 planning, need you to defer things > > > > On 3/12/2015 10:41 AM, Stian Thorgersen wrote: > >> > >>> Before we can do a release we need to make sure that database migration > >>> works (I know they don't atm as social providers and social links are > >>> lost). We also need to add transformation of JSON exports and > >>> representations so older versions can be imported into 1.2.0.Beta1. > >>> > >> > >> Not sure, but json imports from older versions should be backwards > >> compatible. We're just doing migrations via json export/import right? > > > > No, we migrate the database directly. > > https://github.com/keycloak/keycloak/blob/master/misc/UpdatingDatabaseSchema.md > > > > This direct database migration is just schema changes correct? I > already updated the 1.2.x liquibase migrater to put in my db schema > changes for protocol mappers. No it should migrate data as well. We can write custom migration tasks for Liquibase and Mongo that takes care of translating the data. It's just going to be much simpler and quicker for users to upgrade that way than having to export/import to json. Especially if they have a large db. > > > > -- > Bill Burke > JBoss, a division of Red Hat > http://bill.burkecentral.com > From bburke at redhat.com Thu Mar 12 11:08:09 2015 From: bburke at redhat.com (Bill Burke) Date: Thu, 12 Mar 2015 11:08:09 -0400 Subject: [keycloak-dev] JWK In-Reply-To: <107320048.4836039.1426172184044.JavaMail.zimbra@redhat.com> References: <550191D6.7090604@redhat.com> <921481207.4825144.1426171504884.JavaMail.zimbra@redhat.com> <5501A7BF.8010703@redhat.com> <107320048.4836039.1426172184044.JavaMail.zimbra@redhat.com> Message-ID: <5501ABD9.3070401@redhat.com> On 3/12/2015 10:56 AM, Stian Thorgersen wrote: > > > ----- Original Message ----- >> From: "Bill Burke" >> To: "Stian Thorgersen" >> Cc: keycloak-dev at lists.jboss.org >> Sent: Thursday, 12 March, 2015 3:50:39 PM >> Subject: Re: [keycloak-dev] JWK >> >> JWK shouldn't be transmitted with ID Token and/or access token by >> default is what I mean. If I remember the specs correctly. Bloats the >> tokens and requires more parsing time. > > That's how we sign the access token isn't it? Is there an option to include it in the token itself? > You don't need to store JWK information in the JWS header of the access token because the adapter only works with one realm and one public realm key. We're not doing certificate chains either. -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From jpkroehling at redhat.com Thu Mar 12 12:41:25 2015 From: jpkroehling at redhat.com (=?UTF-8?B?SnVyYWNpIFBhaXjDo28gS3LDtmhsaW5n?=) Date: Thu, 12 Mar 2015 17:41:25 +0100 Subject: [keycloak-dev] Password policy for "password != username" Message-ID: <5501C1B5.8040909@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 All, I've asked on the IRC channel, but it seems it's better to have a first discussion here before opening a JIRA and/or sending a PR. I have a requirement in my application, where the user's passwords should meet some complexity. The initial rules will be based on Wildfly's own rules. Two of them I can fulfill via Keycloak, but the third is: "The password must be different from the username". I couldn't find a way to do it with the current policy configuration. So, should this be possible? If so, what would be the syntax? My first suggestion would be "notUsername()". Is this acceptable? Should I open a JIRA and send a PR? - - Juca. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJVAcG1AAoJECKM1e+fkPrXMyMH/Ah2zaprgeJMd/S8Pl3kR3A9 Ft7ssejCalbUVWBSHZtQhzUIQKpdeVMs2HWbxOFwSydt+4SezM6SUQ/KpalDksXv modIFf3/sZbTi1fyY/qTJCB4FVXxoO2s0ajfxF6WH0cidzF3IBqnpe4Zi2P+N/xW PLOTuZK+uY170fcL1thkHjAyjNFxO1kYwUSvwHZTrg/9H4F08Cb2d26xt6yHwC09 ZPsqa1j2jHYO7m55sGhvkPPhb3DclwZKn0r+sDB2pnTX+VNLl+DioUM1eWAsaFFq MsxB3J03MD2yDds8sWrxvnk/KVHU5UwlUex9dZPLuH6CBi/OpPw8FRO8cZW931c= =I7Xg -----END PGP SIGNATURE----- From bburke at redhat.com Thu Mar 12 13:24:37 2015 From: bburke at redhat.com (Bill Burke) Date: Thu, 12 Mar 2015 13:24:37 -0400 Subject: [keycloak-dev] Password policy for "password != username" In-Reply-To: <5501C1B5.8040909@redhat.com> References: <5501C1B5.8040909@redhat.com> Message-ID: <5501CBD5.4070703@redhat.com> that works. On 3/12/2015 12:41 PM, Juraci Paix?o Kr?hling wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > All, > > I've asked on the IRC channel, but it seems it's better to have a > first discussion here before opening a JIRA and/or sending a PR. > > I have a requirement in my application, where the user's passwords > should meet some complexity. The initial rules will be based on > Wildfly's own rules. Two of them I can fulfill via Keycloak, but the > third is: "The password must be different from the username". I > couldn't find a way to do it with the current policy configuration. > > So, should this be possible? If so, what would be the syntax? My first > suggestion would be "notUsername()". > > Is this acceptable? Should I open a JIRA and send a PR? > > - - Juca. > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1 > > iQEcBAEBAgAGBQJVAcG1AAoJECKM1e+fkPrXMyMH/Ah2zaprgeJMd/S8Pl3kR3A9 > Ft7ssejCalbUVWBSHZtQhzUIQKpdeVMs2HWbxOFwSydt+4SezM6SUQ/KpalDksXv > modIFf3/sZbTi1fyY/qTJCB4FVXxoO2s0ajfxF6WH0cidzF3IBqnpe4Zi2P+N/xW > PLOTuZK+uY170fcL1thkHjAyjNFxO1kYwUSvwHZTrg/9H4F08Cb2d26xt6yHwC09 > ZPsqa1j2jHYO7m55sGhvkPPhb3DclwZKn0r+sDB2pnTX+VNLl+DioUM1eWAsaFFq > MsxB3J03MD2yDds8sWrxvnk/KVHU5UwlUex9dZPLuH6CBi/OpPw8FRO8cZW931c= > =I7Xg > -----END PGP SIGNATURE----- > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From guydavis.ca at gmail.com Thu Mar 12 14:52:00 2015 From: guydavis.ca at gmail.com (Guy Davis) Date: Thu, 12 Mar 2015 12:52:00 -0600 Subject: [keycloak-dev] Issue with latest Github master and SAML IDP providers? In-Reply-To: <404035330.4495455.1426153778301.JavaMail.zimbra@redhat.com> References: <404035330.4495455.1426153778301.JavaMail.zimbra@redhat.com> Message-ID: Hi Stian, Thanks for the response. Yes, I'm still seeing this issue with the very latest Github master (including today's commit #1038). This was working for me a couple of weeks ago, before more recent commits. We demoed the identity broker to our management using a PicketLink test idp.war (in same container) and also using MS WAAD on Azure. It's a key feature for us. Let me provide more details about my environment: 1. Building/running with Java 1.7 2. Building master with 'mvn clean install -DskipTests=true -Pdistribution' 3. Running within a JBoss EAP 6.1.0alpha container using the modules from distribution\as7-adapter-zip\target\unpacked in my ApplicationServer\modules\system\layers\base with the following differences: 1. Had to add 'org/bouncycastle/main/bcprov-jdk16-1.46.jar' otherwise Keycloak complained on startup in server.log. 2. Had to remove 'org/jboss/as' and 'org/jboss/aesh' as they were overwriting older JBoss EAP 6.1.0alpha versions and preventing startup. 4. Deploying the auth-server.war by zipping the contents and renaming 'auth.war', placing in my standalone/deployments folder. 5. Updating the standalone.xml file with the required Keycloak config. Defining the realm and secure deployments in that XML directly. 6. Starting with a missing H2 datasource to ensure old data/schema is not the problem. On startup, I confirm admin's password and then re-build my DSIS realm. Any help you can provide would be most appreciated. I'm using the Keycloak master as features being added now such as Kerberos/Spnego and Identity Brokering are critical use cases for our adoption. Thanks, Guy On Thu, Mar 12, 2015 at 3:49 AM, Stian Thorgersen wrote: > Are you still having issues or did you figure it out? > > ----- Original Message ----- > > From: "Guy Davis" > > To: keycloak-dev at lists.jboss.org > > Sent: Wednesday, 4 March, 2015 1:10:52 AM > > Subject: [keycloak-dev] Issue with latest Github master and SAML IDP > providers? > > > > Good day, > > > > I've been using a sample Picketlink IDP locally for testing the SAML > v2.0 ID > > brokering, however after updating to latest master and re-deploying > > components, I'm getting the following error. Any tips? > > > > > > > > Thanks in advance, > > Guy > > > > _______________________________________________ > > keycloak-dev mailing list > > keycloak-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/keycloak-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150312/4a333e60/attachment.html From stian at redhat.com Fri Mar 13 01:50:15 2015 From: stian at redhat.com (Stian Thorgersen) Date: Fri, 13 Mar 2015 01:50:15 -0400 (EDT) Subject: [keycloak-dev] Issue with latest Github master and SAML IDP providers? In-Reply-To: References: <404035330.4495455.1426153778301.JavaMail.zimbra@redhat.com> Message-ID: <510530563.5356159.1426225815272.JavaMail.zimbra@redhat.com> I assume this happens after you've clicked on 'PicketLink IDP' on the login screen? Can you try the same with the appliance download? We don't support JBoss EAP 6.1.0alpha, so maybe that's the problem. ----- Original Message ----- > From: "Guy Davis" > To: "Stian Thorgersen" > Cc: keycloak-dev at lists.jboss.org > Sent: Thursday, March 12, 2015 7:52:00 PM > Subject: Re: [keycloak-dev] Issue with latest Github master and SAML IDP providers? > > Hi Stian, > > Thanks for the response. Yes, I'm still seeing this issue with the very > latest Github master (including today's commit #1038). This was working > for me a couple of weeks ago, before more recent commits. We demoed the > identity broker to our management using a PicketLink test idp.war (in same > container) and also using MS WAAD on Azure. It's a key feature for us. > > Let me provide more details about my environment: > > 1. Building/running with Java 1.7 > 2. Building master with 'mvn clean install -DskipTests=true > -Pdistribution' > 3. Running within a JBoss EAP 6.1.0alpha container using the modules > from distribution\as7-adapter-zip\target\unpacked in > my ApplicationServer\modules\system\layers\base with the following > differences: > 1. Had to add 'org/bouncycastle/main/bcprov-jdk16-1.46.jar' otherwise > Keycloak complained on startup in server.log. > 2. Had to remove 'org/jboss/as' and 'org/jboss/aesh' as they were > overwriting older JBoss EAP 6.1.0alpha versions and preventing startup. > 4. Deploying the auth-server.war by zipping the contents and renaming > 'auth.war', placing in my standalone/deployments folder. > 5. Updating the standalone.xml file with the required Keycloak config. > Defining the realm and secure deployments in that XML directly. > 6. Starting with a missing H2 datasource to ensure old data/schema is > not the problem. On startup, I confirm admin's password and then re-build > my DSIS realm. > > Any help you can provide would be most appreciated. I'm using the Keycloak > master as features being added now such as Kerberos/Spnego and Identity > Brokering are critical use cases for our adoption. > > Thanks, > Guy > > > On Thu, Mar 12, 2015 at 3:49 AM, Stian Thorgersen wrote: > > > Are you still having issues or did you figure it out? > > > > ----- Original Message ----- > > > From: "Guy Davis" > > > To: keycloak-dev at lists.jboss.org > > > Sent: Wednesday, 4 March, 2015 1:10:52 AM > > > Subject: [keycloak-dev] Issue with latest Github master and SAML IDP > > providers? > > > > > > Good day, > > > > > > I've been using a sample Picketlink IDP locally for testing the SAML > > v2.0 ID > > > brokering, however after updating to latest master and re-deploying > > > components, I'm getting the following error. Any tips? > > > > > > > > > > > > Thanks in advance, > > > Guy > > > > > > _______________________________________________ > > > keycloak-dev mailing list > > > keycloak-dev at lists.jboss.org > > > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > From stian at redhat.com Fri Mar 13 02:05:18 2015 From: stian at redhat.com (Stian Thorgersen) Date: Fri, 13 Mar 2015 02:05:18 -0400 (EDT) Subject: [keycloak-dev] Introducing KeycloakContext In-Reply-To: <212628356.5357183.1426226444519.JavaMail.zimbra@redhat.com> Message-ID: <101768104.5357724.1426226718404.JavaMail.zimbra@redhat.com> Currently we pass a lot of things around. For example: AuthenticationManager.logout(session, realm, userSession, uriInfo, connection) Flows.forms(session, realm, client, uriInfo) I propose we introduce a KeycloakContext that can hold everything. It would be injectable by RestEasy: @Context KeycloakContext context; And would look something like: public interface KeycloakContext { KeycloakSession session(); RealmModel realm(); HttpRequest request(); UriInfo uriInfo(); ClientConnection clientConnection(); EventBuilder event(); } Also, I think we should convert AuthenticationManager and TokenManager into providers so they can be obtained from the session rather than passing it around everywhere. The above changes would be introduced after 1.2.0.Beta1 and can be done incrementally!! From stian at redhat.com Fri Mar 13 02:07:53 2015 From: stian at redhat.com (Stian Thorgersen) Date: Fri, 13 Mar 2015 02:07:53 -0400 (EDT) Subject: [keycloak-dev] Introducing KeycloakContext In-Reply-To: <101768104.5357724.1426226718404.JavaMail.zimbra@redhat.com> References: <101768104.5357724.1426226718404.JavaMail.zimbra@redhat.com> Message-ID: <1932460263.5357862.1426226873163.JavaMail.zimbra@redhat.com> An alternative would be to just add the methods to KeycloakSession ----- Original Message ----- > From: "Stian Thorgersen" > To: "keycloak dev" > Sent: Friday, March 13, 2015 7:05:18 AM > Subject: [keycloak-dev] Introducing KeycloakContext > > Currently we pass a lot of things around. For example: > > AuthenticationManager.logout(session, realm, userSession, uriInfo, > connection) > Flows.forms(session, realm, client, uriInfo) > > I propose we introduce a KeycloakContext that can hold everything. It would > be injectable by RestEasy: > > @Context > KeycloakContext context; > > And would look something like: > > public interface KeycloakContext { > KeycloakSession session(); > RealmModel realm(); > HttpRequest request(); > UriInfo uriInfo(); > ClientConnection clientConnection(); > EventBuilder event(); > } > > Also, I think we should convert AuthenticationManager and TokenManager into > providers so they can be obtained from the session rather than passing it > around everywhere. > > The above changes would be introduced after 1.2.0.Beta1 and can be done > incrementally!! > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > From stian at redhat.com Fri Mar 13 02:24:20 2015 From: stian at redhat.com (Stian Thorgersen) Date: Fri, 13 Mar 2015 02:24:20 -0400 (EDT) Subject: [keycloak-dev] Shared mapper configs In-Reply-To: <526578349.5359055.1426227732057.JavaMail.zimbra@redhat.com> Message-ID: <233064518.5359325.1426227860571.JavaMail.zimbra@redhat.com> Bill, As I mentioned when you demoed protocol mappers I think we should introduce a protocol mapper type that is configured on a realm level, then one or more applications can use the same configuration. It would be good to do that before releasing 1.2.0.Beta1. I think that having it like is will be an overhead to most folks as they'll want the same token sent to all applications and will have to re-create the same mapping multiple times (and make changes multiple times as well). From velias at redhat.com Fri Mar 13 06:28:59 2015 From: velias at redhat.com (Vlastimil Elias) Date: Fri, 13 Mar 2015 11:28:59 +0100 Subject: [keycloak-dev] 1.2.beta1 planning, need you to defer things In-Reply-To: <5501A74E.1030200@redhat.com> References: <5500921C.8090605@redhat.com> <1632062033.4404645.1426138834278.JavaMail.zimbra@redhat.com> <55018D31.5090200@redhat.com> <1308740292.4822787.1426171311061.JavaMail.zimbra@redhat.com> <5501A74E.1030200@redhat.com> Message-ID: <5502BBEB.2030908@redhat.com> Hi On 12.3.2015 15:48, Bill Burke wrote: > > On 3/12/2015 10:41 AM, Stian Thorgersen wrote: >> >> ----- Original Message ----- >>> From: "Bill Burke" >>> To: "Stian Thorgersen" >>> Cc: keycloak-dev at lists.jboss.org >>> Sent: Thursday, 12 March, 2015 1:57:21 PM >>> Subject: Re: [keycloak-dev] 1.2.beta1 planning, need you to defer things >>> >>> >>> >>> On 3/12/2015 1:40 AM, Stian Thorgersen wrote: >>> ... >>>>> I'm going to try and close existing bugs and implement features needed >>>>> for jboss.org guys over the next 2 weeks as well as test out master to >>>>> make sure things still work. >>>> With regards to jboss.org guys we shouldn't just add features because they >>>> request it. Take for example KEYCLOAK-1045, which was easily solved with >>>> we already have. Another one is KEYCLOAK-1051, which I think is a horrible >>>> idea. >>>> >>> I don't want to just add features either, but some of their things are >>> valid...i.e. finding out if a user is logged and who they are without >>> doing all the token stuff. >> That's exactly one of the things that are not necessary, I've added a POC that uses keycloak.js, which they where happy with. See KEYCLOAK-1045 and http://stianst.github.io/jbossorg/index.html. >> > I'll take a look, but IIRC there was a different issue described (not > 1045), where a static home page shouldn't have to perform a full login > and obtain a token just to know whether or not a user is logged in and > who they are. > I appreciate our features to be pushed, some working/semistable version in two or three weeks should be cool for us to be able develop other/client parts of our solution. Then we need some production ready version available in the middle of May at worse. We can always discuss issues I created in JIRA, if we find some other solution for our needs then it is OK. Also features marked by jbossorg_req_opt label (like KEYCLOAK-1051) are not mandatory for us now, we can probably live without them. But we have to resolve issues marked by jbossorg_req label somehow as they block us. Like for KEYCLOAK-1045 we found some solution by improving keycloak.js for now. But there is room for performance improvements still (I think you call it "implicit flow" or so in the comments). As real users of this feature will be some other developers of the final web then they will maybe push to get these performance improvements implemented later. I also don't think KEYCLOAK-1051 is so horible idea, I just added comment to it with my more detailed explanation why ;-) Thanks guys for the great cooperation which allow us to use KC for our project, and will help to improve KC in general for other users I believe. Vl. -- Vlastimil Elias Principal Software Engineer jboss.org Development Team From velias at redhat.com Fri Mar 13 06:50:36 2015 From: velias at redhat.com (Vlastimil Elias) Date: Fri, 13 Mar 2015 11:50:36 +0100 Subject: [keycloak-dev] Improvements of registration over Social Login providers In-Reply-To: <1566209466.4485464.1426152980166.JavaMail.zimbra@redhat.com> References: <55000EA2.1060106@redhat.com> <1890728201.3815264.1426069493109.JavaMail.zimbra@redhat.com> <1406310153.3818601.1426069818031.JavaMail.zimbra@redhat.com> <55003803.5000905@redhat.com> <1566209466.4485464.1426152980166.JavaMail.zimbra@redhat.com> Message-ID: <5502C0FC.1010902@redhat.com> Hi, On 12.3.2015 10:36, Stian Thorgersen wrote: > > ----- Original Message ----- >> From: "Vlastimil Elias" >> To: keycloak-dev at lists.jboss.org >> Sent: Wednesday, 11 March, 2015 1:41:39 PM >> Subject: Re: [keycloak-dev] Improvements of registration over Social Login providers >> >> Hi >> >> I see your points and understand them if you take KC as primary system >> for identity. >> >> But things change a bit if you use UserFederationProvider SPI and >> primary user database is some other backend, and KC is used primarily to >> add some missing features (eg social logins, modern SSO protocols) at >> top of this backend. I'm in this position and I have to propagate new >> users to the backend (even one created due social login) and must >> reflect some constraints from the backend (like username must be email >> in my case). >> >> Feature proposal from point 1 is not critical for me, I think it should >> be useful for some KC installations to be able to disable social >> registrations, but I do not need it, so we can let it be. > If you don't need it I suggest we don't add it, as we haven't had anyone else request it. I agree > >> Feature proposal 2 is more important for me. >> I need email to be used as username in KC due my backend restrictions, >> so I implemented some basic solution as part of KEYCLOAK-1074 pull >> request. If you accept it and keep it in the code then I can use KC for >> my project (or we have to find some other solution, eg some extension of >> UserFederationProvider SPI to allow it to select username in case of >> social registration). >> >> But this solution is only partial and I want to help you make KC >> generally better for all use cases, so I did this proposal. > I appreciate it, but if possible IMO it would be better to make it work by default rather than introducing configuration options. Sure, I agree with this also. Use reasonable default if possible, not to add config options for everything. But if we have some more special requirements for our project which can't be solved by reasonable default, we have only few ways how to add them (as we can't fork KC for our project): - add common config option into admin app - reasonable if they can fit for more general use - add some hidden config option (eg. in keycloak.json) - reasonable if this option is raare use - find some other customization solution like extension of some SPI or so > >> I also think that current way how KC reuses username from social >> providers is wrong as it may prevent some users from login, so what to >> do with this? Create a bug in JIRA? > Agree - using username from social providers isn't a good approach. > >> But I don't think solution with some randomly generated username, which >> will be changed later, is a good one. >> This may bring problems to other systems which use KC for SSO and store >> data related to users. They typically rely on usernames to store these >> data, but change of username in KC may break data integrity (hide data >> for the user who changed username). How do you plan to prevent those >> problems if you implement username change in KC? >> >> I understand that correct solution should be using 'User ID' in these >> systems instead of username, but I fear it is not possible in many cases. >> From my experience integration of existing applications like Atlassian >> JIRA into SSO system may be problematic in this area, you are forced to >> use usernames there, username changes are typically a problem. >> So I think that username changes should be possible in KC for systems >> who need it, but no any important feature like social registrations >> should rely on them so heavily. > Yeah, you're right we need a solution to this that doesn't require allowing usernames to be changed. > > How about: > > 1. We allow username to be null and users created through social login has a null username - this would change the login with email only feature you're implementing slightly > 2. We add validation support to user profiles and if any required attributes are missing the user is required to add the missing attributes on login (before redirecting to application) > 3. We add a require username/password option on social login - if this is enabled the user will have to add a username/password on first login. If not enable the same feature will be available through account management. > > In your use-case it would work by: > > * On social login if user is missing email (for example twitter) the user is shown a insert your email form as email would be marked as required. This would also work if you need other required attributes that are not available from social, for example a DOB > * In the case of applications that require a username you can use the new claim mapping feature to map email to the username claim, or just make sure the application uses the email claim null username is a bit courageous proposal, I'm not sure keycloak can live with it without any big rewrites of the code. Some sensible default username should be used there I think (take it from social provider if it is free, try to prepare some unique if it is occupied in KC already). Or we can ask user to input his username, but it is less user friendly as it requires some user interaction (so finally we can do this as configurable option how system will behave ;-). Our use of email as username is a bit more complicated as we use UserFedaretionProvider SPI with synchronizeRegistrations() enabled - we have to create user in backend system when it is created in KC, and we have to use email as username there. So claim mapping for client applications is not useful for us. Problem is that KC now provides only "after first login" user actions/screens which may be a bit late as account is created in KC already. I'll look at this problem a bit deeper in next few days and try to suggest some sensible solution. See also https://issues.jboss.org/browse/KEYCLOAK-1053 Cheers Vl. >> Thanks >> >> Vlastimil >> >> On 11.3.2015 11:30, Stian Thorgersen wrote: >>> We can also add some more required actions: >>> >>> * Set email if missing >>> * Set username/password >>> >>> It would then be possible to set one or more required actions for a first >>> social login. >>> >>> ----- Original Message ----- >>>> From: "Stian Thorgersen" >>>> To: "Vlastimil Elias" >>>> Cc: keycloak-dev at lists.jboss.org >>>> Sent: Wednesday, 11 March, 2015 11:24:53 AM >>>> Subject: Re: [keycloak-dev] Improvements of registration over Social Login >>>> providers >>>> >>>> >>>> >>>> ----- Original Message ----- >>>>> From: "Vlastimil Elias" >>>>> To: keycloak-dev at lists.jboss.org >>>>> Sent: Wednesday, 11 March, 2015 10:45:06 AM >>>>> Subject: [keycloak-dev] Improvements of registration over Social Login >>>>> providers >>>>> >>>>> Hi great Keycloak dev team, >>>>> >>>>> during implementation of https://issues.jboss.org/browse/KEYCLOAK-1074 I >>>>> found few things which should be improved in area of registration over >>>>> Social Login providers. >>>>> I'd like to discuss them here before creating JIRAs. I believe I should >>>>> implement these changes if you will be interested. >>>>> >>>>> 1. It is not possible to disable registration over Social provider >>>>> ====================================== >>>>> Once provider is created then it is always possible to register over it, >>>>> even >>>>> if "User registration" is disabled in realm "Login Settings". I think it >>>>> should be possible to disable social registrations and allow only to link >>>>> social logins to existing accounts (eg. loaded from other system). >>>>> >>>>> Marek Posolda pointed me to https://issues.jboss.org/browse/KEYCLOAK-1036 >>>>> which is rejected without any comment. I understand that this global >>>>> setting >>>>> is probably not a good solution, so my proposal is to add independent >>>>> "User >>>>> registration" switch into configuration of each Identity provider, so >>>>> admin >>>>> will get fine grained control. >>>> -1 >>>> >>>> IMO when you add a identity broker (or social provider) you are allowing >>>> all >>>> those users to login. When a user logs in the first time using a identity >>>> broker we're not really registering the user, just creating an internal >>>> representation. >>>> >>>>> 2. Username from Social provider is used as Keycloak username during >>>>> registration >>>>> =================================================== >>>>> This can lead to the situation that user registering eg. over Twitter >>>>> will >>>>> not be able to register as other user eg. from Facebook will use same >>>>> username there and occupy it in Keycloak as first. >>>>> My proposal is to extend configuration of each Identity provider by new >>>>> option "Username type" which will be select from these options: >>>>> >>>>> >>>>> * provided username exact - works as now, username is got from >>>>> provider, >>>>> user can't register if occupied in KC already >>>>> * provided username unique - KC will take username from provider, if >>>>> occupied then it adds some random number to it to create unique >>>>> username >>>>> and allow user to register >>>>> * provided email - this is related to KEYCLOAK-1074, I need this >>>>> option >>>>> for my project. I know that email is not provided by some providers >>>>> (eg >>>>> Twitter) so I can't use them until KEYCLOAK-1053 is resolved somehow >>>>> >>>>> So let me know what you think about my proposals, can I implement them? >>>> -1 >>>> >>>> If it's using the username from the identity provider that's not correct, >>>> it >>>> should just be set to something unique (could be set to same as user id), >>>> that's how it used to be before the identity brokering was introduced. >>>> >>>> We have an open issue to allow users to change their username. This would >>>> then be used by a user that wants to enable regular logins in the above >>>> scenario. We could improve the account management around this, for example >>>> it should not display username if it's the same as user id, but have an >>>> option for a user to "enable regular login" by providing a username and >>>> password. >>>> >>>>> Cheers >>>>> >>>>> Vlastimil >>>>> >>>>> -- >>>>> Vlastimil Elias >>>>> Principal Software Engineer >>>>> jboss.org Development Team >>>>> >>>>> _______________________________________________ >>>>> keycloak-dev mailing list >>>>> keycloak-dev at lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>>> _______________________________________________ >>>> keycloak-dev mailing list >>>> keycloak-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>>> >> -- >> Vlastimil Elias >> Principal Software Engineer >> jboss.org Development Team >> >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> -- Vlastimil Elias Principal Software Engineer jboss.org Development Team From mposolda at redhat.com Fri Mar 13 10:30:26 2015 From: mposolda at redhat.com (Marek Posolda) Date: Fri, 13 Mar 2015 15:30:26 +0100 Subject: [keycloak-dev] Introducing KeycloakContext In-Reply-To: <101768104.5357724.1426226718404.JavaMail.zimbra@redhat.com> References: <101768104.5357724.1426226718404.JavaMail.zimbra@redhat.com> Message-ID: <5502F482.8070008@redhat.com> +1 for KeycloakContext and especially for AuthenticationManager and TokenManager as providers. We can also convert some static methods (like AuthenticationManager.nextActionAfterAuthentication for instance) to non-static so people can inject their impl of AuthenticationManager and override if needed. Maybe at the same time, we can also allow to pass custom Require actions (convert RequiredAction enum to String maybe?) and pass custom freemarker template for them? It could be the start for "interceptors" related stuff :-) As long as people are able to inject custom action like terms&conditions page after first login, we should be good. Marek On 13.3.2015 07:05, Stian Thorgersen wrote: > Currently we pass a lot of things around. For example: > > AuthenticationManager.logout(session, realm, userSession, uriInfo, connection) > Flows.forms(session, realm, client, uriInfo) > > I propose we introduce a KeycloakContext that can hold everything. It would be injectable by RestEasy: > > @Context > KeycloakContext context; > > And would look something like: > > public interface KeycloakContext { > KeycloakSession session(); > RealmModel realm(); > HttpRequest request(); > UriInfo uriInfo(); > ClientConnection clientConnection(); > EventBuilder event(); > } > > Also, I think we should convert AuthenticationManager and TokenManager into providers so they can be obtained from the session rather than passing it around everywhere. > > The above changes would be introduced after 1.2.0.Beta1 and can be done incrementally!! > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev From bburke at redhat.com Fri Mar 13 10:48:43 2015 From: bburke at redhat.com (Bill Burke) Date: Fri, 13 Mar 2015 10:48:43 -0400 Subject: [keycloak-dev] Introducing KeycloakContext In-Reply-To: <101768104.5357724.1426226718404.JavaMail.zimbra@redhat.com> References: <101768104.5357724.1426226718404.JavaMail.zimbra@redhat.com> Message-ID: <5502F8CB.3010802@redhat.com> Lol! I was thinking the same thing yesterday. There's other things that need passing around too in many areas: UserSessionModel, ClientSessionModel On 3/13/2015 2:05 AM, Stian Thorgersen wrote: > Currently we pass a lot of things around. For example: > > AuthenticationManager.logout(session, realm, userSession, uriInfo, connection) > Flows.forms(session, realm, client, uriInfo) > > I propose we introduce a KeycloakContext that can hold everything. It would be injectable by RestEasy: > > @Context > KeycloakContext context; > > And would look something like: > > public interface KeycloakContext { > KeycloakSession session(); > RealmModel realm(); > HttpRequest request(); > UriInfo uriInfo(); > ClientConnection clientConnection(); > EventBuilder event(); > } > > Also, I think we should convert AuthenticationManager and TokenManager into providers so they can be obtained from the session rather than passing it around everywhere. > > The above changes would be introduced after 1.2.0.Beta1 and can be done incrementally!! > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From bburke at redhat.com Fri Mar 13 11:40:19 2015 From: bburke at redhat.com (Bill Burke) Date: Fri, 13 Mar 2015 11:40:19 -0400 Subject: [keycloak-dev] Shared mapper configs In-Reply-To: <233064518.5359325.1426227860571.JavaMail.zimbra@redhat.com> References: <233064518.5359325.1426227860571.JavaMail.zimbra@redhat.com> Message-ID: <550304E3.6010907@redhat.com> I think it will be just as common that each application has different token requirements, so it needs to be easy to add additional mappers as well. For example, each may want the same user attribute claims, but each will want a different role scope and maybe want to format the roles to match how their application wants them. This is especially true for SAML where how the roles are formatted may be different per app. On 3/13/2015 2:24 AM, Stian Thorgersen wrote: > Bill, > > As I mentioned when you demoed protocol mappers I think we should introduce a protocol mapper type that is configured on a realm level, then one or more applications can use the same configuration. It would be good to do that before releasing 1.2.0.Beta1. > > I think that having it like is will be an overhead to most folks as they'll want the same token sent to all applications and will have to re-create the same mapping multiple times (and make changes multiple times as well). > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From mposolda at redhat.com Fri Mar 13 12:42:09 2015 From: mposolda at redhat.com (Marek Posolda) Date: Fri, 13 Mar 2015 17:42:09 +0100 Subject: [keycloak-dev] Shared mapper configs In-Reply-To: <550304E3.6010907@redhat.com> References: <233064518.5359325.1426227860571.JavaMail.zimbra@redhat.com> <550304E3.6010907@redhat.com> Message-ID: <55031361.9020305@redhat.com> How about the modularization stuff? I believe ProtocolMapper is kind of SPI, which will people often implement by themselves. Currently they need to declare dependency on keycloak-services module, which has 50 other dependencies. It looks to me that it could be divided into 3 separate modules like: - ProtocolMapper SPI itself - OIDC mapper implementations - SAML mapper implementations and each of them will need to have just some minimal dependencies on keycloak-core, keycloak-model-api and few other things. Marek On 13.3.2015 16:40, Bill Burke wrote: > I think it will be just as common that each application has different > token requirements, so it needs to be easy to add additional mappers as > well. For example, each may want the same user attribute claims, but > each will want a different role scope and maybe want to format the roles > to match how their application wants them. This is especially true for > SAML where how the roles are formatted may be different per app. > > > On 3/13/2015 2:24 AM, Stian Thorgersen wrote: >> Bill, >> >> As I mentioned when you demoed protocol mappers I think we should introduce a protocol mapper type that is configured on a realm level, then one or more applications can use the same configuration. It would be good to do that before releasing 1.2.0.Beta1. >> >> I think that having it like is will be an overhead to most folks as they'll want the same token sent to all applications and will have to re-create the same mapping multiple times (and make changes multiple times as well). >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> From guydavis.ca at gmail.com Sat Mar 14 21:17:19 2015 From: guydavis.ca at gmail.com (Guy Davis) Date: Sat, 14 Mar 2015 19:17:19 -0600 Subject: [keycloak-dev] Issue with latest Github master and SAML IDP providers? In-Reply-To: <510530563.5356159.1426225815272.JavaMail.zimbra@redhat.com> References: <404035330.4495455.1426153778301.JavaMail.zimbra@redhat.com> <510530563.5356159.1426225815272.JavaMail.zimbra@redhat.com> Message-ID: Hi Stian, I tried the following using the very latest Github master. 1. Keycloak appliance (built in distribution folder so Wildfly 8.2). Had a problem: 1. Doesn't list SAML or Open ID Connect in the Identity Providers picklist like previous versions. Please see screenshot attached. Did the IdP choice get moved? 2. Deploying Keycloak into a JBoss EAP 6.3 (from Teiid 8.10). Had following errors: 1. Failed deployment due to lack of org.bouncycastle module. Not part of JBoss 6 Adapter? bcprov and bcpix are in auth-server.war/WEB-INF/lib, but something is trying to load it as a module. 2. After adding a org.bouncycastle module manually using the bc 1.50 jars, I got a resteasy-crypto module missing error. If I add that I get conflicts between resteasy-2.3.8 in JBoss EAP and resteasy 3 that provides resteasy-crypto. So, I'm struggling to see the best way forward. I need to remain compatible with Teiid which is tied to JBoss EAP, not Wildfly. As well, our app is still geared toward JBoss EAP 6.1.0alpha (aka JBoss AS 7). Keycloak indicates adapters for WF, EAP, and AS 7 are all supported. I was able to demo Identity Brokering just two weeks ago successfully on AS7 (6.1.0alpha), so this is a recent change on master. Please advise on the best path forward. A key benefit of Keycloak over other IDP/SSO options was that it could exist in the same JBoss container as our other apps and frameworks. Thanks, Guy On Thu, Mar 12, 2015 at 11:50 PM, Stian Thorgersen wrote: > I assume this happens after you've clicked on 'PicketLink IDP' on the > login screen? > > Can you try the same with the appliance download? We don't support JBoss > EAP 6.1.0alpha, so maybe that's the problem. > > ----- Original Message ----- > > From: "Guy Davis" > > To: "Stian Thorgersen" > > Cc: keycloak-dev at lists.jboss.org > > Sent: Thursday, March 12, 2015 7:52:00 PM > > Subject: Re: [keycloak-dev] Issue with latest Github master and SAML IDP > providers? > > > > Hi Stian, > > > > Thanks for the response. Yes, I'm still seeing this issue with the very > > latest Github master (including today's commit #1038). This was working > > for me a couple of weeks ago, before more recent commits. We demoed the > > identity broker to our management using a PicketLink test idp.war (in > same > > container) and also using MS WAAD on Azure. It's a key feature for us. > > > > Let me provide more details about my environment: > > > > 1. Building/running with Java 1.7 > > 2. Building master with 'mvn clean install -DskipTests=true > > -Pdistribution' > > 3. Running within a JBoss EAP 6.1.0alpha container using the modules > > from distribution\as7-adapter-zip\target\unpacked in > > my ApplicationServer\modules\system\layers\base with the following > > differences: > > 1. Had to add 'org/bouncycastle/main/bcprov-jdk16-1.46.jar' > otherwise > > Keycloak complained on startup in server.log. > > 2. Had to remove 'org/jboss/as' and 'org/jboss/aesh' as they were > > overwriting older JBoss EAP 6.1.0alpha versions and preventing > startup. > > 4. Deploying the auth-server.war by zipping the contents and renaming > > 'auth.war', placing in my standalone/deployments folder. > > 5. Updating the standalone.xml file with the required Keycloak config. > > Defining the realm and secure deployments in that XML directly. > > 6. Starting with a missing H2 datasource to ensure old data/schema is > > not the problem. On startup, I confirm admin's password and then > re-build > > my DSIS realm. > > > > Any help you can provide would be most appreciated. I'm using the > Keycloak > > master as features being added now such as Kerberos/Spnego and Identity > > Brokering are critical use cases for our adoption. > > > > Thanks, > > Guy > > > > > > On Thu, Mar 12, 2015 at 3:49 AM, Stian Thorgersen > wrote: > > > > > Are you still having issues or did you figure it out? > > > > > > ----- Original Message ----- > > > > From: "Guy Davis" > > > > To: keycloak-dev at lists.jboss.org > > > > Sent: Wednesday, 4 March, 2015 1:10:52 AM > > > > Subject: [keycloak-dev] Issue with latest Github master and SAML IDP > > > providers? > > > > > > > > Good day, > > > > > > > > I've been using a sample Picketlink IDP locally for testing the SAML > > > v2.0 ID > > > > brokering, however after updating to latest master and re-deploying > > > > components, I'm getting the following error. Any tips? > > > > > > > > > > > > > > > > Thanks in advance, > > > > Guy > > > > > > > > _______________________________________________ > > > > keycloak-dev mailing list > > > > keycloak-dev at lists.jboss.org > > > > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150314/b41b7bd5/attachment.html -------------- next part -------------- A non-text attachment was scrubbed... Name: 2015-03-14_184434.png Type: image/png Size: 6125 bytes Desc: not available Url : http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150314/b41b7bd5/attachment.png From prakhashsiva21 at gmail.com Sun Mar 15 01:25:34 2015 From: prakhashsiva21 at gmail.com (Prakhash siva) Date: Sun, 15 Mar 2015 10:55:34 +0530 Subject: [keycloak-dev] [GSOC]Keycloak - Audit Reporting and Intrusion Detection Message-ID: Hi All, I'm Prakhash Sivakumar, a 3rd year Computer Science and Engineering Student from University of Moratuwa. I'm interested in participating in GSOC 2015. I'm specially interested in the project Audit Reporting and Intrusion Detection because I have already worked on an Intrusion detection system based Project. Short overview of my previous project I have mainly used Fluentd and MongoDB for my project. I have got the requests from the Apache log in real time using fluentd and stored those request parameter objects(7 objects) in to MongoDb as a collection. I have used Jess a java rule engine and defined some rules to identify the Intrusions. So whenever a request comes my application compares the request with the rules and authorizes the request only if it is valid. It will go through the stored history before it authorizes the request(Currently that application only able to handle get requests). I have used Java for the application development I'm very much interested in Security side and I would like to explore lot of security related technologies. So I believe this is a great opportunity to me to learn and apply lot of security related technologies. As a Student who loves to learn security related technologies I would like to apply for this project & I also believe I'm not late to apply for this project. please give me some guidelines where I really need to start. It will be really helpful to me Thanks -- *Sivakumar Prakhash* *Undergraduate* *Computer Science & Engineering* *University of Moratuwa.* -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150315/e209e985/attachment.html From prakhashsiva21 at gmail.com Sun Mar 15 13:06:20 2015 From: prakhashsiva21 at gmail.com (Prakhash siva) Date: Sun, 15 Mar 2015 22:36:20 +0530 Subject: [keycloak-dev] Keycloak-Initial configuration Message-ID: Hi all, I'm Prakhash From Sri Lanka. I'm willing to contribute keycloak. I have cloned the keycloak repository but I could not figure out the initial configurations I need to do. I was able to find many tutorials saying how to configure keycloak with specific application but I believe it is not for keycloak development as a contributor. So can you please help me to do the initial configurations. I'm using ubuntu Thanks -- *Sivakumar Prakhash* *Undergraduate* *Computer Science & Engineering* *University of Moratuwa.* -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150315/a5532539/attachment-0001.html From giriraj.sharma27 at gmail.com Sun Mar 15 23:26:34 2015 From: giriraj.sharma27 at gmail.com (Giriraj Sharma) Date: Mon, 16 Mar 2015 08:56:34 +0530 Subject: [keycloak-dev] Keycloak-Initial configuration In-Reply-To: References: Message-ID: Hi, Keycloak source has KeycloakServer.java [1] in testsuite-integration module. It will let you run keycloak locally with JPA or Mongo model. This[2] might help you in running keycloak locally at localhost:8081/auth [1] https://github.com/keycloak/keycloak/blob/master/testsuite/integration/src/main/java/org/keycloak/testutils/KeycloakServer.java [2] https://github.com/keycloak/keycloak/tree/master/testsuite/integration Thanks, On Sun, Mar 15, 2015 at 10:36 PM, Prakhash siva wrote: > Hi all, I'm Prakhash From Sri Lanka. I'm willing to contribute keycloak. I > have cloned the keycloak repository but I could not figure out the initial > configurations I need to do. I was able to find many tutorials saying how > to configure keycloak with specific application but I believe it is not for > keycloak development as a contributor. So can you please help me to do the > initial configurations. I'm using ubuntu > > Thanks > > -- > *Sivakumar Prakhash* > *Undergraduate* > *Computer Science & Engineering* > *University of Moratuwa.* > > > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > -- Giriraj Sharma about.me/girirajsharma Giriraj Sharma, Department of Computer Science National Institute of Technology Hamirpur Himachal Pradesh, India 177005 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150316/5208d176/attachment.html From prakhashsiva21 at gmail.com Mon Mar 16 00:29:18 2015 From: prakhashsiva21 at gmail.com (Prakhash siva) Date: Mon, 16 Mar 2015 09:59:18 +0530 Subject: [keycloak-dev] Keycloak-Initial configuration In-Reply-To: References: Message-ID: Thanks Giriraj, I will configure it and let you know. I think it will be really helpfull On Mon, Mar 16, 2015 at 8:56 AM, Giriraj Sharma wrote: > Hi, > Keycloak source has KeycloakServer.java [1] in testsuite-integration > module. It will let you run keycloak locally with JPA or Mongo model. > This[2] might help you in running keycloak locally at localhost:8081/auth > > > [1] > https://github.com/keycloak/keycloak/blob/master/testsuite/integration/src/main/java/org/keycloak/testutils/KeycloakServer.java > [2] https://github.com/keycloak/keycloak/tree/master/testsuite/integration > > Thanks, > > On Sun, Mar 15, 2015 at 10:36 PM, Prakhash siva > wrote: > >> Hi all, I'm Prakhash From Sri Lanka. I'm willing to contribute keycloak. >> I have cloned the keycloak repository but I could not figure out the >> initial configurations I need to do. I was able to find many tutorials >> saying how to configure keycloak with specific application but I believe it >> is not for keycloak development as a contributor. So can you please help me >> to do the initial configurations. I'm using ubuntu >> >> Thanks >> >> -- >> *Sivakumar Prakhash* >> *Undergraduate* >> *Computer Science & Engineering* >> *University of Moratuwa.* >> >> >> >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> > > > > -- > > Giriraj Sharma > about.me/girirajsharma > > Giriraj Sharma, > Department of Computer Science > National Institute of Technology Hamirpur > Himachal Pradesh, India 177005 > -- *Sivakumar Prakhash* *Undergraduate* *Computer Science & Engineering* *University of Moratuwa.* -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150316/10eef9b6/attachment.html From prakhashsiva21 at gmail.com Mon Mar 16 13:49:33 2015 From: prakhashsiva21 at gmail.com (Prakhash siva) Date: Mon, 16 Mar 2015 23:19:33 +0530 Subject: [keycloak-dev] Keycloak-Initial configuration In-Reply-To: References: Message-ID: Hi, When using the keycloak how can we identify how the URL pattern works. i.e if I'm going to work on the bug KEYCLOAK-953 Allow a user to delete his own account I should identify how the user creation and deletion works.is there is any specific URL mappings or way to identify classes related that Can you explain how URL execution performed according to the request Thanks On Mon, Mar 16, 2015 at 9:59 AM, Prakhash siva wrote: > Thanks Giriraj, I will configure it and let you know. I think it will be > really helpfull > > On Mon, Mar 16, 2015 at 8:56 AM, Giriraj Sharma < > giriraj.sharma27 at gmail.com> wrote: > >> Hi, >> Keycloak source has KeycloakServer.java [1] in testsuite-integration >> module. It will let you run keycloak locally with JPA or Mongo model. >> This[2] might help you in running keycloak locally at localhost:8081/auth >> >> >> [1] >> https://github.com/keycloak/keycloak/blob/master/testsuite/integration/src/main/java/org/keycloak/testutils/KeycloakServer.java >> [2] >> https://github.com/keycloak/keycloak/tree/master/testsuite/integration >> >> Thanks, >> >> On Sun, Mar 15, 2015 at 10:36 PM, Prakhash siva > > wrote: >> >>> Hi all, I'm Prakhash From Sri Lanka. I'm willing to contribute keycloak. >>> I have cloned the keycloak repository but I could not figure out the >>> initial configurations I need to do. I was able to find many tutorials >>> saying how to configure keycloak with specific application but I believe it >>> is not for keycloak development as a contributor. So can you please help me >>> to do the initial configurations. I'm using ubuntu >>> >>> Thanks >>> >>> -- >>> *Sivakumar Prakhash* >>> *Undergraduate* >>> *Computer Science & Engineering* >>> *University of Moratuwa.* >>> >>> >>> >>> _______________________________________________ >>> keycloak-dev mailing list >>> keycloak-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>> >> >> >> >> -- >> >> Giriraj Sharma >> about.me/girirajsharma >> >> Giriraj Sharma, >> Department of Computer Science >> National Institute of Technology Hamirpur >> Himachal Pradesh, India 177005 >> > > > > -- > *Sivakumar Prakhash* > *Undergraduate* > *Computer Science & Engineering* > *University of Moratuwa.* > > > -- *Sivakumar Prakhash* *Undergraduate* *Computer Science & Engineering* *University of Moratuwa.* -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150316/6494e0be/attachment-0001.html From prakhashsiva21 at gmail.com Mon Mar 16 14:23:38 2015 From: prakhashsiva21 at gmail.com (Prakhash siva) Date: Mon, 16 Mar 2015 23:53:38 +0530 Subject: [keycloak-dev] Keycloak-Initial configuration In-Reply-To: References: Message-ID: I thought of doing this in order to get a proper understanding about how keycloak works. I'm interested in working on the project Keycloak - Audit Reporting and Intrusion Detection. So is that a correct approach starting with a bug ? or can you please guide me where I can start my work. & I will go through the keycloak-services source as you suggested On Mon, Mar 16, 2015 at 11:29 PM, Giriraj Sharma wrote: > Hi, > You must have a look at keycloak-services source. It's the module bundled > up with all endpoints and REST API. > Also, you must have a prior discussion with the community if that bug even > needs a fix or is a priority at the moment. > > > On Mon, Mar 16, 2015 at 11:19 PM, Prakhash siva > wrote: > >> Hi, When using the keycloak how can we identify how the URL pattern >> works. i.e if I'm going to work on the bug KEYCLOAK-953 Allow a user to >> delete his own account I should identify how the user creation and deletion >> works.is there is any specific URL mappings or way to identify classes >> related that >> >> Can you explain how URL execution performed according to the request >> >> Thanks >> >> On Mon, Mar 16, 2015 at 9:59 AM, Prakhash siva >> wrote: >> >>> Thanks Giriraj, I will configure it and let you know. I think it will be >>> really helpfull >>> >>> On Mon, Mar 16, 2015 at 8:56 AM, Giriraj Sharma < >>> giriraj.sharma27 at gmail.com> wrote: >>> >>>> Hi, >>>> Keycloak source has KeycloakServer.java [1] in testsuite-integration >>>> module. It will let you run keycloak locally with JPA or Mongo model. >>>> This[2] might help you in running keycloak locally at >>>> localhost:8081/auth >>>> >>>> >>>> [1] >>>> https://github.com/keycloak/keycloak/blob/master/testsuite/integration/src/main/java/org/keycloak/testutils/KeycloakServer.java >>>> [2] >>>> https://github.com/keycloak/keycloak/tree/master/testsuite/integration >>>> >>>> Thanks, >>>> >>>> On Sun, Mar 15, 2015 at 10:36 PM, Prakhash siva < >>>> prakhashsiva21 at gmail.com> wrote: >>>> >>>>> Hi all, I'm Prakhash From Sri Lanka. I'm willing to contribute >>>>> keycloak. I have cloned the keycloak repository but I could not figure out >>>>> the initial configurations I need to do. I was able to find many tutorials >>>>> saying how to configure keycloak with specific application but I believe it >>>>> is not for keycloak development as a contributor. So can you please help me >>>>> to do the initial configurations. I'm using ubuntu >>>>> >>>>> Thanks >>>>> >>>>> -- >>>>> *Sivakumar Prakhash* >>>>> *Undergraduate* >>>>> *Computer Science & Engineering* >>>>> *University of Moratuwa.* >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> keycloak-dev mailing list >>>>> keycloak-dev at lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>>>> >>>> >>>> >>>> >>>> -- >>>> >>>> Giriraj Sharma >>>> about.me/girirajsharma >>>> >>>> Giriraj Sharma, >>>> Department of Computer Science >>>> National Institute of Technology Hamirpur >>>> Himachal Pradesh, India 177005 >>>> >>> >>> >>> >>> -- >>> *Sivakumar Prakhash* >>> *Undergraduate* >>> *Computer Science & Engineering* >>> *University of Moratuwa.* >>> >>> >>> >> >> >> -- >> *Sivakumar Prakhash* >> *Undergraduate* >> *Computer Science & Engineering* >> *University of Moratuwa.* >> >> >> > > > -- > > Giriraj Sharma > about.me/girirajsharma > > Giriraj Sharma, > Department of Computer Science > National Institute of Technology Hamirpur > Himachal Pradesh, India 177005 > -- *Sivakumar Prakhash* *Undergraduate* *Computer Science & Engineering* *University of Moratuwa.* -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150316/82f46510/attachment.html From bburke at redhat.com Mon Mar 16 14:25:23 2015 From: bburke at redhat.com (Bill Burke) Date: Mon, 16 Mar 2015 14:25:23 -0400 Subject: [keycloak-dev] Keycloak-Initial configuration In-Reply-To: References: Message-ID: <55072013.6020007@redhat.com> AccountService and account theme is where you should implement this. IMO, also, this action shouldn't delete the user, but rather disable it. Once a user is deleted it becomes harder to develop an audit trail. On 3/16/2015 1:49 PM, Prakhash siva wrote: > Hi, When using the keycloak how can we identify how the URL pattern > works. i.e if I'm going to work on the bug KEYCLOAK-953 Allow a user to > delete his own account I should identify how the user creation and > deletion works.is there is any specific URL mappings > or way to identify classes related that > > Can you explain how URL execution performed according to the request > > Thanks > > On Mon, Mar 16, 2015 at 9:59 AM, Prakhash siva > wrote: > > Thanks Giriraj, I will configure it and let you know. I think it > will be really helpfull > > On Mon, Mar 16, 2015 at 8:56 AM, Giriraj Sharma > > wrote: > > Hi, > Keycloak source has KeycloakServer.java [1] in > testsuite-integration module. It will let you run keycloak > locally with JPA or Mongo model. > This[2] might help you in running keycloak locally at > localhost:8081/auth > > > [1] > https://github.com/keycloak/keycloak/blob/master/testsuite/integration/src/main/java/org/keycloak/testutils/KeycloakServer.java > [2] > https://github.com/keycloak/keycloak/tree/master/testsuite/integration > > Thanks, > > On Sun, Mar 15, 2015 at 10:36 PM, Prakhash siva > > wrote: > > Hi all, I'm Prakhash From Sri Lanka. I'm willing to > contribute keycloak. I have cloned the keycloak repository > but I could not figure out the initial configurations I need > to do. I was able to find many tutorials saying how to > configure keycloak with specific application but I believe > it is not for keycloak development as a contributor. So can > you please help me to do the initial configurations. I'm > using ubuntu > > Thanks > > -- > /*Sivakumar Prakhash*/ > /*Undergraduate*/ > /*Computer Science & Engineering*/ > /*University of Moratuwa.*/ > > > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > > > -- > Giriraj Sharma > about.me/girirajsharma > > > > Giriraj Sharma, > Department of Computer Science > National Institute of Technology Hamirpur > Himachal Pradesh, India 177005 > > > > > -- > /*Sivakumar Prakhash*/ > /*Undergraduate*/ > /*Computer Science & Engineering*/ > /*University of Moratuwa.*/ > > > > > > -- > /*Sivakumar Prakhash*/ > /*Undergraduate*/ > /*Computer Science & Engineering*/ > /*University of Moratuwa.*/ > > > > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From leonardo.zanivan at gmail.com Mon Mar 16 15:00:06 2015 From: leonardo.zanivan at gmail.com (Leonardo Loch Zanivan) Date: Mon, 16 Mar 2015 19:00:06 +0000 Subject: [keycloak-dev] Incorrect table mapping Message-ID: Hi, I've configured KeyCloak datasource to a PostgreSQL database. I found that "REALM_APPLICATION" table has a strange mapping. REALM_ID is the APPLICATION (CLIENT) APPLICATION_ID is the REALM I think it was a mistake by incorrect JPA mapping. Regards, Leonardo Zanivan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150316/99481e64/attachment.html From mposolda at redhat.com Mon Mar 16 15:23:49 2015 From: mposolda at redhat.com (Marek Posolda) Date: Mon, 16 Mar 2015 20:23:49 +0100 Subject: [keycloak-dev] Incorrect table mapping In-Reply-To: References: Message-ID: <55072DC5.3040904@redhat.com> Hi, could you please create a JIRA for this? Thanks, Marek On 16.3.2015 20:00, Leonardo Loch Zanivan wrote: > Hi, > > I've configured KeyCloak datasource to a PostgreSQL database. > I found that "REALM_APPLICATION" table has a strange mapping. > > REALM_ID is the APPLICATION (CLIENT) > APPLICATION_ID is the REALM > > I think it was a mistake by incorrect JPA mapping. > > Regards, > Leonardo Zanivan > > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150316/7be412ce/attachment-0001.html From leonardo.zanivan at gmail.com Mon Mar 16 15:28:11 2015 From: leonardo.zanivan at gmail.com (Leonardo Loch Zanivan) Date: Mon, 16 Mar 2015 19:28:11 +0000 Subject: [keycloak-dev] Incorrect table mapping In-Reply-To: <55072DC5.3040904@redhat.com> References: <55072DC5.3040904@redhat.com> Message-ID: https://issues.jboss.org/browse/KEYCLOAK-1106 On Mon, Mar 16, 2015 at 4:24 PM Marek Posolda wrote: > Hi, > > could you please create a JIRA for this? > > Thanks, > Marek > > > On 16.3.2015 20:00, Leonardo Loch Zanivan wrote: > > Hi, > > I've configured KeyCloak datasource to a PostgreSQL database. > I found that "REALM_APPLICATION" table has a strange mapping. > > REALM_ID is the APPLICATION (CLIENT) > APPLICATION_ID is the REALM > > I think it was a mistake by incorrect JPA mapping. > > Regards, > Leonardo Zanivan > > > _______________________________________________ > keycloak-dev mailing listkeycloak-dev at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-dev > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150316/bd763de4/attachment.html From bburke at redhat.com Mon Mar 16 15:28:59 2015 From: bburke at redhat.com (Bill Burke) Date: Mon, 16 Mar 2015 15:28:59 -0400 Subject: [keycloak-dev] Incorrect table mapping In-Reply-To: <55072DC5.3040904@redhat.com> References: <55072DC5.3040904@redhat.com> Message-ID: <55072EFB.7080501@redhat.com> This is a major screwup...How do we handle this in a migration script? Looks like an export/import would have to be done. On 3/16/2015 3:23 PM, Marek Posolda wrote: > Hi, > > could you please create a JIRA for this? > > Thanks, > Marek > > On 16.3.2015 20:00, Leonardo Loch Zanivan wrote: >> Hi, >> >> I've configured KeyCloak datasource to a PostgreSQL database. >> I found that "REALM_APPLICATION" table has a strange mapping. >> >> REALM_ID is the APPLICATION (CLIENT) >> APPLICATION_ID is the REALM >> >> I think it was a mistake by incorrect JPA mapping. >> >> Regards, >> Leonardo Zanivan >> >> >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From leonardo.zanivan at gmail.com Mon Mar 16 15:36:18 2015 From: leonardo.zanivan at gmail.com (Leonardo Loch Zanivan) Date: Mon, 16 Mar 2015 19:36:18 +0000 Subject: [keycloak-dev] Incorrect table mapping In-Reply-To: <55072EFB.7080501@redhat.com> References: <55072DC5.3040904@redhat.com> <55072EFB.7080501@redhat.com> Message-ID: I think it's quite trivial create a migration script with liquibase. On Mon, Mar 16, 2015 at 4:29 PM Bill Burke wrote: > This is a major screwup...How do we handle this in a migration script? > Looks like an export/import would have to be done. > > On 3/16/2015 3:23 PM, Marek Posolda wrote: > > Hi, > > > > could you please create a JIRA for this? > > > > Thanks, > > Marek > > > > On 16.3.2015 20:00, Leonardo Loch Zanivan wrote: > >> Hi, > >> > >> I've configured KeyCloak datasource to a PostgreSQL database. > >> I found that "REALM_APPLICATION" table has a strange mapping. > >> > >> REALM_ID is the APPLICATION (CLIENT) > >> APPLICATION_ID is the REALM > >> > >> I think it was a mistake by incorrect JPA mapping. > >> > >> Regards, > >> Leonardo Zanivan > >> > >> > >> _______________________________________________ > >> keycloak-dev mailing list > >> keycloak-dev at lists.jboss.org > >> https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > > > > > > _______________________________________________ > > keycloak-dev mailing list > > keycloak-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > > -- > Bill Burke > JBoss, a division of Red Hat > http://bill.burkecentral.com > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150316/643881ff/attachment.html From mposolda at redhat.com Mon Mar 16 15:42:03 2015 From: mposolda at redhat.com (Marek Posolda) Date: Mon, 16 Mar 2015 20:42:03 +0100 Subject: [keycloak-dev] Incorrect table mapping In-Reply-To: References: <55072DC5.3040904@redhat.com> <55072EFB.7080501@redhat.com> Message-ID: <5507320B.2010604@redhat.com> yeah, I believe that just renaming columns of table REALM_APPLICATION with liquibase script would be enough. Marek On 16.3.2015 20:36, Leonardo Loch Zanivan wrote: > I think it's quite trivial create a migration script with liquibase. > > On Mon, Mar 16, 2015 at 4:29 PM Bill Burke > wrote: > > This is a major screwup...How do we handle this in a migration script? > Looks like an export/import would have to be done. > > On 3/16/2015 3:23 PM, Marek Posolda wrote: > > Hi, > > > > could you please create a JIRA for this? > > > > Thanks, > > Marek > > > > On 16.3.2015 20:00, Leonardo Loch Zanivan wrote: > >> Hi, > >> > >> I've configured KeyCloak datasource to a PostgreSQL database. > >> I found that "REALM_APPLICATION" table has a strange mapping. > >> > >> REALM_ID is the APPLICATION (CLIENT) > >> APPLICATION_ID is the REALM > >> > >> I think it was a mistake by incorrect JPA mapping. > >> > >> Regards, > >> Leonardo Zanivan > >> > >> > >> _______________________________________________ > >> keycloak-dev mailing list > >> keycloak-dev at lists.jboss.org > >> https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > > > > > > _______________________________________________ > > keycloak-dev mailing list > > keycloak-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > > -- > Bill Burke > JBoss, a division of Red Hat > http://bill.burkecentral.com > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150316/755124f3/attachment.html From bburke at redhat.com Mon Mar 16 15:43:11 2015 From: bburke at redhat.com (Bill Burke) Date: Mon, 16 Mar 2015 15:43:11 -0400 Subject: [keycloak-dev] Incorrect table mapping In-Reply-To: <5507320B.2010604@redhat.com> References: <55072DC5.3040904@redhat.com> <55072EFB.7080501@redhat.com> <5507320B.2010604@redhat.com> Message-ID: <5507324F.8070108@redhat.com> Phew... On 3/16/2015 3:42 PM, Marek Posolda wrote: > yeah, I believe that just renaming columns of table REALM_APPLICATION > with liquibase script would be enough. > > Marek > > On 16.3.2015 20:36, Leonardo Loch Zanivan wrote: >> I think it's quite trivial create a migration script with liquibase. >> >> On Mon, Mar 16, 2015 at 4:29 PM Bill Burke > > wrote: >> >> This is a major screwup...How do we handle this in a migration script? >> Looks like an export/import would have to be done. >> >> On 3/16/2015 3:23 PM, Marek Posolda wrote: >> > Hi, >> > >> > could you please create a JIRA for this? >> > >> > Thanks, >> > Marek >> > >> > On 16.3.2015 20:00, Leonardo Loch Zanivan wrote: >> >> Hi, >> >> >> >> I've configured KeyCloak datasource to a PostgreSQL database. >> >> I found that "REALM_APPLICATION" table has a strange mapping. >> >> >> >> REALM_ID is the APPLICATION (CLIENT) >> >> APPLICATION_ID is the REALM >> >> >> >> I think it was a mistake by incorrect JPA mapping. >> >> >> >> Regards, >> >> Leonardo Zanivan >> >> >> >> >> >> _______________________________________________ >> >> keycloak-dev mailing list >> >> keycloak-dev at lists.jboss.org >> >> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> > >> > >> > >> > _______________________________________________ >> > keycloak-dev mailing list >> > keycloak-dev at lists.jboss.org >> > https://lists.jboss.org/mailman/listinfo/keycloak-dev >> > >> >> -- >> Bill Burke >> JBoss, a division of Red Hat >> http://bill.burkecentral.com >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> >> >> >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev > -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From bburke at redhat.com Mon Mar 16 16:29:51 2015 From: bburke at redhat.com (Bill Burke) Date: Mon, 16 Mar 2015 16:29:51 -0400 Subject: [keycloak-dev] DB migration tasks being worked on? Message-ID: <55073D3F.8010208@redhat.com> Are DB migration tasks being worked on? I'd be willing to do the JPA ones, but not the Mongo ones. -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From bburke at redhat.com Mon Mar 16 16:31:15 2015 From: bburke at redhat.com (Bill Burke) Date: Mon, 16 Mar 2015 16:31:15 -0400 Subject: [keycloak-dev] need to release 1.2.beta1 Message-ID: <55073D93.9050501@redhat.com> We need to release beta1 next week. A few users are either working from master, asking for a release, and/or bugging us about an unworking master. Let's finish up jiras or defer them please so we can release next week. -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From matthew.casperson at autogeneral.com.au Mon Mar 16 19:44:39 2015 From: matthew.casperson at autogeneral.com.au (Matthew Casperson) Date: Tue, 17 Mar 2015 09:44:39 +1000 Subject: [keycloak-dev] Any way to limit Google social logins to a domain? Message-ID: It would be quite beneficial to be able to restrict Google social logins to a corporate domain. This appears to be supported by Google with the "hd" query param (see https://developers.google.com/accounts/docs/OAuth_ref#GetAuth and http://stackoverflow.com/questions/14336564/google-client-api-limit-oauth-authentication-to-my-domain). Is this something has been, or could be, exposed by KeyCloak? -- *Matthew Casperson* *Senior Front End Developer* Technology, Space & Distribution Auto & General Holdings Pty Ltd P: 07) 3377 8751 (Direct: 3377 8751) F: 07) 3377 8833 -- This email is sent by Auto & General Insurance Company Ltd, Auto & General Services Pty Ltd, Auto & General Holdings Pty Ltd or a related body corporate (Auto & General) and is for the intended addressee. The views expressed in this email and attachments (email) reflect the views of the stated author but may not reflect views of Auto & General. This email is confidential and subject to copyright. It may be privileged. If you are not the intended addressee, confidentiality and privilege have not been waived and any use, interference with, or disclosure of this email is unauthorised. If you are not the intended addressee please immediately notify the sender and then delete the email. Auto & General does not warrant that this email is error or virus free. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150317/b747b212/attachment.html From prakhashsiva21 at gmail.com Tue Mar 17 01:07:09 2015 From: prakhashsiva21 at gmail.com (Prakhash siva) Date: Tue, 17 Mar 2015 10:37:09 +0530 Subject: [keycloak-dev] Keycloak-Initial configuration In-Reply-To: <55072013.6020007@redhat.com> References: <55072013.6020007@redhat.com> Message-ID: Hi , Do I have to do anything in addition to mvn compile after I have done some changes in the files. I couldn't observe any changes after editing some files(Tried to observe changes after editing some Html files too). I think it is working from cache. Is it possible ? Steps I Followed. 1. Made changes in some files 2. executed mvn compile 3. started KeycloakServer using IDE 4. Localhost:8081/auth Thanks On Mon, Mar 16, 2015 at 11:55 PM, Bill Burke wrote: > AccountService and account theme is where you should implement this. > IMO, also, this action shouldn't delete the user, but rather disable it. > Once a user is deleted it becomes harder to develop an audit trail. > > On 3/16/2015 1:49 PM, Prakhash siva wrote: > > Hi, When using the keycloak how can we identify how the URL pattern > > works. i.e if I'm going to work on the bug KEYCLOAK-953 Allow a user to > > delete his own account I should identify how the user creation and > > deletion works.is there is any specific URL mappings > > or way to identify classes related that > > > > Can you explain how URL execution performed according to the request > > > > Thanks > > > > On Mon, Mar 16, 2015 at 9:59 AM, Prakhash siva > > wrote: > > > > Thanks Giriraj, I will configure it and let you know. I think it > > will be really helpfull > > > > On Mon, Mar 16, 2015 at 8:56 AM, Giriraj Sharma > > > > wrote: > > > > Hi, > > Keycloak source has KeycloakServer.java [1] in > > testsuite-integration module. It will let you run keycloak > > locally with JPA or Mongo model. > > This[2] might help you in running keycloak locally at > > localhost:8081/auth > > > > > > [1] > > > https://github.com/keycloak/keycloak/blob/master/testsuite/integration/src/main/java/org/keycloak/testutils/KeycloakServer.java > > [2] > > > https://github.com/keycloak/keycloak/tree/master/testsuite/integration > > > > Thanks, > > > > On Sun, Mar 15, 2015 at 10:36 PM, Prakhash siva > > > > wrote: > > > > Hi all, I'm Prakhash From Sri Lanka. I'm willing to > > contribute keycloak. I have cloned the keycloak repository > > but I could not figure out the initial configurations I need > > to do. I was able to find many tutorials saying how to > > configure keycloak with specific application but I believe > > it is not for keycloak development as a contributor. So can > > you please help me to do the initial configurations. I'm > > using ubuntu > > > > Thanks > > > > -- > > /*Sivakumar Prakhash*/ > > /*Undergraduate*/ > > /*Computer Science & Engineering*/ > > /*University of Moratuwa.*/ > > > > > > > > _______________________________________________ > > keycloak-dev mailing list > > keycloak-dev at lists.jboss.org > > > > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > > > > > > > > -- > > Giriraj Sharma > > about.me/girirajsharma > > > > > > > > Giriraj Sharma, > > Department of Computer Science > > National Institute of Technology Hamirpur > > Himachal Pradesh, India 177005 > > > > > > > > > > -- > > /*Sivakumar Prakhash*/ > > /*Undergraduate*/ > > /*Computer Science & Engineering*/ > > /*University of Moratuwa.*/ > > > > > > > > > > > > -- > > /*Sivakumar Prakhash*/ > > /*Undergraduate*/ > > /*Computer Science & Engineering*/ > > /*University of Moratuwa.*/ > > > > > > > > > > _______________________________________________ > > keycloak-dev mailing list > > keycloak-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > > -- > Bill Burke > JBoss, a division of Red Hat > http://bill.burkecentral.com > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > -- *Sivakumar Prakhash* *Undergraduate* *Computer Science & Engineering* *University of Moratuwa.* -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150317/d1b6236b/attachment.html From stian at redhat.com Tue Mar 17 01:36:10 2015 From: stian at redhat.com (Stian Thorgersen) Date: Tue, 17 Mar 2015 01:36:10 -0400 (EDT) Subject: [keycloak-dev] Keycloak-Initial configuration In-Reply-To: References: <55072013.6020007@redhat.com> Message-ID: <314984915.7797737.1426570570819.JavaMail.zimbra@redhat.com> ----- Original Message ----- > From: "Prakhash siva" > To: "Bill Burke" , "Giriraj Sharma" > Cc: "keycloak-dev" > Sent: Tuesday, March 17, 2015 6:07:09 AM > Subject: Re: [keycloak-dev] Keycloak-Initial configuration > > Hi , Do I have to do anything in addition to mvn compile after I have done > some changes in the files. I couldn't observe any changes after editing some > files(Tried to observe changes after editing some Html files too). I think > it is working from cache. Is it possible ? > > Steps I Followed. > 1. Made changes in some files > 2. executed mvn compile > 3. started KeycloakServer using IDE Set -Dresources when you start KeycloakServer and it'll load FreeMarker templates, html files, stylesheets, etc from sources instead of JARs. You also either have to disable Browser cache in your browser or you can tweak max-age in keycloak-server.json. > 4. Localhost:8081/auth > > Thanks > > On Mon, Mar 16, 2015 at 11:55 PM, Bill Burke < bburke at redhat.com > wrote: > > > AccountService and account theme is where you should implement this. > IMO, also, this action shouldn't delete the user, but rather disable it. > Once a user is deleted it becomes harder to develop an audit trail. > > On 3/16/2015 1:49 PM, Prakhash siva wrote: > > Hi, When using the keycloak how can we identify how the URL pattern > > works. i.e if I'm going to work on the bug KEYCLOAK-953 Allow a user to > > delete his own account I should identify how the user creation and > > deletion works.is < http://works.is > there is any specific URL mappings > > or way to identify classes related that > > > > Can you explain how URL execution performed according to the request > > > > Thanks > > > > On Mon, Mar 16, 2015 at 9:59 AM, Prakhash siva < prakhashsiva21 at gmail.com > > > wrote: > > > > Thanks Giriraj, I will configure it and let you know. I think it > > will be really helpfull > > > > On Mon, Mar 16, 2015 at 8:56 AM, Giriraj Sharma > > < giriraj.sharma27 at gmail.com > wrote: > > > > Hi, > > Keycloak source has KeycloakServer.java [1] in > > testsuite-integration module. It will let you run keycloak > > locally with JPA or Mongo model. > > This[2] might help you in running keycloak locally at > > localhost:8081/auth > > > > > > [1] > > https://github.com/keycloak/keycloak/blob/master/testsuite/integration/src/main/java/org/keycloak/testutils/KeycloakServer.java > > [2] > > https://github.com/keycloak/keycloak/tree/master/testsuite/integration > > > > Thanks, > > > > On Sun, Mar 15, 2015 at 10:36 PM, Prakhash siva > > < prakhashsiva21 at gmail.com > wrote: > > > > Hi all, I'm Prakhash From Sri Lanka. I'm willing to > > contribute keycloak. I have cloned the keycloak repository > > but I could not figure out the initial configurations I need > > to do. I was able to find many tutorials saying how to > > configure keycloak with specific application but I believe > > it is not for keycloak development as a contributor. So can > > you please help me to do the initial configurations. I'm > > using ubuntu > > > > Thanks > > > > -- > > /*Sivakumar Prakhash*/ > > /*Undergraduate*/ > > /*Computer Science & Engineering*/ > > /*University of Moratuwa.*/ > > > > > > > > _______________________________________________ > > keycloak-dev mailing list > > keycloak-dev at lists.jboss.org > > > > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > > > > > > > > -- > > Giriraj Sharma > > about.me/girirajsharma > > > > < http://about.me/girirajsharma?promo=email_sig > > > > > Giriraj Sharma, > > Department of Computer Science > > National Institute of Technology Hamirpur > > Himachal Pradesh, India 177005 > > > > > > > > > > -- > > /*Sivakumar Prakhash*/ > > /*Undergraduate*/ > > /*Computer Science & Engineering*/ > > /*University of Moratuwa.*/ > > > > > > > > > > > > -- > > /*Sivakumar Prakhash*/ > > /*Undergraduate*/ > > /*Computer Science & Engineering*/ > > /*University of Moratuwa.*/ > > > > > > > > > > _______________________________________________ > > keycloak-dev mailing list > > keycloak-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > > -- > Bill Burke > JBoss, a division of Red Hat > http://bill.burkecentral.com > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > > -- > Sivakumar Prakhash > Undergraduate > Computer Science & Engineering > University of Moratuwa. > > > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev From stian at redhat.com Tue Mar 17 01:45:32 2015 From: stian at redhat.com (Stian Thorgersen) Date: Tue, 17 Mar 2015 01:45:32 -0400 (EDT) Subject: [keycloak-dev] need to release 1.2.beta1 In-Reply-To: <55073D93.9050501@redhat.com> References: <55073D93.9050501@redhat.com> Message-ID: <1588266934.7798381.1426571132398.JavaMail.zimbra@redhat.com> +1 Remaining work is: * Testing and testing and testing - we've done a lot of changes in this release, especially with moving jars to modules, so I'd like everyone to do some manual testing please! * Migration for identity broker changes in DB - Marek is working on this * Migration of protocol mappers - where are we with this? * Migration of json representations - the plan was to support transforming old json representation (exports and also manually created realm.jsons) when we change the json representations * KEYCLOAK-946 LoginProtocol endpoints not shown in rest api documentation * KEYCLOAK-1042 Access to Cookies within Events - I propose we postpone this to 1.2.0.RC1 and introduce the KeycloakContext/Session changes I proposed first * KEYCLOAK-752 Upgrade Liquibase - we're using an old version of Liquibase that has a bug so we're currently using a different version in Keycloak and in Maven so we should upgrade to latest Liquibase * KEYCLOAK-301 Internationalization support for login screens - thanks to Michael Gerber we now have internationalization support for login forms, there's a few minor things outstanding though, but it's only visible if user enables the feature for a realm so I'm happy with releasing beta1 with this as a work in progress Anything else?!? ----- Original Message ----- > From: "Bill Burke" > To: keycloak-dev at lists.jboss.org > Sent: Monday, March 16, 2015 9:31:15 PM > Subject: [keycloak-dev] need to release 1.2.beta1 > > We need to release beta1 next week. A few users are either working from > master, asking for a release, and/or bugging us about an unworking > master. Let's finish up jiras or defer them please so we can release > next week. > -- > Bill Burke > JBoss, a division of Red Hat > http://bill.burkecentral.com > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > From juraci at kroehling.de Tue Mar 17 03:02:51 2015 From: juraci at kroehling.de (=?windows-1252?Q?Juraci_Paix=E3o_Kr=F6hling?=) Date: Tue, 17 Mar 2015 08:02:51 +0100 Subject: [keycloak-dev] Keycloak-Initial configuration In-Reply-To: References: <55072013.6020007@redhat.com> Message-ID: <5507D19B.2090300@kroehling.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 03/17/2015 06:07 AM, Prakhash siva wrote: > Hi , Do I have to do anything in addition to mvn compile after I > have done some changes in the files. I couldn't observe any changes > after editing some files(Tried to observe changes after editing > some Html files too). I think it is working from cache. Is it > possible ? > > Steps I Followed. 1. Made changes in some files 2. executed mvn > compile 3. started KeycloakServer using IDE 4. Localhost:8081/auth I had a similar problem recently when working on a small JIRA, and what I did was to load the resource in a separate browser tab and force a refresh there. For instance, if you need to force-refresh "service.js", you could open this JS in another tab and "ctrl+refresh" from there. Forcing a refresh on the main application seems to refresh only the resources first loaded by the page, not any resources loaded via XHR (like the ones that AngularJS loads, including HTML partials). I guess that's not very practical for heavy UI development, but it works for smaller tasks. - - Juca. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJVB9GbAAoJEDnJtskdmzLMqecH/3ZpanuYavNHpxy1tihKB0VY kVdEaGOAnbDYKRXemEzVN5c7M3TIT+dlS4+xP6OLWyNobV1CV5ZQ8sKocTO90HGy 03cVjXJdRHpEJS83Xa1uGKXRoePQ1XjQWSDx+4T2cKzsrpXnInW2eLWc4zPxepMu zSB3VSyv99XH7MOTCeeZ7UII9gIBDBKcOuAngm1u38DesA4yFI8YOTBakdO/8nBy 5YFR0utUxS2yCCOX86fjjAMEOsbIVF6xyG4u8E6L5YgohICLNWjeDKiqvKEXH2kw bsQTiRuB2tKZnFeQOxCbPu49LGHYVuOWm/kJDStjVrI0Gji7KxgLG9qOF2BjeKw= =/seJ -----END PGP SIGNATURE----- From stian at redhat.com Tue Mar 17 04:45:39 2015 From: stian at redhat.com (Stian Thorgersen) Date: Tue, 17 Mar 2015 04:45:39 -0400 (EDT) Subject: [keycloak-dev] Improvements of registration over Social Login providers In-Reply-To: <5502C0FC.1010902@redhat.com> References: <55000EA2.1060106@redhat.com> <1890728201.3815264.1426069493109.JavaMail.zimbra@redhat.com> <1406310153.3818601.1426069818031.JavaMail.zimbra@redhat.com> <55003803.5000905@redhat.com> <1566209466.4485464.1426152980166.JavaMail.zimbra@redhat.com> <5502C0FC.1010902@redhat.com> Message-ID: <611455806.7844697.1426581939600.JavaMail.zimbra@redhat.com> ----- Original Message ----- > From: "Vlastimil Elias" > To: "Stian Thorgersen" > Cc: keycloak-dev at lists.jboss.org > Sent: Friday, March 13, 2015 11:50:36 AM > Subject: Re: [keycloak-dev] Improvements of registration over Social Login providers > > Hi, > > On 12.3.2015 10:36, Stian Thorgersen wrote: > > > > ----- Original Message ----- > >> From: "Vlastimil Elias" > >> To: keycloak-dev at lists.jboss.org > >> Sent: Wednesday, 11 March, 2015 1:41:39 PM > >> Subject: Re: [keycloak-dev] Improvements of registration over Social Login > >> providers > >> > >> Hi > >> > >> I see your points and understand them if you take KC as primary system > >> for identity. > >> > >> But things change a bit if you use UserFederationProvider SPI and > >> primary user database is some other backend, and KC is used primarily to > >> add some missing features (eg social logins, modern SSO protocols) at > >> top of this backend. I'm in this position and I have to propagate new > >> users to the backend (even one created due social login) and must > >> reflect some constraints from the backend (like username must be email > >> in my case). > >> > >> Feature proposal from point 1 is not critical for me, I think it should > >> be useful for some KC installations to be able to disable social > >> registrations, but I do not need it, so we can let it be. > > If you don't need it I suggest we don't add it, as we haven't had anyone > > else request it. > I agree > > > >> Feature proposal 2 is more important for me. > >> I need email to be used as username in KC due my backend restrictions, > >> so I implemented some basic solution as part of KEYCLOAK-1074 pull > >> request. If you accept it and keep it in the code then I can use KC for > >> my project (or we have to find some other solution, eg some extension of > >> UserFederationProvider SPI to allow it to select username in case of > >> social registration). > >> > >> But this solution is only partial and I want to help you make KC > >> generally better for all use cases, so I did this proposal. > > I appreciate it, but if possible IMO it would be better to make it work by > > default rather than introducing configuration options. > Sure, I agree with this also. Use reasonable default if possible, not to > add config options for everything. > But if we have some more special requirements for our project which > can't be solved by reasonable default, we have only few ways how to add > them (as we can't fork KC for our project): > - add common config option into admin app - reasonable if they can fit > for more general use > - add some hidden config option (eg. in keycloak.json) - reasonable if > this option is raare use > - find some other customization solution like extension of some SPI or so I don't like the idea of adding hidden things directly to Keycloak, if it's common we can add it directly, if not it should be added through an SPI/extension-point. We can rather work on adding more extension points, than hidden options. > > > > >> I also think that current way how KC reuses username from social > >> providers is wrong as it may prevent some users from login, so what to > >> do with this? Create a bug in JIRA? > > Agree - using username from social providers isn't a good approach. > > > >> But I don't think solution with some randomly generated username, which > >> will be changed later, is a good one. > >> This may bring problems to other systems which use KC for SSO and store > >> data related to users. They typically rely on usernames to store these > >> data, but change of username in KC may break data integrity (hide data > >> for the user who changed username). How do you plan to prevent those > >> problems if you implement username change in KC? > >> > >> I understand that correct solution should be using 'User ID' in these > >> systems instead of username, but I fear it is not possible in many cases. > >> From my experience integration of existing applications like Atlassian > >> JIRA into SSO system may be problematic in this area, you are forced to > >> use usernames there, username changes are typically a problem. > >> So I think that username changes should be possible in KC for systems > >> who need it, but no any important feature like social registrations > >> should rely on them so heavily. > > Yeah, you're right we need a solution to this that doesn't require allowing > > usernames to be changed. > > > > How about: > > > > 1. We allow username to be null and users created through social login has > > a null username - this would change the login with email only feature > > you're implementing slightly > > 2. We add validation support to user profiles and if any required > > attributes are missing the user is required to add the missing attributes > > on login (before redirecting to application) > > 3. We add a require username/password option on social login - if this is > > enabled the user will have to add a username/password on first login. If > > not enable the same feature will be available through account management. > > > > In your use-case it would work by: > > > > * On social login if user is missing email (for example twitter) the user > > is shown a insert your email form as email would be marked as required. > > This would also work if you need other required attributes that are not > > available from social, for example a DOB > > * In the case of applications that require a username you can use the new > > claim mapping feature to map email to the username claim, or just make > > sure the application uses the email claim > > null username is a bit courageous proposal, I'm not sure keycloak can > live with it without any big rewrites of the code. Keycloak can live perfectly fine with a null username, it's just db constraints that would prevent it. > Some sensible default username should be used there I think (take it > from social provider if it is free, try to prepare some unique if it is > occupied in KC already). > Or we can ask user to input his username, but it is less user friendly > as it requires some user interaction (so finally we can do this as > configurable option how system will behave ;-). Setting it to username from social provider if free is fine. If it's not then we can either set it to null or even easier would be to set it to users id as it wouldn't require any changes elsewhere. We can then introduce an option to require user to specify username if it's null or same as user id. > > Our use of email as username is a bit more complicated as we use > UserFedaretionProvider SPI with synchronizeRegistrations() enabled - we > have to create user in backend system when it is created in KC, and we > have to use email as username there. So claim mapping for client > applications is not useful for us. > Problem is that KC now provides only "after first login" user > actions/screens which may be a bit late as account is created in KC already. > I'll look at this problem a bit deeper in next few days and try to > suggest some sensible solution. > See also https://issues.jboss.org/browse/KEYCLOAK-1053 We have to create the user internally in Keycloak as we need to persist it somewhere. In your UserFedaretionProvider you could create the user in register if the email is set, otherwise you could wait until the email is set (and verified perhaps?!). > > Cheers > > Vl. > > >> Thanks > >> > >> Vlastimil > >> > >> On 11.3.2015 11:30, Stian Thorgersen wrote: > >>> We can also add some more required actions: > >>> > >>> * Set email if missing > >>> * Set username/password > >>> > >>> It would then be possible to set one or more required actions for a first > >>> social login. > >>> > >>> ----- Original Message ----- > >>>> From: "Stian Thorgersen" > >>>> To: "Vlastimil Elias" > >>>> Cc: keycloak-dev at lists.jboss.org > >>>> Sent: Wednesday, 11 March, 2015 11:24:53 AM > >>>> Subject: Re: [keycloak-dev] Improvements of registration over Social > >>>> Login > >>>> providers > >>>> > >>>> > >>>> > >>>> ----- Original Message ----- > >>>>> From: "Vlastimil Elias" > >>>>> To: keycloak-dev at lists.jboss.org > >>>>> Sent: Wednesday, 11 March, 2015 10:45:06 AM > >>>>> Subject: [keycloak-dev] Improvements of registration over Social Login > >>>>> providers > >>>>> > >>>>> Hi great Keycloak dev team, > >>>>> > >>>>> during implementation of https://issues.jboss.org/browse/KEYCLOAK-1074 > >>>>> I > >>>>> found few things which should be improved in area of registration over > >>>>> Social Login providers. > >>>>> I'd like to discuss them here before creating JIRAs. I believe I should > >>>>> implement these changes if you will be interested. > >>>>> > >>>>> 1. It is not possible to disable registration over Social provider > >>>>> ====================================== > >>>>> Once provider is created then it is always possible to register over > >>>>> it, > >>>>> even > >>>>> if "User registration" is disabled in realm "Login Settings". I think > >>>>> it > >>>>> should be possible to disable social registrations and allow only to > >>>>> link > >>>>> social logins to existing accounts (eg. loaded from other system). > >>>>> > >>>>> Marek Posolda pointed me to > >>>>> https://issues.jboss.org/browse/KEYCLOAK-1036 > >>>>> which is rejected without any comment. I understand that this global > >>>>> setting > >>>>> is probably not a good solution, so my proposal is to add independent > >>>>> "User > >>>>> registration" switch into configuration of each Identity provider, so > >>>>> admin > >>>>> will get fine grained control. > >>>> -1 > >>>> > >>>> IMO when you add a identity broker (or social provider) you are allowing > >>>> all > >>>> those users to login. When a user logs in the first time using a > >>>> identity > >>>> broker we're not really registering the user, just creating an internal > >>>> representation. > >>>> > >>>>> 2. Username from Social provider is used as Keycloak username during > >>>>> registration > >>>>> =================================================== > >>>>> This can lead to the situation that user registering eg. over Twitter > >>>>> will > >>>>> not be able to register as other user eg. from Facebook will use same > >>>>> username there and occupy it in Keycloak as first. > >>>>> My proposal is to extend configuration of each Identity provider by new > >>>>> option "Username type" which will be select from these options: > >>>>> > >>>>> > >>>>> * provided username exact - works as now, username is got from > >>>>> provider, > >>>>> user can't register if occupied in KC already > >>>>> * provided username unique - KC will take username from provider, > >>>>> if > >>>>> occupied then it adds some random number to it to create unique > >>>>> username > >>>>> and allow user to register > >>>>> * provided email - this is related to KEYCLOAK-1074, I need this > >>>>> option > >>>>> for my project. I know that email is not provided by some > >>>>> providers > >>>>> (eg > >>>>> Twitter) so I can't use them until KEYCLOAK-1053 is resolved > >>>>> somehow > >>>>> > >>>>> So let me know what you think about my proposals, can I implement them? > >>>> -1 > >>>> > >>>> If it's using the username from the identity provider that's not > >>>> correct, > >>>> it > >>>> should just be set to something unique (could be set to same as user > >>>> id), > >>>> that's how it used to be before the identity brokering was introduced. > >>>> > >>>> We have an open issue to allow users to change their username. This > >>>> would > >>>> then be used by a user that wants to enable regular logins in the above > >>>> scenario. We could improve the account management around this, for > >>>> example > >>>> it should not display username if it's the same as user id, but have an > >>>> option for a user to "enable regular login" by providing a username and > >>>> password. > >>>> > >>>>> Cheers > >>>>> > >>>>> Vlastimil > >>>>> > >>>>> -- > >>>>> Vlastimil Elias > >>>>> Principal Software Engineer > >>>>> jboss.org Development Team > >>>>> > >>>>> _______________________________________________ > >>>>> keycloak-dev mailing list > >>>>> keycloak-dev at lists.jboss.org > >>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev > >>>> _______________________________________________ > >>>> keycloak-dev mailing list > >>>> keycloak-dev at lists.jboss.org > >>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev > >>>> > >> -- > >> Vlastimil Elias > >> Principal Software Engineer > >> jboss.org Development Team > >> > >> _______________________________________________ > >> keycloak-dev mailing list > >> keycloak-dev at lists.jboss.org > >> https://lists.jboss.org/mailman/listinfo/keycloak-dev > >> > > -- > Vlastimil Elias > Principal Software Engineer > jboss.org Development Team > > From stian at redhat.com Tue Mar 17 04:57:59 2015 From: stian at redhat.com (Stian Thorgersen) Date: Tue, 17 Mar 2015 04:57:59 -0400 (EDT) Subject: [keycloak-dev] Introducing KeycloakContext In-Reply-To: <5502F8CB.3010802@redhat.com> References: <101768104.5357724.1426226718404.JavaMail.zimbra@redhat.com> <5502F8CB.3010802@redhat.com> Message-ID: <513851046.7847365.1426582679629.JavaMail.zimbra@redhat.com> Great, I'll get started on this once 1.2.0.Beta1 is released. What's everyone's preference add to KeycloakSession or introduce a separate KeycloakContext? ----- Original Message ----- > From: "Bill Burke" > To: keycloak-dev at lists.jboss.org > Sent: Friday, March 13, 2015 3:48:43 PM > Subject: Re: [keycloak-dev] Introducing KeycloakContext > > Lol! I was thinking the same thing yesterday. There's other things > that need passing around too in many areas: UserSessionModel, > ClientSessionModel > > > > On 3/13/2015 2:05 AM, Stian Thorgersen wrote: > > Currently we pass a lot of things around. For example: > > > > AuthenticationManager.logout(session, realm, userSession, uriInfo, > > connection) > > Flows.forms(session, realm, client, uriInfo) > > > > I propose we introduce a KeycloakContext that can hold everything. It would > > be injectable by RestEasy: > > > > @Context > > KeycloakContext context; > > > > And would look something like: > > > > public interface KeycloakContext { > > KeycloakSession session(); > > RealmModel realm(); > > HttpRequest request(); > > UriInfo uriInfo(); > > ClientConnection clientConnection(); > > EventBuilder event(); > > } > > > > Also, I think we should convert AuthenticationManager and TokenManager into > > providers so they can be obtained from the session rather than passing it > > around everywhere. > > > > The above changes would be introduced after 1.2.0.Beta1 and can be done > > incrementally!! > > _______________________________________________ > > keycloak-dev mailing list > > keycloak-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > > -- > Bill Burke > JBoss, a division of Red Hat > http://bill.burkecentral.com > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > From stian at redhat.com Tue Mar 17 05:00:57 2015 From: stian at redhat.com (Stian Thorgersen) Date: Tue, 17 Mar 2015 05:00:57 -0400 (EDT) Subject: [keycloak-dev] Issue with latest Github master and SAML IDP providers? In-Reply-To: References: <404035330.4495455.1426153778301.JavaMail.zimbra@redhat.com> <510530563.5356159.1426225815272.JavaMail.zimbra@redhat.com> Message-ID: <1084413568.7848043.1426582857523.JavaMail.zimbra@redhat.com> ----- Original Message ----- > From: "Guy Davis" > To: "Stian Thorgersen" > Cc: keycloak-dev at lists.jboss.org > Sent: Sunday, March 15, 2015 2:17:19 AM > Subject: Re: [keycloak-dev] Issue with latest Github master and SAML IDP providers? > > Hi Stian, > > I tried the following using the very latest Github master. > > 1. Keycloak appliance (built in distribution folder so Wildfly 8.2). > Had a problem: > 1. Doesn't list SAML or Open ID Connect in the Identity Providers > picklist like previous versions. Please see screenshot > attached. Did the > IdP choice get moved? Seems like there's a bug, I'll look at this now > 2. Deploying Keycloak into a JBoss EAP 6.3 (from Teiid 8.10). Had > following errors: > 1. Failed deployment due to lack of org.bouncycastle module. Not > part of JBoss 6 Adapter? bcprov and bcpix are in > auth-server.war/WEB-INF/lib, but something is trying to load it > as a module. > 2. After adding a org.bouncycastle module manually using the bc 1.50 > jars, I got a resteasy-crypto module missing error. If I add that I > get > conflicts between resteasy-2.3.8 in JBoss EAP and resteasy 3 > that provides > resteasy-crypto. > > So, I'm struggling to see the best way forward. I need to remain > compatible with Teiid which is tied to JBoss EAP, not Wildfly. As well, > our app is still geared toward JBoss EAP 6.1.0alpha (aka JBoss AS 7). > Keycloak indicates adapters for WF, EAP, and AS 7 are all supported. I was > able to demo Identity Brokering just two weeks ago successfully on AS7 > (6.1.0alpha), so this is a recent change on master. > > Please advise on the best path forward. A key benefit of Keycloak over > other IDP/SSO options was that it could exist in the same JBoss container > as our other apps and frameworks. > > Thanks, > Guy > > > On Thu, Mar 12, 2015 at 11:50 PM, Stian Thorgersen wrote: > > > I assume this happens after you've clicked on 'PicketLink IDP' on the > > login screen? > > > > Can you try the same with the appliance download? We don't support JBoss > > EAP 6.1.0alpha, so maybe that's the problem. > > > > ----- Original Message ----- > > > From: "Guy Davis" > > > To: "Stian Thorgersen" > > > Cc: keycloak-dev at lists.jboss.org > > > Sent: Thursday, March 12, 2015 7:52:00 PM > > > Subject: Re: [keycloak-dev] Issue with latest Github master and SAML IDP > > providers? > > > > > > Hi Stian, > > > > > > Thanks for the response. Yes, I'm still seeing this issue with the very > > > latest Github master (including today's commit #1038). This was working > > > for me a couple of weeks ago, before more recent commits. We demoed the > > > identity broker to our management using a PicketLink test idp.war (in > > same > > > container) and also using MS WAAD on Azure. It's a key feature for us. > > > > > > Let me provide more details about my environment: > > > > > > 1. Building/running with Java 1.7 > > > 2. Building master with 'mvn clean install -DskipTests=true > > > -Pdistribution' > > > 3. Running within a JBoss EAP 6.1.0alpha container using the modules > > > from distribution\as7-adapter-zip\target\unpacked in > > > my ApplicationServer\modules\system\layers\base with the following > > > differences: > > > 1. Had to add 'org/bouncycastle/main/bcprov-jdk16-1.46.jar' > > otherwise > > > Keycloak complained on startup in server.log. > > > 2. Had to remove 'org/jboss/as' and 'org/jboss/aesh' as they were > > > overwriting older JBoss EAP 6.1.0alpha versions and preventing > > startup. > > > 4. Deploying the auth-server.war by zipping the contents and renaming > > > 'auth.war', placing in my standalone/deployments folder. > > > 5. Updating the standalone.xml file with the required Keycloak config. > > > Defining the realm and secure deployments in that XML directly. > > > 6. Starting with a missing H2 datasource to ensure old data/schema is > > > not the problem. On startup, I confirm admin's password and then > > re-build > > > my DSIS realm. > > > > > > Any help you can provide would be most appreciated. I'm using the > > Keycloak > > > master as features being added now such as Kerberos/Spnego and Identity > > > Brokering are critical use cases for our adoption. > > > > > > Thanks, > > > Guy > > > > > > > > > On Thu, Mar 12, 2015 at 3:49 AM, Stian Thorgersen > > wrote: > > > > > > > Are you still having issues or did you figure it out? > > > > > > > > ----- Original Message ----- > > > > > From: "Guy Davis" > > > > > To: keycloak-dev at lists.jboss.org > > > > > Sent: Wednesday, 4 March, 2015 1:10:52 AM > > > > > Subject: [keycloak-dev] Issue with latest Github master and SAML IDP > > > > providers? > > > > > > > > > > Good day, > > > > > > > > > > I've been using a sample Picketlink IDP locally for testing the SAML > > > > v2.0 ID > > > > > brokering, however after updating to latest master and re-deploying > > > > > components, I'm getting the following error. Any tips? > > > > > > > > > > > > > > > > > > > > Thanks in advance, > > > > > Guy > > > > > > > > > > _______________________________________________ > > > > > keycloak-dev mailing list > > > > > keycloak-dev at lists.jboss.org > > > > > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > > > > > > > > From stian at redhat.com Tue Mar 17 05:05:56 2015 From: stian at redhat.com (Stian Thorgersen) Date: Tue, 17 Mar 2015 05:05:56 -0400 (EDT) Subject: [keycloak-dev] Issue with latest Github master and SAML IDP providers? In-Reply-To: References: <404035330.4495455.1426153778301.JavaMail.zimbra@redhat.com> <510530563.5356159.1426225815272.JavaMail.zimbra@redhat.com> Message-ID: <1591132776.7849698.1426583156197.JavaMail.zimbra@redhat.com> ----- Original Message ----- > From: "Guy Davis" > To: "Stian Thorgersen" > Cc: keycloak-dev at lists.jboss.org > Sent: Sunday, March 15, 2015 2:17:19 AM > Subject: Re: [keycloak-dev] Issue with latest Github master and SAML IDP providers? > > Hi Stian, > > I tried the following using the very latest Github master. > > 1. Keycloak appliance (built in distribution folder so Wildfly 8.2). > Had a problem: > 1. Doesn't list SAML or Open ID Connect in the Identity Providers > picklist like previous versions. Please see screenshot > attached. Did the > IdP choice get moved? > 2. Deploying Keycloak into a JBoss EAP 6.3 (from Teiid 8.10). Had > following errors: > 1. Failed deployment due to lack of org.bouncycastle module. Not > part of JBoss 6 Adapter? bcprov and bcpix are in > auth-server.war/WEB-INF/lib, but something is trying to load it > as a module. > 2. After adding a org.bouncycastle module manually using the bc 1.50 > jars, I got a resteasy-crypto module missing error. If I add that I > get > conflicts between resteasy-2.3.8 in JBoss EAP and resteasy 3 > that provides > resteasy-crypto. > > So, I'm struggling to see the best way forward. I need to remain > compatible with Teiid which is tied to JBoss EAP, not Wildfly. As well, > our app is still geared toward JBoss EAP 6.1.0alpha (aka JBoss AS 7). > Keycloak indicates adapters for WF, EAP, and AS 7 are all supported. I was > able to demo Identity Brokering just two weeks ago successfully on AS7 > (6.1.0alpha), so this is a recent change on master. > > Please advise on the best path forward. A key benefit of Keycloak over > other IDP/SSO options was that it could exist in the same JBoss container > as our other apps and frameworks. We support adapters for EAP and AS7, but not deploying the server itself. We will provide an option for other JBoss projects to build their own Keycloak to embed into their project though, which would be the recommended route for Teiid if they'd like to include it. > > Thanks, > Guy > > > On Thu, Mar 12, 2015 at 11:50 PM, Stian Thorgersen wrote: > > > I assume this happens after you've clicked on 'PicketLink IDP' on the > > login screen? > > > > Can you try the same with the appliance download? We don't support JBoss > > EAP 6.1.0alpha, so maybe that's the problem. > > > > ----- Original Message ----- > > > From: "Guy Davis" > > > To: "Stian Thorgersen" > > > Cc: keycloak-dev at lists.jboss.org > > > Sent: Thursday, March 12, 2015 7:52:00 PM > > > Subject: Re: [keycloak-dev] Issue with latest Github master and SAML IDP > > providers? > > > > > > Hi Stian, > > > > > > Thanks for the response. Yes, I'm still seeing this issue with the very > > > latest Github master (including today's commit #1038). This was working > > > for me a couple of weeks ago, before more recent commits. We demoed the > > > identity broker to our management using a PicketLink test idp.war (in > > same > > > container) and also using MS WAAD on Azure. It's a key feature for us. > > > > > > Let me provide more details about my environment: > > > > > > 1. Building/running with Java 1.7 > > > 2. Building master with 'mvn clean install -DskipTests=true > > > -Pdistribution' > > > 3. Running within a JBoss EAP 6.1.0alpha container using the modules > > > from distribution\as7-adapter-zip\target\unpacked in > > > my ApplicationServer\modules\system\layers\base with the following > > > differences: > > > 1. Had to add 'org/bouncycastle/main/bcprov-jdk16-1.46.jar' > > otherwise > > > Keycloak complained on startup in server.log. > > > 2. Had to remove 'org/jboss/as' and 'org/jboss/aesh' as they were > > > overwriting older JBoss EAP 6.1.0alpha versions and preventing > > startup. > > > 4. Deploying the auth-server.war by zipping the contents and renaming > > > 'auth.war', placing in my standalone/deployments folder. > > > 5. Updating the standalone.xml file with the required Keycloak config. > > > Defining the realm and secure deployments in that XML directly. > > > 6. Starting with a missing H2 datasource to ensure old data/schema is > > > not the problem. On startup, I confirm admin's password and then > > re-build > > > my DSIS realm. > > > > > > Any help you can provide would be most appreciated. I'm using the > > Keycloak > > > master as features being added now such as Kerberos/Spnego and Identity > > > Brokering are critical use cases for our adoption. > > > > > > Thanks, > > > Guy > > > > > > > > > On Thu, Mar 12, 2015 at 3:49 AM, Stian Thorgersen > > wrote: > > > > > > > Are you still having issues or did you figure it out? > > > > > > > > ----- Original Message ----- > > > > > From: "Guy Davis" > > > > > To: keycloak-dev at lists.jboss.org > > > > > Sent: Wednesday, 4 March, 2015 1:10:52 AM > > > > > Subject: [keycloak-dev] Issue with latest Github master and SAML IDP > > > > providers? > > > > > > > > > > Good day, > > > > > > > > > > I've been using a sample Picketlink IDP locally for testing the SAML > > > > v2.0 ID > > > > > brokering, however after updating to latest master and re-deploying > > > > > components, I'm getting the following error. Any tips? > > > > > > > > > > > > > > > > > > > > Thanks in advance, > > > > > Guy > > > > > > > > > > _______________________________________________ > > > > > keycloak-dev mailing list > > > > > keycloak-dev at lists.jboss.org > > > > > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > > > > > > > > From mposolda at redhat.com Tue Mar 17 05:37:03 2015 From: mposolda at redhat.com (Marek Posolda) Date: Tue, 17 Mar 2015 10:37:03 +0100 Subject: [keycloak-dev] need to release 1.2.beta1 In-Reply-To: <1588266934.7798381.1426571132398.JavaMail.zimbra@redhat.com> References: <55073D93.9050501@redhat.com> <1588266934.7798381.1426571132398.JavaMail.zimbra@redhat.com> Message-ID: <5507F5BF.2040102@redhat.com> On 17.3.2015 06:45, Stian Thorgersen wrote: > +1 > > Remaining work is: > > * Testing and testing and testing - we've done a lot of changes in this release, especially with moving jars to modules, so I'd like everyone to do some manual testing please! > * Migration for identity broker changes in DB - Marek is working on this > * Migration of protocol mappers - where are we with this? When I am looking at migration of identity brokers, I can maybe take a look at migration of protocol mappers too? So all the migration stuff for JPA and Mongo is on me. So should I assign KEYCLOAK-1098 to myself? Marek > * Migration of json representations - the plan was to support transforming old json representation (exports and also manually created realm.jsons) when we change the json representations > * KEYCLOAK-946 LoginProtocol endpoints not shown in rest api documentation > * KEYCLOAK-1042 Access to Cookies within Events - I propose we postpone this to 1.2.0.RC1 and introduce the KeycloakContext/Session changes I proposed first > * KEYCLOAK-752 Upgrade Liquibase - we're using an old version of Liquibase that has a bug so we're currently using a different version in Keycloak and in Maven so we should upgrade to latest Liquibase > * KEYCLOAK-301 Internationalization support for login screens - thanks to Michael Gerber we now have internationalization support for login forms, there's a few minor things outstanding though, but it's only visible if user enables the feature for a realm so I'm happy with releasing beta1 with this as a work in progress > > Anything else?!? > > ----- Original Message ----- >> From: "Bill Burke" >> To: keycloak-dev at lists.jboss.org >> Sent: Monday, March 16, 2015 9:31:15 PM >> Subject: [keycloak-dev] need to release 1.2.beta1 >> >> We need to release beta1 next week. A few users are either working from >> master, asking for a release, and/or bugging us about an unworking >> master. Let's finish up jiras or defer them please so we can release >> next week. >> -- >> Bill Burke >> JBoss, a division of Red Hat >> http://bill.burkecentral.com >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev From stian at redhat.com Tue Mar 17 05:43:20 2015 From: stian at redhat.com (Stian Thorgersen) Date: Tue, 17 Mar 2015 05:43:20 -0400 (EDT) Subject: [keycloak-dev] need to release 1.2.beta1 In-Reply-To: <5507F5BF.2040102@redhat.com> References: <55073D93.9050501@redhat.com> <1588266934.7798381.1426571132398.JavaMail.zimbra@redhat.com> <5507F5BF.2040102@redhat.com> Message-ID: <1166121338.7862293.1426585400057.JavaMail.zimbra@redhat.com> ----- Original Message ----- > From: "Marek Posolda" > To: "Stian Thorgersen" , "Bill Burke" > Cc: keycloak-dev at lists.jboss.org > Sent: Tuesday, March 17, 2015 10:37:03 AM > Subject: Re: [keycloak-dev] need to release 1.2.beta1 > > On 17.3.2015 06:45, Stian Thorgersen wrote: > > +1 > > > > Remaining work is: > > > > * Testing and testing and testing - we've done a lot of changes in this > > release, especially with moving jars to modules, so I'd like everyone to > > do some manual testing please! > > * Migration for identity broker changes in DB - Marek is working on this > > * Migration of protocol mappers - where are we with this? > When I am looking at migration of identity brokers, I can maybe take a > look at migration of protocol mappers too? So all the migration stuff > for JPA and Mongo is on me. So should I assign KEYCLOAK-1098 to myself? Sounds good, unless Bill wants to or has already started to look at that > > Marek > > * Migration of json representations - the plan was to support transforming > > old json representation (exports and also manually created realm.jsons) > > when we change the json representations > > * KEYCLOAK-946 LoginProtocol endpoints not shown in rest api documentation > > * KEYCLOAK-1042 Access to Cookies within Events - I propose we postpone > > this to 1.2.0.RC1 and introduce the KeycloakContext/Session changes I > > proposed first > > * KEYCLOAK-752 Upgrade Liquibase - we're using an old version of Liquibase > > that has a bug so we're currently using a different version in Keycloak > > and in Maven so we should upgrade to latest Liquibase > > * KEYCLOAK-301 Internationalization support for login screens - thanks to > > Michael Gerber we now have internationalization support for login forms, > > there's a few minor things outstanding though, but it's only visible if > > user enables the feature for a realm so I'm happy with releasing beta1 > > with this as a work in progress > > > > Anything else?!? > > > > ----- Original Message ----- > >> From: "Bill Burke" > >> To: keycloak-dev at lists.jboss.org > >> Sent: Monday, March 16, 2015 9:31:15 PM > >> Subject: [keycloak-dev] need to release 1.2.beta1 > >> > >> We need to release beta1 next week. A few users are either working from > >> master, asking for a release, and/or bugging us about an unworking > >> master. Let's finish up jiras or defer them please so we can release > >> next week. > >> -- > >> Bill Burke > >> JBoss, a division of Red Hat > >> http://bill.burkecentral.com > >> _______________________________________________ > >> keycloak-dev mailing list > >> keycloak-dev at lists.jboss.org > >> https://lists.jboss.org/mailman/listinfo/keycloak-dev > >> > > _______________________________________________ > > keycloak-dev mailing list > > keycloak-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > From bburke at redhat.com Tue Mar 17 07:47:18 2015 From: bburke at redhat.com (Bill Burke) Date: Tue, 17 Mar 2015 07:47:18 -0400 Subject: [keycloak-dev] Issue with latest Github master and SAML IDP providers? In-Reply-To: <1591132776.7849698.1426583156197.JavaMail.zimbra@redhat.com> References: <404035330.4495455.1426153778301.JavaMail.zimbra@redhat.com> <510530563.5356159.1426225815272.JavaMail.zimbra@redhat.com> <1591132776.7849698.1426583156197.JavaMail.zimbra@redhat.com> Message-ID: <55081446.2010607@redhat.com> I was going to look into these problems today. Let me know if you've gotten to them. On 3/17/2015 5:05 AM, Stian Thorgersen wrote: > > > ----- Original Message ----- >> From: "Guy Davis" >> To: "Stian Thorgersen" >> Cc: keycloak-dev at lists.jboss.org >> Sent: Sunday, March 15, 2015 2:17:19 AM >> Subject: Re: [keycloak-dev] Issue with latest Github master and SAML IDP providers? >> >> Hi Stian, >> >> I tried the following using the very latest Github master. >> >> 1. Keycloak appliance (built in distribution folder so Wildfly 8.2). >> Had a problem: >> 1. Doesn't list SAML or Open ID Connect in the Identity Providers >> picklist like previous versions. Please see screenshot >> attached. Did the >> IdP choice get moved? >> 2. Deploying Keycloak into a JBoss EAP 6.3 (from Teiid 8.10). Had >> following errors: >> 1. Failed deployment due to lack of org.bouncycastle module. Not >> part of JBoss 6 Adapter? bcprov and bcpix are in >> auth-server.war/WEB-INF/lib, but something is trying to load it >> as a module. >> 2. After adding a org.bouncycastle module manually using the bc 1.50 >> jars, I got a resteasy-crypto module missing error. If I add that I >> get >> conflicts between resteasy-2.3.8 in JBoss EAP and resteasy 3 >> that provides >> resteasy-crypto. >> >> So, I'm struggling to see the best way forward. I need to remain >> compatible with Teiid which is tied to JBoss EAP, not Wildfly. As well, >> our app is still geared toward JBoss EAP 6.1.0alpha (aka JBoss AS 7). >> Keycloak indicates adapters for WF, EAP, and AS 7 are all supported. I was >> able to demo Identity Brokering just two weeks ago successfully on AS7 >> (6.1.0alpha), so this is a recent change on master. >> >> Please advise on the best path forward. A key benefit of Keycloak over >> other IDP/SSO options was that it could exist in the same JBoss container >> as our other apps and frameworks. > > We support adapters for EAP and AS7, but not deploying the server itself. We will provide an option for other JBoss projects to build their own Keycloak to embed into their project though, which would be the recommended route for Teiid if they'd like to include it. > >> >> Thanks, >> Guy >> >> >> On Thu, Mar 12, 2015 at 11:50 PM, Stian Thorgersen wrote: >> >>> I assume this happens after you've clicked on 'PicketLink IDP' on the >>> login screen? >>> >>> Can you try the same with the appliance download? We don't support JBoss >>> EAP 6.1.0alpha, so maybe that's the problem. >>> >>> ----- Original Message ----- >>>> From: "Guy Davis" >>>> To: "Stian Thorgersen" >>>> Cc: keycloak-dev at lists.jboss.org >>>> Sent: Thursday, March 12, 2015 7:52:00 PM >>>> Subject: Re: [keycloak-dev] Issue with latest Github master and SAML IDP >>> providers? >>>> >>>> Hi Stian, >>>> >>>> Thanks for the response. Yes, I'm still seeing this issue with the very >>>> latest Github master (including today's commit #1038). This was working >>>> for me a couple of weeks ago, before more recent commits. We demoed the >>>> identity broker to our management using a PicketLink test idp.war (in >>> same >>>> container) and also using MS WAAD on Azure. It's a key feature for us. >>>> >>>> Let me provide more details about my environment: >>>> >>>> 1. Building/running with Java 1.7 >>>> 2. Building master with 'mvn clean install -DskipTests=true >>>> -Pdistribution' >>>> 3. Running within a JBoss EAP 6.1.0alpha container using the modules >>>> from distribution\as7-adapter-zip\target\unpacked in >>>> my ApplicationServer\modules\system\layers\base with the following >>>> differences: >>>> 1. Had to add 'org/bouncycastle/main/bcprov-jdk16-1.46.jar' >>> otherwise >>>> Keycloak complained on startup in server.log. >>>> 2. Had to remove 'org/jboss/as' and 'org/jboss/aesh' as they were >>>> overwriting older JBoss EAP 6.1.0alpha versions and preventing >>> startup. >>>> 4. Deploying the auth-server.war by zipping the contents and renaming >>>> 'auth.war', placing in my standalone/deployments folder. >>>> 5. Updating the standalone.xml file with the required Keycloak config. >>>> Defining the realm and secure deployments in that XML directly. >>>> 6. Starting with a missing H2 datasource to ensure old data/schema is >>>> not the problem. On startup, I confirm admin's password and then >>> re-build >>>> my DSIS realm. >>>> >>>> Any help you can provide would be most appreciated. I'm using the >>> Keycloak >>>> master as features being added now such as Kerberos/Spnego and Identity >>>> Brokering are critical use cases for our adoption. >>>> >>>> Thanks, >>>> Guy >>>> >>>> >>>> On Thu, Mar 12, 2015 at 3:49 AM, Stian Thorgersen >>> wrote: >>>> >>>>> Are you still having issues or did you figure it out? >>>>> >>>>> ----- Original Message ----- >>>>>> From: "Guy Davis" >>>>>> To: keycloak-dev at lists.jboss.org >>>>>> Sent: Wednesday, 4 March, 2015 1:10:52 AM >>>>>> Subject: [keycloak-dev] Issue with latest Github master and SAML IDP >>>>> providers? >>>>>> >>>>>> Good day, >>>>>> >>>>>> I've been using a sample Picketlink IDP locally for testing the SAML >>>>> v2.0 ID >>>>>> brokering, however after updating to latest master and re-deploying >>>>>> components, I'm getting the following error. Any tips? >>>>>> >>>>>> >>>>>> >>>>>> Thanks in advance, >>>>>> Guy >>>>>> >>>>>> _______________________________________________ >>>>>> keycloak-dev mailing list >>>>>> keycloak-dev at lists.jboss.org >>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>>>> >>>> >>> >> > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From stian at redhat.com Tue Mar 17 09:41:54 2015 From: stian at redhat.com (Stian Thorgersen) Date: Tue, 17 Mar 2015 09:41:54 -0400 (EDT) Subject: [keycloak-dev] Issue with latest Github master and SAML IDP providers? In-Reply-To: <55081446.2010607@redhat.com> References: <404035330.4495455.1426153778301.JavaMail.zimbra@redhat.com> <510530563.5356159.1426225815272.JavaMail.zimbra@redhat.com> <1591132776.7849698.1426583156197.JavaMail.zimbra@redhat.com> <55081446.2010607@redhat.com> Message-ID: <956039655.7970864.1426599714276.JavaMail.zimbra@redhat.com> Fixed #1 ----- Original Message ----- > From: "Bill Burke" > To: keycloak-dev at lists.jboss.org > Sent: Tuesday, March 17, 2015 12:47:18 PM > Subject: Re: [keycloak-dev] Issue with latest Github master and SAML IDP providers? > > I was going to look into these problems today. Let me know if you've > gotten to them. > > On 3/17/2015 5:05 AM, Stian Thorgersen wrote: > > > > > > ----- Original Message ----- > >> From: "Guy Davis" > >> To: "Stian Thorgersen" > >> Cc: keycloak-dev at lists.jboss.org > >> Sent: Sunday, March 15, 2015 2:17:19 AM > >> Subject: Re: [keycloak-dev] Issue with latest Github master and SAML IDP > >> providers? > >> > >> Hi Stian, > >> > >> I tried the following using the very latest Github master. > >> > >> 1. Keycloak appliance (built in distribution folder so Wildfly 8.2). > >> Had a problem: > >> 1. Doesn't list SAML or Open ID Connect in the Identity Providers > >> picklist like previous versions. Please see screenshot > >> attached. Did the > >> IdP choice get moved? > >> 2. Deploying Keycloak into a JBoss EAP 6.3 (from Teiid 8.10). Had > >> following errors: > >> 1. Failed deployment due to lack of org.bouncycastle module. Not > >> part of JBoss 6 Adapter? bcprov and bcpix are in > >> auth-server.war/WEB-INF/lib, but something is trying to load it > >> as a module. > >> 2. After adding a org.bouncycastle module manually using the bc > >> 1.50 > >> jars, I got a resteasy-crypto module missing error. If I add that > >> I > >> get > >> conflicts between resteasy-2.3.8 in JBoss EAP and resteasy 3 > >> that provides > >> resteasy-crypto. > >> > >> So, I'm struggling to see the best way forward. I need to remain > >> compatible with Teiid which is tied to JBoss EAP, not Wildfly. As well, > >> our app is still geared toward JBoss EAP 6.1.0alpha (aka JBoss AS 7). > >> Keycloak indicates adapters for WF, EAP, and AS 7 are all supported. I > >> was > >> able to demo Identity Brokering just two weeks ago successfully on AS7 > >> (6.1.0alpha), so this is a recent change on master. > >> > >> Please advise on the best path forward. A key benefit of Keycloak over > >> other IDP/SSO options was that it could exist in the same JBoss container > >> as our other apps and frameworks. > > > > We support adapters for EAP and AS7, but not deploying the server itself. > > We will provide an option for other JBoss projects to build their own > > Keycloak to embed into their project though, which would be the > > recommended route for Teiid if they'd like to include it. > > > >> > >> Thanks, > >> Guy > >> > >> > >> On Thu, Mar 12, 2015 at 11:50 PM, Stian Thorgersen > >> wrote: > >> > >>> I assume this happens after you've clicked on 'PicketLink IDP' on the > >>> login screen? > >>> > >>> Can you try the same with the appliance download? We don't support JBoss > >>> EAP 6.1.0alpha, so maybe that's the problem. > >>> > >>> ----- Original Message ----- > >>>> From: "Guy Davis" > >>>> To: "Stian Thorgersen" > >>>> Cc: keycloak-dev at lists.jboss.org > >>>> Sent: Thursday, March 12, 2015 7:52:00 PM > >>>> Subject: Re: [keycloak-dev] Issue with latest Github master and SAML IDP > >>> providers? > >>>> > >>>> Hi Stian, > >>>> > >>>> Thanks for the response. Yes, I'm still seeing this issue with the very > >>>> latest Github master (including today's commit #1038). This was working > >>>> for me a couple of weeks ago, before more recent commits. We demoed the > >>>> identity broker to our management using a PicketLink test idp.war (in > >>> same > >>>> container) and also using MS WAAD on Azure. It's a key feature for us. > >>>> > >>>> Let me provide more details about my environment: > >>>> > >>>> 1. Building/running with Java 1.7 > >>>> 2. Building master with 'mvn clean install -DskipTests=true > >>>> -Pdistribution' > >>>> 3. Running within a JBoss EAP 6.1.0alpha container using the modules > >>>> from distribution\as7-adapter-zip\target\unpacked in > >>>> my ApplicationServer\modules\system\layers\base with the following > >>>> differences: > >>>> 1. Had to add 'org/bouncycastle/main/bcprov-jdk16-1.46.jar' > >>> otherwise > >>>> Keycloak complained on startup in server.log. > >>>> 2. Had to remove 'org/jboss/as' and 'org/jboss/aesh' as they were > >>>> overwriting older JBoss EAP 6.1.0alpha versions and preventing > >>> startup. > >>>> 4. Deploying the auth-server.war by zipping the contents and > >>>> renaming > >>>> 'auth.war', placing in my standalone/deployments folder. > >>>> 5. Updating the standalone.xml file with the required Keycloak > >>>> config. > >>>> Defining the realm and secure deployments in that XML directly. > >>>> 6. Starting with a missing H2 datasource to ensure old data/schema > >>>> is > >>>> not the problem. On startup, I confirm admin's password and then > >>> re-build > >>>> my DSIS realm. > >>>> > >>>> Any help you can provide would be most appreciated. I'm using the > >>> Keycloak > >>>> master as features being added now such as Kerberos/Spnego and Identity > >>>> Brokering are critical use cases for our adoption. > >>>> > >>>> Thanks, > >>>> Guy > >>>> > >>>> > >>>> On Thu, Mar 12, 2015 at 3:49 AM, Stian Thorgersen > >>> wrote: > >>>> > >>>>> Are you still having issues or did you figure it out? > >>>>> > >>>>> ----- Original Message ----- > >>>>>> From: "Guy Davis" > >>>>>> To: keycloak-dev at lists.jboss.org > >>>>>> Sent: Wednesday, 4 March, 2015 1:10:52 AM > >>>>>> Subject: [keycloak-dev] Issue with latest Github master and SAML IDP > >>>>> providers? > >>>>>> > >>>>>> Good day, > >>>>>> > >>>>>> I've been using a sample Picketlink IDP locally for testing the SAML > >>>>> v2.0 ID > >>>>>> brokering, however after updating to latest master and re-deploying > >>>>>> components, I'm getting the following error. Any tips? > >>>>>> > >>>>>> > >>>>>> > >>>>>> Thanks in advance, > >>>>>> Guy > >>>>>> > >>>>>> _______________________________________________ > >>>>>> keycloak-dev mailing list > >>>>>> keycloak-dev at lists.jboss.org > >>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev > >>>>> > >>>> > >>> > >> > > _______________________________________________ > > keycloak-dev mailing list > > keycloak-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > > -- > Bill Burke > JBoss, a division of Red Hat > http://bill.burkecentral.com > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > From leonardo.zanivan at gmail.com Tue Mar 17 10:49:05 2015 From: leonardo.zanivan at gmail.com (Leonardo Loch Zanivan) Date: Tue, 17 Mar 2015 14:49:05 +0000 Subject: [keycloak-dev] Social login with user registration disabled Message-ID: I have a requirement in a SaaS application to disable user registration, so only administrators can register new users. Users should be able to login with social providers such as Google+ and Facebook. To allow this, each user could link in his profile. However, when I enable social login, new users are registred automatically to the realm. I don't think that right, since User Registration is disabled. :/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150317/a42224d0/attachment.html From stian at redhat.com Tue Mar 17 10:54:01 2015 From: stian at redhat.com (Stian Thorgersen) Date: Tue, 17 Mar 2015 10:54:01 -0400 (EDT) Subject: [keycloak-dev] Social login with user registration disabled In-Reply-To: References: Message-ID: <653631208.8040344.1426604041092.JavaMail.zimbra@redhat.com> It's not directly linked to user registration. When a user logs in the first time with an external idp the user is automatically provisioned. We can add an option on each identity provider to enable/disable automatically provisioning of users. Please create a jira to request that. ----- Original Message ----- > From: "Leonardo Loch Zanivan" > To: keycloak-dev at lists.jboss.org > Sent: Tuesday, March 17, 2015 3:49:05 PM > Subject: [keycloak-dev] Social login with user registration disabled > > I have a requirement in a SaaS application to disable user registration, so > only administrators can register new users. > > Users should be able to login with social providers such as Google+ and > Facebook. To allow this, each user could link in his profile. > > However, when I enable social login, new users are registred automatically to > the realm. I don't think that right, since User Registration is disabled. > > :/ > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev From bburke at redhat.com Tue Mar 17 10:54:15 2015 From: bburke at redhat.com (Bill Burke) Date: Tue, 17 Mar 2015 10:54:15 -0400 Subject: [keycloak-dev] Social login with user registration disabled In-Reply-To: References: Message-ID: <55084017.4060908@redhat.com> They aren't registered, they are "imported". On 3/17/2015 10:49 AM, Leonardo Loch Zanivan wrote: > I have a requirement in a SaaS application to disable user registration, > so only administrators can register new users. > > Users should be able to login with social providers such as Google+ and > Facebook. To allow this, each user could link in his profile. > > However, when I enable social login, new users are registred > automatically to the realm. I don't think that right, since User > Registration is disabled. > > :/ > > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From bburke at redhat.com Tue Mar 17 10:56:23 2015 From: bburke at redhat.com (Bill Burke) Date: Tue, 17 Mar 2015 10:56:23 -0400 Subject: [keycloak-dev] Social login with user registration disabled In-Reply-To: <653631208.8040344.1426604041092.JavaMail.zimbra@redhat.com> References: <653631208.8040344.1426604041092.JavaMail.zimbra@redhat.com> Message-ID: <55084097.9090200@redhat.com> Ho could we actually implement that. We're dependent on a UserModel existing after the social login. On 3/17/2015 10:54 AM, Stian Thorgersen wrote: > It's not directly linked to user registration. When a user logs in the first time with an external idp the user is automatically provisioned. We can add an option on each identity provider to enable/disable automatically provisioning of users. Please create a jira to request that. > > ----- Original Message ----- >> From: "Leonardo Loch Zanivan" >> To: keycloak-dev at lists.jboss.org >> Sent: Tuesday, March 17, 2015 3:49:05 PM >> Subject: [keycloak-dev] Social login with user registration disabled >> >> I have a requirement in a SaaS application to disable user registration, so >> only administrators can register new users. >> >> Users should be able to login with social providers such as Google+ and >> Facebook. To allow this, each user could link in his profile. >> >> However, when I enable social login, new users are registred automatically to >> the realm. I don't think that right, since User Registration is disabled. >> >> :/ >> >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From stian at redhat.com Tue Mar 17 11:03:48 2015 From: stian at redhat.com (Stian Thorgersen) Date: Tue, 17 Mar 2015 11:03:48 -0400 (EDT) Subject: [keycloak-dev] Social login with user registration disabled In-Reply-To: <55084097.9090200@redhat.com> References: <653631208.8040344.1426604041092.JavaMail.zimbra@redhat.com> <55084097.9090200@redhat.com> Message-ID: <1509513554.8046759.1426604628016.JavaMail.zimbra@redhat.com> ----- Original Message ----- > From: "Bill Burke" > To: keycloak-dev at lists.jboss.org > Sent: Tuesday, March 17, 2015 3:56:23 PM > Subject: Re: [keycloak-dev] Social login with user registration disabled > > Ho could we actually implement that. We're dependent on a UserModel > existing after the social login. If auto-provision was disabled we'd only allow users to login with a identity provider after they have linked the account with a provider. We can (and should) also make it possible for admins to add links (an admin would just need to know the provider-id and the external user-id to do that). Users that try to login without having an account already would just get an error. > > On 3/17/2015 10:54 AM, Stian Thorgersen wrote: > > It's not directly linked to user registration. When a user logs in the > > first time with an external idp the user is automatically provisioned. We > > can add an option on each identity provider to enable/disable > > automatically provisioning of users. Please create a jira to request that. > > > > ----- Original Message ----- > >> From: "Leonardo Loch Zanivan" > >> To: keycloak-dev at lists.jboss.org > >> Sent: Tuesday, March 17, 2015 3:49:05 PM > >> Subject: [keycloak-dev] Social login with user registration disabled > >> > >> I have a requirement in a SaaS application to disable user registration, > >> so > >> only administrators can register new users. > >> > >> Users should be able to login with social providers such as Google+ and > >> Facebook. To allow this, each user could link in his profile. > >> > >> However, when I enable social login, new users are registred automatically > >> to > >> the realm. I don't think that right, since User Registration is disabled. > >> > >> :/ > >> > >> _______________________________________________ > >> keycloak-dev mailing list > >> keycloak-dev at lists.jboss.org > >> https://lists.jboss.org/mailman/listinfo/keycloak-dev > > _______________________________________________ > > keycloak-dev mailing list > > keycloak-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > > -- > Bill Burke > JBoss, a division of Red Hat > http://bill.burkecentral.com > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > From mposolda at redhat.com Tue Mar 17 11:15:25 2015 From: mposolda at redhat.com (Marek Posolda) Date: Tue, 17 Mar 2015 16:15:25 +0100 Subject: [keycloak-dev] Social login with user registration disabled In-Reply-To: <1509513554.8046759.1426604628016.JavaMail.zimbra@redhat.com> References: <653631208.8040344.1426604041092.JavaMail.zimbra@redhat.com> <55084097.9090200@redhat.com> <1509513554.8046759.1426604628016.JavaMail.zimbra@redhat.com> Message-ID: <5508450D.1060306@redhat.com> On 17.3.2015 16:03, Stian Thorgersen wrote: > > ----- Original Message ----- >> From: "Bill Burke" >> To: keycloak-dev at lists.jboss.org >> Sent: Tuesday, March 17, 2015 3:56:23 PM >> Subject: Re: [keycloak-dev] Social login with user registration disabled >> >> Ho could we actually implement that. We're dependent on a UserModel >> existing after the social login. > If auto-provision was disabled we'd only allow users to login with a identity provider after they have linked the account with a provider. We can (and should) also make it possible for admins to add links (an admin would just need to know the provider-id and the external user-id to do that). Users that try to login without having an account already would just get an error. We have already admin REST endpoints to add/get/remove links. However in admin console UI, it's read-only at this moment (admin can see links, but can't add/remove them in UI). Marek > >> On 3/17/2015 10:54 AM, Stian Thorgersen wrote: >>> It's not directly linked to user registration. When a user logs in the >>> first time with an external idp the user is automatically provisioned. We >>> can add an option on each identity provider to enable/disable >>> automatically provisioning of users. Please create a jira to request that. >>> >>> ----- Original Message ----- >>>> From: "Leonardo Loch Zanivan" >>>> To: keycloak-dev at lists.jboss.org >>>> Sent: Tuesday, March 17, 2015 3:49:05 PM >>>> Subject: [keycloak-dev] Social login with user registration disabled >>>> >>>> I have a requirement in a SaaS application to disable user registration, >>>> so >>>> only administrators can register new users. >>>> >>>> Users should be able to login with social providers such as Google+ and >>>> Facebook. To allow this, each user could link in his profile. >>>> >>>> However, when I enable social login, new users are registred automatically >>>> to >>>> the realm. I don't think that right, since User Registration is disabled. >>>> >>>> :/ >>>> >>>> _______________________________________________ >>>> keycloak-dev mailing list >>>> keycloak-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>> _______________________________________________ >>> keycloak-dev mailing list >>> keycloak-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>> >> -- >> Bill Burke >> JBoss, a division of Red Hat >> http://bill.burkecentral.com >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev From leonardo.zanivan at gmail.com Tue Mar 17 12:41:33 2015 From: leonardo.zanivan at gmail.com (Leonardo Loch Zanivan) Date: Tue, 17 Mar 2015 16:41:33 +0000 Subject: [keycloak-dev] Social login with user registration disabled In-Reply-To: <5508450D.1060306@redhat.com> References: <653631208.8040344.1426604041092.JavaMail.zimbra@redhat.com> <55084097.9090200@redhat.com> <1509513554.8046759.1426604628016.JavaMail.zimbra@redhat.com> <5508450D.1060306@redhat.com> Message-ID: Admin management isn't the case. The problem is that social providers automatically "import" new users. The social login buttons should be visible in login, but not add new users. It could be a configuration per provider. On Tue, Mar 17, 2015 at 12:15 PM Marek Posolda wrote: > On 17.3.2015 16:03, Stian Thorgersen wrote: > > > > ----- Original Message ----- > >> From: "Bill Burke" > >> To: keycloak-dev at lists.jboss.org > >> Sent: Tuesday, March 17, 2015 3:56:23 PM > >> Subject: Re: [keycloak-dev] Social login with user registration disabled > >> > >> Ho could we actually implement that. We're dependent on a UserModel > >> existing after the social login. > > If auto-provision was disabled we'd only allow users to login with a > identity provider after they have linked the account with a provider. We > can (and should) also make it possible for admins to add links (an admin > would just need to know the provider-id and the external user-id to do > that). Users that try to login without having an account already would just > get an error. > We have already admin REST endpoints to add/get/remove links. However in > admin console UI, it's read-only at this moment (admin can see links, > but can't add/remove them in UI). > > Marek > > > >> On 3/17/2015 10:54 AM, Stian Thorgersen wrote: > >>> It's not directly linked to user registration. When a user logs in the > >>> first time with an external idp the user is automatically provisioned. > We > >>> can add an option on each identity provider to enable/disable > >>> automatically provisioning of users. Please create a jira to request > that. > >>> > >>> ----- Original Message ----- > >>>> From: "Leonardo Loch Zanivan" > >>>> To: keycloak-dev at lists.jboss.org > >>>> Sent: Tuesday, March 17, 2015 3:49:05 PM > >>>> Subject: [keycloak-dev] Social login with user registration disabled > >>>> > >>>> I have a requirement in a SaaS application to disable user > registration, > >>>> so > >>>> only administrators can register new users. > >>>> > >>>> Users should be able to login with social providers such as Google+ > and > >>>> Facebook. To allow this, each user could link in his profile. > >>>> > >>>> However, when I enable social login, new users are registred > automatically > >>>> to > >>>> the realm. I don't think that right, since User Registration is > disabled. > >>>> > >>>> :/ > >>>> > >>>> _______________________________________________ > >>>> keycloak-dev mailing list > >>>> keycloak-dev at lists.jboss.org > >>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev > >>> _______________________________________________ > >>> keycloak-dev mailing list > >>> keycloak-dev at lists.jboss.org > >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev > >>> > >> -- > >> Bill Burke > >> JBoss, a division of Red Hat > >> http://bill.burkecentral.com > >> _______________________________________________ > >> keycloak-dev mailing list > >> keycloak-dev at lists.jboss.org > >> https://lists.jboss.org/mailman/listinfo/keycloak-dev > >> > > _______________________________________________ > > keycloak-dev mailing list > > keycloak-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150317/c9d941ba/attachment.html From bburke at redhat.com Wed Mar 18 09:16:56 2015 From: bburke at redhat.com (Bill Burke) Date: Wed, 18 Mar 2015 09:16:56 -0400 Subject: [keycloak-dev] Still some broker work to do Message-ID: <55097AC8.1060104@redhat.com> There's still some broker work to do before release. There's one or more blocker bugs and logout doesn't work. The UI is quirky and there is some redundant metadata. -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From mposolda at redhat.com Wed Mar 18 09:45:39 2015 From: mposolda at redhat.com (Marek Posolda) Date: Wed, 18 Mar 2015 14:45:39 +0100 Subject: [keycloak-dev] Still some broker work to do In-Reply-To: <55097AC8.1060104@redhat.com> References: <55097AC8.1060104@redhat.com> Message-ID: <55098183.1060208@redhat.com> I've removed option for enable/disable identity provider per application ( https://issues.jboss.org/browse/KEYCLOAK-1108 ) and fixed facebook, google and twitter examples with keycloak-appliance. I did not test SAML broker though. Now after rebase, I figured that it's not possible to create any identity provider in admin console. Is it the blocker you mean? I am looking at migration stuff now. Marek On 18.3.2015 14:16, Bill Burke wrote: > There's still some broker work to do before release. There's one or > more blocker bugs and logout doesn't work. The UI is quirky and there > is some redundant metadata. > From bburke at redhat.com Wed Mar 18 09:55:27 2015 From: bburke at redhat.com (Bill Burke) Date: Wed, 18 Mar 2015 09:55:27 -0400 Subject: [keycloak-dev] Still some broker work to do In-Reply-To: <55098183.1060208@redhat.com> References: <55097AC8.1060104@redhat.com> <55098183.1060208@redhat.com> Message-ID: <550983CF.9060308@redhat.com> You may want to hold back on the migration stuff for a day. I'm going to remove the IdentityProviderModel.name attribute as it is redundant, rename 'id' to 'alias' and 'internalId' to 'id'. Also going to hardcode the social aliases to 'facebook', 'twitter', etc. and remove this as a field for configuring social. Blocker bug is that logout is totally broken. SAML worked yesterday, not sure after your changes. I'll test and fix any remaining issues with brokers. On 3/18/2015 9:45 AM, Marek Posolda wrote: > I've removed option for enable/disable identity provider per application > ( https://issues.jboss.org/browse/KEYCLOAK-1108 ) and fixed facebook, > google and twitter examples with keycloak-appliance. I did not test SAML > broker though. > > Now after rebase, I figured that it's not possible to create any > identity provider in admin console. Is it the blocker you mean? > > I am looking at migration stuff now. > > Marek > > On 18.3.2015 14:16, Bill Burke wrote: >> There's still some broker work to do before release. There's one or >> more blocker bugs and logout doesn't work. The UI is quirky and there >> is some redundant metadata. >> > -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From mposolda at redhat.com Wed Mar 18 12:01:41 2015 From: mposolda at redhat.com (Marek Posolda) Date: Wed, 18 Mar 2015 17:01:41 +0100 Subject: [keycloak-dev] Still some broker work to do In-Reply-To: <550983CF.9060308@redhat.com> References: <55097AC8.1060104@redhat.com> <55098183.1060208@redhat.com> <550983CF.9060308@redhat.com> Message-ID: <5509A165.2060801@redhat.com> On 18.3.2015 14:55, Bill Burke wrote: > You may want to hold back on the migration stuff for a day. I'm going > to remove the IdentityProviderModel.name attribute as it is redundant, > rename 'id' to 'alias' and 'internalId' to 'id'. Also going to > hardcode the social aliases to 'facebook', 'twitter', etc. and remove > this as a field for configuring social. +1, looks much better than having 3 id fields on IdentityProviderModel. Also how about renaming 'providerId' to 'providerType' ? This points to type (like 'facebook', 'google' etc), so providerId looks a bit misleading to me. Marek > Blocker bug is that logout is totally broken. SAML worked > yesterday, not sure after your changes. I'll test and fix any > remaining issues with brokers. > > On 3/18/2015 9:45 AM, Marek Posolda wrote: >> I've removed option for enable/disable identity provider per application >> ( https://issues.jboss.org/browse/KEYCLOAK-1108 ) and fixed facebook, >> google and twitter examples with keycloak-appliance. I did not test SAML >> broker though. >> >> Now after rebase, I figured that it's not possible to create any >> identity provider in admin console. Is it the blocker you mean? >> >> I am looking at migration stuff now. >> >> Marek >> >> On 18.3.2015 14:16, Bill Burke wrote: >>> There's still some broker work to do before release. There's one or >>> more blocker bugs and logout doesn't work. The UI is quirky and there >>> is some redundant metadata. >>> >> > From stian at redhat.com Thu Mar 19 05:26:48 2015 From: stian at redhat.com (Stian Thorgersen) Date: Thu, 19 Mar 2015 05:26:48 -0400 (EDT) Subject: [keycloak-dev] Still some broker work to do In-Reply-To: <5509A165.2060801@redhat.com> References: <55097AC8.1060104@redhat.com> <55098183.1060208@redhat.com> <550983CF.9060308@redhat.com> <5509A165.2060801@redhat.com> Message-ID: <2072020906.9474925.1426757208672.JavaMail.zimbra@redhat.com> ----- Original Message ----- > From: "Marek Posolda" > To: "Bill Burke" , keycloak-dev at lists.jboss.org > Sent: Wednesday, March 18, 2015 5:01:41 PM > Subject: Re: [keycloak-dev] Still some broker work to do > > On 18.3.2015 14:55, Bill Burke wrote: > > You may want to hold back on the migration stuff for a day. I'm going > > to remove the IdentityProviderModel.name attribute as it is redundant, > > rename 'id' to 'alias' and 'internalId' to 'id'. Also going to > > hardcode the social aliases to 'facebook', 'twitter', etc. and remove > > this as a field for configuring social. > +1, looks much better than having 3 id fields on IdentityProviderModel. > Also how about renaming 'providerId' to 'providerType' ? This points to > type (like 'facebook', 'google' etc), so providerId looks a bit > misleading to me. I'd say leave it as providerId as that's what it's called in ProviderFactory > > Marek > > Blocker bug is that logout is totally broken. SAML worked > > yesterday, not sure after your changes. I'll test and fix any > > remaining issues with brokers. > > > > On 3/18/2015 9:45 AM, Marek Posolda wrote: > >> I've removed option for enable/disable identity provider per application > >> ( https://issues.jboss.org/browse/KEYCLOAK-1108 ) and fixed facebook, > >> google and twitter examples with keycloak-appliance. I did not test SAML > >> broker though. > >> > >> Now after rebase, I figured that it's not possible to create any > >> identity provider in admin console. Is it the blocker you mean? > >> > >> I am looking at migration stuff now. > >> > >> Marek > >> > >> On 18.3.2015 14:16, Bill Burke wrote: > >>> There's still some broker work to do before release. There's one or > >>> more blocker bugs and logout doesn't work. The UI is quirky and there > >>> is some redundant metadata. > >>> > >> > > > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > From stian at redhat.com Thu Mar 19 09:51:38 2015 From: stian at redhat.com (Stian Thorgersen) Date: Thu, 19 Mar 2015 09:51:38 -0400 (EDT) Subject: [keycloak-dev] ClientModel.get/setAllowedClaimsMask Message-ID: <574987363.9595042.1426773098992.JavaMail.zimbra@redhat.com> Am I correct in thinking that these are no longer used and should be removed? From stian at redhat.com Thu Mar 19 09:54:36 2015 From: stian at redhat.com (Stian Thorgersen) Date: Thu, 19 Mar 2015 09:54:36 -0400 (EDT) Subject: [keycloak-dev] Importing json from 1.1.0 into 1.2.0 In-Reply-To: <1716559550.9595486.1426773150457.JavaMail.zimbra@redhat.com> Message-ID: <2040774326.9596557.1426773276643.JavaMail.zimbra@redhat.com> I came up with a simple solution to import json from 1.1.0 to 1.2.0. In RealmRepresentation and UserRepresentation the old social properties are re-added with a @Deprecated. In RepresentationToModel the first thing that's done is to convert these to the new identity brokering properties. For details see https://github.com/keycloak/keycloak/commit/8a38597b3acdb568d794d1d424961c98198a5361 If we do the same for claims to protocol-mappers we should be fine with importing json representations from 1.1.0.Final into 1.2.0.Beta1. From mposolda at redhat.com Thu Mar 19 15:36:36 2015 From: mposolda at redhat.com (Marek Posolda) Date: Thu, 19 Mar 2015 20:36:36 +0100 Subject: [keycloak-dev] Importing json from 1.1.0 into 1.2.0 In-Reply-To: <2040774326.9596557.1426773276643.JavaMail.zimbra@redhat.com> References: <2040774326.9596557.1426773276643.JavaMail.zimbra@redhat.com> Message-ID: <550B2544.9050505@redhat.com> On 19.3.2015 14:54, Stian Thorgersen wrote: > I came up with a simple solution to import json from 1.1.0 to 1.2.0. > > In RealmRepresentation and UserRepresentation the old social properties are re-added with a @Deprecated. In RepresentationToModel the first thing that's done is to convert these to the new identity brokering properties. For details see https://github.com/keycloak/keycloak/commit/8a38597b3acdb568d794d1d424961c98198a5361 > > If we do the same for claims to protocol-mappers we should be fine with importing json representations from 1.1.0.Final into 1.2.0.Beta1. I've pushed the migration for mongo and added MigrationUtils with method for convert old claimsMask to corresponding protocol mappers. I hope it can be reused for JSON and jpa as well. I've added separate module "mongo-update" similarly like we have for JPA as it needs access to keycloak-services (LoginProtocolFactory and protocol mappers are there). For the migration I did: - Migration of "social" to identity providers - Migration of social links to federated identities for users - Migration of claims mask to protocol mappers - Adding new admin roles for "view-identity-providers" and "manage-identity-providers" (This is causing KEYCLOAK-1078) - Adding accessTokenCodeLoginTimeout to existing clients with 1800 seconds Did I miss something? I will start on liquibase tomorrow, will need to fix databases first as many of them are failing in jenkins now.. Will revisit migration again after final model changes related to identity brokering are pushed. Marek > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev From leonardo.zanivan at gmail.com Thu Mar 19 19:42:02 2015 From: leonardo.zanivan at gmail.com (Leonardo Loch Zanivan) Date: Thu, 19 Mar 2015 23:42:02 +0000 Subject: [keycloak-dev] Social login with user registration disabled In-Reply-To: References: <653631208.8040344.1426604041092.JavaMail.zimbra@redhat.com> <55084097.9090200@redhat.com> <1509513554.8046759.1426604628016.JavaMail.zimbra@redhat.com> <5508450D.1060306@redhat.com> Message-ID: JIRA ticket: https://issues.jboss.org/browse/KEYCLOAK-1119 On Tue, Mar 17, 2015 at 1:41 PM Leonardo Loch Zanivan < leonardo.zanivan at gmail.com> wrote: > Admin management isn't the case. > > The problem is that social providers automatically "import" new users. > > The social login buttons should be visible in login, but not add new users. > > It could be a configuration per provider. > > On Tue, Mar 17, 2015 at 12:15 PM Marek Posolda > wrote: > >> On 17.3.2015 16:03, Stian Thorgersen wrote: >> > >> > ----- Original Message ----- >> >> From: "Bill Burke" >> >> To: keycloak-dev at lists.jboss.org >> >> Sent: Tuesday, March 17, 2015 3:56:23 PM >> >> Subject: Re: [keycloak-dev] Social login with user registration >> disabled >> >> >> >> Ho could we actually implement that. We're dependent on a UserModel >> >> existing after the social login. >> > If auto-provision was disabled we'd only allow users to login with a >> identity provider after they have linked the account with a provider. We >> can (and should) also make it possible for admins to add links (an admin >> would just need to know the provider-id and the external user-id to do >> that). Users that try to login without having an account already would just >> get an error. >> We have already admin REST endpoints to add/get/remove links. However in >> admin console UI, it's read-only at this moment (admin can see links, >> but can't add/remove them in UI). >> >> Marek >> > >> >> On 3/17/2015 10:54 AM, Stian Thorgersen wrote: >> >>> It's not directly linked to user registration. When a user logs in the >> >>> first time with an external idp the user is automatically >> provisioned. We >> >>> can add an option on each identity provider to enable/disable >> >>> automatically provisioning of users. Please create a jira to request >> that. >> >>> >> >>> ----- Original Message ----- >> >>>> From: "Leonardo Loch Zanivan" >> >>>> To: keycloak-dev at lists.jboss.org >> >>>> Sent: Tuesday, March 17, 2015 3:49:05 PM >> >>>> Subject: [keycloak-dev] Social login with user registration disabled >> >>>> >> >>>> I have a requirement in a SaaS application to disable user >> registration, >> >>>> so >> >>>> only administrators can register new users. >> >>>> >> >>>> Users should be able to login with social providers such as Google+ >> and >> >>>> Facebook. To allow this, each user could link in his profile. >> >>>> >> >>>> However, when I enable social login, new users are registred >> automatically >> >>>> to >> >>>> the realm. I don't think that right, since User Registration is >> disabled. >> >>>> >> >>>> :/ >> >>>> >> >>>> _______________________________________________ >> >>>> keycloak-dev mailing list >> >>>> keycloak-dev at lists.jboss.org >> >>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> >>> _______________________________________________ >> >>> keycloak-dev mailing list >> >>> keycloak-dev at lists.jboss.org >> >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> >>> >> >> -- >> >> Bill Burke >> >> JBoss, a division of Red Hat >> >> http://bill.burkecentral.com >> >> _______________________________________________ >> >> keycloak-dev mailing list >> >> keycloak-dev at lists.jboss.org >> >> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> >> >> > _______________________________________________ >> > keycloak-dev mailing list >> > keycloak-dev at lists.jboss.org >> > https://lists.jboss.org/mailman/listinfo/keycloak-dev >> >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150319/a1451906/attachment-0001.html From stian at redhat.com Fri Mar 20 00:24:09 2015 From: stian at redhat.com (Stian Thorgersen) Date: Fri, 20 Mar 2015 00:24:09 -0400 (EDT) Subject: [keycloak-dev] Importing json from 1.1.0 into 1.2.0 In-Reply-To: <550B2544.9050505@redhat.com> References: <2040774326.9596557.1426773276643.JavaMail.zimbra@redhat.com> <550B2544.9050505@redhat.com> Message-ID: <1352723478.152949.1426825449003.JavaMail.zimbra@redhat.com> ----- Original Message ----- > From: "Marek Posolda" > To: keycloak-dev at lists.jboss.org > Sent: Thursday, 19 March, 2015 8:36:36 PM > Subject: Re: [keycloak-dev] Importing json from 1.1.0 into 1.2.0 > > On 19.3.2015 14:54, Stian Thorgersen wrote: > > I came up with a simple solution to import json from 1.1.0 to 1.2.0. > > > > In RealmRepresentation and UserRepresentation the old social properties are > > re-added with a @Deprecated. In RepresentationToModel the first thing > > that's done is to convert these to the new identity brokering properties. > > For details see > > https://github.com/keycloak/keycloak/commit/8a38597b3acdb568d794d1d424961c98198a5361 > > > > If we do the same for claims to protocol-mappers we should be fine with > > importing json representations from 1.1.0.Final into 1.2.0.Beta1. > I've pushed the migration for mongo and added MigrationUtils with method > for convert old claimsMask to corresponding protocol mappers. I hope it > can be reused for JSON and jpa as well. I've added separate module > "mongo-update" similarly like we have for JPA as it needs access to > keycloak-services (LoginProtocolFactory and protocol mappers are there). > > For the migration I did: > - Migration of "social" to identity providers > - Migration of social links to federated identities for users > - Migration of claims mask to protocol mappers > - Adding new admin roles for "view-identity-providers" and > "manage-identity-providers" (This is causing KEYCLOAK-1078) > - Adding accessTokenCodeLoginTimeout to existing clients with 1800 seconds > > Did I miss something? Not that I can think of at least > > I will start on liquibase tomorrow, will need to fix databases first as > many of them are failing in jenkins now.. > > Will revisit migration again after final model changes related to > identity brokering are pushed. > > Marek > > _______________________________________________ > > keycloak-dev mailing list > > keycloak-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > From stian at redhat.com Fri Mar 20 09:53:07 2015 From: stian at redhat.com (Stian Thorgersen) Date: Fri, 20 Mar 2015 09:53:07 -0400 (EDT) Subject: [keycloak-dev] Deploy theme as module and simplified creating theme for embedding In-Reply-To: <1925367268.802676.1426857301508.JavaMail.zimbra@redhat.com> Message-ID: <1708548371.848956.1426859587613.JavaMail.zimbra@redhat.com> I've introduce the concept of a theme packaged as a JAR. This makes it possible to deploy a theme as a module (which is nice for domain mode) and simplifies creating themes when KC is embedded into other projects. A theme JAR consists of: * META-INF/keycloak-themes.json A description of what themes are included in the jar * theme// Templates, resources, etc as before Basically there's no longer any need to implement your own theme provider just to bundle a theme as a jar :) While doing this I realised that the structure of: * / Is wrong! It should be: * / Anyone have an objection to changing that? The reasoning is that it will be common to create a theme of different variants and having the theme name as the root makes it easier to copy to standalone/configuration/themes as well as groups everything for a theme into one place. From bburke at redhat.com Fri Mar 20 09:57:58 2015 From: bburke at redhat.com (Bill Burke) Date: Fri, 20 Mar 2015 09:57:58 -0400 Subject: [keycloak-dev] Deploy theme as module and simplified creating theme for embedding In-Reply-To: <1708548371.848956.1426859587613.JavaMail.zimbra@redhat.com> References: <1708548371.848956.1426859587613.JavaMail.zimbra@redhat.com> Message-ID: <550C2766.9090502@redhat.com> +1. I know it was a pain creating the theme for Aerogear quickstart. Also thought the directory structure was weird, so +1 to that too. On 3/20/2015 9:53 AM, Stian Thorgersen wrote: > I've introduce the concept of a theme packaged as a JAR. This makes it possible to deploy a theme as a module (which is nice for domain mode) and simplifies creating themes when KC is embedded into other projects. > > A theme JAR consists of: > > * META-INF/keycloak-themes.json A description of what themes are included in the jar > * theme// Templates, resources, etc as before > > Basically there's no longer any need to implement your own theme provider just to bundle a theme as a jar :) > > While doing this I realised that the structure of: > > * / > > Is wrong! It should be: > > * / > > Anyone have an objection to changing that? The reasoning is that it will be common to create a theme of different variants and having the theme name as the root makes it easier to copy to standalone/configuration/themes as well as groups everything for a theme into one place. > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From bburke at redhat.com Fri Mar 20 10:21:01 2015 From: bburke at redhat.com (Bill Burke) Date: Fri, 20 Mar 2015 10:21:01 -0400 Subject: [keycloak-dev] Events for logout Message-ID: <550C2CCD.3010002@redhat.com> Logout can now span multiple requests and between multiple classes, so I'm not sure what to do with Event. SHould the logout event be created only when it is actually finished (success or error)? Or should an event be created at each step of the logout? -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From lukas at fryc.eu Fri Mar 20 10:28:43 2015 From: lukas at fryc.eu (=?UTF-8?B?THVrw6HFoSBGcnnEjQ==?=) Date: Fri, 20 Mar 2015 14:28:43 +0000 Subject: [keycloak-dev] Deploy theme as module and simplified creating theme for embedding In-Reply-To: <550C2766.9090502@redhat.com> References: <1708548371.848956.1426859587613.JavaMail.zimbra@redhat.com> <550C2766.9090502@redhat.com> Message-ID: Hey Stian, I could provide Ionic Keycloak Theme this way: https://github.com/lfryc/keycloak-ionic-theme ~ Lukas p? 20. 3. 2015 v 14:58 odes?latel Bill Burke napsal: > +1. I know it was a pain creating the theme for Aerogear quickstart. > Also thought the directory structure was weird, so +1 to that too. > > On 3/20/2015 9:53 AM, Stian Thorgersen wrote: > > I've introduce the concept of a theme packaged as a JAR. This makes it > possible to deploy a theme as a module (which is nice for domain mode) and > simplifies creating themes when KC is embedded into other projects. > > > > A theme JAR consists of: > > > > * META-INF/keycloak-themes.json A description of what themes > are included in the jar > > * theme// Templates, resources, etc as > before > > > > Basically there's no longer any need to implement your own theme > provider just to bundle a theme as a jar :) > > > > While doing this I realised that the structure of: > > > > * / > > > > Is wrong! It should be: > > > > * / > > > > Anyone have an objection to changing that? The reasoning is that it will > be common to create a theme of different variants and having the theme name > as the root makes it easier to copy to standalone/configuration/themes as > well as groups everything for a theme into one place. > > _______________________________________________ > > keycloak-dev mailing list > > keycloak-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > > -- > Bill Burke > JBoss, a division of Red Hat > http://bill.burkecentral.com > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150320/a9db2f43/attachment.html From lukas at fryc.eu Fri Mar 20 10:35:31 2015 From: lukas at fryc.eu (=?UTF-8?B?THVrw6HFoSBGcnnEjQ==?=) Date: Fri, 20 Mar 2015 14:35:31 +0000 Subject: [keycloak-dev] Deploy theme as module and simplified creating theme for embedding In-Reply-To: References: <1708548371.848956.1426859587613.JavaMail.zimbra@redhat.com> <550C2766.9090502@redhat.com> Message-ID: Btw I wanted to start with +1 cool idea :-) p? 20. 3. 2015 v 15:28 odes?latel Luk?? Fry? napsal: > Hey Stian, > > I could provide Ionic Keycloak Theme this way: > https://github.com/lfryc/keycloak-ionic-theme > > ~ Lukas > > > p? 20. 3. 2015 v 14:58 odes?latel Bill Burke napsal: > > +1. I know it was a pain creating the theme for Aerogear quickstart. >> Also thought the directory structure was weird, so +1 to that too. >> >> On 3/20/2015 9:53 AM, Stian Thorgersen wrote: >> > I've introduce the concept of a theme packaged as a JAR. This makes it >> possible to deploy a theme as a module (which is nice for domain mode) and >> simplifies creating themes when KC is embedded into other projects. >> > >> > A theme JAR consists of: >> > >> > * META-INF/keycloak-themes.json A description of what themes >> are included in the jar >> > * theme// Templates, resources, etc as >> before >> > >> > Basically there's no longer any need to implement your own theme >> provider just to bundle a theme as a jar :) >> > >> > While doing this I realised that the structure of: >> > >> > * / >> > >> > Is wrong! It should be: >> > >> > * / >> > >> > Anyone have an objection to changing that? The reasoning is that it >> will be common to create a theme of different variants and having the theme >> name as the root makes it easier to copy to standalone/configuration/ >> themes as well as groups everything for a theme into one place. >> > _______________________________________________ >> > keycloak-dev mailing list >> > keycloak-dev at lists.jboss.org >> > https://lists.jboss.org/mailman/listinfo/keycloak-dev >> > >> >> -- >> Bill Burke >> JBoss, a division of Red Hat >> http://bill.burkecentral.com >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150320/6c119917/attachment.html From jboss.atomicknight at xoxy.net Fri Mar 20 16:50:03 2015 From: jboss.atomicknight at xoxy.net (jboss.atomicknight at xoxy.net) Date: Fri, 20 Mar 2015 16:50:03 -0400 Subject: [keycloak-dev] Future direction of PicketLink SAML capabilities post-merge Message-ID: Hi there, I'm writing with regard to the announcement about PicketLink merging into Keycloak, particularly as it pertains to the SAML capabilities and APIs currently offered by PicketLink today. >From what I understand, the focus of Keycloak has historically been to provide a standalone application/appliance that runs "out of process" relative to an application utilizing those capabilities. In contrast, PicketLink has been focused on lower-level APIs that are intended to be integrated "in process" relative to the application. Is this understanding correct? If so, will the combined project continue to support both approaches? More specifically, my company has developed an application that relies on PicketLink's SAML APIs to provide SAML support as part of a larger security subsystem. This uses the SPFilter class and the associated SAML2Handler classes to handle SAML messages, but adapts the inputs/outputs to plug into the existing security infrastructure (not built using PicketLink). Going forward, will these parts of the merged codebase still be supported as first class Java APIs? Or will they be replaced by web service APIs or other equivalent endpoints? Thanks in advance for your help. -Abraham -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150320/a93fbcef/attachment-0001.html From bburke at redhat.com Fri Mar 20 17:24:55 2015 From: bburke at redhat.com (Bill Burke) Date: Fri, 20 Mar 2015 17:24:55 -0400 Subject: [keycloak-dev] Future direction of PicketLink SAML capabilities post-merge In-Reply-To: References: Message-ID: <550C9027.2020604@redhat.com> We will still continue to have a SAML SP adapter, but the APIs/SPIs will change. We will have an SPFilter as well as tomcat, jetty, eap 6.x, and Wildfly integrated adapters for SAML. On 3/20/2015 4:50 PM, jboss.atomicknight at xoxy.net wrote: > Hi there, > > I'm writing with regard to the announcement about PicketLink merging > into Keycloak, particularly as it pertains to the SAML capabilities and > APIs currently offered by PicketLink today. > > From what I understand, the focus of Keycloak has historically been to > provide a standalone application/appliance that runs "out of process" > relative to an application utilizing those capabilities. In contrast, > PicketLink has been focused on lower-level APIs that are intended to be > integrated "in process" relative to the application. Is this > understanding correct? If so, will the combined project continue to > support both approaches? > > More specifically, my company has developed an application that relies > on PicketLink's SAML APIs to provide SAML support as part of a larger > security subsystem. This uses the SPFilter class and the associated > SAML2Handler classes to handle SAML messages, but adapts the > inputs/outputs to plug into the existing security infrastructure (not > built using PicketLink). Going forward, will these parts of the merged > codebase still be supported as first class Java APIs? Or will they be > replaced by web service APIs or other equivalent endpoints? > > Thanks in advance for your help. > > -Abraham > > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From jboss.atomicknight at xoxy.net Fri Mar 20 17:50:49 2015 From: jboss.atomicknight at xoxy.net (jboss.atomicknight at xoxy.net) Date: Fri, 20 Mar 2015 17:50:49 -0400 Subject: [keycloak-dev] Future direction of PicketLink SAML capabilities post-merge In-Reply-To: <550C9027.2020604@redhat.com> References: <550C9027.2020604@redhat.com> Message-ID: Thanks for the prompt response! Looking forward to the new improvements! -Abraham On Fri, Mar 20, 2015 at 5:24 PM, Bill Burke - bburke at redhat.com wrote: > > We will still continue to have a SAML SP adapter, but the APIs/SPIs will > change. We will have an SPFilter as well as tomcat, jetty, eap 6.x, and > Wildfly integrated adapters for SAML. > > On 3/20/2015 4:50 PM, jboss.atomicknight at xoxy.net wrote: > > Hi there, > > > > I'm writing with regard to the announcement about PicketLink merging > > into Keycloak, particularly as it pertains to the SAML capabilities and > > APIs currently offered by PicketLink today. > > > > From what I understand, the focus of Keycloak has historically been to > > provide a standalone application/appliance that runs "out of process" > > relative to an application utilizing those capabilities. In contrast, > > PicketLink has been focused on lower-level APIs that are intended to be > > integrated "in process" relative to the application. Is this > > understanding correct? If so, will the combined project continue to > > support both approaches? > > > > More specifically, my company has developed an application that relies > > on PicketLink's SAML APIs to provide SAML support as part of a larger > > security subsystem. This uses the SPFilter class and the associated > > SAML2Handler classes to handle SAML messages, but adapts the > > inputs/outputs to plug into the existing security infrastructure (not > > built using PicketLink). Going forward, will these parts of the merged > > codebase still be supported as first class Java APIs? Or will they be > > replaced by web service APIs or other equivalent endpoints? > > > > Thanks in advance for your help. > > > > -Abraham > > > > > > _______________________________________________ > > keycloak-dev mailing list > > keycloak-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > > -- > Bill Burke > JBoss, a division of Red Hat > http://bill.burkecentral.com > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > From bburke at redhat.com Fri Mar 20 19:07:02 2015 From: bburke at redhat.com (Bill Burke) Date: Fri, 20 Mar 2015 19:07:02 -0400 Subject: [keycloak-dev] identity broker changes Message-ID: <550CA816.2030906@redhat.com> SPI has changed to support logout and multiple callback endpoints (i.e. keycloak oidc chaining will require a logout callback). This SPI is quite complex, so I don't think we want to expose this to users. I'm not very happy with it, but I'm not sure how to improve it yet. What works now: * If logged in via a SAML broker, a keycloak initiated browser logout will log out of the SAML broker too. What do I still need to do: * Make "UPdate profile" false by default. * Improve saml admin console page. * Implement OIDC broker keycloak initiated browser logout. * Implement OIDC logout endpoint so that I can test OIDC brokering with Keycloak as a parent. * Implement SAML backchannel logout where the parent IDP sends a backchannel logout request. * Create a new "Keycloak OIDC" provider which extends OIDC and adds keycloak extensions like logout. * Review to make sure error handling is correct. So, still a lot to do, but I'm at a milestone. -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From kontakt at michalchoinski.pl Sat Mar 21 16:18:23 2015 From: kontakt at michalchoinski.pl (=?UTF-8?B?TWljaGHFgiBDaG9pxYRza2k=?=) Date: Sat, 21 Mar 2015 21:18:23 +0100 Subject: [keycloak-dev] gsoc 2015, Certificate Management Message-ID: <550DD20F.9050709@michalchoinski.pl> Hi, I would like to participate in "Keyloak - Certificate Management" project. I have already submitted my proposal on Google melange and, to be honest, it is the only proposal I have submitted. It is really important to me to be accepted into this particular project. I wrote something about myself (my studies, skills etc.) in my submission, so I think writing it here again would be a distracting redundancy for you. You can also find some information about my skills and experience on linkedIn web portal. My profile is available at http://pl.linkedin.com/in/michalchoinski I would like to ask you, what should I do to increase my chances? Can I fix a bug? Can you assign such a task to me? Unfortunately, there is a little problem with my availability within next week. I have swimming competition at the weekend and I work midweek. Generally, I have not a lot of time due to work and studies, but If I find out that I am accepted into project, I will immediately stop working and start to getting involved more intensively. Of course I know that is the next stage - first I have to be accepted. So my question is: what you want me to do to get hired? :) Best regards, Micha? Choi?ski From prakhashsiva21 at gmail.com Sun Mar 22 09:27:33 2015 From: prakhashsiva21 at gmail.com (Prakhash siva) Date: Sun, 22 Mar 2015 18:57:33 +0530 Subject: [keycloak-dev] Changing database for maintaining user history Message-ID: Hi all, I have a issue related to how the KC database works. According to my understanding it is a sqlite kind of database and whenever I run the server it get initiates. so when logging the events with the purpose of detecting intrusions is it 100% possible to use the inbuilt database of KC. for example If I'm going to maintain a history for a specific client to identify his activities it can't be locally tested. So its trivial that I need to change the database. So I need to get to know if I change the database to mongo will the same re initialization process will happen? and where I need to work for this Thanks -- *Sivakumar Prakhash* *Undergraduate* *Computer Science & Engineering* *University of Moratuwa.* -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150322/81adb017/attachment.html From stian at redhat.com Mon Mar 23 01:53:30 2015 From: stian at redhat.com (Stian Thorgersen) Date: Mon, 23 Mar 2015 01:53:30 -0400 (EDT) Subject: [keycloak-dev] Events for logout In-Reply-To: <550C2CCD.3010002@redhat.com> References: <550C2CCD.3010002@redhat.com> Message-ID: <375141412.2307733.1427090010956.JavaMail.zimbra@redhat.com> ----- Original Message ----- > From: "Bill Burke" > To: keycloak-dev at lists.jboss.org > Sent: Friday, 20 March, 2015 3:21:01 PM > Subject: [keycloak-dev] Events for logout > > Logout can now span multiple requests and between multiple classes, so > I'm not sure what to do with Event. SHould the logout event be created > only when it is actually finished (success or error)? Or should an > event be created at each step of the logout? With the logout becoming pretty complex (external idp, backchannel/frontchannel logout, etc) it would probably be good to have logout initiated and logout success/error. Don't think we need one for each step, but instead we could add details to the logout success/error on what apps where logged-out? > -- > Bill Burke > JBoss, a division of Red Hat > http://bill.burkecentral.com > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > From stian at redhat.com Mon Mar 23 02:38:57 2015 From: stian at redhat.com (Stian Thorgersen) Date: Mon, 23 Mar 2015 02:38:57 -0400 (EDT) Subject: [keycloak-dev] gsoc 2015, Certificate Management In-Reply-To: <550DD20F.9050709@michalchoinski.pl> References: <550DD20F.9050709@michalchoinski.pl> Message-ID: <491625021.2321079.1427092737530.JavaMail.zimbra@redhat.com> ----- Original Message ----- > From: "Micha? Choi?ski" > To: keycloak-dev at lists.jboss.org > Sent: Saturday, 21 March, 2015 9:18:23 PM > Subject: [keycloak-dev] gsoc 2015, Certificate Management > > Hi, > > I would like to participate in "Keyloak - Certificate Management" > project. I have already submitted my proposal on Google melange and, to > be honest, it is the only proposal I have submitted. It is really > important to me to be accepted into this particular project. I wrote > something about myself (my studies, skills etc.) in my submission, so I > think writing it here again would be a distracting redundancy for you. > You can also find some information about my skills and experience on > linkedIn web portal. My profile is available at > http://pl.linkedin.com/in/michalchoinski > I would like to ask you, what should I do to increase my chances? > Can I fix a bug? Can you assign such a task to me? Unfortunately, there > is a little problem with my availability within next week. I have > swimming competition at the weekend and I work midweek. Generally, I > have not a lot of time due to work and studies, but If I find out that I > am accepted into project, I will immediately stop working and start to > getting involved more intensively. Of course I know that is the next > stage - first I have to be accepted. So my question is: what you want me > to do to get hired? :) Evidence of your capability to understand Keycloak documentation and source would be good, and doing a PR for a simple feature or a bug would certainly be a good way to achieve that. Have a look at https://issues.jboss.org/browse/KEYCLOAK and see if there's any that you believe you'd be able to do. Please, once you've selected one let me know what you're planning before spending days doing it, so I can confirm that it's a valid issue and that no-one else is working on it. > > Best regards, > Micha? Choi?ski > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev From mposolda at redhat.com Mon Mar 23 03:27:25 2015 From: mposolda at redhat.com (Marek Posolda) Date: Mon, 23 Mar 2015 08:27:25 +0100 Subject: [keycloak-dev] Changing database for maintaining user history In-Reply-To: References: Message-ID: <550FC05D.8040604@redhat.com> Hi, the database is re-created after each start just if you're using in-memory H2 database. This is the case by default if you're using KeycloakServer from testsuite for development. You can change it to use either File-based H2 (this is used by keycloak-appliance distribution by default) or point to some other DB like MySQL for example. To change this, you just need to add few system properties when running server. See this file for details of what needs to be changed: https://github.com/keycloak/keycloak/blob/master/testsuite/integration/src/main/resources/META-INF/keycloak-server.json I am personally usually using mongo for development with KeycloakServer. Data are persistent among server restarts, so DB doesn't need to be initialized after restart and server startup usually takes about 2 seconds on my laptop. Marek On 22.3.2015 14:27, Prakhash siva wrote: > Hi all, > I have a issue related to how the KC database works. According to my > understanding it is a sqlite kind of database and whenever I run the > server it get initiates. so when logging the events with the purpose > of detecting intrusions is it 100% possible to use the inbuilt > database of KC. > > for example If I'm going to maintain a history for a specific client > to identify his activities it can't be locally tested. So its trivial > that I need to change the database. So I need to get to know if I > change the database to mongo will the same re initialization process > will happen? and where I need to work for this > > Thanks > > -- > /*Sivakumar Prakhash*/ > /*Undergraduate*/ > /*Computer Science & Engineering*/ > /*University of Moratuwa.*/ > > > > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150323/8fdcdbfb/attachment-0001.html From gerbermichi at me.com Mon Mar 23 05:08:55 2015 From: gerbermichi at me.com (Michael Gerber) Date: Mon, 23 Mar 2015 09:08:55 +0000 (GMT) Subject: [keycloak-dev] Internationalization Message-ID: <848995e1-af96-44d4-beb7-ca196ef58e55@me.com> Hi all @all developers Please make sure that you use ISO-8859-1 encoding for your language property files (messages_en.properties and messages_de.properties) @Bill Can you have a look at the claims and roles internationalization of the login-oauth-grant.ftl page.? If you want to enable internationalization for a value than you have to enter it like that:?${username} Is that ok? Do we want to enable i18n for the default roles and claims? @Stian There are a few minor gui issues: - Registration page with a screen resolution of 768*1024 - Login page in German with a screen resolution of 1024*768 Should I solve this kind of issues, even if they are not directly related to the i18n task? Michael -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150323/4f43322c/attachment.html From stian at redhat.com Mon Mar 23 05:51:38 2015 From: stian at redhat.com (Stian Thorgersen) Date: Mon, 23 Mar 2015 05:51:38 -0400 (EDT) Subject: [keycloak-dev] Internationalization In-Reply-To: <848995e1-af96-44d4-beb7-ca196ef58e55@me.com> References: <848995e1-af96-44d4-beb7-ca196ef58e55@me.com> Message-ID: <857811449.2567620.1427104298336.JavaMail.zimbra@redhat.com> ----- Original Message ----- > From: "Michael Gerber" > To: keycloak-dev at lists.jboss.org > Sent: Monday, 23 March, 2015 10:08:55 AM > Subject: [keycloak-dev] Internationalization > > Hi all > > @all developers > Please make sure that you use ISO-8859-1 encoding for your language property > files (messages_en.properties and messages_de.properties) > > @Bill > Can you have a look at the claims and roles internationalization of the > login-oauth-grant.ftl page. > If you want to enable internationalization for a value than you have to enter > it like that: ${username} > Is that ok? > Do we want to enable i18n for the default roles and claims? Yes and yes > > @Stian > There are a few minor gui issues: > - Registration page with a screen resolution of 768*1024 > - Login page in German with a screen resolution of 1024*768 > Should I solve this kind of issues, even if they are not directly related to > the i18n task? Sure, but create a JIRA and separate PR please > > Michael > > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev From ssilvert at redhat.com Mon Mar 23 08:22:10 2015 From: ssilvert at redhat.com (Stan Silvert) Date: Mon, 23 Mar 2015 08:22:10 -0400 Subject: [keycloak-dev] Changing database for maintaining user history In-Reply-To: <550FC05D.8040604@redhat.com> References: <550FC05D.8040604@redhat.com> Message-ID: <55100572.2000203@redhat.com> On 3/23/2015 3:27 AM, Marek Posolda wrote: > Hi, > > the database is re-created after each start just if you're using > in-memory H2 database. This is the case by default if you're using > KeycloakServer from testsuite for development. You can change it to > use either File-based H2 (this is used by keycloak-appliance > distribution by default) or point to some other DB like MySQL for > example. > > To change this, you just need to add few system properties when > running server. See this file for details of what needs to be changed: > https://github.com/keycloak/keycloak/blob/master/testsuite/integration/src/main/resources/META-INF/keycloak-server.json > > I am personally usually using mongo for development with > KeycloakServer. Data are persistent among server restarts, so DB > doesn't need to be initialized after restart and server startup > usually takes about 2 seconds on my laptop. I'm doing the same thing with the file persistence. The file is written to the /target directory. After a test, it should be about 17K if it was cleaned up properly. If not, you immediately know something went wrong with the test. > > Marek > > On 22.3.2015 14:27, Prakhash siva wrote: >> Hi all, >> I have a issue related to how the KC database works. According to my >> understanding it is a sqlite kind of database and whenever I run the >> server it get initiates. so when logging the events with the purpose >> of detecting intrusions is it 100% possible to use the inbuilt >> database of KC. >> >> for example If I'm going to maintain a history for a specific client >> to identify his activities it can't be locally tested. So its trivial >> that I need to change the database. So I need to get to know if I >> change the database to mongo will the same re initialization process >> will happen? and where I need to work for this >> >> Thanks >> >> -- >> /*Sivakumar Prakhash*/ >> /*Undergraduate*/ >> /*Computer Science & Engineering*/ >> /*University of Moratuwa.*/ >> >> >> >> >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150323/23c5b243/attachment.html From bburke at redhat.com Mon Mar 23 10:10:56 2015 From: bburke at redhat.com (Bill Burke) Date: Mon, 23 Mar 2015 10:10:56 -0400 Subject: [keycloak-dev] Shouldn't external token by stored in UserSession? Message-ID: <55101EF0.2070900@redhat.com> Why is the external token stored in actual user storage (FederatedIdentityModel). The token is really something specific to the UserSession and belongs there. Also, there may not be one single item for "external token". For example, OIDC has both an IDToken and access token. The IDToken is actually used to perform a logout according to the OIDC logout profile. Right now, our code is storing the AccessTokenResponse for OIDC, and the entire login response for SAML. -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From prakhashsiva21 at gmail.com Mon Mar 23 12:51:37 2015 From: prakhashsiva21 at gmail.com (Prakhash siva) Date: Mon, 23 Mar 2015 22:21:37 +0530 Subject: [keycloak-dev] Changing database for maintaining user history In-Reply-To: <55100572.2000203@redhat.com> References: <550FC05D.8040604@redhat.com> <55100572.2000203@redhat.com> Message-ID: I'll try it with the Mongo. I'll contact you if there is any trouble. please be with me until I catch the correct path to move through. then I can keep going thanks On Mon, Mar 23, 2015 at 5:52 PM, Stan Silvert wrote: > On 3/23/2015 3:27 AM, Marek Posolda wrote: > > Hi, > > the database is re-created after each start just if you're using in-memory > H2 database. This is the case by default if you're using KeycloakServer > from testsuite for development. You can change it to use either File-based > H2 (this is used by keycloak-appliance distribution by default) or point to > some other DB like MySQL for example. > > To change this, you just need to add few system properties when running > server. See this file for details of what needs to be changed: > https://github.com/keycloak/keycloak/blob/master/testsuite/integration/src/main/resources/META-INF/keycloak-server.json > > I am personally usually using mongo for development with KeycloakServer. > Data are persistent among server restarts, so DB doesn't need to be > initialized after restart and server startup usually takes about 2 seconds > on my laptop. > > I'm doing the same thing with the file persistence. The file is written > to the /target directory. After a test, it should be about 17K if it was > cleaned up properly. If not, you immediately know something went wrong > with the test. > > > Marek > > On 22.3.2015 14:27, Prakhash siva wrote: > > Hi all, > I have a issue related to how the KC database works. According to my > understanding it is a sqlite kind of database and whenever I run the server > it get initiates. so when logging the events with the purpose of detecting > intrusions is it 100% possible to use the inbuilt database of KC. > > for example If I'm going to maintain a history for a specific client to > identify his activities it can't be locally tested. So its trivial that I > need to change the database. So I need to get to know if I change the > database to mongo will the same re initialization process will happen? and > where I need to work for this > > Thanks > > -- > *Sivakumar Prakhash* > *Undergraduate* > *Computer Science & Engineering* > *University of Moratuwa.* > > > > > _______________________________________________ > keycloak-dev mailing listkeycloak-dev at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-dev > > > > > _______________________________________________ > keycloak-dev mailing listkeycloak-dev at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-dev > > > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > -- *Sivakumar Prakhash* *Undergraduate* *Computer Science & Engineering* *University of Moratuwa.* -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150323/16691021/attachment-0001.html From bartosz.janota at gmail.com Mon Mar 23 14:00:35 2015 From: bartosz.janota at gmail.com (Bartosz Janota) Date: Mon, 23 Mar 2015 18:00:35 +0000 Subject: [keycloak-dev] [GSOC 2015] Keycloak - IoT Security Message-ID: Hi Everyone :), My name is Bartosz Janota and I started my Master's Degree (Computer Science) at AGH University of Science and Technology in Krakow, Poland this month. I'm interested in developing Keycloak - IoT Security and I have some arguments to prove that. First of all I'm a big fan of IoT, I like mobile gadgets and automotive industry - it is strongly connected with IoT. Connecting hobby with GSoC can be very efficient. Next, I have an experience with IoT. I finished IoT course with 5.0 (held at my University). We were programming Intel Galileo boards. We designed and implemented some solutions for smart house. You can see more details about the course here: http://www.ki.agh.edu.pl/strona/agh-copernicus and http://galaxy.agh.edu.pl/~tszydlo/copernicus/. At the end I would like to mention that me and my friend designed and implemented a digital sundial based on Raspberry Pi. You can watch this short movie to see how it works: https://onedrive.live.com/?cid=a0b283703bd03412&id=A0B283703BD03412%212026&ithint=video,.mp4&authkey=!AGkDFXapyN9gMM4, If you are interested in more details about this project I can show you technical documentation. To sum it up, I'm interesting in participating in Keycloak - IoT Security project. Can you please give me more details about this project? Which IoT platforms do you consider? I'm looking forward to hearing from you, Bartosz Janota -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150323/ba38e553/attachment.html From gerbermichi at me.com Mon Mar 23 15:25:54 2015 From: gerbermichi at me.com (Michael Gerber) Date: Mon, 23 Mar 2015 20:25:54 +0100 Subject: [keycloak-dev] GUI Issues Message-ID: Hi All I created a Jira task for GUI issues. https://issues.jboss.org/browse/KEYCLOAK-1131 Please add known GUI issues to this task, so I can fix them all together ;-) Best Michael From ssilvert at redhat.com Mon Mar 23 16:46:40 2015 From: ssilvert at redhat.com (Stan Silvert) Date: Mon, 23 Mar 2015 16:46:40 -0400 Subject: [keycloak-dev] Java 8? Message-ID: <55107BB0.1000200@redhat.com> Java 7 is end of life next month. Elytron requires Java 8. Any opinion on when we should start using it? If I keep Elytron tests in the testsuite then the testsuite would need to run with Java 8. Stan From stian at redhat.com Tue Mar 24 01:33:16 2015 From: stian at redhat.com (Stian Thorgersen) Date: Tue, 24 Mar 2015 01:33:16 -0400 (EDT) Subject: [keycloak-dev] Shouldn't external token by stored in UserSession? In-Reply-To: <55101EF0.2070900@redhat.com> References: <55101EF0.2070900@redhat.com> Message-ID: <502516339.3559352.1427175196105.JavaMail.zimbra@redhat.com> It's not always specific to a UserSession. The tokens obtained from a provider may be offline tokens to provide permanent access. For example if an application wants permanent access to Google and Facebook those providers can be configured with the offline scope, which would provide access even if the user didn't log-in the current session with either of those providers. A logged in user could have one token that's used to login a specific session, but also a number of other tokens that have not been used to login the specific session, but that has been used in the past, or was used when setting up the link initially. ----- Original Message ----- > From: "Bill Burke" > To: keycloak-dev at lists.jboss.org > Sent: Monday, 23 March, 2015 3:10:56 PM > Subject: [keycloak-dev] Shouldn't external token by stored in UserSession? > > Why is the external token stored in actual user storage > (FederatedIdentityModel). The token is really something specific to the > UserSession and belongs there. > > Also, there may not be one single item for "external token". For > example, OIDC has both an IDToken and access token. The IDToken is > actually used to perform a logout according to the OIDC logout profile. > > Right now, our code is storing the AccessTokenResponse for OIDC, and the > entire login response for SAML. > -- > Bill Burke > JBoss, a division of Red Hat > http://bill.burkecentral.com > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > From stian at redhat.com Tue Mar 24 02:29:23 2015 From: stian at redhat.com (Stian Thorgersen) Date: Tue, 24 Mar 2015 02:29:23 -0400 (EDT) Subject: [keycloak-dev] [GSOC 2015] Keycloak - IoT Security In-Reply-To: References: Message-ID: <555938166.3586490.1427178563201.JavaMail.zimbra@redhat.com> I like your sundial, did you come up with the implementation yourself or did you follow instructions from somewhere else? Do you have any experience with Java or security? The IoT project is left vague intentionally. I'd like the student who undertakes the project to come up with an idea for the project. What we want is something that can demonstrate the use of Keycloak and OpenID Connect in IoT. Expected outcomes would be a POC/demo, instructions on how to reproduce and possibly some improvements to Keycloak if required. Ideally if you use any hardware devices (which is quite likely ;)) they should be cheap and generic so we can reproduce it ourselves. If you have any more questions feel free to ask. ----- Original Message ----- > From: "Bartosz Janota" > To: keycloak-dev at lists.jboss.org > Sent: Monday, 23 March, 2015 7:00:35 PM > Subject: [keycloak-dev] [GSOC 2015] Keycloak - IoT Security > > Hi Everyone :), > > My name is Bartosz Janota and I started my Master's Degree (Computer Science) > at AGH University of Science and Technology in Krakow, Poland this month. > > I'm interested in developing Keycloak - IoT Security and I have some > arguments to prove that. > > First of all I'm a big fan of IoT, I like mobile gadgets and automotive > industry - it is strongly connected with IoT. Connecting hobby with GSoC can > be very efficient. > > Next, I have an experience with IoT. I finished IoT course with 5.0 (held at > my University). We were programming Intel Galileo boards. We designed and > implemented some solutions for smart house. You can see more details about > the course here: http://www.ki.agh.edu.pl/strona/agh-copernicus and > http://galaxy.agh.edu.pl/~tszydlo/copernicus/ . > > At the end I would like to mention that me and my friend designed and > implemented a digital sundial based on Raspberry Pi. You can watch this > short movie to see how it works: > https://onedrive.live.com/?cid=a0b283703bd03412&id=A0B283703BD03412%212026&ithint=video,.mp4&authkey=!AGkDFXapyN9gMM4 > , If you are interested in more details about this project I can show you > technical documentation. > > To sum it up, I'm interesting in participating in Keycloak - IoT Security > project. Can you please give me more details about this project? Which IoT > platforms do you consider? > > I'm looking forward to hearing from you, > Bartosz Janota > > > > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev From bartosz.janota at gmail.com Tue Mar 24 04:46:50 2015 From: bartosz.janota at gmail.com (Bartosz Janota) Date: Tue, 24 Mar 2015 08:46:50 +0000 Subject: [keycloak-dev] [GSOC 2015] Keycloak - IoT Security In-Reply-To: <555938166.3586490.1427178563201.JavaMail.zimbra@redhat.com> References: <555938166.3586490.1427178563201.JavaMail.zimbra@redhat.com> Message-ID: Hi Stian, Thank you for your answer. I'm really happy you like my sundial, I appreciate that. I came up with implementation myself. Then me and my friend built and implemented this sundial as a final project for microprocessor systems classes. You can go through the documentation available here: http://student.agh.edu.pl/~bjanota/DokumentacjaZegarSloneczny_v4.pdf if you are interested. Unfortunately it is written in Polish, nevertheless, you can get some details seeing pictures and code samples. Yes of course, I have Java experience. I am member of two Scientific Group Sections and one of them is focusing on creating projects, we implemented some Java projects in the past - this is where I started my adventure with Java. I'm Scala Developer in my current work (earlier I was Java Dev, in the same company), so I am able to create products in Java as well :). If you ask about security - I passed Security of computer systems course at my university - I am familiar with security techniques. In my work we (in fact me and my two friends) develop analytic tool (written in Scala) which handles over 1kk unique requests per day form unique users, we must take care about security - it works well, so I can say I have some experience with security. At the end I'd like to add that during the last semester I built a Meetup client application based on OAuth2.0, you can see code here: https://github.com/BartoszJanota/swipetup (it is also deployed, you can find URL in README). I am familiar with OAuth protocol, so I think I will be able to use OpenID Connect with ease :). Sounds great, I love coding projects when I can do what I really want and it is my own idea. I can't imagine working with Keycloak without physical implementation on hardware devices, I will definitely use some devices :). So as I understood, now you don't have any ideas or implemented any samples that use Keycloak and can be run on IoT devices? Which device can you personally suggest? Will you choose platform or should I do it on my own (assuming I would be accepted)? Your expectations sound good to me. Best, Bartosz On Tue, 24 Mar 2015 at 07:29 Stian Thorgersen wrote: > I like your sundial, did you come up with the implementation yourself or > did you follow instructions from somewhere else? > > Do you have any experience with Java or security? > > The IoT project is left vague intentionally. I'd like the student who > undertakes the project to come up with an idea for the project. What we > want is something that can demonstrate the use of Keycloak and OpenID > Connect in IoT. Expected outcomes would be a POC/demo, instructions on how > to reproduce and possibly some improvements to Keycloak if required. > Ideally if you use any hardware devices (which is quite likely ;)) they > should be cheap and generic so we can reproduce it ourselves. > > If you have any more questions feel free to ask. > > ----- Original Message ----- > > From: "Bartosz Janota" > > To: keycloak-dev at lists.jboss.org > > Sent: Monday, 23 March, 2015 7:00:35 PM > > Subject: [keycloak-dev] [GSOC 2015] Keycloak - IoT Security > > > > Hi Everyone :), > > > > My name is Bartosz Janota and I started my Master's Degree (Computer > Science) > > at AGH University of Science and Technology in Krakow, Poland this month. > > > > I'm interested in developing Keycloak - IoT Security and I have some > > arguments to prove that. > > > > First of all I'm a big fan of IoT, I like mobile gadgets and automotive > > industry - it is strongly connected with IoT. Connecting hobby with GSoC > can > > be very efficient. > > > > Next, I have an experience with IoT. I finished IoT course with 5.0 > (held at > > my University). We were programming Intel Galileo boards. We designed and > > implemented some solutions for smart house. You can see more details > about > > the course here: http://www.ki.agh.edu.pl/strona/agh-copernicus and > > http://galaxy.agh.edu.pl/~tszydlo/copernicus/ . > > > > At the end I would like to mention that me and my friend designed and > > implemented a digital sundial based on Raspberry Pi. You can watch this > > short movie to see how it works: > > https://onedrive.live.com/?cid=a0b283703bd03412&id=A0B283703 > BD03412%212026&ithint=video,.mp4&authkey=!AGkDFXapyN9gMM4 > > , If you are interested in more details about this project I can show you > > technical documentation. > > > > To sum it up, I'm interesting in participating in Keycloak - IoT Security > > project. Can you please give me more details about this project? Which > IoT > > platforms do you consider? > > > > I'm looking forward to hearing from you, > > Bartosz Janota > > > > > > > > > > _______________________________________________ > > keycloak-dev mailing list > > keycloak-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/keycloak-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150324/f5836a4d/attachment-0001.html From bburke at redhat.com Tue Mar 24 08:24:27 2015 From: bburke at redhat.com (Bill Burke) Date: Tue, 24 Mar 2015 08:24:27 -0400 Subject: [keycloak-dev] Shouldn't external token by stored in UserSession? In-Reply-To: <502516339.3559352.1427175196105.JavaMail.zimbra@redhat.com> References: <55101EF0.2070900@redhat.com> <502516339.3559352.1427175196105.JavaMail.zimbra@redhat.com> Message-ID: <5511577B.4020107@redhat.com> Still doesn't require that the tokens be stored. On 3/24/2015 1:33 AM, Stian Thorgersen wrote: > It's not always specific to a UserSession. The tokens obtained from a provider may be offline tokens to provide permanent access. For example if an application wants permanent access to Google and Facebook those providers can be configured with the offline scope, which would provide access even if the user didn't log-in the current session with either of those providers. > > A logged in user could have one token that's used to login a specific session, but also a number of other tokens that have not been used to login the specific session, but that has been used in the past, or was used when setting up the link initially. > > ----- Original Message ----- >> From: "Bill Burke" >> To: keycloak-dev at lists.jboss.org >> Sent: Monday, 23 March, 2015 3:10:56 PM >> Subject: [keycloak-dev] Shouldn't external token by stored in UserSession? >> >> Why is the external token stored in actual user storage >> (FederatedIdentityModel). The token is really something specific to the >> UserSession and belongs there. >> >> Also, there may not be one single item for "external token". For >> example, OIDC has both an IDToken and access token. The IDToken is >> actually used to perform a logout according to the OIDC logout profile. >> >> Right now, our code is storing the AccessTokenResponse for OIDC, and the >> entire login response for SAML. >> -- >> Bill Burke >> JBoss, a division of Red Hat >> http://bill.burkecentral.com >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From bburke at redhat.com Tue Mar 24 08:29:33 2015 From: bburke at redhat.com (Bill Burke) Date: Tue, 24 Mar 2015 08:29:33 -0400 Subject: [keycloak-dev] Shouldn't external token by stored in UserSession? In-Reply-To: <5511577B.4020107@redhat.com> References: <55101EF0.2070900@redhat.com> <502516339.3559352.1427175196105.JavaMail.zimbra@redhat.com> <5511577B.4020107@redhat.com> Message-ID: <551158AD.6070508@redhat.com> What I'm saying is that for non-social brokering, any stored token is invalid after logout. The app will obtain the external token via its ID or access token, or it will have to go to a token exchange service, which, itself is access token secured. storing an external token each login requires a write to the user database. On 3/24/2015 8:24 AM, Bill Burke wrote: > Still doesn't require that the tokens be stored. > > On 3/24/2015 1:33 AM, Stian Thorgersen wrote: >> It's not always specific to a UserSession. The tokens obtained from a provider may be offline tokens to provide permanent access. For example if an application wants permanent access to Google and Facebook those providers can be configured with the offline scope, which would provide access even if the user didn't log-in the current session with either of those providers. >> >> A logged in user could have one token that's used to login a specific session, but also a number of other tokens that have not been used to login the specific session, but that has been used in the past, or was used when setting up the link initially. >> >> ----- Original Message ----- >>> From: "Bill Burke" >>> To: keycloak-dev at lists.jboss.org >>> Sent: Monday, 23 March, 2015 3:10:56 PM >>> Subject: [keycloak-dev] Shouldn't external token by stored in UserSession? >>> >>> Why is the external token stored in actual user storage >>> (FederatedIdentityModel). The token is really something specific to the >>> UserSession and belongs there. >>> >>> Also, there may not be one single item for "external token". For >>> example, OIDC has both an IDToken and access token. The IDToken is >>> actually used to perform a logout according to the OIDC logout profile. >>> >>> Right now, our code is storing the AccessTokenResponse for OIDC, and the >>> entire login response for SAML. >>> -- >>> Bill Burke >>> JBoss, a division of Red Hat >>> http://bill.burkecentral.com >>> _______________________________________________ >>> keycloak-dev mailing list >>> keycloak-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>> > -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From stian at redhat.com Tue Mar 24 08:40:58 2015 From: stian at redhat.com (Stian Thorgersen) Date: Tue, 24 Mar 2015 08:40:58 -0400 (EDT) Subject: [keycloak-dev] Shouldn't external token by stored in UserSession? In-Reply-To: <551158AD.6070508@redhat.com> References: <55101EF0.2070900@redhat.com> <502516339.3559352.1427175196105.JavaMail.zimbra@redhat.com> <5511577B.4020107@redhat.com> <551158AD.6070508@redhat.com> Message-ID: <1536285842.3860788.1427200858580.JavaMail.zimbra@redhat.com> It's not specific to social brokering, the same use-case applies to any IdP. There's two separate use-cases: * External IdP is used only to authenticate user (and logout) - in this case I don't see why the app would need the token at all * Application uses external token to invoke services The last use-case is the one I'm referring to and it doesn't just apply to social brokering (that was just the example I used). An application may want to invoke services secured by both the internal Keycloak and an external IdP. This is the use-case where the application needs to obtain the token from the external IdP. In this case the application quite likely wants to have access to invoke the services independent of what mechanism was used to authenticate the given session. In this case the external IdP could be configured with the offline scope to provide permanent access. ----- Original Message ----- > From: "Bill Burke" > To: keycloak-dev at lists.jboss.org > Sent: Tuesday, 24 March, 2015 1:29:33 PM > Subject: Re: [keycloak-dev] Shouldn't external token by stored in UserSession? > > What I'm saying is that for non-social brokering, any stored token is > invalid after logout. The app will obtain the external token via its ID > or access token, or it will have to go to a token exchange service, > which, itself is access token secured. > > storing an external token each login requires a write to the user database. > > On 3/24/2015 8:24 AM, Bill Burke wrote: > > Still doesn't require that the tokens be stored. > > > > On 3/24/2015 1:33 AM, Stian Thorgersen wrote: > >> It's not always specific to a UserSession. The tokens obtained from a > >> provider may be offline tokens to provide permanent access. For example > >> if an application wants permanent access to Google and Facebook those > >> providers can be configured with the offline scope, which would provide > >> access even if the user didn't log-in the current session with either of > >> those providers. > >> > >> A logged in user could have one token that's used to login a specific > >> session, but also a number of other tokens that have not been used to > >> login the specific session, but that has been used in the past, or was > >> used when setting up the link initially. > >> > >> ----- Original Message ----- > >>> From: "Bill Burke" > >>> To: keycloak-dev at lists.jboss.org > >>> Sent: Monday, 23 March, 2015 3:10:56 PM > >>> Subject: [keycloak-dev] Shouldn't external token by stored in > >>> UserSession? > >>> > >>> Why is the external token stored in actual user storage > >>> (FederatedIdentityModel). The token is really something specific to the > >>> UserSession and belongs there. > >>> > >>> Also, there may not be one single item for "external token". For > >>> example, OIDC has both an IDToken and access token. The IDToken is > >>> actually used to perform a logout according to the OIDC logout profile. > >>> > >>> Right now, our code is storing the AccessTokenResponse for OIDC, and the > >>> entire login response for SAML. > >>> -- > >>> Bill Burke > >>> JBoss, a division of Red Hat > >>> http://bill.burkecentral.com > >>> _______________________________________________ > >>> keycloak-dev mailing list > >>> keycloak-dev at lists.jboss.org > >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev > >>> > > > > -- > Bill Burke > JBoss, a division of Red Hat > http://bill.burkecentral.com > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > From bburke at redhat.com Tue Mar 24 09:12:45 2015 From: bburke at redhat.com (Bill Burke) Date: Tue, 24 Mar 2015 09:12:45 -0400 Subject: [keycloak-dev] Shouldn't external token by stored in UserSession? In-Reply-To: <1536285842.3860788.1427200858580.JavaMail.zimbra@redhat.com> References: <55101EF0.2070900@redhat.com> <502516339.3559352.1427175196105.JavaMail.zimbra@redhat.com> <5511577B.4020107@redhat.com> <551158AD.6070508@redhat.com> <1536285842.3860788.1427200858580.JavaMail.zimbra@redhat.com> Message-ID: <551162CD.3020007@redhat.com> On 3/24/2015 8:40 AM, Stian Thorgersen wrote: > It's not specific to social brokering, the same use-case applies to any IdP. > > There's two separate use-cases: > > * External IdP is used only to authenticate user (and logout) - in this case I don't see why the app would need the token at all > * Application uses external token to invoke services > > The last use-case is the one I'm referring to and it doesn't just apply to social brokering (that was just the example I used). An application may want to invoke services secured by both the internal Keycloak and an external IdP. This is the use-case where the application needs to obtain the token from the external IdP. In this case the application quite likely wants to have access to invoke the services independent of what mechanism was used to authenticate the given session. In this case the external IdP could be configured with the offline scope to provide permanent access. > Again, right now, every brokered login *requires a user database write*. This is unacceptable. Untrue that the external token needs to be separate from user session. That's just the way it was initially decided to be implemented. Flow should be: 1. user logs in via external provide 2. external token stored in user session 3. App receives access token The external token is either obtained by it being embedded in the app's access or ID token (which IMO is the best way to do it), or it is obtained via the token exchange service which *should*, IMO, require the app's acquired access token to retrieve the external token. Offline access should just be a clone of the original userSession, access token, and refresh token. That way our existing architecture can be used to manage "offline" tokens. Also, finally, when the app refreshes its access token, OIDC brokered sessions should also check the timeout of the external refresh token and perform an external refresh if necessary. This is absolutely needed as the external token may have been revoked. -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From bburke at redhat.com Tue Mar 24 09:19:21 2015 From: bburke at redhat.com (Bill Burke) Date: Tue, 24 Mar 2015 09:19:21 -0400 Subject: [keycloak-dev] Fwd: [OAUTH-WG] OAuth Token Swap (token chaining) In-Reply-To: <0C7C1508-DA58-4832-B755-F8BA1F153894@mit.edu> References: <0C7C1508-DA58-4832-B755-F8BA1F153894@mit.edu> Message-ID: <55116459.2@redhat.com> Token exchange discussions on IETF. -------- Forwarded Message -------- Subject: [OAUTH-WG] OAuth Token Swap (token chaining) Date: Mon, 23 Mar 2015 14:40:33 -0500 From: Justin Richer To: As mentioned in today???s IETF meeting, here are the two drafts dealing with generic token swap: https://tools.ietf.org/html/draft-hunt-oauth-chain-01 https://tools.ietf.org/html/draft-richer-oauth-chain-00 -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From psilva at redhat.com Tue Mar 24 09:28:06 2015 From: psilva at redhat.com (Pedro Igor Silva) Date: Tue, 24 Mar 2015 09:28:06 -0400 (EDT) Subject: [keycloak-dev] Fwd: [OAUTH-WG] OAuth Token Swap (token chaining) In-Reply-To: <55116459.2@redhat.com> References: <0C7C1508-DA58-4832-B755-F8BA1F153894@mit.edu> <55116459.2@redhat.com> Message-ID: <939121674.2027061.1427203685999.JavaMail.zimbra@redhat.com> An also ... ----- Original Message ----- From: "Brian Campbell" Cc: "" Sent: Tuesday, March 24, 2015 9:55:10 AM Subject: Re: [OAUTH-WG] OAuth Token Swap (token chaining) And here's the somewhat different take on token exchange that I mentioned yesterday: https://tools.ietf.org/html/draft-campbell-oauth-sts-01 A little more background, context, and discussion about it can be seen following the thread on the Call for Adoption of "OAuth 2.0 Token Exchange" as an OAuth WG Item: https://www.ietf.org/mail-archive/web/oauth/current/msg13236.html https://www.ietf.org/mail-archive/web/oauth/current/msg13305.html ... etc ... https://www.ietf.org/mail-archive/web/oauth/current/msg13311.html ... etc. ----- Original Message ----- From: "Bill Burke" To: keycloak-dev at lists.jboss.org Sent: Tuesday, March 24, 2015 10:19:21 AM Subject: [keycloak-dev] Fwd: [OAUTH-WG] OAuth Token Swap (token chaining) Token exchange discussions on IETF. -------- Forwarded Message -------- Subject: [OAUTH-WG] OAuth Token Swap (token chaining) Date: Mon, 23 Mar 2015 14:40:33 -0500 From: Justin Richer To: As mentioned in today???s IETF meeting, here are the two drafts dealing with generic token swap: https://tools.ietf.org/html/draft-hunt-oauth-chain-01 https://tools.ietf.org/html/draft-richer-oauth-chain-00 -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com _______________________________________________ keycloak-dev mailing list keycloak-dev at lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-dev From psilva at redhat.com Tue Mar 24 10:16:41 2015 From: psilva at redhat.com (Pedro Igor Silva) Date: Tue, 24 Mar 2015 10:16:41 -0400 (EDT) Subject: [keycloak-dev] Shouldn't external token by stored in UserSession? In-Reply-To: <551162CD.3020007@redhat.com> References: <55101EF0.2070900@redhat.com> <502516339.3559352.1427175196105.JavaMail.zimbra@redhat.com> <5511577B.4020107@redhat.com> <551158AD.6070508@redhat.com> <1536285842.3860788.1427200858580.JavaMail.zimbra@redhat.com> <551162CD.3020007@redhat.com> Message-ID: <1583619352.2082620.1427206601124.JavaMail.zimbra@redhat.com> ----- Original Message ----- > From: "Bill Burke" > To: "Stian Thorgersen" > Cc: keycloak-dev at lists.jboss.org > Sent: Tuesday, March 24, 2015 10:12:45 AM > Subject: Re: [keycloak-dev] Shouldn't external token by stored in UserSession? > > > > On 3/24/2015 8:40 AM, Stian Thorgersen wrote: > > It's not specific to social brokering, the same use-case applies to any > > IdP. > > > > There's two separate use-cases: > > > > * External IdP is used only to authenticate user (and logout) - in this > > case I don't see why the app would need the token at all > > * Application uses external token to invoke services > > > > The last use-case is the one I'm referring to and it doesn't just apply to > > social brokering (that was just the example I used). An application may > > want to invoke services secured by both the internal Keycloak and an > > external IdP. This is the use-case where the application needs to obtain > > the token from the external IdP. In this case the application quite likely > > wants to have access to invoke the services independent of what mechanism > > was used to authenticate the given session. In this case the external IdP > > could be configured with the offline scope to provide permanent access. > > > > Again, right now, every brokered login *requires a user database write*. > This is unacceptable. Considering that KC has complete control over users sessions, you can store tokens anytime you want. For instance, before the session expires. > > Untrue that the external token needs to be separate from user session. > That's just the way it was initially decided to be implemented. Flow > should be: > > 1. user logs in via external provide > 2. external token stored in user session > 3. App receives access token > > The external token is either obtained by it being embedded in the app's > access or ID token (which IMO is the best way to do it), or it is > obtained via the token exchange service which *should*, IMO, require the > app's acquired access token to retrieve the external token. > > Offline access should just be a clone of the original userSession, > access token, and refresh token. That way our existing architecture can > be used to manage "offline" tokens. > > Also, finally, when the app refreshes its access token, OIDC brokered > sessions should also check the timeout of the external refresh token and > perform an external refresh if necessary. This is absolutely needed as > the external token may have been revoked. > > > > -- > Bill Burke > JBoss, a division of Red Hat > http://bill.burkecentral.com > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > From stian at redhat.com Tue Mar 24 10:37:54 2015 From: stian at redhat.com (Stian Thorgersen) Date: Tue, 24 Mar 2015 10:37:54 -0400 (EDT) Subject: [keycloak-dev] Shouldn't external token by stored in UserSession? In-Reply-To: <551162CD.3020007@redhat.com> References: <55101EF0.2070900@redhat.com> <502516339.3559352.1427175196105.JavaMail.zimbra@redhat.com> <5511577B.4020107@redhat.com> <551158AD.6070508@redhat.com> <1536285842.3860788.1427200858580.JavaMail.zimbra@redhat.com> <551162CD.3020007@redhat.com> Message-ID: <600395725.3962902.1427207874299.JavaMail.zimbra@redhat.com> ----- Original Message ----- > From: "Bill Burke" > To: "Stian Thorgersen" > Cc: keycloak-dev at lists.jboss.org > Sent: Tuesday, 24 March, 2015 2:12:45 PM > Subject: Re: [keycloak-dev] Shouldn't external token by stored in UserSession? > > > > On 3/24/2015 8:40 AM, Stian Thorgersen wrote: > > It's not specific to social brokering, the same use-case applies to any > > IdP. > > > > There's two separate use-cases: > > > > * External IdP is used only to authenticate user (and logout) - in this > > case I don't see why the app would need the token at all > > * Application uses external token to invoke services > > > > The last use-case is the one I'm referring to and it doesn't just apply to > > social brokering (that was just the example I used). An application may > > want to invoke services secured by both the internal Keycloak and an > > external IdP. This is the use-case where the application needs to obtain > > the token from the external IdP. In this case the application quite likely > > wants to have access to invoke the services independent of what mechanism > > was used to authenticate the given session. In this case the external IdP > > could be configured with the offline scope to provide permanent access. > > > > Again, right now, every brokered login *requires a user database write*. > This is unacceptable. > > Untrue that the external token needs to be separate from user session. > That's just the way it was initially decided to be implemented. Flow > should be: > > 1. user logs in via external provide > 2. external token stored in user session > 3. App receives access token > > The external token is either obtained by it being embedded in the app's > access or ID token (which IMO is the best way to do it), or it is > obtained via the token exchange service which *should*, IMO, require the > app's acquired access token to retrieve the external token. > > Offline access should just be a clone of the original userSession, > access token, and refresh token. That way our existing architecture can > be used to manage "offline" tokens. That's not going to work as UserSessions are lost in the case of a server restart/failure. Offline tokens and client grants needs to be persisted permanently. For example my phone has a offline token to my Google account and it's had it for more than a year now. I wouldn't want to re-enable that every time Google restarts the node that keeps my session. Maybe we need yet another (dread) storage option. > > Also, finally, when the app refreshes its access token, OIDC brokered > sessions should also check the timeout of the external refresh token and > perform an external refresh if necessary. This is absolutely needed as > the external token may have been revoked. > > > > -- > Bill Burke > JBoss, a division of Red Hat > http://bill.burkecentral.com > From stian at redhat.com Tue Mar 24 10:49:20 2015 From: stian at redhat.com (Stian Thorgersen) Date: Tue, 24 Mar 2015 10:49:20 -0400 (EDT) Subject: [keycloak-dev] Shouldn't external token by stored in UserSession? In-Reply-To: <600395725.3962902.1427207874299.JavaMail.zimbra@redhat.com> References: <55101EF0.2070900@redhat.com> <502516339.3559352.1427175196105.JavaMail.zimbra@redhat.com> <5511577B.4020107@redhat.com> <551158AD.6070508@redhat.com> <1536285842.3860788.1427200858580.JavaMail.zimbra@redhat.com> <551162CD.3020007@redhat.com> <600395725.3962902.1427207874299.JavaMail.zimbra@redhat.com> Message-ID: <108182968.3995572.1427208560491.JavaMail.zimbra@redhat.com> Another important thing that I've mentioned a few times that I feel you're ignoring. Storing the token in the user session makes perfect sense for the 1 token that used to login that session, but it does not make sense if a users account is linked with multiple IdPs and there's has an offline token from multiple IdPs. In that case if tokens are stored in the user session how would an application retrieve all of the offline tokens?! ----- Original Message ----- > From: "Stian Thorgersen" > To: "Bill Burke" > Cc: keycloak-dev at lists.jboss.org > Sent: Tuesday, 24 March, 2015 3:37:54 PM > Subject: Re: [keycloak-dev] Shouldn't external token by stored in UserSession? > > > > ----- Original Message ----- > > From: "Bill Burke" > > To: "Stian Thorgersen" > > Cc: keycloak-dev at lists.jboss.org > > Sent: Tuesday, 24 March, 2015 2:12:45 PM > > Subject: Re: [keycloak-dev] Shouldn't external token by stored in > > UserSession? > > > > > > > > On 3/24/2015 8:40 AM, Stian Thorgersen wrote: > > > It's not specific to social brokering, the same use-case applies to any > > > IdP. > > > > > > There's two separate use-cases: > > > > > > * External IdP is used only to authenticate user (and logout) - in this > > > case I don't see why the app would need the token at all > > > * Application uses external token to invoke services > > > > > > The last use-case is the one I'm referring to and it doesn't just apply > > > to > > > social brokering (that was just the example I used). An application may > > > want to invoke services secured by both the internal Keycloak and an > > > external IdP. This is the use-case where the application needs to obtain > > > the token from the external IdP. In this case the application quite > > > likely > > > wants to have access to invoke the services independent of what mechanism > > > was used to authenticate the given session. In this case the external IdP > > > could be configured with the offline scope to provide permanent access. > > > > > > > Again, right now, every brokered login *requires a user database write*. > > This is unacceptable. > > > > Untrue that the external token needs to be separate from user session. > > That's just the way it was initially decided to be implemented. Flow > > should be: > > > > 1. user logs in via external provide > > 2. external token stored in user session > > 3. App receives access token > > > > The external token is either obtained by it being embedded in the app's > > access or ID token (which IMO is the best way to do it), or it is > > obtained via the token exchange service which *should*, IMO, require the > > app's acquired access token to retrieve the external token. > > > > Offline access should just be a clone of the original userSession, > > access token, and refresh token. That way our existing architecture can > > be used to manage "offline" tokens. > > That's not going to work as UserSessions are lost in the case of a server > restart/failure. Offline tokens and client grants needs to be persisted > permanently. For example my phone has a offline token to my Google account > and it's had it for more than a year now. I wouldn't want to re-enable that > every time Google restarts the node that keeps my session. Maybe we need yet > another (dread) storage option. > > > > > Also, finally, when the app refreshes its access token, OIDC brokered > > sessions should also check the timeout of the external refresh token and > > perform an external refresh if necessary. This is absolutely needed as > > the external token may have been revoked. > > > > > > > > -- > > Bill Burke > > JBoss, a division of Red Hat > > http://bill.burkecentral.com > > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > From bburke at redhat.com Tue Mar 24 10:54:28 2015 From: bburke at redhat.com (Bill Burke) Date: Tue, 24 Mar 2015 10:54:28 -0400 Subject: [keycloak-dev] usersession-based UserModels Message-ID: <55117AA4.70707@redhat.com> I'm thinking more and more we need UserSession based UserModels. This would be the case where nothing is imported for a user with either brokering or federation, but rather stored in memory for the duration of the UserSession. If user metadata (role mappings, etc.) is all obtained from external sources, there really is no need to import the data and import is just a huge performance hit. I ran into this with "transient" nameid format and SAML brokering. In this scenario the parent IDP generates a new userid each and every login. This is to define an anonymous user. So, every time a user logs in would create a brand new user in the keycloak database. -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From bburke at redhat.com Tue Mar 24 11:58:24 2015 From: bburke at redhat.com (Bill Burke) Date: Tue, 24 Mar 2015 11:58:24 -0400 Subject: [keycloak-dev] brokerid + subject for brokered username? Message-ID: <551189A0.9050007@redhat.com> Although a remote possibility, it might be possible for usernames to clash when there are multiple brokers. Anybody have a problem with creating usernames of: brokerAlias + "." + external_username ?? -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From stian at redhat.com Tue Mar 24 13:21:51 2015 From: stian at redhat.com (Stian Thorgersen) Date: Tue, 24 Mar 2015 13:21:51 -0400 (EDT) Subject: [keycloak-dev] brokerid + subject for brokered username? In-Reply-To: <551189A0.9050007@redhat.com> References: <551189A0.9050007@redhat.com> Message-ID: <1905477385.4162223.1427217711501.JavaMail.zimbra@redhat.com> A username like that is pointless IMO. Using username from broker actually has a pretty high chance of clash, especially for social logins. I very often can't get my preferred username when signing up to sites, and judging on how may saly9581 there are out there that's a common problem. That's why username for social logins used to be a UUID, but was for some reason changed. For users provisioned through idp logins we should set the username to null, or equal to the user-id. When a user has a null username or username is equal to user-id it should not be displayed in account management, instead we could add an option to allow the user to set the username. ----- Original Message ----- > From: "Bill Burke" > To: keycloak-dev at lists.jboss.org > Sent: Tuesday, 24 March, 2015 4:58:24 PM > Subject: [keycloak-dev] brokerid + subject for brokered username? > > Although a remote possibility, it might be possible for usernames to > clash when there are multiple brokers. Anybody have a problem with > creating usernames of: > > brokerAlias + "." + external_username > > ?? > > > -- > Bill Burke > JBoss, a division of Red Hat > http://bill.burkecentral.com > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > From bburke at redhat.com Tue Mar 24 13:54:53 2015 From: bburke at redhat.com (Bill Burke) Date: Tue, 24 Mar 2015 13:54:53 -0400 Subject: [keycloak-dev] brokerid + subject for brokered username? In-Reply-To: <1905477385.4162223.1427217711501.JavaMail.zimbra@redhat.com> References: <551189A0.9050007@redhat.com> <1905477385.4162223.1427217711501.JavaMail.zimbra@redhat.com> Message-ID: <5511A4ED.6010804@redhat.com> I wanted brokerAlias + "." external_username for backchannel logout when the external IDP is initiating the logout in the background. An external SAML IDP sends a subject name and optionally a session index. These external attributes must be mapped to a UserSession in Keycloak so the logout can be performed. Same sort of thing would need to be done for chained keycloak realms. Its easier to implement if it is brokerAlias + "." + external_username. It could be implemented by doing a UserSessionModel query by Note name/value, but then this would require changes across all the sessionModel data stores and eventually would have to be optimized for each as well. On 3/24/2015 1:21 PM, Stian Thorgersen wrote: > A username like that is pointless IMO. > > Using username from broker actually has a pretty high chance of clash, especially for social logins. I very often can't get my preferred username when signing up to sites, and judging on how may saly9581 there are out there that's a common problem. That's why username for social logins used to be a UUID, but was for some reason changed. > > For users provisioned through idp logins we should set the username to null, or equal to the user-id. When a user has a null username or username is equal to user-id it should not be displayed in account management, instead we could add an option to allow the user to set the username. > > ----- Original Message ----- >> From: "Bill Burke" >> To: keycloak-dev at lists.jboss.org >> Sent: Tuesday, 24 March, 2015 4:58:24 PM >> Subject: [keycloak-dev] brokerid + subject for brokered username? >> >> Although a remote possibility, it might be possible for usernames to >> clash when there are multiple brokers. Anybody have a problem with >> creating usernames of: >> >> brokerAlias + "." + external_username >> >> ?? >> >> >> -- >> Bill Burke >> JBoss, a division of Red Hat >> http://bill.burkecentral.com >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From bburke at redhat.com Tue Mar 24 20:13:01 2015 From: bburke at redhat.com (Bill Burke) Date: Tue, 24 Mar 2015 20:13:01 -0400 Subject: [keycloak-dev] brokerid + subject for brokered username? In-Reply-To: <5511A4ED.6010804@redhat.com> References: <551189A0.9050007@redhat.com> <1905477385.4162223.1427217711501.JavaMail.zimbra@redhat.com> <5511A4ED.6010804@redhat.com> Message-ID: <5511FD8D.5000000@redhat.com> Sucks, for SAML, i'll have to find a usersession based on the SAML nameID and session index. For Keycloak OIDC, I have the external keycloak session id. Searching via a UserSessionModel note would be very slow and hard to create a "index" across all storage types. I'm thinking of pushing up a "brokerId" to a top level attribute on UserSessionModel. Then I can do queries and create indexes much easier across storage types. Damn this shit is a pain in the ass... On 3/24/2015 1:54 PM, Bill Burke wrote: > I wanted brokerAlias + "." external_username for backchannel logout when > the external IDP is initiating the logout in the background. An > external SAML IDP sends a subject name and optionally a session index. > These external attributes must be mapped to a UserSession in Keycloak so > the logout can be performed. Same sort of thing would need to be done > for chained keycloak realms. > > Its easier to implement if it is brokerAlias + "." + external_username. > It could be implemented by doing a UserSessionModel query by Note > name/value, but then this would require changes across all the > sessionModel data stores and eventually would have to be optimized for > each as well. > > On 3/24/2015 1:21 PM, Stian Thorgersen wrote: >> A username like that is pointless IMO. >> >> Using username from broker actually has a pretty high chance of clash, especially for social logins. I very often can't get my preferred username when signing up to sites, and judging on how may saly9581 there are out there that's a common problem. That's why username for social logins used to be a UUID, but was for some reason changed. >> >> For users provisioned through idp logins we should set the username to null, or equal to the user-id. When a user has a null username or username is equal to user-id it should not be displayed in account management, instead we could add an option to allow the user to set the username. >> >> ----- Original Message ----- >>> From: "Bill Burke" >>> To: keycloak-dev at lists.jboss.org >>> Sent: Tuesday, 24 March, 2015 4:58:24 PM >>> Subject: [keycloak-dev] brokerid + subject for brokered username? >>> >>> Although a remote possibility, it might be possible for usernames to >>> clash when there are multiple brokers. Anybody have a problem with >>> creating usernames of: >>> >>> brokerAlias + "." + external_username >>> >>> ?? >>> >>> >>> -- >>> Bill Burke >>> JBoss, a division of Red Hat >>> http://bill.burkecentral.com >>> _______________________________________________ >>> keycloak-dev mailing list >>> keycloak-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>> > -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From stian at redhat.com Wed Mar 25 01:42:28 2015 From: stian at redhat.com (Stian Thorgersen) Date: Wed, 25 Mar 2015 01:42:28 -0400 (EDT) Subject: [keycloak-dev] brokerid + subject for brokered username? In-Reply-To: <5511FD8D.5000000@redhat.com> References: <551189A0.9050007@redhat.com> <1905477385.4162223.1427217711501.JavaMail.zimbra@redhat.com> <5511A4ED.6010804@redhat.com> <5511FD8D.5000000@redhat.com> Message-ID: <1413587914.4604717.1427262148857.JavaMail.zimbra@redhat.com> If it helps a lot we could set the username to brokerAlias + "." external_username and set an attribute on the user that the username isn't set by the user so we know to not display it in account management. One problem is that doesn't work if a user has linked an existing account (with their own username) to a SAML IdP. In the future I also wanted to make it possible for users provisioned through IdP login to set a username/password to add regular login to their account. ----- Original Message ----- > From: "Bill Burke" > To: keycloak-dev at lists.jboss.org > Sent: Wednesday, 25 March, 2015 1:13:01 AM > Subject: Re: [keycloak-dev] brokerid + subject for brokered username? > > Sucks, for SAML, i'll have to find a usersession based on the SAML > nameID and session index. For Keycloak OIDC, I have the external > keycloak session id. > > Searching via a UserSessionModel note would be very slow and hard to > create a "index" across all storage types. I'm thinking of pushing up a > "brokerId" to a top level attribute on UserSessionModel. Then I can do > queries and create indexes much easier across storage types. > > Damn this shit is a pain in the ass... > > On 3/24/2015 1:54 PM, Bill Burke wrote: > > I wanted brokerAlias + "." external_username for backchannel logout when > > the external IDP is initiating the logout in the background. An > > external SAML IDP sends a subject name and optionally a session index. > > These external attributes must be mapped to a UserSession in Keycloak so > > the logout can be performed. Same sort of thing would need to be done > > for chained keycloak realms. > > > > Its easier to implement if it is brokerAlias + "." + external_username. > > It could be implemented by doing a UserSessionModel query by Note > > name/value, but then this would require changes across all the > > sessionModel data stores and eventually would have to be optimized for > > each as well. > > > > On 3/24/2015 1:21 PM, Stian Thorgersen wrote: > >> A username like that is pointless IMO. > >> > >> Using username from broker actually has a pretty high chance of clash, > >> especially for social logins. I very often can't get my preferred > >> username when signing up to sites, and judging on how may saly9581 there > >> are out there that's a common problem. That's why username for social > >> logins used to be a UUID, but was for some reason changed. > >> > >> For users provisioned through idp logins we should set the username to > >> null, or equal to the user-id. When a user has a null username or > >> username is equal to user-id it should not be displayed in account > >> management, instead we could add an option to allow the user to set the > >> username. > >> > >> ----- Original Message ----- > >>> From: "Bill Burke" > >>> To: keycloak-dev at lists.jboss.org > >>> Sent: Tuesday, 24 March, 2015 4:58:24 PM > >>> Subject: [keycloak-dev] brokerid + subject for brokered username? > >>> > >>> Although a remote possibility, it might be possible for usernames to > >>> clash when there are multiple brokers. Anybody have a problem with > >>> creating usernames of: > >>> > >>> brokerAlias + "." + external_username > >>> > >>> ?? > >>> > >>> > >>> -- > >>> Bill Burke > >>> JBoss, a division of Red Hat > >>> http://bill.burkecentral.com > >>> _______________________________________________ > >>> keycloak-dev mailing list > >>> keycloak-dev at lists.jboss.org > >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev > >>> > > > > -- > Bill Burke > JBoss, a division of Red Hat > http://bill.burkecentral.com > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > From stian at redhat.com Wed Mar 25 01:49:46 2015 From: stian at redhat.com (Stian Thorgersen) Date: Wed, 25 Mar 2015 01:49:46 -0400 (EDT) Subject: [keycloak-dev] Restrict admins to only allow granting roles they are privileged to In-Reply-To: <514456793.4607151.1427262412160.JavaMail.zimbra@redhat.com> Message-ID: <981150942.4609053.1427262586429.JavaMail.zimbra@redhat.com> I propose we add a check when an admin wants to grant a role. For a admin to be allowed to grant a role the admin either has to have the admin/realm-admin role or have the role itself. This prevents admins from adding more privileges to themselves than they already have and would also be a way to allow admins that can only manage roles for specific applications. This should be a simple fix. In the future I think we may need to re-design how we map permissions for Keycloak. I'm really not that happy with the realm apps and such, it's messy and not flexible enough. From stian at redhat.com Wed Mar 25 01:55:04 2015 From: stian at redhat.com (Stian Thorgersen) Date: Wed, 25 Mar 2015 01:55:04 -0400 (EDT) Subject: [keycloak-dev] usersession-based UserModels In-Reply-To: <55117AA4.70707@redhat.com> References: <55117AA4.70707@redhat.com> Message-ID: <385614498.4610662.1427262904300.JavaMail.zimbra@redhat.com> Sounds like it would make sense for the SAML transient use-case you mentioned, but do we have other use-cases for it? Wouldn't it be a fairly big change for a rare use-case? Unless we start supporting IdP logins without provisioning an internal account, but that would be a pretty big change as well for something we haven't had a request for. ----- Original Message ----- > From: "Bill Burke" > To: keycloak-dev at lists.jboss.org > Sent: Tuesday, 24 March, 2015 3:54:28 PM > Subject: [keycloak-dev] usersession-based UserModels > > I'm thinking more and more we need UserSession based UserModels. This > would be the case where nothing is imported for a user with either > brokering or federation, but rather stored in memory for the duration of > the UserSession. > > If user metadata (role mappings, etc.) is all obtained from external > sources, there really is no need to import the data and import is just a > huge performance hit. > > I ran into this with "transient" nameid format and SAML brokering. In > this scenario the parent IDP generates a new userid each and every > login. This is to define an anonymous user. So, every time a user logs > in would create a brand new user in the keycloak database. > > -- > Bill Burke > JBoss, a division of Red Hat > http://bill.burkecentral.com > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > From stian at redhat.com Wed Mar 25 02:01:36 2015 From: stian at redhat.com (Stian Thorgersen) Date: Wed, 25 Mar 2015 02:01:36 -0400 (EDT) Subject: [keycloak-dev] Java 8? In-Reply-To: <55107BB0.1000200@redhat.com> References: <55107BB0.1000200@redhat.com> Message-ID: <1917315183.4615751.1427263296081.JavaMail.zimbra@redhat.com> It's to early for us to drop support for Java 7, especially for adapters. The testsuite needs to run with both Java 7 and 8. I suggest we add a new module for those tests (testsuite/elytron) and use a Maven profile to run them only when the profile is active. ----- Original Message ----- > From: "Stan Silvert" > To: keycloak-dev at lists.jboss.org > Sent: Monday, 23 March, 2015 9:46:40 PM > Subject: [keycloak-dev] Java 8? > > Java 7 is end of life next month. Elytron requires Java 8. > > Any opinion on when we should start using it? If I keep Elytron tests > in the testsuite then the testsuite would need to run with Java 8. > > Stan > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > From gerbermichi at me.com Wed Mar 25 02:36:36 2015 From: gerbermichi at me.com (Michael Gerber) Date: Wed, 25 Mar 2015 06:36:36 +0000 (GMT) Subject: [keycloak-dev] Internationalization Message-ID: <1a517cd2-ed1d-4fce-926c-2719708ab8ee@me.com> Am 23. M?rz 2015 um 10:51 schrieb Stian Thorgersen : ----- Original Message ----- From: "Michael Gerber" To: keycloak-dev at lists.jboss.org Sent: Monday, 23 March, 2015 10:08:55 AM Subject: [keycloak-dev] Internationalization Hi all @all developers Please make sure that you use ISO-8859-1 encoding for your language property files (messages_en.properties and messages_de.properties) @Bill Can you have a look at the claims and roles internationalization of the login-oauth-grant.ftl page. If you want to enable internationalization for a value than you have to enter it like that: ${username} Is that ok? Do we want to enable i18n for the default roles and claims? Yes and yes ?Where is the right place to set a default description for a role? @Stian There are a few minor gui issues: - Registration page with a screen resolution of 768*1024 - Login page in German with a screen resolution of 1024*768 Should I solve this kind of issues, even if they are not directly related to the i18n task? Sure, but create a JIRA and separate PR please Michael _______________________________________________ keycloak-dev mailing list keycloak-dev at lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150325/ae1bb201/attachment.html From stian at redhat.com Wed Mar 25 03:01:17 2015 From: stian at redhat.com (Stian Thorgersen) Date: Wed, 25 Mar 2015 03:01:17 -0400 (EDT) Subject: [keycloak-dev] Internationalization In-Reply-To: <1a517cd2-ed1d-4fce-926c-2719708ab8ee@me.com> References: <1a517cd2-ed1d-4fce-926c-2719708ab8ee@me.com> Message-ID: <1172053699.4701971.1427266877244.JavaMail.zimbra@redhat.com> ----- Original Message ----- > From: "Michael Gerber" > To: "Stian Thorgersen" > Cc: keycloak-dev at lists.jboss.org > Sent: Wednesday, 25 March, 2015 7:36:36 AM > Subject: Re: [keycloak-dev] Internationalization > > > > Am 23. M?rz 2015 um 10:51 schrieb Stian Thorgersen : > > > > ----- Original Message ----- > From: "Michael Gerber" > To: keycloak-dev at lists.jboss.org > Sent: Monday, 23 March, 2015 10:08:55 AM > Subject: [keycloak-dev] Internationalization > > Hi all > > @all developers > Please make sure that you use ISO-8859-1 encoding for your language property > files (messages_en.properties and messages_de.properties) > > @Bill > Can you have a look at the claims and roles internationalization of the > login-oauth-grant.ftl page. > If you want to enable internationalization for a value than you have to enter > it like that: ${username} > Is that ok? > Do we want to enable i18n for the default roles and claims? > > Yes and yes > ?Where is the right place to set a default description for a role? ImportUtils.setupMasterAdminManagement RealmManager.setupRealmAdminManagement > > > > @Stian > There are a few minor gui issues: > - Registration page with a screen resolution of 768*1024 > - Login page in German with a screen resolution of 1024*768 > Should I solve this kind of issues, even if they are not directly related to > the i18n task? > > Sure, but create a JIRA and separate PR please > > > Michael > > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev From stian at redhat.com Wed Mar 25 04:36:14 2015 From: stian at redhat.com (Stian Thorgersen) Date: Wed, 25 Mar 2015 04:36:14 -0400 (EDT) Subject: [keycloak-dev] [GSOC 2015] Keycloak - IoT Security In-Reply-To: References: <555938166.3586490.1427178563201.JavaMail.zimbra@redhat.com> Message-ID: <180564180.4753036.1427272574867.JavaMail.zimbra@redhat.com> ----- Original Message ----- > From: "Bartosz Janota" > To: "Stian Thorgersen" > Cc: keycloak-dev at lists.jboss.org > Sent: Tuesday, 24 March, 2015 9:46:50 AM > Subject: Re: [keycloak-dev] [GSOC 2015] Keycloak - IoT Security > > Hi Stian, > > Thank you for your answer. I'm really happy you like my sundial, I > appreciate that. > I came up with implementation myself. Then me and my friend built and > implemented this sundial as a final project for microprocessor systems > classes. You can go through the documentation available here: > http://student.agh.edu.pl/~bjanota/DokumentacjaZegarSloneczny_v4.pdf if you > are interested. Unfortunately it is written in Polish, nevertheless, you > can get some details seeing pictures and code samples. > > Yes of course, I have Java experience. I am member of two Scientific Group > Sections and one of them is focusing on creating projects, we implemented > some Java projects in the past - this is where I started my adventure with > Java. I'm Scala Developer in my current work (earlier I was Java Dev, in > the same company), so I am able to create products in Java as well :). > > If you ask about security - I passed Security of computer systems course at > my university - I am familiar with security techniques. In my work we (in > fact me and my two friends) develop analytic tool (written in Scala) which > handles over 1kk unique requests per day form unique users, we must take > care about security - it works well, so I can say I have some experience > with security. > > At the end I'd like to add that during the last semester I built a Meetup > client application based on OAuth2.0, you can see code here: > https://github.com/BartoszJanota/swipetup (it is also deployed, you can > find URL in README). I am familiar with OAuth protocol, so I think I will > be able to use OpenID Connect with ease :). > > Sounds great, I love coding projects when I can do what I really want and > it is my own idea. I can't imagine working with Keycloak without physical > implementation on hardware devices, I will definitely use some devices :). > > So as I understood, now you don't have any ideas or implemented any samples > that use Keycloak and can be run on IoT devices? Which device can you > personally suggest? Will you choose platform or should I do it on my own > (assuming I would be accepted)? Your expectations sound good to me. Up to you! I would like an idea of what you want to do included in the proposal. With regards to devices they should be cheap and generic. Raspberry Pi obviously stands out, but if there are other devices that's better suited to what you'd like to do that's fine as well. I'm not sure if we can provide you with any devices, so if you have something suitable already that'd be perfect. > > Best, > Bartosz > > On Tue, 24 Mar 2015 at 07:29 Stian Thorgersen wrote: > > > I like your sundial, did you come up with the implementation yourself or > > did you follow instructions from somewhere else? > > > > Do you have any experience with Java or security? > > > > The IoT project is left vague intentionally. I'd like the student who > > undertakes the project to come up with an idea for the project. What we > > want is something that can demonstrate the use of Keycloak and OpenID > > Connect in IoT. Expected outcomes would be a POC/demo, instructions on how > > to reproduce and possibly some improvements to Keycloak if required. > > Ideally if you use any hardware devices (which is quite likely ;)) they > > should be cheap and generic so we can reproduce it ourselves. > > > > If you have any more questions feel free to ask. > > > > ----- Original Message ----- > > > From: "Bartosz Janota" > > > To: keycloak-dev at lists.jboss.org > > > Sent: Monday, 23 March, 2015 7:00:35 PM > > > Subject: [keycloak-dev] [GSOC 2015] Keycloak - IoT Security > > > > > > Hi Everyone :), > > > > > > My name is Bartosz Janota and I started my Master's Degree (Computer > > Science) > > > at AGH University of Science and Technology in Krakow, Poland this month. > > > > > > I'm interested in developing Keycloak - IoT Security and I have some > > > arguments to prove that. > > > > > > First of all I'm a big fan of IoT, I like mobile gadgets and automotive > > > industry - it is strongly connected with IoT. Connecting hobby with GSoC > > can > > > be very efficient. > > > > > > Next, I have an experience with IoT. I finished IoT course with 5.0 > > (held at > > > my University). We were programming Intel Galileo boards. We designed and > > > implemented some solutions for smart house. You can see more details > > about > > > the course here: http://www.ki.agh.edu.pl/strona/agh-copernicus and > > > http://galaxy.agh.edu.pl/~tszydlo/copernicus/ . > > > > > > At the end I would like to mention that me and my friend designed and > > > implemented a digital sundial based on Raspberry Pi. You can watch this > > > short movie to see how it works: > > > https://onedrive.live.com/?cid=a0b283703bd03412&id=A0B283703 > > BD03412%212026&ithint=video,.mp4&authkey=!AGkDFXapyN9gMM4 > > > , If you are interested in more details about this project I can show you > > > technical documentation. > > > > > > To sum it up, I'm interesting in participating in Keycloak - IoT Security > > > project. Can you please give me more details about this project? Which > > IoT > > > platforms do you consider? > > > > > > I'm looking forward to hearing from you, > > > Bartosz Janota > > > > > > > > > > > > > > > _______________________________________________ > > > keycloak-dev mailing list > > > keycloak-dev at lists.jboss.org > > > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > From lkrzyzan at redhat.com Wed Mar 25 06:07:16 2015 From: lkrzyzan at redhat.com (=?utf-8?Q?Libor_Krzy=C5=BEanek?=) Date: Wed, 25 Mar 2015 11:07:16 +0100 Subject: [keycloak-dev] Cannot login to fresh KC + Postgres setup Message-ID: <7DDA7569-58D4-42CF-867E-0A28CF60B169@redhat.com> Hi, I have the latest 1.2.0-Beta1 installation and I cannot login via admin/admin to master realm after fresh installation. I see tables in postgres but cannot login. Deployment is EAP 6.3 with proper modules + Postgres 9.2.8 (everything on Openshift, in keycloak-server.json I uses Openshift?s Postgres datasource defined in standalone.xml) I?m checking tables and I see keycloak=# select * from USER_ENTITY; id | email | email_constraint | email_verified | enabled | federation_link | first_name | last_name | realm_id | totp | username --------------------------------------+-------+--------------------------------------+----------------+---------+-----------------+------------+-----------+----------+------+---------- e8620950-494a-422a-9430-bf8a001b64b6 | | 05634ab8-5856-4587-a42b-9dadb1eef591 | f | t | | | | master | f | admin (1 row) keycloak=# select * from credential where user_id='e8620950-494a-422a-9430-bf8a001b64b6'; id | device | hash_iterations | salt | type | value | user_id --------------------------------------+--------+-----------------+------------------------------------+----------+------------------------------------------------------------------------------------------+-------------------------------------- 675d7483-746e-4195-a544-327027890492 | | 1 | \xa1a0aa3ca2e4ef65e26794805ed1248c | password | b8Ue+oLgrvdUWp4bzKAXoFfSli90ENUSPp439uIqks8iOMcMypjetKYbwZI8Qu1sTwXVZwdEJ6hVf/9hGa66FQ== | e8620950-494a-422a-9430-bf8a001b64b6 (1 row) However USERNAME_LOGIN_FAILURE is empty. rhdssodev2=# select * from USERNAME_LOGIN_FAILURE; realm_id | username | failed_login_not_before | last_failure | last_ip_failure | num_failures ----------+----------+-------------------------+--------------+-----------------+-------------- (0 rows) Is it known issue? Here is snippet from log: 2015/03/25 06:02:34,378 WARN [org.jboss.resteasy.core.ResourceLocator] (http-/127.5.255.129:8080-3) Field uriInfo of subresource org.keycloak.services.resources.LoginActionsService will not be injected according to spec 2015/03/25 06:02:34,378 WARN [org.jboss.resteasy.core.ResourceLocator] (http-/127.5.255.129:8080-3) Field clientConnection of subresource org.keycloak.services.resources.LoginActionsService will not be injected according to spec 2015/03/25 06:02:34,378 WARN [org.jboss.resteasy.core.ResourceLocator] (http-/127.5.255.129:8080-3) Field providers of subresource org.keycloak.services.resources.LoginActionsService will not be injected according to spec 2015/03/25 06:02:34,378 WARN [org.jboss.resteasy.core.ResourceLocator] (http-/127.5.255.129:8080-3) Field session of subresource org.keycloak.services.resources.LoginActionsService will not be injected according to spec 2015/03/25 06:02:34,423 DEBUG [org.keycloak.services.managers.AuthenticationManager] (http-/127.5.255.129:8080-3) validating password for user: admin 2015/03/25 06:02:34,424 DEBUG [org.keycloak.services.managers.AuthenticationManager] (http-/127.5.255.129:8080-3) Expiring remember me cookie 2015/03/25 06:02:34,425 DEBUG [org.keycloak.services.managers.AuthenticationManager] (http-/127.5.255.129:8080-3) Expiring cookie: KEYCLOAK_REMEMBER_ME path: /auth/realms/master 2015/03/25 06:02:34,431 DEBUG [freemarker.cache] (http-/127.5.255.129:8080-3) "template.ftl"["en_US",UTF-8,parsed] using cached since vfs:/content/ROOT.war/WEB-INF/lib/keycloak-forms-common-themes-1.2.0.Beta1-SNAPSHOT.jar/theme/base/login/template.ftl didn't change. Thanks, Libor Krzy?anek jboss.org Development Team From lkrzyzan at redhat.com Wed Mar 25 06:15:30 2015 From: lkrzyzan at redhat.com (=?utf-8?Q?Libor_Krzy=C5=BEanek?=) Date: Wed, 25 Mar 2015 11:15:30 +0100 Subject: [keycloak-dev] Cannot login to fresh KC + Postgres setup In-Reply-To: <7DDA7569-58D4-42CF-867E-0A28CF60B169@redhat.com> References: <7DDA7569-58D4-42CF-867E-0A28CF60B169@redhat.com> Message-ID: When I switch to ExampleDS (H2 DB) everything works as expected. Doesn?t work with PostgreSQLDS Thanks, Libor Krzy?anek jboss.org Development Team > On 25 Mar 2015, at 11:07, Libor Krzy?anek wrote: > > Hi, > I have the latest 1.2.0-Beta1 installation and I cannot login via admin/admin to master realm after fresh installation. > > I see tables in postgres but cannot login. > > Deployment is EAP 6.3 with proper modules + Postgres 9.2.8 (everything on Openshift, in keycloak-server.json I uses Openshift?s Postgres datasource defined in standalone.xml) > > I?m checking tables and I see > > keycloak=# select * from USER_ENTITY; > id | email | email_constraint | email_verified | enabled | federation_link | first_name | last_name | realm_id | totp | username > --------------------------------------+-------+--------------------------------------+----------------+---------+-----------------+------------+-----------+----------+------+---------- > e8620950-494a-422a-9430-bf8a001b64b6 | | 05634ab8-5856-4587-a42b-9dadb1eef591 | f | t | | | | master | f | admin > (1 row) > > keycloak=# select * from credential where user_id='e8620950-494a-422a-9430-bf8a001b64b6'; > id | device | hash_iterations | salt | type | value | user_id > --------------------------------------+--------+-----------------+------------------------------------+----------+------------------------------------------------------------------------------------------+-------------------------------------- > 675d7483-746e-4195-a544-327027890492 | | 1 | \xa1a0aa3ca2e4ef65e26794805ed1248c | password | b8Ue+oLgrvdUWp4bzKAXoFfSli90ENUSPp439uIqks8iOMcMypjetKYbwZI8Qu1sTwXVZwdEJ6hVf/9hGa66FQ== | e8620950-494a-422a-9430-bf8a001b64b6 > (1 row) > > However USERNAME_LOGIN_FAILURE is empty. > > rhdssodev2=# select * from USERNAME_LOGIN_FAILURE; > realm_id | username | failed_login_not_before | last_failure | last_ip_failure | num_failures > ----------+----------+-------------------------+--------------+-----------------+-------------- > (0 rows) > > > Is it known issue? > > > Here is snippet from log: > 2015/03/25 06:02:34,378 WARN [org.jboss.resteasy.core.ResourceLocator] (http-/127.5.255.129:8080-3) Field uriInfo of subresource org.keycloak.services.resources.LoginActionsService will not be injected according to spec > 2015/03/25 06:02:34,378 WARN [org.jboss.resteasy.core.ResourceLocator] (http-/127.5.255.129:8080-3) Field clientConnection of subresource org.keycloak.services.resources.LoginActionsService will not be injected according to spec > 2015/03/25 06:02:34,378 WARN [org.jboss.resteasy.core.ResourceLocator] (http-/127.5.255.129:8080-3) Field providers of subresource org.keycloak.services.resources.LoginActionsService will not be injected according to spec > 2015/03/25 06:02:34,378 WARN [org.jboss.resteasy.core.ResourceLocator] (http-/127.5.255.129:8080-3) Field session of subresource org.keycloak.services.resources.LoginActionsService will not be injected according to spec > 2015/03/25 06:02:34,423 DEBUG [org.keycloak.services.managers.AuthenticationManager] (http-/127.5.255.129:8080-3) validating password for user: admin > 2015/03/25 06:02:34,424 DEBUG [org.keycloak.services.managers.AuthenticationManager] (http-/127.5.255.129:8080-3) Expiring remember me cookie > 2015/03/25 06:02:34,425 DEBUG [org.keycloak.services.managers.AuthenticationManager] (http-/127.5.255.129:8080-3) Expiring cookie: KEYCLOAK_REMEMBER_ME path: /auth/realms/master > 2015/03/25 06:02:34,431 DEBUG [freemarker.cache] (http-/127.5.255.129:8080-3) "template.ftl"["en_US",UTF-8,parsed] using cached since vfs:/content/ROOT.war/WEB-INF/lib/keycloak-forms-common-themes-1.2.0.Beta1-SNAPSHOT.jar/theme/base/login/template.ftl didn't change. > > > > Thanks, > > Libor Krzy?anek > jboss.org Development Team > > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150325/077ecaab/attachment.html From lkrzyzan at redhat.com Wed Mar 25 06:33:48 2015 From: lkrzyzan at redhat.com (=?utf-8?Q?Libor_Krzy=C5=BEanek?=) Date: Wed, 25 Mar 2015 11:33:48 +0100 Subject: [keycloak-dev] Cannot login to fresh KC + Postgres setup In-Reply-To: References: <7DDA7569-58D4-42CF-867E-0A28CF60B169@redhat.com> Message-ID: <822AC853-4307-47A3-933D-5E592B37A31E@redhat.com> Seems I found the problem. Openshift has old Postgres JDBC driver (8.4, JDBC 3) Should be 9.2 JDBC4. (See https://access.redhat.com/articles/111663 ) Thanks, Libor Krzy?anek jboss.org Development Team > On 25 Mar 2015, at 11:15, Libor Krzy?anek wrote: > > When I switch to ExampleDS (H2 DB) everything works as expected. > > Doesn?t work with PostgreSQLDS > > Thanks, > > Libor Krzy?anek > jboss.org Development Team > >> On 25 Mar 2015, at 11:07, Libor Krzy?anek > wrote: >> >> Hi, >> I have the latest 1.2.0-Beta1 installation and I cannot login via admin/admin to master realm after fresh installation. >> >> I see tables in postgres but cannot login. >> >> Deployment is EAP 6.3 with proper modules + Postgres 9.2.8 (everything on Openshift, in keycloak-server.json I uses Openshift?s Postgres datasource defined in standalone.xml) >> >> I?m checking tables and I see >> >> keycloak=# select * from USER_ENTITY; >> id | email | email_constraint | email_verified | enabled | federation_link | first_name | last_name | realm_id | totp | username >> --------------------------------------+-------+--------------------------------------+----------------+---------+-----------------+------------+-----------+----------+------+---------- >> e8620950-494a-422a-9430-bf8a001b64b6 | | 05634ab8-5856-4587-a42b-9dadb1eef591 | f | t | | | | master | f | admin >> (1 row) >> >> keycloak=# select * from credential where user_id='e8620950-494a-422a-9430-bf8a001b64b6'; >> id | device | hash_iterations | salt | type | value | user_id >> --------------------------------------+--------+-----------------+------------------------------------+----------+------------------------------------------------------------------------------------------+-------------------------------------- >> 675d7483-746e-4195-a544-327027890492 | | 1 | \xa1a0aa3ca2e4ef65e26794805ed1248c | password | b8Ue+oLgrvdUWp4bzKAXoFfSli90ENUSPp439uIqks8iOMcMypjetKYbwZI8Qu1sTwXVZwdEJ6hVf/9hGa66FQ== | e8620950-494a-422a-9430-bf8a001b64b6 >> (1 row) >> >> However USERNAME_LOGIN_FAILURE is empty. >> >> rhdssodev2=# select * from USERNAME_LOGIN_FAILURE; >> realm_id | username | failed_login_not_before | last_failure | last_ip_failure | num_failures >> ----------+----------+-------------------------+--------------+-----------------+-------------- >> (0 rows) >> >> >> Is it known issue? >> >> >> Here is snippet from log: >> 2015/03/25 06:02:34,378 WARN [org.jboss.resteasy.core.ResourceLocator] (http-/127.5.255.129:8080-3) Field uriInfo of subresource org.keycloak.services.resources.LoginActionsService will not be injected according to spec >> 2015/03/25 06:02:34,378 WARN [org.jboss.resteasy.core.ResourceLocator] (http-/127.5.255.129:8080-3) Field clientConnection of subresource org.keycloak.services.resources.LoginActionsService will not be injected according to spec >> 2015/03/25 06:02:34,378 WARN [org.jboss.resteasy.core.ResourceLocator] (http-/127.5.255.129:8080-3) Field providers of subresource org.keycloak.services.resources.LoginActionsService will not be injected according to spec >> 2015/03/25 06:02:34,378 WARN [org.jboss.resteasy.core.ResourceLocator] (http-/127.5.255.129:8080-3) Field session of subresource org.keycloak.services.resources.LoginActionsService will not be injected according to spec >> 2015/03/25 06:02:34,423 DEBUG [org.keycloak.services.managers.AuthenticationManager] (http-/127.5.255.129:8080-3) validating password for user: admin >> 2015/03/25 06:02:34,424 DEBUG [org.keycloak.services.managers.AuthenticationManager] (http-/127.5.255.129:8080-3) Expiring remember me cookie >> 2015/03/25 06:02:34,425 DEBUG [org.keycloak.services.managers.AuthenticationManager] (http-/127.5.255.129:8080-3) Expiring cookie: KEYCLOAK_REMEMBER_ME path: /auth/realms/master >> 2015/03/25 06:02:34,431 DEBUG [freemarker.cache] (http-/127.5.255.129:8080-3) "template.ftl"["en_US",UTF-8,parsed] using cached since vfs:/content/ROOT.war/WEB-INF/lib/keycloak-forms-common-themes-1.2.0.Beta1-SNAPSHOT.jar/theme/base/login/template.ftl didn't change. >> >> >> >> Thanks, >> >> Libor Krzy?anek >> jboss.org Development Team >> >> >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150325/dc057edf/attachment-0001.html From mposolda at redhat.com Wed Mar 25 07:27:24 2015 From: mposolda at redhat.com (Marek Posolda) Date: Wed, 25 Mar 2015 12:27:24 +0100 Subject: [keycloak-dev] Restrict admins to only allow granting roles they are privileged to In-Reply-To: <981150942.4609053.1427262586429.JavaMail.zimbra@redhat.com> References: <981150942.4609053.1427262586429.JavaMail.zimbra@redhat.com> Message-ID: <55129B9C.80901@redhat.com> +1 for the simple fix, however I agree that more flexibility might be needed. We may need some more fine grained authorization. For example user is authorized to manage application "app1" but not application "app2" (currently user with "manage-applications" role can manage any application). Similarly I may want some user to grant/revoke other users all application roles of particular application etc. I wonder if we should add the concept of "permission" ? Basically permission would consist of action and target object (could support wildcards). Permissions are given to roles. For example current role "manage-applications" will have permissions like this: - create-applications - update-applications: * - remove-application: * So member of this role can CRUD any application. Now when users from role "myapp1/foo-role" should be able to grant/revoke this role to other users, the permission given to the foo-role will be: - grant-role: "myapp1", "foo-role" When users from role "myapp1/bar-role" should be able to grant/revoke all roles from application "myapp1" to other users, the permission will be: - grant-role: "myapp1", "*" The tricky part is to have the permission model flexible enough, but not be too complex at the same time;-) Maybe it should be driven mainly by real use-cases from community? Marek On 25.3.2015 06:49, Stian Thorgersen wrote: > I propose we add a check when an admin wants to grant a role. For a admin to be allowed to grant a role the admin either has to have the admin/realm-admin role or have the role itself. This prevents admins from adding more privileges to themselves than they already have and would also be a way to allow admins that can only manage roles for specific applications. > > This should be a simple fix. In the future I think we may need to re-design how we map permissions for Keycloak. I'm really not that happy with the realm apps and such, it's messy and not flexible enough. > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev From stian at redhat.com Wed Mar 25 07:52:06 2015 From: stian at redhat.com (Stian Thorgersen) Date: Wed, 25 Mar 2015 07:52:06 -0400 (EDT) Subject: [keycloak-dev] Restrict admins to only allow granting roles they are privileged to In-Reply-To: <55129B9C.80901@redhat.com> References: <981150942.4609053.1427262586429.JavaMail.zimbra@redhat.com> <55129B9C.80901@redhat.com> Message-ID: <371265024.4883064.1427284326590.JavaMail.zimbra@redhat.com> ----- Original Message ----- > From: "Marek Posolda" > To: keycloak-dev at lists.jboss.org > Sent: Wednesday, 25 March, 2015 12:27:24 PM > Subject: Re: [keycloak-dev] Restrict admins to only allow granting roles they are privileged to > > +1 for the simple fix, however I agree that more flexibility might be > needed. Sure, but we have tons of work that has higher priority so we couldn't do that for a while > > We may need some more fine grained authorization. For example user is > authorized to manage application "app1" but not application "app2" > (currently user with "manage-applications" role can manage any > application). Similarly I may want some user to grant/revoke other users > all application roles of particular application etc. > > I wonder if we should add the concept of "permission" ? Basically > permission would consist of action and target object (could support > wildcards). Permissions are given to roles. For example current role > "manage-applications" will have permissions like this: > - create-applications > - update-applications: * > - remove-application: * > > So member of this role can CRUD any application. > > Now when users from role "myapp1/foo-role" should be able to > grant/revoke this role to other users, the permission given to the > foo-role will be: > - grant-role: "myapp1", "foo-role" > > When users from role "myapp1/bar-role" should be able to grant/revoke > all roles from application "myapp1" to other users, the permission will be: > - grant-role: "myapp1", "*" > > The tricky part is to have the permission model flexible enough, but not > be too complex at the same time;-) > Maybe it should be driven mainly by real use-cases from community? I don't see the difference in that to just having more roles. We could just have a manage-app role for individual applications. > > Marek > > On 25.3.2015 06:49, Stian Thorgersen wrote: > > I propose we add a check when an admin wants to grant a role. For a admin > > to be allowed to grant a role the admin either has to have the > > admin/realm-admin role or have the role itself. This prevents admins from > > adding more privileges to themselves than they already have and would also > > be a way to allow admins that can only manage roles for specific > > applications. > > > > This should be a simple fix. In the future I think we may need to re-design > > how we map permissions for Keycloak. I'm really not that happy with the > > realm apps and such, it's messy and not flexible enough. > > _______________________________________________ > > keycloak-dev mailing list > > keycloak-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > From ssilvert at redhat.com Wed Mar 25 08:11:44 2015 From: ssilvert at redhat.com (Stan Silvert) Date: Wed, 25 Mar 2015 08:11:44 -0400 Subject: [keycloak-dev] Java 8? In-Reply-To: <1917315183.4615751.1427263296081.JavaMail.zimbra@redhat.com> References: <55107BB0.1000200@redhat.com> <1917315183.4615751.1427263296081.JavaMail.zimbra@redhat.com> Message-ID: <5512A600.9090007@redhat.com> On 3/25/2015 2:01 AM, Stian Thorgersen wrote: > It's to early for us to drop support for Java 7, especially for adapters. The testsuite needs to run with both Java 7 and 8. Yea, I agree about that. Right now the only requirement is that the elytron tests require Java 8 at runtime. I don't need to actually use it from a source perspective. Aslak wrote a nice article on gradual migration of a project to Java 8. https://gist.github.com/aslakknutsen/9648594 > > I suggest we add a new module for those tests (testsuite/elytron) and use a Maven profile to run them only when the profile is active. > > ----- Original Message ----- >> From: "Stan Silvert" >> To: keycloak-dev at lists.jboss.org >> Sent: Monday, 23 March, 2015 9:46:40 PM >> Subject: [keycloak-dev] Java 8? >> >> Java 7 is end of life next month. Elytron requires Java 8. >> >> Any opinion on when we should start using it? If I keep Elytron tests >> in the testsuite then the testsuite would need to run with Java 8. >> >> Stan >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> From bdawidow at redhat.com Wed Mar 25 08:20:01 2015 From: bdawidow at redhat.com (=?UTF-8?B?Qm9sZXPFgmF3IERhd2lkb3dpY3o=?=) Date: Wed, 25 Mar 2015 13:20:01 +0100 Subject: [keycloak-dev] Restrict admins to only allow granting roles they are privileged to In-Reply-To: <371265024.4883064.1427284326590.JavaMail.zimbra@redhat.com> References: <981150942.4609053.1427262586429.JavaMail.zimbra@redhat.com> <55129B9C.80901@redhat.com> <371265024.4883064.1427284326590.JavaMail.zimbra@redhat.com> Message-ID: <5512A7F1.5000400@redhat.com> On 25/03/15 12:52, Stian Thorgersen wrote: > > > ----- Original Message ----- >> From: "Marek Posolda" To: >> keycloak-dev at lists.jboss.org Sent: Wednesday, 25 March, 2015 >> 12:27:24 PM Subject: Re: [keycloak-dev] Restrict admins to only >> allow granting roles they are privileged to >> >> +1 for the simple fix, however I agree that more flexibility might >> be needed. > > Sure, but we have tons of work that has higher priority so we > couldn't do that for a while Also before we do anything more we need to sync with other pojects with similar requirements to make sure we have something meeting their reqs. Hawcular has such needs. FeedHenry guys have. etc. > >> >> We may need some more fine grained authorization. For example user >> is authorized to manage application "app1" but not application >> "app2" (currently user with "manage-applications" role can manage >> any application). Similarly I may want some user to grant/revoke >> other users all application roles of particular application etc. >> >> I wonder if we should add the concept of "permission" ? Basically >> permission would consist of action and target object (could >> support wildcards). Permissions are given to roles. For example >> current role "manage-applications" will have permissions like >> this: - create-applications - update-applications: * - >> remove-application: * >> >> So member of this role can CRUD any application. >> >> Now when users from role "myapp1/foo-role" should be able to >> grant/revoke this role to other users, the permission given to the >> foo-role will be: - grant-role: "myapp1", "foo-role" >> >> When users from role "myapp1/bar-role" should be able to >> grant/revoke all roles from application "myapp1" to other users, >> the permission will be: - grant-role: "myapp1", "*" >> >> The tricky part is to have the permission model flexible enough, >> but not be too complex at the same time;-) Maybe it should be >> driven mainly by real use-cases from community? > > I don't see the difference in that to just having more roles. We > could just have a manage-app role for individual applications. Depends how much apps/roles you need have. You get nasty looking app specific role names although I agree you can still cover most of common needs Permissions makes more sense if you try to include app specific resources, org structure in form of groups and etc. Then doing anything with just roles radically increases their number and makes it very hard to manage. > >> >> Marek >> >> On 25.3.2015 06:49, Stian Thorgersen wrote: >>> I propose we add a check when an admin wants to grant a role. For >>> a admin to be allowed to grant a role the admin either has to >>> have the admin/realm-admin role or have the role itself. This >>> prevents admins from adding more privileges to themselves than >>> they already have and would also be a way to allow admins that >>> can only manage roles for specific applications. >>> >>> This should be a simple fix. In the future I think we may need to >>> re-design how we map permissions for Keycloak. I'm really not >>> that happy with the realm apps and such, it's messy and not >>> flexible enough. _______________________________________________ >>> keycloak-dev mailing list keycloak-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> >> _______________________________________________ keycloak-dev >> mailing list keycloak-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> > _______________________________________________ keycloak-dev mailing > list keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > -- Boles?aw Dawidowicz From stian at redhat.com Wed Mar 25 08:22:00 2015 From: stian at redhat.com (Stian Thorgersen) Date: Wed, 25 Mar 2015 08:22:00 -0400 (EDT) Subject: [keycloak-dev] Java 8? In-Reply-To: <5512A600.9090007@redhat.com> References: <55107BB0.1000200@redhat.com> <1917315183.4615751.1427263296081.JavaMail.zimbra@redhat.com> <5512A600.9090007@redhat.com> Message-ID: <932378584.4905544.1427286120115.JavaMail.zimbra@redhat.com> That article doesn't make sense to me. Use Java8 for tests, but Java7 in production, whaaat? We need our testsuite to run on Java7, so can't take that approach. ----- Original Message ----- > From: "Stan Silvert" > To: "Stian Thorgersen" > Cc: keycloak-dev at lists.jboss.org > Sent: Wednesday, 25 March, 2015 1:11:44 PM > Subject: Re: [keycloak-dev] Java 8? > > On 3/25/2015 2:01 AM, Stian Thorgersen wrote: > > It's to early for us to drop support for Java 7, especially for adapters. > > The testsuite needs to run with both Java 7 and 8. > Yea, I agree about that. Right now the only requirement is that the > elytron tests require Java 8 at runtime. I don't need to actually use > it from a source perspective. > > Aslak wrote a nice article on gradual migration of a project to Java 8. > https://gist.github.com/aslakknutsen/9648594 > > > > I suggest we add a new module for those tests (testsuite/elytron) and use a > > Maven profile to run them only when the profile is active. > > > > ----- Original Message ----- > >> From: "Stan Silvert" > >> To: keycloak-dev at lists.jboss.org > >> Sent: Monday, 23 March, 2015 9:46:40 PM > >> Subject: [keycloak-dev] Java 8? > >> > >> Java 7 is end of life next month. Elytron requires Java 8. > >> > >> Any opinion on when we should start using it? If I keep Elytron tests > >> in the testsuite then the testsuite would need to run with Java 8. > >> > >> Stan > >> _______________________________________________ > >> keycloak-dev mailing list > >> keycloak-dev at lists.jboss.org > >> https://lists.jboss.org/mailman/listinfo/keycloak-dev > >> > > From ssilvert at redhat.com Wed Mar 25 09:08:38 2015 From: ssilvert at redhat.com (Stan Silvert) Date: Wed, 25 Mar 2015 09:08:38 -0400 Subject: [keycloak-dev] Java 8? In-Reply-To: <932378584.4905544.1427286120115.JavaMail.zimbra@redhat.com> References: <55107BB0.1000200@redhat.com> <1917315183.4615751.1427263296081.JavaMail.zimbra@redhat.com> <5512A600.9090007@redhat.com> <932378584.4905544.1427286120115.JavaMail.zimbra@redhat.com> Message-ID: <5512B356.7030507@redhat.com> On 3/25/2015 8:22 AM, Stian Thorgersen wrote: > That article doesn't make sense to me. Use Java8 for tests, but Java7 in production, whaaat? > > We need our testsuite to run on Java7, so can't take that approach. I could do it for Elytron tests since they only run under Java 8 anyway. :-) For this discussion, I'm just trying to get a feel for when we might make the switch. I agree it may be a long way off for adapters. But I just got confirmation the WildFly 10 will require Java 8. If that's our target platform for productization maybe we should target Java 8 for the server side to coincide with that. Maybe Bolek has a better idea of the productization timing? > > ----- Original Message ----- >> From: "Stan Silvert" >> To: "Stian Thorgersen" >> Cc: keycloak-dev at lists.jboss.org >> Sent: Wednesday, 25 March, 2015 1:11:44 PM >> Subject: Re: [keycloak-dev] Java 8? >> >> On 3/25/2015 2:01 AM, Stian Thorgersen wrote: >>> It's to early for us to drop support for Java 7, especially for adapters. >>> The testsuite needs to run with both Java 7 and 8. >> Yea, I agree about that. Right now the only requirement is that the >> elytron tests require Java 8 at runtime. I don't need to actually use >> it from a source perspective. >> >> Aslak wrote a nice article on gradual migration of a project to Java 8. >> https://gist.github.com/aslakknutsen/9648594 >>> I suggest we add a new module for those tests (testsuite/elytron) and use a >>> Maven profile to run them only when the profile is active. >>> >>> ----- Original Message ----- >>>> From: "Stan Silvert" >>>> To: keycloak-dev at lists.jboss.org >>>> Sent: Monday, 23 March, 2015 9:46:40 PM >>>> Subject: [keycloak-dev] Java 8? >>>> >>>> Java 7 is end of life next month. Elytron requires Java 8. >>>> >>>> Any opinion on when we should start using it? If I keep Elytron tests >>>> in the testsuite then the testsuite would need to run with Java 8. >>>> >>>> Stan >>>> _______________________________________________ >>>> keycloak-dev mailing list >>>> keycloak-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>>> >> From jpkroehling at redhat.com Wed Mar 25 09:12:53 2015 From: jpkroehling at redhat.com (=?UTF-8?B?SnVyYWNpIFBhaXjDo28gS3LDtmhsaW5n?=) Date: Wed, 25 Mar 2015 14:12:53 +0100 Subject: [keycloak-dev] Restrict admins to only allow granting roles they are privileged to In-Reply-To: <5512A7F1.5000400@redhat.com> References: <981150942.4609053.1427262586429.JavaMail.zimbra@redhat.com> <55129B9C.80901@redhat.com> <371265024.4883064.1427284326590.JavaMail.zimbra@redhat.com> <5512A7F1.5000400@redhat.com> Message-ID: <5512B455.4080009@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 03/25/2015 01:20 PM, Boles?aw Dawidowicz wrote: > Also before we do anything more we need to sync with other pojects > with similar requirements to make sure we have something meeting > their reqs. Hawcular has such needs. FeedHenry guys have. etc. Hawkular absolutely have a need for something like that, but at the time, we are doing it by ourselves, mainly because our multi-tenancy concept doesn't maps nicely with Keycloak's. What would probably help is to have the PicketLink's Permission API available (with the notion of partitions, resources and so on), but I guess that the PicketLink integration will still take some time to happen. - - Juca. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBAgAGBQJVErRVAAoJECKM1e+fkPrXu/YIAJRJ+QqOnwsyCjokiqmCvzG1 qCk3zq+xHMFYtX5TG2BkOGHUc3Bpn7Bp/jiLfeNAT1Q6IpH/meuenwBFbjRS8GoA Vl/sjDndwjH915yVdIt/Pt2GZiIr69ScvXMPZPhmNv4INCcr5YCq9AgPNUOlhWVM bm54/mveUd98ozFwxTwFZLvypoha+VXVNSq9k99PzuAlNIYJw7IOTNQ0p2WZBL2B eTSuu2ZBBn6/1ERz+eI0zY1cOXd/nOwfd7VDC8NgxehaG1SMBvo+C+QVTNz2hCA6 pPI3ZKyfDXI9yRfrYsBSkTjhziFv+Z3U82NzcBIFPv0Z2lB29d02iMttQVUZ1RU= =WqlZ -----END PGP SIGNATURE----- From bburke at redhat.com Wed Mar 25 09:49:11 2015 From: bburke at redhat.com (Bill Burke) Date: Wed, 25 Mar 2015 09:49:11 -0400 Subject: [keycloak-dev] usersession-based UserModels In-Reply-To: <385614498.4610662.1427262904300.JavaMail.zimbra@redhat.com> References: <55117AA4.70707@redhat.com> <385614498.4610662.1427262904300.JavaMail.zimbra@redhat.com> Message-ID: <5512BCD7.4080109@redhat.com> Not sure if this would be a rare case. Right now our solution is a bit heavyweight when we have external systems (brokered or UserFederationProvider) as we require a lot of database writes for those that log in for the 1st time. I don't think users have hit this yet because they haven't hit us with a lot of requests. On 3/25/2015 1:55 AM, Stian Thorgersen wrote: > Sounds like it would make sense for the SAML transient use-case you mentioned, but do we have other use-cases for it? Wouldn't it be a fairly big change for a rare use-case? > > Unless we start supporting IdP logins without provisioning an internal account, but that would be a pretty big change as well for something we haven't had a request for. > > ----- Original Message ----- >> From: "Bill Burke" >> To: keycloak-dev at lists.jboss.org >> Sent: Tuesday, 24 March, 2015 3:54:28 PM >> Subject: [keycloak-dev] usersession-based UserModels >> >> I'm thinking more and more we need UserSession based UserModels. This >> would be the case where nothing is imported for a user with either >> brokering or federation, but rather stored in memory for the duration of >> the UserSession. >> >> If user metadata (role mappings, etc.) is all obtained from external >> sources, there really is no need to import the data and import is just a >> huge performance hit. >> >> I ran into this with "transient" nameid format and SAML brokering. In >> this scenario the parent IDP generates a new userid each and every >> login. This is to define an anonymous user. So, every time a user logs >> in would create a brand new user in the keycloak database. >> >> -- >> Bill Burke >> JBoss, a division of Red Hat >> http://bill.burkecentral.com >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From bburke at redhat.com Wed Mar 25 09:52:07 2015 From: bburke at redhat.com (Bill Burke) Date: Wed, 25 Mar 2015 09:52:07 -0400 Subject: [keycloak-dev] social/broker errors Message-ID: <5512BD87.8070309@redhat.com> I'll look into all the social/broker errors and test out on all social providers (again) after I finish up some logout work. -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From stian at redhat.com Wed Mar 25 09:54:31 2015 From: stian at redhat.com (Stian Thorgersen) Date: Wed, 25 Mar 2015 09:54:31 -0400 (EDT) Subject: [keycloak-dev] usersession-based UserModels In-Reply-To: <5512BCD7.4080109@redhat.com> References: <55117AA4.70707@redhat.com> <385614498.4610662.1427262904300.JavaMail.zimbra@redhat.com> <5512BCD7.4080109@redhat.com> Message-ID: <1189605800.4979735.1427291671504.JavaMail.zimbra@redhat.com> If we don't create a user in the db for a federated or brokered user wouldn't we loose a lot of functionality like: * Account management * Required actions * Linking multiple brokered/federated accounts with a single internal account ----- Original Message ----- > From: "Bill Burke" > To: "Stian Thorgersen" > Cc: keycloak-dev at lists.jboss.org > Sent: Wednesday, 25 March, 2015 2:49:11 PM > Subject: Re: [keycloak-dev] usersession-based UserModels > > Not sure if this would be a rare case. Right now our solution is a bit > heavyweight when we have external systems (brokered or > UserFederationProvider) as we require a lot of database writes for those > that log in for the 1st time. I don't think users have hit this yet > because they haven't hit us with a lot of requests. > > On 3/25/2015 1:55 AM, Stian Thorgersen wrote: > > Sounds like it would make sense for the SAML transient use-case you > > mentioned, but do we have other use-cases for it? Wouldn't it be a fairly > > big change for a rare use-case? > > > > Unless we start supporting IdP logins without provisioning an internal > > account, but that would be a pretty big change as well for something we > > haven't had a request for. > > > > ----- Original Message ----- > >> From: "Bill Burke" > >> To: keycloak-dev at lists.jboss.org > >> Sent: Tuesday, 24 March, 2015 3:54:28 PM > >> Subject: [keycloak-dev] usersession-based UserModels > >> > >> I'm thinking more and more we need UserSession based UserModels. This > >> would be the case where nothing is imported for a user with either > >> brokering or federation, but rather stored in memory for the duration of > >> the UserSession. > >> > >> If user metadata (role mappings, etc.) is all obtained from external > >> sources, there really is no need to import the data and import is just a > >> huge performance hit. > >> > >> I ran into this with "transient" nameid format and SAML brokering. In > >> this scenario the parent IDP generates a new userid each and every > >> login. This is to define an anonymous user. So, every time a user logs > >> in would create a brand new user in the keycloak database. > >> > >> -- > >> Bill Burke > >> JBoss, a division of Red Hat > >> http://bill.burkecentral.com > >> _______________________________________________ > >> keycloak-dev mailing list > >> keycloak-dev at lists.jboss.org > >> https://lists.jboss.org/mailman/listinfo/keycloak-dev > >> > > -- > Bill Burke > JBoss, a division of Red Hat > http://bill.burkecentral.com > From stian at redhat.com Wed Mar 25 09:57:38 2015 From: stian at redhat.com (Stian Thorgersen) Date: Wed, 25 Mar 2015 09:57:38 -0400 (EDT) Subject: [keycloak-dev] social/broker errors In-Reply-To: <5512BD87.8070309@redhat.com> References: <5512BD87.8070309@redhat.com> Message-ID: <909393773.4987133.1427291858754.JavaMail.zimbra@redhat.com> Had a quick look at it and seems Facebook and GitHub return access token response as form-url-encoded (access_token=<...>&foo=bar). Another thing I spotted was that I'm pretty sure we're not validating the SSL connection when sending requests to the IdPs. We should drop the SimpleHttp util I created and use something better (Apache or RestEasy) and make sure it's possible to setup a truststore). SimpleHttp was only created as we initially wanted the social lib to be a reusable lightweight lib, but now it's only for KC so there's no point in it and it's pretty crap for many reasons! ----- Original Message ----- > From: "Bill Burke" > To: keycloak-dev at lists.jboss.org > Sent: Wednesday, 25 March, 2015 2:52:07 PM > Subject: [keycloak-dev] social/broker errors > > I'll look into all the social/broker errors and test out on all social > providers (again) after I finish up some logout work. > -- > Bill Burke > JBoss, a division of Red Hat > http://bill.burkecentral.com > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > From stian at redhat.com Wed Mar 25 10:07:33 2015 From: stian at redhat.com (Stian Thorgersen) Date: Wed, 25 Mar 2015 10:07:33 -0400 (EDT) Subject: [keycloak-dev] Invalid value for iss In-Reply-To: <238954058.4998514.1427292362202.JavaMail.zimbra@redhat.com> Message-ID: <1400722694.5003313.1427292453113.JavaMail.zimbra@redhat.com> According to the spec 'iss' should be: REQUIRED. Issuer Identifier for the Issuer of the response. The iss value is a case sensitive URL using the https scheme that contains scheme, host, and optionally, port number and path components and no query or fragment components However, we only use realm name. As that's invalid according to the spec (and also the same iss used for multiple KC servers) I propose we change it to: /realms/ For example: http://localhost:8080/realms/master From bburke at redhat.com Wed Mar 25 10:09:11 2015 From: bburke at redhat.com (Bill Burke) Date: Wed, 25 Mar 2015 10:09:11 -0400 Subject: [keycloak-dev] usersession-based UserModels In-Reply-To: <1189605800.4979735.1427291671504.JavaMail.zimbra@redhat.com> References: <55117AA4.70707@redhat.com> <385614498.4610662.1427262904300.JavaMail.zimbra@redhat.com> <5512BCD7.4080109@redhat.com> <1189605800.4979735.1427291671504.JavaMail.zimbra@redhat.com> Message-ID: <5512C187.8060601@redhat.com> On 3/25/2015 9:54 AM, Stian Thorgersen wrote: > If we don't create a user in the db for a federated or brokered user wouldn't we loose a lot of functionality like: > > * Account management > * Required actions > * Linking multiple brokered/federated accounts with a single internal account > Maybe you're right, but most of those things don't make sense if you're completely delegating login to an external provider. I worry how many users just want to use us as a bridge between their external IDPs and their web apps. -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From bburke at redhat.com Wed Mar 25 10:12:41 2015 From: bburke at redhat.com (Bill Burke) Date: Wed, 25 Mar 2015 10:12:41 -0400 Subject: [keycloak-dev] Invalid value for iss In-Reply-To: <1400722694.5003313.1427292453113.JavaMail.zimbra@redhat.com> References: <1400722694.5003313.1427292453113.JavaMail.zimbra@redhat.com> Message-ID: <5512C259.1040103@redhat.com> This requires changes to a lot of code. I started doing it once until I realized how many files I would have to change. On 3/25/2015 10:07 AM, Stian Thorgersen wrote: > According to the spec 'iss' should be: > > REQUIRED. Issuer Identifier for the Issuer of the response. The iss value is a case sensitive URL using the https scheme that contains scheme, host, and optionally, port number and path components and no query or fragment components > > However, we only use realm name. As that's invalid according to the spec (and also the same iss used for multiple KC servers) I propose we change it to: > > /realms/ > > For example: > > http://localhost:8080/realms/master > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From stian at redhat.com Wed Mar 25 10:15:45 2015 From: stian at redhat.com (Stian Thorgersen) Date: Wed, 25 Mar 2015 10:15:45 -0400 (EDT) Subject: [keycloak-dev] usersession-based UserModels In-Reply-To: <5512C187.8060601@redhat.com> References: <55117AA4.70707@redhat.com> <385614498.4610662.1427262904300.JavaMail.zimbra@redhat.com> <5512BCD7.4080109@redhat.com> <1189605800.4979735.1427291671504.JavaMail.zimbra@redhat.com> <5512C187.8060601@redhat.com> Message-ID: <153679129.5015882.1427292945716.JavaMail.zimbra@redhat.com> ----- Original Message ----- > From: "Bill Burke" > To: "Stian Thorgersen" > Cc: keycloak-dev at lists.jboss.org > Sent: Wednesday, 25 March, 2015 3:09:11 PM > Subject: Re: [keycloak-dev] usersession-based UserModels > > > > On 3/25/2015 9:54 AM, Stian Thorgersen wrote: > > If we don't create a user in the db for a federated or brokered user > > wouldn't we loose a lot of functionality like: > > > > * Account management > > * Required actions > > * Linking multiple brokered/federated accounts with a single internal > > account > > > > Maybe you're right, but most of those things don't make sense if you're > completely delegating login to an external provider. I worry how many > users just want to use us as a bridge between their external IDPs and > their web apps. As that's a valid use-case maybe we could have an option on how it's done. We could have a toggle on a realm or individual idps/federators on whether or not users should be provisioned in KC. Users that are not provisioned in KC would have limited functionality. It's a pretty big dev task to add though, so probably yet another great idea for the road-map?! > > > -- > Bill Burke > JBoss, a division of Red Hat > http://bill.burkecentral.com > From stian at redhat.com Wed Mar 25 10:17:23 2015 From: stian at redhat.com (Stian Thorgersen) Date: Wed, 25 Mar 2015 10:17:23 -0400 (EDT) Subject: [keycloak-dev] Invalid value for iss In-Reply-To: <5512C259.1040103@redhat.com> References: <1400722694.5003313.1427292453113.JavaMail.zimbra@redhat.com> <5512C259.1040103@redhat.com> Message-ID: <562453784.5016931.1427293043259.JavaMail.zimbra@redhat.com> Yeah I know, but we're not going to be compliant unless we do. Also more fundamentally is the fact that the 'iss' value for tokens generated by different servers would be the same so given a token you can't actually know where's it from atm. I'm happy to do the work, unless you've got some other strong arguments against changing it? ----- Original Message ----- > From: "Bill Burke" > To: keycloak-dev at lists.jboss.org > Sent: Wednesday, 25 March, 2015 3:12:41 PM > Subject: Re: [keycloak-dev] Invalid value for iss > > This requires changes to a lot of code. I started doing it once until I > realized how many files I would have to change. > > On 3/25/2015 10:07 AM, Stian Thorgersen wrote: > > According to the spec 'iss' should be: > > > > REQUIRED. Issuer Identifier for the Issuer of the response. The iss > > value is a case sensitive URL using the https scheme that contains > > scheme, host, and optionally, port number and path components and no > > query or fragment components > > > > However, we only use realm name. As that's invalid according to the spec > > (and also the same iss used for multiple KC servers) I propose we change > > it to: > > > > /realms/ > > > > For example: > > > > http://localhost:8080/realms/master > > _______________________________________________ > > keycloak-dev mailing list > > keycloak-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > > -- > Bill Burke > JBoss, a division of Red Hat > http://bill.burkecentral.com > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > From stian at redhat.com Wed Mar 25 10:20:30 2015 From: stian at redhat.com (Stian Thorgersen) Date: Wed, 25 Mar 2015 10:20:30 -0400 (EDT) Subject: [keycloak-dev] Invalid value for iss In-Reply-To: <562453784.5016931.1427293043259.JavaMail.zimbra@redhat.com> References: <1400722694.5003313.1427292453113.JavaMail.zimbra@redhat.com> <5512C259.1040103@redhat.com> <562453784.5016931.1427293043259.JavaMail.zimbra@redhat.com> Message-ID: <1660904734.5020915.1427293230761.JavaMail.zimbra@redhat.com> Actually I can only find 6 places that uses getIssuer in the code, one of which is KeycloakSecurityContext.getRealm, but that can just be changed to return only the last bit of issuer if we follow the proposed format. ----- Original Message ----- > From: "Stian Thorgersen" > To: "Bill Burke" > Cc: keycloak-dev at lists.jboss.org > Sent: Wednesday, 25 March, 2015 3:17:23 PM > Subject: Re: [keycloak-dev] Invalid value for iss > > Yeah I know, but we're not going to be compliant unless we do. Also more > fundamentally is the fact that the 'iss' value for tokens generated by > different servers would be the same so given a token you can't actually know > where's it from atm. > > I'm happy to do the work, unless you've got some other strong arguments > against changing it? > > ----- Original Message ----- > > From: "Bill Burke" > > To: keycloak-dev at lists.jboss.org > > Sent: Wednesday, 25 March, 2015 3:12:41 PM > > Subject: Re: [keycloak-dev] Invalid value for iss > > > > This requires changes to a lot of code. I started doing it once until I > > realized how many files I would have to change. > > > > On 3/25/2015 10:07 AM, Stian Thorgersen wrote: > > > According to the spec 'iss' should be: > > > > > > REQUIRED. Issuer Identifier for the Issuer of the response. The iss > > > value is a case sensitive URL using the https scheme that contains > > > scheme, host, and optionally, port number and path components and no > > > query or fragment components > > > > > > However, we only use realm name. As that's invalid according to the spec > > > (and also the same iss used for multiple KC servers) I propose we change > > > it to: > > > > > > /realms/ > > > > > > For example: > > > > > > http://localhost:8080/realms/master > > > _______________________________________________ > > > keycloak-dev mailing list > > > keycloak-dev at lists.jboss.org > > > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > > > > > -- > > Bill Burke > > JBoss, a division of Red Hat > > http://bill.burkecentral.com > > _______________________________________________ > > keycloak-dev mailing list > > keycloak-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > From velias at redhat.com Wed Mar 25 10:43:44 2015 From: velias at redhat.com (Vlastimil Elias) Date: Wed, 25 Mar 2015 15:43:44 +0100 Subject: [keycloak-dev] social/broker errors In-Reply-To: <909393773.4987133.1427291858754.JavaMail.zimbra@redhat.com> References: <5512BD87.8070309@redhat.com> <909393773.4987133.1427291858754.JavaMail.zimbra@redhat.com> Message-ID: <5512C9A0.1050409@redhat.com> Same is StackOverflow provider I added on monday, it doesn't work now. Problem is in AbstractOAuth2IdentityProvider class, where extractTokenFromResponse() method (which was able to distinguish between JSON and URL encoded responses) is not used anymore, but direct JSON parsing is used now. We should return back use of extractTokenFromResponse() Vl. On 25.3.2015 14:57, Stian Thorgersen wrote: > Had a quick look at it and seems Facebook and GitHub return access token response as form-url-encoded (access_token=<...>&foo=bar). > > Another thing I spotted was that I'm pretty sure we're not validating the SSL connection when sending requests to the IdPs. We should drop the SimpleHttp util I created and use something better (Apache or RestEasy) and make sure it's possible to setup a truststore). SimpleHttp was only created as we initially wanted the social lib to be a reusable lightweight lib, but now it's only for KC so there's no point in it and it's pretty crap for many reasons! > > ----- Original Message ----- >> From: "Bill Burke" >> To: keycloak-dev at lists.jboss.org >> Sent: Wednesday, 25 March, 2015 2:52:07 PM >> Subject: [keycloak-dev] social/broker errors >> >> I'll look into all the social/broker errors and test out on all social >> providers (again) after I finish up some logout work. >> -- >> Bill Burke >> JBoss, a division of Red Hat >> http://bill.burkecentral.com >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev -- Vlastimil Elias Principal Software Engineer jboss.org Development Team From velias at redhat.com Wed Mar 25 10:56:13 2015 From: velias at redhat.com (Vlastimil Elias) Date: Wed, 25 Mar 2015 15:56:13 +0100 Subject: [keycloak-dev] social/broker errors In-Reply-To: <909393773.4987133.1427291858754.JavaMail.zimbra@redhat.com> References: <5512BD87.8070309@redhat.com> <909393773.4987133.1427291858754.JavaMail.zimbra@redhat.com> Message-ID: <5512CC8D.8010002@redhat.com> On 25.3.2015 14:57, Stian Thorgersen wrote: > Had a quick look at it and seems Facebook and GitHub return access token response as form-url-encoded (access_token=<...>&foo=bar). > > Another thing I spotted was that I'm pretty sure we're not validating the SSL connection when sending requests to the IdPs. We should drop the SimpleHttp util I created and use something better (Apache or RestEasy) and make sure it's possible to setup a truststore). SimpleHttp was only created as we initially wanted the social lib to be a reusable lightweight lib, but now it's only for KC so there's no point in it and it's pretty crap for many reasons! SimpleHttp uses common java HttpsURLConnection which by default validates https certificates against common JVM truststore (typically cacerts somewhere in java installation directory) as I know. See http://docs.oracle.com/javase/7/docs/api/javax/net/ssl/HttpsURLConnection.html and http://docs.oracle.com/javase/8/docs/technotes/guides/security/jsse/JSSERefGuide.html Vl. > > ----- Original Message ----- >> From: "Bill Burke" >> To: keycloak-dev at lists.jboss.org >> Sent: Wednesday, 25 March, 2015 2:52:07 PM >> Subject: [keycloak-dev] social/broker errors >> >> I'll look into all the social/broker errors and test out on all social >> providers (again) after I finish up some logout work. >> -- >> Bill Burke >> JBoss, a division of Red Hat >> http://bill.burkecentral.com >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev -- Vlastimil Elias Principal Software Engineer jboss.org Development Team From mposolda at redhat.com Wed Mar 25 11:02:07 2015 From: mposolda at redhat.com (Marek Posolda) Date: Wed, 25 Mar 2015 16:02:07 +0100 Subject: [keycloak-dev] social/broker errors In-Reply-To: <909393773.4987133.1427291858754.JavaMail.zimbra@redhat.com> References: <5512BD87.8070309@redhat.com> <909393773.4987133.1427291858754.JavaMail.zimbra@redhat.com> Message-ID: <5512CDEF.2050401@redhat.com> Question about logout: Should logout always trigger parent broker logout even if "child" is not the initiator of parent SSO login? Some example: I have keycloak server on configured to login against Salesforce SAML broker 1) I login to Salesforce 2) Then I login to Keycloak with usage of Salesforce broker 3) Now I trigger logout from Keycloak. Should it trigger logout from Salesforce too? IMO it shouldn't as localhost:8081 wasn't the initiator of the Salesforce login (in step 1). Wdyt? Marek On 25.3.2015 14:57, Stian Thorgersen wrote: > Had a quick look at it and seems Facebook and GitHub return access token response as form-url-encoded (access_token=<...>&foo=bar). > > Another thing I spotted was that I'm pretty sure we're not validating the SSL connection when sending requests to the IdPs. We should drop the SimpleHttp util I created and use something better (Apache or RestEasy) and make sure it's possible to setup a truststore). SimpleHttp was only created as we initially wanted the social lib to be a reusable lightweight lib, but now it's only for KC so there's no point in it and it's pretty crap for many reasons! > > ----- Original Message ----- >> From: "Bill Burke" >> To: keycloak-dev at lists.jboss.org >> Sent: Wednesday, 25 March, 2015 2:52:07 PM >> Subject: [keycloak-dev] social/broker errors >> >> I'll look into all the social/broker errors and test out on all social >> providers (again) after I finish up some logout work. >> -- >> Bill Burke >> JBoss, a division of Red Hat >> http://bill.burkecentral.com >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev From bburke at redhat.com Wed Mar 25 11:27:47 2015 From: bburke at redhat.com (Bill Burke) Date: Wed, 25 Mar 2015 11:27:47 -0400 Subject: [keycloak-dev] social/broker errors In-Reply-To: <5512CDEF.2050401@redhat.com> References: <5512BD87.8070309@redhat.com> <909393773.4987133.1427291858754.JavaMail.zimbra@redhat.com> <5512CDEF.2050401@redhat.com> Message-ID: <5512D3F3.8010604@redhat.com> So Salesforce IDP is the "parent" and Keycloak is the child? I think Salesforce IDP should be logged out as well, because think of it this way 1. user logs out of keycloak app, but doesn't get logged out of Salesforce 2. user goes away form machine 3. Attacker sits down at desk 4. Attacker visits keycloak app 5. Still logged in at Salesforce, so keycloak app has a successful login due to SSO. I have Currently, if you don't register a logout url for saml or oidc broker providers, then logout isn't propagated to parent IDP. Parent to child logout will always happen though. I have no controls in place for that. I do not support logout for social providers. We might want to have a prompt asking if the user should be logged out from parent. On 3/25/2015 11:02 AM, Marek Posolda wrote: > Question about logout: Should logout always trigger parent broker logout > even if "child" is not the initiator of parent SSO login? > > Some example: I have keycloak server on configured to login against > Salesforce SAML broker > > 1) I login to Salesforce > 2) Then I login to Keycloak with usage of Salesforce broker > 3) Now I trigger logout from Keycloak. Should it trigger logout from > Salesforce too? IMO it shouldn't as localhost:8081 wasn't the initiator > of the Salesforce login (in step 1). > > Wdyt? > > Marek > > > On 25.3.2015 14:57, Stian Thorgersen wrote: >> Had a quick look at it and seems Facebook and GitHub return access >> token response as form-url-encoded (access_token=<...>&foo=bar). >> >> Another thing I spotted was that I'm pretty sure we're not validating >> the SSL connection when sending requests to the IdPs. We should drop >> the SimpleHttp util I created and use something better (Apache or >> RestEasy) and make sure it's possible to setup a truststore). >> SimpleHttp was only created as we initially wanted the social lib to >> be a reusable lightweight lib, but now it's only for KC so there's no >> point in it and it's pretty crap for many reasons! >> >> ----- Original Message ----- >>> From: "Bill Burke" >>> To: keycloak-dev at lists.jboss.org >>> Sent: Wednesday, 25 March, 2015 2:52:07 PM >>> Subject: [keycloak-dev] social/broker errors >>> >>> I'll look into all the social/broker errors and test out on all social >>> providers (again) after I finish up some logout work. >>> -- >>> Bill Burke >>> JBoss, a division of Red Hat >>> http://bill.burkecentral.com >>> _______________________________________________ >>> keycloak-dev mailing list >>> keycloak-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>> >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev > -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From mposolda at redhat.com Wed Mar 25 12:23:02 2015 From: mposolda at redhat.com (Marek Posolda) Date: Wed, 25 Mar 2015 17:23:02 +0100 Subject: [keycloak-dev] social/broker errors In-Reply-To: <5512D3F3.8010604@redhat.com> References: <5512BD87.8070309@redhat.com> <909393773.4987133.1427291858754.JavaMail.zimbra@redhat.com> <5512CDEF.2050401@redhat.com> <5512D3F3.8010604@redhat.com> Message-ID: <5512E0E6.8000804@redhat.com> On 25.3.2015 16:27, Bill Burke wrote: > So Salesforce IDP is the "parent" and Keycloak is the child? Yes > I think Salesforce IDP should be logged out as well, because think > of it this way > > 1. user logs out of keycloak app, but doesn't get logged out of > Salesforce > 2. user goes away form machine > 3. Attacker sits down at desk > 4. Attacker visits keycloak app > 5. Still logged in at Salesforce, so keycloak app has a successful > login due to SSO. I see the point. However if you consider scenario like: 1. I am logged in salesforce.com and doing some important transactions there 2. Now I clicked to different browser tab and want to quickly check something in some keycloak-secured-app. I logged-in to the app through Keycloak + Salesforce broker 3. I checked calendar, clicked "logout" in Zimbra and I want to continue back in Salesforce. But I am logged out from Salesforce... :-( The prompt makes sense to me. At least for the cases when user was logged in before. But not sure if there is a way to track this (In case that Keycloak itself is parent broker, we can check if auth-method was FORM (user just logged in) or SSO (user was already logged before)), but that would require propagate this info from parent broker to child broker too. Maybe easiest is to always display prompt? Marek > > I have > > Currently, if you don't register a logout url for saml or oidc broker > providers, then logout isn't propagated to parent IDP. Parent to child > logout will always happen though. I have no controls in place for that. > > I do not support logout for social providers. > > We might want to have a prompt asking if the user should be logged out > from parent. > > > > On 3/25/2015 11:02 AM, Marek Posolda wrote: >> Question about logout: Should logout always trigger parent broker logout >> even if "child" is not the initiator of parent SSO login? >> >> Some example: I have keycloak server on configured to login against >> Salesforce SAML broker >> >> 1) I login to Salesforce >> 2) Then I login to Keycloak with usage of Salesforce broker >> 3) Now I trigger logout from Keycloak. Should it trigger logout from >> Salesforce too? IMO it shouldn't as localhost:8081 wasn't the initiator >> of the Salesforce login (in step 1). >> >> Wdyt? >> >> Marek >> >> >> On 25.3.2015 14:57, Stian Thorgersen wrote: >>> Had a quick look at it and seems Facebook and GitHub return access >>> token response as form-url-encoded (access_token=<...>&foo=bar). >>> >>> Another thing I spotted was that I'm pretty sure we're not validating >>> the SSL connection when sending requests to the IdPs. We should drop >>> the SimpleHttp util I created and use something better (Apache or >>> RestEasy) and make sure it's possible to setup a truststore). >>> SimpleHttp was only created as we initially wanted the social lib to >>> be a reusable lightweight lib, but now it's only for KC so there's no >>> point in it and it's pretty crap for many reasons! >>> >>> ----- Original Message ----- >>>> From: "Bill Burke" >>>> To: keycloak-dev at lists.jboss.org >>>> Sent: Wednesday, 25 March, 2015 2:52:07 PM >>>> Subject: [keycloak-dev] social/broker errors >>>> >>>> I'll look into all the social/broker errors and test out on all social >>>> providers (again) after I finish up some logout work. >>>> -- >>>> Bill Burke >>>> JBoss, a division of Red Hat >>>> http://bill.burkecentral.com >>>> _______________________________________________ >>>> keycloak-dev mailing list >>>> keycloak-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>>> >>> _______________________________________________ >>> keycloak-dev mailing list >>> keycloak-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> > From mposolda at redhat.com Wed Mar 25 12:25:27 2015 From: mposolda at redhat.com (Marek Posolda) Date: Wed, 25 Mar 2015 17:25:27 +0100 Subject: [keycloak-dev] ClientModel.get/setAllowedClaimsMask In-Reply-To: <574987363.9595042.1426773098992.JavaMail.zimbra@redhat.com> References: <574987363.9595042.1426773098992.JavaMail.zimbra@redhat.com> Message-ID: <5512E177.8090807@redhat.com> Any idea on this? I am seeing that ClientModel.get/setAllowedClaimsMask is not "actively" used and was replaced by protocol mappers. I am working on migration, so I can remove those from the model now and also remove all related stuff (ClaimResource etc). Anyone has objection against this? Marek On 19.3.2015 14:51, Stian Thorgersen wrote: > Am I correct in thinking that these are no longer used and should be removed? > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev From bburke at redhat.com Wed Mar 25 19:15:33 2015 From: bburke at redhat.com (Bill Burke) Date: Wed, 25 Mar 2015 19:15:33 -0400 Subject: [keycloak-dev] ClientModel.get/setAllowedClaimsMask In-Reply-To: <5512E177.8090807@redhat.com> References: <574987363.9595042.1426773098992.JavaMail.zimbra@redhat.com> <5512E177.8090807@redhat.com> Message-ID: <55134195.80200@redhat.com> They are obsolete, so thanks for cleaning up. On 3/25/2015 12:25 PM, Marek Posolda wrote: > Any idea on this? I am seeing that ClientModel.get/setAllowedClaimsMask > is not "actively" used and was replaced by protocol mappers. I am > working on migration, so I can remove those from the model now and also > remove all related stuff (ClaimResource etc). Anyone has objection > against this? > > Marek > > On 19.3.2015 14:51, Stian Thorgersen wrote: >> Am I correct in thinking that these are no longer used and should be removed? >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From bburke at redhat.com Wed Mar 25 19:18:48 2015 From: bburke at redhat.com (Bill Burke) Date: Wed, 25 Mar 2015 19:18:48 -0400 Subject: [keycloak-dev] social/broker errors In-Reply-To: <5512E0E6.8000804@redhat.com> References: <5512BD87.8070309@redhat.com> <909393773.4987133.1427291858754.JavaMail.zimbra@redhat.com> <5512CDEF.2050401@redhat.com> <5512D3F3.8010604@redhat.com> <5512E0E6.8000804@redhat.com> Message-ID: <55134258.9020806@redhat.com> On 3/25/2015 12:23 PM, Marek Posolda wrote: > On 25.3.2015 16:27, Bill Burke wrote: >> So Salesforce IDP is the "parent" and Keycloak is the child? > Yes >> I think Salesforce IDP should be logged out as well, because think >> of it this way >> >> 1. user logs out of keycloak app, but doesn't get logged out of >> Salesforce >> 2. user goes away form machine >> 3. Attacker sits down at desk >> 4. Attacker visits keycloak app >> 5. Still logged in at Salesforce, so keycloak app has a successful >> login due to SSO. > I see the point. However if you consider scenario like: > > 1. I am logged in salesforce.com and doing some important transactions > there > 2. Now I clicked to different browser tab and want to quickly check > something in some keycloak-secured-app. I logged-in to the app through > Keycloak + Salesforce broker > 3. I checked calendar, clicked "logout" in Zimbra and I want to continue > back in Salesforce. But I am logged out from Salesforce... :-( > > > The prompt makes sense to me. At least for the cases when user was > logged in before. But not sure if there is a way to track this (In case > that Keycloak itself is parent broker, we can check if auth-method was > FORM (user just logged in) or SSO (user was already logged before)), but > that would require propagate this info from parent broker to child > broker too. Maybe easiest is to always display prompt? > What should the prompt say? User will have no idea what it means by "Should I logout of parent broker?" Maybe "Logout of too?" i.e. "Logout of Saleforce too?" "Logout of Facebook too?" -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From bburke at redhat.com Wed Mar 25 19:23:15 2015 From: bburke at redhat.com (Bill Burke) Date: Wed, 25 Mar 2015 19:23:15 -0400 Subject: [keycloak-dev] identity broker changes In-Reply-To: <550CA816.2030906@redhat.com> References: <550CA816.2030906@redhat.com> Message-ID: <55134363.2030506@redhat.com> Finished backchannel logout for oidc and saml. Created a "Keycloak OIDC" type that handles our logout protocol. had to make changes to UserSessionProvider and Model to get this to work (and work efficiently). I think I fixed facebook and github login, but I haven't tested it yet. Still need to: * Make sure appliance works (all the module dependency stuff) * Write automated tests * Auto-import certificate for OIDC validation and .well-known address * Review to make sure error handling is correct. Tests too for this. Gonna take me awhile to write all the tests :( On 3/20/2015 7:07 PM, Bill Burke wrote: > SPI has changed to support logout and multiple callback endpoints (i.e. > keycloak oidc chaining will require a logout callback). This SPI is > quite complex, so I don't think we want to expose this to users. I'm > not very happy with it, but I'm not sure how to improve it yet. > > What works now: > * If logged in via a SAML broker, a keycloak initiated browser logout > will log out of the SAML broker too. > > What do I still need to do: > * Make "UPdate profile" false by default. > * Improve saml admin console page. > * Implement OIDC broker keycloak initiated browser logout. > * Implement OIDC logout endpoint so that I can test OIDC brokering with > Keycloak as a parent. > * Implement SAML backchannel logout where the parent IDP sends a > backchannel logout request. > * Create a new "Keycloak OIDC" provider which extends OIDC and adds > keycloak extensions like logout. > * Review to make sure error handling is correct. > > So, still a lot to do, but I'm at a milestone. > > -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From stian at redhat.com Thu Mar 26 01:22:41 2015 From: stian at redhat.com (Stian Thorgersen) Date: Thu, 26 Mar 2015 01:22:41 -0400 (EDT) Subject: [keycloak-dev] social/broker errors In-Reply-To: <55134258.9020806@redhat.com> References: <5512BD87.8070309@redhat.com> <909393773.4987133.1427291858754.JavaMail.zimbra@redhat.com> <5512CDEF.2050401@redhat.com> <5512D3F3.8010604@redhat.com> <5512E0E6.8000804@redhat.com> <55134258.9020806@redhat.com> Message-ID: <613128602.5635752.1427347361521.JavaMail.zimbra@redhat.com> I don't like the idea of a prompt to the user. I'd rather have a configuration option on IdP to select when logout should be propagated: * Always * Only if used as log-in mechanism * Never Same goes for the other way around (user logs out of SalesForce). ----- Original Message ----- > From: "Bill Burke" > To: "Marek Posolda" , "Stian Thorgersen" > Cc: keycloak-dev at lists.jboss.org > Sent: Thursday, 26 March, 2015 12:18:48 AM > Subject: Re: [keycloak-dev] social/broker errors > > > > On 3/25/2015 12:23 PM, Marek Posolda wrote: > > On 25.3.2015 16:27, Bill Burke wrote: > >> So Salesforce IDP is the "parent" and Keycloak is the child? > > Yes > >> I think Salesforce IDP should be logged out as well, because think > >> of it this way > >> > >> 1. user logs out of keycloak app, but doesn't get logged out of > >> Salesforce > >> 2. user goes away form machine > >> 3. Attacker sits down at desk > >> 4. Attacker visits keycloak app > >> 5. Still logged in at Salesforce, so keycloak app has a successful > >> login due to SSO. > > I see the point. However if you consider scenario like: > > > > 1. I am logged in salesforce.com and doing some important transactions > > there > > 2. Now I clicked to different browser tab and want to quickly check > > something in some keycloak-secured-app. I logged-in to the app through > > Keycloak + Salesforce broker > > 3. I checked calendar, clicked "logout" in Zimbra and I want to continue > > back in Salesforce. But I am logged out from Salesforce... :-( > > > > > > The prompt makes sense to me. At least for the cases when user was > > logged in before. But not sure if there is a way to track this (In case > > that Keycloak itself is parent broker, we can check if auth-method was > > FORM (user just logged in) or SSO (user was already logged before)), but > > that would require propagate this info from parent broker to child > > broker too. Maybe easiest is to always display prompt? > > > > What should the prompt say? User will have no idea what it means by > "Should I logout of parent broker?" > > Maybe "Logout of too?" > > i.e. > > "Logout of Saleforce too?" > "Logout of Facebook too?" > > -- > Bill Burke > JBoss, a division of Red Hat > http://bill.burkecentral.com > From stian at redhat.com Thu Mar 26 01:35:34 2015 From: stian at redhat.com (Stian Thorgersen) Date: Thu, 26 Mar 2015 01:35:34 -0400 (EDT) Subject: [keycloak-dev] identity broker changes In-Reply-To: <55134363.2030506@redhat.com> References: <550CA816.2030906@redhat.com> <55134363.2030506@redhat.com> Message-ID: <979197948.5642944.1427348134562.JavaMail.zimbra@redhat.com> ----- Original Message ----- > From: "Bill Burke" > To: keycloak-dev at lists.jboss.org > Sent: Thursday, 26 March, 2015 12:23:15 AM > Subject: Re: [keycloak-dev] identity broker changes > > Finished backchannel logout for oidc and saml. Created a "Keycloak > OIDC" type that handles our logout protocol. had to make changes to > UserSessionProvider and Model to get this to work (and work > efficiently). I think I fixed facebook and github login, but I haven't > tested it yet. Nice, so we're now implementing the complete openid connect session management spec? > > Still need to: > * Make sure appliance works (all the module dependency stuff) > * Write automated tests > * Auto-import certificate for OIDC validation and .well-known address I assume by auto-import you mean that someone can add an IdP by just supplying the .well-known address? > * Review to make sure error handling is correct. Tests too for this. > > Gonna take me awhile to write all the tests :( > > > > On 3/20/2015 7:07 PM, Bill Burke wrote: > > SPI has changed to support logout and multiple callback endpoints (i.e. > > keycloak oidc chaining will require a logout callback). This SPI is > > quite complex, so I don't think we want to expose this to users. I'm > > not very happy with it, but I'm not sure how to improve it yet. > > > > What works now: > > * If logged in via a SAML broker, a keycloak initiated browser logout > > will log out of the SAML broker too. > > > > What do I still need to do: > > * Make "UPdate profile" false by default. > > * Improve saml admin console page. > > * Implement OIDC broker keycloak initiated browser logout. > > * Implement OIDC logout endpoint so that I can test OIDC brokering with > > Keycloak as a parent. > > * Implement SAML backchannel logout where the parent IDP sends a > > backchannel logout request. > > * Create a new "Keycloak OIDC" provider which extends OIDC and adds > > keycloak extensions like logout. > > * Review to make sure error handling is correct. > > > > So, still a lot to do, but I'm at a milestone. > > > > > > -- > Bill Burke > JBoss, a division of Red Hat > http://bill.burkecentral.com > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > From bdawidow at redhat.com Thu Mar 26 02:32:48 2015 From: bdawidow at redhat.com (Boleslaw Dawidowicz) Date: Thu, 26 Mar 2015 02:32:48 -0400 (EDT) Subject: [keycloak-dev] Java 8? In-Reply-To: <5512B356.7030507@redhat.com> References: <55107BB0.1000200@redhat.com> <1917315183.4615751.1427263296081.JavaMail.zimbra@redhat.com> <5512A600.9090007@redhat.com> <932378584.4905544.1427286120115.JavaMail.zimbra@redhat.com> <5512B356.7030507@redhat.com> Message-ID: <482BC368-90ED-40E7-86F2-1B2D800970F3@redhat.com> WildFly 10 is on what we'll need to align although it rather defines minimum to support. Question is if we package with WF 10 which support only Java 8 will it be practical (and possible) to maintain compat with 7 I would def keep 7 for adapters longer. -- Boles?aw Dawidowicz Dnia 25 mar 2015 o godz. 14:08 Stan Silvert napisa?(a): >> On 3/25/2015 8:22 AM, Stian Thorgersen wrote: >> That article doesn't make sense to me. Use Java8 for tests, but Java7 in production, whaaat? >> >> We need our testsuite to run on Java7, so can't take that approach. > I could do it for Elytron tests since they only run under Java 8 anyway. :-) > > For this discussion, I'm just trying to get a feel for when we might make the switch. I agree it may be a long way off for adapters. > > But I just got confirmation the WildFly 10 will require Java 8. If that's our target platform for productization maybe we should target Java 8 for the server side to coincide with that. > > Maybe Bolek has a better idea of the productization timing? >> >> ----- Original Message ----- >>> From: "Stan Silvert" >>> To: "Stian Thorgersen" >>> Cc: keycloak-dev at lists.jboss.org >>> Sent: Wednesday, 25 March, 2015 1:11:44 PM >>> Subject: Re: [keycloak-dev] Java 8? >>> >>>> On 3/25/2015 2:01 AM, Stian Thorgersen wrote: >>>> It's to early for us to drop support for Java 7, especially for adapters. >>>> The testsuite needs to run with both Java 7 and 8. >>> Yea, I agree about that. Right now the only requirement is that the >>> elytron tests require Java 8 at runtime. I don't need to actually use >>> it from a source perspective. >>> >>> Aslak wrote a nice article on gradual migration of a project to Java 8. >>> https://gist.github.com/aslakknutsen/9648594 >>>> I suggest we add a new module for those tests (testsuite/elytron) and use a >>>> Maven profile to run them only when the profile is active. >>>> >>>> ----- Original Message ----- >>>>> From: "Stan Silvert" >>>>> To: keycloak-dev at lists.jboss.org >>>>> Sent: Monday, 23 March, 2015 9:46:40 PM >>>>> Subject: [keycloak-dev] Java 8? >>>>> >>>>> Java 7 is end of life next month. Elytron requires Java 8. >>>>> >>>>> Any opinion on when we should start using it? If I keep Elytron tests >>>>> in the testsuite then the testsuite would need to run with Java 8. >>>>> >>>>> Stan >>>>> _______________________________________________ >>>>> keycloak-dev mailing list >>>>> keycloak-dev at lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev > From stian at redhat.com Thu Mar 26 02:42:12 2015 From: stian at redhat.com (Stian Thorgersen) Date: Thu, 26 Mar 2015 02:42:12 -0400 (EDT) Subject: [keycloak-dev] Java 8? In-Reply-To: <482BC368-90ED-40E7-86F2-1B2D800970F3@redhat.com> References: <55107BB0.1000200@redhat.com> <1917315183.4615751.1427263296081.JavaMail.zimbra@redhat.com> <5512A600.9090007@redhat.com> <932378584.4905544.1427286120115.JavaMail.zimbra@redhat.com> <5512B356.7030507@redhat.com> <482BC368-90ED-40E7-86F2-1B2D800970F3@redhat.com> Message-ID: <1886633369.5666586.1427352132796.JavaMail.zimbra@redhat.com> ----- Original Message ----- > From: "Boleslaw Dawidowicz" > To: "Stan Silvert" > Cc: "Stian Thorgersen" , keycloak-dev at lists.jboss.org > Sent: Thursday, 26 March, 2015 7:32:48 AM > Subject: Re: [keycloak-dev] Java 8? > > WildFly 10 is on what we'll need to align although it rather defines minimum > to support. Question is if we package with WF 10 which support only Java 8 > will it be practical (and possible) to maintain compat with 7 That's what we need to align on for product yes, but other projects/products that embed Keycloak need it to support whatever they support (BRMS for example doesn't even start on Java8). In summary we need to support Java 7 for a while longer :( > > I would def keep 7 for adapters longer. > > > > -- > Boles?aw Dawidowicz > > Dnia 25 mar 2015 o godz. 14:08 Stan Silvert napisa?(a): > > >> On 3/25/2015 8:22 AM, Stian Thorgersen wrote: > >> That article doesn't make sense to me. Use Java8 for tests, but Java7 in > >> production, whaaat? > >> > >> We need our testsuite to run on Java7, so can't take that approach. > > I could do it for Elytron tests since they only run under Java 8 anyway. > > :-) > > > > For this discussion, I'm just trying to get a feel for when we might make > > the switch. I agree it may be a long way off for adapters. > > > > But I just got confirmation the WildFly 10 will require Java 8. If that's > > our target platform for productization maybe we should target Java 8 for > > the server side to coincide with that. > > > > Maybe Bolek has a better idea of the productization timing? > >> > >> ----- Original Message ----- > >>> From: "Stan Silvert" > >>> To: "Stian Thorgersen" > >>> Cc: keycloak-dev at lists.jboss.org > >>> Sent: Wednesday, 25 March, 2015 1:11:44 PM > >>> Subject: Re: [keycloak-dev] Java 8? > >>> > >>>> On 3/25/2015 2:01 AM, Stian Thorgersen wrote: > >>>> It's to early for us to drop support for Java 7, especially for > >>>> adapters. > >>>> The testsuite needs to run with both Java 7 and 8. > >>> Yea, I agree about that. Right now the only requirement is that the > >>> elytron tests require Java 8 at runtime. I don't need to actually use > >>> it from a source perspective. > >>> > >>> Aslak wrote a nice article on gradual migration of a project to Java 8. > >>> https://gist.github.com/aslakknutsen/9648594 > >>>> I suggest we add a new module for those tests (testsuite/elytron) and > >>>> use a > >>>> Maven profile to run them only when the profile is active. > >>>> > >>>> ----- Original Message ----- > >>>>> From: "Stan Silvert" > >>>>> To: keycloak-dev at lists.jboss.org > >>>>> Sent: Monday, 23 March, 2015 9:46:40 PM > >>>>> Subject: [keycloak-dev] Java 8? > >>>>> > >>>>> Java 7 is end of life next month. Elytron requires Java 8. > >>>>> > >>>>> Any opinion on when we should start using it? If I keep Elytron tests > >>>>> in the testsuite then the testsuite would need to run with Java 8. > >>>>> > >>>>> Stan > >>>>> _______________________________________________ > >>>>> keycloak-dev mailing list > >>>>> keycloak-dev at lists.jboss.org > >>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > From gerbermichi at me.com Thu Mar 26 03:04:42 2015 From: gerbermichi at me.com (Michael Gerber) Date: Thu, 26 Mar 2015 07:04:42 +0000 (GMT) Subject: [keycloak-dev] SPI for multi-factor authentication Message-ID: <7a8581f6-1fb6-4b12-ac15-72006ffcfc70@me.com> Hi all, when do you think will you start with the?SPI for multi-factor authentication?? https://issues.jboss.org/browse/KEYCLOAK-310 Best Michael -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150326/f3f159f4/attachment.html From stian at redhat.com Thu Mar 26 03:33:56 2015 From: stian at redhat.com (Stian Thorgersen) Date: Thu, 26 Mar 2015 03:33:56 -0400 (EDT) Subject: [keycloak-dev] SPI for multi-factor authentication In-Reply-To: <7a8581f6-1fb6-4b12-ac15-72006ffcfc70@me.com> References: <7a8581f6-1fb6-4b12-ac15-72006ffcfc70@me.com> Message-ID: <922831815.5679024.1427355236041.JavaMail.zimbra@redhat.com> I'm currently working on something else, but once I've done that I'd like to look at it. It'll be at least a month, maybe longer depending on priorities. ----- Original Message ----- > From: "Michael Gerber" > To: "keycloak-dev" > Sent: Thursday, 26 March, 2015 8:04:42 AM > Subject: [keycloak-dev] SPI for multi-factor authentication > > Hi all, > > when do you think will you start with the SPI for multi-factor > authentication? > https://issues.jboss.org/browse/KEYCLOAK-310 > > Best > Michael > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev From stian at redhat.com Thu Mar 26 04:11:05 2015 From: stian at redhat.com (Stian Thorgersen) Date: Thu, 26 Mar 2015 04:11:05 -0400 (EDT) Subject: [keycloak-dev] Authentication and Required Actions SPI In-Reply-To: <552419636.5693163.1427357356125.JavaMail.zimbra@redhat.com> Message-ID: <1860135521.5694047.1427357465182.JavaMail.zimbra@redhat.com> I'd like to start on an Authentication SPI soon. At the same time I want to add a Required Actions SPI as it should be very related and work in a similar way. From bburke at redhat.com Thu Mar 26 07:56:46 2015 From: bburke at redhat.com (Bill Burke) Date: Thu, 26 Mar 2015 07:56:46 -0400 Subject: [keycloak-dev] Authentication and Required Actions SPI In-Reply-To: <1860135521.5694047.1427357465182.JavaMail.zimbra@redhat.com> References: <1860135521.5694047.1427357465182.JavaMail.zimbra@redhat.com> Message-ID: <5513F3FE.2010009@redhat.com> We really need to release soon for beta On 3/26/2015 4:11 AM, Stian Thorgersen wrote: > I'd like to start on an Authentication SPI soon. At the same time I want to add a Required Actions SPI as it should be very related and work in a similar way. > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From stian at redhat.com Thu Mar 26 08:02:07 2015 From: stian at redhat.com (Stian Thorgersen) Date: Thu, 26 Mar 2015 08:02:07 -0400 (EDT) Subject: [keycloak-dev] Authentication and Required Actions SPI In-Reply-To: <5513F3FE.2010009@redhat.com> References: <1860135521.5694047.1427357465182.JavaMail.zimbra@redhat.com> <5513F3FE.2010009@redhat.com> Message-ID: <2007432668.5944698.1427371327801.JavaMail.zimbra@redhat.com> Yep, I'm definitively starting this after Beta1 is out the door. ----- Original Message ----- > From: "Bill Burke" > To: keycloak-dev at lists.jboss.org > Sent: Thursday, 26 March, 2015 12:56:46 PM > Subject: Re: [keycloak-dev] Authentication and Required Actions SPI > > We really need to release soon for beta > > On 3/26/2015 4:11 AM, Stian Thorgersen wrote: > > I'd like to start on an Authentication SPI soon. At the same time I want to > > add a Required Actions SPI as it should be very related and work in a > > similar way. > > _______________________________________________ > > keycloak-dev mailing list > > keycloak-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > > -- > Bill Burke > JBoss, a division of Red Hat > http://bill.burkecentral.com > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > From stian at redhat.com Thu Mar 26 08:03:17 2015 From: stian at redhat.com (Stian Thorgersen) Date: Thu, 26 Mar 2015 08:03:17 -0400 (EDT) Subject: [keycloak-dev] identity broker changes In-Reply-To: <55134363.2030506@redhat.com> References: <550CA816.2030906@redhat.com> <55134363.2030506@redhat.com> Message-ID: <1350306721.5944911.1427371397334.JavaMail.zimbra@redhat.com> ----- Original Message ----- > From: "Bill Burke" > To: keycloak-dev at lists.jboss.org > Sent: Thursday, 26 March, 2015 12:23:15 AM > Subject: Re: [keycloak-dev] identity broker changes > > Finished backchannel logout for oidc and saml. Created a "Keycloak > OIDC" type that handles our logout protocol. had to make changes to > UserSessionProvider and Model to get this to work (and work > efficiently). I think I fixed facebook and github login, but I haven't > tested it yet. Facebook and GitHub is still broken in master > > Still need to: > * Make sure appliance works (all the module dependency stuff) > * Write automated tests > * Auto-import certificate for OIDC validation and .well-known address > * Review to make sure error handling is correct. Tests too for this. > > Gonna take me awhile to write all the tests :( > > > > On 3/20/2015 7:07 PM, Bill Burke wrote: > > SPI has changed to support logout and multiple callback endpoints (i.e. > > keycloak oidc chaining will require a logout callback). This SPI is > > quite complex, so I don't think we want to expose this to users. I'm > > not very happy with it, but I'm not sure how to improve it yet. > > > > What works now: > > * If logged in via a SAML broker, a keycloak initiated browser logout > > will log out of the SAML broker too. > > > > What do I still need to do: > > * Make "UPdate profile" false by default. > > * Improve saml admin console page. > > * Implement OIDC broker keycloak initiated browser logout. > > * Implement OIDC logout endpoint so that I can test OIDC brokering with > > Keycloak as a parent. > > * Implement SAML backchannel logout where the parent IDP sends a > > backchannel logout request. > > * Create a new "Keycloak OIDC" provider which extends OIDC and adds > > keycloak extensions like logout. > > * Review to make sure error handling is correct. > > > > So, still a lot to do, but I'm at a milestone. > > > > > > -- > Bill Burke > JBoss, a division of Red Hat > http://bill.burkecentral.com > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > From bburke at redhat.com Thu Mar 26 09:54:27 2015 From: bburke at redhat.com (Bill Burke) Date: Thu, 26 Mar 2015 09:54:27 -0400 Subject: [keycloak-dev] can't figure this out Message-ID: <55140F93.60501@redhat.com> I'm going crazy... I'm testing facebook login with the admin console as the test app. 1. Facebook auth succeeds 2. Redirect back to admin console 3. For some reason admin console doesn't like the redirect URL and does a redirect back to keycloak login with a fragment of #_=_ 4. I'm already logged in, so redirect back 5. Success, but the fragment is #_=_ Login works for github though...I'm freakin stumped. The initial redirect back to the admin console is the same exact redirect uri for both github and facebook. Has anybody seen this before? -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From stian at redhat.com Thu Mar 26 11:11:11 2015 From: stian at redhat.com (Stian Thorgersen) Date: Thu, 26 Mar 2015 11:11:11 -0400 (EDT) Subject: [keycloak-dev] can't figure this out In-Reply-To: <55140F93.60501@redhat.com> References: <55140F93.60501@redhat.com> Message-ID: <288065723.6112068.1427382671466.JavaMail.zimbra@redhat.com> I remember seeing the '#_=_' crap a while ago, I believe that was before Pedro started brokering. ----- Original Message ----- > From: "Bill Burke" > To: keycloak-dev at lists.jboss.org > Sent: Thursday, 26 March, 2015 2:54:27 PM > Subject: [keycloak-dev] can't figure this out > > I'm going crazy... I'm testing facebook login with the admin console as > the test app. > > 1. Facebook auth succeeds > 2. Redirect back to admin console > 3. For some reason admin console doesn't like the redirect URL and does > a redirect back to keycloak login with a fragment of #_=_ > 4. I'm already logged in, so redirect back > 5. Success, but the fragment is #_=_ > > Login works for github though...I'm freakin stumped. The initial > redirect back to the admin console is the same exact redirect uri for > both github and facebook. > > Has anybody seen this before? > > -- > Bill Burke > JBoss, a division of Red Hat > http://bill.burkecentral.com > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > From stian at redhat.com Thu Mar 26 11:12:35 2015 From: stian at redhat.com (Stian Thorgersen) Date: Thu, 26 Mar 2015 11:12:35 -0400 (EDT) Subject: [keycloak-dev] can't figure this out In-Reply-To: <55140F93.60501@redhat.com> References: <55140F93.60501@redhat.com> Message-ID: <229693502.6113286.1427382755501.JavaMail.zimbra@redhat.com> Got the same now, tried to login to account management with Facebook and it's http://localhost:8080/auth/realms/social/account/#_=_ Got no clue where the f#!*&?$ the #_=_ comes from ----- Original Message ----- > From: "Bill Burke" > To: keycloak-dev at lists.jboss.org > Sent: Thursday, 26 March, 2015 2:54:27 PM > Subject: [keycloak-dev] can't figure this out > > I'm going crazy... I'm testing facebook login with the admin console as > the test app. > > 1. Facebook auth succeeds > 2. Redirect back to admin console > 3. For some reason admin console doesn't like the redirect URL and does > a redirect back to keycloak login with a fragment of #_=_ > 4. I'm already logged in, so redirect back > 5. Success, but the fragment is #_=_ > > Login works for github though...I'm freakin stumped. The initial > redirect back to the admin console is the same exact redirect uri for > both github and facebook. > > Has anybody seen this before? > > -- > Bill Burke > JBoss, a division of Red Hat > http://bill.burkecentral.com > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > From stian at redhat.com Thu Mar 26 11:13:51 2015 From: stian at redhat.com (Stian Thorgersen) Date: Thu, 26 Mar 2015 11:13:51 -0400 (EDT) Subject: [keycloak-dev] can't figure this out In-Reply-To: <288065723.6112068.1427382671466.JavaMail.zimbra@redhat.com> References: <55140F93.60501@redhat.com> <288065723.6112068.1427382671466.JavaMail.zimbra@redhat.com> Message-ID: <1208443733.6115419.1427382831254.JavaMail.zimbra@redhat.com> AFAIK Facebook is OAuth2 + custom weird stuff that looks like but isn't OpenID Connect ----- Original Message ----- > From: "Stian Thorgersen" > To: "Bill Burke" > Cc: keycloak-dev at lists.jboss.org > Sent: Thursday, 26 March, 2015 4:11:11 PM > Subject: Re: [keycloak-dev] can't figure this out > > I remember seeing the '#_=_' crap a while ago, I believe that was before > Pedro started brokering. > > ----- Original Message ----- > > From: "Bill Burke" > > To: keycloak-dev at lists.jboss.org > > Sent: Thursday, 26 March, 2015 2:54:27 PM > > Subject: [keycloak-dev] can't figure this out > > > > I'm going crazy... I'm testing facebook login with the admin console as > > the test app. > > > > 1. Facebook auth succeeds > > 2. Redirect back to admin console > > 3. For some reason admin console doesn't like the redirect URL and does > > a redirect back to keycloak login with a fragment of #_=_ > > 4. I'm already logged in, so redirect back > > 5. Success, but the fragment is #_=_ > > > > Login works for github though...I'm freakin stumped. The initial > > redirect back to the admin console is the same exact redirect uri for > > both github and facebook. > > > > Has anybody seen this before? > > > > -- > > Bill Burke > > JBoss, a division of Red Hat > > http://bill.burkecentral.com > > _______________________________________________ > > keycloak-dev mailing list > > keycloak-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > From leonardo.zanivan at gmail.com Thu Mar 26 11:19:39 2015 From: leonardo.zanivan at gmail.com (Leonardo Loch Zanivan) Date: Thu, 26 Mar 2015 15:19:39 +0000 Subject: [keycloak-dev] can't figure this out In-Reply-To: <1208443733.6115419.1427382831254.JavaMail.zimbra@redhat.com> References: <55140F93.60501@redhat.com> <288065723.6112068.1427382671466.JavaMail.zimbra@redhat.com> <1208443733.6115419.1427382831254.JavaMail.zimbra@redhat.com> Message-ID: Facebook adds "#_=_" at the end of redirect URL for "security reasons", so SPA apps won't work unless you remove it. In Angular apps you should remove before call keycloak: if (window.location.hash === '#_=_') { window.location.hash = ''; } On Thu, Mar 26, 2015 at 12:14 PM Stian Thorgersen wrote: > AFAIK Facebook is OAuth2 + custom weird stuff that looks like but isn't > OpenID Connect > > ----- Original Message ----- > > From: "Stian Thorgersen" > > To: "Bill Burke" > > Cc: keycloak-dev at lists.jboss.org > > Sent: Thursday, 26 March, 2015 4:11:11 PM > > Subject: Re: [keycloak-dev] can't figure this out > > > > I remember seeing the '#_=_' crap a while ago, I believe that was before > > Pedro started brokering. > > > > ----- Original Message ----- > > > From: "Bill Burke" > > > To: keycloak-dev at lists.jboss.org > > > Sent: Thursday, 26 March, 2015 2:54:27 PM > > > Subject: [keycloak-dev] can't figure this out > > > > > > I'm going crazy... I'm testing facebook login with the admin console > as > > > the test app. > > > > > > 1. Facebook auth succeeds > > > 2. Redirect back to admin console > > > 3. For some reason admin console doesn't like the redirect URL and does > > > a redirect back to keycloak login with a fragment of #_=_ > > > 4. I'm already logged in, so redirect back > > > 5. Success, but the fragment is #_=_ > > > > > > Login works for github though...I'm freakin stumped. The initial > > > redirect back to the admin console is the same exact redirect uri for > > > both github and facebook. > > > > > > Has anybody seen this before? > > > > > > -- > > > Bill Burke > > > JBoss, a division of Red Hat > > > http://bill.burkecentral.com > > > _______________________________________________ > > > keycloak-dev mailing list > > > keycloak-dev at lists.jboss.org > > > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > > > _______________________________________________ > > keycloak-dev mailing list > > keycloak-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150326/360e0f4b/attachment.html From leonardo.zanivan at gmail.com Thu Mar 26 11:21:49 2015 From: leonardo.zanivan at gmail.com (Leonardo Loch Zanivan) Date: Thu, 26 Mar 2015 15:21:49 +0000 Subject: [keycloak-dev] can't figure this out In-Reply-To: References: <55140F93.60501@redhat.com> <288065723.6112068.1427382671466.JavaMail.zimbra@redhat.com> <1208443733.6115419.1427382831254.JavaMail.zimbra@redhat.com> Message-ID: Ops, you need to remove after keycloak success. Here is an example: keycloakAuth.init({ onLoad: 'login-required' }).success(function(authenticated) { //fix facebook oauth if (window.location.hash === '#_=_') { window.location.hash = ''; } }); On Thu, Mar 26, 2015 at 12:19 PM Leonardo Loch Zanivan < leonardo.zanivan at gmail.com> wrote: > Facebook adds "#_=_" at the end of redirect URL for "security reasons", so > SPA apps won't work unless you remove it. > > In Angular apps you should remove before call keycloak: > > if (window.location.hash === '#_=_') { > window.location.hash = ''; > } > > On Thu, Mar 26, 2015 at 12:14 PM Stian Thorgersen > wrote: > >> AFAIK Facebook is OAuth2 + custom weird stuff that looks like but isn't >> OpenID Connect >> >> ----- Original Message ----- >> > From: "Stian Thorgersen" >> > To: "Bill Burke" >> > Cc: keycloak-dev at lists.jboss.org >> > Sent: Thursday, 26 March, 2015 4:11:11 PM >> > Subject: Re: [keycloak-dev] can't figure this out >> > >> > I remember seeing the '#_=_' crap a while ago, I believe that was before >> > Pedro started brokering. >> > >> > ----- Original Message ----- >> > > From: "Bill Burke" >> > > To: keycloak-dev at lists.jboss.org >> > > Sent: Thursday, 26 March, 2015 2:54:27 PM >> > > Subject: [keycloak-dev] can't figure this out >> > > >> > > I'm going crazy... I'm testing facebook login with the admin console >> as >> > > the test app. >> > > >> > > 1. Facebook auth succeeds >> > > 2. Redirect back to admin console >> > > 3. For some reason admin console doesn't like the redirect URL and >> does >> > > a redirect back to keycloak login with a fragment of #_=_ >> > > 4. I'm already logged in, so redirect back >> > > 5. Success, but the fragment is #_=_ >> > > >> > > Login works for github though...I'm freakin stumped. The initial >> > > redirect back to the admin console is the same exact redirect uri for >> > > both github and facebook. >> > > >> > > Has anybody seen this before? >> > > >> > > -- >> > > Bill Burke >> > > JBoss, a division of Red Hat >> > > http://bill.burkecentral.com >> > > _______________________________________________ >> > > keycloak-dev mailing list >> > > keycloak-dev at lists.jboss.org >> > > https://lists.jboss.org/mailman/listinfo/keycloak-dev >> > > >> > _______________________________________________ >> > keycloak-dev mailing list >> > keycloak-dev at lists.jboss.org >> > https://lists.jboss.org/mailman/listinfo/keycloak-dev >> > >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150326/dfa17687/attachment-0001.html From stian at redhat.com Thu Mar 26 11:24:56 2015 From: stian at redhat.com (Stian Thorgersen) Date: Thu, 26 Mar 2015 11:24:56 -0400 (EDT) Subject: [keycloak-dev] can't figure this out In-Reply-To: References: <55140F93.60501@redhat.com> <288065723.6112068.1427382671466.JavaMail.zimbra@redhat.com> <1208443733.6115419.1427382831254.JavaMail.zimbra@redhat.com> Message-ID: <480227693.6121266.1427383496204.JavaMail.zimbra@redhat.com> Great, so we just need to tweak the Facebook provider to strip that off before redirecting to the app ----- Original Message ----- > From: "Leonardo Loch Zanivan" > To: "Stian Thorgersen" , "Bill Burke" > Cc: keycloak-dev at lists.jboss.org > Sent: Thursday, 26 March, 2015 4:21:49 PM > Subject: Re: [keycloak-dev] can't figure this out > > Ops, you need to remove after keycloak success. Here is an example: > > keycloakAuth.init({ > onLoad: 'login-required' > }).success(function(authenticated) { > //fix facebook oauth > if (window.location.hash === '#_=_') { > window.location.hash = ''; > } > }); > > > On Thu, Mar 26, 2015 at 12:19 PM Leonardo Loch Zanivan < > leonardo.zanivan at gmail.com> wrote: > > > Facebook adds "#_=_" at the end of redirect URL for "security reasons", so > > SPA apps won't work unless you remove it. > > > > In Angular apps you should remove before call keycloak: > > > > if (window.location.hash === '#_=_') { > > window.location.hash = ''; > > } > > > > On Thu, Mar 26, 2015 at 12:14 PM Stian Thorgersen > > wrote: > > > >> AFAIK Facebook is OAuth2 + custom weird stuff that looks like but isn't > >> OpenID Connect > >> > >> ----- Original Message ----- > >> > From: "Stian Thorgersen" > >> > To: "Bill Burke" > >> > Cc: keycloak-dev at lists.jboss.org > >> > Sent: Thursday, 26 March, 2015 4:11:11 PM > >> > Subject: Re: [keycloak-dev] can't figure this out > >> > > >> > I remember seeing the '#_=_' crap a while ago, I believe that was before > >> > Pedro started brokering. > >> > > >> > ----- Original Message ----- > >> > > From: "Bill Burke" > >> > > To: keycloak-dev at lists.jboss.org > >> > > Sent: Thursday, 26 March, 2015 2:54:27 PM > >> > > Subject: [keycloak-dev] can't figure this out > >> > > > >> > > I'm going crazy... I'm testing facebook login with the admin console > >> as > >> > > the test app. > >> > > > >> > > 1. Facebook auth succeeds > >> > > 2. Redirect back to admin console > >> > > 3. For some reason admin console doesn't like the redirect URL and > >> does > >> > > a redirect back to keycloak login with a fragment of #_=_ > >> > > 4. I'm already logged in, so redirect back > >> > > 5. Success, but the fragment is #_=_ > >> > > > >> > > Login works for github though...I'm freakin stumped. The initial > >> > > redirect back to the admin console is the same exact redirect uri for > >> > > both github and facebook. > >> > > > >> > > Has anybody seen this before? > >> > > > >> > > -- > >> > > Bill Burke > >> > > JBoss, a division of Red Hat > >> > > http://bill.burkecentral.com > >> > > _______________________________________________ > >> > > keycloak-dev mailing list > >> > > keycloak-dev at lists.jboss.org > >> > > https://lists.jboss.org/mailman/listinfo/keycloak-dev > >> > > > >> > _______________________________________________ > >> > keycloak-dev mailing list > >> > keycloak-dev at lists.jboss.org > >> > https://lists.jboss.org/mailman/listinfo/keycloak-dev > >> > > >> _______________________________________________ > >> keycloak-dev mailing list > >> keycloak-dev at lists.jboss.org > >> https://lists.jboss.org/mailman/listinfo/keycloak-dev > >> > > > From leonardo.zanivan at gmail.com Thu Mar 26 11:41:50 2015 From: leonardo.zanivan at gmail.com (Leonardo Loch Zanivan) Date: Thu, 26 Mar 2015 15:41:50 +0000 Subject: [keycloak-dev] can't figure this out In-Reply-To: <480227693.6121266.1427383496204.JavaMail.zimbra@redhat.com> References: <55140F93.60501@redhat.com> <288065723.6112068.1427382671466.JavaMail.zimbra@redhat.com> <1208443733.6115419.1427382831254.JavaMail.zimbra@redhat.com> <480227693.6121266.1427383496204.JavaMail.zimbra@redhat.com> Message-ID: I think it would need some tweak in the JavaScript adapter. On Thu, Mar 26, 2015 at 12:25 PM Stian Thorgersen wrote: > Great, so we just need to tweak the Facebook provider to strip that off > before redirecting to the app > > ----- Original Message ----- > > From: "Leonardo Loch Zanivan" > > To: "Stian Thorgersen" , "Bill Burke" < > bburke at redhat.com> > > Cc: keycloak-dev at lists.jboss.org > > Sent: Thursday, 26 March, 2015 4:21:49 PM > > Subject: Re: [keycloak-dev] can't figure this out > > > > Ops, you need to remove after keycloak success. Here is an example: > > > > keycloakAuth.init({ > > onLoad: 'login-required' > > }).success(function(authenticated) { > > //fix facebook oauth > > if (window.location.hash === '#_=_') { > > window.location.hash = ''; > > } > > }); > > > > > > On Thu, Mar 26, 2015 at 12:19 PM Leonardo Loch Zanivan < > > leonardo.zanivan at gmail.com> wrote: > > > > > Facebook adds "#_=_" at the end of redirect URL for "security > reasons", so > > > SPA apps won't work unless you remove it. > > > > > > In Angular apps you should remove before call keycloak: > > > > > > if (window.location.hash === '#_=_') { > > > window.location.hash = ''; > > > } > > > > > > On Thu, Mar 26, 2015 at 12:14 PM Stian Thorgersen > > > wrote: > > > > > >> AFAIK Facebook is OAuth2 + custom weird stuff that looks like but > isn't > > >> OpenID Connect > > >> > > >> ----- Original Message ----- > > >> > From: "Stian Thorgersen" > > >> > To: "Bill Burke" > > >> > Cc: keycloak-dev at lists.jboss.org > > >> > Sent: Thursday, 26 March, 2015 4:11:11 PM > > >> > Subject: Re: [keycloak-dev] can't figure this out > > >> > > > >> > I remember seeing the '#_=_' crap a while ago, I believe that was > before > > >> > Pedro started brokering. > > >> > > > >> > ----- Original Message ----- > > >> > > From: "Bill Burke" > > >> > > To: keycloak-dev at lists.jboss.org > > >> > > Sent: Thursday, 26 March, 2015 2:54:27 PM > > >> > > Subject: [keycloak-dev] can't figure this out > > >> > > > > >> > > I'm going crazy... I'm testing facebook login with the admin > console > > >> as > > >> > > the test app. > > >> > > > > >> > > 1. Facebook auth succeeds > > >> > > 2. Redirect back to admin console > > >> > > 3. For some reason admin console doesn't like the redirect URL and > > >> does > > >> > > a redirect back to keycloak login with a fragment of #_=_ > > >> > > 4. I'm already logged in, so redirect back > > >> > > 5. Success, but the fragment is #_=_ > > >> > > > > >> > > Login works for github though...I'm freakin stumped. The initial > > >> > > redirect back to the admin console is the same exact redirect uri > for > > >> > > both github and facebook. > > >> > > > > >> > > Has anybody seen this before? > > >> > > > > >> > > -- > > >> > > Bill Burke > > >> > > JBoss, a division of Red Hat > > >> > > http://bill.burkecentral.com > > >> > > _______________________________________________ > > >> > > keycloak-dev mailing list > > >> > > keycloak-dev at lists.jboss.org > > >> > > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > >> > > > > >> > _______________________________________________ > > >> > keycloak-dev mailing list > > >> > keycloak-dev at lists.jboss.org > > >> > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > >> > > > >> _______________________________________________ > > >> keycloak-dev mailing list > > >> keycloak-dev at lists.jboss.org > > >> https://lists.jboss.org/mailman/listinfo/keycloak-dev > > >> > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150326/9aa63bd0/attachment.html From stian at redhat.com Thu Mar 26 11:44:43 2015 From: stian at redhat.com (Stian Thorgersen) Date: Thu, 26 Mar 2015 11:44:43 -0400 (EDT) Subject: [keycloak-dev] can't figure this out In-Reply-To: References: <55140F93.60501@redhat.com> <288065723.6112068.1427382671466.JavaMail.zimbra@redhat.com> <1208443733.6115419.1427382831254.JavaMail.zimbra@redhat.com> <480227693.6121266.1427383496204.JavaMail.zimbra@redhat.com> Message-ID: <2141254213.6132913.1427384683458.JavaMail.zimbra@redhat.com> No, we can sort it out in Keycloak as Facebook redirects to Keycloak, not the application. ----- Original Message ----- > From: "Leonardo Loch Zanivan" > To: "Stian Thorgersen" > Cc: "Bill Burke" , keycloak-dev at lists.jboss.org > Sent: Thursday, 26 March, 2015 4:41:50 PM > Subject: Re: [keycloak-dev] can't figure this out > > I think it would need some tweak in the JavaScript adapter. > > On Thu, Mar 26, 2015 at 12:25 PM Stian Thorgersen wrote: > > > Great, so we just need to tweak the Facebook provider to strip that off > > before redirecting to the app > > > > ----- Original Message ----- > > > From: "Leonardo Loch Zanivan" > > > To: "Stian Thorgersen" , "Bill Burke" < > > bburke at redhat.com> > > > Cc: keycloak-dev at lists.jboss.org > > > Sent: Thursday, 26 March, 2015 4:21:49 PM > > > Subject: Re: [keycloak-dev] can't figure this out > > > > > > Ops, you need to remove after keycloak success. Here is an example: > > > > > > keycloakAuth.init({ > > > onLoad: 'login-required' > > > }).success(function(authenticated) { > > > //fix facebook oauth > > > if (window.location.hash === '#_=_') { > > > window.location.hash = ''; > > > } > > > }); > > > > > > > > > On Thu, Mar 26, 2015 at 12:19 PM Leonardo Loch Zanivan < > > > leonardo.zanivan at gmail.com> wrote: > > > > > > > Facebook adds "#_=_" at the end of redirect URL for "security > > reasons", so > > > > SPA apps won't work unless you remove it. > > > > > > > > In Angular apps you should remove before call keycloak: > > > > > > > > if (window.location.hash === '#_=_') { > > > > window.location.hash = ''; > > > > } > > > > > > > > On Thu, Mar 26, 2015 at 12:14 PM Stian Thorgersen > > > > wrote: > > > > > > > >> AFAIK Facebook is OAuth2 + custom weird stuff that looks like but > > isn't > > > >> OpenID Connect > > > >> > > > >> ----- Original Message ----- > > > >> > From: "Stian Thorgersen" > > > >> > To: "Bill Burke" > > > >> > Cc: keycloak-dev at lists.jboss.org > > > >> > Sent: Thursday, 26 March, 2015 4:11:11 PM > > > >> > Subject: Re: [keycloak-dev] can't figure this out > > > >> > > > > >> > I remember seeing the '#_=_' crap a while ago, I believe that was > > before > > > >> > Pedro started brokering. > > > >> > > > > >> > ----- Original Message ----- > > > >> > > From: "Bill Burke" > > > >> > > To: keycloak-dev at lists.jboss.org > > > >> > > Sent: Thursday, 26 March, 2015 2:54:27 PM > > > >> > > Subject: [keycloak-dev] can't figure this out > > > >> > > > > > >> > > I'm going crazy... I'm testing facebook login with the admin > > console > > > >> as > > > >> > > the test app. > > > >> > > > > > >> > > 1. Facebook auth succeeds > > > >> > > 2. Redirect back to admin console > > > >> > > 3. For some reason admin console doesn't like the redirect URL and > > > >> does > > > >> > > a redirect back to keycloak login with a fragment of #_=_ > > > >> > > 4. I'm already logged in, so redirect back > > > >> > > 5. Success, but the fragment is #_=_ > > > >> > > > > > >> > > Login works for github though...I'm freakin stumped. The initial > > > >> > > redirect back to the admin console is the same exact redirect uri > > for > > > >> > > both github and facebook. > > > >> > > > > > >> > > Has anybody seen this before? > > > >> > > > > > >> > > -- > > > >> > > Bill Burke > > > >> > > JBoss, a division of Red Hat > > > >> > > http://bill.burkecentral.com > > > >> > > _______________________________________________ > > > >> > > keycloak-dev mailing list > > > >> > > keycloak-dev at lists.jboss.org > > > >> > > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > >> > > > > > >> > _______________________________________________ > > > >> > keycloak-dev mailing list > > > >> > keycloak-dev at lists.jboss.org > > > >> > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > >> > > > > >> _______________________________________________ > > > >> keycloak-dev mailing list > > > >> keycloak-dev at lists.jboss.org > > > >> https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > >> > > > > > > > > > > From bburke at redhat.com Thu Mar 26 12:07:42 2015 From: bburke at redhat.com (Bill Burke) Date: Thu, 26 Mar 2015 12:07:42 -0400 Subject: [keycloak-dev] can't figure this out In-Reply-To: <2141254213.6132913.1427384683458.JavaMail.zimbra@redhat.com> References: <55140F93.60501@redhat.com> <288065723.6112068.1427382671466.JavaMail.zimbra@redhat.com> <1208443733.6115419.1427382831254.JavaMail.zimbra@redhat.com> <480227693.6121266.1427383496204.JavaMail.zimbra@redhat.com> <2141254213.6132913.1427384683458.JavaMail.zimbra@redhat.com> Message-ID: <55142ECE.5070906@redhat.com> Honestly, your descriptions don't make sense at all... 1. admin console redirects to keycloak with a redirect uri of /auth/admin/master/console. 2. Keycloak stores this redirect uri as-is, keycloak also stores "state" param. 3. keycloak redirects to facebook 4. facebook redirects to keycloak callback url 5. keycloak builds a redirect URI back to admin console based on original stored redirect uri and "state" param and "code". 6. keylcoak redirects back to admin console How could Facebook insert #_=_? Is there some browser/fragment magic happening? On 3/26/2015 11:44 AM, Stian Thorgersen wrote: > No, we can sort it out in Keycloak as Facebook redirects to Keycloak, not the application. > > ----- Original Message ----- >> From: "Leonardo Loch Zanivan" >> To: "Stian Thorgersen" >> Cc: "Bill Burke" , keycloak-dev at lists.jboss.org >> Sent: Thursday, 26 March, 2015 4:41:50 PM >> Subject: Re: [keycloak-dev] can't figure this out >> >> I think it would need some tweak in the JavaScript adapter. >> >> On Thu, Mar 26, 2015 at 12:25 PM Stian Thorgersen wrote: >> >>> Great, so we just need to tweak the Facebook provider to strip that off >>> before redirecting to the app >>> >>> ----- Original Message ----- >>>> From: "Leonardo Loch Zanivan" >>>> To: "Stian Thorgersen" , "Bill Burke" < >>> bburke at redhat.com> >>>> Cc: keycloak-dev at lists.jboss.org >>>> Sent: Thursday, 26 March, 2015 4:21:49 PM >>>> Subject: Re: [keycloak-dev] can't figure this out >>>> >>>> Ops, you need to remove after keycloak success. Here is an example: >>>> >>>> keycloakAuth.init({ >>>> onLoad: 'login-required' >>>> }).success(function(authenticated) { >>>> //fix facebook oauth >>>> if (window.location.hash === '#_=_') { >>>> window.location.hash = ''; >>>> } >>>> }); >>>> >>>> >>>> On Thu, Mar 26, 2015 at 12:19 PM Leonardo Loch Zanivan < >>>> leonardo.zanivan at gmail.com> wrote: >>>> >>>>> Facebook adds "#_=_" at the end of redirect URL for "security >>> reasons", so >>>>> SPA apps won't work unless you remove it. >>>>> >>>>> In Angular apps you should remove before call keycloak: >>>>> >>>>> if (window.location.hash === '#_=_') { >>>>> window.location.hash = ''; >>>>> } >>>>> >>>>> On Thu, Mar 26, 2015 at 12:14 PM Stian Thorgersen >>>>> wrote: >>>>> >>>>>> AFAIK Facebook is OAuth2 + custom weird stuff that looks like but >>> isn't >>>>>> OpenID Connect >>>>>> >>>>>> ----- Original Message ----- >>>>>>> From: "Stian Thorgersen" >>>>>>> To: "Bill Burke" >>>>>>> Cc: keycloak-dev at lists.jboss.org >>>>>>> Sent: Thursday, 26 March, 2015 4:11:11 PM >>>>>>> Subject: Re: [keycloak-dev] can't figure this out >>>>>>> >>>>>>> I remember seeing the '#_=_' crap a while ago, I believe that was >>> before >>>>>>> Pedro started brokering. >>>>>>> >>>>>>> ----- Original Message ----- >>>>>>>> From: "Bill Burke" >>>>>>>> To: keycloak-dev at lists.jboss.org >>>>>>>> Sent: Thursday, 26 March, 2015 2:54:27 PM >>>>>>>> Subject: [keycloak-dev] can't figure this out >>>>>>>> >>>>>>>> I'm going crazy... I'm testing facebook login with the admin >>> console >>>>>> as >>>>>>>> the test app. >>>>>>>> >>>>>>>> 1. Facebook auth succeeds >>>>>>>> 2. Redirect back to admin console >>>>>>>> 3. For some reason admin console doesn't like the redirect URL and >>>>>> does >>>>>>>> a redirect back to keycloak login with a fragment of #_=_ >>>>>>>> 4. I'm already logged in, so redirect back >>>>>>>> 5. Success, but the fragment is #_=_ >>>>>>>> >>>>>>>> Login works for github though...I'm freakin stumped. The initial >>>>>>>> redirect back to the admin console is the same exact redirect uri >>> for >>>>>>>> both github and facebook. >>>>>>>> >>>>>>>> Has anybody seen this before? >>>>>>>> >>>>>>>> -- >>>>>>>> Bill Burke >>>>>>>> JBoss, a division of Red Hat >>>>>>>> http://bill.burkecentral.com >>>>>>>> _______________________________________________ >>>>>>>> keycloak-dev mailing list >>>>>>>> keycloak-dev at lists.jboss.org >>>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>>>>>>> >>>>>>> _______________________________________________ >>>>>>> keycloak-dev mailing list >>>>>>> keycloak-dev at lists.jboss.org >>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>>>>>> >>>>>> _______________________________________________ >>>>>> keycloak-dev mailing list >>>>>> keycloak-dev at lists.jboss.org >>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>>>>> >>>>> >>>> >>> >> -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From leonardo.zanivan at gmail.com Thu Mar 26 12:24:30 2015 From: leonardo.zanivan at gmail.com (Leonardo Loch Zanivan) Date: Thu, 26 Mar 2015 16:24:30 +0000 Subject: [keycloak-dev] can't figure this out In-Reply-To: <55142ECE.5070906@redhat.com> References: <55140F93.60501@redhat.com> <288065723.6112068.1427382671466.JavaMail.zimbra@redhat.com> <1208443733.6115419.1427382831254.JavaMail.zimbra@redhat.com> <480227693.6121266.1427383496204.JavaMail.zimbra@redhat.com> <2141254213.6132913.1427384683458.JavaMail.zimbra@redhat.com> <55142ECE.5070906@redhat.com> Message-ID: I had this problem with my angular app :) Keycloak return "redirect_fragment" param with "#_=_" On Thu, Mar 26, 2015 at 1:07 PM Bill Burke wrote: > Honestly, your descriptions don't make sense at all... > > 1. admin console redirects to keycloak with a redirect uri of > /auth/admin/master/console. > 2. Keycloak stores this redirect uri as-is, keycloak also stores "state" > param. > 3. keycloak redirects to facebook > 4. facebook redirects to keycloak callback url > 5. keycloak builds a redirect URI back to admin console based on > original stored redirect uri and "state" param and "code". > 6. keylcoak redirects back to admin console > > How could Facebook insert #_=_? Is there some browser/fragment magic > happening? > > > On 3/26/2015 11:44 AM, Stian Thorgersen wrote: > > No, we can sort it out in Keycloak as Facebook redirects to Keycloak, > not the application. > > > > ----- Original Message ----- > >> From: "Leonardo Loch Zanivan" > >> To: "Stian Thorgersen" > >> Cc: "Bill Burke" , keycloak-dev at lists.jboss.org > >> Sent: Thursday, 26 March, 2015 4:41:50 PM > >> Subject: Re: [keycloak-dev] can't figure this out > >> > >> I think it would need some tweak in the JavaScript adapter. > >> > >> On Thu, Mar 26, 2015 at 12:25 PM Stian Thorgersen > wrote: > >> > >>> Great, so we just need to tweak the Facebook provider to strip that off > >>> before redirecting to the app > >>> > >>> ----- Original Message ----- > >>>> From: "Leonardo Loch Zanivan" > >>>> To: "Stian Thorgersen" , "Bill Burke" < > >>> bburke at redhat.com> > >>>> Cc: keycloak-dev at lists.jboss.org > >>>> Sent: Thursday, 26 March, 2015 4:21:49 PM > >>>> Subject: Re: [keycloak-dev] can't figure this out > >>>> > >>>> Ops, you need to remove after keycloak success. Here is an example: > >>>> > >>>> keycloakAuth.init({ > >>>> onLoad: 'login-required' > >>>> }).success(function(authenticated) { > >>>> //fix facebook oauth > >>>> if (window.location.hash === '#_=_') { > >>>> window.location.hash = ''; > >>>> } > >>>> }); > >>>> > >>>> > >>>> On Thu, Mar 26, 2015 at 12:19 PM Leonardo Loch Zanivan < > >>>> leonardo.zanivan at gmail.com> wrote: > >>>> > >>>>> Facebook adds "#_=_" at the end of redirect URL for "security > >>> reasons", so > >>>>> SPA apps won't work unless you remove it. > >>>>> > >>>>> In Angular apps you should remove before call keycloak: > >>>>> > >>>>> if (window.location.hash === '#_=_') { > >>>>> window.location.hash = ''; > >>>>> } > >>>>> > >>>>> On Thu, Mar 26, 2015 at 12:14 PM Stian Thorgersen > >>>>> wrote: > >>>>> > >>>>>> AFAIK Facebook is OAuth2 + custom weird stuff that looks like but > >>> isn't > >>>>>> OpenID Connect > >>>>>> > >>>>>> ----- Original Message ----- > >>>>>>> From: "Stian Thorgersen" > >>>>>>> To: "Bill Burke" > >>>>>>> Cc: keycloak-dev at lists.jboss.org > >>>>>>> Sent: Thursday, 26 March, 2015 4:11:11 PM > >>>>>>> Subject: Re: [keycloak-dev] can't figure this out > >>>>>>> > >>>>>>> I remember seeing the '#_=_' crap a while ago, I believe that was > >>> before > >>>>>>> Pedro started brokering. > >>>>>>> > >>>>>>> ----- Original Message ----- > >>>>>>>> From: "Bill Burke" > >>>>>>>> To: keycloak-dev at lists.jboss.org > >>>>>>>> Sent: Thursday, 26 March, 2015 2:54:27 PM > >>>>>>>> Subject: [keycloak-dev] can't figure this out > >>>>>>>> > >>>>>>>> I'm going crazy... I'm testing facebook login with the admin > >>> console > >>>>>> as > >>>>>>>> the test app. > >>>>>>>> > >>>>>>>> 1. Facebook auth succeeds > >>>>>>>> 2. Redirect back to admin console > >>>>>>>> 3. For some reason admin console doesn't like the redirect URL and > >>>>>> does > >>>>>>>> a redirect back to keycloak login with a fragment of #_=_ > >>>>>>>> 4. I'm already logged in, so redirect back > >>>>>>>> 5. Success, but the fragment is #_=_ > >>>>>>>> > >>>>>>>> Login works for github though...I'm freakin stumped. The initial > >>>>>>>> redirect back to the admin console is the same exact redirect uri > >>> for > >>>>>>>> both github and facebook. > >>>>>>>> > >>>>>>>> Has anybody seen this before? > >>>>>>>> > >>>>>>>> -- > >>>>>>>> Bill Burke > >>>>>>>> JBoss, a division of Red Hat > >>>>>>>> http://bill.burkecentral.com > >>>>>>>> _______________________________________________ > >>>>>>>> keycloak-dev mailing list > >>>>>>>> keycloak-dev at lists.jboss.org > >>>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev > >>>>>>>> > >>>>>>> _______________________________________________ > >>>>>>> keycloak-dev mailing list > >>>>>>> keycloak-dev at lists.jboss.org > >>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev > >>>>>>> > >>>>>> _______________________________________________ > >>>>>> keycloak-dev mailing list > >>>>>> keycloak-dev at lists.jboss.org > >>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev > >>>>>> > >>>>> > >>>> > >>> > >> > > -- > Bill Burke > JBoss, a division of Red Hat > http://bill.burkecentral.com > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150326/92a35d52/attachment.html From bburke at redhat.com Thu Mar 26 13:04:40 2015 From: bburke at redhat.com (Bill Burke) Date: Thu, 26 Mar 2015 13:04:40 -0400 Subject: [keycloak-dev] can't figure this out In-Reply-To: References: <55140F93.60501@redhat.com> <288065723.6112068.1427382671466.JavaMail.zimbra@redhat.com> <1208443733.6115419.1427382831254.JavaMail.zimbra@redhat.com> <480227693.6121266.1427383496204.JavaMail.zimbra@redhat.com> <2141254213.6132913.1427384683458.JavaMail.zimbra@redhat.com> <55142ECE.5070906@redhat.com> Message-ID: <55143C28.6060802@redhat.com> Ok, keycloak.js was not removing the fragment when parsing query params. Some other information why this was happening *ONLY* for facebook: http://stackoverflow.com/questions/7131909/facebook-callback-appends-to-return-url and http://blogs.msdn.com/b/ieinternals/archive/2011/05/17/url-fragments-and-redirects-anchor-hash-missing.aspx Seems that an intermediary (Facebook in this instance) can add a fragment that then gets propagated when you redirect back, even if the original URL does not have a fragment!!!!....ugh...This is bollux! On 3/26/2015 12:24 PM, Leonardo Loch Zanivan wrote: > I had this problem with my angular app :) > Keycloak return "redirect_fragment" param with "#_=_" > > On Thu, Mar 26, 2015 at 1:07 PM Bill Burke > wrote: > > Honestly, your descriptions don't make sense at all... > > 1. admin console redirects to keycloak with a redirect uri of > /auth/admin/master/console. > 2. Keycloak stores this redirect uri as-is, keycloak also stores "state" > param. > 3. keycloak redirects to facebook > 4. facebook redirects to keycloak callback url > 5. keycloak builds a redirect URI back to admin console based on > original stored redirect uri and "state" param and "code". > 6. keylcoak redirects back to admin console > > How could Facebook insert #_=_? Is there some browser/fragment magic > happening? > > > On 3/26/2015 11:44 AM, Stian Thorgersen wrote: > > No, we can sort it out in Keycloak as Facebook redirects to > Keycloak, not the application. > > > > ----- Original Message ----- > >> From: "Leonardo Loch Zanivan" > > >> To: "Stian Thorgersen" > > >> Cc: "Bill Burke" >, > keycloak-dev at lists.jboss.org > >> Sent: Thursday, 26 March, 2015 4:41:50 PM > >> Subject: Re: [keycloak-dev] can't figure this out > >> > >> I think it would need some tweak in the JavaScript adapter. > >> > >> On Thu, Mar 26, 2015 at 12:25 PM Stian Thorgersen > > wrote: > >> > >>> Great, so we just need to tweak the Facebook provider to strip > that off > >>> before redirecting to the app > >>> > >>> ----- Original Message ----- > >>>> From: "Leonardo Loch Zanivan" > > >>>> To: "Stian Thorgersen" >, "Bill Burke" < > >>> bburke at redhat.com > > >>>> Cc: keycloak-dev at lists.jboss.org > > >>>> Sent: Thursday, 26 March, 2015 4:21:49 PM > >>>> Subject: Re: [keycloak-dev] can't figure this out > >>>> > >>>> Ops, you need to remove after keycloak success. Here is an > example: > >>>> > >>>> keycloakAuth.init({ > >>>> onLoad: 'login-required' > >>>> }).success(function(__authenticated) { > >>>> //fix facebook oauth > >>>> if (window.location.hash === '#_=_') { > >>>> window.location.hash = ''; > >>>> } > >>>> }); > >>>> > >>>> > >>>> On Thu, Mar 26, 2015 at 12:19 PM Leonardo Loch Zanivan < > >>>> leonardo.zanivan at gmail.com > > wrote: > >>>> > >>>>> Facebook adds "#_=_" at the end of redirect URL for "security > >>> reasons", so > >>>>> SPA apps won't work unless you remove it. > >>>>> > >>>>> In Angular apps you should remove before call keycloak: > >>>>> > >>>>> if (window.location.hash === '#_=_') { > >>>>> window.location.hash = ''; > >>>>> } > >>>>> > >>>>> On Thu, Mar 26, 2015 at 12:14 PM Stian Thorgersen > > > >>>>> wrote: > >>>>> > >>>>>> AFAIK Facebook is OAuth2 + custom weird stuff that looks > like but > >>> isn't > >>>>>> OpenID Connect > >>>>>> > >>>>>> ----- Original Message ----- > >>>>>>> From: "Stian Thorgersen" > > >>>>>>> To: "Bill Burke" > > >>>>>>> Cc: keycloak-dev at lists.jboss.org > > >>>>>>> Sent: Thursday, 26 March, 2015 4:11:11 PM > >>>>>>> Subject: Re: [keycloak-dev] can't figure this out > >>>>>>> > >>>>>>> I remember seeing the '#_=_' crap a while ago, I believe > that was > >>> before > >>>>>>> Pedro started brokering. > >>>>>>> > >>>>>>> ----- Original Message ----- > >>>>>>>> From: "Bill Burke" > > >>>>>>>> To: keycloak-dev at lists.jboss.org > > >>>>>>>> Sent: Thursday, 26 March, 2015 2:54:27 PM > >>>>>>>> Subject: [keycloak-dev] can't figure this out > >>>>>>>> > >>>>>>>> I'm going crazy... I'm testing facebook login with the admin > >>> console > >>>>>> as > >>>>>>>> the test app. > >>>>>>>> > >>>>>>>> 1. Facebook auth succeeds > >>>>>>>> 2. Redirect back to admin console > >>>>>>>> 3. For some reason admin console doesn't like the redirect > URL and > >>>>>> does > >>>>>>>> a redirect back to keycloak login with a fragment of #_=_ > >>>>>>>> 4. I'm already logged in, so redirect back > >>>>>>>> 5. Success, but the fragment is #_=_ > >>>>>>>> > >>>>>>>> Login works for github though...I'm freakin stumped. The > initial > >>>>>>>> redirect back to the admin console is the same exact > redirect uri > >>> for > >>>>>>>> both github and facebook. > >>>>>>>> > >>>>>>>> Has anybody seen this before? > >>>>>>>> > >>>>>>>> -- > >>>>>>>> Bill Burke > >>>>>>>> JBoss, a division of Red Hat > >>>>>>>> http://bill.burkecentral.com > >>>>>>>> _________________________________________________ > >>>>>>>> keycloak-dev mailing list > >>>>>>>> keycloak-dev at lists.jboss.org > > >>>>>>>> https://lists.jboss.org/__mailman/listinfo/keycloak-dev > > >>>>>>>> > >>>>>>> _________________________________________________ > >>>>>>> keycloak-dev mailing list > >>>>>>> keycloak-dev at lists.jboss.org > > >>>>>>> https://lists.jboss.org/__mailman/listinfo/keycloak-dev > > >>>>>>> > >>>>>> _________________________________________________ > >>>>>> keycloak-dev mailing list > >>>>>> keycloak-dev at lists.jboss.org > > >>>>>> https://lists.jboss.org/__mailman/listinfo/keycloak-dev > > >>>>>> > >>>>> > >>>> > >>> > >> > > -- > Bill Burke > JBoss, a division of Red Hat > http://bill.burkecentral.com > -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From lkrzyzan at redhat.com Fri Mar 27 04:31:48 2015 From: lkrzyzan at redhat.com (=?utf-8?Q?Libor_Krzy=C5=BEanek?=) Date: Fri, 27 Mar 2015 09:31:48 +0100 Subject: [keycloak-dev] Keycloak JIRA - github commits sync Message-ID: <01ADCFED-C074-4F8B-91ED-240AE2B94A8C@redhat.com> Hi there, I think it?s very useful to have configured jira project to sync issues with commits. For example I would very quickly see how Stian implemented this https://issues.jboss.org/browse/KEYCLOAK-1137 WDYT? Thanks, Libor Krzy?anek jboss.org Development Team -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150327/44ee4f6c/attachment-0001.html From stian at redhat.com Fri Mar 27 05:27:37 2015 From: stian at redhat.com (Stian Thorgersen) Date: Fri, 27 Mar 2015 05:27:37 -0400 (EDT) Subject: [keycloak-dev] Keycloak JIRA - github commits sync In-Reply-To: <01ADCFED-C074-4F8B-91ED-240AE2B94A8C@redhat.com> References: <01ADCFED-C074-4F8B-91ED-240AE2B94A8C@redhat.com> Message-ID: <1903093497.6626423.1427448457307.JavaMail.zimbra@redhat.com> Can that be automated? Or does it require manually linking PRs? ----- Original Message ----- > From: "Libor Krzy?anek" > To: keycloak-dev at lists.jboss.org > Sent: Friday, 27 March, 2015 9:31:48 AM > Subject: [keycloak-dev] Keycloak JIRA - github commits sync > > Hi there, > I think it?s very useful to have configured jira project to sync issues with > commits. > > For example I would very quickly see how Stian implemented this > https://issues.jboss.org/browse/KEYCLOAK-1137 > > WDYT? > > Thanks, > > Libor Krzy?anek > jboss.org Development Team > > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev From lkrzyzan at redhat.com Fri Mar 27 05:28:09 2015 From: lkrzyzan at redhat.com (=?utf-8?Q?Libor_Krzy=C5=BEanek?=) Date: Fri, 27 Mar 2015 10:28:09 +0100 Subject: [keycloak-dev] Keycloak JIRA - github commits sync In-Reply-To: <1903093497.6626423.1427448457307.JavaMail.zimbra@redhat.com> References: <01ADCFED-C074-4F8B-91ED-240AE2B94A8C@redhat.com> <1903093497.6626423.1427448457307.JavaMail.zimbra@redhat.com> Message-ID: Fully automated. Vlastimil can configure it. Thanks, Libor Krzy?anek jboss.org Development Team > On 27 Mar 2015, at 10:27, Stian Thorgersen wrote: > > Can that be automated? Or does it require manually linking PRs? > > ----- Original Message ----- >> From: "Libor Krzy?anek" >> To: keycloak-dev at lists.jboss.org >> Sent: Friday, 27 March, 2015 9:31:48 AM >> Subject: [keycloak-dev] Keycloak JIRA - github commits sync >> >> Hi there, >> I think it?s very useful to have configured jira project to sync issues with >> commits. >> >> For example I would very quickly see how Stian implemented this >> https://issues.jboss.org/browse/KEYCLOAK-1137 >> >> WDYT? >> >> Thanks, >> >> Libor Krzy?anek >> jboss.org Development Team >> >> >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150327/dd6884c3/attachment.html From stian at redhat.com Fri Mar 27 05:29:24 2015 From: stian at redhat.com (Stian Thorgersen) Date: Fri, 27 Mar 2015 05:29:24 -0400 (EDT) Subject: [keycloak-dev] Keycloak JIRA - github commits sync In-Reply-To: References: <01ADCFED-C074-4F8B-91ED-240AE2B94A8C@redhat.com> <1903093497.6626423.1427448457307.JavaMail.zimbra@redhat.com> Message-ID: <1383765894.6627256.1427448564160.JavaMail.zimbra@redhat.com> Then the answer is yes please :) ----- Original Message ----- > From: "Libor Krzy?anek" > To: "Stian Thorgersen" > Cc: keycloak-dev at lists.jboss.org > Sent: Friday, 27 March, 2015 10:28:09 AM > Subject: Re: [keycloak-dev] Keycloak JIRA - github commits sync > > Fully automated. > > Vlastimil can configure it. > > Thanks, > > Libor Krzy?anek > jboss.org Development Team > > > On 27 Mar 2015, at 10:27, Stian Thorgersen wrote: > > > > Can that be automated? Or does it require manually linking PRs? > > > > ----- Original Message ----- > >> From: "Libor Krzy?anek" > >> To: keycloak-dev at lists.jboss.org > >> Sent: Friday, 27 March, 2015 9:31:48 AM > >> Subject: [keycloak-dev] Keycloak JIRA - github commits sync > >> > >> Hi there, > >> I think it?s very useful to have configured jira project to sync issues > >> with > >> commits. > >> > >> For example I would very quickly see how Stian implemented this > >> https://issues.jboss.org/browse/KEYCLOAK-1137 > >> > >> WDYT? > >> > >> Thanks, > >> > >> Libor Krzy?anek > >> jboss.org Development Team > >> > >> > >> _______________________________________________ > >> keycloak-dev mailing list > >> keycloak-dev at lists.jboss.org > >> https://lists.jboss.org/mailman/listinfo/keycloak-dev > > From velias at redhat.com Fri Mar 27 05:40:11 2015 From: velias at redhat.com (Vlastimil Elias) Date: Fri, 27 Mar 2015 10:40:11 +0100 Subject: [keycloak-dev] Keycloak JIRA - github commits sync In-Reply-To: <1383765894.6627256.1427448564160.JavaMail.zimbra@redhat.com> References: <01ADCFED-C074-4F8B-91ED-240AE2B94A8C@redhat.com> <1903093497.6626423.1427448457307.JavaMail.zimbra@redhat.com> <1383765894.6627256.1427448564160.JavaMail.zimbra@redhat.com> Message-ID: <5515257B.9020808@redhat.com> Hi Stian, general description is at https://developer.jboss.org/en/website/blog/2013/03/11/new-way-to-show-github-commits-in-jbossorg-jira even it is a bit out of date as jira now shows commits a bit differently. But process of adding at the end of the page is valid, so you have to do step 2 - jboss-jira-hook github user must be added into the Keycloak organization's Owners group. Jira needs this to add webhooks. After you configure this then let me know and I can configure jira. Cheers Vl. On 27.3.2015 10:29, Stian Thorgersen wrote: > Then the answer is yes please :) > > ----- Original Message ----- >> From: "Libor Krzy?anek" >> To: "Stian Thorgersen" >> Cc: keycloak-dev at lists.jboss.org >> Sent: Friday, 27 March, 2015 10:28:09 AM >> Subject: Re: [keycloak-dev] Keycloak JIRA - github commits sync >> >> Fully automated. >> >> Vlastimil can configure it. >> >> Thanks, >> >> Libor Krzy?anek >> jboss.org Development Team >> >>> On 27 Mar 2015, at 10:27, Stian Thorgersen wrote: >>> >>> Can that be automated? Or does it require manually linking PRs? >>> >>> ----- Original Message ----- >>>> From: "Libor Krzy?anek" >>>> To: keycloak-dev at lists.jboss.org >>>> Sent: Friday, 27 March, 2015 9:31:48 AM >>>> Subject: [keycloak-dev] Keycloak JIRA - github commits sync >>>> >>>> Hi there, >>>> I think it?s very useful to have configured jira project to sync issues >>>> with >>>> commits. >>>> >>>> For example I would very quickly see how Stian implemented this >>>> https://issues.jboss.org/browse/KEYCLOAK-1137 >>>> >>>> WDYT? >>>> >>>> Thanks, >>>> >>>> Libor Krzy?anek >>>> jboss.org Development Team >>>> >>>> >>>> _______________________________________________ >>>> keycloak-dev mailing list >>>> keycloak-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev -- Vlastimil Elias Principal Software Engineer jboss.org Development Team -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150327/497fea8d/attachment.html From stian at redhat.com Fri Mar 27 05:43:32 2015 From: stian at redhat.com (Stian Thorgersen) Date: Fri, 27 Mar 2015 05:43:32 -0400 (EDT) Subject: [keycloak-dev] 1.2.0.Beta1 release on Thursday (2nd April) In-Reply-To: <689476903.6631050.1427449209495.JavaMail.zimbra@redhat.com> Message-ID: <1549471357.6631751.1427449412205.JavaMail.zimbra@redhat.com> I want 1.2.0.Beta1 released on Thursday 2nd April. We need a couple more days to finish of the last tasks and do some testing and 1st April didn't seam like a good release date! Is there any remaining issues outstanding that are not in JIRA? I'd like to request that everyone spends a bit of time today and Monday to do some testing! From stian at redhat.com Fri Mar 27 06:58:30 2015 From: stian at redhat.com (Stian Thorgersen) Date: Fri, 27 Mar 2015 06:58:30 -0400 (EDT) Subject: [keycloak-dev] REST API documentation In-Reply-To: <17537018.6661472.1427453800494.JavaMail.zimbra@redhat.com> Message-ID: <727495904.6662050.1427453910788.JavaMail.zimbra@redhat.com> Currently we're generating the REST API documentation automatically. There's a few issues with that approach: * Dynamic endpoints are not included (for example openid-connect and saml endpoints are missing) * No categories - we should split docs into admin, openid-connect, saml, etc. * Includes private endpoints - for example required actions and account management are included even though they are not intended for public use * JSON objects not defined - a lot of REST APIs include examples on how to use, including details on the JSON consumed/produced Is there a way to solve this with the current approach or would it be better to manually create the documentations? From ssilvert at redhat.com Fri Mar 27 07:47:14 2015 From: ssilvert at redhat.com (Stan Silvert) Date: Fri, 27 Mar 2015 07:47:14 -0400 Subject: [keycloak-dev] REST API documentation In-Reply-To: <727495904.6662050.1427453910788.JavaMail.zimbra@redhat.com> References: <727495904.6662050.1427453910788.JavaMail.zimbra@redhat.com> Message-ID: <55154342.8080400@redhat.com> On 3/27/2015 6:58 AM, Stian Thorgersen wrote: > Currently we're generating the REST API documentation automatically. There's a few issues with that approach: > > * Dynamic endpoints are not included (for example openid-connect and saml endpoints are missing) > * No categories - we should split docs into admin, openid-connect, saml, etc. > * Includes private endpoints - for example required actions and account management are included even though they are not intended for public use > * JSON objects not defined - a lot of REST APIs include examples on how to use, including details on the JSON consumed/produced > > Is there a way to solve this with the current approach or would it be better to manually create the documentations? I suspect that there are hooks into the generator we could use? As someone who is starting to use those REST API's, improved documentation would be a huge help! Glad you are thinking about it. > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev From bburke at redhat.com Fri Mar 27 08:13:18 2015 From: bburke at redhat.com (Bill Burke) Date: Fri, 27 Mar 2015 08:13:18 -0400 Subject: [keycloak-dev] REST API documentation In-Reply-To: <727495904.6662050.1427453910788.JavaMail.zimbra@redhat.com> References: <727495904.6662050.1427453910788.JavaMail.zimbra@redhat.com> Message-ID: <5515495E.5080900@redhat.com> IMO< continue doing it this way for a few more months. Docs will get out of sync fast with REST api. Which is why it is automated in the first place. On 3/27/2015 6:58 AM, Stian Thorgersen wrote: > Currently we're generating the REST API documentation automatically. There's a few issues with that approach: > > * Dynamic endpoints are not included (for example openid-connect and saml endpoints are missing) > * No categories - we should split docs into admin, openid-connect, saml, etc. > * Includes private endpoints - for example required actions and account management are included even though they are not intended for public use > * JSON objects not defined - a lot of REST APIs include examples on how to use, including details on the JSON consumed/produced > > Is there a way to solve this with the current approach or would it be better to manually create the documentations? > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From stian at redhat.com Fri Mar 27 08:21:56 2015 From: stian at redhat.com (Stian Thorgersen) Date: Fri, 27 Mar 2015 08:21:56 -0400 (EDT) Subject: [keycloak-dev] REST API documentation In-Reply-To: <5515495E.5080900@redhat.com> References: <727495904.6662050.1427453910788.JavaMail.zimbra@redhat.com> <5515495E.5080900@redhat.com> Message-ID: <1226782597.6713627.1427458916652.JavaMail.zimbra@redhat.com> I agree, generating is best, but we'd need to least figure out how to add missing protocol endpoints, and also exclude internal endpoints. ----- Original Message ----- > From: "Bill Burke" > To: keycloak-dev at lists.jboss.org > Sent: Friday, 27 March, 2015 1:13:18 PM > Subject: Re: [keycloak-dev] REST API documentation > > IMO< continue doing it this way for a few more months. Docs will get > out of sync fast with REST api. Which is why it is automated in the > first place. > > On 3/27/2015 6:58 AM, Stian Thorgersen wrote: > > Currently we're generating the REST API documentation automatically. > > There's a few issues with that approach: > > > > * Dynamic endpoints are not included (for example openid-connect and saml > > endpoints are missing) > > * No categories - we should split docs into admin, openid-connect, saml, > > etc. > > * Includes private endpoints - for example required actions and account > > management are included even though they are not intended for public use > > * JSON objects not defined - a lot of REST APIs include examples on how to > > use, including details on the JSON consumed/produced > > > > Is there a way to solve this with the current approach or would it be > > better to manually create the documentations? > > _______________________________________________ > > keycloak-dev mailing list > > keycloak-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > > -- > Bill Burke > JBoss, a division of Red Hat > http://bill.burkecentral.com > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > From bburke at redhat.com Fri Mar 27 08:51:58 2015 From: bburke at redhat.com (Bill Burke) Date: Fri, 27 Mar 2015 08:51:58 -0400 Subject: [keycloak-dev] REST API documentation In-Reply-To: <1226782597.6713627.1427458916652.JavaMail.zimbra@redhat.com> References: <727495904.6662050.1427453910788.JavaMail.zimbra@redhat.com> <5515495E.5080900@redhat.com> <1226782597.6713627.1427458916652.JavaMail.zimbra@redhat.com> Message-ID: <5515526E.7010501@redhat.com> I'm more concerned about the admin api. we can manually doc the protocol endpoints. On 3/27/2015 8:21 AM, Stian Thorgersen wrote: > I agree, generating is best, but we'd need to least figure out how to add missing protocol endpoints, and also exclude internal endpoints. > > ----- Original Message ----- >> From: "Bill Burke" >> To: keycloak-dev at lists.jboss.org >> Sent: Friday, 27 March, 2015 1:13:18 PM >> Subject: Re: [keycloak-dev] REST API documentation >> >> IMO< continue doing it this way for a few more months. Docs will get >> out of sync fast with REST api. Which is why it is automated in the >> first place. >> >> On 3/27/2015 6:58 AM, Stian Thorgersen wrote: >>> Currently we're generating the REST API documentation automatically. >>> There's a few issues with that approach: >>> >>> * Dynamic endpoints are not included (for example openid-connect and saml >>> endpoints are missing) >>> * No categories - we should split docs into admin, openid-connect, saml, >>> etc. >>> * Includes private endpoints - for example required actions and account >>> management are included even though they are not intended for public use >>> * JSON objects not defined - a lot of REST APIs include examples on how to >>> use, including details on the JSON consumed/produced >>> >>> Is there a way to solve this with the current approach or would it be >>> better to manually create the documentations? >>> _______________________________________________ >>> keycloak-dev mailing list >>> keycloak-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>> >> >> -- >> Bill Burke >> JBoss, a division of Red Hat >> http://bill.burkecentral.com >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From bburke at redhat.com Fri Mar 27 11:20:17 2015 From: bburke at redhat.com (Bill Burke) Date: Fri, 27 Mar 2015 11:20:17 -0400 Subject: [keycloak-dev] logging of errors Message-ID: <55157531.6030903@redhat.com> While we do create appropriate events when errors happen, we do not do any logging. Should we be logging too when errors happen? Many times I have no idea what went wrong and have to guess how I might have configured keycloak incorrectly. -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From ssilvert at redhat.com Fri Mar 27 12:15:23 2015 From: ssilvert at redhat.com (Stan Silvert) Date: Fri, 27 Mar 2015 12:15:23 -0400 Subject: [keycloak-dev] REST API documentation In-Reply-To: <5515526E.7010501@redhat.com> References: <727495904.6662050.1427453910788.JavaMail.zimbra@redhat.com> <5515495E.5080900@redhat.com> <1226782597.6713627.1427458916652.JavaMail.zimbra@redhat.com> <5515526E.7010501@redhat.com> Message-ID: <5515821B.2050102@redhat.com> BTW, the direct grant section of the doc needs to be updated. ServiceUrlConstants.TOKEN_SERVICE_DIRECT_GRANT_PATH is not valid any more. I'm new to that API, so I won't attempt to update the doc myself. On 3/27/2015 8:51 AM, Bill Burke wrote: > I'm more concerned about the admin api. we can manually doc the protocol > endpoints. > > On 3/27/2015 8:21 AM, Stian Thorgersen wrote: >> I agree, generating is best, but we'd need to least figure out how to add missing protocol endpoints, and also exclude internal endpoints. >> >> ----- Original Message ----- >>> From: "Bill Burke" >>> To: keycloak-dev at lists.jboss.org >>> Sent: Friday, 27 March, 2015 1:13:18 PM >>> Subject: Re: [keycloak-dev] REST API documentation >>> >>> IMO< continue doing it this way for a few more months. Docs will get >>> out of sync fast with REST api. Which is why it is automated in the >>> first place. >>> >>> On 3/27/2015 6:58 AM, Stian Thorgersen wrote: >>>> Currently we're generating the REST API documentation automatically. >>>> There's a few issues with that approach: >>>> >>>> * Dynamic endpoints are not included (for example openid-connect and saml >>>> endpoints are missing) >>>> * No categories - we should split docs into admin, openid-connect, saml, >>>> etc. >>>> * Includes private endpoints - for example required actions and account >>>> management are included even though they are not intended for public use >>>> * JSON objects not defined - a lot of REST APIs include examples on how to >>>> use, including details on the JSON consumed/produced >>>> >>>> Is there a way to solve this with the current approach or would it be >>>> better to manually create the documentations? >>>> _______________________________________________ >>>> keycloak-dev mailing list >>>> keycloak-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>>> >>> -- >>> Bill Burke >>> JBoss, a division of Red Hat >>> http://bill.burkecentral.com >>> _______________________________________________ >>> keycloak-dev mailing list >>> keycloak-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>> From sebastian.rose at aoe.com Fri Mar 27 12:22:06 2015 From: sebastian.rose at aoe.com (Sebastian Rose) Date: Fri, 27 Mar 2015 17:22:06 +0100 Subject: [keycloak-dev] application session state update Message-ID: <1B725C3C52B62D42A8A766BB4EFFCA2C43CECE8FF8@srv-mail01.aoemedia.lan> Hi everyone, The endpoint /auth/realms//protocol/openid-connect/access/codes has a parameter for the session id of a secured application (adapters use it): application_session_state. The Endpoint /auth/realms//protocol/openid-connect/refresh has not. At least this is what i saw within the code. Sorry, if it's there. We have integrated our own application a la adapter, using these two url's and it's working fine. Our application completes the login via the first endpoint and changes it's session id after the successful login. This means when a logout event is send to our application, the old session id is used. So i'm asking if it makes sense to you to have the same parameter for the refresh-url to cover our requirement or to integrate an application_session_state update endpoint to add/delete/update additional/new session id's. Best Regrads Sebastian -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150327/77f250c8/attachment.html From stian at redhat.com Mon Mar 30 01:41:58 2015 From: stian at redhat.com (Stian Thorgersen) Date: Mon, 30 Mar 2015 01:41:58 -0400 (EDT) Subject: [keycloak-dev] logging of errors In-Reply-To: <55157531.6030903@redhat.com> References: <55157531.6030903@redhat.com> Message-ID: <44951513.8016575.1427694118903.JavaMail.zimbra@redhat.com> We already have a jboss-logging events logger. You can enable it through the admin console. ----- Original Message ----- > From: "Bill Burke" > To: keycloak-dev at lists.jboss.org > Sent: Friday, 27 March, 2015 4:20:17 PM > Subject: [keycloak-dev] logging of errors > > While we do create appropriate events when errors happen, we do not do > any logging. Should we be logging too when errors happen? Many times I > have no idea what went wrong and have to guess how I might have > configured keycloak incorrectly. > -- > Bill Burke > JBoss, a division of Red Hat > http://bill.burkecentral.com > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > From bgorai at cisco.com Mon Mar 30 02:33:50 2015 From: bgorai at cisco.com (Bappaditya Gorai (bgorai)) Date: Mon, 30 Mar 2015 06:33:50 +0000 Subject: [keycloak-dev] Client getting 405 response for POST API using stateless adapter Message-ID: Hi Team, We are facing following issue in Keycloak 1.1.0_Final release. I am using stateless adapter configuration i.e tokenstore is cookie. I have an API endpoint which support POST method. While accessing this API client is receiving 405 (Method not allowed) response. Same works fine if adapter is *not* stateless. >From my understanding looks like 302 response of CODE_TO_TOKEN is causing the Client to access the Resource Endpoint as GET method which is not allowed in my case( My API endpoint only supports POST). Do you have any fix for this? Thanks Bappaditya Gorai -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150330/d7236cd8/attachment.html From lvadali at cisco.com Mon Mar 30 11:23:03 2015 From: lvadali at cisco.com (Lakshmi Narayana VADALI (lvadali)) Date: Mon, 30 Mar 2015 15:23:03 +0000 Subject: [keycloak-dev] Application clustering Issue with Keycloak 1.1.0_Final In-Reply-To: <54FEA91F.7060505@redhat.com> References: <54F87562.4060408@redhat.com> <54F9628D.9020100@redhat.com> <54FEA91F.7060505@redhat.com> Message-ID: Hi Marek, We Tested with our Application standalone mode and clustered but still facing the same issue. Can you please help us in taking this forward. We are getting below exception client side org.apache.http.client.ClientProtocolException at org.apache.http.impl.client.InternalHttpClient.doExecute(InternalHttpClient.java:186) at org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:84) at org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:109) at org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:57) at org.cisco.oauth.test.OAuthClient.sendGetRequest(OAuthClient.java:241) at org.cisco.oauth.test.OAuthClient.accessResource(OAuthClient.java:383) at org.cisco.oauth.test.OAuthClient.hitResource(OAuthClient.java:436) at org.cisco.oauth.test.OAuthClient.hitResource(OAuthClient.java:456) at org.cisco.oauth.test.OAuthClient.main(OAuthClient.java:503) Caused by: org.apache.http.client.CircularRedirectException: Circular redirect to 'https://10.78.216.143:10001/peach-ecmg/ecmg/get' at org.apache.http.impl.client.DefaultRedirectStrategy.getLocationURI(DefaultRedirectStrategy.java:175) at org.apache.http.impl.client.DefaultRedirectStrategy.getRedirect(DefaultRedirectStrategy.java:219) at org.apache.http.impl.execchain.RedirectExec.execute(RedirectExec.java:120) at org.apache.http.impl.client.InternalHttpClient.doExecute(InternalHttpClient.java:184) ... 8 more Thanks, Lakshmi Narayana V From: Marek Posolda [mailto:mposolda at redhat.com] Sent: Tuesday, March 10, 2015 1:50 PM To: Lakshmi Narayana VADALI (lvadali); keycloak-dev at lists.jboss.org Subject: Re: [keycloak-dev] Application clustering Issue with Keycloak 1.1.0_Final Can you please try to test cluster with your application in standalone mode? Just curious if it's bug specific just to domain mode... Thanks, Marek On 9.3.2015 11:09, Lakshmi Narayana VADALI (lvadali) wrote: Hi Marek, We are thinking may be session replication for keycloak application alone ( in domain mode) is not working because of below reasons 1. The application you provided is working fine in our environment . (Conclusion:: session replication working for other applications) 2. If only one node in the cluster(domain mode) is up its working. (Conclusion:: keycloak setup is fine in my environment , as session replication is not needed) Please let us know if you think otherwise. Thanks, Lakshmi Narayana V From: Marek Posolda [mailto:mposolda at redhat.com] Sent: Friday, March 06, 2015 1:47 PM To: Lakshmi Narayana VADALI (lvadali); keycloak-dev at lists.jboss.org Subject: Re: [keycloak-dev] Application clustering Issue with Keycloak 1.1.0_Final Hi Lakshmi, EAP 6.3.0 should work, but I've tested with "standalone" mode so far, not domain mode yet.. Not sure if it's keycloak bug specific to domain or just some issue in your environment. Could you try to test if HTTP session replication works for you in domain mode with some simple servlet application (not keycloak authentication enabled) ? If you don't have any, take a look at this for example: https://github.com/keycloak/keycloak/blob/master/testsuite/integration/src/test/java/org/keycloak/testsuite/adapter/SessionServlet.java Thanks, Marek On 5.3.2015 17:18, Lakshmi Narayana VADALI (lvadali) wrote: Hi Marek, Yes we have "" tag in web.xml. We are using EAP 6.3.0-1. Thanks, Lakshmi Narayana V From: Marek Posolda [mailto:mposolda at redhat.com] Sent: Thursday, March 05, 2015 8:55 PM To: Lakshmi Narayana VADALI (lvadali); keycloak-dev at lists.jboss.org Subject: Re: [keycloak-dev] Application clustering Issue with Keycloak 1.1.0_Final Hi, do you have "" tag in web.xml? Do you have Wildfly or EAP6 for your application and which version? Thanks, Marek On 5.3.2015 14:12, Lakshmi Narayana VADALI (lvadali) wrote: Hi, We are using keycloak 1.1.0_Final. We are trying Application clustering using jboss (domain mode). We Tested clustering setup (with cluster-demo application provided by jboss) which is working. But With Latest keycloak-adapter looks like keycloak-sessions are not replicated. We are always redirected to Keycloak when the request lands new node of cluster. We are able to make our setup work if we use cookie store, But we wanted to use Session store rather than cookie store. When we bringup our nodes we are able to receive below logs INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (Incoming-10,shared=udp) ISPN000094: Received new cluster view: [node1/web|1] (2) [node1/web, node2/web] Thanks, Lakshmi Narayana V _______________________________________________ keycloak-dev mailing list keycloak-dev at lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150330/33be3368/attachment-0001.html From mposolda at redhat.com Mon Mar 30 11:36:36 2015 From: mposolda at redhat.com (Marek Posolda) Date: Mon, 30 Mar 2015 17:36:36 +0200 Subject: [keycloak-dev] Client getting 405 response for POST API using stateless adapter In-Reply-To: References: Message-ID: <55196D84.60600@redhat.com> I will take a look at it and will let you know. Marek On 30.3.2015 08:33, Bappaditya Gorai (bgorai) wrote: > > Hi Team, > > We are facing following issue in Keycloak 1.1.0_Final release. I am > using *stateless adapter* configuration i.e * tokenstore is cookie*. > > I have an API endpoint which support *POST *method. While accessing > this API client is receiving 405 (Method not allowed) response. Same > works fine if adapter is **not*** *stateless. > > From my understanding looks like 302 response of CODE_TO_TOKEN is > causing the Client to access the Resource Endpoint as GET method which > is not allowed in my case( My API endpoint only supports POST). > > Do you have any fix for this? > > Thanks > > Bappaditya Gorai > > > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150330/3b3707f1/attachment.html From mposolda at redhat.com Mon Mar 30 17:00:03 2015 From: mposolda at redhat.com (Marek Posolda) Date: Mon, 30 Mar 2015 23:00:03 +0200 Subject: [keycloak-dev] application session state update In-Reply-To: <1B725C3C52B62D42A8A766BB4EFFCA2C43CECE8FF8@srv-mail01.aoemedia.lan> References: <1B725C3C52B62D42A8A766BB4EFFCA2C43CECE8FF8@srv-mail01.aoemedia.lan> Message-ID: <5519B953.6090802@redhat.com> On 27.3.2015 17:22, Sebastian Rose wrote: > > Hi everyone, > > The endpoint /auth/realms//protocol/openid-connect/access/codes > has a parameter for the session id of a secured application (adapters > use it): application_session_state. The Endpoint > /auth/realms//protocol/openid-connect/refresh has not. At least > this is what i saw within the code. Sorry, if it's there. > > We have integrated our own application a la adapter, using these two > url's and it's working fine. Our application completes the login via > the first endpoint and changes it's session id after the successful > login. This means when a logout event is send to our application, the > old session id is used. > So you're not using servlet API but something completely different? Which framework are you using? Just curious about your usecase as in normal servlet application the HttpSession ID is same for the whole life of user interaction and doesn't need to be changed after authentication (or during refresh). Marek > > So i'm asking if it makes sense to you to have the same parameter for > the refresh-url to cover our requirement or to integrate an > application_session_state update endpoint to add/delete/update > additional/new session id's. > > Best Regrads > > Sebastian > > > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150330/5546e1db/attachment.html From bastian.ike at aoe.com Tue Mar 31 03:24:09 2015 From: bastian.ike at aoe.com (Bastian Ike) Date: Tue, 31 Mar 2015 09:24:09 +0200 Subject: [keycloak-dev] application session state update In-Reply-To: <5519B953.6090802@redhat.com> Message-ID: Hi guys, We're connecting Magento with Keycloak, and the SID is regenerated after every change of the login status to prevent session fixation attacks where attackers might be able to enforce a session id or observe a session id prior to authentication and can later access useraccounts by requesting private resources using these session ids. SID refreshs are a common way to prevent this kind of issues and to ensure that no old SID's are leaked and cannot be enforced or predicted. Regards, Bastian Von: Marek Posolda > Datum: Mon, 30 Mar 2015 23:00:03 +0200 An: Sebastian Rose >, "keycloak-dev at lists.jboss.org" > Betreff: Re: [keycloak-dev] application session state update On 27.3.2015 17:22, Sebastian Rose wrote: Hi everyone, The endpoint /auth/realms//protocol/openid-connect/access/codes has a parameter for the session id of a secured application (adapters use it): application_session_state. The Endpoint /auth/realms//protocol/openid-connect/refresh has not. At least this is what i saw within the code. Sorry, if it's there. We have integrated our own application a la adapter, using these two url's and it's working fine. Our application completes the login via the first endpoint and changes it's session id after the successful login. This means when a logout event is send to our application, the old session id is used. So you're not using servlet API but something completely different? Which framework are you using? Just curious about your usecase as in normal servlet application the HttpSession ID is same for the whole life of user interaction and doesn't need to be changed after authentication (or during refresh). Marek So i'm asking if it makes sense to you to have the same parameter for the refresh-url to cover our requirement or to integrate an application_session_state update endpoint to add/delete/update additional/new session id's. Best Regrads Sebastian _______________________________________________ keycloak-dev mailing list keycloak-dev at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150331/58cd0e8e/attachment.html From stian at redhat.com Tue Mar 31 03:33:26 2015 From: stian at redhat.com (Stian Thorgersen) Date: Tue, 31 Mar 2015 03:33:26 -0400 (EDT) Subject: [keycloak-dev] application session state update In-Reply-To: References: Message-ID: <1314518274.8909518.1427787206897.JavaMail.zimbra@redhat.com> ----- Original Message ----- > From: "Bastian Ike" > To: "Marek Posolda" , "Sebastian Rose" , keycloak-dev at lists.jboss.org > Sent: Tuesday, 31 March, 2015 9:24:09 AM > Subject: Re: [keycloak-dev] application session state update > > Hi guys, > > We're connecting Magento with Keycloak, and the SID is regenerated after > every change of the login status to prevent session fixation attacks where > attackers might be able to enforce a session id or observe a session id > prior to authentication and can later access useraccounts by requesting > private resources using these session ids. > > SID refreshs are a common way to prevent this kind of issues and to ensure > that no old SID's are leaked and cannot be enforced or predicted. I don't think this is relevant to this discussion, but in either case that's not an issue in Keycloak. The session id in Keycloak is just a reference to a specific user session and only valid for the lifetime of the session (it's also a UUID so is not predictable). Having the knowledge of a session id doesn't provide an attacker with anything more than say a username, it's just a reference. > > > Regards, Bastian > > > Von: Marek Posolda < mposolda at redhat.com > > Datum: Mon, 30 Mar 2015 23:00:03 +0200 > An: Sebastian Rose < sebastian.rose at aoe.com >, " keycloak-dev at lists.jboss.org > " < keycloak-dev at lists.jboss.org > > Betreff: Re: [keycloak-dev] application session state update > > On 27.3.2015 17:22, Sebastian Rose wrote: > > > > > > Hi everyone, > > > > The endpoint /auth/realms//protocol/openid-connect/access/codes has a > parameter for the session id of a secured application (adapters use it): > application_session_state. The Endpoint > /auth/realms//protocol/openid-connect/refresh has not. At least this > is what i saw within the code. Sorry, if it's there. > > > > We have integrated our own application a la adapter, using these two url's > and it's working fine. Our application completes the login via the first > endpoint and changes it's session id after the successful login. This means > when a logout event is send to our application, the old session id is used. > So you're not using servlet API but something completely different? Which > framework are you using? Just curious about your usecase as in normal > servlet application the HttpSession ID is same for the whole life of user > interaction and doesn't need to be changed after authentication (or during > refresh). > > Marek > > > > > > > > > > So i'm asking if it makes sense to you to have the same parameter for the > refresh-url to cover our requirement or to integrate an > application_session_state update endpoint to add/delete/update > additional/new session id's. > > > > > > > > > > Best Regrads > > Sebastian > > > > > > > > > _______________________________________________ > keycloak-dev mailing list keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev From mposolda at redhat.com Tue Mar 31 04:02:36 2015 From: mposolda at redhat.com (Marek Posolda) Date: Tue, 31 Mar 2015 10:02:36 +0200 Subject: [keycloak-dev] application session state update In-Reply-To: <1314518274.8909518.1427787206897.JavaMail.zimbra@redhat.com> References: <1314518274.8909518.1427787206897.JavaMail.zimbra@redhat.com> Message-ID: <551A549C.9090608@redhat.com> On 31.3.2015 09:33, Stian Thorgersen wrote: > > ----- Original Message ----- >> From: "Bastian Ike" >> To: "Marek Posolda" , "Sebastian Rose" , keycloak-dev at lists.jboss.org >> Sent: Tuesday, 31 March, 2015 9:24:09 AM >> Subject: Re: [keycloak-dev] application session state update >> >> Hi guys, >> >> We're connecting Magento with Keycloak, and the SID is regenerated after >> every change of the login status to prevent session fixation attacks where >> attackers might be able to enforce a session id or observe a session id >> prior to authentication and can later access useraccounts by requesting >> private resources using these session ids. >> >> SID refreshs are a common way to prevent this kind of issues and to ensure >> that no old SID's are leaked and cannot be enforced or predicted. > I don't think this is relevant to this discussion, but in either case that's not an issue in Keycloak. The session id in Keycloak is just a reference to a specific user session and only valid for the lifetime of the session (it's also a UUID so is not predictable). Having the knowledge of a session id doesn't provide an attacker with anything more than say a username, it's just a reference. That's actually related to the application session (kind of HttpSession ID in web application secured by keycloak). We can add support for changing application_session_state in refreshToken endpoint instead of introducing separate endpoint. Will it be sufficient for your usecase? Marek > >> >> Regards, Bastian >> >> >> Von: Marek Posolda < mposolda at redhat.com > >> Datum: Mon, 30 Mar 2015 23:00:03 +0200 >> An: Sebastian Rose < sebastian.rose at aoe.com >, " keycloak-dev at lists.jboss.org >> " < keycloak-dev at lists.jboss.org > >> Betreff: Re: [keycloak-dev] application session state update >> >> On 27.3.2015 17:22, Sebastian Rose wrote: >> >> >> >> >> >> Hi everyone, >> >> >> >> The endpoint /auth/realms//protocol/openid-connect/access/codes has a >> parameter for the session id of a secured application (adapters use it): >> application_session_state. The Endpoint >> /auth/realms//protocol/openid-connect/refresh has not. At least this >> is what i saw within the code. Sorry, if it's there. >> >> >> >> We have integrated our own application a la adapter, using these two url's >> and it's working fine. Our application completes the login via the first >> endpoint and changes it's session id after the successful login. This means >> when a logout event is send to our application, the old session id is used. >> So you're not using servlet API but something completely different? Which >> framework are you using? Just curious about your usecase as in normal >> servlet application the HttpSession ID is same for the whole life of user >> interaction and doesn't need to be changed after authentication (or during >> refresh). >> >> Marek >> >> >> >> >> >> >> >> >> >> So i'm asking if it makes sense to you to have the same parameter for the >> refresh-url to cover our requirement or to integrate an >> application_session_state update endpoint to add/delete/update >> additional/new session id's. >> >> >> >> >> >> >> >> >> >> Best Regrads >> >> Sebastian >> >> >> >> >> >> >> >> >> _______________________________________________ >> keycloak-dev mailing list keycloak-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> >> >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev From bastian.ike at aoe.com Tue Mar 31 04:14:15 2015 From: bastian.ike at aoe.com (Bastian Ike) Date: Tue, 31 Mar 2015 10:14:15 +0200 Subject: [keycloak-dev] application session state update In-Reply-To: <551A549C.9090608@redhat.com> Message-ID: Am 31.03.15 10:02 schrieb "Marek Posolda" unter : >On 31.3.2015 09:33, Stian Thorgersen wrote: >> >> ----- Original Message ----- >>> From: "Bastian Ike" >>> To: "Marek Posolda" , "Sebastian Rose" >>>, keycloak-dev at lists.jboss.org >>> Sent: Tuesday, 31 March, 2015 9:24:09 AM >>> Subject: Re: [keycloak-dev] application session state update >>> >>> Hi guys, >>> >>> We're connecting Magento with Keycloak, and the SID is regenerated >>>after >>> every change of the login status to prevent session fixation attacks >>>where >>> attackers might be able to enforce a session id or observe a session id >>> prior to authentication and can later access useraccounts by requesting >>> private resources using these session ids. >>> >>> SID refreshs are a common way to prevent this kind of issues and to >>>ensure >>> that no old SID's are leaked and cannot be enforced or predicted. >> I don't think this is relevant to this discussion, but in either case >>that's not an issue in Keycloak. The session id in Keycloak is just a >>reference to a specific user session and only valid for the lifetime of >>the session (it's also a UUID so is not predictable). Having the >>knowledge of a session id doesn't provide an attacker with anything more >>than say a username, it's just a reference. Yes, this is not about the Keycloak session but about the connected application. I just wanted to answer Marek's question :) >That's actually related to the application session (kind of HttpSession >ID in web application secured by keycloak). We can add support for >changing application_session_state in refreshToken endpoint instead of >introducing separate endpoint. Will it be sufficient for your usecase? > >Marek That would help us a lot! Thanks, Bastian >> >>> >>> Regards, Bastian >>> >>> >>> Von: Marek Posolda < mposolda at redhat.com > >>> Datum: Mon, 30 Mar 2015 23:00:03 +0200 >>> An: Sebastian Rose < sebastian.rose at aoe.com >, " >>>keycloak-dev at lists.jboss.org >>> " < keycloak-dev at lists.jboss.org > >>> Betreff: Re: [keycloak-dev] application session state update >>> >>> On 27.3.2015 17:22, Sebastian Rose wrote: >>> >>> >>> >>> >>> >>> Hi everyone, >>> >>> >>> >>> The endpoint /auth/realms//protocol/openid-connect/access/codes >>>has a >>> parameter for the session id of a secured application (adapters use >>>it): >>> application_session_state. The Endpoint >>> /auth/realms//protocol/openid-connect/refresh has not. At least >>>this >>> is what i saw within the code. Sorry, if it's there. >>> >>> >>> >>> We have integrated our own application a la adapter, using these two >>>url's >>> and it's working fine. Our application completes the login via the >>>first >>> endpoint and changes it's session id after the successful login. This >>>means >>> when a logout event is send to our application, the old session id is >>>used. >>> So you're not using servlet API but something completely different? >>>Which >>> framework are you using? Just curious about your usecase as in normal >>> servlet application the HttpSession ID is same for the whole life of >>>user >>> interaction and doesn't need to be changed after authentication (or >>>during >>> refresh). >>> >>> Marek >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> So i'm asking if it makes sense to you to have the same parameter for >>>the >>> refresh-url to cover our requirement or to integrate an >>> application_session_state update endpoint to add/delete/update >>> additional/new session id's. >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> Best Regrads >>> >>> Sebastian >>> >>> >>> >>> >>> >>> >>> >>> >>> _______________________________________________ >>> keycloak-dev mailing list keycloak-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>> >>> >>> _______________________________________________ >>> keycloak-dev mailing list >>> keycloak-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev > From mposolda at redhat.com Tue Mar 31 04:28:00 2015 From: mposolda at redhat.com (Marek Posolda) Date: Tue, 31 Mar 2015 10:28:00 +0200 Subject: [keycloak-dev] application session state update In-Reply-To: <1B725C3C52B62D42A8A766BB4EFFCA2C43CEF5764F@srv-mail01.aoemedia.lan> References: <1314518274.8909518.1427787206897.JavaMail.zimbra@redhat.com>, <551A549C.9090608@redhat.com> <1B725C3C52B62D42A8A766BB4EFFCA2C43CEF5764F@srv-mail01.aoemedia.lan> Message-ID: <551A5A90.7050502@redhat.com> On 31.3.2015 10:16, Sebastian Rose wrote: >> That's actually related to the application session (kind of HttpSession >> ID in web application secured by keycloak). We can add support for >> changing application_session_state in refreshToken endpoint instead of >> introducing separate endpoint. Will it be sufficient for your usecase? >> Marek > As Bastian already said... > Thanks for your response. Yes, i think this would work for us. > > I will create a JIRA for that and contribute a change via pull request (if this is fine for you)? yep, thanks. There is some refactoring in latest master, you would need to look at TokenEndpoint.buildRefreshToken now (TokenEndpoint is new class, which didn't exist in 1.1.0.Final) Marek > > Best regards, > Sebastian From mposolda at redhat.com Tue Mar 31 05:43:51 2015 From: mposolda at redhat.com (Marek Posolda) Date: Tue, 31 Mar 2015 11:43:51 +0200 Subject: [keycloak-dev] Client getting 405 response for POST API using stateless adapter In-Reply-To: <55196D84.60600@redhat.com> References: <55196D84.60600@redhat.com> Message-ID: <551A6C57.40406@redhat.com> The issue is that we don't yet have support for save/restore requests after authentication in cookie store. I've created for that JIRA https://issues.jboss.org/browse/KEYCLOAK-1164 . As a workaround, you may need to initialize a login with different endpoint (GET request). Is it possible for your usecase? Marek On 30.3.2015 17:36, Marek Posolda wrote: > I will take a look at it and will let you know. > > Marek > > On 30.3.2015 08:33, Bappaditya Gorai (bgorai) wrote: >> >> Hi Team, >> >> We are facing following issue in Keycloak 1.1.0_Final release. I am >> using *stateless adapter* configuration i.e * tokenstore is cookie*. >> >> I have an API endpoint which support *POST *method. While accessing >> this API client is receiving 405 (Method not allowed) response. Same >> works fine if adapter is **not*** *stateless. >> >> From my understanding looks like 302 response of CODE_TO_TOKEN is >> causing the Client to access the Resource Endpoint as GET method >> which is not allowed in my case( My API endpoint only supports POST). >> >> Do you have any fix for this? >> >> Thanks >> >> Bappaditya Gorai >> >> >> >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150331/14f192d3/attachment.html From bburke at redhat.com Tue Mar 31 10:12:55 2015 From: bburke at redhat.com (Bill Burke) Date: Tue, 31 Mar 2015 10:12:55 -0400 Subject: [keycloak-dev] application session state update In-Reply-To: <551A5A90.7050502@redhat.com> References: <1314518274.8909518.1427787206897.JavaMail.zimbra@redhat.com>, <551A549C.9090608@redhat.com> <1B725C3C52B62D42A8A766BB4EFFCA2C43CEF5764F@srv-mail01.aoemedia.lan> <551A5A90.7050502@redhat.com> Message-ID: <551AAB67.8070700@redhat.com> On 3/31/2015 4:28 AM, Marek Posolda wrote: > On 31.3.2015 10:16, Sebastian Rose wrote: >>> That's actually related to the application session (kind of HttpSession >>> ID in web application secured by keycloak). We can add support for >>> changing application_session_state in refreshToken endpoint instead of >>> introducing separate endpoint. Will it be sufficient for your usecase? >>> Marek >> As Bastian already said... >> Thanks for your response. Yes, i think this would work for us. >> >> I will create a JIRA for that and contribute a change via pull request (if this is fine for you)? > yep, thanks. There is some refactoring in latest master, you would need > to look at TokenEndpoint.buildRefreshToken now (TokenEndpoint is new > class, which didn't exist in 1.1.0.Final) > I'm not understanding what you want here. You are worried about an attacker getting the HTTP session id of the application? You want the HttpSession id to change 1) after login, 2) after refresh token? How does this have anything to do with the auth server? Wouldn't this be an adapter feature? -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From bastian.ike at aoe.com Tue Mar 31 10:19:31 2015 From: bastian.ike at aoe.com (Bastian Ike) Date: Tue, 31 Mar 2015 16:19:31 +0200 Subject: [keycloak-dev] application session state update In-Reply-To: <551AAB67.8070700@redhat.com> Message-ID: Am 31.03.15 16:12 schrieb "Bill Burke" unter : > > >On 3/31/2015 4:28 AM, Marek Posolda wrote: >> On 31.3.2015 10:16, Sebastian Rose wrote: >>>> That's actually related to the application session (kind of >>>>HttpSession >>>> ID in web application secured by keycloak). We can add support for >>>> changing application_session_state in refreshToken endpoint instead of >>>> introducing separate endpoint. Will it be sufficient for your usecase? >>>> Marek >>> As Bastian already said... >>> Thanks for your response. Yes, i think this would work for us. >>> >>> I will create a JIRA for that and contribute a change via pull request >>>(if this is fine for you)? >> yep, thanks. There is some refactoring in latest master, you would need >> to look at TokenEndpoint.buildRefreshToken now (TokenEndpoint is new >> class, which didn't exist in 1.1.0.Final) >> > >I'm not understanding what you want here. You are worried about an >attacker getting the HTTP session id of the application? You want the >HttpSession id to change 1) after login, 2) after refresh token? How >does this have anything to do with the auth server? Wouldn't this be an >adapter feature? Yes, and 1) is already in place. I want to send the new session id to keycloak so when keycloak pushes the logout notification (using the application admin rest interface) I get the correct session id I need to logout in my application. The session id is saved in keycloak when we get the initial access codes using realms/realm/protocol/openid-connect/access/codes We can submit the application_session_state (so keycloak can push a logout for this session to our application), but we change it after this happend (after we are sure the authentication was successfull). At this point the SID in keycloak is different from the one we have newly created, so we need a way to update the application_session_state in keycloak. Marek's idea was to add this feature to the token-refresh endpoint so when we get a new access token we can send the new/updated application_session_state which will replace or add to the one in keycloak. I hope this clarifies it a little bit. > >-- >Bill Burke >JBoss, a division of Red Hat >http://bill.burkecentral.com >_______________________________________________ >keycloak-dev mailing list >keycloak-dev at lists.jboss.org >https://lists.jboss.org/mailman/listinfo/keycloak-dev From bburke at redhat.com Tue Mar 31 10:26:11 2015 From: bburke at redhat.com (Bill Burke) Date: Tue, 31 Mar 2015 10:26:11 -0400 Subject: [keycloak-dev] application session state update In-Reply-To: References: Message-ID: <551AAE83.8090907@redhat.com> On 3/31/2015 10:19 AM, Bastian Ike wrote: > Am 31.03.15 16:12 schrieb "Bill Burke" unter : > > >> >> >> On 3/31/2015 4:28 AM, Marek Posolda wrote: >>> On 31.3.2015 10:16, Sebastian Rose wrote: >>>>> That's actually related to the application session (kind of >>>>> HttpSession >>>>> ID in web application secured by keycloak). We can add support for >>>>> changing application_session_state in refreshToken endpoint instead of >>>>> introducing separate endpoint. Will it be sufficient for your usecase? >>>>> Marek >>>> As Bastian already said... >>>> Thanks for your response. Yes, i think this would work for us. >>>> >>>> I will create a JIRA for that and contribute a change via pull request >>>> (if this is fine for you)? >>> yep, thanks. There is some refactoring in latest master, you would need >>> to look at TokenEndpoint.buildRefreshToken now (TokenEndpoint is new >>> class, which didn't exist in 1.1.0.Final) >>> >> >> I'm not understanding what you want here. You are worried about an >> attacker getting the HTTP session id of the application? You want the >> HttpSession id to change 1) after login, 2) after refresh token? How >> does this have anything to do with the auth server? Wouldn't this be an >> adapter feature? > Yes, and 1) is already in place. > I want to send the new session id to keycloak so when keycloak pushes the > logout notification (using the application admin rest interface) I get the > correct session id I need to logout in my application. > > The session id is saved in keycloak when we get the initial access codes > using > realms/realm/protocol/openid-connect/access/codes > We can submit the application_session_state (so keycloak can push a logout > for this session to our application), but we change it after this happend > (after we are sure the authentication was successfull). At this point the > SID in keycloak is different from the one we have newly created, so we > need a way to update the application_session_state in keycloak. Marek's > idea was to add this feature to the token-refresh endpoint so when we get > a new access token we can send the new/updated application_session_state > which will replace or add to the one in keycloak. > > I hope this clarifies it a little bit. > Ok, that makes sense now. -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From bburke at redhat.com Tue Mar 31 11:40:40 2015 From: bburke at redhat.com (Bill Burke) Date: Tue, 31 Mar 2015 11:40:40 -0400 Subject: [keycloak-dev] logging of errors In-Reply-To: <44951513.8016575.1427694118903.JavaMail.zimbra@redhat.com> References: <55157531.6030903@redhat.com> <44951513.8016575.1427694118903.JavaMail.zimbra@redhat.com> Message-ID: <551ABFF8.3070501@redhat.com> Should this be enabled by default? On 3/30/2015 1:41 AM, Stian Thorgersen wrote: > We already have a jboss-logging events logger. You can enable it through the admin console. > > ----- Original Message ----- >> From: "Bill Burke" >> To: keycloak-dev at lists.jboss.org >> Sent: Friday, 27 March, 2015 4:20:17 PM >> Subject: [keycloak-dev] logging of errors >> >> While we do create appropriate events when errors happen, we do not do >> any logging. Should we be logging too when errors happen? Many times I >> have no idea what went wrong and have to guess how I might have >> configured keycloak incorrectly. >> -- >> Bill Burke >> JBoss, a division of Red Hat >> http://bill.burkecentral.com >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From ssilvert at redhat.com Tue Mar 31 11:48:53 2015 From: ssilvert at redhat.com (Stan Silvert) Date: Tue, 31 Mar 2015 11:48:53 -0400 Subject: [keycloak-dev] logging of errors In-Reply-To: <551ABFF8.3070501@redhat.com> References: <55157531.6030903@redhat.com> <44951513.8016575.1427694118903.JavaMail.zimbra@redhat.com> <551ABFF8.3070501@redhat.com> Message-ID: <551AC1E5.4020102@redhat.com> On 3/31/2015 11:40 AM, Bill Burke wrote: > Should this be enabled by default? I would say that this depends on whether, out of the box, you want Keycloak to be optimized for development or production. Maybe we should do something like WildFly/EAP where, more or less, the community version ships optimized for development and the productized version ships optimized for production. > > On 3/30/2015 1:41 AM, Stian Thorgersen wrote: >> We already have a jboss-logging events logger. You can enable it through the admin console. >> >> ----- Original Message ----- >>> From: "Bill Burke" >>> To: keycloak-dev at lists.jboss.org >>> Sent: Friday, 27 March, 2015 4:20:17 PM >>> Subject: [keycloak-dev] logging of errors >>> >>> While we do create appropriate events when errors happen, we do not do >>> any logging. Should we be logging too when errors happen? Many times I >>> have no idea what went wrong and have to guess how I might have >>> configured keycloak incorrectly. >>> -- >>> Bill Burke >>> JBoss, a division of Red Hat >>> http://bill.burkecentral.com >>> _______________________________________________ >>> keycloak-dev mailing list >>> keycloak-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>> From stian at redhat.com Tue Mar 31 13:31:54 2015 From: stian at redhat.com (Stian Thorgersen) Date: Tue, 31 Mar 2015 13:31:54 -0400 (EDT) Subject: [keycloak-dev] logging of errors In-Reply-To: <551ABFF8.3070501@redhat.com> References: <55157531.6030903@redhat.com> <44951513.8016575.1427694118903.JavaMail.zimbra@redhat.com> <551ABFF8.3070501@redhat.com> Message-ID: <303796770.9342259.1427823114959.JavaMail.zimbra@redhat.com> We can change it to use debug for success and enable it by default for the master realm as well as new realms. That would show errors by default and wouldn't affect out of the box performance. ----- Original Message ----- > From: "Bill Burke" > To: "Stian Thorgersen" > Cc: keycloak-dev at lists.jboss.org > Sent: Tuesday, 31 March, 2015 5:40:40 PM > Subject: Re: [keycloak-dev] logging of errors > > Should this be enabled by default? > > On 3/30/2015 1:41 AM, Stian Thorgersen wrote: > > We already have a jboss-logging events logger. You can enable it through > > the admin console. > > > > ----- Original Message ----- > >> From: "Bill Burke" > >> To: keycloak-dev at lists.jboss.org > >> Sent: Friday, 27 March, 2015 4:20:17 PM > >> Subject: [keycloak-dev] logging of errors > >> > >> While we do create appropriate events when errors happen, we do not do > >> any logging. Should we be logging too when errors happen? Many times I > >> have no idea what went wrong and have to guess how I might have > >> configured keycloak incorrectly. > >> -- > >> Bill Burke > >> JBoss, a division of Red Hat > >> http://bill.burkecentral.com > >> _______________________________________________ > >> keycloak-dev mailing list > >> keycloak-dev at lists.jboss.org > >> https://lists.jboss.org/mailman/listinfo/keycloak-dev > >> > > -- > Bill Burke > JBoss, a division of Red Hat > http://bill.burkecentral.com > From leonardo.zanivan at gmail.com Tue Mar 31 16:51:54 2015 From: leonardo.zanivan at gmail.com (Leonardo Loch Zanivan) Date: Tue, 31 Mar 2015 20:51:54 +0000 Subject: [keycloak-dev] WildFly 9 adapter support Message-ID: I'm trying to deploy a keycloak secured application in WildFly 9.0.0-Beta2, but I got a NPE. It's working fine with WildFly 8.1.0-Final. 17:41:19,764 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-2) MSC000001: Failed to start service jboss.deployment.unit."app.war".POST_MODULE: org.jboss.msc.service.StartException in service jboss.deployment.unit."app.war".POST_MODULE: WFLYSRV0153: Failed to process phase POST_MODULE of deployment "app.war" at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:163) at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at java.lang.Thread.run(Thread.java:745) *Caused by: java.lang.NullPointerException at org.keycloak.subsystem.extension.KeycloakAdapterConfigDeploymentProcessor.deploy(KeycloakAdapterConfigDeploymentProcessor.java:73)* at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:156) ... 5 more 17:41:19,770 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 1) WFLYCTL0013: Operation ("deploy") failed - address: ([("deployment" => "app.war")]) - failure description: {"WFLYCTL0080: Failed services" => {"jboss.deployment.unit.\"app.war\".POST_MODULE" => "org.jboss.msc.service.StartException in service jboss.deployment.unit.\"app.war\".POST_MODULE: WFLYSRV0153: Failed to process phase POST_MODULE of deployment \"app.war\" Caused by: java.lang.NullPointerException"}} 17:41:19,771 ERROR [org.jboss.as.server] (management-handler-thread - 1) WFLYSRV0021: Deploy of deployment "app.war" was rolled back with the following failure message: {"WFLYCTL0080: Failed services" => {"jboss.deployment.unit.\"app.war\".POST_MODULE" => "org.jboss.msc.service.StartException in service jboss.deployment.unit.\"app.war\".POST_MODULE: WFLYSRV0153: Failed to process phase POST_MODULE of deployment \"app.war\" Caused by: java.lang.NullPointerException"}} -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150331/8c4bfc59/attachment.html From ssilvert at redhat.com Tue Mar 31 18:04:31 2015 From: ssilvert at redhat.com (Stan Silvert) Date: Tue, 31 Mar 2015 18:04:31 -0400 Subject: [keycloak-dev] WildFly 9 adapter support In-Reply-To: References: Message-ID: <551B19EF.7070006@redhat.com> On 3/31/2015 4:51 PM, Leonardo Loch Zanivan wrote: > I'm trying to deploy a keycloak secured application in WildFly > 9.0.0-Beta2, but I got a NPE. You may be the first one to try the adapter on WildFly 9. I'll probably have some time to look at it tomorrow. > > It's working fine with WildFly 8.1.0-Final. > > 17:41:19,764 ERROR [org.jboss.msc.service.fail] (MSC service thread > 1-2) MSC000001: Failed to start service > jboss.deployment.unit."app.war".POST_MODULE: > org.jboss.msc.service.StartException in service > jboss.deployment.unit."app.war".POST_MODULE: WFLYSRV0153: Failed to > process phase POST_MODULE of deployment "app.war" > at > org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:163) > at > org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) > at > org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at java.lang.Thread.run(Thread.java:745) > *Caused by: java.lang.NullPointerException > at > org.keycloak.subsystem.extension.KeycloakAdapterConfigDeploymentProcessor.deploy(KeycloakAdapterConfigDeploymentProcessor.java:73)* > at > org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:156) > ... 5 more > > 17:41:19,770 ERROR [org.jboss.as.controller.management-operation] > (management-handler-thread - 1) WFLYCTL0013: Operation ("deploy") > failed - address: ([("deployment" => "app.war")]) - failure > description: {"WFLYCTL0080: Failed services" => > {"jboss.deployment.unit.\"app.war\".POST_MODULE" => > "org.jboss.msc.service.StartException in service > jboss.deployment.unit.\"app.war\".POST_MODULE: WFLYSRV0153: Failed to > process phase POST_MODULE of deployment \"app.war\" > Caused by: java.lang.NullPointerException"}} > 17:41:19,771 ERROR [org.jboss.as.server] (management-handler-thread - > 1) WFLYSRV0021: Deploy of deployment "app.war" was rolled back with > the following failure message: > {"WFLYCTL0080: Failed services" => > {"jboss.deployment.unit.\"app.war\".POST_MODULE" => > "org.jboss.msc.service.StartException in service > jboss.deployment.unit.\"app.war\".POST_MODULE: WFLYSRV0153: Failed to > process phase POST_MODULE of deployment \"app.war\" > Caused by: java.lang.NullPointerException"}} > > > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150331/4c353fc1/attachment.html From bburke at redhat.com Tue Mar 31 20:37:52 2015 From: bburke at redhat.com (Bill Burke) Date: Tue, 31 Mar 2015 20:37:52 -0400 Subject: [keycloak-dev] brokered username Message-ID: <551B3DE0.2080205@redhat.com> When a user gets created I am changing it so that the UserModel username will be: brokerAlias + "." + username-imported-from-broker This is so that we don't have username conflicts. The downside is that if anybody relies on username, it will now have all these extra characters i.e. "facebook.bburke123" instead of "bburke123" Is this an ok stopgap until we have a better solution? I think just making the username null opens up a wide variety of potential problems as a lot of our codebase is dependent on username. -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com