September 2018 - keycloak-dev - Jboss List Archives

by Stan Silvert

*Executive summary: *Any time you use ?no_esc, make sure you also use kcSanitize(). Most of you on the team are already aware of this, but for completeness I'll post to the community dev list. Some time ago, we switched our default Freemarker settings so that everything is escaped by default. However, this means that some things need to be explicitly "un-escaped". This includes any time we allow HTML in an admin console field or in a resource bundle (*.properties file). The way this is done in Freemarker is to use the ?no_esc directive. For example, login.ftl has <span class="kc-feedback-text">${message.summary?no_esc}</span> This is fine, but what if, somehow an attacker was able to insert some HTML into message.summary? It's unlikely because it requires a high level of access. But it's possible. We now protect against this using a sanitizer for unescaped content. From now on, you should call the Keycloak sanitizer any time you are using ?no_esc. The sanitizer removes unsafe HTML using an algorithm similar to the one used on eBay. So this example becomes: <span class="kc-feedback-text">${kcSanitize(message.summary)?no_esc}</span>

5 years, 7 months

1
0
0 / 0

Can KeyCloak support Multi-lateral SAML federation?

by Chris Phillips

Hi. I sent this to the Users list and have had zero response. Re-sending here on the dev list hoping to hear feedback and thoughts from Keycloak Devs on my questions around KeyCloak's ability to support multi-lateral federation and if it is on the roadmap. Thanks and look forward to thoughts and comments.. Chris. On 2018-08-30, 4:06 PM, "keycloak-user-bounces(a)lists.jboss.org on behalf of Chris Phillips" <keycloak-user-bounces(a)lists.jboss.org on behalf of Chris.Phillips(a)canarie.ca> wrote: Hi. I’m going through assessing KeyCloak as being able to be an Identity Provider in a multi-lateral SAML federation context and am seeking insight from the users and devs involved in KeyCloak. For an IdP to be considered interoperable in a multi-lateral SAML trust federation context, IdPs need to be able to do a base set of functions. These are some of the critical (but not only) ones: * Retrieve, with a configurable frequency (usually hourly), an online metadata aggregate * validate the signature on the aggregate * when signature validity is verified, load all the entities (Identity Providers/Service Providers) to be trusted or used in trust decisions in the Identity Provider. I have not seen this capability in KeyCloak 4.3.0.Final (docker) but could be missing something. Is anyone using KeyCloak in this manner or are there plans for this functionality on KeyCloak’s technical roadmap? Some additional items to decorate my ask for information.. To give an idea of scale, the aggregates I want to work with have ~4500 entities with 2800 IdPs and 2100 SPs and need to be refreshed hourly. The list of items important for interoperability can be seen here with the ones I called out above appearing in section 2.2.1: https://kantarainitiative.github.io/SAMLprofiles/fedinterop.html I’ve searched the keycloak-users list a bit and came across the reference to EntitiesDescriptor which lead me to this issue and code update in KeyCloak: https://issues.jboss.org/browse/KEYCLOAK-4399 which leads me to think that the support for reading in aggregates is not possible and maybe engineered out of the product itself. Am I right in thinking that? Thoughts and insights welcome.. Chris. ___________________________________________________________________________________________ Chris Phillips Technical Architect, Canadian Access Federation, CANARIE| chris.phillips(a)canarie.ca<mailto:chris.phillips@canarie.ca> |GPG: 0x7F6245580380811D _______________________________________________ keycloak-user mailing list keycloak-user(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-user

5 years, 7 months

1
0
0 / 0

Audience support

by Marek Posolda

