Cross Client Use case
by Raghu Prabhala
We have a use case similar to the one listed in the below url - basically once a user is authenticated, a client application after receiving the tokens from the Provider, shares the tokens with a few other applications that are in a group. The other client applications should be able to verify the tokens without requiring any more user interaction. In the OIDC world, unfortunately, the aud parameter has the clientid of the first app only and it will fail validation by the other apps. So, is there any way this can be handled in KC?
https://developers.google.com/identity/protocols/CrossClientAuth
11 years
KeycloakSession question
by Stan Silvert
Is KeycloakSession always short-lived?
If so, it might be relatively easy to make the JSON File based
persistence more robust and probably fix the cache tests that currently
fail with it.
All KeycloakSessions would share the same in-memory model. When a
KeycloakSession ends and requests to write the model to disk, all new
requests for access to the model are blocked. When all active
KeycloakSessions are done, we write out the model and unblock the new
KeycloakSessions.
But this only works if we can assume KeycloakSession is short-lived.
11 years
offline access
by Bill Burke
Wanted to discuss again how offline access might be implemented. IMO,
offline access should be a REST api. Clients would request offline
access and the UserSession would be cloned and the ClientSession would
be cloned for that particular client. ID, Access token and refresh
token would also be regenerated and sent back with the response.
With this approach, the admin console and user account session
management pages will just work. These pages will just work they way
they already work with no extra changes.
Additionally, we would want to allow different session timeouts for
offline access.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
11 years
First round of unifying application and oauth clients
by Stian Thorgersen
First round of unifying application and oauth clients is done. What I've done is:
* Combined ApplicationModel and OAuthClientModel into ClientModel
* Removed OAuth Clients (html and js) from Admin Console and Admin Endpoints
* Renamed Applications menu entry to Clients in Admin Console
Next steps are:
* Add database migration
* Update Representations (deprecate OAuthClientRepresentation and ApplicationRepresentation and add ClientRepresentation)
* Rename Application to Client in Admin Endpoints and Admin Console html/js
* Look for other references to Application or OAuth Client in code
* Update documentation, including migration guide
11 years
Remove IDM entirely or keep Picketlink federation provider?
by Marek Posolda
Not sure if we already decide about $subject. I am in the middle of
forking LDAP from PLIDM and removing PLIDM dependency. Now I wonder if I
should:
1) Remove PLIDM dependency entirely from whole codebase
2) Create the module with Picketlink FederationProvider, which won't be
packaged in distribution by default. This can be separate package used
on demand by EAP customers to migrate their PLIDM users into Keycloak
users. This module will be the only place, which will be still dependent
on PLIDM, but since it won't be in distribution by default, we can
remove PLIDM dependency from appliance and war distributions.
The reason I am asking is, that current LDAPFederationProvider can be
quite easily converted into PicketlinkFederationProvider. But limitation
is, that it will migrate just users. It won't migrate IDM roles into
Keycloak roles..
Or should I simply go with (1) and don't care about the migration for now?
Marek
11 years
thoughts on 1.2->1.3 releases
by Bill Burke
I was thinking that we would cram as many features we can into the 1.2
release, then for 1.3 really focus on:
* refactoring the SPIs
* refactoring the UIs. Reorganizing them, consolidating them, thinking
of good defaults. Think about any features we can remove to simplify things
* Break out the Public and Private apis
* Talk about "config profiles", i.e. Default application templates, and
stuff like that.
* Improving the "Hello World" experience.
Really focus on usability, simplification, documentation, examples, etc.
Take a step back and really think about how to make Keycloak easier to
use and consume.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
11 years
