Scope parameter support
by Marek Posolda
It seems that for OIDC certification, we will need more proper support
for "scope" parameter. There are few tests from OIDC conformance
testsuite, which end with WARNING because of issues with "scope" parameter.
SUMMARY OF SPECS REQUIREMENTS
-----------------------------
- In OIDC specification, the "scope" parameter is actually REQUIRED. And
you must add the scope value "openid" to all authorization requests.
Hence if you don't use "scope=openid", the request is pure OAuth2
request, but it's not OIDC request.
In https://issues.jboss.org/browse/KEYCLOAK-3147 we discuss the
possibility that we should change our adapters and add "scope=openid" to
all requests, and also the possibility to remove IDToken if it's not
OIDC request (and maybe other things). However it may be potential issue
with backward compatibility with older adapters (which don't add
"scope=openid" at all).
- OIDC also prescribes the "scope=offline_access", which you use if you
want offline token. We actually support this as we have realm role
"offline_access", with scopeParamRequired=true . So this role is applied
just if it's included in scope parameter. This is our only support of
scope param actually. ATM we reference the realm roles by name (role
name must match the value of scope parameter) and clientRoles by
"clientId/roleName" . So it's not very flexible and won't work well in
the future with role namespaces.
- OIDC defines four other scope values, which we don't support, with the
meaning like this:
profile
OPTIONAL. This scope value requests access to the End-User's
default profile Claims, which are: "name", "family_name", "given_name",
"middle_name", "nickname", "preferred_username", "profile", "picture",
"website", "gender", "birthdate", "zoneinfo", "locale", and "updated_at".
email
OPTIONAL. This scope value requests access to the "email" and
"email_verified" Claims.
address
OPTIONAL. This scope value requests access to the "address" Claim.
phone
OPTIONAL. This scope value requests access to the "phone_number"
and "phone_number_verified" Claims.
- Not directly related to scopes, however OIDC also has one parameter
"claims" described in section
http://openid.net/specs/openid-connect-core-1_0.html#ClaimsParameter .
This allows to define some additional claims, which should be included
in IDToken or UserInfo endpoint in addition to claims specified by
"scope" parameter.
HOW TO IMPLEMENT?
-----------------
My current thinking is, that we will have 2 kinds of protocolMappers and
roles.
1) "Always applied" - Those roles/protocolMappers are always applied to
token even if they are not specified by scope parameter.
2) "Applied on demand" - Those roles/protocolMappers are applied just if
they are specifically requested by scope parameter
For roles, we already have that with "scope param required" flag defined
per roleModel. However for protocolMappers we don't have it yet.
IMO We will also need some more flexible way to specify how the value of
scope parameter will be mapped to roles and protocolMappers. For example
if I use "scope=foo", it can mean that I want realm role "foo1", client
role "client1/foo2" and protocolMapper for "firstName" and "lastName" etc.
I can see 2 possibilities:
a) Configure allowed scope param separately per each role / protocolMapper
If some role has "Scope param required" checked, you will have
possibility to configure list of available values of scope parameter,
which this role will be applied to. This will be configured per-each
role separately.
Example: I have realm role "foo" . I check "scope param required" to
true. Then I will define "scope param values" : "bar" and "baz". It
means that if someone uses parameter "scope=bar" or
scope=baz", then role "foo" will be applied to token. Otherwise it won't
be applied.
Similarly it will be for protocolMappers. We will add switch "Scope
param required" to protocolMappers and we will use list of available
values of scope parameter, which is configured per each protocolMapper
separately.
b) Configure scope parameter in separate place
We will have another tab "Scope parameter config" (or maybe rather
another sub-tab under existing "Scope" tab). Here you will define the
allowed values of scope parameter. For each allowed value, you will
define protocolMappers and roles to apply. Hence for example for
"profile" scope parameter, you will define all protocolMappers for
corresponding claims ( name, family_name, ...) here.
We will still need "scope param required" switch for protocolMappers in
case (b).
My current thinking is to go with (a). So when you go to some role (or
protocolMapper) in admin console you will see if you need scope
parameter and what are available values of scope parameter to request it.
WDYT? Another ideas?
Marek
9 years, 2 months
Docker Protocol?
by Josh Cain
Hi All,
We want to use Keycloak as the IDP/Token issuer for authentication with a
docker registry as per the specification found here:
https://docs.docker.com/registry/spec/auth/
I've implemented a Protocol Mapper in Keycloak that successfully uses the
IDP to perform a login against a registry/docker client. Is this something
that the team is interested in building into the product? If so, I'd be
happy to push back upstream.
Josh Cain | Software Applications Engineer
*Identity and Access Management*
*Red Hat*
+1 843-737-1735
9 years, 9 months
Scope Param with Keycloak
by Tomas Cerny
Hi all,
I am trying to use the scope param with keycloak, which is part of the open
id
http://openid.net/specs/openid-connect-core-1_0.html#ScopeClaims
Here is an sample URL (from
https://openid.net/specs/openid-connect-basic-1_0.html#AuthenticationRequest
)
Which is
https://server.example.com/authorize?
response_type=code
&client_id=s6BhdRkqt3
&redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb
&scope=openid%20profile
&state=af0ifjsldkj
note the state param there
with keycloak this is my auth URL:
http://127.0.0.1:8080/auth/realms/example/protocol/openid-connect/auth?cl...
When I pass scope param, then it is ignored.
Does keycloak support scope param? Can I intercept it to make a custom
handler? (e.g. lookup DB data)
Sample Use Case: Keycloak has my custom UserFederation provides where I
issue user lookup to my SQL DB, and determine access, next basing on the
scope I like to post back to the app roles relevant to the scope param.
I know keycloak has static roles, but I need it contextual, such as - user
is master in scope = A, but reader in scope = B. Since the range of scopes
is dynamic and large, the use of client-ids is not sufficient.
I assume the scope can help me solving situation such as am I owned of an
object?
I did days of debugging keycloak code and cannot find much even thought
there is OAuth2Constants.Scope but may be that is something different?
and I seem some dead sample here: FishEye: changeset
d309fab8251d95f50f94c77e4d08e6e8c2977994
<https://source.jboss.org/changelog/Keycloak?cs=d309fab8251d95f50f94c77e4d...>
The alternative OpenAM supports scope param it - OpenAM Project - About
OpenAM <http://openam.forgerock.org/>
Thanks, Tom
Here a forum public users.
https://developer.jboss.org/message/934762#934762
9 years, 10 months
new provider deployer working on branch!
by Bill Burke
I've implemented a Keycloak provider deployer and it works great. I
re-implemented the JPA User Storage SPI example. The provider is now a
@Stateful EJB and EntityManager access is all managed by
@PersistenceContext. The example now looks really simple and elegant
rather than the crap I mentioned before. Would not have worked without
the JTA integration I did (see previous email). Things left to do:
* hot deployment. Pretty sure I can implement this
* Make sure things work in WARs and EARs.
* Also thinking of defining a @KeycloakProvider annotation that you can
use on your ProviderFactories. This would remove the need to specify a
META-INF/services file and the annotation could be scanned for at
deployment. Would work like this:
@KeycloakProvider(UserStorageProviderFactory.class)
public class MyProvider ... {
}
As a side note, one thing I could look into is the ability to use
@Inject of a KeycloakSession. Developer could then write entire web
applications that are deployed separately and worked with the keycloak
API directly. @Inject KeycloakSession would work similarly to
@PersistenceContexts EntityManager. KeycloakSessions would be
associated with a transaction. This will give us nice integration with
Java EE and give a lot of power to developers wanting to extend keycloak.
9 years, 11 months
Client Self-Registration and Administration Plugin
by Erik Berdonces Bonelo
Hello,
I’m working at the moment in a Master Thesis project in TU Berlin where we are using Keycloak for Authentication and Authorisation purposes.
We are planning on extending Keycloak in order to provide users a way to register clients/applications by themselves into the platform, while having an admin overseeing the system.
This would mean that as a user, if I have the proper rights I should be able to create and manage my own clients. With, this it comes the idea of ownership, as this would mean that a client ownership could be transferred to someone else.
Also, the admin should be able to accept, revoke and delete the clients and requests to create clients in my Keycloak.
At the moment the only option would be giving the permission to create clients to the user, but that would allow to change ANY of the possible clients.
Then, I have two questions:
1. Would it make sense to integrate this to the Keycloak core?
2. If it doesn’t make sense to merge it in the core, is there any plugin system to extend Keycloak’s core? I’ve seen a discussion related to a plugin system in GitHub but there is no outcome yet. We would rather like to integrate it with Keycloak itself, otherwise the other option would be creating a client that uses Keycloak’s REST API to manage the clients remotely.
Thanks a lot in advance!
—
Best Regards,
Erik Berdonces Bonelo
9 years, 11 months
Edit value contained in NameID field of SAML response
by Rashmi Singh
I have a keycloak app that calls an external TokenValidator for
authentication. This TokenValidator returns a SP specific username value. I
want my SAML response to contain this value in the NameID field. My
question is how do I edit the SAML response to change the value in NameID
field to this value?
Any insight into how to edit the NameID field in the SAML response?
10 years
No more keycloak-server.json
by Stan Silvert
Now that changes for KEYCLOAK-3196 are merged, everything you used to
configure in keycloak-server.json will now be configured in
standalone.xml, standalone-ha.xml, or domain.xml.
If you need to make a change to the default keycloak-subsystem
configuration, you will need to edit this file:
https://github.com/keycloak/keycloak/blob/master/wildfly/server-subsystem...
This file contains a single multi-line property containing the subsystem
xml declaration. Maven filtering is used to read this property and
inject it everywhere it needs to go. Editing this file will also take
care of propagating it to the distributions like server-dist and demo-dist.
Also, you need to create CLI commands for each change by editing this file:
https://github.com/keycloak/keycloak/blob/master/wildfly/server-subsystem...
This CLI snippet is used in the scripts required by the overlay
distribution.
We have always had the problem that whenever someone changes
keycloak-server.json, they forget to make corresponding changes that
affect the various distributions. With the switch to standalone.xml, we
now have just these two files to edit instead of five or six.
Below, I'm pasting part of the asciidoc documentation I'm working on for
this. It explains how to configure SPI's in standalone.xml. Also, if
someone can tell me if what I said about default-provider is accurate
I'd appreciate that:
----------------------------------------------------------------------------------------------------------------------------------------------------------
All elements in an SPI declaration are optional, but a full SPI declaration
looks like this:
[source,xml]
----
<spi name="dblock">
<default-provider>mongo</default-provider>
<provider name="jpa" enabled="true">
<properties>
<property name="lockWaitTimeout" value="800"/>
</properties>
</provider>
<provider name="mongo" enabled="true">
<properties>
<property name="lockRecheckTime" value="2"/>
<property name="lockWaitTimeout" value="600"/>
</properties>
</provider>
</spi>
----
Here we have two providers defined for the SPI `dblock`. The
`default-provider`
is listed as `mongo`. However it is up to the SPI to decide how it will
treat
this setting. Some SPIs allow more than one provider and some do not. So
`default-provider` can help the SPI to choose.
Also notice that each provider defines its own set of configuration
properties.
The fact that both providers above have a property called
`lockWaitTimeout` is just a
coincidence.
The type of each property value is interpreted by the provider. However,
there
is one exception. Consider the `jpa` provider for the `eventStore` API:
[source,xml]
----
<spi name="eventsStore">
<provider name="jpa" enabled="true">
<properties>
<property name="exclude-events" value="["EVENT1",
"EVENT2"]"/>
</properties>
</provider>
</spi>
----
We see that the value begins and ends with square brackets. That means that
the value will be passed to the provider as a list. In this example,
the system will pass the
provider a list with two element values _EVENT1_ and _EVENT2_. To add
more values
to the list, just separate each list element with a comma. Unfortunately,
you do need to escape the quotes surrounding each list element with
`\"`.
10 years
Securing realm resources with custom admin roles
by Dmitry Telegin
Hi,
While developing a complex production-grade KeyCloak extension I've
faced the following problem. Let's say the extension provides several
custom realm resources plus the relevant parts of admin console GUI. A
user should be able to access this functionality only if he/she has
corresponding roles: one role for read-only access, another one for
full operation. The "domain-extension" example does solve the similar
problem, but in a very simplistic way: the user is only checked against
the built-in "admin" role. A real-world example would likely feature at
least two custom roles, different from the built-in ones. Implementing
this with the current KeyCloak version turned out to be a rather
complex problem. To demonstrate it, I've created the following example.
Throughout the example, two custom roles are used, "view-hello" and
"manage-hello":
https://github.com/dteleguin/custom-admin-roles
The problem could be broken down into three parts:
1. Creating roles. Imagine the instructions: "After you have installed
the extension, please go to Clients, select the master-realm client,
add view-hello and manage-hello roles, then go to Roles, select admin,
add the above roles to it. Repeat for each and every realm you've
already created, but this time also with the realm-management client
and realm-admin role. Don't forget to do the same for every new realm
you add" - this is totally unacceptable if we are speaking of high
quality software. In the example, this is fully automated (see
HelloResourceProviderFactory::postInit). Adding roles to the newly
created realms has become possible with the recent introduction of
RealmPostCreateEvent.
2. Client-side authorization. The GUI elements in the admin console
should be shown only to the users having corresponding roles. There is
the global "access" AngularJS object, instantiated by GlobalCtrl and
used everywhere in the admin console; it would be quite natural to use
the same semantics for custom roles. In the example, AngularJS
decorator mechanism is used to augment the "access" object with
additional getters, reflecting custom role grants. Unfortunately, by
some reason decorating GlobalCtrl directly doesn't work, so we have to
decorate all the controllers (as "$controller") and then select
GlobalCtrl. I'm not sure if it's a KeyCloak or AngularJS issue, since
there's not much information on the net about using decorators with
GlobalCtrl.
3. Server-side authorization, i.e. checking user roles in service
methods of realm REST resources. This is particularly cumbersome, and
imposes an ugly restriction on resource methods - all of them are
required to have @Context HttpHeaders in the argument list. Otherwise
it would be impossible to extract a JWS token and to deduce a realm to
authorize against. The only workaround I see is to move all the service
methods into a sub-resource, so that processing HttpHeaders and auth
setup could be done once, while instantiating sub-resource (like this
is done in o.k.services.resources.admin.AdminRoot). This is especially
frustrating because any custom realm resource is a sub-resource by
default, so there is no reason why it couldn't obtain a HttpHeaders
object from its parent resource upon construction.
Conclusion: a simple and natural requirement for an extension, which is
to have custom admin roles, turns into a lot of boilerplate code, most
of which is present in either form in KeyCloak. Could this
functionality be simply exposed to extensions? Ideally, this should be
a one-liner for extension authors, since the only information needed is
the name of the role(s). I could see it like this:
- an extension declares the roles. Considering possible introduction of
@KeyloakProvider annotation, this could be an annotation parameter, or
a separate annotation;
- KeyCloak takes responsibility for creating roles in both existing and
newly added realms;
- GlobalCtrl augments the "access" object with the relevant getters;
- upon creation, realm resources receive
an o.k.services.resources.admin.AdminAuth-like object, which could be
further decorated, or used as is.
What do you think?
Dmitry
10 years
