March 2018 - keycloak-dev - Jboss List Archives

by gregory grey

Hi guys, I'm interested in adding Apache NiFi a possibility to use Keycloak as authn/authz provider, instead of their inbuilt mechanisms. The interfaces for doing so are quite permissive in design: https://github.com/apache/nifi-registry/blob/master/nifi-registry-securit... Could someone of the core developers please recommend the best way to perform such integration? Do you think it should follow some of the protocols of be custom set of API calls? Any ideas are welcome. Thanks. -- http://ror6ax.github.io/

6 years, 11 months

1
0
0 / 0

Keycloak 4.0.0.Beta1 is out

by Stian Thorgersen

I'm very pleased to announce the first release of Keycloak 4! To download the release go to the Keycloak homepage <http://www.keycloak.org/downloads>. HighlightsBrand new login pages The login pages have received a brand new look. They now look much more modern and clean! Themes and Theme Resources It's now possible to hot-deploy themes to Keycloak through a regular provider deployment. We've also added support for theme resources. Theme resources allows adding additional templates and … [View More]

6 years, 12 months

1
0
0 / 0

kcinit screencast

by Bill Burke

http://youtu.be/uwkggE25TjM?hd=1 -- Bill Burke Red Hat

6 years, 12 months

4
10
0 / 0

Sharing authorization settings across multiple clients

by Pedro Igor Silva

Hi, I was investigating how we could share authorization settings (resources, scopes, and specially policies) across multiple clients. Until now, I was considering using Client Templates for that. But now that Client Templates are gone in favor of Client Scopes, I'm not sure where this functionality fits in. Any suggestion on how we can support this ? IMO, better would be avoid another item on the menu for this. But I can't envision other way to do it .... Regards. Pedro Igor

6 years, 12 months

3
8
0 / 0

kcinit console sso tool

by Bill Burke

I'm finally finishing the generic console login tool I've been promising and working on for awhile now. Its an extension of KeycloakInstalled, but it works entirely on the command line and doesn't require a browser. Its all text input and output in your command line console to login. All driven by the server and rendered by the utility. Supports localization just like the browser too. * To enable this a simple challenge-based protocol was implemented. OAuth Code to token flow is required. … [View More] Authenticator returns 401 with a WWW-Authenticate header with value of X-Text-Form-Challenge callback="{url}" param="username" label="Username: " mask="false" param/label/mask are input parameter definitions that require command line console input and can be repeated for each input parameter you require from the console. Label is what should be outputed to the console. If mask is true, this means it is a password field and should be hidden on input. If the Response contains "text/plain" content, then that should be outputed before command input is asked for. Client should loop and render/ask for input until a 302 response is returned that contains a "code" parameter. Then regular OAuth is used to get the token. * The access and refresh token is stored locally in a password protected file (like ssh does). This file is checked before login is initiated to see if the user is still logged in. * If logged in, and the client has permission, the kcinit tool can also perform token exchange to obtain tokens for other clients. It stores these tokens in password protected files on local disk. * I have extended the OAuth layer on the server to support the OIDC "display" parameter. (It just stores this value in the AuthSession. I'm also in the process to refactor all the built-in Authenticators and Required Actions to support the "display" parameter and use the texts protocol described above if the "display" parameter is "console". * kcinit is implemented via Java and a shell and windows batch scripts. There's also a wrapper template script that can be used to secure existing command line tools. here's example usage with the target app command being `oc`. $ . kcinit Initially you will be prompted for the "local password" that protects token files on local disk. If you do not "source" this script (with a '.' or 'source' command), then you will have to enter in this local password every time you interact with kcinit utility. the kcinit script will prompt for this local password. Once it gets the password value, it will invoke the Java kcinit program: read -sp 'Local password: ' password KC_SESSION_KEY=`java -jar kcinit.jar password $password` The `password` command will generate an AES key from the password that will be used encrypt and decrypt locally stored files. I do it this way so that when the user's shell is exited, they can no longer access stored tokens. Once the user is logged in, they can start using command line utilities that are secured by it. To secure a command line utility the developer must use a wrapper script for each of their command line tools. The wrapper script looks like this - checks to see if KC_SESSION_KEY is set. If not, it will prompt for the local password and generate this key. - It then tries to obtain the token for the app token=`java -jar kcinit.jar token oc` This will perform a token exchange to obtain a token for the `oc` client. If this is not successful, an error message is displayed (i.e. "You are not logged in".) If successful, then the target command line tool is invoked. The tool extracts the "token" environment variable to invoke on its REST services. $path_to_real_command/$0 $@ * There is an install option for kcinit $ kcinit install This will prompt you for auth server url, realm, client, client secret, and the local password to encrypt things. -- Bill Burke Red Hat [View Less]

6 years, 12 months

3
11
0 / 0

KEYCLOAK-3210 Temporary Fix

by Donald Gay

We want to use Keycloak on MSSQL, but have concerns with the timeline of proposed fix for https://issues.jboss.org/browse/KEYCLOAK-3210 since it requires significant schema changes. One commenter noted that *"Using Hibernate's native annotation @Nationalized for JPA fields might help here - left for further investigation."* We have run some initial tests using @Nationalized on all fields specified in documentation as supporting unicode characters, and along with setting … [View More]

