redhat sso get baseurl in custom theme for email registration
by Antonia Nicolaou
Hello all,
Your help would be greatly appreciated.
I am using single sign on service from redhat v7.1 and I am developing a
custom template (in a custom theme) for registration email. In the email,
Unfortunately, I didn’t find the proper way to get the client baseUrl or
the url.registrationUrl .
Could you please help me?
Thank you in advanced.
Sincerely,
Antonia Nicolaou
7 years, 5 months
Access Query Parameter in FreeMarker Template - Keycloak 2.1.0
by Bernhard Steindl
Hello,
I must access Query Parameters passed to my keycloak login theme.
Neither was I able to obtain them using
RequestParameters.paramName nor
request.getParameter(paramName)
in the login FreeMarker template.
Everytime I access a query parameter using these methods I get an FreeMarker error
2017-07-06 13:32:07,917 ERROR [freemarker.runtime] (default task-12) Error executing FreeMarker template:
freemarker.core.InvalidReferenceException: The following has evaluated to null or missing
I also found that there is an url object visible which provides a few keys to access.
I am using Keycloak 2.1.0 which includes a FreeMarker jar version 2.3.20.
Can anybody support me in this issue?
I need to use query params to dynamically display information on the login theme.
Kind Regards,
Bernhard
7 years, 5 months
Keycloak very slow on retrieving "events"
by Sarp Kaya
Hello,
When I click on Events, it takes very long time (more than a minute) just to display first 5 events. I checked what endpoint it uses and it’s using this:
"/auth/admin/realms/<realm-id>/events?first=0&max=5” endpoint.
I believe that there is something broken with the filtering option as it should never take more than a minute to just retrieve 5 results.
I’m using Keycloak 3.1.0 and MySQL for the database.
7 years, 5 months
Understanding "Server Principal" in Kerberos setup
by Malte Finsterwalder
Hi there,
I'm trying to set up Keycloak to use Kerberos with Active Directory.
But I'm not sure, I understand the Server Principal correctly.
Keycloak is running on a server, that is reachable under
keycloak.some.domain.com
The Kerberos Realm is whatever.else.com
So is the Server Principal correctly specified as:
HTTP/keycloak.some.domain.com(a)whatever.else.com
Or more general HTTP/<CLIENT HOST>@<Kerberos Realm>
And is <Kerberos Realm> in the Server Principal always the same as stated
in "Kerberos Realm" in the admin ui?
And does case matter anywhere?
Greetings,
Malte
7 years, 5 months
Identity provider, keycloak js adapter and session management
by Peter Nalyvayko
Hi,
We've hit a bit of a snag while setting up our one page js client. Changing the value of the "sub" claim to anything other than the unique identifier of the keycloak user causes the keycloak adapter to detect the changes to the session and clear out the tokens, forcing the users to re-log in after every 5 seconds.
We are using the version 2.3.0 of keycloak. Our app is set up to use keycloak.js adapter for all things related to OIDC. The adapter is configured to use the "code authorization" (standard) flow. The instance of keycloak is configured to use an external OIDC identity provider and the users are uniquely identified by their e-mails. Naturally, we wanted that the "sub" claim in the claim set returned by calling the keycloak's OIDC /token endpoint would return the unique identity of the external user rather than the internal identifier of the keycloak user, so we re-configured the keycloak client by adding a property mapper to map the user's email to the "sub" claim, here the example of the access token:
{
"sub": "user(a)company.com",
"iat": 223235098325,
"email": "user(a)company.com",
...
}
Once we had implemented these changes on the keycloak side, our users were able to initially sign into the application, but when they tried to access any functionality within the app, they would be prompted to sign in again. The problem seems to related to the OIDC session management and the assumption and the "sub" claim always matches the keycloak user's unique identifier.
We narrowed the problem down to four components:
- keycloak.js
- login-status-iframe.html
- services\srv\main\java\org\keycloak\protocol\oidc\endpoints\LoginStatusIframeEndpoint.java
- services\src\main\java\org\keycloak\services\managers\AuthenticationManager.java
In keycloak.js, line 637, the implementation creates a session id to be used to check the session state. Notice that the code uses the value from the "sub" claim:
var sessionId = kc.realm + "/" + kc.tokenParsed.sub;
In AuthenticationManager.createLoginCookie, line 306, the value of the "SESSION_COOKIE" is set to:
String sessionCookieValue = realm.getName() + "/" + user.getId();
Sadly, in our configuration, the value returned of by user.getId() is not the same as the value stored in the "sub" claim, thus causing the session management code in login-status-iframe.html, line 53 to clear out any tokens and force the users to re-login the next time it checks the session state (default is 5 second intervals):
var cookie = getCookie();
if (sessionState == cookie) { ... } else { callback("changed"); }
Looking at the LoginStatusIframeEndpoint.preCheck (LoginSatusIframeEndpoint.java, lines 71-93), we've noticed that the implementation does not even make use of the user identity, only the session id.
The workaround, at least temporary, for us was to add the "id" claim containing the user identity internal to keycloak, and modify the keycloak JS adapter code to look for the "id" claim and use its value instead of the value in the "sub" claim when creating the session id, i.e.:
var sessionId;
if (kc.tokenParsed.id) {
sessionId = kc.realm + "/" + kc.tokenParsed.id;
} else {
sessionId = kc.realm + "/" + kc.tokenParsed.sub;
}
Is this a bug, or does it work as intended, i.e. the users should never set the "sub" claim to anything other than the keycloak's user identity? If this is a bug, I can submit a JIRA request and a fix as long as the workaround above seems like an acceptable solution
Any comments are welcome
Regards,
Peter
7 years, 5 months
AdapterTokenStore: automatic refresh token
by Antoine Carton
Hello,
I have implemented an org.keycloak.adapters.AdapterTokenStore, like the
existing ones, for example:
- org.keycloak.adapters.jetty.core.JettyCookieTokenStore (from
keycloak-jetty-core 3.1.0.Final)
- org.keycloak.adapters.jetty.core.JettySessionTokenStore (from
keycloak-jetty-core 3.1.0.Final)
The purpose is that these AdapterTokenStores refresh the current access
token with the refreshToken they have stored, and then update the
org.keycloak.adapters.RefreshableKeycloakSecurityContext (see
refreshExpiredToken() of this context) with a new token.
All of this is triggered thanks to the checkCurrentToken, called in
org.keycloak.adapters.jetty.core.AbstractKeycloakJettyAuthenticator.
The trouble is that the current "Authorization" header of the Request
object is not updated with the new token.
Therefore, even if the security context has a new token, the current
request failed because of the old token that is still in the Authorization
header (the check is done in
BearerTokenRequestAuthenticator.authenticate(HttpFacade exchange)).
Any idea how to solve this issue? Does it mean the request must be done
twice even if the token is refreshed?
Otherwise, the alternative I see is to have a proxy that will be in charge
of refreshing the token by modifying the request header.
Thanks!
7 years, 5 months
Permission related issues in 3.2.0
by Dmitry Telegin
Hi,
After upgrade to 3.2.0, I've noticed the following issues that may all
be permissions-related:
* in 3.2.0, if you create a (non-master) realm, add a user, assign
realm-management.realm-admin client role, click impersonate (or simply
relogin) to access the account page - in the Applications tab you'll
see only Account itself, and neither Security Admin Console nor Admin
CLI like in 3.1.0. This is a bit confusing since the user actually is
able to access admin console and CLI;
* in 3.2.0, if you log in as a master realm admin, create a role in a
non-master realm, turn it into composite and try to add roles to it,
you'll get an exception:
23:12:52,654 ERROR [org.jboss.resteasy.resteasy_jaxrs.i18n] (default
task-12) RESTEASY002005: Failed executing POST
/admin/realms/foobar/roles-by-id/3e38af68-5aef-482c-868e-
461f12e11592/composites: org.keycloak.services.ForbiddenException
at
org.keycloak.services.resources.admin.permissions.RolePermissions.requi
reMapComposite(RolePermissions.java:383) at
org.keycloak.services.resources.admin.RoleResource.addComposites(RoleRe
source.java:70) at
org.keycloak.services.resources.admin.RoleByIdResource.addComposites(Ro
leByIdResource.java:161)
I didn't manage to find a working combination of permissions to solve
this. Anyway, one might expect this to work out of the box, like it
used to in 3.1.0.
Dmitry
7 years, 5 months
saml logout
by Сергей Галюзин
hi all!
i try use Keycloak as IDP for gitlab via SAML protocol.
autentification is work well.
but i can't configure integration with logout service
gillab can redirect user after logout to customizable url
if it redirect to main SAML entry point ( root/realms/{realm}/protocol/saml/)
i see error "invalid request"
if i try type anybody to field "Logout Service POST Binding URL" and
redirect to this url - i see error 404 or blank screen.
In the documentation this service is practically not described.
Is there a standard entry point for logout servise (like standart SSO point
root/realms/{realm}/protocol/saml/clients/{url name}) ?
7 years, 5 months
keycloak saml logout
by Сергей Галюзин
hi all!
i try use Keycloak as IDP for gitlab via SAML protocol.
autentification is work well.
but i can't configure integration with logout service
gillab can redirect user after logout to customizable url
if it redirect to main SAML entry point (
root/realms/{realm}/protocol/saml/) i see error "invalid request"
if i try type anybody to field "Logout Service POST Binding URL" and
redirect to this url - i see error 404 or blank screen.
In the documentation this service is practically not described.
Is there a standard entry point for logout servise (like standart SSO point
root/realms/{realm}/protocol/saml/clients/{url name}) ?
7 years, 5 months
