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
3 years, 10 months
Support rfc6750 Form-Encoded Body Parameter for access tokens in Keycloak
by Alexander Schwartz
Hi Keycloak Developers,
RFC6750 allows the access token to be submitted as part of a POST
request. I found that this is the only good way to do file downloads in
a JavaScript frontend.
https://tools.ietf.org/html/rfc6750#section-2.1
Excerpt: When sending the access token in the HTTP request entity-body,
client adds the access token to the request-body using the
"access_token" parameter. [...] Resource servers MAY support this method.
I don't remember a thread on this mailing list. The only place I could
find in the code was the User Endpoint that does this quite manually.
Currently Keycloak only supports the query parameter using
QueryParamterTokenRequestAuthenticator. A similar class will be needed
to support a Form Parameter. Like the
QueryParamterTokenRequestAuthenticator it will be part of the request
processing and it will not be configurable.
I'd like to open a JIRA issue for this as part of the Java Keycloak
Clients to track the efforts and thoughts.
Comments welcome!
Regards,
Alexander
--
Alexander Schwartz (alexander.schwartz(a)gmx.net)
http://www.ahus1.de
3 years, 11 months
Re: [keycloak-dev] [keycloak-user] [keycloak-spring-boot-adapter] disable security via application.properties file
by Alexander Schwartz
Hi keycloak developers,
I like this idea to be able to disable keycloak with a property. It
would be useful in the keycloak-spring projects that I've seen
The convention with other libraries is usually to add a property like
keycloak.enabled=false
to the spring boot configuration file and a
@ConditionalOnProperty(value = "keycloak.enabled", matchIfMissing = true)
to the spring autoconfiguration.
What do you think? If this is OK-ed, I'll open a JIRA and prepare a PR.
Thanks,
Alexander
Am 10.03.2017 um 16:49 schrieb Pavel Maslov:
> Hi all,
>
>
> Sometimes (for testing purposes) I need to disable keycloak security
>
> Is it possible to do so via application.properties file? Right now
> apart from the properties file I also have to comment out these
> dependencies and rebuild the project:
>
> compile 'org.keycloak:keycloak-spring-boot-adapter:2.5.1.Final'
> compile 'org.keycloak:keycloak-tomcat8-adapter:2.5.1.Final'
>
>
>
> Regards,
> Pavel Maslov, MS
> _______________________________________________
> keycloak-user mailing list
> keycloak-user(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user
--
Alexander Schwartz (alexander.schwartz(a)gmx.net)
http://www.ahus1.de
3 years, 11 months
Help with SSO
by Jorge M.
Hi,
In the past some systems inside my company were using a custom made sso
implementation that had the ability to do silent login among them.
On of that systems was completly refactored and is using keycloak for
authentication and authorization. Since than, we lost that silent login
feature with the other systems.
We assumed that it was ok to lost this feature for a while but now we are
trying to implement the silent login again.
So..summing up:
- System "A" is using keycloak with a realm "RealmA" with multiple clients
(modules) with sso between them.
- Other systems "B", "C" with their custom authentication and authorization
- We are using a custom federation on keycloak over the same users database
that is shared among all the systems.
What's the best practise to achieve sso between all the systems?
We are thinking about a proxy that detects if the user has a session on
some of the other systems and if that is true, we programatically create a
session on keycloak for a given (Is this possible with the API?).
Thank you,
JM
3 years, 11 months
Master bumped to 3.2
by Stian Thorgersen
3.1.0 release is on it's way and master is ready for 3.2 commits.
3 years, 11 months
Slow query performance for client with large data volume
by Alexandre Héroux
After some benchmark tests, a point comes where the performance of the JPA
repository become a bottle neck.
At this point, we are doing tests with:
- 21 560 391 COMPOSITE_ROLE rows
- 14 774 947 USER_ROLE_MAPPING rows
- 1 332 324 KEYCLOAK_ROLE rows
- 191 034 CREDENTIAL rows
- 191 034 USER_ENTITY rows
- 145 905 PROTOCOL_MAPPER_CONFIG rows
- 191 033 USER_REQUIRED_ACTION rows
- 30 187 PROTOCOL_MAPPER rows
- 5 031 CLIENT rows
- 10 054 REDIRECT_URIS rows
- 5 026 WEB_ORIGINS rows
- 6 AUTHENTICATOR_CONFIG_ENTRY rows
- 27 COMPONENT_CONFIG rows
- 6 IDENTITY_PROVIDER_CONFIG rows
- 41 AUTHENTICATION_EXECUTION rows
- 16 AUTHENTICATION_FLOW rows
- 4 AUTHENTICATOR_CONFIG rows
- 2 CLIENT_DEFAULT_ROLES rows
- 10 COMPONENT rows
- 39 DATABASECHANGELOG rows
- 1 DATABASECHANGELOGLOCK rows
- 1 DATABASECHANGELOG_EXAMPLE_EN rows
- 2 IDENTITY_PROVIDER rows
- 1 MIGRATION_MODEL rows
- 1 REALM rows
- 13 REALM_ATTRIBUTE rows
- 2 REALM_DEFAULT_ROLES rows
- 1 REALM_EVENTS_LISTENERS rows
- 1 REALM_REQUIRED_CREDENTIAL rows
- 11 REALM_SUPPORTED_LOCALES rows
- 5 REQUIRED_ACTION_PROVIDER rows
- 2 SCOPE_MAPPING rows
- 1 USER_ATTRIBUTE rows
1) When we are trying to load clients for migration/administration purpose,
Keycloak load each client one by one and perform lazy loading.
2) When the administrator delete a client, listeners are notified and some
of them reload all clients from the realm to load resources for each
occurrence from resourceServerStore one by one in a foreach loop.
With the current test volume, that take approximatively 1 hour 3 minutes to
:
- load reaml's clients into memory
- delete 11 clients
- delete 50 Users
- delete 340 user/role association
- delete 85 roles
- create 11 clients
- create 85 roles
- create 50 users
- create 340 user/role association
After some tuning we can optimize the query and surrounded services to take
only 5 minutes
*Impacted projects*
- keycloak-authz-policy-common
-
org.keycloak.authorization.policy.provider.user.UserPolicyProviderFactory
- keycloak-model-infinispan
-
org.keycloak.models.authorization.infinispan.CachedResourceServerStore
- org.keycloak.models.cache.infinispan.RealmCacheSession
- keycloak-model-jpa
- org.keycloak.authorization.jpa.entities.ResourceServerEntity
- org.keycloak.models.jpa.entities.ClientEntity
- org.keycloak.models.jpa.entities.ScopeMappingEntity
- org.keycloak.authorization.jpa.store.JPAResourceServerStore
- org.keycloak.models.jpa.JpaRealmProvider
- keycloak-server-spi-private
- org.keycloak.authorization.store.ResourceServerStore
- org.keycloak.authorization.store.syncronization.RealmSynchronizer
- org.keycloak.authorization.store.syncronization.UserSynchronizer
- org.keycloak.migration.migrators.MigrateTo2_1_0
- keycloak-services
- org.keycloak.authorization.admin.AuthorizationService
- org.keycloak.services.resources.admin.ClientsResource
3 years, 11 months
Step-up Authentication for Keycloak
by Thomas Darimont
Hello guys,
(longish email)
I have an idea how step up authentication could work with Keycloak that I'd
like to share.
Summary:
Clients require certain authentication steps by using scopes linked to
authenticators.
An authenticator would only be executed if it's scope is present.
An application can detect the current authentication level by inspecting
the
OIDC token or SAML assertions and request additional authentication if
necessary.
All that with (IMHO) a few little additions to Keycloak.
Idea:
The main idea is to have a new option 'Scope Param Required' for
authenticators as
there is for Roles. If 'Scope Param Required' is "On" then the
authenticator is
only executed if the scope parameter in the login URL contains the
authenticator
provider id, e.g. 'auth-otp-form'.
On the client / adapter side there could be a new configuration property
like
'additional-scopes' to specify a required authentication scope.
Optionally there could be an additional property 'required-claims:
auth-otp-form=true' to
indicate that a user can only access the app if the given claim is present.
Authenticators could also by default emit a 'User session note' with the
provider id to
indicate that they were executed, e.g. "auth-otp-form: true".
This could then be mapped via a protocol mapper into a OIDC token / SAML
response.
(for OIDC one could also configure an ACR level that is provided by an
authenticator,
but this wouldn't help for SAML)
With this clients could detect the executed authenticators based on the
claims in the
OIDC token (or ACR value) or SAML assertions and trigger reauthentication
if necessary, e.g. by sending a
redirect to the '/auth' URL with parameters 'prompt=login' and
'scope=openid+auth-otp-form'.
Example Scenario (OIDC):
In realm 'acme' we have two clients 'A' and 'B'.
To access 'A' username/password authentication is enough, but for 'B' one
needs to provide an
additional factor, e.g. an OTP token or code via SMS.
The auth-otp-form authenticator is configured with 'Scope Param Required=On'
B's adapter config contains 'additional-scopes: auth-otp-form'
First the user accesses 'A' and authenticates with username-password. Then
the user tries
to access 'B'. 'B' detects that the current OIDC (access/ID) token doesn't
contain the
required claim 'auth-otp-form'. Thus it sends a redirect as mentioned
above, e.g.:
http://localhost:8081/auth/realms/acme/protocol/openid-connect/auth?clien...
Keycloak would now detect that it needs to execute the OTPForm authentiator
based on the scope
parameter auth-otp-form which will prompt the user for OTP input.
Note that the user still would need to provide his username/password. If
one would be able to skip
that (since the user is already authenticated via username/password) one
could think of an additional
parameter like 'auth_mode=step_up' to signal Keycloak that it should only
verify credentials that have not yet checked.
In this case it would skip the username / password authenticator and jump
to the OTP form.
What do you think?
Cheers,
Thomas
3 years, 11 months
