Support for passing custom attributes from authenticators to login pages
by Thomas Darimont
Hello group,
are there any plans to support custom attributes to be passed from
authenticators to (login-) forms?
Concrete use-case is that I want to pass information
from a custom OTP authenticator down to the login-totp.ftl template.
Would be helpful if it were possible to pass custom attributes to the
create*Page(..) methods in org.keycloak.forms.login.LoginFormsProvider.
This would really ease customizations.
Other alternatives to pass data are:
- use some ThreadLocal storage within an Authenticator (set and clear) -
but this feels more like a hack
- custom page template and population logic in in a custom
FreeMarkerLoginFormsProvider (quite involved...)
Cheers,
Thomas
7 years, 11 months
Retrieve SAMLResponse after login
by Shiva Krishna
Hello,
I need to retrieve SAMLResponse as is after login using Keycloak. I
am able to retrieve SAMLPrincipal and other variables. But, I am not
able to see the parameter "SAMLResponse".
What is the way to get it?
Thanks,
Krishna S
7 years, 11 months
Online Export
by Marko Strukelj
I've been working on online Export functionality for Admin Console
(RHSSO-402).
Primary use case is to get core realm configuration with identity providers
and user storage, but no users, and optionally also excluding clients,
roles, and groups. As opposed to offline export (at startup time), which
can serve as a backup to restore the server, the idea of online export is
to help gather server configuration for troubleshooting so you can
reproduce / diagnose issues.
In terms of implementation the idea was first to just trigger the same
logic that creates a single JSON export during offline export, just filter
it to have less content, and no secrets. Then one would ssh to the server
to retrieve the file. But, that's a complicated workflow, especially when
dealing with a cluster of servers - how to know which server performed the
export?
A more usable implementation would be to download the exported JSON through
Admin Console. That does return a lot of information through a simple REST
request - anybody sees any issues here?
Another thing is to be careful that triggering an export does not slow or
block processing of other requests to the server. Current implementation
performs single file export within a single UserTransaction. With no users,
groups, roles, and clients there should be no issues here. But if exporting
many thousands of clients, that might interfere with normal operation of
the server.
One idea how to prevent that is to hardcode a fixed limit on instance count
for groups, roles, and clients. Export page would display client count next
to toggle button for exporting of client, and analogous for groups, and
roles. If count is greater than let's say 10k, the toggle for that
inclusion would be disabled. That will require an extra rest endpoint for
gathering these counts. To consistently enforce the limits the check would
have to be performed inside Admin REST export call as well.
Such implementation is more complicated but the whole workflow to get to
exported JSON is much better.
Any thoughts on such an approach?
7 years, 11 months
Proposal of RFC7636 (PKCE) support
by 乗松隆志 / NORIMATSU，TAKASHI
Hello.
I've been using keycloak 2.4.0.FINAL.
I've implemented codes for RFC 7636 for Proof Key Code Exchange experimentally.
(https://tools.ietf.org/html/rfc7636)
[Background: Why RFC7636 is necessary]
RFC 7636 is important for industries where high level security is required because it can prevent Authorization Code Interception and Substitution attacks for OAuth2.0. For example, it is required for both confidential and public clients in draft specification of Financial API of OpenID foundation. By implementing RFC 7636, keycloak will be used more widely.
[Description of the implementation]
My implementation is about 90steps for Authorization Server, 90steps for Client(only Servlet-OAuth), both excluded debug log codes in step counts. Please see the detail in below links.
* The implementation:
https://github.com/keycloak/keycloak/commit/9e3d2d1e5e8c3b30ddc9ccd5083ba...
It is based on 2.4.0.FINAL. Hope we'll refine and rebase it onto master branch for PR if you accept our implementation proposal.
* Design document:
https://github.com/Hitachi/contributions/wiki/Description-of-RFC7636-for-...
* PoC test:
I've validated my implementation and found worked well in following scenarios.
[1]
Flow: Authorization Code Flow
Client: RFC 7636 not supported
[2]
Flow: Authorization Code Flow
Client: RFC 7636 supported and operate properly
[3]
Flow: Authorization Code Flow
Client: RFC 7636 supported but operate illegally
(send invalid code_verifier to Token Endpoint)
For detail of PoC test, please see:
https://github.com/Hitachi/contributions/wiki/PoC-Test-Result-of-RFC7636
I am also willing to add tests to community’s testsuites according to the process as described in “Hacking on Keycloak”.
I've known that related ticket had already been issued as KEYCLOAK-2604.
https://issues.jboss.org/browse/KEYCLOAK-2604
Would you mind if I contribute this RFC 7636 support to Keycloak related with KEYCLOAK-2604 ticket ?
Best Regards
Takashi Norimatsu
Hitachi, Ltd.
7 years, 11 months
modeling map role fine grain permissions
by Bill Burke
Here's how I am going to model role mapping with fine grain permissions
in Authz service. The goal of this is to be able to limit or expand on
who can map specific roles. While we want to have a default that any
admin that has the "manage-users" role can map a role, we also want to
be able to do things like saying that an admin can map a specific role
if they belong to a group instead.
DEFAULT PERMISSIONS
* "permit all" policy. Just grants it.
* "Default Role Mapping Policy" Policy. This is an aggregate policy
that includes the "permit all" policy.
* "map-role" scope
* "Roles" resource. Associated scope is "map-role"
* "Default Role Mapping Permission" - scope permission that binds
"Roles" resource and "map-role" scope. The associated policy will be
"Default Role Mapping Policy".
* "manage-users" scope
* "Users" resource. Associated scope is "manage-users"
* "manage-users" policy that checks that "manage-users" role is present
* "Default Manage Users Policy". This is an aggregate policy that
includes the "manage-users" policy.
* "Default Manage Users Permission". scope permission that binds
"Users" resource and "manage-users" scope. The associated policy will
be "Default Manage Users Policy".
The above defines the default policy for mapping all roles. In the
admin console "Roles" section, there will be a "Default Admin
Permissions" tab. Here the user will be able to modify the "Default
Role Mapping Permission". The will be able to create and add new
policies for this permission. They will not be able to create any other
permission. In the "Users" section of the admin console, there will be
a "Default Admin Permissions" tab. Here the admin will be able to
modify the "Default Manage Users Permission"
FINE GRAIN PERMISSION
For more fine grain permissions, there will be a resource created per
role on demand. The admin will go to the role's console page and there
will be a "Admin Permissions" tab. The admin will say they want to add
a fine grain permission for that role and this will trigger these actions:
* A resource will be created specifically for that role with an
associated scope of "map-role"
* A scope permission will be created for that role resource and the
"map-role" scope. The "Default Role Mapping Policy" will be added
automatically to this permission.
THere will also be a "Admin Permissions" tab for each Group. The admin
will say they want to add a fine grain permission for that group and
this will trigger these actions:
* A resource will be created specifically for that group with an
associated scope of "manage-users"
* A scope permission will be created for that group resource and the
"manage-users" scope. The "Default Manage User Policy" will be added
automatically to this permission.
EVALUATION
When evaluating whether or not a role is allowed to be mapped by a
particular admin, this will be the algorithm:
1. If there is a resource for that specific role, evaluate that the
admin can use the "map-role" scope with that role's resource
2. If there is not a resource for that specific role, then evaluate that
teh admin can use the "map-role" scope with the "Roles" resource.
3. Evaluate if the admin can perform the "manage-users" scope on the
"Users" resource.
4. If Step #3 fails, then for each group see if the admin has the
"manage-users" scope for that group.
DEFAULT PERMISSIONS FOR ADMIN ROLES
By default, each admin role in the system "manage-users",
"manage-realm", etc... will have a resource ad scope permission created
for it as articulated above. The scope permission will be UNANIMOUS and
will also associate a role policy of that role in addition to the
"Default Role Mapping Policy". This additional role policy is basically
saying "Admins with 'manage-users' role and the admin must have this
role mapping as well". So, somebody with 'manage-users' role can't map
'manage-realm' unless they have that role themselves.
MORE FINE GRAIN PERMISSIONS
We also want to solve the case of allowing an admin to be able to map
specific roles for members of a specific group. To do this we'll add
another policy type called "Has Permission". Here you'll be able to
link a permission to a policy. So, to solve the use case for specific
roles for members of a specific group, we can edit the "map-role"
permission for a specific role and add a "Has Permission" that links to
the permission that the admin has "manage-users" scope for a specific
group. Hope I'm making sense on this one.
7 years, 11 months
testsuite still eats server-side logs in IDE
by Bill Burke
When running arquillian tests in the IDE, I'm still seeing no log
messages from the server. I had to set a breakpoint in JAX-RS code to
find out a Javascript parsing error.
7 years, 11 months
Extension for Health-Checks in Keycloak
by Thomas Darimont
Hello group,
I wrote a small Keycloak extension [0] that exposes a health endpoint
with health-checks as a RealmResource.
Health Checks can be contributed with a dedicated SPI.
(I took some inspiration from Spring Boot and Wildfly Swarm Health-Checks:
[1])
I'm now looking for general feedback and suggestions for additional health
checks
that could be added (infinispan?) - perhaps this could even be added to
Keycloak directly.
Some things I noticed:
1) RealmResourceProvider allows to expose custom JAX-RS resources on realm
level but
there is no equivalent for "global" Resources, e.g. something like
KeycloakResourceProvider / PublicResourceProvider is missing.
I wanted to add health-check for the whole Keycloak Server not just a
realm...
2) It seems that many requests lead to a database tx being commited via
org.keycloak.services.filters.KeycloakTransactionCommitter, even if there
is no write to the database.
Is this intended?
3) The keycloak-server BOMs didn't work for me. Even if I declare
<dependencyManagement>
<dependencies>
<dependency>
<groupId>org.keycloak.bom</groupId>
<artifactId>keycloak-spi-bom</artifactId>
<version>${keycloak.version}</version>
<type>pom</type>
<scope>import</scope>
</dependency>
</dependencies>
</dependencyManagement>
in my pom.xml I need to provide <version> settings to keycloak
dependencies, e.g.
<dependency>
<groupId>org.keycloak</groupId>
<artifactId>keycloak-server-spi-private</artifactId>
<version>${keycloak.version}</version>
</dependency>
which shouldn't be the case with a correct maven BOM.
I tried this with keycloak version 2.5.5.Final and 3.0.0.Final
Cheers,
Thomas
[0] https://github.com/thomasdarimont/keycloak-health-checks
[1]
https://wildfly-swarm.gitbooks.io/wildfly-swarm-users-guide/advanced/moni...
7 years, 11 months
