WildFly 9 adapter support
by Leonardo Loch Zanivan
I'm trying to deploy a keycloak secured application in WildFly 9.0.0-Beta2,
but I got a NPE.
It's working fine with WildFly 8.1.0-Final.
17:41:19,764 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-2)
MSC000001: Failed to start service
jboss.deployment.unit."app.war".POST_MODULE:
org.jboss.msc.service.StartException in service
jboss.deployment.unit."app.war".POST_MODULE: WFLYSRV0153: Failed to process
phase POST_MODULE of deployment "app.war"
at
org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:163)
at
org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948)
at
org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
*Caused by: java.lang.NullPointerException at
org.keycloak.subsystem.extension.KeycloakAdapterConfigDeploymentProcessor.deploy(KeycloakAdapterConfigDeploymentProcessor.java:73)*
at
org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:156)
... 5 more
17:41:19,770 ERROR [org.jboss.as.controller.management-operation]
(management-handler-thread - 1) WFLYCTL0013: Operation ("deploy") failed -
address: ([("deployment" => "app.war")]) - failure description:
{"WFLYCTL0080: Failed services" =>
{"jboss.deployment.unit.\"app.war\".POST_MODULE" =>
"org.jboss.msc.service.StartException in service
jboss.deployment.unit.\"app.war\".POST_MODULE: WFLYSRV0153: Failed to
process phase POST_MODULE of deployment \"app.war\"
Caused by: java.lang.NullPointerException"}}
17:41:19,771 ERROR [org.jboss.as.server] (management-handler-thread - 1)
WFLYSRV0021: Deploy of deployment "app.war" was rolled back with the
following failure message:
{"WFLYCTL0080: Failed services" =>
{"jboss.deployment.unit.\"app.war\".POST_MODULE" =>
"org.jboss.msc.service.StartException in service
jboss.deployment.unit.\"app.war\".POST_MODULE: WFLYSRV0153: Failed to
process phase POST_MODULE of deployment \"app.war\"
Caused by: java.lang.NullPointerException"}}
10 years, 10 months
logging of errors
by Bill Burke
While we do create appropriate events when errors happen, we do not do
any logging. Should we be logging too when errors happen? Many times I
have no idea what went wrong and have to guess how I might have
configured keycloak incorrectly.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
10 years, 10 months
Re: [keycloak-dev] application session state update
by Marek Posolda
On 31.3.2015 10:16, Sebastian Rose wrote:
>> That's actually related to the application session (kind of HttpSession
>> ID in web application secured by keycloak). We can add support for
>> changing application_session_state in refreshToken endpoint instead of
>> introducing separate endpoint. Will it be sufficient for your usecase?
>> Marek
> As Bastian already said...
> Thanks for your response. Yes, i think this would work for us.
>
> I will create a JIRA for that and contribute a change via pull request (if this is fine for you)?
yep, thanks. There is some refactoring in latest master, you would need
to look at TokenEndpoint.buildRefreshToken now (TokenEndpoint is new
class, which didn't exist in 1.1.0.Final)
Marek
>
> Best regards,
> Sebastian
10 years, 10 months
Client getting 405 response for POST API using stateless adapter
by Bappaditya Gorai (bgorai)
Hi Team,
We are facing following issue in Keycloak 1.1.0_Final release. I am using stateless adapter configuration i.e tokenstore is cookie.
I have an API endpoint which support POST method. While accessing this API client is receiving 405 (Method not allowed) response. Same works fine if adapter is *not* stateless.
>From my understanding looks like 302 response of CODE_TO_TOKEN is causing the Client to access the Resource Endpoint as GET method which is not allowed in my case( My API endpoint only supports POST).
Do you have any fix for this?
Thanks
Bappaditya Gorai
10 years, 10 months
application session state update
by Sebastian Rose
Hi everyone,
The endpoint /auth/realms/<realm>/protocol/openid-connect/access/codes has a parameter for the session id of a secured application (adapters use it): application_session_state. The Endpoint /auth/realms/<realm>/protocol/openid-connect/refresh has not. At least this is what i saw within the code. Sorry, if it's there.
We have integrated our own application a la adapter, using these two url's and it's working fine. Our application completes the login via the first endpoint and changes it's session id after the successful login. This means when a logout event is send to our application, the old session id is used.
So i'm asking if it makes sense to you to have the same parameter for the refresh-url to cover our requirement or to integrate an application_session_state update endpoint to add/delete/update additional/new session id's.
Best Regrads
Sebastian
10 years, 10 months
Application clustering Issue with Keycloak 1.1.0_Final
by Lakshmi Narayana VADALI (lvadali)
Hi,
We are using keycloak 1.1.0_Final. We are trying Application clustering using jboss (domain mode). We Tested clustering setup (with cluster-demo application provided by jboss) which is working. But With Latest keycloak-adapter looks like keycloak-sessions are not replicated. We are always redirected to Keycloak when the request lands new node of cluster.
We are able to make our setup work if we use cookie store, But we wanted to use Session store rather than cookie store.
When we bringup our nodes we are able to receive below logs
INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (Incoming-10,shared=udp)
ISPN000094: Received new cluster view: [node1/web|1] (2) [node1/web, node2/web]
Thanks,
Lakshmi Narayana V
10 years, 10 months
REST API documentation
by Stian Thorgersen
Currently we're generating the REST API documentation automatically. There's a few issues with that approach:
* Dynamic endpoints are not included (for example openid-connect and saml endpoints are missing)
* No categories - we should split docs into admin, openid-connect, saml, etc.
* Includes private endpoints - for example required actions and account management are included even though they are not intended for public use
* JSON objects not defined - a lot of REST APIs include examples on how to use, including details on the JSON consumed/produced
Is there a way to solve this with the current approach or would it be better to manually create the documentations?
10 years, 10 months
1.2.0.Beta1 release on Thursday (2nd April)
by Stian Thorgersen
I want 1.2.0.Beta1 released on Thursday 2nd April. We need a couple more days to finish of the last tasks and do some testing and 1st April didn't seam like a good release date!
Is there any remaining issues outstanding that are not in JIRA?
I'd like to request that everyone spends a bit of time today and Monday to do some testing!
10 years, 10 months
can't figure this out
by Bill Burke
I'm going crazy... I'm testing facebook login with the admin console as
the test app.
1. Facebook auth succeeds
2. Redirect back to admin console
3. For some reason admin console doesn't like the redirect URL and does
a redirect back to keycloak login with a fragment of #_=_
4. I'm already logged in, so redirect back
5. Success, but the fragment is #_=_
Login works for github though...I'm freakin stumped. The initial
redirect back to the admin console is the same exact redirect uri for
both github and facebook.
Has anybody seen this before?
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
10 years, 10 months
