possible change to subsystem format
by Bill Burke
Old format was
<realm>
realm info
<secure-deployment name="war name">
app specific deployment
</secure-deployment
</realm>
For now, I'm getting rid of the concept of a realm. So it will just be:
<secure-deployment name="war name">
all the config you'd see in a keycloak.json file
</secure-deployment>
The benefits of this is that it will be really easy for the keycloak
admin console to initiate a deployment. Also, not sure yet, but we may
end up having an "UNCONFIGURED" mode for keycloak adapters. Where they
aren't attached to a realm/application, but are applied to the WAR
deployment (see the Aerogear hread).
The downside to this is that there will be duplicate config if there is
more than one app on the server. Later on I'll add a "realm-ref"
element or something to secure-deployment so we can define common realm
data elsewhere. I'll do that next iteration.
Bill
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
10 years, 10 months
Patternfly and RCUE styles
by Stian Thorgersen
Currently we use our own styles in Keycloak. Problems with this include:
* We have to maintain our own styles
* Can't integrate as easily with other projects
To solve these issues we need to replace our styles with the stylesheets provided by RCUE project, or more specifically the PatternFly project (which is basically RCUE for projects, while RCUE is for products).
Villiam has done an excellent start on this work. However, there was a fair few changes required to the html so there may be some bugs.
I'd like to include this work ASAP. This is to prevent headaches with merging and also to introduce the slight changes to the l&f as early as possible. So I think it would be good to include this in alpha2.
If you want to have a look at the current state go to https://kc2-sthorger.rhcloud.com/auth/admin/index.html (username/password: admin/secret). Code is at https://github.com/stianst/keycloak/tree/FORMS2.
10 years, 10 months
Use UUID for IDs
by Stian Thorgersen
I propose we use java.util.UUID to IDs generated by DB (JPA @GeneratedValue). Reasoning behind this is:
* IDs are the same independent of store used (JPA, Mongo, PicketLink, LDAP, etc)
* Easy to support many RDBMS (some support sequence and/or identity, so it seems the recommended approach when you don't know what the db will be is table)
* IDs can be generated without a "central" db
Also, we'd like to be able to export all data to a json then import into any store. We then need to make sure there's no conflicts in IDs. For example you first use KC with H2, then export all data, import into MySQL, then export all data, import into Mongo. I can see that causing some issues with IDs generated by DB.
This is related to DB issues (Mysql, PostgreSQL not working), Mongo store impl as well as move to using user id instead of username as the reference for a user.
10 years, 10 months
missing styles from initial login page
by Bill Burke
I'm seeing this weird behavior where my first login (from the
customer-portal) shows a login page with no styles. If you look at the
HTML page source, no stylesheets are linked. Hitting browser refresh
then loads the login page correctly, and the stylesheets are linked and
shown in the source of the HTML. This is only for the 1st time you see
the login screen.
Any ideas?
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
10 years, 10 months
Running unit tests with different model implementations
by Marek Posolda
Hi,
For improving testability, it would be nice if it's possible to execute
unit tests with all available model implementations.
It seems that for testability of various model implementations, it may
be good to move majority of unit test classes (like AdapterTest,
ImportTest etc) from module "services" into "model/api" and then each
model implementation will run all unit tests for particular model during
it's own build. So building of module "model/jpa" will run all unit
tests with JPA model and similarly building of "model/mongo" will run
same set of tests for mongo module. This means that unit tests for all
enabled models will be automatically executed during Keycloak build,
which means that various model implementations won't be out of sync.
This would mean that some util classes used in unit tests will be moved
from services to model/api as well because unit tests need them (For
example RealmManager, ApplicationManager etc.)
Another possibility is to keep unit tests in "services" module and just
add some dedicated profile for running tests with Mongo. So for example
-Dkeycloak.model=mongo will run unit tests with Mongo model and
-Dkeycloak.model=all will run unit tests with all available model
implementations (so currently jpa and mongo).
What do you think?
Thanks,
Marek
10 years, 10 months
subsystem status
by Bill Burke
Forked and ported Stan's subsystem to AS7/EAP 6.1. I still have some
cleanup work to do, but what this means is that we will no longer have
special examples directories in the distribution! Installation and
configuration between AS7/EAP/Wildfly will be consistent too.
The side effect of this is that I'll have to redo some of the
screencasts. But that was inevitable. I hope to be done by Friday.
Bill
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
10 years, 10 months
Aerogear UPS + External Keycloak boostrap
by Bill Burke
We still need to figure this out.
Can't port mappings be set up from the cartridge config so the
as7/wildfly mgmt HTTP interface can be exposed? There's also a problem
of setting up credentials for the as7/wildfly HTTP mgmt service. Quite
honestly, I'm not sure how we can use a Wildfly subsystem for this.
We just might have to build support for all this within the keycloak
adapter itself. Allow it the ability to modify the keycloak.json file.
Then you only have one Aerogear UPS + Keycloak cartridge.
1. UPS would use a preconfigured co-bundled Keycloak for initial login
2. Initial login would require you to change the admin password
3. UPS Admin page allows you to switch Keycloak realms.
4. Switching a realm automatically creates the UPS Application on the
new Keycloak realm. It also rewrites the keycloak.json file, and also
modifies the adapter's runtime config.
Am I making any sense?
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
10 years, 10 months
User ids and usernames
by Stian Thorgersen
A user should have an id, username and email (what we have now). The id should be generated by the server and should never change for a user. The sub field in the token should use this id, not the username. Applications that wants to store information associated with a specific user should also use this id, not the username or email, as the id will never change.
That means it should be possible for a user to change his/her username. Obviously a username has to be unique within a realm. We should then allow a user to login with either their username or their password. When a user is able to login with their username we can also remove the forgot username option on the login form, and only have a forgot password option.
This would also help integration with social login as now we don't have to try to create a sensible username for a user on social login. Instead we create a generated id, and don't even set a username. A user can then set the username they want through the account management (or on the update profile action page if that option is enabled).
If there's no objections to this, I'd like to add these changes to alpha2.
10 years, 10 months
subsystem integration phase 1
by Bill Burke
Going to iterate on this. The admin console UI could end up different
in the end, but for phase 1 this is what I've decided to do:
* Get rid of RequiredApplicationCredentials. Applications will have a
viewable client secret from admin console. This will be resetable form
admin console too. (cloud.google.com allows you to view the client secret)
* Application Install page will now just have a select list. Options
will be: "config file", "remote wildfly". Basically all integration
points we support.
* "config file" will display what we have now, except credential will be
set up as client secret will be exposed
* "remote wildfly" will bring you to a page that asks for:
- URL of Wildfly admin
- username and password of wildfly instance
- deployment name
- A "Configure" button
Clicking the configure button will remotely set up the wildfly
subsystem. Creating a realm if it doesn't already exist, then creating
the deployment.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
10 years, 10 months
Keycloak Subsystem PR
by ssilvert＠redhat.com
I've done the initial pull request for the Keycloak subsystem. After
starting fresh with the latest build I was finally able to verify that
it really does work end to end!
I probably won't have much more time to work on Keycloak for the next
4-5 weeks. So I'll try to put everything I know about it into these
notes in case someone wants to take it over. I happy to answer
questions though.
Directions to try the subsystem on your own:
* Build the new subsystem module.
* Rebuild the undertow adapter. The EAP6 adapter has not been updated
to use the subsystem, so you will need to use WildFly.
* Update standalone.xml. I've attached a version of standalone.xml that
I used with the Keycloak appliance. It shows adding the Keycloak
extension near the top of the file and adding the subsystem definition
near the bottom.
* Copy
keycloak/subsystem/target/keycloak-subsystem-1.0-alpha-2-SNAPSHOT.jar to
<WILDFLY_HOME>/modules/system/layers/base/org/keycloak/keycloak-subsystem/main
* Copy
keycloak/distribution/modules/src/main/resources/modules/org/keycloak/keycloak-subsystem/main/module.xml
to
<WILDFLY_HOME>/modules/system/layers/base/org/keycloak/keycloak-subsystem/main
* Edit module.xml and add the subsystem jar as a resource-root.
Alternatively, you can just use the module.xml attached to this email.
* Copy
keycloak/integration/undertow/target/keycloak-undertow-adapter-1.0-alpha-2-SNAPSHOT.jar
to
<WILDFLY_HOME>/modules/system/layers/base/org/keycloak/keycloak-undertow-adapter/main
Now if you reboot WildFly you can view and manipulate the subsystem
using CLI or CLI GUI. All operations such as add/remove/write-attribute
should be working. I recommend CLI GUI so you can see everything in
context. https://community.jboss.org/wiki/AGUIForTheCommandLineInterface
To test the subsystem with a live application, I did the following:
* Copy the customer-portal.war to customer-portal-subsys.war.
* Remove keycloak.json and jboss-deployment-structure.xml from the WAR.
The subsystem makes those files redundant.
* Edit the web.xml inside the WAR and change the <module-name> to
customer-portal-subsys. I'm not sure if this is really needed. If we
need to manipulate web.xml settings at deploy time then the subsystem
can be modified to do that too.
* Define the customer-portal-subsys application in Keycloak Admin. It
should have the same settings as customer-portal.
* Deploy customer-portal-subsys.war to WildFly and test it out.
Future tasks for the Keycloak Subsystem:
* Integration with the Keycloak Admin
* Review the attributes of realm and secure-deployment to make sure they
align with keycloak.json.
* Fill in help text in
keycloak/subsystem/src/main/resources/org/keycloak/subsystem/extension/LocalDescriptions.properties
* See comments in KeycloakAdapterConfigService.java. This class may
work better as a plain Singleton instead of a service.
* It probably wouldn't hurt to ask Brian Stansberry to give the
subsystem a quick review.
* More tests
* Package the subsystem with the distribution
* Documentation
10 years, 10 months