6 years, 12 months

2
1
0 / 0

we do not support offline tokens

by Bill Burke

Correct me if I'm wrong, but we don't support the concept of an offline token right? Just an offline refresh token? Probably something we will have to support as Kubernetes, Openshift, and many of the social providers have a similar concept of a permanent persisted access token. -- Bill Burke Red Hat

6 years, 12 months

5
13
0 / 0

[KEYCLOAK-4775] Export of Encryption Key missing in several SAML components

by Gilles Cornu

Hi, Context: While trying to integrate some SAML Service Provider that requires IdP autoconfiguration (via the /auth/realms/REALM/protocol/saml/descriptor endpoint), I observed that the <KeyDescriptor use="encryption"> was not generated in the <IDPSSODescriptor> XML element. While searching for known issue related to this bug, I found that KEYCLOAK-4775 which already report this problem (among several SAML encryption key issues). But this issue was closed and marked as "working … [View More]

6 years, 12 months

1
0
0 / 0

keycloak userinfo

by nirmal a

Is it possible to get the user details from the KEYCLOAK_IDENTITY cookie. I tried the following curl command but was getting an error. curl -d "access_token=$KEYCLOAK_IDENTITY" -H "Content-Type: application/x-www-form-urlencoded" -X POST "http://localhost:8180/auth/realms/demo/protocol/openid-connect/userinfo" { "error": "invalid_token", "error_description": "Token invalid: Secret key not set"} Is the token parameter value that is passed incorrect? If so … [View More]

6 years, 12 months

1
0
0 / 0

Re: [keycloak-dev] Initial client scopes PR

by Marek Posolda

