July 2015 - keycloak-dev - Jboss List Archives

Keycloak OpenShift Cartridge updated to 1.3.1.Final

by Stian Thorgersen

Keycloak OpenShift Cartridge updated to 1.3.1.Final

10 years, 10 months

1
0
0 / 0

Email/ username case-sensitivity issues

by Marek Posolda

There are some case-sensitivity issues, which cause that sometimes you can add object with duplicated email/username into DB etc. Some details are at https://issues.jboss.org/browse/KEYCLOAK-1545 or https://issues.jboss.org/browse/KEYCLOAK-1551 . Those issues happened with LDAP, but generally issues are not LDAP specific - for example even without LDAP integration you can add user with email "JOHN(a)keycloak.org" and then "john(a)keycloak.org" . Second user is created successfully, which doesn't look correct to me. The solutions I can see is: 1) Ensure that username and email is always added lowercased into DB and then searched lowercased. We already fixed similar issues earlier, but not entirely . Right now, we are adding username lowercased and searching both username and email lowercased, but we are not adding email lowercased. I've sent PR when I am convert both username and email to lowercase in UserAdapter.setEmail and UserAdapter.setUserName - https://github.com/mposolda/keycloak/commit/66f16bf654fc22570ce9ef7b34c47... 2) Another approach can be to add usernames and emails case sensitively, but instead ensure that DB searching is case insensitive (lowercased). For JPA there is "lower" function in HQL, but I am not sure if it's supported for various databases (and I would really like to avoid DB specific failures TBH...;-) ). For Mongo there is possibility to search with regex to achieve case-insensitive search but it sucks due to performance- so in this case we may need to add separate columns username_lowercased and email_lowercased, which will be used for searching to ensure index is used... I like (1) much more and that's what I used in PR. Any objections against merging it? Or is it bad to assume that email are case insensitive? Strictly said, the "local" part of email is supposed to be case sensitive, so "JOHN(a)keycloak.org" and "john(a)keycloak.org" are theoretically different emails. But in reality most organizations and mail servers treat them as same emails - including Google. Just checked that I can successfully login to Google with MPosOLDA(a)gmail.com . Marek

10 years, 10 months

2
3
0 / 0

deprecated removals in future

by Bill Burke

We're accumulating deprecated metadata in models and data model. Eventually we should draw a line in the sand and say we will only support migration from a certain version to current. i.e. Keycloak 2.0 would only allow migration from the last 1.x version. We need to clean all the old stuff out prior to product. -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com

10 years, 10 months

3
15
0 / 0

Tell if user is logged in via idp

by Scott Rossillo

Is there a way to tell if a user logged in via an idp? We don't see anything on the access token or id token to indicate.

10 years, 10 months

2
3
0 / 0

How should reset-password-email work?

by Stan Silvert

http://keycloak.github.io/docs/rest-api/admin/realms/%7Brealm%7D/users/%7... I'm looking into KEYCLOAK-1543 [1], which concerns the REST API for reset-password-email [2]. I want to make sure I understand how this is meant to work. You make a call to send the user a reset-password email. And you specify a client id and a redirect uri. I assume the redirect uri is the place the user is sent after he changes his password? (via a link he clicks to continue) Right now, it looks like the code is checking the client config to make sure that the redirect uri is included in the client's "valid redirect uri's". So if redirect uri is specified then client id is also required? The problem is that currently, the redirect uri is ignored and the user is always sent to the base uri of the client. Please let me know if any of the above is incorrect. I want to make sure I have this right as I fix it and update the documentation. [1] https://issues.jboss.org/browse/KEYCLOAK-1543 [2] http://keycloak.github.io/docs/rest-api/admin/realms/%7Brealm%7D/users/%7...

10 years, 10 months

2
1
0 / 0

READ THIS! Updated line endings on all files

by Stian Thorgersen

Due to files have different line-endings if they are edited on Linux or Windows there's often issues with merging. To resolved this we've added .gitattributes file that sets the default line ending on files. This makes Git automatically convert line endings for us. One issue is that if you have commits that are not yet in master you may have issues rebasing on master after this change. This is caused by files you've changed may have different line endings causing in a merge conflict. This is easily resolved though. Instead of doing a regular rebase run it with: git rebase -Xignore-space-at-eol upstream/master If that doesn't work try: git rebase -X renormalize upstream/master If neither of those works let me know and we'll figure out something!

10 years, 10 months

1
0
0 / 0

