Keycloak 3.3.0 fails Google Social Registration with NPE
by Niels Bertram
I unzipped Keycloak 3.3.0.Final and configured a localhost:8080 instance
realm "play" to use Google Identity Provider for sozial. Navigating to
http://localhost:8080/auth/realms/play/account will get me to the login
page as expected, then I click on the Google logo and it takes me to google
login. Login is all good but then I get back to the Keycloak server and I
see this stack trace in the web browser and logs.
Anynone seen this before? I got exact setup behind a proper DNS with SSL
and it works fine. In the "Play" realm I configured Require SSL to none and
cant really think of any other thing that could cause this. Anyone seen
this error or has any suggestions for configuration?
14:47:05,845 ERROR [io.undertow.request] (default task-14) UT005023:
Exception handling request to
/auth/realms/play/login-actions/first-broker-login:
org.jboss.resteasy.spi.UnhandledException: java.lang.RuntimeException: No
ident
ifier provider for identity.
at
org.jboss.resteasy.core.ExceptionHandler.handleApplicationException(ExceptionHandler.java:78)
at
org.jboss.resteasy.core.ExceptionHandler.handleException(ExceptionHandler.java:222)
at
org.jboss.resteasy.core.SynchronousDispatcher.writeException(SynchronousDispatcher.java:179)
at
org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:422)
at
org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:213)
at
org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:228)
at
org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:56)
at
org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:51)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
at
io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85)
at
io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:129)
at
org.keycloak.services.filters.KeycloakSessionServletFilter.doFilter(KeycloakSessionServletFilter.java:90)
at
io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:61)
at
io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131)
at
io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:84)
at
io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62)
at
io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)
at
org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
at
io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at
io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131)
at
io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57)
at
io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at
io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
at
io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
at
io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60)
at
io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77)
at
io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50)
at
io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43)
at
io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at
org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
at
io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at
org.wildfly.extension.undertow.deployment.GlobalRequestControllerHandler.handleRequest(GlobalRequestControllerHandler.java:68)
at
io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at
io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:292)
at
io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:81)
at
io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:138)
at
io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:135)
at
io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48)
at
io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43)
at
org.wildfly.extension.undertow.security.SecurityContextThreadSetupAction.lambda$create$0(SecurityContextThreadSetupAction.java:105)
at
org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1508)
at
org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1508)
at
org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1508)
at
org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1508)
at
io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:272)
at
io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
at
io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:104)
at
io.undertow.server.Connectors.executeRootHandler(Connectors.java:326)
at
io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:812)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
Caused by: java.lang.RuntimeException: No identifier provider for identity.
at
org.keycloak.broker.provider.BrokeredIdentityContext.<init>(BrokeredIdentityContext.java:53)
at
org.keycloak.authentication.authenticators.broker.util.SerializedBrokeredIdentityContext.deserialize(SerializedBrokeredIdentityContext.java:250)
at
org.keycloak.services.resources.LoginActionsService.brokerLoginFlow(LoginActionsService.java:697)
at
org.keycloak.services.resources.LoginActionsService.firstBrokerLoginGet(LoginActionsService.java:650)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at
org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:140)
at
org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTarget(ResourceMethodInvoker.java:295)
at
org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:249)
at
org.jboss.resteasy.core.ResourceLocatorInvoker.invokeOnTargetObject(ResourceLocatorInvoker.java:138)
at
org.jboss.resteasy.core.ResourceLocatorInvoker.invoke(ResourceLocatorInvoker.java:101)
at
org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:406)
... 48 more
7 years, 2 months
Fwd: Authz with nodejs
by Corentin Dupont
Hi guys,
I created a REST API that I would like to protect with keycloak.
However, I don't find any example/tutorial on Internet that suits.
At the moment I use keycloak-nodejs-connect: https://github.com/keycloak/ke
ycloak-nodejs-connect/blob/master/example/index.js
This is the basic example given:
var Keycloak = require('keycloak-connect');
var express = require('express');
var session = require('express-session');
var app = express();
var server = app.listen(3000, function () {});
var memoryStore = new session.MemoryStore();
app.use(session({
secret: 'mySecret',
resave: false,
saveUninitialized: true,
store: memoryStore,
}));
var keycloak = new Keycloak({
store: memoryStore
});
app.use(keycloak.middleware({
logout: '/logout',
admin: '/'
}));
app.get('/login', keycloak.protect(), function (req, res) {
res.render('index', {
result: JSON.stringify(JSON.parse(req.session['keycloak-token']), null,
4),
event: '1. Authentication\n2. Login'
});
});
But that doesn't corresponds to my need: in a REST API I have no login or
logout and no memory.
I think the user should always make requests with a bearer token. Based on
that token I can identify the user and get his roles.
Then I could use keycloak.protect('realm:myendpoint') to protect each of my
endpoints. If the user have got that role, he is authorized.
Did I understood correctly the flow?
Is there some example or REST API with authz, using nodeJS?
Thanks a lot!!!
Corentin
7 years, 2 months
Use RestAPI to add roles to groups
by O'Callaghan, John
Hi all
A similar question to before. Am trying to use the rest api to add existing access roles to an existing group.
I have tried to use:
PUT /auth/admin/realms/REALM_NAME/groups/GROUP_ID
With data {'realmRoles': [LIST_OF_ROLES], 'id': gid}
Am getting a 204 back from PUT but when I look in the webui I am not seeing the assigned roles table getting updated for the group.
This is similar to a previous question I had (thanks again Marko for the response) and for fun I did try :
PUT /auth/admin/realms/REALM_ID/groups/GROUP_ID/roles/ROLE_ID
With data {'roleId': ROLE_ID, 'id': GROUP_ID, ‘realm’: REALM_NAME}
But that gave a 404.
Anyone else had this problem? Any help would be much appreciated!
Thanks
John
________________________________
This message is for the designated recipient only and may contain privileged, proprietary, or otherwise confidential information. If you have received it in error, please notify the sender immediately and delete the original. Any other use of the e-mail by you is prohibited. Where allowed by local law, electronic communications with Accenture and its affiliates, including e-mail and instant messaging (including content), may be scanned by our systems for the purposes of information security and assessment of internal compliance with Accenture policy.
______________________________________________________________________________________
www.accenture.com
7 years, 2 months
Keycloak SAML IDP configuration problems
by Drew Weirshousky
I am having a problem setting up Okta as an IDP with keycloak as the SP using SAML. We are using keycloak 3.2.1.
What we want:
We want to prepopulate the users from Okta in keycloak (only a handful of users are involved). So that when a user comes from Okta to our application no registration info has to be entered or confirmed. The user will be authenticated with Okta, click on the application link. Keycloak will handle the SAML authentication and then redirect the user to our application.
What I have so far:
I am initiating login to the application from Okta. When the user comes from Okta they are prompted to update account information. Then a message appears stating that the account already exists, click add to existing account. The user receives the verify email and confirms linking. Then the user goes back to the browser window and continues and is redirected to a page that doesn't exist.
Link from SP:
https://myHost/auth/realms/myRealm/login-actions/first-broker-login?code=...
Link it redirects to:
https://myHost/auth/realms/myRealm/broker/null
The user is linked to the identity provider and a session is created. At this point I am starting to think that we shouldn't use this version of Keycloak and wondering if this is a bug or configuration issue.
Any help would be appreciated.
Thanks
Drew
7 years, 2 months
Re: [keycloak-user] Adding users to groups using restapi
by O'Callaghan, John
Hi Marko
That worked perfectly. Thanks for the help!
John
________________________________
This message is for the designated recipient only and may contain privileged, proprietary, or otherwise confidential information. If you have received it in error, please notify the sender immediately and delete the original. Any other use of the e-mail by you is prohibited. Where allowed by local law, electronic communications with Accenture and its affiliates, including e-mail and instant messaging (including content), may be scanned by our systems for the purposes of information security and assessment of internal compliance with Accenture policy.
______________________________________________________________________________________
www.accenture.com
7 years, 2 months
Automatically disable inactive users
by James Rowe
Hi all,
is there a way in Keycloak to automatically disable a users account after a configurable period of inactivity? For example, if a user has been inactive (e.g. not authenticated) for 60 days then his account is automatically disabled meaning he can no longer login.
If it is not possible then i plan to add a feature request. I don't see anything like this in the existing JIRA requests.
Thanks,
Jim.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you are not the intended recipient, please note that any review, dissemination, disclosure, alteration, printing, circulation, retention or transmission of this e-mail and/or any file or attachment transmitted with it, is prohibited and may be unlawful. If you have received this e-mail or any file or attachment transmitted with it in error please notify postmaster(a)openet.com. Although Openet has taken reasonable precautions to ensure no viruses are present in this email, we cannot accept responsibility for any loss or damage arising from the use of this email or attachments.
7 years, 2 months
Adding users to groups using restapi
by O'Callaghan, John
Hi All
Im trying to use the rest api to update an existing user to add them to an existing group.
The url that I am using is /auth/admin/realms/MY_REALM/users/USER_ID
Where MY_REALM is equal to my realm name and
USER_ID is equal to an existing users id.
I am sending a json doc in the PUT body and in here I have { “groups”: [“admin”], “enabled”: True }
But when I look at the users info using the WebUI I am not seeing the admin group listed in their “Group Membership” table. I do see it listed in their “Available Groups” table.
I do see that the users “enabled” flag is going from False to True after the PUT so I believe the permission to update the user is correct. But shouldn’t I see the admin group added to the Group Membership table too?
Has anyone come across this problem?
Any help would be really appreciated.
Thanks
John
________________________________
This message is for the designated recipient only and may contain privileged, proprietary, or otherwise confidential information. If you have received it in error, please notify the sender immediately and delete the original. Any other use of the e-mail by you is prohibited. Where allowed by local law, electronic communications with Accenture and its affiliates, including e-mail and instant messaging (including content), may be scanned by our systems for the purposes of information security and assessment of internal compliance with Accenture policy.
______________________________________________________________________________________
www.accenture.com
7 years, 2 months
populating phone number in IDToken
by Sud Ramasamy
Hi Keycloak team,
We were wondering if and how the phone number property in IDToken is populated. We are using OIDC between the client and Keycloak we came across the org.keycloak.protocol.oidc.OIDCLoginProtocolFactory.java class which seems to be responsible for populating some of the properties of IDToken but phone number isn’t one of them.
Regards
-sud
7 years, 2 months
Issue with not enabling sticky session
by Narendra Kadali
Hello All,
We configured an external SAML based identity provider in a realm and. When user coming back to Keycloak after successful authentication at external IdP Keycloak giving either "Page expired" or "Not found serialized context in authenticationSession " error.
The process of reproducing the issue is as follows:
1. Access the corresponding realm login page and then click on the identity provider link to login using external IdP.
2. This will take us to the external identity provider. After successful authentication at external IdP, the user will be redirected back to Keycloak instance with a valid SAMLResponse.
3. Then there might be a chance that instead of either showing first-broker-login flow or profile page you might be presented with 'page expired' error or 'Not found serialized context in authenticationSession' error.
Some information about my environment:
1. Three Keycloak instances running in a standalone mode. All of them connected to common DB and external Infinispan cluster. We are running Keycloak 3.2.1.Final
2. Three Infinispan instances are deployed as a single cluster. Our Keycloakc instances connected to this external Infinispan cluster.
3. We don't have any session stickiness enabled at the load balancer
1. Below is the configuration we are using for autehtnicationSessions cache in standalone.xml file.
<local-cache name="authenticationSessions">
<remote-store cache="authenticationSessions" remote-servers="remote-cache" fetch-state="false" passivation="false" preload="false" purge="false" shared="true">
<property name="rawValues">
true
</property>
<property name="marshaller">
org.keycloak.cluster.infinispan.KeycloakHotRodMarshallerFactory
</property>
</remote-store>
</local-cache>
Some findings on this issue:
1. Since session stickiness is not there the first time when login page rendered it can go to Keycloak node 1 and when user come back to Keycloak with valid SMAL Response request can be forwarded to Keycloak node2. So requests can be spread across all Keycloak nodes.
2. The error log observed for 'Not found serialized context in authenticationSession' message is: ERROR [org.keycloak.services] (default task-17) KC-SERVICES0068: Not found serialized context in clientSession under note 'BROKERED_CONTEXT'
3. If we run only one single Keycloak node, we are not seeing this error.
Any of you seen a similar issue?
Thanks!
7 years, 2 months
