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
7 years, 5 months
Suggestion and fix for e-Directory federation provider
by Tomas Tikovsky
Hello everyone,
im using e-directory federation ldap provider and came to this bug
KEYCLOAK-3099 <https://issues.jboss.org/browse/KEYCLOAK-3099> as i was
experiencing the same problem.
e-Directory sends guid attribute as byte[] so it needs to be declared as
binary the same way as its done for activeDirectory.
Sending simple diff to fix this issue if you consider this as helpfull.
Novell was acquired by microfocus and their product has been renamed to
netIQ eDirectory so i incorporated that change as well.
Another thing i noted were 2 incorrect attribute mappings in administration
console.
"username" -> "uid"
correct as long as users are enabled for linux (not default) otherwise cn.
So cn should work for more cases than uid.
"firstname" -> "cn"
wrong, should be "givenname"
Cheers
Tom
8 years
Performance improvements with large number of realms
by Gabriel Lavoie
Hi,
following
http://lists.jboss.org/pipermail/keycloak-user/2016-October/008032.html
that was discussed in the keycloak-user mailing list, I've been working in
the last few weeks on fixing performance issues for Keycloak setup with a
very large number of realms (tested with 500-600). As suggested by Stian, I
have changes to submit as pull requests that I want to discuss here first
to make sure they are acceptable.
With this improvements, the following issues were solved in our setup:
- Startup time reduced from more than 15 minute to under a minute.
- Login time to the admin console reduced from ~5 minutes to ~20 secs when
cache is being filled, to under 5 when cache is filled.
- Realm creation time reduced from ~1 minute to under 10 secs.
1 - Too many autoFlush checks by Hibernate and explicit em.flush():
>From what I see, the JPA entity model is very disconnected and many
entities are retrieved through their ID using NamedQuery. I'm not sure why
the mapping was done this way.
This causes Hibernate to make a autoFlush check for dirty entities on every
query, which is very CPU intensive. There are a few entities that can
benefit from having a Collection/Set to their child entities and use it
rather than a query to retrieve the required information. Also, with
explicit mapping, I foresee multiple explicit em.flush() that could be
removed when changing the data.
In this changeset I've covered only what was necessary for us, but there
are still a few areas that could be improved in my opinion:
https://github.com/glavoie/keycloak/commit/93c8056498e38ed075523f5b9b78db...
2 - Many missing index for FKs:
We are using an Oracle database and indexes are not created automatically
for FKs. I've added many but I'm not 100% sure if you want a new Liquibase
changeset for every changes that could go in a version or only one per
version. I still have one index to fix so don't take this as-is for now:
https://github.com/glavoie/keycloak/commit/7bb44b7dfeea31e663695218524a0d...
3 - Using Set rather than Collection with JPA entities:
When using a Collection, Hibernate will delete all rows and re-insert them
in the join table to update the content. This behavior was very slow and
visible with the "admin" composite role that points to roles for all realms
(through the different clients). This was slowing down a lot new realm
creation. When using a Set, Hibernate does a better job at tracking changes.
https://github.com/glavoie/keycloak/commit/9eb1bf013e80395affeec09625d5ee...
4 - "session" cache when testing for "hasRole" with a composite role:
The recursive search done KeycloakModelUtils.searchFor() can generate quite
a lot of hits on the Infinispan cache when trying to test for role. With
500 realms, we saw up to 1.5 millions hits on the realmsRevision cache just
to login to the admin console. I've added a in-memory cache of the
retrieved composite RoleModel list in the Infinispan RoleAdapter. As I
understand, every instance of a RoleAdapter is bound to a KeycloakSession
that can be seen as a transaction/request. Still relying on the delegate
object if the RealmAdapter is being invalidated.
This is the change that reduced the most the login time to the admin
console or the time to obtain a Bearer token for the admin API:
https://github.com/glavoie/keycloak/commit/0ab39670525315148761627e7d0f80...
5 - realmRevisions cache size:
In https://issues.jboss.org/browse/KEYCLOAK-3202, the realmRevisions cache
creation was moved from standalone.xml to Java code. With our current
Keycloak cluster we already added the eviction policy mentioned in the
ticket, but had to increase the size to 50000 to support our number of
realms. Having this size hardcoded in the Java code becomes a bit
inconvenient with the latest versions.
I didn't really fix the code as Stian mentioned that this part is being
heavily reworked. I would guess this has something to do with
http://lists.jboss.org/pipermail/keycloak-dev/2016-November/008397.html?
https://github.com/glavoie/keycloak/commit/6e3e7e8400da3440a743941980bad3...
Thank you!
Gabriel
--
Gabriel Lavoie
glavoie(a)gmail.com
8 years
Major themes for Keycloak 3.0?
by Thomas Darimont
Hello guys,
after having read that the next Keycloak release will be the last one
of the 2.x line I was wondering what the major themes for Keycloak 3.0 will
be.
Do you guys already have a roadmap (apart from the JIRA issues) or
information about major features / changes that are planned which you
could share with the list?
Would be very interesting to hear what's next :)
Cheers,
Thomas
8 years
migrating custom User Fed Providers
by Bill Burke
Not sure what to do about migration of custom User Fed providers. The
issue is around imported users as they have a federation link
specified. What I think I can do is check to see if the provider exists
for the linked user when queried, if it doesn't remove the user. This
would slowly remove old linked users. This is the easiest solution.
I can do something similar to LDAP in which if a UserStorage with same
provider id exists, then just port it to the new component model. If
there isn't a similar provider remove all users that are linked. This
becomes much harder as this isn't as simple as deleting the user from
the user table. I'll have to port all the queries that are executed
from JPA to JDBC when a user is removed.
More work....
8 years
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
8 years
next release should be 2.5 not 2.4.1
by Bill Burke
Next community release should be 2.5 not 2.4.1. Since we are removing
support for the User Federation SPI, this will break backward
campatibility with 2.4.0.Final. Point releases should not break
backward compatibility so, IMO, the next community release should be
2.5.0, not 2.4.1.
Bill
8 years
Admin console broken on master?
by Bruno Oliveira
Good morning,
I'm fixing the SSSD provider testsuite and noticed that User Federation
provider list is broken on master. It looks like some endpoints changed:
Error:
http://localhost:8081/auth/admin/realms/master/user-federation/providers Failed to load resource: the server responded with a status of 404 (Not Found)
http://localhost:8081/auth/admin/realms/master/user-federation/instances Failed to load resource: the server responded with a status of 404 (Not Found)
To reproduce it, based on commit 9dd4cbb40e1579394aa2a4618b2dc941fffa4af1 run:
1. mvn clean install -DskipTests=true && mvn -f testsuite/integration/pom.xml exec:java -Pkeycloak-server
2. Login and go to "User Federation"
The expected page is:
Resource not found...
We could not find the resource you are looking for. Please make sure the URL you entered is correct.
Go to the home page »
Am I the only one?
--
abstractj
PGP: 0x84DC9914
8 years
