social login and remember me
by Bill Burke
I implemented "Remember Me" for regular login. The problem is, it won't
work for social because social login using an href so "remember me"
checkbox will not get propagated.
* Social login links need to be turned into a form containing a img
submit button for each, correct?
* Where should "Remember Me" go? Have 2 Remember Me checkboxes?
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
10 years, 10 months
Update on authz for admin console
by Stian Thorgersen
I've got fine-grained authz permissions working for the admin console now. There's 4 roles associated with each realm (represented as an app in keycloak-admin realm). These allows users to manage the realm, clients, applications and/or users. The admin console has also been updated to only show the sections a user has permissions to (for example if a user can only manage-users the settings, applications and clients links are not shown). Obviously rest endpoints check for permissions as well.
There's a few issues left that I'm working on:
* Need to fix refresh in admin - I'm hoping to use refresh tokens for this
* Admin needs to log out/log back in after creating realm - An admin (super) has access to all 4 roles for all realms. When a realm is created these roles are created as well, so the current token doesn't contain these roles.
AuthenticationManager was starting to become quite messy, so I extracted methods specific to admin console and account into a separate AppAuthManager. The token in the cookies created for these didn't use to include roles, which I've added to make it simpler to check for permissions.
If anyone wants to have a look at what I've got atm it's at:
https://github.com/stianst/keycloak/tree/admin-access
10 years, 10 months
Semantics of Realm.get***ById()
by Marek Posolda
Hi,
Felt into an issue when trying to fix testsuite with Mongo and adding
more unit tests... Currently when we call realm.getRoleById("123") it
will always return the role with ID "123" even if this role belongs to
different realm or it's application role. For JPA model, there is
usually just call to: RoleEntity entity = em.find(RoleEntity.class, id);
Nothing, which checks that role with this ID belongs to this realm. I am
not sure how to address this. I can see options:
1) Change the semantics, so that realm.getRoleById("123") will return
role just in case that it belongs to this realm/application. This means
that instead of em.find(RoleEntity.class, id) we will need to use named
query for both roleId and realm. This will affect performance...
2) Move methods like "getRoleById", "getApplicationById", "getUserById"
etc. from RealmModel to IdentitySession as it would be global search
(not just in context of the particular Realm). This will require some
changes in impl, as for example RoleAdapter or ApplicationAdapter wants
access to RealmModel right now.
3) Keep current behaviour and live with the fact that "get***ById()" may
return entity from different realm.
To me, it seems that option 3 is fine and won't affect performance, but
wanted to ask for sure.
Marek
10 years, 10 months
caching
by Bill Burke
What's been brewing around in my mind awhile is optimization of the
token service. There's no reason everything couldn't be cached in
memory for each token service deployed. Even millions of users could be
cache. Memory is cheap.
The cache should be local only and only the Token Service should use it.
Admin console, or any other update operations would cause invalidation
of each cache on each machine by sending invalidation messages. These
invalidation messages would be REST invocation secured by Keycloak of
course! If we wanted to put in any guarantees, we could back these
invalidation messages with HornetQ or something.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
10 years, 10 months
/tokens/access/codes now uses Basic Auth
by Bill Burke
Since we're using client secret now to authenticate clients, I changed
the protocol to use Basic Auth as per the OAuth and OpenId Connect
specs. I updated the javascript adapter to use basic auth (I think),
but I don't have an app to test against.
P.S.
I hear Marek laughing and/or cursing at me in the background...
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
10 years, 10 months
Authz for admin console/endpoints (KEYCLOAK-292)
by Stian Thorgersen
Currently a user in the 'keycloak-admin' realm with the role 'admin' has full access to all realms. We need to support a bit more fine-grained access control for admin console/endpoints. At the bare minimum we need to be able to have users that can administer only some realms. Further, it would be nice to build this on-top of roles alone and not require an ACL table or something similar.
We could start with the following permissions/roles for a realm:
* view-realm-config
* manage-realm-config
* view-users
* manage-users
* view-applications
* manage-applications
* view-clients
* manage-clients
* admin (composite role containing all the above roles)
One approach to this would be to create an application per-realm that represents that realm (application name could be 'realm-<realm name>'). This would be created automatically when we create a new realm, and it would have the above roles as application roles. Users can then be granted access to individual realms by mapping the roles for the associated application to them.
We could also have a composite realm role 'admin' that maps to the 'admin' role in all realm applications. Any user that is granted this role would have full access to all realms.
This made me think about the concept of "resources" in Keycloak. A resource is similar to an application except it doesn't have scope mappings, nor does it have credentials. This could be used in the demo for the 'database-service', which would mean we'd have roles associated with the 'database-service' rather than using realm roles. It would also provide an installation file (and wildfly config) where 'bearer-only' is set to 'true'.
10 years, 10 months
what's next for Alpha 3?
by Bill Burke
I'd like to work on OpenID connect support as well as refresh tokens.
We also need to help meet Aerogear's requirements, probably mostly
around bootstrapping on Openshift.
Like Alpha 2. I'd like each one of us to do one thing major, then do
another quick release 3-4 weeks from now.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
10 years, 10 months
Refresh tokens
by Stian Thorgersen
With regards to refresh tokens it would be nice to add support for users to be able to manage applications at the same time.
https://issues.jboss.org/browse/KEYCLOAK-312:
Account management should have a page that lists all applications and clients that have access to a users account. This would be a list of applications and clients that have been given a refresh token (and where the refresh token hasn't expired). For clients it should also list the scope that was granted (probably doesn't make sense to list this for applications).
Users should be able to revoke access to an individual application or client. This would result in the refresh token being invalidated so the application or client wouldn't be able to retrieve a new token.
10 years, 11 months
