Import proposal
by Stian Thorgersen
Currently we support importing a complete realm definition using the
import/export feature. Issues with the current approach is:
* Only complete realm - not possible to add to an existing realm
* No good feedback if import was successful or not
* Use of system properties to initiate the import is not very user friendly
* Not very elegant for provisioning. For example a Docker image that want's
to bundle some initial setup ends up always running the import of a realm,
which is skipped if realm exists
To solve this I've come up with the following proposal:
Allow dropping representations to be imported into 'standalone/import'.
This should support creating a new realm as well as importing into an
existing realm. When importing into an existing realm we will have an
import strategy that is used to configure what happens if a resource exists
(user, role, identity provider, user federtation provider). The import
strategies are:
* Skip - existing resources are skipped,
* Fail - if any resource exists nothing is imported
* Overwrite - any existing resources are deleted.
The directory will be scanned at startup, but there will also be an option
to monitor this directory at runtime.
To prevent a file being imported multiple times (also to make sure only one
node in a cluster imports) we will have a table in the database that
contains what files was imported, from what node, date and result
(including a list of what resources where imported, which was not, and
stack trace if applicable). The primary key will be the checksum of the
file. We will also add marker files (<json file>.imported or <json
file>.failed). The contents of the marker files will be a json object with
date imported, outcome (including stack trace if applicable) as well as a
complete list of what resources was successfully imported, what where not.
The files will also allow resolving system properties and environment
variables. For example:
{
"secret": "${env.MYCLIENT_SECRET}"
}
This will be very convenient for example with Docker as it would be very
easy to create a Docker image that extends ours to add a few clients and
users.
It will also be convenient for examples as it will make it possible to add
the required clients and users to an existing realm.
9 years, 12 months
Custom attributes on registration and account management
by Marek Posolda
I wonder if we should improve handling of custom attributes in
freemarker templates and their validation. Let's assume that I want to
add custom attribute "birthday" and I want to add it to all screens
where user can create/edit account. I can see those issues:
- Admin will need to edit 3 separate freemarker templates (registration,
account management, update profile page) to have this attribute
displayed on all those places.
- Missing validations. For registration screen, admin can implement his
own validator through the Authentication SPI. But for account management
and update profile it's currently no way to add custom validations. But
for my "birthday" field, I usually want to have same custom validation
applied on all 3 places
- Built-in validations: Similarly like we have builtin password
policies, we can provide some builtin validators for custom fields
(mandatory, regex)
I wonder if we should add the tab in admin console where people can specify:
- Name of custom attribute and the type. Then we have some freemarker
helper, which will render those attributes in all 3 places
(registration, account mgmt, updateProfile). I believe something similar
like Bill did for custom providers in admin console ( kc-provider-config
directive) can work here too.
- Define the validators applied to each field. Similarly like we have
password/OTP policies, we can have "policies" for each custom attribute.
We can provide "mandatory" and "regex" policy with possibility for
people to add custom field validator implementations if they want.
Not sure if this was already discussed before and just not implemented.
However I think this will be useful and currently can't think of much
reasons why it couldn't work?
Marek
10 years
Adapter Feature Pack
by Pedro Igor Silva
Hi,
Is keycloak-adapter-feature-pack the right pack to use to build distributions to deploy client applications only, which require only the adapters ? In this case, WFLY ones ...
Regards.
Pedro Igor
10 years
user groups vs. client groups
by Bill Burke
In my previous email I talked about combining Groups and Role
Namespaces. Now I want to talk about User Groups vs. Client Groups.
User Groups would manage a set of users. Members would automatically
inherit a set of "permissions": a set of roles. User Groups would also
provide a set of attributes that the user inherits.
I'd like to introduce the concept of a Client Group. Client Group would
have:
* Roles - basically a role namespace
* Permissions - set of roles service accounts members inherit
* Scope - same as our current concept of scope
* Protocol Policies - common protocol configuration.
Each Client Group would have some default roles defined. i.e. roles
that allow a user to edit any client in the client group.
Each Client would have the same configuration options. They would be
able to have an additional set of roles, permissions, scope, and
overridable Protocol Policies.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
10 years
adapter-core and errors
by Thomas Raehalme
Hi,
I'm playing around with client-side error pages regarding Keycloak
authentication.
I have an Java EE web application utilizing error-page definitions in
web.xml. If authentication fails for a reason or another, shouldn't the
adapter-core enable the use of these error-pages?
At the moment all or most of the AuthChallenge implementations in
adapter-core call the setStatus method of the HttpFacade. This results in
blank responses with only the status being set. If sendError was used
instead then the default error-page handling would kick in.
Is there a reason I am missing why using setStatus instead of sendError in,
for example, OAuthRequestAuthenticator?
Best regards,
Thomas
10 years
user group admins
by Bill Burke
A few users have been asking about the ability to limit the admin to
managing a set of users in a group.
I know Pedro is doing permission work, but IMO, this type of thing needs
to be integrated and natural to the Keycloak UI as it would be a
fundamental feature.
Here's a proposal though based on my layout of User Groups in a previous
email.
Group Admins need to be able to:
* Manage group membership
* Manage users within a group to do things like reset credentials and
other user management actions.
* Grant roles to users within a group
* Add attributes to the group
* Grant roles to the group
So, if each User Group had its own Role Namespace, we could define one
or more roles that grant each of those permissions. i.e.
"group-membership-admin", "group-user-admin", "group-admin". If a User
Gruop has its own Role Namespace, it becomes really easy to compose
adminstrative access. So you could define individual "admin groups" and
grant users in those groups permission to manage one more groups.
If groups don't have their own Role Namespace, you need a way to
associate a role to each group admin permission.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
10 years
controlling which roles an admin can grant
by Bill Burke
One of things that we need to be able to do if we have the idea of a
"Group Admin" is to control specifically which role mappings an admin is
allowed to grant. One of the places this comes up currently is that if
an admin has the "manage-users" role, they can pretty much add any
permission they want to themselves and get access to the whole realm.
IMO, this is something we need now. It needs to be built into our admin UI.
So, how could we add the ability to control which roles an admin is
allowed to grant? Under the "Roles" menu option there would be a "Grant
Permissions" tab. Here, the admin can select a role and specify a list
of roles that can be granted if a user has that role.
Here's an example:
Let's say there are 2 sales applications "reporting" and "analytics".
Each of the apps has defined an "admin" and "user" role. We want to have
a developer manage user access to these systems.
1. Define "Sales Access Control Manager" role.
2. Go into "Roles" menu
3. Go to the "Role Granting Permissions" tab.
4. Select the "Sales Access Control Manager" role
5. Select and add the "reporting.user", "reporting.admin",
"analytics.user", and "analytics.admin" roles to the list of roles a
"Sales Access Control Manager" is allowed to grant.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
10 years
Password grant flow with client consent is bugged
by Paul Wolf
Hi guys,
I am currently evaluating Keycloak and so far I have only two complaints:
1. The implicit flow is not supported, but I already found a Jira issue for
that. How realistic is it that the feature comes with 1.7CR1?
2. When the client consent is needed for an application, which uses the
password grant flow, the flow fails all the time... Even if the consent has
been given. This seems an easy to fix bug. Will you fix that? Should I
write a fix and make a pull request?
Otherwise good stuff so far :)
Best regards,
Paul
10 years
roles vs. groups
by Bill Burke
Stian and I were having a conversation about roles, keycloak composite
roles, vs. groups. It seems that groups and roles are often confused
and one can be equivalent to the other. One common thread is the following:
Groups are user centric. Roles are permission centric.
"A group is a means of organising users, whereas a role is usually a
means of organising rights."
So, keycloak composite roles would be a way to organise rights for a set
of applications. For example, you might have a set of sales services,
each sales service has an "admin" and "user" role. You'd define a
"sales user" and "sales admin" role which would be a composite
containing the "admin" and/or "user" role of each sales service.
Conversely, a keycloak group would provide a way to organize a set of
users. You would create a group called "sales associates" add members
to it and then assign the roles members of the group can partake.
Really, in Keycloak with composite roles, you can have a role act as a
group. So, while groups and roles are logically the sameAdding the
concept of a group though provides distinction and clarity without
overloading the concept of a composite.
So, given that, Role mapping tab for Groups and Users would be named
"Permissions" instead of "Role Mappings". Each role would have a
"Rights" tab instead of the "Composite Role" concept we have now. That
might bring more clarity? Or will it just confuse concepts that are
going to be introduced by Pedro and his Authz stuff?
I'm also thinking that a Groups and Role Namespaces could be combined.
So a group would have a set of "Permissions" (role mappings) that are
automatically granted to user members. The group could also define a
set of "Roles" that apply to this group. So "Sales" could have a
"Manager" role. This "Manager" role would be a composite role that
assigns additional permissions. This would also allow us to define
default roles for
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
10 years
