Keycloak 3.2 release (and WildFly 11)
by Stian Thorgersen
The plan was to wait for WildFly 11, but it has been delayed significantly.
The new plan is to go back to WildFly 10 and release Keycloak 3.2 CR1 late
next week or early the following week.
7 years, 6 months
no stack trace in testsuite failed run
by Bill Burke
I performed the following in integration-arquillian testsuite
mvn -Dkeycloak.logging.level=debug clean install > out.txt 2>&1
My test is failing in AbstractKeycloakTest.afterAbstractKeycloakTest
while running TestCleanup loop. I'm getting a NullPointerException but
I can't seem to get the testsuite to output the stack trace. I do see
info level logs from this class, but no stack trace. Even if I add a
exception.printStackTrace(). The stack trace is empty.
Any ideas? This popped up before but just magically disappeared. Now
its back. The test failure only comes up in a full maven build. Can't
reproduce in IDE.
Thanks,
Bill
7 years, 6 months
Timeframe for 3.2?
by John D. Ament
Hi,
According to JIRA, 3.2 was supposed to be out 6/14. It seems like this may
be blocked on Wildfly 11's release which doesn't seem to have any dates.
I was wondering, would it be possible to have a 3.2 that didn't depend on
WF11?
John
7 years, 6 months
Assign existing roles to clients using a realm json file
by Hector Fernandez
Hi guys,
We want to assign roles to existing clients whenever we import the realm
json file. I tried several ways and checked your code looking for potential
json elements without any success.
I tried to define them using clientScopeMappings but it seems to be ignored:
```
"clientScopeMappings": {
"realm-management": [
{
"client": "hector-online-platform",
"roles": ["view-users"]
},
{
"client": "hector-online-platform",
"roles": ["manage-authorization"]
}
],
"broker": [
{
"client": "hector-online-platform",
"roles": ["read-token"]
}
]
}
```
I even tried to use the client element from the roles section in the realm.
But it fails whenever a role exists how it happens with the read-token.
```
"roles": {
"client": {
"broker": { "name": "read-token"},
...
}
```
In other words, we want to emulate what we do via admin console -- Clients
-> Choose a client --> Service Account Roles --> Choose a client then
assign a role like for broker the role read-token.
--
*<hector/>*
7 years, 6 months
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, 6 months
Branches for Node.js modules
by Bruno Oliveira
Good morning, I would like to propose the creation of 2 branches for
Node.js modules following the same approach from the quickstarts:
- latest: stable
- master: development
The initial motivation behind this, is to enable Travis to test these modules
against the latest change on Keycloak server.
Thoughts?
--
abstractj
7 years, 6 months
UMA 2.0
by Pedro Igor Silva
Hi,
I would like to review our UMA implementation (which is based on v1), and
get it aligned with the new version, v2.
One of the main changes we need is that now UMA has a specific grant type
that should be used by clients to obtain RPTs. The Authorization API no
longer exists.
Other changes are basically related with parts of the specs we are missing
that don't really bring issues for people already using UMA in Keycloak.
But new features and better UMA support.
My question is if it is reasonable to have those changes in 3.2.0.CR1 and
how ? For instance, if we decide to have those changes in, specially the
new UMA grant type, should we keep/deprecate the legacy Authorization API
for backward compatibility or just remove it from AuthZ REST API ?
Regards.
Pedro Igor
7 years, 7 months
JS policy performance improvements
by Jay Anslow
Hi all,
I'm using the JS Policy to evaluate resource permissions, but we've started to run into some performance problems when using large numbers of resources.
However, I've managed to improve the performance of the JSPolicyProvider, by caching the ScriptEngine (creating new bindings per evaluation) and compiling the code on policy update.
The "Obtaining Entitlements" operation is now ~5x faster than before, for my test setup (100 test runs, ~1100 resources, remote Postgres).
I'd like to merge my changes back to Keycloak, so I just wanted to check if the community would be interested in this change before I prepare a PR and create a JIRA issue.
Regards,
Jay
--
Jay Anslow, Product Development, CoreFiling Limited
http://www.corefiling.com
Phone: +44-1865-203192
7 years, 7 months
How to do my pull request successfully
by Jairo Henao
Hello comunity,
I am trying to understand the process to contribute to the project. A few
days ago I did my first pull request but some errors occurred while running
the tests. I do not understand the error very well, what is the process
here ?, Where can I find more information ?, This is the channel where I
should ask about this?
https://github.com/keycloak/keycloak/pull/4219
Thanks
7 years, 7 months
Re: [keycloak-dev] UMA 2.0
by Pedro Igor Silva
On Wed, Jun 14, 2017 at 6:11 PM, Alexey Kazakov <alkazako(a)redhat.com> wrote:
> IMO it's not a good approach in general to remove any public API without
> deprecating it first. Give users some time to adopt the changes :)
>
I won't dare to break you guys :)
>
> On 06/14/2017 05:50 AM, Pedro Igor Silva wrote:
>
> Hi,
>
> I would like to review our UMA implementation (which is based on v1), and
> get it aligned with the new version, v2.
>
> One of the main changes we need is that now UMA has a specific grant type
> that should be used by clients to obtain RPTs. The Authorization API no
> longer exists.
>
> Other changes are basically related with parts of the specs we are missing
> that don't really bring issues for people already using UMA in Keycloak.
> But new features and better UMA support.
>
> My question is if it is reasonable to have those changes in 3.2.0.CR1 and
> how ? For instance, if we decide to have those changes in, specially the
> new UMA grant type, should we keep/deprecate the legacy Authorization API
> for backward compatibility or just remove it from AuthZ REST API ?
>
> Regards.
> Pedro Igor
> _______________________________________________
> keycloak-dev mailing listkeycloak-dev@lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>
>
7 years, 7 months
