June 2019 - keycloak-dev - Jboss List Archives

keycloak-gatekeeper - Cookies being applied to subdomains

by Daniel Martin

Hi, I believe there is a bug in the keycloak-gatekeeper in that when it sets cookies they apply to the subdomains of the host. This causes any other services on those subdomains that are running keycloak-gatekeeper to fail when the cookie is present. For example, let's say we are running keycloak-gatekeeper on the following URLs: 1. mydomain.com 2. sub.mydomain.com If a user logs in to mydomain.com and then tries to visit sub.mydomain.com the service will fail (infinite redirect loop) as the cookie from the first service will be applied to the second service. In terms of the cookie, the problem is caused by this piece of code: https://github.com/keycloak/keycloak-gatekeeper/blob/master/cookies.go#L3... If you read section 4.1.2.3 of https://tools.ietf.org/html/rfc6265#section-4.1.2 it implies that if you set the 'Domain' attribute in that fashion it will propagate down to subdomains. It seems that to prevent this the 'Domain' attribute should simply be omitted. I've created a PR for this here: https://github.com/keycloak/keycloak-gatekeeper/pull/480 Do you agree? If so, can we get this fix merged? Best regards, Daniel Martin. Please ensure that any communication with the Home Office is via an official account ending with digital.homeoffice.gov.uk or homeoffice.gsi.gov.uk. This email and any files transmitted with it are private and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please return it to the address it came from telling them it is not for you and then delete it from your system. Communications via the digital.homeoffice.gov.uk domain may be automatically logged, monitored and/or recorded for legal purposes. This email message has been swept for computer viruses.

3 years, 9 months

2
2
0 / 0

Custom protocol mapper does not show up in console

by Chris Smith

I'm trying to get my initial protocol mapper to show up in the KC console This is my protocol mapper https://github.com/smitopher/fms-keycloak This is the Jar https://github.com/smitopher/fms-keycloak/blob/master/fms-kerberos.jar It is deployed to <kc root>/standalone/deployments It does not show up in the console https://github.com/smitopher/fms-keycloak/blob/master/kc-console.jpg Am I missing anything obvious?

3 years, 9 months

1
1
0 / 0

User Consents via Account REST API

by Schuster Sebastian (INST-CSS/BSV-OS2)

Hi everybody (and probably especially Stan and Stian), In some of our projects we want to make heavy use of Keycloaks ability to obtain user consent to third parties to access user data in our APIs. In one project, the third parties provide modules that plug into our app and the user should give his consent for this plugin at plugin installation time. We plan to have one client for every plugin so the user can for every plugin decide which scope of backend API access it wants to grant to the plugin. I would be cool if asking for consent would be possible from the app in its UI at the point when the user installs the plugin. To do that, we would like to extend the account REST Api that’s currently in preview state so it a) covers the “applications” functionality (this is currently a TODO) b) allows to create consents using the REST Api. I am well aware there might be security implications here for clients that are essentially public, e.g. a rogue app could manage consents of a user if he does not pay attention. c) use a finer-grained role model for the accounts service, e.g. at least splitting up view-account into view-profile+view-consents and manage-account into manage-profile+manage-consents so we can control which clients may invoke the consents functionality or we can prevent changing profile attributes that come from an external IDP in our case. What do you think about these changes/additions? Do they make sense? If yes, we would like to contribute them. Thanks and best regards, Sebastian Mit freundlichen Grüßen / Best regards Dr.-Ing. Sebastian Schuster Open Source Services (INST-CSS/BSV-OS2) Bosch Software Innovations GmbH | Ullsteinstr. 128 | 12109 Berlin | GERMANY | www.bosch-si.com<http://www.bosch-si.com> Tel. +49 30 726112-485 | Mobil +49 152 02177668 | 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, Dr. Aleksandar Mitrovic

3 years, 9 months

3
3
0 / 0

Krb5 direct support

by Fox, Kevin M

I've got a public client that I would like to use a direct flow with something similar to the grant_type=password, but instead would like to use kerberos spnego. I did try to edit the password flow to use the krb plugin rather then the password one but it complains about it not being configured, but regular web based krb spnego works fine so the plugin is configured properly. How hard would it be to add a grant_type=krb5 option to the code? Thanks, Kevin

3 years, 9 months

1
0
0 / 0

Keycloak REST API SPI

by Pedro Igor Silva

Hi, When reviewing the Account REST API based on our guidelines [1], I realized that we should implement APIs on top of a specific SPI. As you might know, today we have the RealmResourceSPI [2] which kinds of provides a hook to plug additional APIs into Keycloak. However, the RealmResourceSPI was created for a different purpose and is too generic. The idea behind the new SPI is that it will serve as an entry point for any API we implement for now on, being specific for the addition and management of APIs based on our guidelines. We would still keep the RealmResourceSPI as it is in order to not break backward compatibility. As we result, we should be able to: * Enhanced pluggability of new APIs * Versioning * Control over APIs marked as a technology preview or extensions * Better separation and loose-coupled APIs * Manage APIs individually as well as their respective versions Please, let me know what you think. Regards. Pedro Igor [1] https://github.com/keycloak/keycloak-community/pull/4 [2] https://github.com/keycloak/keycloak/blob/7e33f4a7d1cbf2b37aa2a6d5b87dfe7...

