Keycloak M1 distribution
by Stian Thorgersen
What will the distribution of Keycloak be for M1? Just keycloak-server.war? Should this be deployable to AS 7.1.1.Final and WildFly?
OpenShift QuickStart
--------------------
For OpenShift I thought a QuickStart using the AS 7.1.1.Final cartridge would be the simplest option. The QuickStart basically is a github repo that contains a starting point to get Keycloak installed. It would update the Resteasy version + install keycloak-server.war. To start a Keycloak instance using rhc you'd use:
# rhc app-create keycloak jbossas-7 --from-code https://github.com/keycloak/keycloak-openshift-quickstart.git
We could also make the QuickStart automatically configure Keycloak to use PostgreSQL if available. For example if creating a Keycloak instance with the following it would use PostgreSQL instead of H2:
# rhc app-create keycloak jbossas-7 postgresql-9.2 --from-code https://github.com/keycloak/keycloak-openshift-quickstart.git
WildFly
-------
I've tried to run Keycloak on WildFly and ran into a PicketLink/Hibernate issue (see https://issues.jboss.org/browse/KEYCLOAK-135 for details). PicketLink guys have merged fix, but that would require upgrading to 2.5.3.Final when it's released.
I've also tried to upgrade to PicketLink 2.5.2.Final, but am having some issues with the ApplicationData/Entity. When loading the Application from the database, PicketLink tries to set a RealmData on ApplicationData.resourceUser which you may imagine throws an exception. I've added it to https://github.com/stianst/keycloak/tree/pl-2.5. It's either a bug in PicketLink, or a mistake in ApplicationData/Entity, I'm not sure which though.
12 years
adapter cors support
by Bill Burke
Apologies, I had to work on a new Resteasy release for the past week.
Am back on Keycloak now.
I committed support for CORS at the adapter level. Allowed origins are
now stuffed into the token. The adapter handles Preflight and Regular
CORS requests. It validates Origin vs. the allowed origins within the
token. There's an example:
* add localhost1 and localhost2 entry to your /etc/hosts or OS equivalent
* Open browser debug console window
* http://localhost1:8080/customer-portal/customers/cors-test.html
* login and then view the console.
If you instead go to:
http://localhost2:8080/customer-portal/customers/cors-test.html
You will see a failure.
I also added a "/K_QUERY_BEARER_TOKEN" endpoint to the adapter. This
allows you to obtain the text representation of the access token so that
it can be used to make authenticated REST calls. The example makes use
of it.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
12 years
Automatically login user to application when logged into realm
by Stian Thorgersen
Currently there's no mechanism for an application to automatically login a user that is already logged in to the realm.
I've added a proposal to https://github.com/stianst/keycloak/tree/auto-sso. It's a simple approach where all it does is to add an optional 'noforms' query parameter to 'auth/request/login'. If noforms is specified a code is returned only if the user is already logged in to the realm + grants are already given (as grants are not saved currently that will never be the case). Otherwise it will return error=access_denied.
12 years
Composite roles
by Stian Thorgersen
I wanted to clarify the idea behind composite roles.
We'll support it by making it possible to map roles to a role (in the same way as it is possible to map roles to users and applications). Through the admin console when editing a role there's an option to enable/disable composite for a role. If enabled the role mapping forms will be displayed (see role-detail.png). When listing the roles for a realm the composite roles will be marked as well (see roles.png).
This means that a realm role can be mapped to a set of realm roles, as well as a set of roles per-application.
There's mainly two use-cases for this. First is to make it simpler to assign roles to users by allowing admins to assign groups of roles to users. Secondly this comes in handy when we want to specify a set of default roles for a realm. Default roles are those that are automatically assigned to a new user when the user self-registers (we probably want the same when an admin creates a user, but that hasn't been added yet). In both cases it's possible for an admin to modify what roles are mapped to the composite role.
The token service will expand composite roles. This means that the scopes requested by applications should only include simple roles and the token will also only contain simple roles. For performance reasons there's should be an attribute set on a role to indicate whether or not its a composite role or not (this means we'll only look up mapped roles when needed).
An example:
* 'default' realm role is mapped to realm role 'realm-user', twitter application role 'twitter-default' and calendar application role 'calendar-user'
* 'realm-user' is a simple role
* 'twitter-default' is a composite role for the twitter application that is mapped to 'create-post' and 'view-posts' roles
* 'calendar-user' is a simple role for the calendar application
If an application requests all scopes this will result in a token with the following roles:
{
realm_access : { roles : [ realm-user ] },
resource_access : [
{ twitter : { roles: [ create-post, view-posts ] } },
{ calendar : { roles : [ calendar-user ] } }
]
}
12 years
Support for invalidation of access/refresh tokens
by Marek Posolda
Hi,
it seems that actually there is no way to invalidate access token by
client. For example: if client recognize that his access token has been
stolen, he may want to logout and invalidate his access token, so that
nobody can use it anymore to authenticate REST calls via Bearer
authentication. Actually Bearer token authentication (like
CatalinaBearerTokenAuthenticator) just verifies the signature of access
token, but this verification will pass for stolen access token.
It seems that for supporting this feature, we may need:
- Store all valid access tokens (either in memory or in persistent storage)
- REST endpoint for invalidate access token, which could be used by client
- REST endpoint for check if access token is valid, which could be used
by application providing REST endpoints in addition to signature
verification
It seems that this problem is maybe not so bad for access tokens as long
as they have low expiration period, but what if attacker somehow steal
refresh token? Is it planned to have invalidation support for refresh
tokens?
Marek
12 years
Outstanding work for M1
by Stian Thorgersen
In my opinion here's the outstanding work for M1:
* Composite roles
* Retrieve full user profile
* Ability to automatically log in user to application when logged into realm
* JavaScript SDK
* CORS support for applications via adapters
* WAR distribution deployable to JBoss AS 7.1.1.Final (and WildFly?)
* OpenShift quickstart
* Forms - some minor work outstanding
* Admin console
* Documentation
* Documentation for REST endpoints
* Examples
* Keycloak website setup and finalized
* Online video walking through a demonstration of features
* Online video walking though how to configure it
* More tests?
12 years
Alert x Feedback
by Gabriel Cardoso
Hi guys,
I tried to adequate the feedback messages in the console to have my design but I would need to use this set of classes:
<div class="feedback success">
[content]
</div>
The code in the console is:
<div class="alert alert-success">
[content]
</div>
By updating it to my classes, it does not work anymore. Should I change my CSS classes to alert or anybody could make it work with <div class="feedback success">? FYI, the form area is using my css classes.
Gabriel
--
Gabriel Cardoso
GateIn Portal | User Experience Designer
12 years
changes to admin ui login/bootstrap
by Bill Burke
There are some changes on how Keycloak Admin UI is bootstrapped:
* There is no longer a registration page for the admin ui.
* There is a built in user
username: admin
password: admin
* There is a built in realm "Keycloak Adminstration"
* This realm has a built in application "Admin Console" with one role:
"admin"
* You can add additional users to the "Keycloak Adminstration" realm.
They must add an Admin Consle "admin" role to be able to log into the
admin UI.
Eventually, the bootstrap will require a "password update" for this
built-in "admin" user. There's a bug in the admin UI login on the
server side that I haven't figured out yet. I'll ping the list when this
is ready.
Going forward, the admin REST interfaces/admin UI will *NOT* use the
token service. We can't use the token service out of the box for the
admin UI/REST interfaces because this would require specifying the
Application password for the "Admin Console" and enabling it through the
UI. For usability, IMO, it is best that the user doesn't have to do this.
You will still be able to use the Token Service's OAuth flow to obtain
an access token. The admin REST interface should support bearer token
access, although I haven't written any tests for it yet.
BTW, the "Admin Console" application has a random, large, password
generated for it at bootstrap. A side effect is that this password is
never known. We need to generate a random, unknown password for this to
avoid a security hole and to keep the nice usability. Hope I make sense
here. :)
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
12 years
modeling CORS support
by Bill Burke
Here's my thoughts on modeling CORS.
* We'll take the access token approach to support CORS
* There will be a default set of allowed origins configurable at the
realm level.
* Each Application and OAuth Client within the realm can add their own
allowed origins. When an Application or OAuth Client initiates a token
grant request, the token will be populated with the allowed origins
configured for that Application or OAuth client.
* Application adapters will have configuration switches to allow all
method/headers. Later on we will add options in the management
interfaces to configure headers/methods as well.
Bill
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
12 years
