Entitlement API, role based Policy, forbidden
by Sven Thoms
I have users in my realm that I have assigned realm roles to:
realm roles: Master, Apprentice
one such user is
test_user
roles: uma_authorization, Apprentice
When I enable authorization on a client and
1. add a resource besides the default resource to it, say "Second Resource"
2. under Policies - Roles a role-based policy referencing the realm role
Apprentice that my user belongs to
Using the test user’s acess_token gotten from the realm token endpoint:
curl -X POST \
-H "Content-Type: application/x-www-form-urlencoded" \
-d "client_id=admin-cli&username=test_user&password=password&grant_type=password"
\
https://mykeycloak.domain/auth/realms/myrealm/protocol/openid-connect/token
and checking the entitlement API response for the client’s id and using the
bearer access token of the user as well as the payload for the Second
Resource, I always get status code forbidden
curl -v -X POST \
-H "Content-Type:application/json" \
-H 'Authorization: bearer userbearerrertoken' \
-d '{"permissions":[{"resource_set_name:"Second Resource"}]}' \
https://mykeycloak.domainauth/realms/myrealm/authz/entitlement/my_client_id
For the Default Resource, all is fine and I get back an RPT.
Am I missing something regarding the user’s needed roles? According to the
documentation, the role-level permission for the Second Resource should
lead to the user being authorized to access the second resource if any
realm role in a role-based permission for a resource holds.
I am using keycloak 2.5.1.
7 years
OpenID Connect: userkey instead of username
by Tech
Dear experts,
we are working with an application that implements with a plugin OIDC.
What we detected is that when we run the authentication for a local user
present into Keycloak, the remote username appearing on the application
is the Keycloak's userKey instead of the Keycloak's username.
Is there anything that we should do to retrieve instead the username?
Thanks!
7 years
[authz] introducing security holes by mistake
by Bill Burke
In Authz you can define a permission that applies only to scope or only
to resource or only to a specific resource type. These are different
ways to define default behaviors. Also, you can define multiple
permission definitions for the same scope, resource, or combination of
both. You can do this multiple times.
This bring me to the point of this email. Isn't it too easy to screw
things up? Somebody could add a more constrained permission that
overrides default behavior and not realize that they've screwed things
up. Somebody could add an additional permission for a resource and not
realize there was already an existing one. It all seems very error prone.
I'm wondering if we should constrain this a bit more. For instance,
what if each resource-scope pair is unique? That is, you can't define
more than one permission for each resource-scope pair. This goes for
resource only, resource type only, and scope only permission definitions
too. That way, when somebody goes to define a permission, they see all
policies that are currently applied.
I also think that any resource-scope permission definition should
automatically inherit from permissions defined in resource-type,
resource, or pure-scope permission definitions. You should see these
inherited permissions in the "Applied Policies" when you create the
resource-scope permission. Then admins can remove the inherited
permissions they want to.
Bill
7 years
Authentication sessions prototype
by Marek Posolda
We started on the work for cross-dc support. One of the initial steps
for this is to improve current "sessions" cache to avoid unnecessary
communication between data-centers.
Currently ClientSessionModel is created at the start of the
authentication and every step in the authentication flow means some
writes to the ClientSessionModel. So the idea is, to create separate
provider and separate "Authentication session", which will be used just
during the authentication time. The advantage is, that authentication
usually doesn't take lots of times and can be tracked with browser
sticky session. So typical deployment will be able to rely on sticky
sessions and won't need the authentication sessions to be replicated
across different data centers.
I have some prototype already working in the branch [1]
What I did so far is:
- Created separate provider AuthenticationSessionProvider and separate
AuthenticationSessionModel
- During start of authentication (at the time of request from OIDC or
SAML application is sent to Keycloak), the AuthenticationSession is
created instead of old ClientSession. For now, there is cookie with the
authentication-session-id created. This one is used for track sticky
sessions
- AuthenticationSession is used for the time of authentication,
requiredActions and consents. The UserSession is now created after the
consent is confirmed (before redirecting to OIDC/SAML application). Some
minor changes were needed in the authentication SPI, requiredActions
SPI, forms SPI to use AuthenticationSession instead of ClientSession and
to not use UserSession.
- For now, UserSession still tracks the list of clientSessions of the
authenticated clients. But those authenticated client-sessions are now
saved just as an attachment of userSession entity, so there is just
single infinispan entity for userSession and not additional entities for
clientSessions.
This is just another step. Hopefully we will be able to get rid of
"clientSession" at all and keep just list of the client IDs in the user
session. This would require some additional refactoring as we currently
have some data in clientSession, which are used during refresh and
during logout. But this will be done later though (eg. ensure that roles
and protocolMappers will be available in refreshToken. Maybe support for
OIDC logout on adapters side similar to what we have for SAML as
currently we track the HttpSession ID as the note in clientSession and
this one is needed to logout HttpSession on the adapter side etc)
- There are some improvements done around back / forward / refresh
button. We discussed this in another thread. For now, the aim is to
never display the Keycloak page with "We're sorry. An error occurred and
please login through your application" but rather display the more
friendly "Page is expired" with the links to the start of
authenticationFlow and/or with go to last step. Anything more tricky
functionality (track history with real "rollback" of some authentication
/ requiredAction / registration actions etc) is beyond the scope of
this, so I am likely not going to do anything related to it.
- I have the most important flows working (login, registration, required
actions, consents, reset password). There are still many TODOs and
non-working flows (eg. brokering) and also many failing tests. But
hopefully in 1-2 weeks I will be able to have this more stable and send
PR for it.
- In the branch, I have also cherry-picked some initial work by Hynek on
"action tokens". This is used in reset password flow. I think that Hynek
will send separate email around this later with more details.
[1] https://github.com/mposolda/keycloak/tree/cross-dc2
Marek
7 years
[authz] REST and Java API need work
by Bill Burke
Authorization component of Keycloak is really cool and has a strong core
base of functionality. I think it needs another iteration though
especially around the RESET interface and Java API.
The REST interface is just too complex for anybody to use. I'll give
some examples:
* To create a permission, you must create a PolicyRepresentation.
Policy and Permission are overloaded and its unclear how to use the REST
API to create concepts that exist in the admin console.
* To apply resources and scopes to a permission definition, you have to
store a stringified JSON array into a regular JSON map.
* In java api, Policy and Permission are also overloaded. In data model
policy and permission are also overloaded. This makes it really unclear
how to create a permission vs. just a plain policy.
Suggestion:
* Create a PermissionDefinitionRepresentation and pull core config
optiosn (scopes, applied policies, resources) into actual fields rather
than in a generic config map.
* Leverage the ComponentModel API to store non-core configuration, i.e.
policy type specific information. It supports multi-valued hash maps
and also has utilities in admin console for rendering this configuration
data.
* Create a PermissionDefinition interface in storage API
Bill
7 years
User-managed permissions
by Marek Posolda
I was wondering about the use-case when users manage permissions to
their own objects. It seems that proper support for this can be very
challenging for the amount of DB space.
For example: I have 1000 documents and I have 1000 users. I want to be
able to define fine-grained permissions and be able to define that user
"john" is able to see document-1 and document-2, but not document-3 etc.
So I can end with up to:
count of users * number of documents = 1000 users * 1000 documents =
1000000 permission records in DB
When authorization scopes (actions) come into play and I want to specify
that "john" is able just to "read" document-1 when "alice" is able to
"read", "update" and "comment" on document-1, I may end up with 5
million objects in DB (assuming I have 5 actions).
We can do something like divide documents into "groups" and grant the
permission just per group. But for example Google allows to group things
(you can put more photos into one photoalbum and share whole photoalbum
with user "john"), but also define fine-grained permission (share just
single photo with user "john").
My estimation is, that using for JPA for save such data is likely not
feasible. And I bet that Google is really using something different :-)
Maybe we need to restore Mongo or some other similar DB type for manage
this stuff? Or is it something where the "Nearby policy evaluation" can
help and permissions data would rather need to be saved by the
application itself?
Marek
7 years
typos in manual
by 乗松隆志 / NORIMATSU，TAKASHI
Dear all,
I've been engaging in applying keycloak onto the systems whose emphasis are on high-security.
By the way, I've found some typos in RH-SSO and keycloak's manuals, and an erroneous description on RH-SSO and keycloak's UI, as follows.
I'm not sure it be appropriate that I post such the issue onto this dev mailing list. If not, please tell me.
1) On 3.19.7 Compromised Access Codes of Server Administration Guide for keycloak 3.0.0 and before, we'd like to use "Authorization Codes" instead of "Access Codes".
The same is applied on 17.8 Compromised Access Code of Server Administration Guide for RH-SSO 7.1beta and before.
2) On 3.14.3 Session and Token Timeouts for keycloak 3.0.0 and before, we'd like to use "Authorization Code Flow in OIDC" instead of "Authentication Code Flow in OIDC".
The same is applied on 13.3 Session and Token Timeouts of Server Administration Guide for RH-SSO 7.1beta and before.
3) On "Security Defences" of "Realm Settings" for keycloak 3.0.0 and before, the description of the tooltip for "Content-Security-Policy" is the same as "X-Frame-Options".
However, CSP is the different mechanism against X-Frame-Options according to https://www.w3.org/TR/CSP/.
we'd better consider other description. For example, "Default value prevents pages from accessing non-origin resources(click label for more information)".
Regards.
Takashi Norimatsu
7 years
Password Hashing in custom User Storage Provider
by Danny Trunk
Hi,
when implementing my own User Storage Provider I've noticed that the
password has to be raw in my database as no Password Hash Provider is
getting triggered.
The User Storage Provider is based on the JPA Example located here:
https://github.com/keycloak/keycloak/tree/master/examples/providers/user-...
When adding some logging into the isValid method of the Provider to see
whats the content of password and cred.getValue() I can see that
password (the one from the database) is hashed whereas cred.getValue()
isn't. That's why it mismatches and the user can see an invalid
credentials error message.
Do I have to call all (as I could have multiple algorithms in my
database without any information which algorithm it is)
PasswordHashProvider myself in this method? I guess that's not the
intended behaviour of the Password Hash Providers?!
7 years
Product (RHSSO) profile available in community
by Stian Thorgersen
Currently the (minor) changes between Keycloak and RHSSO are done in a
separate internal repository. This causes a lot of merge conflicts and also
makes it much harder to maintain these differences.
The plan is to do all the changes using Maven profiles in the Keycloak
repository. The exception will be POM manipulation changes (changes
versions to '-redhat' versions).
I've started the work and at the moment you can build something similar to
RHSSO by running:
mvn clean install -Pdistribution -Dproduct
The trick is '-Dproduct'. At the moment the profile does the following
changes:
* Add RHSSO theme
* Set RHSSO build properties (names, etc.)
More to come ;)
7 years
Re: [keycloak-dev] New Account Management Console and Account REST api
by Thomas Connolly
Hi Stian
Our scenario is that we do not want to expose the admin UI externally.This opens the system to an external exploit.
At the moment we have two options,1) Block, via a rule on the load balancer port / (partial) path2) Change / hack the KeycloakSessionServletFilter to block external requests
Note we had to implement 2 as the company policies for the LB didn't allow path based rules.The issue has been raised previously...https://issues.jboss.org/browse/KEYCLOAK-2944
RegardsTom Connolly
Message: 5
Date: Thu, 23 Mar 2017 13:00:56 -0400
From: Stan Silvert <ssilvert(a)redhat.com>
Subject: Re: [keycloak-dev] New Account Management Console and Account
REST api
To: keycloak-dev@lists.jboss.org
Message-ID: <fdd8b93c-a6a4-193e-ad4a-41e7447772c4(a)redhat.com>
Content-Type: text/plain; charset=utf-8; format=flowed
On 3/23/2017 8:28 AM, Thomas Connolly wrote:
> Hi All
> Could this UI and API be put on a separate port please?
It's still very early in development, but you will probably have the
option of putting it on a different port and even a different server.
Of course, the default will be to sill run it as you do today.
But I'm interested in your use case. Why do you need it on a different
port?
> RegardsTom.-----------------------------------
>
> Message: 1Date: Fri, 17 Mar 2017 08:25:47 -0700
> From: Tair Sabirgaliev <tair.sabirgaliev(a)gmail.com>
> Subject: Re: [keycloak-dev] New Account Management Console and Account
> REST api
> To: Stan Silvert <ssilvert(a)redhat.com>, stian(a)redhat.com
> Cc: keycloak-dev <keycloak-dev(a)lists.jboss.org>
> Message-ID:
> <CAGU3vRfYkUjsoZMdyTz25HFAE0+P+Yfn69X1wG1_SdBqNwAW3w(a)mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8
>
> +1 for Angular2, this will make maintenance and customisation easier.
> The framework becomes very popular and close to ?JavaEE mindset?.
>
> On 17 March 2017 at 18:19:23, Stan Silvert (ssilvert(a)redhat.com) wrote:
>
> On 3/17/2017 8:09 AM, Stian Thorgersen wrote:
>> Had another idea. We could quite easily make it possible to configure
>> the "account management url" for a realm. That would let folks
>> redirect to external account management console if they want to
>> completely override it.
> That would also mean that our own account management console could be
> served from anywhere or even installed locally on the client machine.
>> On 17 March 2017 at 13:08, Stian Thorgersen <sthorger(a)redhat.com
>> <mailto:sthorger@redhat.com>> wrote:
>>
>> I'm going to call it "YetAnotherJsFramework" ;)
>>
>> On 17 March 2017 at 12:54, Stan Silvert <ssilvert(a)redhat.com
>> <mailto:ssilvert@redhat.com>> wrote:
>>
>> On 3/17/2017 5:47 AM, Stian Thorgersen wrote:
>>> As we've discussed a few times now the plan is to do a brand
>> new account
>>> management console. Instead of old school forms it will be
>> all modern using
>>> HTML5, AngularJS and REST endpoints.
>> One thing. That should be "Angular", not "AngularJS". Just to
>> educate everyone, here is what's going on in Angular-land:
>>
>> AngularJS is the old framework we used for the admin console.
>> Angular is the new framework we will use for the account
>> management console.
>>
>> Most of you know the new framework as Angular2 or ng-2, but
>> the powers
>> that be want to just call it "Angular". This framework is
>> completely
>> rewritten and really has no relation to AngularJS, except they
>> both come
>> from Google and both have "Angular" in the name.
>>
>> To avoid confusion, I'm going to call it "Angualr2" for the
>> foreseeable
>> future.
>>> The JIRA for this work is:
>>> https://issues.jboss.org/browse/KEYCLOAK-1250
>> <https://issues.jboss.org/browse/KEYCLOAK-1250>
>>> We where hoping to get some help from the professional UXP
>> folks for this,
>>> but it looks like that may take some time. In the mean time
>> the plan is to
>>> base it on the following template:
>>>
>>>
>> https://rawgit.com/andresgalante/kc-user/master/layout-alt-fixed.html#
>> <https://rawgit.com/andresgalante/kc-user/master/layout-alt-fixed.html#>
>>> Also, we'll try to use some newer things from PatternFly
>> patterns to
>>> improve the screens.
>>>
>>> First pass will have the same functionality and behavior as
>> the old account
>>> management console. Second pass will be to improve the
>> usability (pages
>>> like linking, sessions and history are not very nice).
>>>
>>> We will deprecate the old FreeMarker/forms way of doing
>> things, but keep it
>>> around so it doesn't break what people are already doing.
>> This can be
>>> removed in the future (probably RHSSO 8.0?).
>>>
>>> We'll also need to provide full rest endpoints for the
>> account management
>>> console. I'll work on that, while Stan works on the UI.
>>>
>>> As the account management console will be a pure HTML5 and
>> JS app anyone
>>> can completely replace it with a theme. They can also
>> customize it a lot.
>>> We'll also need to make sure it's easy to add additional
>> pages/sections.
>>> Rather than just add to AccountService I'm going to rename that
>>> to DeprecatedAccountFormService remove all REST from there
>> and add a new
>>> AccountService that only does REST. All features available
>> through forms at
>>> the moment will be available as REST API, with the exception
>> of account
>>> linking which will be done through Bills work that was
>> introduced in 3.0
>>> that allows applications to initiate the account linking.
>>> _______________________________________________
>>> keycloak-dev mailing list
>>> keycloak-dev(a)lists.jboss.org
>> <mailto:keycloak-dev@lists.jboss.org>
>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>> <https://lists.jboss.org/mailman/listinfo/keycloak-dev>
>>
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev(a)lists.jboss.org <mailto:keycloak-dev@lists.jboss.org>
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>> <https://lists.jboss.org/mailman/listinfo/keycloak-dev>
>>
>>
>>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
7 years