Hi, I have some concerns about the audience support. The prototype done few months ago, which I have in my branch [1] is based on client scopes. I showed it on the weekly demo some time ago and changed few things based on the feedback. Just to clarify, the PR: - Adds the AudienceProtocolMapper, which is able to attach single client_id of the specified client (typically will be bearer-only client) - Adds the easy way to generate "audience client scope" for specified "service" client (usually bearer-only client). This clientScope contains: -- the audienceProtocolMapper of bearer-only described above -- the scope role mappings of all the client roles of that bearer-only client. The "frontend" clients can then use this clientScope, so that audience + roleMappings will be both available in the accessToken issued for the frontend-client. Now there is this specs [2], which Pedro pointed. Short summary about this specs: - It is still in draft state for few years and there are some TODO in it. So hard to say how much to rely on it... - It specifically talks about "scope" parameter and mentions, that it is often used by various parties for "what the token can be used for" (permissions/claims associated with the token) and "where to use that token" . But it mentions that "where" use-case should be ideally handled by something else. - It introduces "resource" parameter, which MUST be an absolute URI per this specification and it should point to the service/resource where the access token will be used. When authorization server is creating token, it may apply audiences, encrypt token by various algorithms based on the requested "resource" etc. For the audience, they specify that: "The authorization server may use the exact 'resource' value as the audience or it may map from that value to a more general URI or abstract identifier for the resource server." - The "resource" parameter is used in the token request if possible. For the grants where it's not possible (implicit, resource owner password login, client credentials) it is used in the initial authentication request. So for the classic "authorization_code" grant it can be used in code-to-token or refresh-token requests. This is great and allows some cool flexibility (unlike "scope" where the whole SSO login including all the redirects is needed). But it requires some support on adapters. Now I am thinking about 2 possible ways to continue: 1) Finish my current work around audience and for now, let it be driven through the "scope" parameter. Then later add the support for the "resource" parameter and the specs above. 2) Skip what I currently have and start something different based on the "resource" parameter specs. ATM I am more keen to option 1, so that we can have some audience support in master ASAP. Also because the specs is still draft and I don't know how much we can rely on the "resource" parameter being adopted by 3rd party applications (for example Openshift). When we later have the option to drive audiences through both "scope" and "resource" params, it will be good thing IMO. The "resource" related support will require changes on the adapter side as it is new parameter to be supported in code-to-token request and refresh-token request. On our adapter's side, it will be good to have some changes to allow "cache" of more access tokens for various resources/audiences, not just one. On server-side, I was thinking about various possibilities, and it still looks good to represent "resource" support through client scopes. So optional clientScopes can be requested either through "scope" parameter (default case) or through "resource" parameter (probably disabled by default) or through both. Thoughts? [1] https://github.com/mposolda/keycloak/tree/audience [2] https://tools.ietf.org/html/draft-ietf-oauth-resource-indicators-00 Marek

5 years, 7 months

3
3
0 / 0

Possible feature: role attributes

by Schuster Sebastian (INST/ESY1)

Hi everybody, We have a use case where we would like to store additional meta-information for roles. This come from our IAM-requirements, that say there is a single responsible person for a role or that roles give access to data with different classifications. One way to store this kind of information would be to introduce role attributes to client and realm roles, basically similar to user or group attributes. For us, it would be sufficient to have this information purely as metadata, i.e. we would only read it through the audit log to inform the responsible person about role assignments if a role with a certain classification is assigned. In contrast to that, you can add group und user attributes to a token using user attribute mappers and the client application can extract this information from the token and act on it. WDYT? Does anybody else have similar requirements? Would you need role custom attributes also in the token? I can imagine that it gets kind of difficult to identify where attributes come from, once there are user, group, and role attributes, possibly with inheritance/composition. Best regards, Sebastian Mit freundlichen Grüßen / Best regards Dr.-Ing. Sebastian Schuster Engineering and Support (INST/ESY1) Bosch Software Innovations GmbH | Ullsteinstr. 128 | 12109 Berlin | GERMANY | www.bosch-si.com<http://www.bosch-si.com> Tel. +49 30 726112-485 | Fax +49 30 726112-100 | Sebastian.Schuster(a)bosch-si.com<mailto:Sebastian.Schuster@bosch-si.com> Sitz: Berlin, Registergericht: Amtsgericht Charlottenburg; HRB 148411 B Aufsichtsratsvorsitzender: Dr.-Ing. Thorsten Lücke; Geschäftsführung: Dr. Stefan Ferber, Michael Hahn

5 years, 7 months

2
3
0 / 0

Keycloak 4.4.0.Final is out

by Ian Duffy

Hi all, Glad to see the Keycloak 4.4.0 release, the image seems to be missing from Docker Hub. https://hub.docker.com/r/jboss/keycloak/tags/ Is there anything that can be done to fix this? Thanks, Ian.

5 years, 7 months

2
1
0 / 0

Keycloak 4.4.0.Final is out

by Stian Thorgersen

https://www.keycloak.org/docs/latest/release_notes/index.html

5 years, 7 months

1
0
0 / 0

Permission for client scopes

