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
6 years, 3 months
Re: [keycloak-dev] The browser property and the org.keycloak.testsuite.console.* UI tests
by Vaclav Muzikar
The UI tests are not supposed to work with "artificial" browsers - only the
real-life ones are supported.
UI tests are high-demanding on JS interpreter (PhantomJS nor HtmlUnit can
satisfy such demands) and moreover UI needs to be anyway tested with all
supported browsers (due to some differences between them). So it wouldn't
make much sense to run them with e.g. HtmlUnit.
Please see our HOW-TO-RUN [1] where are the instructions on some special
tests (like UI or adapters).
However, good point that we should add some check for supported browsers
before running the tests. I'll look into it.
[1]
https://github.com/keycloak/keycloak/blob/master/testsuite/integration-ar...
V.
On Wed, May 31, 2017 at 8:41 AM, Pavel Drozd <pdrozd(a)redhat.com> wrote:
> Dne 31.5.2017 v 08:31 Stian Thorgersen napsal(a):
>
> Ideally the console tests should work with HtmlUnit, but failing that they
> certainly need to work with PhantomJS.
>
> Pavel - any chance we can get the console tests working with HtmlUnit? If
> not I guess we need to set the default for the console tests to PhantomJS.
>
>
> We were focusing to run the tests mainly with real browsers. Vasek did you
> try to run the UI tests with HtmlUnit?
>
>
> On 30 May 2017 at 17:37, Alex Szczuczko <aszczucz(a)redhat.com> wrote:
>
>> Hi,
>>
>> I just lost a couple days to a really simple mistake when running the UI
>> tests. I didn't set -Dbrowser=firefox, so the headless WebDriver was used,
>> which produces a lot of impossible errors that I couldn't figure out at
>> all. To save the next person the same agony, I think there are two possible
>> solutions:
>>
>> 1. Define a default browser=firefox property in
>> testsuite/integration-arquillian/tests/other/console/pom.xml
>>
>> 2. Use a plugin to fail the build if the user has not defined the browser
>> property on the command line.
>>
>> Note that you need to enable a profile to run these tests
>> (-Pconsole-ui-tests), so this doesn't impact the project's normal mvn clean
>> install.
>>
>> Opinions on either of these options?
>>
>> Thanks,
>> Alex
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>
>
>
--
Václav Muzikář
Quality Engineer
Keycloak / Red Hat Single Sign-On
Red Hat Czech s.r.o.
6 years, 4 months
Fuse quickstarts
by Bruno Oliveira
For Fuse quickstarts, we have a some configuration steps to setup the
server like:
1. Set the Keycloak version
KEYCLOAK_VERSION=3.2.0.CR1-SNAPSHOT
2. Add Maven local repository
config:edit org.ops4j.pax.url.mvn
config:propset org.ops4j.pax.url.mvn.localRepository
file:///$HOME/.m2/repository
config:update
3. Install quickstarts artifacts
4. Install features
features:addurl
mvn:org.keycloak/keycloak-osgi-features/$KEYCLOAK_VERSION/xml/features
features:addurl
mvn:org.keycloak.quickstarts/keycloak-fuse-features/$KEYCLOAK_VERSION/xml/features
features:install keycloak-fuse-quickstarts
I was wondering if we could have a profile to make this process more
simple. Something like mvn clean install -Pfuse-server and you're good to
go. Do we want this? Or follow all these steps would be the goal as part of
the learning process?
6 years, 4 months
Assign group roles to specific users
by Shanon Levenherz
Hi there,
I’m looking to leverage Keycloak as the primary IdP for our SaaS platform. We have many tenants, each with sub-tenants and would like to provide them with the ability to administer themselves (including any applicable sub-tenants). Based on my current research, which includes the multi-tenant example in the GitHub repo, it appears that multiple tenants are supported via separate realms. My current thinking is that I’d like to use a single realm as I’d like for a platform administrator (like myself) to be able to manage all users in a single place, use a group hierarchy to support multiple tenants, and apply roles to specific users in a group to eg. administer the users or create a sub group for a new tenant.
Something like this:
REALM
|
|- User 1 (user-admin role)
|
|- Tenant 1 Group
| |
| |- User 1.1 (user-admin role)
| |- User 1.2
| |- …
| |- User 1.n
|
|- Tenant 2 Group
| |
| |- User 2.1 (user-admin role)
| |- User 2.1
| |- …
| |- User 2.n
| |
| |- Tenant 3 Group
| |
| |- User 3.1 (user-admin role)
| |- User 3.2
| |- …
| |- User 3.n
From the above we’re looking for:
* User 1 is the realm/platform administrator and has full control over all groups/users
* User 1.1 is the administrator for Tenant 1
* User 2.1 is the administrator for Tenants 2 and 3
* User 3.1 is the administrator for Tenant 3
I came across this thread <http://lists.jboss.org/pipermail/keycloak-user/2015-October/003359.html> and specifically this comment from Bill Burke:
>I like that idea. A better alternative might be that each group has an
>"user-admin" role. If a user has the "user-admin" role of the group, it
>can administer users in that group and assign roles defined in that
>group. One thing to really think about is, what about sub-groups. Can
>an admin of the parent group administer sub groups?
This post is from October 2015, so I’m curious if the ability to grant specific roles to specific users in a specific group has been implemented at all? I can’t find anything about it in the docs. I also just noticed this JIRA issue <https://issues.jboss.org/browse/KEYCLOAK-3168> but am not sure if it’s the same thing.
Please let me know if I can provide more information; I can provide a more complete description of my goals / requirements if that would help. Thank you!
Best,
Shanon
6 years, 4 months
The browser property and the org.keycloak.testsuite.console.* UI tests
by Alex Szczuczko
Hi,
I just lost a couple days to a really simple mistake when running the UI tests. I didn't set -Dbrowser=firefox, so the headless WebDriver was used, which produces a lot of impossible errors that I couldn't figure out at all. To save the next person the same agony, I think there are two possible solutions:
1. Define a default browser=firefox property in testsuite/integration-arquillian/tests/other/console/pom.xml
2. Use a plugin to fail the build if the user has not defined the browser property on the command line.
Note that you need to enable a profile to run these tests (-Pconsole-ui-tests), so this doesn't impact the project's normal mvn clean install.
Opinions on either of these options?
Thanks,
Alex
6 years, 4 months
Client role not supplied
by Marcel Hartwig
Hi,
I added a client (access type „confidential“) to a realm and added one role to the client. If I authorize against that realm with the correct client id, then the role is not supplied in the created access token. There are only role for the client „account“ supplied.
I am using key cloak from the latest docker image. Can anybody help me?
kind regards
Marcel Hartwig
6 years, 4 months
Reducing queries when initially loading a realm
by Stian Thorgersen
When we initially load a realm there are a lot of queries going to the db.
A lot of things are fetched lazily which results a large number of queries.
For example to load roles see https://issues.jboss.org/browse/KEYCLOAK-4964.
How feasible would it be to have a single query that fetches most things
(if not everything) when a realm is initially loaded? We could at least
fetch all realm data including roles and composites, but excluding clients
and users.
6 years, 4 months
Re: [keycloak-dev] [keycloak-user] Admin API Authz was Re: Keycloak Performance with large number of realms
by Bill Burke
I don't think I'm going to get it in for 3.2. But its coming.
On 5/26/17 6:11 AM, John D. Ament wrote:
> Bill,
>
> Is this something for 3.2?
>
> If I had to guess, based on what I"m seeing, yes, this would fix the
> underlying issues. I'm assuming that the association to the realms
> involves loading all of the realms from the database, and specifically
> granting for all of the existing permissions?
>
> John
>
> On Thu, May 25, 2017 at 11:11 PM Bill Burke <bburke(a)redhat.com
> <mailto:bburke@redhat.com>> wrote:
>
> [keycloak-dev] See below thread.
>
> I think that this problem might be solved by the work I'm doing. I'm
> changing the admin console to not include roles in the token. The
> Admin
> REST API instead will see that the token was generated for the console
> client (by "aud" claim) and look up role mappings directly. I have to
> do this anyways because with the new fine grain admin permissions, I
> don't want admins to have to change the scope of the admin console
> client every time a new fine grain permission policy is specified.
>
>
> On 5/24/17 11:07 PM, John D. Ament wrote:
> > Ok,so I think I have a fix working, but one question I have is
> whether the
> > existing PR for performance fixes will be getting merged in to
> 3.2? While
> > its a different problem it touches a lot of the same areas so it
> will
> > create some conflicts if either gets merged first. LIkewise if I
> have a
> > fix for this, would you consider it part of 3.2?
> >
> > It also seems to me that there's an inherent problem with how
> some of the
> > authorizations are done via Keycloak. Specifically, it seems
> that a client
> > authenticated to master is getting the roles from all realms,
> which is
> > really what is causing these problems. So while I can fix
> queries, without
> > a fix in that area this type of problem can keep popping up.
> >
> > On Wed, May 24, 2017 at 9:42 AM Stian Thorgersen
> <sthorger(a)redhat.com <mailto:sthorger@redhat.com>>
> > wrote:
> >
> >> That's used by composite roles. It is probably invoked on all
> roles in the
> >> realm. Could probably be fetched eagerly rather than lazy. Can
> you create a
> >> JIRA please?
> >>
> >> On 24 May 2017 at 12:11, John D. Ament <john.d.ament(a)gmail.com
> <mailto:john.d.ament@gmail.com>> wrote:
> >>
> >>> Stian,
> >>>
> >>> No, I don't believe its in that PR. This seems to be the table
> >>> "CHILD_ROLE" which has a large number of queries being
> executed against
> >>> it. But I'm not sure which entity that maps to in your
> persistence.xml
> >>>
> https://github.com/keycloak/keycloak/blob/master/model/jpa/src/main/resou...
> >>>
> >>> John
> >>>
> >>> On Wed, May 24, 2017 at 3:54 AM Stian Thorgersen
> <sthorger(a)redhat.com <mailto:sthorger@redhat.com>>
> >>> wrote:
> >>>
> >>>> Sure, please create a JIRA and link it to
> >>>> https://issues.jboss.org/browse/KEYCLOAK-4593
> >>>>
> >>>> Does this PR help:
> https://github.com/keycloak/keycloak/pull/3561?
> >>>>
> >>>> On 23 May 2017 at 15:04, John D. Ament
> <john.d.ament(a)gmail.com <mailto:john.d.ament@gmail.com>> wrote:
> >>>>
> >>>>> Stian,
> >>>>>
> >>>>> We just got a report of a new issue, not sure if its related
> to the
> >>>>> existing but I can create a ticket on your side if it makes
> sense.
> >>>>>
> >>>>> When accessing
> /auth/realms/master/protocol/openid-connect/token we are
> >>>>> seeing 3k SQLs being executed of this format:
> >>>>>
> >>>>> select compositer0_.COMPOSITE as COMPOSIT1_16_0_,
> >>>>> compositer0_.CHILD_ROLE as CHILD_RO2_16_0_, roleentity1_.ID
> as ID1_38_1_,
> >>>>> roleentity1_.CLIENT as CLIENT8_38_1_,
> roleentity1_.CLIENT_REALM_CONSTRAINT
> >>>>> as CLIENT_R2_38_1_, roleentity1_.CLIENT_ROLE as CLIENT_R3_38_1_,
> >>>>> roleentity1_.DESCRIPTION as DESCRIPT4_38_1_,
> roleentity1_.NAME as
> >>>>> NAME5_38_1_, roleentity1_.REALM as REALM9_38_1_,
> roleentity1_.REALM_ID as
> >>>>> REALM_ID6_38_1_, roleentity1_.SCOPE_PARAM_REQUIRED as
> SCOPE_PA7_38_1_ from
> >>>>> COMPOSITE_ROLE compositer0_ inner join KEYCLOAK_ROLE
> roleentity1_ on
> >>>>> compositer0_.CHILD_ROLE=roleentity1_.ID where
> compositer0_.COMPOSITE=?
> >>>>>
> >>>>> On Wed, May 10, 2017 at 12:40 PM John D. Ament
> <john.d.ament(a)gmail.com <mailto:john.d.ament@gmail.com>>
> >>>>> wrote:
> >>>>>
> >>>>>> Stian,
> >>>>>>
> >>>>>> Good news. Glad to see these things get prioritized. So
> far they
> >>>>>> look like they're matching the problems I'm running into,
> specifically
> >>>>>> around the whoami endpoint and overall number of SQLs (2800
> queries in one
> >>>>>> of my tests) and the total number of DB connections
> allocated within that
> >>>>>> one request (3200+).
> >>>>>>
> >>>>>> John
> >>>>>>
> >>>>>>
> >>>>>> On Wed, May 10, 2017 at 8:02 AM Stian Thorgersen
> <sthorger(a)redhat.com <mailto:sthorger@redhat.com>>
> >>>>>> wrote:
> >>>>>>
> >>>>>>> There are a number of issues around having a large number
> of realms.
> >>>>>>> We have a general issue open to support this:
> >>>>>>> https://issues.jboss.org/browse/KEYCLOAK-4593
> >>>>>>>
> >>>>>>> We haven't prioritized this in the past, but that has
> changed and we
> >>>>>>> would like to get this sorted out.
> >>>>>>>
> >>>>>>> There's a few more related PRs including the one you linked:
> >>>>>>> https://github.com/keycloak/keycloak/pull/3557
> >>>>>>> https://github.com/keycloak/keycloak/pull/3561
> >>>>>>>
> >>>>>>> On 10 May 2017 at 12:35, John D. Ament
> <john.d.ament(a)gmail.com <mailto:john.d.ament@gmail.com>>
> >>>>>>> wrote:
> >>>>>>>
> >>>>>>>> Hi,
> >>>>>>>>
> >>>>>>>> After enabling Keycloak and starting work on a multi-tenant
> >>>>>>>> application, it
> >>>>>>>> was noted that the admin console started to get very slow in
> >>>>>>>> keycloak.
> >>>>>>>> After some searching around, it seemed like this was an
> already
> >>>>>>>> reported
> >>>>>>>> issue [1] and a fix underway [2]. I was wondering if
> this fix would
> >>>>>>>> make
> >>>>>>>> it into 3.2?
> >>>>>>>>
> >>>>>>>> If additional testing is needed, I'd be happy to help
> out. Deleting
> >>>>>>>> 161
> >>>>>>>> realms with minimal clients and users took me 15 minutes
> via the
> >>>>>>>> REST API.
> >>>>>>>>
> >>>>>>>> [1]: https://issues.jboss.org/browse/KEYCLOAK-4858
> >>>>>>>> [2]: https://github.com/keycloak/keycloak/pull/4095
> >>>>>>>>
> >>>>>>> _______________________________________________
> >>>>>>>> keycloak-user mailing list
> >>>>>>>> keycloak-user(a)lists.jboss.org
> <mailto:keycloak-user@lists.jboss.org>
> >>>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-user
> >>>>>>>>
> >>>>>>>
> > _______________________________________________
> > keycloak-user mailing list
> > keycloak-user(a)lists.jboss.org <mailto:keycloak-user@lists.jboss.org>
> > https://lists.jboss.org/mailman/listinfo/keycloak-user
>
> _______________________________________________
> keycloak-user mailing list
> keycloak-user(a)lists.jboss.org <mailto:keycloak-user@lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/keycloak-user
>
6 years, 4 months
