Notes on KEYCLOAK-795: Move Auth Server into KC subsystem
by Stan Silvert
I've sent a PR for this:
https://github.com/keycloak/keycloak/pull/811
It's a pretty big change in the way the Auth Server is started when the
KeyCloak subsystem is used. The WAR is no longer dropped into the
standalone/deployments directory. This is especially helpful for
domain deployments, but it makes standalone cleaner as well. It will
also be important for Feature Pack installation.
The main difference you will see right away with this PR is that the
appliance dist now uses the subsystem to launch the Auth Server.
Here are some notes about how everything turned out. Next, I'll update
the documentation if there is no major rework that needs to be done
after the PR is reviewed.
* The WAR for the auth server now lives in
modules/.../keycloak-wildfly-subsystem/main/auth-server. By
default, it is unexploded. If you want it to be exploded you can
unzip it into that same directory and set the "auth-server-exploded"
property in module.xml.
* A new Auth Server is declared in standalone.xml/domain.xml. You can
have more than one Auth Server in the same WildFly instance.
* <subsystem xmlns="urn:jboss:domain:keycloak:1.0">
<auth-server name="main-auth-server">
<enabled>true</enabled>
<web-context>auth</web-context>
</auth-server>
* The "enabled" attribute can be toggled at runtime to make the auth
server undeploy/redeploy.
* If you have more than one auth-server, the web-context must be unique.
* In a domain environment, all specified Auth Server deployments are
propagated to all servers using that profile. The same is true for
overlays uploaded through the new CLI operations.
* There are two new CLI operations that act on an auth-server. They
are "add-provider" and "update-server-config". Currently, you can
only execute these operations in the latest version of CLI GUI. We
should discuss if we need to add support in plain CLI. The long
term goal would be to add this functionality to the Keycloak Admin
Console.
* "add-provider" adds a provider jar to an auth-server
* "update-server-config" overlays the keycloak-server.json for an
auth-server.
* If a keycloak-server.json file is found in standalone/configuration
directory, all auth-server instances will still use it regardless of
any update-server-config operations.
* EAP6 does not yet support all this. We should discuss whether or
not this functionality should be backported.
10 years, 12 months
KC Auth Server Subsystem questions
by Bill Burke
* What are the benefits of it. Specifically. I'll need to state this
in the release blog.
* Where is the documentation for it? Benefits, how to configure,
manage? How to add new providers? Modify keycloak-server.json, etc...
This can't be released or brought into the appliance until it is
documented thoroughly.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
10 years, 12 months
Create Principal instance with username instead?
by Bill Burke
Right no UserPrincipal is created in the adapters using the user id.
For strictly pure Servlet apps, an ID is pretty ugly. I don't want to
force them to use keycloak code.
So...is it ok to populate the principal name with
accessToken.getPreferredUsername()?
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
10 years, 12 months
Multi tenant review
by Stian Thorgersen
Hi,
I merged the PR into multi-tenant-adapter branch. It looks good, but I've got a few comments/suggestions:
Adapter:
1. Change <name> in integration/adapter-core/pom.xml - can you send this as a separate PR directly to master?
2. With the updates to AdapterDeploymentContext it's always required to pass request, so we can just remove getDeployment and always use resolveDeployment
3. CatalinaSessionTokenStore.checkCurrentToken - can you figure out the realm if the session was serialized? when adapter is clustered we support serializing the session
4. KeycloakAuthenticatorValve.initInternal - just do a warn + unconfigured to make it behave same as if keycloak-server.json is missing, and drop the comment
5. KeycloakServletExtension.handleDeployment - same as above
6. CatalinaCookieTokenStore.checkPrincipalFromCookie - if cookie has different realm I'd say the log should at least be a warn, is this not a significant problem?
7. CatalinaSessionTokenStore.checkCurrentToken - same as above isn't cookie with different realm a pretty big issue?
Docs:
1. Move multi-tenancy documentation into adapters section
Examples:
1. Remove multi-tenant example (it's just to complex for us to maintain it)
2. Rename simple-multi-tenant example to multi-tenant
3. In simple-multi-tenant/README.MD can you remove instructions on starting server (we have separate instructions for that, and assume a user can do it by the time they're looking at examples), also remove comments about docker (we need to focus examples and not confuse users by introducing other concepts). Also, why does it instruct the user to start on 8180?
4. Remove/improve "hackish" comment in PathBasedKeycloakConfigResolver
5. PathBasedKeycloakConfigResolver loads adapter settings from json on every request - this will be relatively expensive
10 years, 12 months
BRMS Good news/ Bad news
by Bill Burke
Looked into security JBoss BRMS 6.0.2 with Keycloak.
Good news is that I can secure brms console login just by installing the
keycloak adapter and turning it on in the WAR of BRMS. Bad news is that
keycloak initiated logout doesn't work that great. It just disables the
console.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
11 years
ClientSessions may never be removed
by Stian Thorgersen
As new client sessions are initially detached there's a chance they are never linked to a user session (for example user closes browser when login page is displayed). These client sessions are never removed. I reckon we need to have a similar garbage collection of client sessions as we do for user sessions.
https://issues.jboss.org/browse/KEYCLOAK-788
11 years
tomcat 7 adapter
by Bill Burke
I added the tomcat 7 adapter to the distro as well as some docbook docs
for it. This is shaping up to a really nice release!
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
11 years
