Keycloak WAR inside on an EAR file ?
by Matthias Wessendorf
Hello,
I tried to pull the auth-server.war file into an EAR. Once that is deployed
to the JBoss 7.1.1 (I did not try WildFly), I am getting this error on the
JAX-RS Application initialization:
17:55:00,113 ERROR
[org.apache.catalina.core.ContainerBase.[jboss.web].[default-host].[/auth]]
(MSC service thread 1-14) StandardWrapper.Throwable:
java.lang.RuntimeException: Failed to construct public
org.keycloak.server.KeycloakServerApplication(javax.servlet.ServletContext)
throws java.io.FileNotFoundException
at org.jboss.resteasy.core.ConstructorInjectorImpl.construct(ConstructorInjectorImpl.java:144)
[resteasy-jaxrs-2.3.2.Final.jar:]
at org.jboss.resteasy.spi.ResteasyDeployment.createFromInjectorFactory(ResteasyDeployment.java:282)
[resteasy-jaxrs-2.3.2.Final.jar:]
at org.jboss.resteasy.spi.ResteasyDeployment.createApplication(ResteasyDeployment.java:259)
[resteasy-jaxrs-2.3.2.Final.jar:]
at org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.init(ServletContainerDispatcher.java:85)
[resteasy-jaxrs-2.3.2.Final.jar:]
at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.init(HttpServletDispatcher.java:36)
[resteasy-jaxrs-2.3.2.Final.jar:]
at org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:1202)
[jbossweb-7.0.13.Final.jar:]
at org.apache.catalina.core.StandardWrapper.load(StandardWrapper.java:1102)
[jbossweb-7.0.13.Final.jar:]
at org.apache.catalina.core.StandardContext.loadOnStartup(StandardContext.java:3655)
[jbossweb-7.0.13.Final.jar:]
at org.apache.catalina.core.StandardContext.start(StandardContext.java:3873)
[jbossweb-7.0.13.Final.jar:]
at org.jboss.as.web.deployment.WebDeploymentService.start(WebDeploymentService.java:90)
[jboss-as-web-7.1.1.Final.jar:7.1.1.Final]
at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1811)
at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1746)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
[rt.jar:1.7.0_09]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
[rt.jar:1.7.0_09]
at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_09]
Caused by: org.jboss.resteasy.spi.LoggableFailure: Unable to find
contextual data of type: javax.servlet.ServletContext
at org.jboss.resteasy.core.ContextParameterInjector$GenericDelegatingProxy.invoke(ContextParameterInjector.java:53)
[resteasy-jaxrs-2.3.2.Final.jar:]
at $Proxy39.getContextPath(Unknown Source) at
org.keycloak.services.resources.KeycloakApplication.<init>(KeycloakApplication.java:37)
[keycloak-services-1.0-alpha-4.jar:]
at org.keycloak.server.KeycloakServerApplication.<init>(KeycloakServerApplication.java:41)
[classes:]
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
Method) [rt.jar:1.7.0_09]
at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57)
[rt.jar:1.7.0_09]
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
[rt.jar:1.7.0_09]
at java.lang.reflect.Constructor.newInstance(Constructor.java:525)
[rt.jar:1.7.0_09]
at org.jboss.resteasy.core.ConstructorInjectorImpl.construct(ConstructorInjectorImpl.java:132)
[resteasy-jaxrs-2.3.2.Final.jar:]
... 14 more
17:55:00,123 ERROR
[org.apache.catalina.core.ContainerBase.[jboss.web].[default-host].[/auth]]
(MSC service thread 1-14) Servlet /auth threw load() exception:
org.jboss.resteasy.spi.LoggableFailure: Unable to find contextual data
of type: javax.servlet.ServletContext
at org.jboss.resteasy.core.ContextParameterInjector$GenericDelegatingProxy.invoke(ContextParameterInjector.java:53)
[resteasy-jaxrs-2.3.2.Final.jar:]
at $Proxy39.getContextPath(Unknown Source) at
org.keycloak.services.resources.KeycloakApplication.<init>(KeycloakApplication.java:37)
[keycloak-services-1.0-alpha-4.jar:]
at org.keycloak.server.KeycloakServerApplication.<init>(KeycloakServerApplication.java:41)
[classes:]
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
Method) [rt.jar:1.7.0_09]
at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57)
[rt.jar:1.7.0_09]
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
[rt.jar:1.7.0_09]
at java.lang.reflect.Constructor.newInstance(Constructor.java:525)
[rt.jar:1.7.0_09]
at org.jboss.resteasy.core.ConstructorInjectorImpl.construct(ConstructorInjectorImpl.java:132)
[resteasy-jaxrs-2.3.2.Final.jar:]
at org.jboss.resteasy.spi.ResteasyDeployment.createFromInjectorFactory(ResteasyDeployment.java:282)
[resteasy-jaxrs-2.3.2.Final.jar:]
at org.jboss.resteasy.spi.ResteasyDeployment.createApplication(ResteasyDeployment.java:259)
[resteasy-jaxrs-2.3.2.Final.jar:]
at org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.init(ServletContainerDispatcher.java:85)
[resteasy-jaxrs-2.3.2.Final.jar:]
at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.init(HttpServletDispatcher.java:36)
[resteasy-jaxrs-2.3.2.Final.jar:]
at org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:1202)
[jbossweb-7.0.13.Final.jar:]
at org.apache.catalina.core.StandardWrapper.load(StandardWrapper.java:1102)
[jbossweb-7.0.13.Final.jar:]
at org.apache.catalina.core.StandardContext.loadOnStartup(StandardContext.java:3655)
[jbossweb-7.0.13.Final.jar:]
at org.apache.catalina.core.StandardContext.start(StandardContext.java:3873)
[jbossweb-7.0.13.Final.jar:]
at org.jboss.as.web.deployment.WebDeploymentService.start(WebDeploymentService.java:90)
[jboss-as-web-7.1.1.Final.jar:7.1.1.Final]
at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1811)
at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1746)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
[rt.jar:1.7.0_09]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
[rt.jar:1.7.0_09]
at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_09]
I wonder if there is anything wrong here, w/ the
jboss-deployment-structure.xml file of the actual WAR file from Keycloak?
--
Matthias Wessendorf
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
8 years, 8 months
Update on audit
by Stian Thorgersen
Work completed:
* Added AuditListener SPI (https://github.com/keycloak/keycloak/blob/master/audit/api/src/main/java/...)
* Added JBoss Logging AuditListener implementation (this is used by default for all realms atm)
* Added audit events for token service, social, account management and required actions
Remaining work:
* Add a AuditProvider SPI (extends AuditListener to add querying for events)
* Add implementations of AuditProvider - atm I'm thinking a JPA and Mongo providers as a sensible starting point (with an option to remove events after N days). I've considered parsing logs, but I'm pretty sure that won't work for account management (and will also be quite limiting for admin console)
* Allow configuring audit listeners/providers for a realm through admin console
* View events associated with user in account management
* View all events in admin console
* Audit events for admin
Related:
* AuditListener/Provider could be useful for brute force protection
* AuditListener could be used to allow applications to listen for user creation/update/deletion to sync user details into a separate database / maybe we could add a UserListener interface?
8 years, 8 months
Do we need a RDMS/Mongo backed Audit Log?
by Bill Burke
If you look at things like fail2ban, they parse logs in order to make
decisions.
Do we really need our Audit Log to be backed by an actual database?
Yes, we need an "Event" or "Action" log that a user and/or admin sees of
things they need to be aware of. But logging of successful logins,
login failures, and the like should be pushed to a rolling log file, no?
Then Keycloak could hook into things like fail2ban.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
8 years, 8 months
Idea for brute force protection
by Stian Thorgersen
While working on audit an idea popped into my head. What about if after N failed attempts we disable the users account, then send an email to the user saying something like:
------------
We have recently detected a number of failed login attempts to your account:
* 28/03/2014 14:27 from 80.129.51.201
* 28/03/2014 14:26 from 80.129.51.201
* 28/03/2014 14:25 from 80.129.51.201
* 28/03/2014 14:24 from 80.129.51.201
To prevent unauthorized access to your account it has been disabled. To enable your account click on the following link (or contact an admin):
http://localhost:8080/auth/rest/realms/tokens/auth/request/login-actions/...
------------
We could have a drop-down under realm settings to select the 'brute force' protection policy, from one of:
* Sleep - sleep for N seconds on login (increased for each attempt)
* Temporary disable - disable login for the account until some time in the future (may also send an email to user to indicate this)
* User can re-enable - the proposal from above
* Admin can re-enable - similar to above, but the email is sent to an admin instead of the user
8 years, 8 months
Features whishlist
by Adrian Mitev
Hi guys! I'm very interested in Keycloak and would like to share with you
some ideas that come from user requirements I currently have or had in the
past that you may find useful to add in Keycloak.
* Automatically revoke access to user account after a (configurable) number
of invalid sign-on passwords until the system administrator has unlocked
the account or automatically after an administrator-defined interval - I
know that with such feature an attacker could lock user accounts by simply
knowing usernames/emails. However I have a case of an Intranet application
that is accessible only inside the company and could trace such attackers
by their ip addresses.
* Record and report (i.e. email sending) on failed login attempts outlining
* Force password changes at regular (configurable) intervals or
* Automatically reset the password and send a new one to the user via email
* Can ensure that the new password has not been used before in a number
(configurable) of password changes
* Login using digital signature in a smart card or p12 file
* Security questions for password recovery
Other that I found as issues in other Identity Providers
* Support many accounts (~10K) within a reasonable amount of time
* When providing an authentication client (maven dependency) add only the
needed set of dependencies. I know this sounds silly but I have experience
with a client library provided by the Identity Provider that had a compile
dependency to apache ant...
8 years, 8 months
LDAP test still failing
by Bill Burke
java.lang.AssertionError: expected:<SUCCESS> but was:<INVALID_CREDENTIALS>
at org.junit.Assert.fail(Assert.java:88)
at org.junit.Assert.failNotEquals(Assert.java:743)
at org.junit.Assert.assertEquals(Assert.java:118)
at org.junit.Assert.assertEquals(Assert.java:144)
at
org.keycloak.model.test.AuthProvidersLDAPTest.testLdapAuthentication(AuthProvidersLDAPTest.java:86)
Can you please fix it? Otherwise I'm just going to comment it out.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
8 years, 8 months
