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 -
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 .
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.
JBoss, a division of Red Hat
I'm looking into KEYCLOAK-1543 , which concerns the REST API for
reset-password-email . 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.
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!
----- 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.
> > 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
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
- 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?
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.
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.
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
I need to set new attributes in principal and get principal in the
There is an other way?
"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
"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."