per realm admin console implemented
by Bill Burke
Within each realm, you can now add permissions to any user of that realm
so that they can access the keycloak admin console (but only for that
realm). This will allow SSO between keycloak admin console and an
application's admin console. Will probably make it easier to use admin
REST API too in many scenarios.
To access realm-specific admin console go to:
/context-root/admin/{realm}/console/index.html
Finally, you can now set the admin console theme for each realm-specific
admin console within the realm's theme settings too.
Each realm now has 2 new applications added:
{realmName}-realm
security-admin-console
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
12 years, 1 month
User sessions added
by Stian Thorgersen
User sessions have been added. In summary when a user logs in a new session is created (and persisted in the model). The identity cookie as well as all tokens/refresh-tokens are associated with a session. When a user logs out the session is invalidated (removed from the model), which invalidates the identity cookie and all tokens/refresh-tokens.
There's two related issues left to do:
* Make sure adapters only log out a specific session (if LoginAction contains a session id)
* Allow a user to log out all sessions through the account management console
Also, we may want some mechanism to retrieve the status of a session from applications. This could be a REST endpoint, or the crazy iframe technique from OpenID Connect. I think this can be postponed to after 1.0 though.
12 years, 1 month
openid connect iframe logout
by Bill Burke
I'm looking at:
http://openid.net/specs/openid-connect-session-1_0.html
I don't think using iframes for single log out is any better than what
we're currently doing and planning on doing for keycloak.js.
For the OpenID Iframe technique, if our global login cookies are
HttpOnly, then the OP Iframe will have to do a periodic "ping" request
to the server to test the cookie. This is really no different than the
current plan to expire login sessions and invalidate refresh token
requests based on on a login-session id. I say this because there is
still a time element involved where there is a window from when the user
logs out and either the periodic "ping" hasn't been executed yet (openid
connect iframe technique), or the access token hasn't expired yet.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
12 years, 1 month
Signle sign off doens't work for admin console
by Bill Burke
I think I can solve this by moving the admin console and its REST api
under /realms/{realm}.
URL would be:
/realms/{realm}/console/index.html
/realms/{realm}/console/{.js, .html, .img}
/realms/{realm}/console/realms/{realm}/... admin REST api
To protect against CSRF (not sure its applicable to JSON services
anyways), we can do double authentication with the realm's Identity
cookie and an access-token for REST calls.
When a user does a single-sign-off, this will expire the realm's global
identity cookie, and thus, the admin console would then also
automatically be logged out.
BTW, this single-sign-off problem exists for all javascript apps secured
by keycloak.js or that don't have a server-side session we can callback.
We might be able to use:
http://openid.net/specs/openid-connect-session-1_0.html
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
12 years, 1 month
Export/import implementation
by Marek Posolda
I am planning to start soon on export/import. If I recall correctly, one
of the requirements is to export the content of whole DB content
(including IDs and password hashes) to JSON file, which can then be
later imported into other DB. This will allow to migrate between
environments and various DB types (For example from Mongo to MySQL and
viceversa).
I have some question though
1) I assume that DB should be cleared before full import from JSON file?
Or do we want to update existing data without deleting the previous
content? I assume that this is used for migration, so it's not about
updating but completely delete and recreate existing DB, correct?
2) How to implement it. I can see two approaches
a) Use model API to retrieve content of the DB into JSON file during
export. Similarly during import use model API to sync objects back from
JSON into model DB.
b) Add some methods to KeycloakSession interface like:
ObjectNode export();
void import(ObjectNode node);
and implement export/import separately for each model.
Approach (b) might be better for performance as it allows to directly
use low-level queries specific to JPA, Mongo or other model
implementations to export/import stuff more effectively in batch,
however it will require changes in model implementations and probably
adding more stuff into dependencies. So I am more convinced to use (a).
Thoughts?
3) How will be export/import triggered?
I think that for security reasons, we want to always export into local
file with KC server and similarly always import from local file. Is it
correct? I can see approaches like:
a) Use KC admin console. By default, just "admin" will be able to
export/import stuff . Data will be always exported/imported into JSON
file local to server. So it will be possible to trigger export/import
remotely from admin console, but just use local JSON file. The import
would be tricky though as import will recreate all data (including admin
realm and admin user) so it would need to cancel logout sessions
including the session of admin user who triggered import.
b) Use some script, which will trigger JVM process for export/import
data. Script can be executed locally from CMD. I can imagine something
like this (executed from the directory with AS7/wildfly server):
./bin/keycloak-import -Dkeycloak.model=jpa
-Ddata-to-import=/tmp/file-with-full-kc-data-to-import-which-were-previously-exported.json
Assumption is that distribution contains deployed KC inside
standalone/deployments/auth-server.war. Script will be able to run JVM
which will have access to needed KC jars on classpath and access to
persistence.xml . In AS7/Wildfly environment the persistence.xml bundled
inside auth-server.war is using datasource though, so this JVM process
would also need to parse datasource from
standalone/configuration/standalone.xml as it won't be executed in
managed AS7/Wildfly environment.
c) Use something similar to approach (b) but execute export/import from
AS7/Wildfly CLI or admin console. The advantage is that it is triggered
from the managed (AS7 or Wildfly) so has access to server resources like
datasource referenced from persistence.xml
Any other possibility I am missing?
Thanks,
Marek
12 years, 1 month
merged: started /rest remove and pom fixes
by Bill Burke
Some of the poms were broken. Also removed "/rest" from RealmsResource.
Finally, I refactored a lot of the tests so that they aren't so
sensitive to url schema changes anymore.
So, you might want to merge! I'll be doing a lot more of these URI
schema change and removing /rest entirely. This goes along with the
realm admin work, btw.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
12 years, 1 month
can we ditch org.json?
by Bill Burke
Would it be possible to ditch org.json and use Jackson instead?
Specifically the JsonSerialization class?
It will just be one less library that needs to go through productization.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
12 years, 1 month