On 16/03/18 14:30, Schuster Sebastian (INST/ESY1) wrote: > What I meant was with the old functionality "role scope mappings" you could control which roles a client could get using a 1:1 mapping from scope to role and then 1:n with composite roles OR you could disable controlling this by simply allowing full scopes for a client. > With the new functionality "client scopes" you can control which roles AND other mapped claims a client can get using an explicit 1:n mapping BUT you cannot … [View More]simply allow all scopes for a client, right? There is still "Full Scope Allowed" tab on the client. This wasn't removed in my PR. Marek > That’s why I thought it could make sense to just add that switch to the new "client scopes" tab and remove the current "scope" tab completely, at least in the long run... > > 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 > Tel. +49 30 726112-485 | Fax +49 30 726112-100 | Sebastian.Schuster(a)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 > > > > > -----Original Message----- > From: Marek Posolda [mailto:mposolda@redhat.com] > Sent: Freitag, 16. März 2018 14:19 > To: Schuster Sebastian (INST/ESY1) <Sebastian.Schuster(a)bosch-si.com>; keycloak-dev(a)lists.jboss.org > Subject: Re: [keycloak-dev] Initial client scopes PR > > On 16/03/18 09:15, Schuster Sebastian (INST/ESY1) wrote: >> Doesn't the current client scope functionality cover everything that was possible on the scopes tab, except for the ability to simply allow all scopes for a client? > Not sure what you mean. I am probably lost in what "scope" you are talking about :) Client scope (new thing, which is not yet in Keycloak > master) or "Role scope mappings" (functionality which is under "Scopes" > tab of client or clientTemplate in current master?) > > But at least for now with my PR applied, clients still have "Scope" tab on themselves as it's still possible to grant "Role scope mappings" > directly to client. But clients will also inherit "Role scope mappings" > from all client scopes, which are assigned to them. > > Marek >> Then my proposal would be to add that functionality to the "client scope" tab and call it "scope" tab again, and maybe rename the menu on the left to "scope mappings" >> or also just "scopes". >> >> 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 Tel. +49 30 726112-485 | Fax +49 30 >> 726112-100 | Sebastian.Schuster(a)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 >> >> >> >> >> -----Original Message----- >> From: Marek Posolda [mailto:mposolda@redhat.com] >> Sent: Freitag, 16. März 2018 08:48 >> To: Schuster Sebastian (INST/ESY1) <Sebastian.Schuster(a)bosch-si.com>; >> keycloak-dev(a)lists.jboss.org >> Subject: Re: [keycloak-dev] Initial client scopes PR >> >> It's not yet clear... Maybe we can rename tab to "Role Scopes"? Will >> it be clearer or even more confusing? :) >> >> Marek >> >> On 15/03/18 13:13, Schuster Sebastian (INST/ESY1) wrote: >>> Is the long-term goal to make the "Scopes" tab for clients go away? Because currently it's a bit confusing both are there... >>> >>> 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 Tel. +49 30 726112-485 | Fax +49 30 >>> 726112-100 | Sebastian.Schuster(a)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 >>> >>> >>> >>> >>> -----Original Message----- >>> From: keycloak-dev-bounces(a)lists.jboss.org >>> [mailto:keycloak-dev-bounces@lists.jboss.org] On Behalf Of Marek >>> Posolda >>> Sent: Mittwoch, 14. März 2018 18:47 >>> To: keycloak-dev(a)lists.jboss.org >>> Subject: [keycloak-dev] Initial client scopes PR >>> >>> Hi, >>> >>> I've finally send PR https://github.com/keycloak/keycloak/pull/5076 for the first iteration of client scopes. I will talk on tomorrow call about the details and still need to write some more automated tests. But I am seing PR now if someone wants to take a look. >>> >>> Summary: >>> >>> - Client Templates were renamed to "Client Scopes". Some things were removed from the client template admin console (EG. Theme setting added recently). Also I've removed some ClientTemplate model properties, which were never used. Client Scope still has list of protocol mappers and list of "Scopes" (Roles scope mappings). >>> >>> >>> - There is new tab "Client Scopes" on client. Here you can assign client scopes to client. Each client has 2 types of client scopes: >>> -- Default client scopes -- Those client scopes are automatically applied when login with the client. Their protocol mappers and "Role scope mappings" are always used. >>> -- Optional client scopes -- Those client scopes are applicable just for OIDC clients. They are used just if they are requested by "scope" >>> parameter during login >>> >>> >>> - Under "Client scopes", there is new tab "Default Client Scopes" . This allows to specify "Realm default client scopes" and "Realm optional client scopes". The scopes configured here will be added as default/optional scopes to new clients. Client can override this (Remove those defaults and add some different client scopes). So it works similarly to Default Roles. >>> >>> >>> - Roles don't have "Scope Param Required" flag anymore. Protocol mappers don't have "Consent required" and "Consent text" anymore. Client scopes don't have "Full scope allowed" flag. But clients still have "Full scope allowed" flag for now and it's still ON by default for newly created clients. >>> >>> - There are few builtin client scopes added to each realm. There are >>> 4 claims scopes defined in OIDC specification and those are added by >>> default: "profile", "email", "address" and "phone" with the protocol mappers corresponding to the claims described in OIDC specification [1]. >>> -- The "profile" and "email" are configured as default scopes and hence are automatically added to new clients. >>> -- The "phone" and "address" are configured as optional scopes by default. >>> -- The clients now doesn't have any protocolMappers added by default when they are created. I've added "profile" and "email" as default scopes due it's most close to the previous default protocolMappers we had. >>> >>> - For SAML, there is "role_list" default client scope, containing just 1 protocol mapper "role list". So both OIDC and SAML clients don't have any protocol mappers by default, it's driven by client scopes now by default. >>> >>> - There is "offline_access" OIDC client scope, which is optional scope by default. This scope contains just "offline_access" realm role. Due the fact, that parameter "Scope Param Required" was removed from RoleModel, the "offline_access" role is now automatically available in tokens for clients with "Full Scope Allowed", even if no offline tokens was requsted. But I don't think it's big issue besides a bit bigger token. Same also already applies for uma_authorization and some other built-in roles. The fact, that offline token is requested is now driven by "offline_access" scope. But user should still have "offline_access" >>> role to be able to receive offline token. >>> >>> Consent changes: >>> - Consent screen now doesn't display protocolMappers (claims) and roles, but instead it displays just client scopes. So by default, the consent screen contains 2 items "User profile" and "Email address", which correspond to the "profile" and "email" OIDC scopes. >>> >>> - There can be still the case, when client has some protocolMappers or role scope mappings defined on itself. So I've added flag "Display On Consent Screen" on clients (It's OFF by default) to specify if some message should be shown on consent screen about claims dedicated directly to client itself. It's useful especially when client doesn't have any client scopes as the consent screen wouldn't be displayed in that case. >>> >>> - During this refactoring, I've tried to do some cleanup we discussed before, so I've removed protocolMappers and roles from clientSession. >>> Instead I've added clientScopes to refresh token. During refreshing token, it's checked that user still has all the consents, which are in the refresh token. So in case that user revoked consents in the meantime, the token refresh will fail. ProtocolMappers and scoped roles are always re-computed from the clientScopes. So if for example another claim was added to scope "profile", it will automatically be applied after refreshed token. I don't see an issue with that. User approved on consent screen scope "profile" and he may not be concerned what claims/scoped roles are in profile. >>> >>> - Migration: In the end I did not change existing clients and did not remove protocolMappers from them and didn't add default/optional client scopes to them. The only exception is "offline_access" profile, which is added as optional to all clients, which had scope to "offline_access" >>> role. Consents are not migrated - again with the only exception being "offline_access" consent, so refreshing offline tokens from previous version still works. The new consent screen is something quite different than previous one, so makes sense to show it to users again when they want to login, even if they approved protocolMappers for the previous version. >>> >>> Sorry for long email and long PR :) More tomorrow... >>> >>> >>> [1] http://openid.net/specs/openid-connect-core-1_0.html#ScopeClaims >>> >>> Marek >>> >>> _______________________________________________ >>> keycloak-dev mailing list >>> keycloak-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev [View Less]

6 years, 12 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

keycloak-dev March 2018