Design of Auth Server startup from subsystem
by Stan Silvert
After lots of experimentation, I think I've finally settled on a
design. Though this whole effort has taken longer than expected, I
don't think the coding will take that long since I've got experimental
code that does the hard stuff. I just need to rearrange it and clean it up.
Here is the design. I appreciate your feedback.
_*Design Goals*_
* Support auth-server running in a WildFly domain.
* Eliminate deployment from /deployments directory to make it a proper
service instead of an ordinary app.
* Eliminate need to explode or crack open auth-server.war. Keep it
intact so it doesn't need to be hacked up.
* Load user-provided overlays for keycloak-server.json, SPI jars, and
theme jars.
* Allow uploading overlays from CLI.
* Allow more than one auth-server in a WildFly instance.
* Compatibility with EAP6, EAP7, WildFly8, and WildFly9.
_*Management Model*_
The Keycloak subsystem introduces a new resource called, "auth-server".
You can define more than one auth-server if you like. The simplest form
just looks like this:
<subsystem xmlns="urn:jboss:domain:keycloak:1.1">
<auth-server name="my-auth-server-name"/>
</subsystem xmlns="urn:jboss:domain:keycloak:1.1">
On startup, this deploys my-auth-server-name.war with web context "auth".
There are two optional attributes under <auth-server>. They are
"enabled" and "web-context". Here is an example:
<subsystem xmlns="urn:jboss:domain:keycloak:1.1">
<auth-server name="auth-server1"/>
<auth-server name="auth-server2">
<enabled>true<enabled/>
<web-context>auth2</web-context>
</auth-server>
</subsystem xmlns="urn:jboss:domain:keycloak:1.1">
In a domain environment, there is an additional resource. You assign
the auth server to one or more server groups:
<subsystem xmlns="urn:jboss:domain:keycloak:1.1">
<auth-server name="my-auth-server-name">
<server-group name="group1"/>
<server-group name="group2"/>
</auth-server>
</subsystem xmlns="urn:jboss:domain:keycloak:1.1">
_*Loading the Auth Server*_
The auth-server.war will be loaded from the Keycloak subsystem module.
This is just a convenient place to put it. We could actually load it
from anywhere. Note that it no longer needs to be exploded.
_*Using Overalys*_
The Keycloak subsystem can overlay or add to the auth-server.war.
Overlays do not touch the original content of auth-server.war.
To define an overaly, you just drop your files in the proper directories
on the file system. The layout is:
/overlays/<auth-server-name>/server-config/
/overlays/<auth-server-name>/account-spi/
/overlays/<auth-server-name>/login-spi/
/overlays/<auth-server-name>/other-spi/
/server-config optionally contains a single json file that replaces
keycloak-server.json
/account-spi optionally contains a single jar file that replaces
keycloak-account-freemarker.jar.
/login-spi optionally contains a single jar file that replaces
keycloak-login-freemarker.jar
/other-spi optionally contains one or more spi jar files to be added to
WEB-INF/lib. Theme jars also go here.
_*Location of SPI jars and other user-defined overalys*_
For now, I'm planning to have the /overlays directory in the Keycloak
subsystem module. They could, for instance, go in a /keycloak directory
such as <wildfly-home>/keycloak. Any thoughts on this?
_*Uploading overlays from CLI*_
It is already possible to create overalys via CLI. You upload the
content and assign it to deployments and server-groups. The CLI
commands for this are rather complicated and you really need to know
what you are doing.
We could make this easier by adding simpler CLI operations to the
Keycloak subsystem. However, I think we should hold off on this until
we find out if the directory-based approach is acceptable to users. In
the mean time, we can just document the CLI commands needed to upload
overlays.
10 years, 2 months
initial login protocol refactoring done
by Bill Burke
I think everything that can be is now protocol independent. I wrote a
provider for protocol plugins:
LoginProtocol
LoginProtocolFactory
URI schemes were refactored, but the old ones are there and deprecated
for backward compatibility. I'll probably have to tweak things more
once I put in SAML, but the bulk of it should be done.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
10 years, 2 months
Releases next week?
by Stian Thorgersen
Looks like clustering will still be finished this week, so I'd like to release 1.1.0.Alpha1 next week (probably Wed). Then once SAML is finished we can release Alpha2 (or Beta1?).
At the same time should we release a 1.0.2.RC1 (or just go straight for 1.0.2.Final)?
10 years, 2 months
Ok to have no direct links to...
by Bill Burke
I need some input.
It is ok for, registration page and social link buttons to only be
linkable from within a Keycloak login page?
The idea is that there would be a OAUTH specific and SAML specific login
page entry point where client ids are verified and a ClientSessionModel
is created. Registration page, social login links, required user
actions would all be driven by a ClientSession code and would not be
linkable to from the outside world. This allows those pages to be
completely separate from the login protocol being used.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
10 years, 2 months