by Stian Thorgersen

As scopes are often used for permissions in the applications themselves it would be useful to have a mechanism to grant a user access to a scope. For example if you have the scopes "photos:view" and "photos:edit" you would like only users that are permitted to use the photos application to be able to get those scopes in the token. One simple way of doing this would be to have a optional required role associated with a client scope. Then we can simply apply the client scopes for which the user has the required role.

5 years, 7 months

2
1
0 / 0

Keycloak large token issue

by tushar dhole

Hello Community, There is a limitation with keycloak to support large number of realms. Following is the existing jira issue related to same, https://issues.jboss.org/browse/KEYCLOAK-1268 I was wondering if we can solve this following approach, 1. Make the token for users under "master" realm not return all realm info. 2. We can just allow a token from "realm": "master" any for cross realm authorization 3. For all other non master realm the token will be same as that of today If this approach is feasible/doable, then I can dig into the code and try to implement this. But would first like to know if this is really a feasible/doable one. Thanks a lot, Tushar Dhole <https://issues.jboss.org/browse/KEYCLOAK-1268> [KEYCLOAK-1268] Token for admin becomes to large with many ...<https://issues.jboss.org/browse/KEYCLOAK-1268> issues.jboss.org I have a big problem here because of bearer token size. I'm using keycloak within a SaaS application, so I need create alot of realms.

5 years, 7 months

2
2
0 / 0

SCIM v2 support

by Lösch, Sebastian

Hello, in a customer project we use keycloak and need a SCIM (System for Cross-domain Identity Management) API. Currently we write a wrapper API and a custom endpoint providing the SCIM functionality. We wrote a extension of the UserEntity, UserModel and an extension of the JpaUserProvider. This strategy seems not ideal and the nicest way is to add this extensions to Keycloak. This is already suggested in https://issues.jboss.org/browse/KEYCLOAK-2537 Is anybody out there who can guide me, what coding would be necessary to contribute the SCIM functionality? Currently I think we have to: - extend the UserEntity with all SCIM attributes. This will result in additional tables/entities for complex attributes e.g. Address, Name, Email - extend the UserModel to povide the additional attributes - implement the new SCIM endpoint /Users - make the additional attributes available via Admin REST API /users - extend views to be able to edit SCIM user attributes using the web ui - - All the above again for the Groups endpoint This also seem to be major changes. To big for one Pull Request. How do you like to handle this? Best regards, Sebastian

5 years, 7 months

3
4
0 / 0

Potential performance regression between 3.4.3.Final and 4.3.0.Final

by Thomas Darimont

Hello Keycloak team, has anyone encountered some performance issues after upgrading 3.4.3 to 4.x (4.3.0)? Today I noticed a performance regression while preparing an upgrade from Keycloak 3.4.3.Final to 4.3.0.Final in our staging environment. In our test environment, we have around ~100k test users stored in a postgres-backed database. When we started the server with the new Keycloak version, the migration went through, and everything looked fine at first, but when we tried to browse the list of users via the admin-console, we noticed that the CPU and memory consumption of the server increased significantly, up to a point where Keycloak crashed with an OOME. All previous Keycloak versions including 3.4.3 were very modest with their memory requirements and quite happy with ~1g heap. However, that seems to have changed in Keycloak 4.3.0 - there we needed at least 4g to prevent Keycloak from crashing with an OOME. Furthermore, we noticed that the response times for browsing the paginated user view increased significantly as well: In Keycloak 3.4.3 the average time to load a user page is ~80ms. In Keycloak 4.3.0 (and older versions >= 4.0.0.Beta1) the same operation takes ~7 seconds for a test realm with just 10k users. In the test realm with 100k users, the time to load a single page in the users listing was 66 seconds for version 4.3.0, on average - compared to quite stable 80ms in 3.4.3. The database query that is executed by Keycloak 4.3.0 runs in ~1.5 seconds for 100k users, so I assume the processing logic in Keycloak is the culprit. The problem of long load-times can be reproduced with the Keycloak docker images and the in-memory database. I also created a small example project that creates some users with just a few attributes in a docker based 3.4.3 and 4.3.0 Keycloak environment with a Postgres database to reproduce the problem. https://github.com/thomasdarimont/kc-user-regression-tester Cheers, Thomas

5 years, 7 months

5
15
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

keycloak-dev September 2018