Re: [keycloak-dev] [wildfly-dev] Feature pack provisioning

by Stian Thorgersen

----- Original Message ----- > From: "Jason Greene" <jason.greene(a)redhat.com> > To: "Marko Strukelj" <mstrukel(a)redhat.com> > Cc: "keycloak dev" <keycloak-dev(a)lists.jboss.org>, "WildFly Developers" <wildfly-dev(a)lists.jboss.org> > Sent: Thursday, 16 July, 2015 12:11:53 AM > Subject: Re: [wildfly-dev] Feature pack provisioning > > The feature-pack build tool is a tool thats intended for creating WildFly > distributions (#1), its not intended to create layered project/products[A] / > overlays (#2). For #2, the solution is really just packaging a subsystem in > an extension jar, and thats something easily achieved with just the standard > maven tools. > > I can certainly see why you would want to do #1 or #2, but I have a hard time > seeing why you would want to do both. #1 is our standalone Keycloak server distribution - this is the recommended distribution for production or non-JEE developers #2 is intended to be used by JEE developers so they can have the KC server bits available in a single WF instance for development - this is intended as a distribution for JEE developers only > > As to #3, the notion of a runtime provisioning system similar to something > like a yum tool is a long term goal, which I totally agree we need, but its > going to be a while before we can get there (Definitely not 10 nor 11). > Alexey has been assembling requirements for it, and has some ideas around > the packaging format. We really want to get it right, so the plan is to let > it grow organically until its proven to be a solid system, and only then > switch to it. > > [A] > https://developer.jboss.org/hfurl/redirectToHFURL.jspa?url=/docs/DOC-4792... > > On Jul 9, 2015, at 9:02 AM, Marko Strukelj <mstrukel(a)redhat.com> wrote: > > > > > > Currently wildfly-server-provisioning-maven-plugin always generates a full > > Wildfly distribution. For Keycloak project we have three different cases > > of provisioning, and it would be great to be able to cover it with a > > common wildfly provided tool: > > > > 1) full server distribution > > 2) overlay distribution (unzip into existing OOTB Wildfly distribution - > > your problem if you use unsupported Wildfly version) > > 3) provision into existing Wildfly server detecting version mismatches, and > > configuring existing and additional subsystems for Keycloak to run > > properly. > > > > > > First one is what’s currently supported, and what we use. > > > > Second one is what we currently hack up by extracting modules directory > > from (1) - it would support this use case better if > > wildfly-server-provisioning-maven-plugin could generate 'modules only' for > > example. > > > > The third one requires a CLI installer tool. I’m not aware that currently > > there is something for that, and we are loath to develop one from scratch. > > > > Is it realistic to expect 2) and 3) in not so distant future? > > > > > > - marko > > > > > > _______________________________________________ > > wildfly-dev mailing list > > wildfly-dev(a)lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/wildfly-dev > > -- > Jason T. Greene > WildFly Lead / JBoss EAP Platform Architect > JBoss, a division of Red Hat > > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev

10 years, 10 months

1
0
0 / 0

Requirements to Elytron for Client 2-way SSL authentication

by Marek Posolda

I want to doublecheck if we are on the same page regarding how client certificate authentication should work, so we know what are the requirements for Elytron to support it. This will allow us to improve things before the Elytron code freeze (end of August AFAIK) if needed. Right now, I am covering just Service accounts and authenticating of clients with the certificate. But I believe that for authenticate of users, the requirements will be similar. My view is: - Admin will upload certificate of some client via Keycloak admin console. (I guess many companies want to use their own certificate issued by their trusted CA. IMO later Keycloak should provide the ability to easily generate trusted certificates and act as CA - not sure if it's something Giriraj is looking at. But for now, I assume that trusted certificate is always provided by admin and uploaded to Keycloak admin console) - There is REST endpoint, which allows to authenticate with client certificate. For example "https://localhost:8443/auth/realms/demo/clients/certificate" . Client will be able to start SSL handshake with it's certificate when sending request to this endpoint. Server will then verify the underlying SSLSession from the SSL socket and check that valid client certificate was provided during handshake. It will authenticate client based on that. To cover this usecase, the Wildfly/Elytron should be able to: 1) Support "variable" 2-way SSL . In other words, there is possibility to set flag "setWantClientAuth(true)" in underlying SSLServerSocket. This means that I will be able to access admin console "https://localhost:8443/auth/admin" with my browser without client certificate, but I will be able to provide client certificate on the endpoint "https://localhost:8443/auth/realms/demo/clients/certificate" , which is deployed under same context 2) Dynamically upload it's truststore at runtime or provide SPI to add/remove/update certificates in truststore. This is needed, so that when admin uploads the certificate of client in KC admin console, I want my client to be able to authenticate with the certificate immediatelly without need to restart server and edit any JKS files . 3) Possibility to access underlying SSL Socket and SSL Session from the REST endpoint, so I am able to verify the certificate in REST endpoint (but maybe this one could be handled with our server subsystem if it's not available for normal apps?) WDYT? Am I missing something? Marek