3 years, 9 months

2
1
0 / 0

Storage SPI: Users, Clients, and ?

by Justin Gross

Born out of necessity it looks like originally (for storage SPI) there was only user storage SPI and eventually came a partial client storage SPI motivated by a need for Openshift integration. The more I think about how it could be finished, and the more I look at the user storage SPI, the more I am finding code within user storage SPI that can be generalized as simply storage SPI. Seeking feedback on refactoring existing user storage SPI related interfaces to be agnostic to users and generalized as “storage SPI”. This should reduce the need for duplicating similar code when implementing other storage SPI (ie: client storage SPI). In the future I could see more storage SPI’s being created and I feel this would be extremely useful. Thank you, Justin Gross

3 years, 9 months

4
6
0 / 0

Guaranteed Backwards Compatibility

by Justin Gross

Marek Posolda brought up a good point in another thread about certain pieces of Keycloak being guaranteed to have backward compatibility. Is there a guideline for this, a strict outline of what is guaranteed to continue being backwards compatible or any documentation outlining what should be kept strictly compatible during a version change? TLDR; I recognize and understand the semantic versioning (or at least presume to) however I ask this so that I can make sure I consider the list of sacred things (if there is one) and especially take this into account while I design/propose/work on anything within the Keycloak project. I tried Google searching but only found the upgrade docs at keycloak.org/docs/latest/upgrading. Thank you, Justin Gross

3 years, 9 months

2
1
0 / 0

KEYCLOAK-10251 New Claim JSON Type - JSON

by Tomasz Prętki

Hi, As of now Keycloak allows to specify claims as single values of String, boolean, int and long. By naming a claim with "fully qualified name like 'address.street'" Keycloak creates a nested json object. But what if someone wants to specify a list of addresses? How to achieve that? Especially when this list has to be updated through Admin REST API? That's the use-case I and my colleagues at work have faced. We want to store a list of servers (name, url, some ids) as a hardcoded claim, be able to fetch them from userinfo and show in Web UI to choose one and connect to. Currently we store the list as a json in a String claim, but it would be more appropriate to specify a raw json in a single claim that would be included in claims as a node. Regards Tomasz Prętki

3 years, 9 months

2
2
0 / 0

Keycloak Operator proposal

by Sebastian Laskawiec

Dear Community, In the near-to-mid future we plan to start working on Keyclaok Operator. Before we dive into the code, we'd like to share our plans with wider audience. A while ago, I created a small design document and issued a Pull Request against the Keycloak Community repo: https://github.com/keycloak/keycloak- community/pull/8 If you are interested in this topic, please grab a cup of coffee and give us some feedback on the PR. Thanks, Sebastian

3 years, 9 months

1
0
0 / 0

Dynamic SAML roles to user mapper

by Heger Oliver (INST-IOT/ESB)

Hi all, For an external customer we need to bring together the SAML IDP of the customer as leading system for user data with our services that are only supporting OIDC. We think Keycloak could fit very well as some kind of mediator between the customer's IDP and our OIDC-based services. The services expect JWTs containing basic user data and also a list with all the roles the user has. With the mappers available in Keycloak a JWT can be constructed that contains the desired information. But now it can happen that the roles model is extended in agreement between the IDP and the client services. As we understand it, in order to support the newly added roles, they would have to be added manually into Keycloak before they can be referenced by the existing SAML Attribute to Role mapper. This manual step we would like to avoid. In our ideal scenario, Keycloak would just be an infrastructure component handling the SAML to OIDC conversion. With respect to the roles assigned to users, it should be agnostic and simply copy the information it receives from the SAML IDP verbatim. To achieve this we think about implementing a custom mapper that allows dealing with roles in this way. It would read the roles from a configurable attribute of the SAML response and assign them to the user affected in the Keycloak data model. If a role was encountered that did not exist yet, it would be newly created. That way the roles model used by Keycloak would adapt itself dynamically to the model used by the parties involved, and no manual updates would be required. Do you think there is an easier solution for this problem than writing a custom mapper? If the answer is no, would you be interested in such a mapper implementation? We would be happy to contribute it. In our opinion this feature would strengthen the brokering facilities of Keycloak. Thank you and kind regards Oliver Heger (INST-IOT/ESB) Bosch Software Innovations GmbH | Stuttgarter Straße 130 | 71332 Waiblingen | GERMANY | www.bosch-si.com<http://www.bosch-si.com> Tel. +49 711 811-58473 | Fax +49 711 811-58200 | oliver.heger(a)bosch-si.com<mailto:oliver.heger@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, Dr. Aleksandar Mitrovic

3 years, 9 months

1
0
0 / 0

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

keycloak-dev June 2019