Roles Claims
by gambol
Hiya ...
I was wondering if it's possible as of 1.9.0 to change or map the roles of
a user into new claim .. The reason I ask is
https://github.com/kubernetes/kubernetes/pull/21001/files. I know the
current implementation uses something akin to the below in the access token.
"resource_access": {
"client_id": {
"roles": [
"role-a",
"role-b",
"role-c"
]
},
"account": {
"roles": [
"view-profile",
"manage-account"
]
}
},
Any chance via a mapper we could use an string array?
Rohith
7 years, 9 months
Fwd: Bad Request
by Alex Gouvêa Vasconcelos
Hi guys. I'm running into some trouble here...
I have a very simple application which should authenticate against keycloak
and return to the main page. This is triggered through the web.xml in my
application.
<web-app xmlns="http://java.sun.com/xml/ns/javaee" xmlns:xsi="
http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://java.sun.com/xml/ns/javaee
http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd"
version="3.0">
<module-name>teste</module-name>
<filter>
<filter-name>CORSFilter</filter-name>
<filter-class>br.com.test.tms.teste.util.CORSFilter</filter-class>
</filter>
<filter-mapping>
<filter-name>CORSFilter</filter-name>
<url-pattern>/rest/*</url-pattern>
</filter-mapping>
<distributable />
<security-constraint>
<web-resource-collection>
<web-resource-name>teste</web-resource-name>
<url-pattern>/rest/exemploService/secure/*</url-pattern>
</web-resource-collection>
<auth-constraint>
<role-name>*</role-name>
</auth-constraint>
<user-data-constraint>
<transport-guarantee>CONFIDENTIAL</transport-guarantee>
</user-data-constraint>
</security-constraint>
<login-config>
<auth-method>KEYCLOAK</auth-method>
<realm-name>realmtest</realm-name>
</login-config>
<security-role>
<role-name>user</role-name>
</security-role>
<security-role>
<role-name>admin</role-name>
</security-role>
</web-app>
The server side has a REST API and the client side is an angular
application. Everything very simple to just try the development
environment. What happens is that, after filling the login page and return
to the index.html (actually it's not returning), I receive a 400 BAD
REQUEST for the uri:
http://localhost:8080/teste/?code=X8VlnUNxYzofJDHzkx1ZmMgO2BP0ZDJ-e2l7uB0...
It seems to me, that the malformed URI is because of the ?code=... If I
reload the page with the same URL, it just return the same 400... if I
remove the ? portion, it reloads the page and again redirects to and from
the keycloak server, and recovers the ? portion, repeating the same 400.
I'm running everything in the same application under wildfly 10. Both the
server and client sides in the same deployed WAR.
I'd appreciate any help.
Best regards.
Alex Gouvea Vasconcelos
[image: Imagem inline 1]
7 years, 9 months
table locks
by Bill Burke
FYI, I don't think I can really fix, but I tried a concurrency test that
creates, fetches, and then deletes a client in multiple concurrent
threads. HSQL is giving me deadlock exceptions. Looks like it is
trying to obtain table locks. Sucks as I can't really unit test this
scenario.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
7 years, 9 months
Keycloak 1.9.0.Final release status
by Stian Thorgersen
I'm hoping we can start testing Keycloak 1.9.0.Final release on Monday
morning. That means all changes should be in by end of today.
With that regards there's a few outstanding items:
* Bill - is the cache stable for release? We can do improvements for next
release if required.
* Marek - what's status on performance degredation? You also have a few
other issues assigned, will these be ready?
* Bruno - will you fix KEYCLOAK-2501 in time?
Is there anything else that's not in JIRA that needs doing?
I'd appreciate as many people as possible help out with testing the
release. I'll send out details once we're ready to start.
Thanks,
Stian
7 years, 9 months
client query caches getting complicated
by Bill Burke
Currently, adding or deleting a client, or updating a realm causes
invalidation/eviction of the realm and all clients in that realm. To
make matters worse, the next time the realm is accessed, it queries and
loads each client and its relationships. Why do we do this? When a
realm invalidation happens, the cache has no idea if the realm is just
being updated or removed entirely from the DB. With a realm removal, you
also need to evict the cache of all clients within the realm. So, a
cached realm MUST have a list of all clients within it. As a result,
the more clients that get added, keycloak gets slower and slower.
Eventually though the cache stabilizes after inserts/update/deletes
subside and we get back to normal performance, but you can see a nasty
blip for a little bit.
I think i have a couple of solutions for this:
* Create a separate client cache. Client keys would be
"{realm.id}.{client.id}". Iterate on all client keys, and evict those
that start with the realm id.
* Or, do a DB query for all clients of the realm.
I'm giving this until end of day to see if I can get a good solution,
otherwise i'm aborting.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
7 years, 9 months
Concurrent sync in cluster
by Marek Posolda
We had a bug https://issues.jboss.org/browse/KEYCLOAK-2412 that there
are errors when sync of users from federationProvider is triggered
concurrently in more cluster nodes. This affects periodic sync as well.
To avoid concurrent executions of same task, I've added ClusterProvider.
This is based on infinispan and it provides some locking functionality
to ensures that sync from federation can be executed just by one cluster
node at a time. Even on single node (non-cluster setup), now you can't
trigger sync multiple times concurrently. So for example if there is
periodic sync in progress and you click in admin console on "Sync
users", the sync won't happen.
The same mechanism is now also used for scheduled tasks (Removing
expired user sessions and expired events). Nobody reported any bug yet,
however when removing of expired events/sessions is triggered
concurrently by more cluster nodes, it can be issue too. So this is now
avoided. Maybe we can improve even more and ensure that just cluster
coordinator will run scheduled tasks and other nodes will just ignore them?
ClusterProvider also adds possibility to register ClusterListener with
any task, that should be executed once notification from any cluster
node comes. This allows that when some federation provider is
created/updated/removed, then all nodes are aware of the change and will
immediately change (or remove) scheduled timer.
PR is here https://github.com/keycloak/keycloak/pull/2234
Marek
7 years, 9 months