10 years, 10 months

4
8
0 / 0

Re: [keycloak-dev] Custom KeycloakPrincipal in adapter

by Marcelo Arthur Sampaio

Hi, I created my custom valve to set my user principal in the security context. It would be possible to change the org.keycloak.subsystem.as7.KeycloakAdapterConfigDeploymentProcessor class so that the custom valve? I would like to be able to set my custom valve and extends the keycloakValve. Line 93: valve.setValveClass (KeycloakAuthenticatorValve.class.getName ()); maybe change to config the valve in module.xml or other config file. Thanks. Em 11/07/2015 05:59:55, Marek Posolda escreveu: > > Not sure why you need this. But maybe easiest is to create just Http Servlet filter (this can be configured in web.xml and doesn't use any tomcat/jboss-web specific stuff) . In this filter, you will create HttpServletRequestWrapper wrapping the original HttpServletRequest, but you will override just the method "getUserPrincipal" in your wrapper class. Here you can do any hacking you want and return any principal instance you want. All the data from Keycloak (KeycloakSecurityContext, AccessToken, IDToken, original KeycloakPrincipal...) are already available in the filter, so you can use them for create your own principal. > > Marek > > On 10.7.2015 21:02, Marcelo Arthur Sampaio wrote: > > > > > Hi, > > > > I need to implement my custom security Principal. > > What is the best way to do it in adapter for jboss eap. > > > > Create new adapter for my business extends RefreshableKeycloakSecurityContext, KeycloakAuthenticatorValve and set the new valve class in KeycloakAdapterConfigDeploymentProcessor? > > > > I need to set new attributes in principal and get principal in the SecurityContext. > > > > There is an other way? > > > > Thanks. > > - > > > > > > "Esta mensagem do SERVIÇO FEDERAL DE PROCESSAMENTO DE DADOS (SERPRO), empresa pública federal regida pelo disposto na Lei Federal nº 5.615, é enviada exclusivamente a seu destinatário e pode conter informações confidenciais, protegidas por sigilo profissional. Sua utilização desautorizada é ilegal e sujeita o infrator às penas da lei. Se você a recebeu indevidamente, queira, por gentileza, reenviá-la ao emitente, esclarecendo o equívoco." > > > > "This message from SERVIÇO FEDERAL DE PROCESSAMENTO DE DADOS (SERPRO) -- a government company established under Brazilian law (5.615/70) -- is directed exclusively to its addressee and may contain confidential data, protected under professional secrecy rules. Its unauthorized use is illegal and may subject the transgressor to the law's penalties. If you're not the addressee, please send it back, elucidating the failure." > > > > _______________________________________________ keycloak-dev mailing list > > keycloak-dev(a)lists.jboss.org> > > > https://lists.jboss.org/mailman/listinfo/keycloak-dev> > > - "Esta mensagem do SERVIÇO FEDERAL DE PROCESSAMENTO DE DADOS (SERPRO), empresa pública federal regida pelo disposto na Lei Federal nº 5.615, é enviada exclusivamente a seu destinatário e pode conter informações confidenciais, protegidas por sigilo profissional. Sua utilização desautorizada é ilegal e sujeita o infrator às penas da lei. Se você a recebeu indevidamente, queira, por gentileza, reenviá-la ao emitente, esclarecendo o equívoco." "This message from SERVIÇO FEDERAL DE PROCESSAMENTO DE DADOS (SERPRO) -- a government company established under Brazilian law (5.615/70) -- is directed exclusively to its addressee and may contain confidential data, protected under professional secrecy rules. Its unauthorized use is illegal and may subject the transgressor to the law's penalties. If you're not the addressee, please send it back, elucidating the failure."

10 years, 10 months

1
0
0 / 0

1.4.0.Final release on 28th

by Stian Thorgersen

I'm aiming to release 1.4.0.Final on the 28th so we need to wrap things up next week.

10 years, 10 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

keycloak-dev July 2015