Notify clients on client configuration changes in Keycloak
by Thomas Darimont
Hello group,
I have a service which is registered as an OIDC client with service
accounts enabled.
If the service obtained an access_token with client_credentials grant
it contains the service account roles assigned to that client at the moment
the token was issued.
The service now uses the access_token to make calls to other services.
As long as the access_token is valid the service reuses the access_token.
If one now changes the service account role configuration of the client in
Keycloak
the new roles are NOT visible to the service until it obtains a new
access_token with
the new role assignment - which can take a while depending on the
configured token lifetime.
It would be helpful if Keycloak could notify clients (perhaps via Webhook?)
about client
configuration changes (roles, mappers, scopes, etc.) - services could then
take
suitable action e.g. obtain a new access_token.
What do you think?
Cheers,
Thomas
9 years
Email locale
by Michael B
I do not understand the logic behind the locale of the mails. Example scenario's:
- Mail verification => mail is sent based on the locale of the registration screen => this is clear
- Forgot password => mail is sent based on the locale of the 'forgot password' screen. => this is NOT clear
- Execute actions mail sent by an administrator => mail is sent based on the locale of the user to which the mail is sent => this is clear
Is the language of the 'forgot password' mail intended behaviour? If so, could you briefly explain me the logic of the locale selection? Is it a different selection per mail, or does it somehow depend on the user that is logged in and the user to whom the mail is sent?
thanks,
Michael
9 years
Re: [keycloak-dev] KEYCLOAK-4523 SPI implementation
by Stian Thorgersen
[Moving to dev list]
Currently PasswordPolicy.HASH_ALGORITHM_DEFAULT is used as the default
provider when not specified for a realm. Maybe it would actually be better
to have the default set in standalone.xml to make it configurable. Same
could be done for the hashing intervals and make the default a
configuration option on each provider separately. The default hashing
intervals should most likely me lower for pbkdf2-sha256 and pbkdf2-sha512
to make them as expensive.
If we do that I'd like to see new installations use pbkdf2-sha256 by
default (and whatever hash interval matches 20K with pbkdf2), while
upgraded installations remain with pbkdf2 and 20K until manually changed in
standalone.xml or in realm password policy.
On 9 March 2017 at 18:36, Adam Kaplan <akaplan(a)findyr.com> wrote:
> I noticed the ID for the original PasswordHashProvider
> (Pbkdf2PasswordHashProvider) was hard-coded in several places.
>
> 1. Should I add an SPI definition to default-server-subsys-config.
> properties?
> 2. Does calling getProvider(Class.class) on a KeycloakSession return the
> default provider?
>
> On Thu, Mar 9, 2017 at 12:15 PM, Adam Kaplan <akaplan(a)findyr.com> wrote:
>
>> I'd agree with 4 being overkill - I just listed what was available in in
>> the JRE.
>>
>> I started down the path of implementing - feature branch is here:
>> https://github.com/adambkaplan/keycloak/tree/feature/KEYCLOAK-4523
>>
>> On Thu, Mar 9, 2017 at 8:24 AM, Stian Thorgersen <sthorger(a)redhat.com>
>> wrote:
>>
>>> Search for usage of the class PasswordHashProvider
>>>
>>> On 9 March 2017 at 12:54, Ori Doolman <Ori.Doolman(a)amdocs.com> wrote:
>>>
>>>> From this discussion I understand that for all realm users, current
>>>> password hashing algorithm is using SHA1 before the hashed password is
>>>> saved to the DB.
>>>>
>>>> Can you please point me to the place in the code where this hashing
>>>> occurs ?
>>>>
>>>> Thanks.
>>>>
>>>>
>>>> -----Original Message-----
>>>> From: keycloak-user-bounces(a)lists.jboss.org [mailto:
>>>> keycloak-user-bounces(a)lists.jboss.org] On Behalf Of Bruno Oliveira
>>>> Sent: יום ב 06 מרץ 2017 14:08
>>>> To: stian(a)redhat.com; Adam Kaplan <akaplan(a)findyr.com>
>>>> Cc: keycloak-user <keycloak-user(a)lists.jboss.org>
>>>> Subject: Re: [keycloak-user] Submitted Feature: More Secure
>>>> PassowrdHashProviders
>>>>
>>>> On Mon, Mar 6, 2017 at 8:37 AM Stian Thorgersen <sthorger(a)redhat.com>
>>>> wrote:
>>>>
>>>> > 4 new providers is surely a bit overkill? Isn't 256 and 512 more than
>>>> > sufficient?
>>>> >
>>>>
>>>> +1
>>>>
>>>>
>>>> >
>>>> > On 2 March 2017 at 15:28, Adam Kaplan <akaplan(a)findyr.com> wrote:
>>>> >
>>>> > This is now in the jboss JIRA:
>>>> > https://issues.jboss.org/browse/KEYCLOAK-4523
>>>> >
>>>> > I intend to work on it over the next week or two and submit a PR.
>>>> >
>>>> > On Thu, Mar 2, 2017 at 4:39 AM, Bruno Oliveira <bruno(a)abstractj.org>
>>>> > wrote:
>>>> >
>>>> > > Hi Adam and John, I understand your concern. Although, collisions
>>>> > > are not practical for key derivation functions. There's a long
>>>> > > discussion about this subject here[1].
>>>> > >
>>>> > > Anyways, you can file a Jira as a feature request. If you feel like
>>>> > > you would like to attach a PR, better.
>>>> > >
>>>> > > [1] - http://comments.gmane.org/gmane.comp.security.phc/973
>>>> > >
>>>> > > On Wed, Mar 1, 2017 at 3:33 PM John D. Ament
>>>> > > <john.d.ament(a)gmail.com>
>>>> > > wrote:
>>>> > >
>>>> > >> I deal with similarly concerned customer bases. I would be happy
>>>> > >> to see some of these algorithms added. +1
>>>> > >>
>>>> > >> On Wed, Mar 1, 2017 at 12:56 PM Adam Kaplan <akaplan(a)findyr.com>
>>>> wrote:
>>>> > >>
>>>> > >> > My company has a client whose security prerequisites require us
>>>> > >> > to
>>>> > store
>>>> > >> > passwords using SHA-2 or better for the hash (SHA-512 ideal).
>>>> > >> > We're
>>>> > >> looking
>>>> > >> > to migrate our user management functions to Keycloak, and I
>>>> > >> > noticed
>>>> > that
>>>> > >> > hashing with SHA-1 is only provider out of the box.
>>>> > >> >
>>>> > >> > I propose adding the following providers (and will be happy to
>>>> > >> > contribute!), using the hash functions available in the Java 8
>>>> > >> > runtime
>>>> > >> > environment:
>>>> > >> >
>>>> > >> > 1. PBKDF2WithHmacSHA224
>>>> > >> > 2. PBKDF2WithHmacSHA256
>>>> > >> > 3. PBKDF2WithHmacSHA384
>>>> > >> > 4. PBKDF2WithHmacSHA512
>>>> > >> >
>>>> > >> > I also propose marking the current Pbkdf2PasswordHashProvider as
>>>> > >> > deprecated, now that a real SHA-1 hash collision has been
>>>> > >> > published by Google Security.
>>>> > >> >
>>>> > >> > --
>>>> > >> > *Adam Kaplan*
>>>> > >> > Senior Engineer
>>>> > >> > findyr <http://findyr.com/>
>>>> >
>>>> > >> > m 914.924.5186 <(914)%20924-5186> <(914)%20924-5186>
>>>> > >> > <//914.924.5186
>>>> > >> <(914)%20924-5186> <(914)%20924-5186>> | e
>>>> >
>>>> >
>>>> > >> > akaplan(a)findyr.com
>>>> > >> > WeWork c/o Findyr | 1460 Broadway | New York, NY 10036
>>>> > >> > _______________________________________________
>>>> > >> > keycloak-user mailing list
>>>> > >> > keycloak-user(a)lists.jboss.org
>>>> > >> > https://lists.jboss.org/mailman/listinfo/keycloak-user
>>>> > >> >
>>>> > >> _______________________________________________
>>>> > >> keycloak-user mailing list
>>>> > >> keycloak-user(a)lists.jboss.org
>>>> > >> https://lists.jboss.org/mailman/listinfo/keycloak-user
>>>> > >>
>>>> > >
>>>> >
>>>> >
>>>> >
>>>> > --
>>>> >
>>>> >
>>>> > *Adam Kaplan*
>>>> > Senior Engineer
>>>> > findyr <http://findyr.com/>
>>>> >
>>>> > m 914.924.5186 <//914.924.5186> | e akaplan(a)findyr.com
>>>> >
>>>> >
>>>> > WeWork c/o Findyr | 1460 Broadway | New York, NY 10036
>>>> > _______________________________________________
>>>> > keycloak-user mailing list
>>>> > keycloak-user(a)lists.jboss.org
>>>> > https://lists.jboss.org/mailman/listinfo/keycloak-user
>>>> >
>>>> >
>>>> _______________________________________________
>>>> keycloak-user mailing list
>>>> keycloak-user(a)lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/keycloak-user
>>>> This message and the information contained herein is proprietary and
>>>> confidential and subject to the Amdocs policy statement,
>>>>
>>>> you may review at http://www.amdocs.com/email_disclaimer.asp
>>>>
>>>
>>>
>>
>>
>> --
>> *Adam Kaplan*
>> Senior Engineer
>> findyr <http://findyr.com/>
>> m 914.924.5186 <//914.924.5186> | e akaplan(a)findyr.com
>> WeWork c/o Findyr | 1460 Broadway | New York, NY 10036
>>
>
>
>
> --
> *Adam Kaplan*
> Senior Engineer
> findyr <http://findyr.com/>
> m 914.924.5186 <//914.924.5186> | e akaplan(a)findyr.com
> WeWork c/o Findyr | 1460 Broadway | New York, NY 10036
>
9 years
Keycloak 3.0.0.CR1 approaching
by Stian Thorgersen
Keycloak 3.0.0.CR1 is scheduled to be released on the 15th March. Please
have things ready for end of Monday 13th.
9 years
Arquillian testsuite: realm import per class now
by Marek Posolda
So testsuite-arquillian is now using the realm import per class
similarly like the old testsuite. Also there is just one adminClient and
one testingClient per class now.
This was identified as one of the two major bottlenecks (The second was
the phantomjs, which was changed to htmlUnit earlier). With both
changes, running the arquillian testsuite takes 10 minutes instead of 36
on my laptop.
There was quite a lot of changes needed to achieve this as many test
methods relied on the fact that realm is imported and didn't clean stuff
after itself.
I may not fix all the tests, especially not those, which are not
executed during default build (eg. cluster tests). In case that you
found your test is broken you can do either:
- Fix the tests to clean after itself without realm reimport needed
after every test. This is preferred way :)
- Add this to your test class:
@Override
protected boolean isImportAfterEachMethod() {
return true;
}
This is fallback to previous behaviour and will cause the import after
each test method like was before. Hopefully this option can be removed
after some time once all tests are fixed :)
For now, I needed to use it for all adapter tests (added into
AbstractAdapterTest) as some adapter tests were still failing and I
don't have much time to investigate further.. Created
https://issues.jboss.org/browse/KEYCLOAK-4517 .
Marek
9 years
min-time-between-jwks-requests Problems when running tests
by Bill Burke
Ok, I just spent 1.5 days on debugging a problem and I was ready to
throw my Laptop out of the window I was getting so frustrated.
#1 I copied code from the arquillian adapter tests to deploy my own
servlet. When running in IntelliJ, all logging messages by the servlet
and OIDC adapters were eaten and never displayed.
#2 If you have a @Deployment it deploys it in @BeforeClass and only once
for all tests run in the class
#3 I recreate/destroy my realms for every test
#4 The default "min-time-between-jwks-requests" is 10 seconds...Because
my servlet doesn't get redeployed per test, the 1st test would set up
the cache for the realm key for the servlet. The 2nd test would run,
because the realms were recreated, there is a different key, but the
min-time-between-jwkds-requests was 10 seconds so it wasn't updating the
key and my logins would fail. This was extermely frustrating to debug
because of #1 and because it only happened if I was running all tests in
the class.
The workaround is to set "min-time-between-jwks-requests" to zero in
your adapter configuration. This is an FYI just in case somebody else
runs into this. Took me awhile to figure out.
9 years
Keycloak Impersonation feature | KEYCLOAK-4219
by Ritesh Garg
Hello everyone,
As of now, Keycloak supports impersonation by an admin user at the front end application level. However, if someone is using JWT token based API security, there is no existing way to get a user's JWT token "on behalf" of the user by admin u.
I understand and agree with Stian Thorgersen that this is not just adding the return of a JWT token to the current impersonation endpoint. But I believe if keycloak supports impersonation; we should support that for API security as well and not just front-end applications.
If we decide to incorporate it; one implementation approach can be to introduce an impersonation grant type which would perform client and admin user authentication before granting a token on behalf of the user it is requested for. Please let me know if this sounds completely absurd to you guys.
Thoughts?
Thanks,
Ritesh Garg
9 years
Client adapters backwards compatibility
by Marek Posolda
It looks that we should support latest Keycloak server with older
versions of Keycloak adapters.
So for some corner scenarios, I wonder if we should add the switch to
the ClientModel and admin console like "Adapter version" . This switch
will be available for both OIDC and SAML clients, but will be useful
just for the clients, which uses Keycloak adapter. It will be useful to
specify the version of Keycloak client adapter, which particular client
application is using. WDYT?
The reason why I felt into this is a reported RHSSO bug.
Long-story short: When Keycloak SAML 1.9.8 adapter is used with
"isPassive=true", then Keycloak 2.5.4 server returns him the valid error
response. However 1.9.8 adapter has a bug
https://issues.jboss.org/browse/KEYCLOAK-4264 and it throws NPE when it
receives such response.
With SAML 1.9.8 adapter + 1.9.8 server, the Keycloak server returned
invalid error response, however 1.9.8 adapter was able to handle this
invalid response without throwing any exception.
By adding the switch to the ClientModel, we defacto allow adapter to
say: "Please return me broken response, because I am not able to handle
valid response."
Note that this is bug in adapter, so it will be better to ask customers
to rather upgrade their SAML adapters to newest version. On the other
hand, we claim to support backwards compatibility.
So should we add the switch or not? WDYT?
Marek
9 years
Bug / un-intended behaviour in jpa RealmAdapter?
by Martin Hardselius
The below piece of code seems faulty to me. Shouldn't it pass
model.getName() as the second arg to getIdentityProviderMapperByName
instead?
org.keycloak.models.jpa.RealmAdapter
@Override
public IdentityProviderMapperModel
addIdentityProviderMapper(IdentityProviderMapperModel model) {
if (getIdentityProviderMapperByName(model.getIdentityProviderAlias(),
model.getIdentityProviderMapper()) != null) {
throw new RuntimeException("identity provider mapper name must be
unique per identity provider");
}
// ...
}
Martin
9 years
