From ieugen at netdava.com Sat Dec 1 12:32:49 2018 From: ieugen at netdava.com (Eugen Stan) Date: Sat, 1 Dec 2018 19:32:49 +0200 Subject: [keycloak-dev] translate keycloak Message-ID: Hello, Where can we find the translation files for Keycloak and what is the process for upstreaming them? I found this place for comunity resources and would like to confirm that is the place to upload the files and the process / requirements for contributing upstream. https://github.com/keycloak/keycloak/tree/master/themes/src/main/resources-community/theme/base We are planning to deploy Keycloak for authentication for our services. We have users all accross the globe and we have translators that we can ask to translate. I'm planning to push the translations upstream once they are done (need to get approbal on this). Thanks, Eugen From alistair.doswald at elca.ch Tue Dec 4 05:36:29 2018 From: alistair.doswald at elca.ch (Doswald Alistair) Date: Tue, 4 Dec 2018 10:36:29 +0000 Subject: [keycloak-dev] Keycloak testsuite artifacts on maven, for module testing In-Reply-To: References: <59b2788fe019432c9c46236198a92d93@elca.ch> Message-ID: <7845f78eb1644b369474c5709742eb7e@elca.ch> Re-reading my mail, I feel that I may not have been very clear, sorry. So: For the cloudtrust project (on github: https://github.com/cloudtrust), we have developed or furthered a certain number of extensions (modules) for keycloak (I wrote a mail on this mailing list about them a few months back, and was asked to list them here: https://www.keycloak.org/extensions.html), for example an extension to allow keycloak to use ws-fed or to do a full export while running. We will also soon need to develop some new modules. We originally wrote those extensions for keycloak 3.4.3.Final, but we are currently updating them to the latest version of keycloak, and as part of the process, we are moving the unit tests from a mock-based system to arquillian, so that they are more meaningful. To simplify the task, and since the code is already there, we are using existing classes from the keycloak testsuite. We are currently only using classes from integration-arquillian-tests-base, for example the classes LoginPage and OAuthClient. For our current use I don?t actually expect to use classes from any other artifact, though since we are at the start of the process, I may be wrong about that. We are also using the pom from integration-arquillian-tests as a parent for our maven project for now, as a convenience. This will probably have to be changed in the future. And basically, though currently we are building keycloak to deploy the testsuite artifacts to our local artifactory to use them, I was wondering if they are already available on a public maven repository, or if they could be, like the other keycloak artifacts are. From: Stian Thorgersen Sent: vendredi 30 novembre 2018 09:31 To: Doswald Alistair Cc: keycloak-dev Subject: Re: [keycloak-dev] Keycloak testsuite artifacts on maven, for module testing Can you add a bit more details please? What modules and how are you using them? On Thu, 29 Nov 2018, 10:34 Doswald Alistair wrote: Hello, Are the keycloak testsuite artifacts pushed to a public repository? Or if not, would it be possible to publish them alongside the other keycloak artifacts? We are currently updating the cloudtrust keycloak modules to the latest version of keycloak, and as a part of that we are moving the tests from mocks to arquillian. Since there's a lot of great work already done, we reuse the keycloak testsuite artifacts for this. For our purposes this is fine (we have them cached in our local repository), but for anybody who wishes to build our modules from github it's a bit more cumbersome. On a more general level, it would probably also help other module developers who wish to unit test with arquillian. Best regards, Alistair _______________________________________________ keycloak-dev mailing list keycloak-dev at lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-dev From sthorger at redhat.com Tue Dec 4 10:25:33 2018 From: sthorger at redhat.com (Stian Thorgersen) Date: Tue, 4 Dec 2018 16:25:33 +0100 Subject: [keycloak-dev] Keycloak testsuite artifacts on maven, for module testing In-Reply-To: <7845f78eb1644b369474c5709742eb7e@elca.ch> References: <59b2788fe019432c9c46236198a92d93@elca.ch> <7845f78eb1644b369474c5709742eb7e@elca.ch> Message-ID: Thanks for the explanation. I'm not sure if it makes all that much sense to publish the artifacts as they are as it is all very much setup to support testing of Keycloak itself and as such contains a lot of complexity. You'll quite likely also often have to update it as we refactor/change our tests. Would be nice to have a simple way to test extensions with Arquillian though. On Tue, 4 Dec 2018 at 11:36, Doswald Alistair wrote: > Re-reading my mail, I feel that I may not have been very clear, sorry. > > > > So: For the cloudtrust project (on github: https://github.com/cloudtrust), > we have developed or furthered a certain number of extensions (modules) for > keycloak (I wrote a mail on this mailing list about them a few months back, > and was asked to list them here: https://www.keycloak.org/extensions.html), > for example an extension to allow keycloak to use ws-fed or to do a full > export while running. We will also soon need to develop some new modules. > > > > We originally wrote those extensions for keycloak 3.4.3.Final, but we are > currently updating them to the latest version of keycloak, and as part of > the process, we are moving the unit tests from a mock-based system to > arquillian, so that they are more meaningful. To simplify the task, and > since the code is already there, we are using existing classes from the > keycloak testsuite. > > > > We are currently only using classes from > integration-arquillian-tests-base, for example the classes LoginPage and > OAuthClient. For our current use I don?t actually expect to use classes > from any other artifact, though since we are at the start of the process, I > may be wrong about that. We are also using the pom from > integration-arquillian-tests as a parent for our maven project for now, as > a convenience. This will probably have to be changed in the future. > > > > And basically, though currently we are building keycloak to deploy the > testsuite artifacts to our local artifactory to use them, I was wondering > if they are already available on a public maven repository, or if they > could be, like the other keycloak artifacts are. > > > > *From:* Stian Thorgersen > *Sent:* vendredi 30 novembre 2018 09:31 > *To:* Doswald Alistair > *Cc:* keycloak-dev > *Subject:* Re: [keycloak-dev] Keycloak testsuite artifacts on maven, for > module testing > > > > Can you add a bit more details please? What modules and how are you using > them? > > > > On Thu, 29 Nov 2018, 10:34 Doswald Alistair wrote: > > Hello, > > Are the keycloak testsuite artifacts pushed to a public repository? Or if > not, would it be possible to publish them alongside the other keycloak > artifacts? > > We are currently updating the cloudtrust keycloak modules to the latest > version of keycloak, and as a part of that we are moving the tests from > mocks to arquillian. Since there's a lot of great work already done, we > reuse the keycloak testsuite artifacts for this. For our purposes this is > fine (we have them cached in our local repository), but for anybody who > wishes to build our modules from github it's a bit more cumbersome. On a > more general level, it would probably also help other module developers who > wish to unit test with arquillian. > > Best regards, > > Alistair > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > From sthorger at redhat.com Tue Dec 4 10:32:56 2018 From: sthorger at redhat.com (Stian Thorgersen) Date: Tue, 4 Dec 2018 16:32:56 +0100 Subject: [keycloak-dev] Wildcard for Valid Redirect URI Hostname In-Reply-To: References: Message-ID: Last time we discussed this I was rather reluctant to add this as I was never keen on redirect-uris having any wildcard in them at all. Strictly speaking it would be more correct if the app has a single callback which then takes care of opening the correct page in the app afterwards, but it is what it is. That being said my new point of view on it is that perhaps we should have a developer mode, or a way to review clients for secure configuration in production. So.... In summary I'm open to changes and there's no hard no at this point. Looking at what we support today it's wildcard at the end of the URI, which results in '*' being allowed (which is just plain daft TBH). I suggest we change the logic to allowing wildcard in two places: * In subdomain (i.e. *.domain.com, my-apps*.domain.com, my-*-apps.domain.com ) * In context path (https://domain.com/*, https://domain.com/app/*) For backwards compatiblity we should probably still allow the behavior today, but use a big fat warning somewhere if it doesn't match the two cases above. On Fri, 30 Nov 2018 at 20:40, Josh Cain wrote: > Dredging this one up again - I've had a couple more requests and instances > in which this would be useful... > > This still a hard "no"? we're evaluating workarounds at this point that > involved doing the redirect checking and CORS in authenticators and just > wildcarding the Keycloak constructs since they're not flexible enough for > what we need... > > Josh Cain | Senior Software Applications Engineer > *Identity and Access Management* > *Red Hat* > > > On Fri, Sep 23, 2016 at 4:05 AM Stian Thorgersen > wrote: > >> >> >> On 22 September 2016 at 22:54, Josh Cain wrote: >> >>> On Thu, Sep 22, 2016 at 2:27 AM, Stian Thorgersen >>> wrote: >>> >>>> >>>> >>>> On 21 September 2016 at 16:10, Josh Cain wrote: >>>> >>>>> On Wed, Sep 21, 2016 at 1:12 AM, Stian Thorgersen >>>> > wrote: >>>>> >>>>>> >>>>>> >>>>>> On 20 September 2016 at 16:15, Josh Cain >>>>>> wrote: >>>>>> >>>>>>> So I certainly get that we want to be as close to the spec as >>>>>>> possible - wholeheartedly agree. However, I'd also like to reiterate that >>>>>>> the main purpose of this is for lower/developer environments in which there >>>>>>> are a large number of developers who are frequently spinning up sanboxes >>>>>>> with apps that need SSO capabilities. Unless I want to open up the GUI in >>>>>>> these environments to the world, I'm left without a good CM option for >>>>>>> Keycloak. Any suggestions on the management of this? Right now I'm >>>>>>> looking at a high amount of manual overhead, or scripting it out with some >>>>>>> one-off config scripts that I'll have to wind up maintaining. Neither >>>>>>> option sounds appealing. >>>>>>> >>>>>> >>>>>> +1 This is a use-case we need to find a solution to >>>>>> >>>>> >>>>> Cool. Keep me posted - in the meantime I've started cobbling together >>>>> a few JAXRS scripts against the admin endpoint, but would ideally like >>>>> something more CM-y. Maybe something like ansible integration... >>>>> >>>>>> >>>>>> >>>>>>> >>>>>>> Hope you didn't get the wrong impression from the PR - I noted a >>>>>>> javascript library that was shared across several pages within a number of >>>>>>> subdomains. All pages share a similar look and feel, but due to the nature >>>>>>> of the content and topic can live at different subdomains or even have >>>>>>> slightly different page content implementations. Are we really going to >>>>>>> make the assertion that a 'client' cannot span subdomains? That seems to >>>>>>> be the implication here. And if so, is that necessarily more 'secure', or >>>>>>> does that just mean that implementers could simply favor a single domain >>>>>>> name with varying paths instead of categorically organized subdomains? >>>>>>> Seems like an implementation detail that can easily be circumvented and >>>>>>> does not inherently make an enclave more or less secure. >>>>>>> >>>>>> >>>>>> A shared JavaScript library is not an client/application it's a >>>>>> library. Not sure how you can argue that it's a client. A client has more >>>>>> than just a redirect uri. It has: >>>>>> >>>>>> * Base URL - so users can find the application. This will be more >>>>>> useful in the future once we introduce a SSO landing page and provide links >>>>>> to applications from the account management console >>>>>> * Consent - clients that require consents should allow users to give >>>>>> consent per-application, not per-library >>>>>> * Audit/log - audit and log both in admin console and account >>>>>> management relies on knowing what application, not what library, accessed a >>>>>> users account >>>>>> >>>>>> I really think you are misusing the concept of a client when you are >>>>>> using a client for a library and I disagree that this is a valid use-case. >>>>>> You are doing something wrong here. >>>>>> >>>>> >>>>> Thanks for further examining this use case, and I'm certainly open to >>>>> hearing you on this one if we're 'doing something wrong.' I do have some >>>>> further questions clarifying what that 'something' is. >>>>> >>>>> - Where does the Base URL requirement come from? I've not seen >>>>> that in any of the specifications. Is it more of a pragmatic >>>>> best-practice-ish kind of approach? If so, do we have evidence of >>>>> industry-wide adherence such that we can enforce it with a product? >>>>> - Let me make sure I understand your point about mis-using a >>>>> javascript 'library'. It feels like you're indicating that something like >>>>> a javascript status bar that uses keycloak.js can share the same 'client' >>>>> if, and only if, they share the same domain. So to illustrate, this would >>>>> be allowed: >>>>> >>>>> ? >>>>> >>>>> Since the above pages share the same 'Base URL', they may rightfully >>>>> be considered as 'valid' by Keycloak. However, according to the current >>>>> Keycloak implementation, the below diagram demonstrates how the same >>>>> application would *not* be allowed to delineate itself with the use of >>>>> subdomains: >>>>> >>>>> ? >>>>> >>>>> This constrains seems superficial for this use case. Am I >>>>> understanding this correctly? >>>>> >>>>> Again, I would contest that a logical 'application' can be comprised >>>>> of pages split across subdomains. What's more, sharing the same base URL >>>>> provides no guarantee of proper granularity for definition of a single >>>>> 'application'. >>>>> >>>> Your example there makes sense to me and I agree that in this case it >>>> could make sense to use the same client across multiple subdomains. I >>>> assumed you had a login status library that was reused on different >>>> applications. >>>> >>>> That doesn't justify having a wildcard for subdomain though. You should >>>> have separate redirect uris for each subdomain. >>>> >>> >>> I think we might have to just agree to disagree on this one. I think >>> that there remains a justification for wildcarding a subdomain since it can >>> be secured properly and would save on administrative burden. Same use case >>> for wildcards in the path, just a different URL element. >>> >>>> >>>>>> >>>>>>> >>>>>>> I completely agree with your argument that we should be striving for >>>>>>> the finest level of granularity with respect to client definition. I >>>>>>> understand the intentional segregation of logical clients by the >>>>>>> specification so as to keep one compromised client from affecting the >>>>>>> entire SSO ecosystem. However, I do think that there is a solid case for a >>>>>>> single 'client' that does stuff like spans subdomains, and that such a >>>>>>> client could be used in a secure manner. >>>>>>> >>>>>> >>>>>> Can you give me a real example of where an application has multiple >>>>>> subdomains? I just don't see it. >>>>>> >>>>> >>>>> Sure. amazon.com uses smile.amazon.com for its charitable donation >>>>> giving. At the end of the day it's exactly the *same* site, but with >>>>> slightly different content. Same "Application", but residing on a >>>>> different subdomain. Could probably crawl some frequently used sites to >>>>> find more, but that one came to mind first. >>>>> >>>> >>>> Actually I think that's a bad example and in that case it should be two >>>> separate clients. >>>> >>>> >>> >>> Really? So an app that has almost *exactly* identical function with >>> some stylistic and business rule differences deserves to be treated as a >>> different client altogether. >>> >>> Will kindly disagree, but note that there's also disagreement on this >>> one in implementations across the internet. For instance, Stack overflow >>> treats each different topic's forum as a client, and these happen to be >>> delineated by subdomains (however, notifications are shared across all >>> sites which is a bit of a mixed message if you asked me). Whereas github ( >>> gist.github.com), Facebook (m.facebook.com, touch.facebook.com, etc), >>> or Amazon (smile.amazon.com) will let a single app/account span >>> subdomains. >>> >>> I suppose the point was not so much to argue about which way is the >>> purest implementation, but more to align product features with valid, >>> real-world use cases. >>> >> >> No point in discussing that any further you're right. End of the day it >> doesn't matter as you've convinced me that an app can span multiple >> subdomains. >> >> >>> >>> >>>> >>>>> Are there any standards/restrictions/stated best practices against >>>>> this? This is the first time I've run up against problems with subdomains >>>>> used in this way, but I'm certainly open to hearing if it's in violation of >>>>> one of the above. >>>>> >>>> >>>> OIDC for one says simple string matching for redirect uris. I don't >>>> have any issue with splitting a client into subdomains if that makes sense >>>> (didn't think it did, but you've convinced me). My issue was purely with >>>> accepting wildcard for the subdomain as that allows all subdomains, not a >>>> clearly specified set. >>>> >>> >>> See above - don't see how we can allow wildcards in path for pragmatic >>> purposes (outside the spec) but exclude the domain from the same >>> treatment. I'm for allowing both. >>> >> >> To be honest we shouldn't have had in the path either. We should never >> have had the wildcard in the first place. It's down to a slightly less than >> optimal implementation of our adapters. They use any current URI as the >> redirect URI, but they should have had a specific callback URI >> ('.../app/oidc-callback' or something) that is the only callback URI for >> the app. The specific path should have been encoded into the state variable >> instead and once authenticated the adapter should forward to that page. >> That reduces the chance of any malicious code and especially any js >> snippets from intercepting the callback. >> >> You could for instance using something similar in your app. Have a >> callback for all subdomains then redirect once you've set cookies >> accordingly. However, you do need a list of subdomains for an app to set a >> cookie, so that kinda implies you need a static list of subdomains involved >> in one "app" in either case. >> >> >>> >>> Will take this one as a hard 'no' since the discussion has been ongoing >>> for so long. I think all the points are out there and have been fleshed >>> out; no use in beating a dead horse. Thanks again for the good discussion >>> - has been educational for me and more importantly very amiable ;-) >>> >>> I do have some follow-up questions on the client registration >>> functionality in Keycloak. Another thread perhaps? >>> >> >> Yep >> >> >>> >>> >>>> >>>> >>>>> >>>>>> >>>>>>> >>>>>>> At the end of the day, it feels like we're trying to force a >>>>>>> definition on what is a client. The discussion seems to acknowledge that >>>>>>> 'real world' application of this spec find wildcards useful (as your >>>>>>> suggestion for supporting them in the path), however the manner in which >>>>>>> they're used appropriately is up for debate. If we're living outside the >>>>>>> spec anyway, do we really have a firm leg to stand on for the assertion >>>>>>> that clients can have different paths but not subdomains? I don't see a >>>>>>> solid reason for this one. >>>>>>> >>>>>> >>>>>> We shouldn't have had the wildcard in the first place. The reason we >>>>>> need it is that our adapters use the current path for the application as >>>>>> the redirect-uri. In other OIDC providers you are limited to a simple >>>>>> string matching in which case it's usual to have a callback endpoint and >>>>>> encode the path in the state parameter. >>>>>> >>>>>> >>>>>>> >>>>>>> Some other thoughts I had on this that might be useful: >>>>>>> >>>>>>> - Some of the rub here is that maintaining a list of valid >>>>>>> redirects for something like string matching is a CM nightmare >>>>>>> (particularly in dev-ish environments). Something like an SPI to drop an >>>>>>> implementation in here where I can apply a little more powerful logic would >>>>>>> also do the job. Could this be used nefariously or poorly to circumvent >>>>>>> the specification? yeah, sure - but so can Authenticators, and they're >>>>>>> seen as a useful tool whereby developers can extend necessary functionality. >>>>>>> - Would you also consider something like a 'development mode' >>>>>>> flag that allowed for different options such as wildcards in different URL >>>>>>> parts? Would have to add a little more validation to define what is and is >>>>>>> not allowed, but would be useful for this case. >>>>>>> >>>>>>> I had the idea of an SPI or a developer mode, but ideally we'd find >>>>>> another way to deal with this. >>>>>> >>>>>> Have you looked at dynamic client registration by the way? That >>>>>> allows registering clients without UI access and with a limited initial >>>>>> access token. We're also soon going to have a client registration CLI that >>>>>> allows doing this. >>>>>> >>>>> >>>>> I'll dig into that more - I've not taken more than a cursory glance at >>>>> it. If we have more fine-grained control over token/client access it could >>>>> certainly be useful. >>>>> >>>>> >>>>>> >>>>>> >>>>>>> Thanks for good the discussion. As always, learning much and >>>>>>> enjoying it! >>>>>>> >>>>>>> Josh Cain | Software Applications Engineer >>>>>>> *Identity and Access Management* >>>>>>> *Red Hat* >>>>>>> +1 256-452-0150 >>>>>>> >>>>>>> On Tue, Sep 20, 2016 at 1:20 AM, Stian Thorgersen < >>>>>>> sthorger at redhat.com> wrote: >>>>>>> >>>>>>>> I appreciate this feature might be useful, so there's no need to >>>>>>>> discuss that aspect. The only issue I have with this PR is with regards to >>>>>>>> security and especially as it enables doing the "wrong" thing. >>>>>>>> >>>>>>>> With regards to redirect URIs with confidential clients they are >>>>>>>> still important, but not quite as important as they are for public client. >>>>>>>> This means redirect URIs can typically be more flexible with confidential >>>>>>>> clients without a significant risk. >>>>>>>> >>>>>>>> For public clients it's very important to lock these down as much >>>>>>>> as possible as they are the ONLY way to prevent malicious clients to gain >>>>>>>> access to the SSO session. This means we should actually tighten the >>>>>>>> requirements for redirect URIs not further relax them. For public clients >>>>>>>> the redirect URIs: >>>>>>>> >>>>>>>> * Should be as specific as possible. We should only allow wildcard >>>>>>>> in the path. I believe we should introduce this for both public and >>>>>>>> confidential clients. >>>>>>>> * Require HTTPs unless it's http://localhost. This is not so easy >>>>>>>> in development, so maybe we should have an option to run the server in >>>>>>>> "unsafe" mode for developers. >>>>>>>> >>>>>>>> Here's a quote from the OIDC spec around this: >>>>>>>> >>>>>>>> *"REQUIRED. Redirection URI to which the response will be sent. >>>>>>>> This URI MUST exactly match one of the Redirection URI values for the >>>>>>>> Client pre-registered at the OpenID Provider, with the matching performed >>>>>>>> as described in Section 6.2.1 of [RFC3986] (Simple String Comparison). The >>>>>>>> Redirection URI SHOULD use the https scheme; however, it MAY use the http >>>>>>>> scheme, provided that the Client Type is confidential, as defined in >>>>>>>> Section 2.1 of OAuth 2.0, and provided the OP allows the use of http >>>>>>>> Redirection URIs in this case. The Redirection URI MAY use an alternate >>>>>>>> scheme, such as one that is intended to identify a callback into a native >>>>>>>> application."* >>>>>>>> >>>>>>>> Looking at your comments on the PR it worries me slightly that you >>>>>>>> have a shared client for a "library". A library is not a client. A client >>>>>>>> is an instance of an application. Sharing the client will have impact on >>>>>>>> audit, what clients a user believes they are authenticated to. With regards >>>>>>>> to wildcard to allow any subdomains that is scary as your allowing any >>>>>>>> piece of code running on any subdomain within your domain to authenticate >>>>>>>> via that particular client. That could be an infected forum, something any >>>>>>>> user has executing, etc.. As long as the redirect URI permits it an >>>>>>>> application can obtain a token for a client for a user that is >>>>>>>> authenticated without the user knowing about it. Unless you enable consent >>>>>>>> that is, but if the user used the "real" client they would have given >>>>>>>> consent and the malicious client on a different subdomain can take >>>>>>>> advantage of it. >>>>>>>> >>>>>>>> In summary my opinion is that we can't accept this PR and that we >>>>>>>> further: >>>>>>>> >>>>>>>> * Allow wildcard only in path. This is actually still looser than >>>>>>>> the OIDC spec mandates as it requires a simple string comparison. >>>>>>>> * Require HTTPS (or custom scheme) for public clients. We may need >>>>>>>> a development mode that disables this. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On 19 September 2016 at 16:50, Josh Cain >>>>>>>> wrote: >>>>>>>> >>>>>>>>> Per KEYCLOAK-3585: >>>>>>>>> >>>>>>>>> Currently, valid redirect URI hostnames allow for wildcards at the >>>>>>>>> end like so: >>>>>>>>> >>>>>>>>> http://www.redhat.com/* >>>>>>>>> >>>>>>>>> I'm managing several environments where clients need 'n' number of >>>>>>>>> available redirect URI's with different hostnames, I.E. >>>>>>>>> >>>>>>>>> http://developer1.env.redhat.com >>>>>>>>> >>>>>>>>> http://developer2.env.redhat.com >>>>>>>>> >>>>>>>>> http://developer3.env.redhat.com >>>>>>>>> >>>>>>>>> Would really help to have the ability to wildcard hostnames too, >>>>>>>>> I.E.: >>>>>>>>> >>>>>>>>> http://*.env.redhat.com >>>>>>>>> >>>>>>>>> >>>>>>>>> I've submitted #3241 >>>>>>>>> to address this >>>>>>>>> issue, but there seem to be some concerns about allowing wildcards in other >>>>>>>>> parts of the URL. See the PR for a more fleshed out discussion, but wanted >>>>>>>>> to start a thread here on the mailing list. Particularly with respect to: >>>>>>>>> >>>>>>>>> - Does anyone have need of this feature or would find it >>>>>>>>> useful? >>>>>>>>> - Should this kind of wildcard be allowed as a configuration >>>>>>>>> option by Keycloak? >>>>>>>>> >>>>>>>>> Josh Cain | Software Applications Engineer >>>>>>>>> *Identity and Access Management* >>>>>>>>> *Red Hat* >>>>>>>>> +1 256-452-0150 >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> keycloak-dev mailing list >>>>>>>>> keycloak-dev at lists.jboss.org >>>>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> -------------- next part -------------- A non-text attachment was scrubbed... Name: javascriptlibpath.png Type: image/png Size: 63746 bytes Desc: not available Url : http://lists.jboss.org/pipermail/keycloak-dev/attachments/20181204/06d31716/attachment-0002.png -------------- next part -------------- A non-text attachment was scrubbed... Name: javascriptlibdomain.png Type: image/png Size: 73920 bytes Desc: not available Url : http://lists.jboss.org/pipermail/keycloak-dev/attachments/20181204/06d31716/attachment-0003.png From alistair.doswald at elca.ch Tue Dec 4 11:41:32 2018 From: alistair.doswald at elca.ch (Doswald Alistair) Date: Tue, 4 Dec 2018 16:41:32 +0000 Subject: [keycloak-dev] Keycloak testsuite artifacts on maven, for module testing In-Reply-To: References: <59b2788fe019432c9c46236198a92d93@elca.ch> <7845f78eb1644b369474c5709742eb7e@elca.ch> Message-ID: <2b11954d240949178b8a5f690e3fbd13@elca.ch> I agree that it?s not necessarily Ideal, but I have found that there?s the advantage that the tests to be written for extensions (at least ours) can often be inspired from existing tests of similar features, and having some of the same classes available simplifies the process. This is not perfect, as sometimes this requires figuring out what?s going on in the testsuite code, and also some functional code is in the test section, and thus not available in the artifacts. For updating its not really a problem however (I hope). It?s something that often has to be done anyway for extensions when keycloak changes version, though it may cause some extra work to account for the refactoring of the testsuite classes as well. On balance, at least for now, I feel that reusing existing testsuite code lessens the development burden of the tests for extensions, which is why we went with this solution. From: Stian Thorgersen Sent: mardi 4 d?cembre 2018 16:26 To: Doswald Alistair Cc: keycloak-dev Subject: Re: [keycloak-dev] Keycloak testsuite artifacts on maven, for module testing Thanks for the explanation. I'm not sure if it makes all that much sense to publish the artifacts as they are as it is all very much setup to support testing of Keycloak itself and as such contains a lot of complexity. You'll quite likely also often have to update it as we refactor/change our tests. Would be nice to have a simple way to test extensions with Arquillian though. On Tue, 4 Dec 2018 at 11:36, Doswald Alistair > wrote: Re-reading my mail, I feel that I may not have been very clear, sorry. So: For the cloudtrust project (on github: https://github.com/cloudtrust), we have developed or furthered a certain number of extensions (modules) for keycloak (I wrote a mail on this mailing list about them a few months back, and was asked to list them here: https://www.keycloak.org/extensions.html), for example an extension to allow keycloak to use ws-fed or to do a full export while running. We will also soon need to develop some new modules. We originally wrote those extensions for keycloak 3.4.3.Final, but we are currently updating them to the latest version of keycloak, and as part of the process, we are moving the unit tests from a mock-based system to arquillian, so that they are more meaningful. To simplify the task, and since the code is already there, we are using existing classes from the keycloak testsuite. We are currently only using classes from integration-arquillian-tests-base, for example the classes LoginPage and OAuthClient. For our current use I don?t actually expect to use classes from any other artifact, though since we are at the start of the process, I may be wrong about that. We are also using the pom from integration-arquillian-tests as a parent for our maven project for now, as a convenience. This will probably have to be changed in the future. And basically, though currently we are building keycloak to deploy the testsuite artifacts to our local artifactory to use them, I was wondering if they are already available on a public maven repository, or if they could be, like the other keycloak artifacts are. From: Stian Thorgersen > Sent: vendredi 30 novembre 2018 09:31 To: Doswald Alistair > Cc: keycloak-dev > Subject: Re: [keycloak-dev] Keycloak testsuite artifacts on maven, for module testing Can you add a bit more details please? What modules and how are you using them? On Thu, 29 Nov 2018, 10:34 Doswald Alistair wrote: Hello, Are the keycloak testsuite artifacts pushed to a public repository? Or if not, would it be possible to publish them alongside the other keycloak artifacts? We are currently updating the cloudtrust keycloak modules to the latest version of keycloak, and as a part of that we are moving the tests from mocks to arquillian. Since there's a lot of great work already done, we reuse the keycloak testsuite artifacts for this. For our purposes this is fine (we have them cached in our local repository), but for anybody who wishes to build our modules from github it's a bit more cumbersome. On a more general level, it would probably also help other module developers who wish to unit test with arquillian. Best regards, Alistair _______________________________________________ keycloak-dev mailing list keycloak-dev at lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-dev From sthorger at redhat.com Tue Dec 4 12:09:50 2018 From: sthorger at redhat.com (Stian Thorgersen) Date: Tue, 4 Dec 2018 18:09:50 +0100 Subject: [keycloak-dev] Review Chinese translation update Message-ID: Can someone from the community please review updates to the Chinese translation? https://github.com/keycloak/keycloak/pull/5778 From sthorger at redhat.com Tue Dec 4 12:10:42 2018 From: sthorger at redhat.com (Stian Thorgersen) Date: Tue, 4 Dec 2018 18:10:42 +0100 Subject: [keycloak-dev] Review switch to UTF-8 encoding for Lithuanian translation Message-ID: Can someome from the community please review $sub? https://github.com/keycloak/keycloak/pull/5767 From sthorger at redhat.com Tue Dec 4 13:04:46 2018 From: sthorger at redhat.com (Stian Thorgersen) Date: Tue, 4 Dec 2018 19:04:46 +0100 Subject: [keycloak-dev] Keycloak testsuite artifacts on maven, for module testing In-Reply-To: <2b11954d240949178b8a5f690e3fbd13@elca.ch> References: <59b2788fe019432c9c46236198a92d93@elca.ch> <7845f78eb1644b369474c5709742eb7e@elca.ch> <2b11954d240949178b8a5f690e3fbd13@elca.ch> Message-ID: I appreciate that, but not sure I want to advocate this approach by dropping the jars into Maven. Atm we don't include anything from testsuite and that's intentional as we don't expect them to be used by anyone. On Tue, 4 Dec 2018 at 17:41, Doswald Alistair wrote: > I agree that it?s not necessarily Ideal, but I have found that there?s the > advantage that the tests to be written for extensions (at least ours) can > often be inspired from existing tests of similar features, and having some > of the same classes available simplifies the process. This is not perfect, > as sometimes this requires figuring out what?s going on in the testsuite > code, and also some functional code is in the test section, and thus not > available in the artifacts. > > > > For updating its not really a problem however (I hope). It?s something > that often has to be done anyway for extensions when keycloak changes > version, though it may cause some extra work to account for the refactoring > of the testsuite classes as well. > > > > On balance, at least for now, I feel that reusing existing testsuite code > lessens the development burden of the tests for extensions, which is why we > went with this solution. > > > > *From:* Stian Thorgersen > *Sent:* mardi 4 d?cembre 2018 16:26 > *To:* Doswald Alistair > *Cc:* keycloak-dev > *Subject:* Re: [keycloak-dev] Keycloak testsuite artifacts on maven, for > module testing > > > > Thanks for the explanation. > > > > I'm not sure if it makes all that much sense to publish the artifacts as > they are as it is all very much setup to support testing of Keycloak itself > and as such contains a lot of complexity. You'll quite likely also often > have to update it as we refactor/change our tests. > > > > Would be nice to have a simple way to test extensions with Arquillian > though. > > > > On Tue, 4 Dec 2018 at 11:36, Doswald Alistair > wrote: > > Re-reading my mail, I feel that I may not have been very clear, sorry. > > > > So: For the cloudtrust project (on github: https://github.com/cloudtrust), > we have developed or furthered a certain number of extensions (modules) for > keycloak (I wrote a mail on this mailing list about them a few months back, > and was asked to list them here: https://www.keycloak.org/extensions.html), > for example an extension to allow keycloak to use ws-fed or to do a full > export while running. We will also soon need to develop some new modules. > > > > We originally wrote those extensions for keycloak 3.4.3.Final, but we are > currently updating them to the latest version of keycloak, and as part of > the process, we are moving the unit tests from a mock-based system to > arquillian, so that they are more meaningful. To simplify the task, and > since the code is already there, we are using existing classes from the > keycloak testsuite. > > > > We are currently only using classes from > integration-arquillian-tests-base, for example the classes LoginPage and > OAuthClient. For our current use I don?t actually expect to use classes > from any other artifact, though since we are at the start of the process, I > may be wrong about that. We are also using the pom from > integration-arquillian-tests as a parent for our maven project for now, as > a convenience. This will probably have to be changed in the future. > > > > And basically, though currently we are building keycloak to deploy the > testsuite artifacts to our local artifactory to use them, I was wondering > if they are already available on a public maven repository, or if they > could be, like the other keycloak artifacts are. > > > > *From:* Stian Thorgersen > *Sent:* vendredi 30 novembre 2018 09:31 > *To:* Doswald Alistair > *Cc:* keycloak-dev > *Subject:* Re: [keycloak-dev] Keycloak testsuite artifacts on maven, for > module testing > > > > Can you add a bit more details please? What modules and how are you using > them? > > > > On Thu, 29 Nov 2018, 10:34 Doswald Alistair wrote: > > Hello, > > Are the keycloak testsuite artifacts pushed to a public repository? Or if > not, would it be possible to publish them alongside the other keycloak > artifacts? > > We are currently updating the cloudtrust keycloak modules to the latest > version of keycloak, and as a part of that we are moving the tests from > mocks to arquillian. Since there's a lot of great work already done, we > reuse the keycloak testsuite artifacts for this. For our purposes this is > fine (we have them cached in our local repository), but for anybody who > wishes to build our modules from github it's a bit more cumbersome. On a > more general level, it would probably also help other module developers who > wish to unit test with arquillian. > > Best regards, > > Alistair > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > From sthorger at redhat.com Tue Dec 4 13:27:56 2018 From: sthorger at redhat.com (Stian Thorgersen) Date: Tue, 4 Dec 2018 19:27:56 +0100 Subject: [keycloak-dev] Need review for Latvian translation Message-ID: We have an open PR for Latvian translations. Unless someone from the community can review it I will have to reject the PR. https://github.com/keycloak/keycloak/pull/5676 From lkrzyzan at redhat.com Thu Dec 6 04:39:03 2018 From: lkrzyzan at redhat.com (Libor Krzyzanek) Date: Thu, 6 Dec 2018 10:39:03 +0100 Subject: [keycloak-dev] Client in VERIFY_EMAIL event is "account" when doing in different browser Message-ID: Hi, I just realised that when user do verification email in restarted browser (or incognito mode or on different device) then the client is always ?account?. I expect that client in this event would be always the client during which user has been asked to verify e-mail and received the verification e-mail. It works in this way only if user do email verification on same device and same browser. Is my expectation correct? I?m using Keycloak 3.4.3.Final Should I fire a ticket? Thanks, Libor Krzy?anek Principal Software Engineer Middleware Engineering Services From s.kreutz at yieldlab.de Thu Dec 6 05:26:17 2018 From: s.kreutz at yieldlab.de (Steffen Kreutz) Date: Thu, 6 Dec 2018 11:26:17 +0100 Subject: [keycloak-dev] Custom UserStorageProvider for a different database Message-ID: Hey guys, I am trying to create a custom UserStorageProvider for an external Postgres database. I don?t wnat to manage the users in Keycloak, so I think it should be enough to implement UserStorageProvider and UserLookupProvider. Now I am wondering how I can configure and retrieve the datasource for my provider. I thought about adding another datasource to Wildfly. We run Keycloak in Kubernetes and I think setting up the datasource could be scripted using the jboss-cli. Do you think this is a good approach or do you have better advices? Best, Steffen From sthorger at redhat.com Thu Dec 6 09:08:31 2018 From: sthorger at redhat.com (Stian Thorgersen) Date: Thu, 6 Dec 2018 15:08:31 +0100 Subject: [keycloak-dev] Custom UserStorageProvider for a different database In-Reply-To: References: Message-ID: Hi, This mailing list is for Keycloak developers and contributors. For general questions and help please use the user mailing list. On Thu, 6 Dec 2018 at 11:27, Steffen Kreutz wrote: > Hey guys, > > I am trying to create a custom UserStorageProvider for an external > Postgres database. I don?t wnat to manage the users in Keycloak, so I think > it should be enough to implement UserStorageProvider and > UserLookupProvider. Now I am wondering how I can configure and retrieve the > datasource for my provider. I thought about adding another datasource to > Wildfly. We run Keycloak in Kubernetes and I think setting up the > datasource could be scripted using the jboss-cli. Do you think this is a > good approach or do you have better advices? > > Best, > > Steffen > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev From sthorger at redhat.com Thu Dec 6 09:09:25 2018 From: sthorger at redhat.com (Stian Thorgersen) Date: Thu, 6 Dec 2018 15:09:25 +0100 Subject: [keycloak-dev] Client in VERIFY_EMAIL event is "account" when doing in different browser In-Reply-To: References: Message-ID: Yeah, that sounds like a bug to me On Thu, 6 Dec 2018 at 10:40, Libor Krzyzanek wrote: > Hi, > I just realised that when user do verification email in restarted browser > (or incognito mode or on different device) then the client is always > ?account?. > > I expect that client in this event would be always the client during which > user has been asked to verify e-mail and received the verification e-mail. > It works in this way only if user do email verification on same device and > same browser. > > Is my expectation correct? > > I?m using Keycloak 3.4.3.Final > > Should I fire a ticket? > > Thanks, > > Libor Krzy?anek > Principal Software Engineer > Middleware Engineering Services > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev From guilhem.lucas at actility.com Fri Dec 7 05:40:32 2018 From: guilhem.lucas at actility.com (Guilhem Lucas) Date: Fri, 7 Dec 2018 11:40:32 +0100 Subject: [keycloak-dev] Make theme properties available in email templates Message-ID: Hello, I need to have theme properties available in Freemarker email templates (like in login and account theme). I overrided FreeMarkerEmailTemplateProvider to add them in a new attribute "properties", but I think it could be useful to have it by default in Keycloak. Is it possible to do it? If necessary I can create a pull request. Thank you. Guilhem Lucas From guilhem.lucas at actility.com Fri Dec 7 05:44:51 2018 From: guilhem.lucas at actility.com (Guilhem Lucas) Date: Fri, 7 Dec 2018 11:44:51 +0100 Subject: [keycloak-dev] Update password user experience Message-ID: Hello, Currently, a user choosing a password that violates password policies is notified for the first failing policy only. The user needs several attempts to find a valid password by discovering password policies one by one. I think that this is a bad user experience that could be enhanced by one of the following improvements. 1 - Display password policies in update password form Account and login Freemarker template provider could be modified to add a "policies" attribute in template context. This could be done by completing the RealmBean object with a passwordPolicies property that contains the list of enabled password policies. This new property could then be used in templates to display password requirements. For example: Your password must: - contain at least one symbol - contain at least one lower case character - have 8 characters minimum - not be equal of any of last 3 passwords 2- Report all failing policies Templates are already designed to display a list of errors. Instead of stop password validation on first policy error, it could be possible to continue validating other policies and return a list of errors. This list can be added to the template using the existing LoginFormsProvider#setErrors() method. Do you plan to add such improvement in a future release? Thank you. Guilhem Lucas From ssilvert at redhat.com Fri Dec 7 07:52:30 2018 From: ssilvert at redhat.com (Stan Silvert) Date: Fri, 7 Dec 2018 07:52:30 -0500 Subject: [keycloak-dev] Update password user experience In-Reply-To: References: Message-ID: <12538e99-336c-ed17-f6eb-40fe688169af@redhat.com> This comes up fairly often and we are planning to do something about it.? I suggest that you add your feedback here and vote up the JIRA: https://issues.jboss.org/browse/KEYCLOAK-7284 Stan On 12/7/2018 5:44 AM, Guilhem Lucas wrote: > Hello, > > Currently, a user choosing a password that violates password policies is > notified for the first failing policy only. The user needs several attempts > to find a valid password by discovering password policies one by one. > I think that this is a bad user experience that could be enhanced by one of > the following improvements. > > 1 - Display password policies in update password form > Account and login Freemarker template provider could be modified to add a > "policies" attribute in template context. This could be done by completing > the RealmBean object with a passwordPolicies property that contains the > list of enabled password policies. > This new property could then be used in templates to display password > requirements. > For example: > > Your password must: > - contain at least one symbol > > - contain at least one lower case character > > - have 8 characters minimum > - not be equal of any of last 3 passwords > > > 2- Report all failing policies > Templates are already designed to display a list of errors. Instead of stop > password validation on first policy error, it could be possible to continue > validating other policies and return a list of errors. This list can be > added to the template using the existing LoginFormsProvider#setErrors() > method. > > Do you plan to add such improvement in a future release? > > Thank you. > > Guilhem Lucas > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev From hmlnarik at redhat.com Fri Dec 7 14:20:53 2018 From: hmlnarik at redhat.com (Hynek Mlnarik) Date: Fri, 7 Dec 2018 20:20:53 +0100 Subject: [keycloak-dev] Client in VERIFY_EMAIL event is "account" when doing in different browser In-Reply-To: References: Message-ID: Nope, please check with latest Keycloak first. You should be redirected to the correct client. It was fixed in https://issues.jboss.org/browse/KEYCLOAK-7222. --Hynek On Thu, Dec 6, 2018 at 3:13 PM Stian Thorgersen wrote: > Yeah, that sounds like a bug to me > > On Thu, 6 Dec 2018 at 10:40, Libor Krzyzanek wrote: > > > Hi, > > I just realised that when user do verification email in restarted browser > > (or incognito mode or on different device) then the client is always > > ?account?. > > > > I expect that client in this event would be always the client during > which > > user has been asked to verify e-mail and received the verification > e-mail. > > It works in this way only if user do email verification on same device > and > > same browser. > > > > Is my expectation correct? > > > > I?m using Keycloak 3.4.3.Final > > > > Should I fire a ticket? > > > > Thanks, > > > > Libor Krzy?anek > > Principal Software Engineer > > Middleware Engineering Services > > > > _______________________________________________ > > keycloak-dev mailing list > > keycloak-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/keycloak-dev > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev From sthorger at redhat.com Mon Dec 10 05:02:32 2018 From: sthorger at redhat.com (Stian Thorgersen) Date: Mon, 10 Dec 2018 11:02:32 +0100 Subject: [keycloak-dev] Make theme properties available in email templates In-Reply-To: References: Message-ID: If I remember correctly these are already available to the login forms, so I have no issue with a PR for this as long as it's done consistently to how it's done in login forms. On Fri, 7 Dec 2018 at 11:42, Guilhem Lucas wrote: > Hello, > > I need to have theme properties available in Freemarker email templates > (like in login and account theme). > > I overrided FreeMarkerEmailTemplateProvider to add them in a new attribute > "properties", but I think it could be useful to have it by default in > Keycloak. > > Is it possible to do it? If necessary I can create a pull request. > > Thank you. > > Guilhem Lucas > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > From bhavana at browserstack.com Thu Dec 13 06:56:05 2018 From: bhavana at browserstack.com (Bhavana Motwani) Date: Thu, 13 Dec 2018 17:26:05 +0530 Subject: [keycloak-dev] Keycloak Premium Support Message-ID: Hi all, I'm new to this community! I had a query around paid support for Keycloak. The archives had some posts around 2016, but I could not find any latest update, so please excuse me if this is common knowledge. We are trying to use Keycloak for SSO auth of our customers. We were looking to buy Support for the same. We have not currently bought any other product like RH-SSO or JBoss Middleware. 1. Does buying https://www.redhat.com/en/store/red-hat-jboss-enterprise-application-platform#?sku=MW0196814 give me Support for Keycloak? 2. Is anything else also needed to be purchased? 3. Will this Support help with technical questions like configuring IdP-initiated workflows? We were able to make the SP-initiated workflows work, but getting stuck with IdP-initiated flow. Thank you From bhavana at browserstack.com Thu Dec 13 07:14:58 2018 From: bhavana at browserstack.com (Bhavana Motwani) Date: Thu, 13 Dec 2018 17:44:58 +0530 Subject: [keycloak-dev] RH-SSO release eta for Keycloak 4.5 Message-ID: Hi all Is the RH-SSO release around the corner for Keycloak4.5+? Thank you From sthorger at redhat.com Thu Dec 13 14:06:04 2018 From: sthorger at redhat.com (Stian Thorgersen) Date: Thu, 13 Dec 2018 20:06:04 +0100 Subject: [keycloak-dev] RH-SSO release eta for Keycloak 4.5 In-Reply-To: References: Message-ID: Yes, we are wrapping up now with the aim to release RH-SSO 7.3 Jan/Feb next year. As usual no guarantees for release dates though. On Thu, 13 Dec 2018 at 13:17, Bhavana Motwani wrote: > Hi all > > Is the RH-SSO release around the corner for Keycloak4.5+? > > Thank you > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > From sthorger at redhat.com Thu Dec 13 14:10:30 2018 From: sthorger at redhat.com (Stian Thorgersen) Date: Thu, 13 Dec 2018 20:10:30 +0100 Subject: [keycloak-dev] Keycloak Premium Support In-Reply-To: References: Message-ID: On Thu, 13 Dec 2018 at 13:02, Bhavana Motwani wrote: > Hi all, > I'm new to this community! > > I had a query around paid support for Keycloak. The archives had some posts > around 2016, but I could not find any latest update, so please excuse me if > this is common knowledge. > > > We are trying to use Keycloak for SSO auth of our customers. > We were looking to buy Support for the same. > We have not currently bought any other product like RH-SSO or JBoss > Middleware. > > 1. Does buying > > https://www.redhat.com/en/store/red-hat-jboss-enterprise-application-platform#?sku=MW0196814 > give > me Support for Keycloak? > Yes, but I would recommend contacting Red Hat sales first as there are other options available as well: https://access.redhat.com/support/contact/sales > 2. Is anything else also needed to be purchased? > See above > 3. Will this Support help with technical questions like configuring > IdP-initiated workflows? We were able to make the SP-initiated workflows > work, but getting stuck with IdP-initiated flow. > Yes, of course. IdP-initiated workflows are currently only supported for SAML though. With a subscription you can raise a RFE for additional features you need. > > Thank you > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > From quynh at axiadids.com Thu Dec 13 20:29:59 2018 From: quynh at axiadids.com (Quynh Nguyen) Date: Fri, 14 Dec 2018 01:29:59 +0000 Subject: [keycloak-dev] Why does LDAP AD federation in some cases does not have the first name mapper by default? Message-ID: <93CB18C9-553A-4DCB-9F7F-1EAF69B85EBA@axiadids.com> Hi, I would like to ask the reason why does LDAP AD federation in some cases does not have the first name mapper by default? What is the reason for that decision making? Best Regards, Quynh Nguyen From bhavana at browserstack.com Fri Dec 14 06:09:12 2018 From: bhavana at browserstack.com (Bhavana Motwani) Date: Fri, 14 Dec 2018 16:39:12 +0530 Subject: [keycloak-dev] IdP initiated flow issues Message-ID: Hi all, We are using Keycloak as a SP. So far we have done the following: - Configured an external IDP (eg. auth0) to broker the authentication in a realm. - Created an open-id connect client in the same realm - Using the keycloak-connect node lib in our web application to connect to client. - We are successfully able to do a SP initiated SSO authentication. Facing issues with IDP initiated SSO - Do we have to create a client in our Keycloak? if yes what will be the changes. - What will be the possible changes on the IDP side that we have brokered. We are trying with Auth0. - this is the link we are using : https://www.keycloak.org/docs/4.5/server_admin/index.html#idp-initiated-login , but documentation is not very clear. Thank you for the help From sthorger at redhat.com Fri Dec 14 06:19:27 2018 From: sthorger at redhat.com (Stian Thorgersen) Date: Fri, 14 Dec 2018 12:19:27 +0100 Subject: [keycloak-dev] IdP initiated flow issues In-Reply-To: References: Message-ID: Please use the user mailing list for general questions and help. This list is reserved for Keycloak team members and contributors. On Fri, 14 Dec 2018 at 12:16, Bhavana Motwani wrote: > Hi all, > > We are using Keycloak as a SP. > So far we have done the following: > > - Configured an external IDP (eg. auth0) to broker the authentication in > a realm. > - Created an open-id connect client in the same realm > - Using the keycloak-connect node lib in our web application to connect > to client. > - We are successfully able to do a SP initiated SSO authentication. > > > Facing issues with IDP initiated SSO > > - Do we have to create a client in our Keycloak? if yes what will be the > changes. > - What will be the possible changes on the IDP side that we have > brokered. We are trying with Auth0. > - this is the link we are using : > > https://www.keycloak.org/docs/4.5/server_admin/index.html#idp-initiated-login > , but documentation is not very clear. > > Thank you for the help > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > From fredbi at yahoo.com Sat Dec 15 05:57:35 2018 From: fredbi at yahoo.com (BIDON Frederic) Date: Sat, 15 Dec 2018 10:57:35 +0000 (UTC) Subject: [keycloak-dev] [keycloak-gatekeeper] Defense against cookie replay References: <715302306.4758995.1544871455574.ref@mail.yahoo.com> Message-ID: <715302306.4758995.1544871455574@mail.yahoo.com> Hello all I am working on a hybrid use-case in which the API gateway (keycloak-gatekeeper) checks trafficfrom (i) trusted server-side apps (e.g. serving server-based UIs) and (ii) browser apps (e.g. react JS apps). With case (i), traffic is authenticated against a bearer token in header, which is never exposed to the end user-agent.With case (ii), authentication is carried out with encrypted, httpOnly, Secure cookies. I am fine with this setup, but for the classical cookie replay attack (however, this is already strongly mitigated by the httpOnly flag, but not entirely satisfactory). So I have been experimenting a bit with introducing an automatic CSRF mechanism in gatekeeper, based on gorilla/csrf package. With CSRF enabled on a per protected resource basis, another encrypted cookie is carried back and forth to store the CSRF state and a header returned to the client. Obviously, CSRF check is disabled when a bearer token is present. This forces the browser app to add a volatile CSRF token every time it calls a mutable resource (e.g. with POST, PUT, DELETE) relayed by the gateway. I am currently polishing my POC with this feature and would be happy to contribute it as a PR. Pieces of advice, feedback and opinions are welcome. Cheers, Frederic From fredbi at yahoo.com Sat Dec 15 06:39:40 2018 From: fredbi at yahoo.com (BIDON Frederic) Date: Sat, 15 Dec 2018 11:39:40 +0000 (UTC) Subject: [keycloak-dev] [keycloak-gatekeeper] Rationale behind merged PR#440 In-Reply-To: <715302306.4758995.1544871455574@mail.yahoo.com> References: <715302306.4758995.1544871455574.ref@mail.yahoo.com> <715302306.4758995.1544871455574@mail.yahoo.com> Message-ID: <2053902479.4785475.1544873980932@mail.yahoo.com> TL;DR: PR#440 did break the way the redirection/state handling use to work. Need at least some explanation to get to work again with this. I had implemented the final landing page using encoded state, and accomodate the way leycloak-gatekeeper used to work. I understand that now, setting the state for further checks by the client at the end of the sequence of redirection is no more possible. Further, to control the final landing page, we must now use a special "request_uri" cookie... Am I assuming correctly? Another remark: I cannot find the associated JIRA 8984 so it is difficult to grasp the background of this change. The closest I could find is KEYCLOAK-8856, but no mention there of the strategy adopted with this PR. Could someone shed some light on this change? Fr?d?ric From ssilvert at redhat.com Sat Dec 15 08:02:02 2018 From: ssilvert at redhat.com (Stan Silvert) Date: Sat, 15 Dec 2018 08:02:02 -0500 Subject: [keycloak-dev] [keycloak-gatekeeper] Defense against cookie replay In-Reply-To: <715302306.4758995.1544871455574@mail.yahoo.com> References: <715302306.4758995.1544871455574.ref@mail.yahoo.com> <715302306.4758995.1544871455574@mail.yahoo.com> Message-ID: <01fbe842-1cd3-6903-35b9-f54b66d02697@redhat.com> This sounds interesting, but I wouldn't expect much feedback until January.? A lot of the Keycloak team is already on holiday. On 12/15/2018 5:57 AM, BIDON Frederic wrote: > Hello all > I am working on a hybrid use-case in which the API gateway (keycloak-gatekeeper) checks trafficfrom (i) trusted server-side apps (e.g. serving server-based UIs) and (ii) browser apps (e.g. react JS apps). > With case (i), traffic is authenticated against a bearer token in header, which is never exposed to the end user-agent.With case (ii), authentication is carried out with encrypted, httpOnly, Secure cookies. > I am fine with this setup, but for the classical cookie replay attack (however, this is already strongly mitigated by the httpOnly flag, but not entirely satisfactory). > So I have been experimenting a bit with introducing an automatic CSRF mechanism in gatekeeper, based on gorilla/csrf package. > With CSRF enabled on a per protected resource basis, another encrypted cookie is carried back and forth to store the CSRF state and a header returned to the client. Obviously, CSRF check is disabled when a bearer token is present. > > This forces the browser app to add a volatile CSRF token every time it calls a mutable resource (e.g. with POST, PUT, DELETE) relayed by the gateway. > I am currently polishing my POC with this feature and would be happy to contribute it as a PR. > > Pieces of advice, feedback and opinions are welcome. > Cheers, > Frederic > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev From bruno at abstractj.org Mon Dec 17 06:50:28 2018 From: bruno at abstractj.org (Bruno Oliveira) Date: Mon, 17 Dec 2018 09:50:28 -0200 Subject: [keycloak-dev] [keycloak-gatekeeper] Defense against cookie replay In-Reply-To: <01fbe842-1cd3-6903-35b9-f54b66d02697@redhat.com> References: <715302306.4758995.1544871455574.ref@mail.yahoo.com> <715302306.4758995.1544871455574@mail.yahoo.com> <01fbe842-1cd3-6903-35b9-f54b66d02697@redhat.com> Message-ID: Please, file a Jira as a feature request, providing all the details. In this way, we don't miss it. On Sat, Dec 15, 2018 at 11:02 AM Stan Silvert wrote: > > This sounds interesting, but I wouldn't expect much feedback until > January. A lot of the Keycloak team is already on holiday. > > On 12/15/2018 5:57 AM, BIDON Frederic wrote: > > Hello all > > I am working on a hybrid use-case in which the API gateway (keycloak-gatekeeper) checks trafficfrom (i) trusted server-side apps (e.g. serving server-based UIs) and (ii) browser apps (e.g. react JS apps). > > With case (i), traffic is authenticated against a bearer token in header, which is never exposed to the end user-agent.With case (ii), authentication is carried out with encrypted, httpOnly, Secure cookies. > > I am fine with this setup, but for the classical cookie replay attack (however, this is already strongly mitigated by the httpOnly flag, but not entirely satisfactory). > > So I have been experimenting a bit with introducing an automatic CSRF mechanism in gatekeeper, based on gorilla/csrf package. > > With CSRF enabled on a per protected resource basis, another encrypted cookie is carried back and forth to store the CSRF state and a header returned to the client. Obviously, CSRF check is disabled when a bearer token is present. > > > > This forces the browser app to add a volatile CSRF token every time it calls a mutable resource (e.g. with POST, PUT, DELETE) relayed by the gateway. > > I am currently polishing my POC with this feature and would be happy to contribute it as a PR. > > > > Pieces of advice, feedback and opinions are welcome. > > Cheers, > > Frederic > > _______________________________________________ > > keycloak-dev mailing list > > keycloak-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev -- - abstractj From sthorger at redhat.com Mon Dec 17 06:54:37 2018 From: sthorger at redhat.com (Stian Thorgersen) Date: Mon, 17 Dec 2018 12:54:37 +0100 Subject: [keycloak-dev] Keycloak 4.8.0.Final released Message-ID: To download the release go to the Keycloak homepage . For details on what is included in the release check out the Release notes The full list of resolved issues is available in JIRA . Before you upgrade remember to backup your database and check the upgrade guide for anything that may have changed. From mitzel at tawadi.de Wed Dec 19 06:00:52 2018 From: mitzel at tawadi.de (Wladislaw Mitzel) Date: Wed, 19 Dec 2018 12:00:52 +0100 (CET) Subject: [keycloak-dev] Questions about adding new identity providers Message-ID: <2014743213.11302.1545217252214@office.mailbox.org> Hi all, How is the addition of new identity providers handled in this project? I'd love to have a vk.com integration in keycloak. After some search, I've found this pull request [1] which adds PayPal as a new IdP. I think it's a pretty good "blueprint" of how to add a new IdP. I plan to give it a try and implement vk.com. This raises the following questions: 1) Is this implementation of a vk.com IdP something the project is interested in? 2) Does the answer to 1) apply to all IdPs? I mean vk.com is a quite large social network. What about some less known websites providing OAuth2 authentication. Would *any* IdP be added to the project? Are there certain criteria from which you can decide? 3) What do you think about a feature which would enable to "configure" arbitrary OAuth2 Providers as IdP using the Admin Console? To me most of the implementations of org.keycloak.broker.oidc.AbstractOAuth2IdentityProvider look pretty similar. The main differences are how to interpret the responses of the IdP: I wonder whether this could be generalised. I look forward to your answers, Kind Regards, Wladislaw [1] https://github.com/keycloak/keycloak/pull/4449 From mailsenik11 at gmail.com Wed Dec 19 14:36:33 2018 From: mailsenik11 at gmail.com (=?utf-8?B?0JDRgNGB0LXQvdC40Lkg0JrRgNCw0YHQtdC90YzQutC+0LI=?=) Date: Wed, 19 Dec 2018 22:36:33 +0300 Subject: [keycloak-dev] Token Verifier behaviour change since 4.4.0.Final Message-ID: <41B55708-2070-4FCD-92FF-3C313CA634AC@gmail.com> Hello everyone! I recently discovered undocumented behaviour change of Token Verification provider (ex RSATokenVerifier) starting from Keycloak ver. 4.4.0.Final caused by https://issues.jboss.org/browse/KEYCLOAK-7560. In short, TokenVerifier now by default does not perform check of token expiration. This causes, for example, successful responses for Userinfo requests even if token is being expired. Because this change was not documented I consider it as a bug and would like to create an issue. Any thoughts on this point? Sincerely, Arseny. From bhavana at browserstack.com Thu Dec 20 12:59:28 2018 From: bhavana at browserstack.com (Bhavana Motwani) Date: Thu, 20 Dec 2018 23:29:28 +0530 Subject: [keycloak-dev] Questions around keycloak IdP initiated flow In-Reply-To: References: Message-ID: Hi all We are using keycloak 4.5.0 for SP-initiated and IdP-initiated auth flows. We are using Auth0 as the external IdP for test purposes. We have managed the SP-initiated flow successfully. But we are facing issues with IdP initiated flow. I was hoping you could help. 1. Will the external IdP need two separate clients to connect to our keycloak instance, one for SP-initiated and other for IdP. PFA the metadata we generated for SP-initiated flow. The SingleLogoutService.Location and AssertionConsumerService.Location are ' https://shaktimaanhub.bsstag.com/auth/realms/browserstack/broker/oracle-stage/endpoint ' But, for IdP initiated flow, we are having to replace the above with ' https://shaktimaanhub.bsstag.com/auth/realms/browserstack/broker/oracle-stage/endpoint/clients/{client-name} ' This would result in 2 clients on the external IdP side. Is there a way to avoid this? 2. With the IdP initiated flow, we are also facing issues with backchannel logout. It gives a certificate issue. What certificate does keycloak expect? The SP client's or the external IdP's? Any help will be appreciated! Thank you once again. -------------- next part -------------- A non-text attachment was scrubbed... Name: bs_oracle_shaktimaan.xml Type: text/xml Size: 2226 bytes Desc: not available Url : http://lists.jboss.org/pipermail/keycloak-dev/attachments/20181220/5e179a4c/attachment.xml From mpeck at mitre.org Sun Dec 23 12:38:35 2018 From: mpeck at mitre.org (Peck, Michael A) Date: Sun, 23 Dec 2018 17:38:35 +0000 Subject: [keycloak-dev] User TLS client certificate authentication - inconsistent DN string representation with LDAP Message-ID: <5D9D597A-206A-4E7C-96E9-DB3368842117@mitre.org> Hello, I?ve configured Keycloak to authenticate users using TLS client certificate authentication. I?ve also configured Keycloak to synchronize users with my LDAP server. I?d like to match the TLS client certificate?s Subject DN to the Subject DNs synchronized from my LDAP server (which are stored by Keycloak in each user?s LDAP_ENTRY_DN attribute). I?ve set that up, but am running into an issue that Keycloak appears to have inconsistent string representations of DNs between those two methods - so the Subject DNs from the TLS client certificate and the LDAP server aren?t matching as I was expecting. The TLS client certificate DNs look like this: CN=Peck Michael, OU=People, DC=test, DC=net While the LDAP_ENTRY_DN attribute is formatted like this: cn=Peck Michael,ou=People,dc=test,dc=net It looks to me that the TLS client certificate DN string representation is coming from the standard Java X500Principal class used by calls to X509Certificate.getSubjectDN().getName() in keycloak/services/src/main/java/org/keycloak/authentication/authenticators/x509/X509ClientCertificateAuthenticator.java and the LDAP_ENTRY_DN string representation is coming from the toString method in keycloak/federation/ldap/src/main/java/org/keycloak/storage/ldap/idm/model/LDAPDn.java. I modified the LDAPDn class?s toString method to follow the same format as used in the TLS client certificate DNs, and authentication works for me now. Would the Keycloak project consider accepting a pull request to change the way LDAPDn formats DNs as strings? (However I have not checked if this would impact other uses of the LDAPDn class within Keycloak or cause problems with upgrading existing deployments?) The suggested change follows: diff --git a/federation/ldap/src/main/java/org/keycloak/storage/ldap/idm/model/LDAPDn.java b/federation/ldap/src/main/ index 39e7d97..2f8c805 100644 --- a/federation/ldap/src/main/java/org/keycloak/storage/ldap/idm/model/LDAPDn.java +++ b/federation/ldap/src/main/java/org/keycloak/storage/ldap/idm/model/LDAPDn.java @@ -87,9 +87,9 @@ public class LDAPDn { if (first) { first = false; } else { - builder.append(","); + builder.append(", "); } - builder.append(rdn.attrName).append("=").append(rdn.attrValue); + builder.append(rdn.attrName.toUpperCase()).append("=").append(rdn.attrValue); } return builder.toString(); Thank you, Michael Peck The MITRE Corporation