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, 3 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, 10 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, 12 months
Custom AdminEvents
by Dmitry Telegin
Hi,
The org.keycloak.events.* subsystem could potentially be of great use
for KeyCloak extensions (providers), especially for combinations of
JpaEntityProvider+RealmResourceProvider. Imagine we've implemented a
custom entity + REST resource, and we want to log create/update/delete
events for our entity, and then analyze log records in the event viewer
inside admin console.
Unfortunately, the event subsystem in its current state is not very
useful for the above. This is due to resource types hardcoded into
org.keycloak.events.admin.ResourceType enum. When logging events for a
custom entity, the only option is to leave resource type empty:
adminEvent .operation(OperationType.CREATE) .resource
Path(uriInfo,
myEntity.getId()) .representation(rep) .success();
This will obviously create a log record without a "Resource Type"
value, which is definitely not of great use.
It would be nice to have extensible ResourceType. One of the approaches
to the extensible enum problem is described here: https://blogs.oracle.
com/darcy/entry/enums_and_mixins
I think this could be applied here with minimal modifications.
ResourceType would become an interface, and there would be introduced
something like StandardResourceType enum, which would implement built-
in resource types as enum keys, and store custom types in a static map-
backed registry. A public static method would be introduced so that
extension authors could register their own resource types. In the
future, when (I hope) registering providers will be done with
annotations, this could be even more simplified and made purely
declarative.
The same approach could be applied to extending login events
(potentially useful for custom authenticators etc.) What do you think?
If everybody is OK with it, I can go on with JIRA and a PR.
Cheers,
Dmitry
10 years
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.
10 years
Configurable cookie names
by Martin Hardselius
What are your thoughts on configurable cookie names (or other visible
references to Keycloak)? I.e a way to override e.g "KEYCLOAK_SESSION" with
"MYCOMPANY_SESSION". The use case being
1. Product branding
2. Making it harder to figure out exactly which technology that's used
behind the scenes
Regards,
Martin
10 years
Custom Authenticator
by Yunus ÖNCEL
Hello;
i have described for MD5 passwort. now i write to database password of
users with MD5ed password.
it is possible, Can ı wrıte or change custom Authenticator with hilfe SPI?
Because i need another conditon to the correct user to the login.
thank you and sorry for my English
10 years
Allow adapter subsystem to just inject dependencies
by Marek Posolda
I've did some testing with hawtio on EAP 7. It works fine, however there
is one thing in our subsystem, which may improve integration a bit.
Hawtio doesn't use servlet security ( security-constraints in web.xml )
but they rely on JAAS, which is needed for JMX calls to be performed on
behalf of JAAS Subject. Hawtio WAR needs to have access to
keycloak-adapter classes (as it needs login modules for JAAS), however
it doesn't need subsystem to configure adapter. This is all handled by
JAAS login module.
In other words, it will be nice if subsystem can just inject
dependencies ( KeycloakDependencyProcessor ), but ignore adding
subsystem configuration ( KeycloakAdapterConfigDeploymentProcessor ).
The workaround I used was to add secure-deployment section to
standalone.xml with some dummy values, which are mandatory for
subsystem. It works, but it's really not too pretty IMO. Something like:
<secure-deployment name="hawtio.war">
<resource>does-not-matter</resource>
<auth-server-url>does-not-matter</auth-server-url>
</secure-deployment>
What will be nice is to have some of those possibilities:
1) Have subsystem to use some default values like "undefined" instead of
null . This is more a workaround as subsystem will still process the
KeycloakAdapterConfigDeploymentProcessor. However it's less work and it
will improve usability, so this will work just fine:
<secure-deployment name="hawtio.war" />
2) Tell the subsystem to ignore
KeycloakAdapterConfigDeploymentProcessor. Looks like more work, but
seems to be more proper solution than (1). I can think of:
2.a) some flag like:
<secure-deployment name="hawtio.war" ignore-deployment-config="true" />
2.b) Use different element like "deployment" instead of
"secure-deployment" . The "deployment" will inject dependencies, but
won't handle adapter configuration. So something like this will work:
<deployment name="hawtio.war" />
WDYT?
Marek
10 years
