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, 3 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.
3 years, 5 months
Error deploying Keycloak over MariaDB
by Tech
Hello,
I need to deploy keycloak over MariaDB:
I downloaded the latest version of Keycloak, 2.5.1 and I want to connect
to my DB running over MariaDB.
I'm using the same JDBC driver that I also use for other applications:
I start WildFly, I open the console and I go to Deployment.
I load the mariadb-java-client-1.5.5.jar.
The driver is correctly loaded.
I shutdown the server, I edit the standalone.xml and I add:
<datasource jndi-name="java:jboss/MariaDBDS" pool-name="MariaDBDS">
<connection-url>jdbc:mariadb://localhost:3306/KcTbs</connection-url>
<driver>mariadb-java-client-1.5.5.jar</driver>
<driver-class>org.mariadb.jdbc.Driver</driver-class>
<security>
<user-name>KcUsr</user-name>
<password>KcPwd</password>
</security>
<validation>
<valid-connection-checker
class-name="org.jboss.jca.adapters.jdbc.extensions.mysql.MySQLValidConnectionChecker"/>
<validate-on-match>true</validate-on-match>
<background-validation>false</background-validation>
<exception-sorter
class-name="org.jboss.jca.adapters.jdbc.extensions.mysql.MySQLExceptionSorter"/>
</validation>
</datasource>
I restart the server and I can see the new datasource.
I open it, I go to "Connection" and I receive the following error when I
try to test the connection:
12:12:51,248 ERROR [org.jboss.as.controller.management-operation]
(management task-7) WFLYCTL0013: Operation ("test-connection-in-pool")
failed - address: ([
("subsystem" => "datasources"),
("data-source" => "MariaDBDS")
]) - failure description: "WFLYJCA0040: failed to invoke operation:
WFLYJCA0047: Connection is not valid"
Any idea?
3 years, 5 months
Action tokens
by Hynek Mlnarik
Following up e-mail sent earlier today by Marek, I'm sending info on action tokens.
Action token is a concept intended as a time-boxed ticket for a bearer to perform a single operation like reset password. They will be used for one-time actions that can be potentially delayed or executed outside of current authentication flow.
The idea is to implement them as signed JWT tokens where the allowed operation will be specified in token type field. Action tokens will support expiration definable per action (different expiration for e.g. verify e-mail and reset password, or customizable expiration when sent from admin interface). JWT allows both signing and supports custom fields that can be used by the operation to supply additional arguments and to implement prevention of reusing the token once the operation would be performed already.
Initially it seemed that a distributed cache would be needed to prevent reusing the token for the second time. After thinking it over however it turned out that currently all required cases can be prevented by introducing a field like "last timestamp of the password change" into a reset password token that is checked and operation is only allowed if the token value is equal to the one from database.
So far the initial implementation covers token in reset-password e-mail. Cache-independent version of action tokens is available here [1].
--Hynek
[1] https://github.com/hmlnarik/keycloak/tree/mposolda--cross-dc2-replaced-hm...
3 years, 5 months
OIDC Secret Encryption
by Caranzo Gideon
Hi,
Is there a way to extend Keycloak so that we can encrypt OIDC secret? Or is there an existing feature for this?
Thanks,
Gideon
________________________________
This message and any attachments are intended solely for the addressees and may contain confidential information. Any unauthorized use or disclosure, either whole or partial, is prohibited.
E-mails are susceptible to alteration. Our company shall not be liable for the message if altered, changed or falsified. If you are not the intended recipient of this message, please delete it and notify the sender.
Although all reasonable efforts have been made to keep this transmission free from viruses, the sender will not be liable for damages caused by a transmitted virus.
3 years, 5 months
Some questions from a Keycloak talk
by Thomas Darimont
Hi group,
yesterday I gave a talk about Keycloak at the Javaland conference in
Germany.
The talk was well attended (~100) and I got a lot of questions at the end.
Some of the things people asked for were:
Q1: Will Keycloak support JWT with EC signature?
Q2: How to integrate Keycloak login forms or use custom login components
in Single Page Applications?
Q3:Will the Spring Boot Adapter make use of the Spring Security Adapter
instead of
using the Servlet Container specific implementations?
Q4: Is there a reserved path for custom REST-Resources to avoid
clashes with Keycloak REST-Resources in new releases?
Q5: Is there a documentation of all exposed Resource paths in Keycloak
(appart from the REST API Docs)?
Q6: Are there some guidelines for protecting a Keycloak server?
Q7: The RH-SSO commercial offering states that it is based on the Open
Source
Community Edition of Keycloak and that on can get patches and support.
Will those patches (e.g. for security vulnerabilities) also end up in the
Community Edition?
In addition to those questions. Some people asked for a list of services
using Keycloak.
Since not many people talk about that they are using Keycloak
I found a nice way to find some Keycloak installations with a simple
google search, just try:
inurl:auth inurl:realms inurl:protocol
Cheers,
Thomas
3 years, 5 months
logout social providers?
by Bill Burke
If a user logs in through Facebook or links to Facebook in the account
service, should we logout the Facebook when the user logs out? My
thinking is that we should otherwise that machine will keep facebook
logged in.
Bill
3 years, 5 months
