had to bump surefire memory
by Bill Burke
My build was running really really slow. Bumping the heap and permgen
for surefire seemed to fix the problem. Its probably either the server
starting/stopping so much and not fully cleaning itself up after a stop,
and/or we have a lot of open JAX-RS clients Apache Http Clients that
aren't being closed from our tests, and/or selenium doesn't clean itself
up nicely. Something we might want to look into later.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
8 years, 4 months
cross-realm adminstration part II
by Bill Burke
So, decided on goals are:
* remove and provide alternative for master realm per-realm clients
* Ability to turn any realm into a "master" realm of a set of realms
Maybe we should just wait for role namespaces....I'll work on client
templates instead.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
8 years, 4 months
NoSuchMethodError
by Michael Gerber
Hi,
I am using WildFly 10.0.0.CR4 and Keycloak 1.7.0.CR1.
I received the following error:
2015-12-10 12:26:59,012 ERROR [io.undertow.request] (default task-74) UT005023: Exception handling request to /admin/system-config/login.html: java.lang.NoSuchMethodError: io.undertow.server.Connectors.ungetRequestBytes(Lio/undertow/server/HttpServerExchange;[Lorg/xnio/Pooled;)V
at org.keycloak.adapters.undertow.SavedRequest.tryRestoreRequest(SavedRequest.java:112) [keycloak-undertow-adapter-1.7.0.CR1.jar:1.7.0.CR1]
at org.keycloak.adapters.undertow.ServletSessionTokenStore.restoreRequest(ServletSessionTokenStore.java:119) [keycloak-undertow-adapter-1.7.0.CR1.jar:1.7.0.CR1]
at org.keycloak.adapters.undertow.ServletSessionTokenStore.isCached(ServletSessionTokenStore.java:67) [keycloak-undertow-adapter-1.7.0.CR1.jar:1.7.0.CR1]
at org.keycloak.adapters.RequestAuthenticator.authenticate(RequestAuthenticator.java:88) [keycloak-adapter-core-1.7.0.CR1.jar:1.7.0.CR1]
at org.keycloak.adapters.undertow.AbstractUndertowKeycloakAuthMech.keycloakAuthenticate(AbstractUndertowKeycloakAuthMech.java:110) [keycloak-undertow-adapter-1.7.0.CR1.jar:1.7.0.CR1]
at org.keycloak.adapters.undertow.ServletKeycloakAuthMech.authenticate(ServletKeycloakAuthMech.java:92) [keycloak-undertow-adapter-1.7.0.CR1.jar:1.7.0.CR1]
at io.undertow.security.impl.SecurityContextImpl$AuthAttempter.transition(SecurityContextImpl.java:233) [undertow-core-1.3.3.Final.jar:1.3.3.Final]
at io.undertow.security.impl.SecurityContextImpl$AuthAttempter.transition(SecurityContextImpl.java:250) [undertow-core-1.3.3.Final.jar:1.3.3.Final]
at io.undertow.security.impl.SecurityContextImpl$AuthAttempter.access$100(SecurityContextImpl.java:219) [undertow-core-1.3.3.Final.jar:1.3.3.Final]
at io.undertow.security.impl.SecurityContextImpl.attemptAuthentication(SecurityContextImpl.java:121) [undertow-core-1.3.3.Final.jar:1.3.3.Final]
at io.undertow.security.impl.SecurityContextImpl.authTransition(SecurityContextImpl.java:96) [undertow-core-1.3.3.Final.jar:1.3.3.Final]
at io.undertow.security.impl.SecurityContextImpl.authenticate(SecurityContextImpl.java:89) [undertow-core-1.3.3.Final.jar:1.3.3.Final]
at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:55) [undertow-servlet-1.3.3.Final.jar:1.3.3.Final]
at io.undertow.server.handlers.DisableCacheHandler.handleRequest(DisableCacheHandler.java:33) [undertow-core-1.3.3.Final.jar:1.3.3.Final]
at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.3.3.Final.jar:1.3.3.Final]
at io.undertow.security.handlers.AuthenticationConstraintHandler.handleRequest(AuthenticationConstraintHandler.java:51) [undertow-core-1.3.3.Final.jar:1.3.3.Final]
at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46) [undertow-core-1.3.3.Final.jar:1.3.3.Final]
at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64) [undertow-servlet-1.3.3.Final.jar:1.3.3.Final]
at io.undertow.servlet.handlers.security.ServletSecurityConstraintHandler.handleRequest(ServletSecurityConstraintHandler.java:56) [undertow-servlet-1.3.3.Final.jar:1.3.3.Final]
at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60) [undertow-core-1.3.3.Final.jar:1.3.3.Final]
at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:72) [undertow-servlet-1.3.3.Final.jar:1.3.3.Final]
at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50) [undertow-core-1.3.3.Final.jar:1.3.3.Final]
at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43) [undertow-core-1.3.3.Final.jar:1.3.3.Final]
at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.3.3.Final.jar:1.3.3.Final]
at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.3.3.Final.jar:1.3.3.Final]
at org.keycloak.adapters.undertow.ServletPreAuthActionsHandler.handleRequest(ServletPreAuthActionsHandler.java:69) [keycloak-undertow-adapter-1.7.0.CR1.jar:1.7.0.CR1]
at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.3.3.Final.jar:1.3.3.Final]
at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:284) [undertow-servlet-1.3.3.Final.jar:1.3.3.Final]
at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:263) [undertow-servlet-1.3.3.Final.jar:1.3.3.Final]
at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81) [undertow-servlet-1.3.3.Final.jar:1.3.3.Final]
at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:174) [undertow-servlet-1.3.3.Final.jar:1.3.3.Final]
at io.undertow.server.Connectors.executeRootHandler(Connectors.java:198) [undertow-core-1.3.3.Final.jar:1.3.3.Final]
at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:788) [undertow-core-1.3.3.Final.jar:1.3.3.Final]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_51]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_51]
at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_51]
It looks like the method Connectors.ungetRequestBytes has changed....
Keycloak currently uses undertow-core-1.1.1.Final and Wildfly uses undertow-core.1.3.3.Final.
Should I create a JIRA for that or is that already known?
Michael
8 years, 4 months
cross-realm administration
by Bill Burke
Continuing our hangout from yesterday...
The primary goal, IMO is to 1) clean up the master realm realm clients
2) remove the master realm requirement for cross-realm impersonation 3)
give possibility to remove the master realm
Right now non-master realms trust admins in the master realm. These
"child" realms allow the master realm to decide which users in the
master realm are allowed to access it. I'll call this "cross-realm
administration". We could continue this model, but without role
namespaces you'd have to create realm-clients in each trusted realm.
Another idea is to do something really simple. Realm A decides to trust
Realm B and they "share" admin roles. If user in Realm B has
"view-user" permission, then he also has "view-user" permission. The UI
is simple and there's no need for Realm A and B to know anything else
about each other. This is a simpler version of "cross-realm
administration" which doesn't give you any fine grain per-realm control.
This requires very little UI work which is the big blocker for me.
Building on that idea, which is what I started to implement, is that
Realm A "shares" admin roles still, but only allows certain permissions
for Realm B. Realm A grants admins in Realm B "view user and create client"
If you want to go further with the ability to grant a specific user or
group in another realm admin privileges then it becomes more
complicated. You have a chicken and egg problem first as you'd need a
way to view users and groups in another realm so you can grant
permission to them. I guess it could be you
1. Granting trust ot a realm allows that realm to view your users and
groups. Well, at least query for username/email/attributes
2. UI screens would have to be created specific for managing
users/groups in another realm as you would want to filter what
information gets displayed
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
8 years, 4 months
Keycloak 1.7.0.CR1 Released
by Stian Thorgersen
I'm pleased to announce the release of Keycloak 1.7.0.CR1. Recently we've
gone straight to Final, but we'd like to give everyone a chance to try a
release out first. Unless there are major issues reported we will release
Final next week.
As usual we've been far from idle and have a number of highlights in this
release, including:
- *Groups* - users can belong to one or more groups and inherit role
mappings and attributes from the group.
- *First Broker Login Flow* - we've introduced a number of improvements
to first login with identity brokers as well as the ability to customize
the flow used.
- *Client Registration* - clients can now dynamically register
themselves with a Keycloak server. This supports Keycloak client
representations, OpenID Connect Dynamic Client Registration and SAML Entity
Descriptors. Client registration are simple REST endpoints, there's also a
Java library and a CLI is coming soon.
- *OpenID Connect Implicit and Hybrid flows* - we've added support for
the Implicit and Hybrid flows. It's also possible to select what flows are
available for a specific client.
- *Add User script* - as a first step to not having a default admin user
we've added a script that allows creating an initial admin account.
- *Cache fixes* - there's a number of fixes related to caching, which
should improve performance especially in clusters.
- *Email Sender SPI* - previously we had one SPI that created email
content from FreeMarker and also sent emails. We've now split this into two
separate SPIs.
- *SAML SP WildFly subsystem* - there's now a WildFly subsystem for the
SAML SP adapter, which makes it easier to use the SAML SP adapter on
WildFly.
- *WildFly 10 adapter support* - the WildFly adapter, including adapter
subsystem, now supports WildFly 10.
For the full list of issues resolved check out JIRA
<https://issues.jboss.org/issues/?jql=project%20%3D%20keycloak%20and%20fix...>
and
to download the release go to the Keycloak homepage
<http://keycloak.org/downloads>.
8 years, 4 months
inter-realm trust model
by Bill Burke
To establish trust between realms I was thinking about a simple table:
realm|trusted-realm|role
Here's some example records:
test-realm|master|manage-clients
test-realm|master|view-users
means
"test-realm" trusts the "master" realm, but they can only
"manage-clients" and "view-users"
The "role" column would just be the name of the realm, not an id and
would reference the "realm-management" client roles (which will be moved
to security-admin-console client).
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
8 years, 4 months
getting rid of master realm
by Bill Burke
I'm thinking that getting rid of the master realm would allow us to
clean up some things we've wanted to clean up for some time. Here's what
I have in mind.
* There is no master realm
* Realm admins can create other realms
* You can set up trust from one realm to another. Just realms that are
stored in that keycloak deployment. No remote stuff.
* To keep it simple, the admin console in the realm would just have a
"Trust" tab somewhere with a list of realms you trust or want to trust.
When you trust a realm, any users that have admin roles in that
trusted realm will have the same roles within the current realm.
* When users log into the admin console, the list of realms that trust
the logged into realm will be listed as realms the user can manage.
* When a new realm is created, the new realm automatically trust the
realm that created it.
* If there is a trust relationship impersonation will work no matter
what realm it is
* We can remove the realm-management client in each realm and just merge
the roles into security-admin-console.
* For migration, we just import the master realm and set up trust
between the master realm and every other realm.
Once we do all this we can now look at satisfying the
cannot-have-a-default-password requirement passed down by the security
audit team. We can have a welcome page that just asks "To create your
first realm, click here".
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
8 years, 4 months
Disabling SAML client
by Michal Hajas
Hi,
I am wondering what should happen in second scenario below.
I have working SAML client and try to disable client in admin console in next two scenarios:
First:
1. Disable client in admin console
2. Try to access client URL -> I am getting "Login requester not enabled". I think this behavior is correct.
Second:
1. Login to client
2. Disable client in admin console
3. Nothing happens, secured resource is still available, even after some time.
Is it correct? Shouldn't keycloak forbid to refresh token or somehow restrict accessing secured resource?
Thank you,
Michal Hajas.
8 years, 4 months
