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
9 years, 8 months
Keycloak artifacts not in Maven Central
by Karel Piwko
Hi,
I've noticed that Keycloak Maven artifacts are not synced to Maven Central,
they are only on JBoss Nexus. Do you plan to sync them to Central?
Let me know if so, I can help with that.
Karel
9 years, 8 months
when next release
by Bill Burke
IMO, next release should be ASAP and include:
* Composite roles (almost done implementing)
* Wildfly Subsystem
* Themes (how far away are you stian?)
When we are done with these 3 things (and documented) we will release.
Any other features that sneak in in that timeframe we will consider a bonus.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
9 years, 8 months
Brining KeyCloak to WildFly Management / Subsystemless Integration
by Darran Lofthouse
Hi all,
Just finishing off some WildFly 8 tasks and have a few things to work on
for EAP after that but as soon as that is done I need to get on with the
next steps for WildFly 9.
For the future SSO within domain management we have a few different
issues to content with: -
- CORS
- Switching to a new identity provider
- Integrating with existing authentication mechanisms
- Enabling OAuth
What I wanted to check with you guys before I start raising some
tracking issues is if we can consider these points independently or if
we are going to need an all at once approach?
As an example we had a discussion the other day where it was identified
there may already be a CORS implementation in KeyCloak we can use, that
is also one of our number one requirements in WildFly - would it be an
option to integrate that portion first and then start looking to the rest?
Regards,
Darran Lofthouse.
9 years, 8 months
Customization for Keycloak
by Gabriel Cardoso
Hi,
I’m working on the customization of Keycloak based on the new logo and colors.
Here is my proposal for the console:
What do you think?
Gabriel
---
Gabriel Cardoso
User Experience Designer @ Red Hat
9 years, 8 months
Storage protection
by Bruno Oliveira
Good morning, I've been thinking about how to properly protect private key in a world where HSM is not an option. Currently a key pair is generated (https://github.com/keycloak/keycloak/blob/c0a1090733975977179662dd44fc3ac...) to cryptographically sign tokens (https://github.com/keycloak/keycloak/blob/0fe9318fa414d06fc39c83d91c78eff...) and the private key is stored into the database.
Some of the possibilities to improve it:
# 1
- HSM or Java Security manager are perfect, but impractical for regular devs, that would require a lot of maintanance (a dream)
# 2
- Entering a password for a PKCS#8/PBKDF2-derived key, also impractical assuming that someone would be required to enter the password at each app startup
# 3
- Not bullet-proof solution, but store the key into a text file that only sysadmins and the web server has access, doing our best with the usage of ACLs provided by environment. I understand Bill's concern (http://lists.jboss.org/pipermail/keycloak-dev/2014-January/001089.html) but at the same time, a file could have a very restricted access while the database is more acessible to developers.
-
# 4
Generate the keys per session, instead of use it per realm (it must be tested/implemented because that could slow down our server)
# 5
Leave it as is.
So what do you think? Ideas or tomatoes?
--
abstractj
9 years, 8 months
The Keycloak Vision/Core Values
by Bill Burke
Keycloak aims to provide the entire User Interface experience for your
security needs so your applications don't have to. UIs like "Forgot
Password", "Lost Authenticator", registration pages, social login,
update/reset password, and user account management can all be handled
and customly styled by Keycloak so you don't have to implement these
screens and features for each one of your web applications.
How's that sound?
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
9 years, 8 months
Keycloak Integration Options (with UnifiedPush Server)
by Matthias Wessendorf
Hello there!
For the AeroGear UnifiedPush Server Bruno and I started looking at Keycloak
([1]). On this branch, we basically include the adapater jar and a
keycloak.json file and simply rely on Keycloak as an external service (e.g.
as different WAR inside of the same containter). That works very well so
far!!
However, here I have to create a realm in the server (either via
Admin-Console or by including it via something like 'myRealm.json') and
afterwards I have to 'hard-code' the public key into my own WAR file
(keycloak.jso):
https://github.com/aerogear/aerogear-unifiedpush-server/blob/keycloak/src...
So this would be a little bit of a negative effect;
Another option would be embedding the Keycloak JARs into my own WAR file,
by adding all the dependent JARs, similiar to what the 'keycloak-server'
does ([2]). At the end I'd have an uber WAR file, containing UPS and
Keycloak facilities. However, I think the 'problem' w/ the 'hard-code' key
inside of the keycloak.json would be there as well, right ?
On the IRC channel Stian mentioned that there will be a WildFly subsystem
soon. I think, from what I hear, the real benefit of this subsystem are the
following items:
* configuring realms through standalone.xml
* automatically sets up security for wars (using the wildfly adapter)
So, this option seems to let us avoid the above described keycloak.json
'issue', right ?
For a future integration w/ the Keycloak SSO server, I could leverage the
Subsystem deliverables and bundle them w/ our own UnifiedPush Server
distribution, to ensure things are running out of the box; Or is the
subsystem not the best option for a Push/Keycloak integration ?
-Matthias
[1] https://github.com/aerogear/aerogear-unifiedpush-server/tree/keycloak
[2] https://github.com/keycloak/keycloak/blob/master/server/pom.xml
--
Matthias Wessendorf
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
9 years, 8 months
new client type: "server"
by Bill Burke
Stan's work on the Wildfly subsystem got me thinking about how we might
want to reorganize keycloak. Since multiple applications may often be
deployed on the same server, what if we split the notion of Application
and client? Application would be a place to define application roles
and application scope only. A server can be associated with multiple
applications.
For config/bootstrapping, the user would specify a server in the admin
console and set up trust between the two. Then the user could import
deployments from a server and associate them with a realm and even
download the the roles of each of these deployments and create
Applications from them. For OAuth tokens, server would specify the
server's client_id as well as a scope. The scope would be the
Application the server is asking a token for.
So, a server would have:
* a client_id
* credentials
* admin URL
* be associated with one or more Applications
Application would have:
* roles
* valid redirect urls (which are associated with a server)
* scope
* sessions (view who's logged in where into what server)
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
9 years, 8 months
Device mgmt
by Bill Burke
Here's my thoughts on device mgmt, both UI and protocol:
Scenario:
An iOS device as a "Brokerage App" installed. The app needs to do REST
invocations to be able to trade stocks, etc. Devices must be registered
in order to obtain permission. Flow would look like this:
* User installs app on iPad.
* User hits login button on app.
* User is redirected to browser with a Keycloak server URL
* User enters in credentials
* User is redirected to "Device Registration" page. Keycloak asks user
if it authorizes access to the device.
* Keycloak registers the device under the user and generates a device token
* User is redirected back to iPad ap
* iPad app gets auth code from redirect URL
* iPad makes REST request to obtain auth token *AND* a device token.
* iPad app stores the device token.
Next login is the same, except there is no "grant" page displayed. The
iPad app uses the "device token" as a credential to turn an access code
into an access token. These are all extensions we'll need to make to
the current OAuth protocol.
UI work:
The User Account Service will need a way to list registered devices so
the user can see it and manage it (i.e. remove a registered device).
Admin Console should have a way to define a "Device Type". The name,
description and scope of the device type is defined. "name" is used in
the initial OAuth grant as a client_id identifier so that Keycloak knows
what to display as a description in the
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
9 years, 8 months
