Keycloak Modules developed for the Cloudtrust project
by Doswald Alistair
Hello,
I just wanted to let this mailing list know that for the Cloudtrust project (https://github.com/cloudtrust), we have developed a certain number modules for Keycloak. These are currently compatible with the version 3.4.3.Final of Keycloak, but we will make them compatible with Keycloak 4.X (where X will be the latest sub-version of Keycloak when we start working on this) as soon as we can. These modules are:
* keycloak-wsfed (https://github.com/cloudtrust/keycloak-wsfed): an implementation of the WS-Federation protocol for keycloak. This allows to select the WS-Federation protocol for Keycloak clients and for identity brokers.
* keycloak-authorization (https://github.com/cloudtrust/keycloak-authorization): this module allows the use of the client authorization system to prevent a user which is authenticated in a Keycloak realm to access a given client. It works no matter which protocol is used, and without the client having to support any extra protocol. Note: this solution is a bit hacky, but necessary for one of our use-cases.
* keycloak-client-mappers (https://github.com/cloudtrust/keycloak-client-mappers): a module for adding any mappers that we might need that are not yet part of Keycloak. Currently only contains a JavaScript mapper for SAML, analogous to the OIDC script mapper. I've noticed that there's an open issue for this feature (https://issues.jboss.org/browse/KEYCLOAK-5520). If desirable I could submit this code not as a module but a solution to the issue.
* keycloak-export (https://github.com/cloudtrust/keycloak-export): a module adding an endpoint to fully export a realm while Keycloak is still running (no need for restarts!).
Cheers,
Alistair
PS: I mailed this to both dev and user mailing lists as I believe it may interest members of both mailing lists. However, upon sending to the dev mailing list the first time it bounced. This is the second attempt.
6 years, 4 months
UMA2.0 & Policy permission evaluations for RPTs
by Gary Schulte
I encountered this late last week and created a JIRA for it, but in
retrospect I should probably have brought it up on the list as well.
https://issues.jboss.org/browse/KEYCLOAK-8134
briefly, for a uma 2.0 managed realm, I am seeing inconsistent behavior
when getting an RPT. When I request an RPT for the uma grant type
(urn:ietf:params:oauth:grant-type:uma-ticket) the policy/permissions are
not evaluated unless I specify some combination of resources/scopes for the
permission parameter(s).
I was expecting an unfiltered RPT to come back with permissions that are
specifically granted by policy as well as those granted by UMA2. As it is,
I have worked around it by specifying all of the "scope permissions's"
scopes (without resources) in the permission params. e.g.
...&permission=#edit&permission=#view&permission=#owner
I am encountering this on 4.1.0.Final and it appears to be present in
latest (4.3.0.Final)
Is this expected behavior?
--
Gary Schulte I Software Engineer
OpenGov
505-750-4279
gary.schulte(a)opengov.com
www.opengov.com
Silicon Valley
<https://www.google.com/maps/place/OpenGov+Inc/@37.4859652,-122.2121292,15...>
| Washington DC
<https://www.google.com/maps/place/1875+Connecticut+Ave+NW,+Washington,+DC...>
<https://www.google.com/maps/place/1875+Connecticut+Ave+NW,+Washington,+DC...>
<https://www.linkedin.com/company/opengov-inc>
<https://www.facebook.com/opengovinc>
6 years, 4 months
KEYCLOAK-4593 - large number of realms - approaching a solution
by Mariusz Zawadzki
Hi.
We're considering Keycloak as a solution for us to Authenticate and Authorize users.
We want to have separate realm for a customer but that requires hundreds possibly more realms in one keycloak.
I've looked into the code and currently the main bottle neck I see are calls to:
session.realms().getRealms();
During application initialization.
I've got a simple solution to one of those usages, so my question is.
What is the general approach to do this?
On github it is "one commit per issue", but the whole problem with many realms looks to have a lot of places to improve, and currently we are blocked by two places:
org.keycloak.services.managers.ApplianceBootstrap#isNewInstall
org.keycloak.services.managers.UserStorageSyncManager#bootstrapPeriodic
Regards,
Mariusz Zawadzki
6 years, 4 months
Keycloak to OpenLDAP - Password Policies
by Jamie McDowell
Hi Dev's,
Appreciate if you can help me with an issue i have with password policies federating from Keycloak (v3.4.3) to OpenLDAP. I have created 2 password policies on the OpenLDAP server, where i require one for end users and one for service accounts - these are defined in the specific OU's to where the accounts are held.
I have set the password policies for both users and service accounts (policy module, schema, overlay etc..) and can confirm that the policy is being picked up on the OpenLDAP host when i run the command ldappasswd for the user and enter less characters than the required password length (for example)
The issue i have is that within keycloak i haven't set any password policies as i would like this to use the one i have created within the OpenLDAP server. Can Keycloak be configured that this must check against the OpenLDAP password policy? I have one realm set up along with a client.
I have been trying to get this working now for the last 10 days and not getting very far.
Within my LDAP Mapper i have tried creating a msad-user-account-control-mapper however this does not work, i get provided with an error when resetting my user password "Failed to update password in Active Directory. Exception message: [LDAP: error code 17 - pwdLastSet: attribute type undefined"
I would have expected something like this considering i am not using AD.
Any suggestions would be appreciated
Regards,Jamie
6 years, 4 months
Locale cookie vs ui_locales priority
by Johannes Knutsen
Currently the LocaleHelper#getUserLocale chooses locale priority based
on the following order:
1. kc_locale query parameter
2. Locale cookie
3. User profile
4. ui_locales query parameter
5. Accept-Language http header
We are building clients which uses the ui_locales parameter to select
localization of the login to match the locale of the client.
Since the locale cookie has a higher priority than the ui_locales
query parameter, the ui_locales query parameter is ignored for any
auth requests with a kc_locale cookie present.
1. Do you see any implications of prioritizing the ui_locales
parameter above the locale cookie when resolving locale?
2. Are there reasons why the ui_locales does not update the locale
cookie value the same way kc_locale parameter does it?
Best regards,
Johannes Knutsen
6 years, 4 months
Authenticator SPI: correct way to recover from JPA PersistenceException
by Gary Schulte
Keycloak 4.1, standalone-ha, postgres db:
As a part of our migration to keycloak, we have a custom authenticator we
are using for the direct grant flow which will "lazily create" users.
If we fail to find the user in local storage, we create the user with
session data from a legacy IDP. This works well, except in the rare case
where multiple services are authenticating a user for the first time, we
end up with a race condition that yields a ModelDuplicateException:
[0m [31m17:31:41,417 ERROR
[org.keycloak.services.error.KeycloakErrorHandler] (default task-8)
Uncaught server error: org.keycloak.models.ModelDuplicateException:
javax.persistence.PersistenceException:
org.hibernate.exception.ConstraintViolationException: could not execute
statement
at
org.keycloak.connections.jpa.PersistenceExceptionConverter.convert(PersistenceExceptionConverter.java:57)
at
org.keycloak.connections.jpa.PersistenceExceptionConverter.invoke(PersistenceExceptionConverter.java:51)
at com.sun.proxy.$Proxy79.flush(Unknown Source)
at org.keycloak.models.jpa.JpaUserProvider.addUser(JpaUserProvider.java:94)
at
com.opengov.auth.keycloak.delphius.DelphiusAuthenticator.authenticate(DelphiusAuthenticator.java:123)
at
org.keycloak.authentication.DefaultAuthenticationFlow.processFlow(DefaultAuthenticationFlow.java:221)
at
org.keycloak.authentication.AuthenticationProcessor.authenticateOnly(AuthenticationProcessor.java:910)
at
org.keycloak.protocol.oidc.endpoints.TokenEndpoint.resourceOwnerPasswordCredentialsGrant(TokenEndpoint.java:547)
at
org.keycloak.protocol.oidc.endpoints.TokenEndpoint.processGrantRequest(TokenEndpoint.java:184)
...
Ideally we could avoid a 500 response and have the race 'loser' look up the
newly created user, but the session's transaction gets marked rollback, and
further lookup/sql operations fail.
I am not finding a way to flush or restart the transaction state in the
Provider.
I have implemented a failureChallenge that is essentially a 302 redirect
back to the same token endpoint, but there are circumstances where a
redirect loop occurs. I can sort out and handle these cases, but it feels
a bit crufty.
Is there a better/prescribed way to recover from JPA session errors in a
custom Authenticator?
TIA
Gary S
6 years, 4 months
Truststore SPI
by Stian Thorgersen
Was thinking some more about how to share certificate functionality between
user authentication and client authentication. Potentially also to SAML.
We could add a Truststore SPI. The TruststoreProvider interface would have
something like the following methods (quick mock stuff):
* boolean verifyCert(CertificateMatcher matcher)
* Set<String> listExpiring()
* void trustCert(Cert cert)
* void removeTrustedCert(String id)
* Cert getSavedCert(String id)
* void removeSavedCert(String id)
* void saveCert(Cert cert)
We'd have a default built-in TruststoreProvider. Potentially delegating
some stuff to Elytron, but it would have to store certs in the db. It would
deal with checking if cert is still valid, call cert validation like the
user cert does, etc..
For user and client authentication we'd use verifyCert primarily. We'd have
something like UserCertMatcher.create()... and
ClientCertMatcher.create()... In the admin console we could add an option
to add trusted certs (not sure how that'd work in a cluster). For SAML
clients we'd delegate storing certs to the Truststore SPI instead of
storing the cert data alongside the client. The truststore would also add
some metadata in the db about certs so we can easily query for expiring
certs.
6 years, 4 months
./target/dependency/log4j.properties
by Stian Thorgersen
Anyone know what this file is doing there? It seems to be a copy
of ./src/test/resources/log4j.properties
It seems this is copied when you run mvn build, but that results in changes
to ./src/test/resources/log4j.properties not taking affect when you're
working from the IDE.
6 years, 4 months
Configurable signature algorithms
by Stian Thorgersen
Currently, Keycloak always use RS256 both for access tokens and id tokens.
We're working on introducing support for more algorithms and the ability to
change the default for a realm and also for a client.
Now the question is should have we two options one for access token and
another for ID token. Or just one for both?
6 years, 4 months
