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 resources without creating
a theme. Perfect for custom authenticators that require additional pages
added to the authentication flow.
We've also added support to override the theme for specific clients. If
that doesn't cover your needs, then there's a new Theme Selector SPI that
allows you to implement custom logic to select the theme.
Native promise support to keycloak.js
The JavaScript adapter now supports native promises. Of course it still has
support for the old style promises as well. Both can be used
interchangeably.
Edit links in documentation
To make it easier to contribute changes to the documentation we have added
links to all sections of the documentation. This brings you straight to the
GitHub editor for the relevant AsciiDoctor file. There's also a quick link
to report an issue on a specific page that will include the relevant page
in the description.
HTTPS support on keycloak.org
Thanks to GitHub pages and Let's Encrypt there's finally HTTPS on
keycloak.org. About time?
Loads more..
The full list of resolved issues is available in JIRA
<https://issues.jboss.org/issues/?jql=project%20%3D%20keycloak%20and%20fix...>
.
Upgrading
Before you upgrade remember to backup your database and check the upgrade
guide <http://www.keycloak.org/docs/latest/upgrading/index.html> for
anything that may have changed.
6 years, 1 month
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, 1 month
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.
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
6 years, 1 month
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 sendStringParametersAsUnicode=false,
this seems to resolve the issue while not impacting unicode support.
Any thoughts on implementing this to provide quicker resolution? From my
perspective it seems like a desirable change to make regardless of any
other efforts to clean up schemas.
Thanks
6 years, 1 month
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, 1 month
[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 as expected", apparently
without any change to the code base so far.
I added a comment there 5 days ago, but I am not sure if comments on closed
tickets are considered/accepted.
Questions:
How should I proceed to start a new discussion about this issue?
Please let me know if you prefer that I file a new JIRA issue, or if you
plan to reopen KEYCLOAK-4775.
Note: I am interested to implement a bug-fix pull request, although my Java
Skills and Knowledge on the Keycloak project are "rather" (aka extremely)
scarce and will certainly slow down the process. On the other hand, I
"suspect" that this should be quickly fixed by an experimented Keycloak
developer... (to be confirmed ;-). In other words: Help offered, Help
welcome ;-)
Thank you very much to all the Keycloak Development community for this very
nice and powerful project (that I'm recently starting to learn/use).
Best regards,
Gilles Cornu
6 years, 1 month
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 is it possible to get the valid parameter value using the cookies KEYCLOAK_IDENTITY, KEYCLOAK_SESSION, AUTH_SESSION_ID.
6 years, 1 month
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 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
6 years, 1 month
