Silent Login for SPA
by Gregor Tudan
Hi everyone,
After reading https://tools.ietf.org/html/draft-ietf-oauth-browser-based-apps on how to secure SPAs with OAuth I would like to implement the measures outlined there. I know it’s still a draft, but the arguments stated there make a lot of sense - including that doing OAuth in the browser only should only be considered if session based auth or some kind of backend (like gatekeeper) is not an option.
Here’s what the draft suggests:
* use public clients only as one cannot keep secrets private (easy)
* Use the Code-Flow with PKCE to secure the token exchange (possible with the JS-Adapter from v7)
* Don’t expose the refresh token to the client (I don’t think that’s possible with the code flow today).
* If this is not possible return a new refresh token on every refresh invalidating the old one.
* Don’t use Implicit flow - it safes roundtrips but is vulnerable to numerous attacks (easy - see above)
So while a lot has been done, there still seems to be the issue about the refresh tokens.
First off, I’m not sure how to obtain an access token only during the Access Token Request - while the spec states that the refresh token is optional, there is no parameter defined to communicate this kind of behavior to the auth server. Can this be configured in the client?
Let’s say I managed to obtain an access token. The second issue is: how can I refresh it without a refresh token? It was suggested to use the session with the Auth-Server for this, but with the current Javascript-Adapter this would mean doing a full reload every two minutes and having to reboot the SPA. This is not practical.
The other option would be to do this in an iframe with promt=none. A similar approach was supposed and implemented in https://issues.jboss.org/browse/KEYCLOAK-6795 (Silent Authentication in Iframe for Implicit Flow), but abandoned due to the usage of the implicit flow. Stian suggested to use the code flow with PKCE instead, but this would mean picking having to do an extra call inside the iframe.
I’m happy to work on something similar for PKCE, but before starting I would like to make sure that this kind of feature makes sense and has a chance to get accepted.
- Gregor
7 years
Scalability Problems with the admin console
by Gregor Tudan
Hi there,
We are running a Keycloak instance with quiet a lot of realms (~400 and growing) and are starting to get into the dreaded scalability issue of the admin console (https://issues.jboss.org/browse/KEYCLOAK-6096). I’ve been watching the issue for quiet a while now and you made it clear that this isn’t a top priority at the moment.
The issue is flagged with „Awaiting volunteers“ and I’d love to contribute.
The design proposed by the reporter sounds reasonable. There would have to be some changes to the whoami-API (which seems to be exclusively used by the console). The Realms-API would need pagination, which could be kept backwards compatible. There’s already a page in the admin-ui for realm-selection that we could add pagination to: https://service-e.tech.visualvest.de/auth/admin/master/console/#/realms
What do you think? Can I go ahead and give it a try?
Thanks,
Gregor
7 years
issues with building keycloak master
by Federico Michele Facca
Hi,
I have been trying to build the master branch using:
mvn install -Dmaven.test.skip
The installation fails at the last project:
[*INFO*] SSSD tests .........................................
*FAILURE* [ 0.586
s]
[*INFO*]
*------------------------------------------------------------------------*
[*INFO*] *BUILD FAILURE*
[*INFO*]
*------------------------------------------------------------------------*
[*INFO*] Total time: 03:53 min
[*INFO*] Finished at: 2019-07-24T10:50:40+02:00
[*INFO*]
*------------------------------------------------------------------------*
[*ERROR*] Failed to execute goal on project
integration-arquillian-tests-sssd: *Could not resolve dependencies for
project
org.keycloak.testsuite:integration-arquillian-tests-sssd:jar:8.0.0-SNAPSHOT:
Could not find artifact
org.keycloak.testsuite:integration-arquillian-tests-base:jar:tests:8.0.0-SNAPSHOT*
-> *[Help 1]*
I am now trying without skipping tests (which takes quite some time, I will
update you later if that works), but in general I suppose this should work
also with skipping them.
Thanks for any hint on the matter!
Cheers,
Federico
--
*Dr. FEDERICO MICHELE FACCA*
*CTO, Head of Martel Lab*
+41 788075838
*MARTEL INNOVATE* <https://www.martel-innovate.com/> - INNOVATION, WE MAKE
IT HAPPEN
Click *HERE* to download Martel reports and white papers!
<https://www.martel-innovate.com/premium-content/>
Follow us on *TWITTER* <https://twitter.com/Martel_Innovate>
7 years
Realm Default Groups ... ?
by Lennart Jörelid
Hello all,
I have a rich, external User Model and want to use KeyCloak to handle
Authentication (and maybe even Authorization) for a suite of services using
that User Model. The existing user model contains all the elements required
by Keycloak (User, Group, Role, Realm etc.) - and hence I have created what
I believe to be required for such Keycloak integration, namely:
1. UserProviderFactory
2. UserProvider (which implements UserStorageProvider,
UserLookupProvider, UserQueryProvider, CredentialInputValidator,
CredentialInputUpdater) as outlined in the Keycloak documentation
3. UserModel implementation
4. GroupModel implementation
5. RoleModel implementation
This means I can fetch the data required to populate the admin GUI for a
single user - but I now want to populate some Realm Groups with data from
the external system in a similar manner. The data master for these Groups
and Roles is still the external system, so changes within that system
should be reflected into KeyCloak when they are done. There seems to be no
documentation on how to echo (Realm) Groups and Roles into KeyCloak in the
Keycloak Documentation - at least not in a similar way as Chapter 11 in the
Server Development documentation.
Hence, I have a few questions:
1. Do I need to create a custom RealmProvider and Realm implementation
to mirror Group data/state from an external system to KeyCloak this?
2. Is the recommended way to use existing implementations of Groups and
Users to implement the *UserFederatedStorageProvider* instead?
3. The RealmModel interface contains a suite of method definitions such
as "getTopLevelGroups" which retrieve GroupModel objects. I simply want to
implement some of these methods to fetch group information from the
external system. However, the RealmModel is created by KeyCloak, and I have
failed to understand how I can change its implementation ... short of
re-implementing the RealmModel and supplying a "RealmStorageProviderFactory
/ RealmProvider
Also, the specification interfaces in keycloak-server-spi are rather anemic
- no comments and rather difficult to realize which ones and which paradigm
should be used. There is no comments at all on any of the specification
interfaces in package org.keycloak.storage.federated, which means it is
hard to understand when they should or should not be used.
--
+==============================+
| Bästa hälsningar,
| [sw. "Best regards"]
|
| Lennart Jörelid
| EAI Architect & Integrator
|
| jGuru Europe AB
| Mölnlycke - Kista
|
| Email: lj(a)jguru.se
| URL: www.jguru.se
| Phone
| (skype): jgurueurope
| (intl): +46 708 507 603
| (domestic): 0708 - 507 603
+==============================+
7 years
How to get refresh keys from Google Identity Provider?
by Nick Powers
Hello,
I have Keycloak configured and working with Google Identity Provider. I
have configured the Default Scope of
https://www.googleapis.com/auth/youtube.force-ssl.
It seems that Google is getting that scope because when I authenticate
against Keyclock, Google is asking me for the permissions that match that
scope.
>From there I am able to get the user's access token through the Keycloak
API. What I cannot get is the Google refresh token. My understanding is
to get the refresh token from Google access_type=offline needs to be
appended to the Google Auth URL.
I have been unable to find how I can get Keycloak to
append access_type=offline to the URL so I can gain access to the Google
refresh token, for offline access.
Does anyone know what I need to do to have Keycloak request that offline
access so I can retrieve the Google refresh token?
Thanks for your help!
Nick
7 years
Re: [keycloak-dev] Supporting multiple front-end channels (KEYCLOAK-6073)
by Luke McDougall
Ok, I'll give that a try thanks.
Would you be interested in an enhancement to the adapter which allows
configuring a list of valid issuer URLs through the keycloak.json file so
that this same behaviour can be achieved without using a custom
KeycloakConfigResolver? We could probably provide this.
Also, I noticed I should have been doing reply-all, so I've added
keycloak-dev back to the 'cc' list.
Luke
On Fri, Jul 19, 2019 at 3:52 AM Stian Thorgersen <sthorger(a)redhat.com>
wrote:
>
>
> On Thu, 18 Jul 2019 at 22:24, Luke McDougall <luke.mcdougall(a)gmail.com>
> wrote:
>
>> Hi...thanks for continuing to help me with this. I didn't know there was
>> a way to do this with existing functionality. Here's what I think you're
>> suggesting:
>>
>>
>> SERVER SIDE
>>
>> Currently we're using the default 'Request' hostname provider. I know
>> this is not recommended, but if I understand this properly then it will
>> work without any changes. But we should either (a) setup an undertow
>> filter to prevent invalid hostnames, or (b) develop a custom hostname
>> provider that will make sure only valid hostnames are used.
>>
>>
>> CLIENT SIDE
>>
>> On the backend services, where the Keycloak adapter is used, I would
>> implement a KeycloakConfigResolver as described here:
>> https://www.keycloak.org/docs/latest/securing_apps/index.html#_multi_tenancy
>>
>> This resolver would:
>>
>> 1. determine which URL the client used when acquiring the JWT token
>> (i.e., determine the token issuer). This can be determined by (a) looking
>> at the issuer in the token itself or (b) by looking at the Host header used
>> to reach the backend server.
>> 2. if the issuer from step 1 is valid, the resolver would return a
>> KeycloakDeployment with realmInfoUrl set to the appropriate issuer URL
>>
>> This would allow the token to pass the TokenVerifier.RealmUrlCheck test.
>>
>> And I would also need the changes in the PR submitted by Luca Graf to
>> KEYCLOAK-6073 which allows specifying a back-channel URL by which the
>> adapter would contact the Keycloak server. This is required because the
>> URL used by clients (e.g., external.myapp.net) may not be resolvable
>> from the backend service.
>>
>>
>> Does that sound right?
>>
>
> Yes, that should do the trick
>
>
>>
>>
>> Luke
>>
>>
>>
>>
>> On Thu, Jul 18, 2019 at 8:49 AM Stian Thorgersen <sthorger(a)redhat.com>
>> wrote:
>>
>>> You can still achieve that by having a custom hostname provider to allow
>>> both 'loadbalancer.intra.myapp.net' and 'external.myapp.net'. Then on
>>> the client side you can use multi-tenancy to allow the adapters to accept
>>> tokens both from 'loadbalancer.intra.myapp.net' and 'external.myapp.net
>>> '.
>>>
>>> On Wed, 17 Jul 2019 at 17:33, Luke McDougall <luke.mcdougall(a)gmail.com>
>>> wrote:
>>>
>>>> Hi... there's still some misunderstanding of the situation I'm
>>>> describing so I'll try to clarify.
>>>>
>>>> We do not use multi-tenancy. Each customer has their own Kubernetes
>>>> cluster running in their own private data center. Keycloak and our product
>>>> microservices are running in the Kubernetes cluster. There is only one
>>>> Keycloak realm.
>>>>
>>>> A customer has multiple users who may need to access the Kubernetes
>>>> cluster through different DNS names. For example on-site users point their
>>>> browsers at loadbalancer.intra.myapp.net, but off-site users point
>>>> their browsers at external.myapp.net. Both sets of users are
>>>> connecting to the same Kubernetes cluster and same Keycloak realm but end
>>>> of with different 'issuers' in the JWT token.
>>>>
>>>> We need a way for our backend services that use the keycloak adapter to
>>>> accept both 'loadbalancer.intra.myapp.net' and 'external.myapp.net' as
>>>> valid issuers.
>>>>
>>>> I'm not sure this is a corner case as we've had requirements like this
>>>> from multiple customers.
>>>>
>>>> Thanks...
>>>>
>>>>
>>>> Luke
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> On Wed, Jul 17, 2019 at 9:46 AM Stian Thorgersen <sthorger(a)redhat.com>
>>>> wrote:
>>>>
>>>>> As I mentioned this is unrelated and out of scope of KEYCLOAK-6073.
>>>>> That issue is simply about allowing adapters to communicate with Keycloak
>>>>> using an internal IP, rather than with the public URL. In cases where the
>>>>> application and Keycloak is on the same internal network. As such this
>>>>> should not hold up that work.
>>>>>
>>>>> I believe this is a corner case and not a common scenario so it may
>>>>> not be something we want to support directly, but rather something we
>>>>> should find some way for you to achieve.
>>>>>
>>>>> I don't fully understand your issue though as say you have two
>>>>> customers:
>>>>>
>>>>> * Customer A uses keycloak.customerA.com, app.customerA.com,
>>>>> service.customerA.com, etc
>>>>> * Customer B uses keycloak.customerB.com, app.customerB.com,
>>>>> service.customerB.com, etc
>>>>>
>>>>> In that case you could use the multi-tenancy support in the adapters
>>>>> to provide different frontend/backend URLs for Keycloak depending on the
>>>>> incoming request. If it's app.customerA.com, then it's
>>>>> keycloak.customerA.com, etc.. You would also need to have a custom
>>>>> hostname provider for Keycloak.
>>>>>
>>>>> I assume you have different realms as well for the different
>>>>> customers? If so you have different token issuers regardless right? Also,
>>>>> you are probably already using the multi-tenancy option or have different
>>>>> instances of the apps/services per-customer?
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Wed, 17 Jul 2019 at 15:00, Luke McDougall <luke.mcdougall(a)gmail.com>
>>>>> wrote:
>>>>>
>>>>>> Hi... I'd like to continue a discussion regarding supporting multiple
>>>>>> public realm URLs that was started on
>>>>>> https://issues.jboss.org/browse/KEYCLOAK-6073.
>>>>>>
>>>>>> We are using Keycloak to support single-sign on to our suite of
>>>>>> products.
>>>>>> Our products run in a Kubernetes cluster; we deploy a Kubernetes
>>>>>> cluster
>>>>>> into our customers data centers to host our products. The products
>>>>>> consist
>>>>>> of microservices built on Widlfy, NGINX, Spring Boot, and others. We
>>>>>> use
>>>>>> NGINX ingress controllers as the entry point into the cluster.
>>>>>>
>>>>>> Users may access the products through multiple DNS names and/or IP
>>>>>> addresses; this is driven by each customers requirements. For
>>>>>> example,
>>>>>> regular customer employees may access the cluster using a
>>>>>> loadbalancer DNS
>>>>>> name while external contractors may need to connect via a VPN and are
>>>>>> required to use a different DNS name (maybe to a different
>>>>>> loadbalancer).
>>>>>> In other cases multiple IP (or VIP) addresses are used. All users are
>>>>>> logging into the same Keycloak realm.
>>>>>>
>>>>>> The result is that the 'issuer' in the JWT tokens is different
>>>>>> depending on
>>>>>> how the user is required to access the cluster; we need the Keycloak
>>>>>> adapter in our backend services to accept each of these possible
>>>>>> issuers.
>>>>>>
>>>>>> We have developed proof-of-concept changes in the Keycloak adapter to
>>>>>> solve
>>>>>> this by allowing us to specify a list of valid realm URLs in the
>>>>>> keycloak.json file used by the adapter. Our intent was to submit
>>>>>> this as a
>>>>>> pull request for KEYCLOAK-6073. However at the same time as we were
>>>>>> working on this, someone else submitted a pull request against
>>>>>> KEYCLOAK-6073 to support a single frontend and a single backend URL.
>>>>>>
>>>>>> I commented on the JIRA issue asking whether we could enhance this PR
>>>>>> allow
>>>>>> multiple frontend channels. I'm concerned that if this PR is merged
>>>>>> without supporting multiple frontend channels that it will be more
>>>>>> difficult to add this afterwards. However at Stian Thorgersen's
>>>>>> request I
>>>>>> have moved the conversation off JIRA and onto the mailing list.
>>>>>>
>>>>>> What do you think? Is there any reason Keycloak shouldn't support
>>>>>> multiple
>>>>>> frontend channels? We have customers that are very strict about
>>>>>> separating
>>>>>> client access as described above, and I'm not sure how else we could
>>>>>> support this with Keycloak.
>>>>>>
>>>>>> Thanks...
>>>>>>
>>>>>>
>>>>>> Luke
>>>>>> _______________________________________________
>>>>>> keycloak-dev mailing list
>>>>>> keycloak-dev(a)lists.jboss.org
>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>>>
>>>>>
7 years
SAML adapter configuration - read passwords from credential-store
by Daniel Schmidt
Hi,
I am using the SAML Adapter in Wildfly. I am configuring it via Keycloak
SAML Subsystem in standalone.xml
Currently I am trying to remove all clear-text passwords from this file.
This also applies to the password-attributes in the <KeyStore>-elements
of the SAML adapter configuration:
<KeyStore password="REMOVE_THIS"
file="${jboss.server.config.dir}\saml_keystore.jks">
<PrivateKey alias="some_alias" password="REMOVE_THIS"/>
<Certificate alias="some_alias"/>
</KeyStore>
I placed all other credentials in a credential store[1] and replaced the
password with
<credential-reference store="credential-store" alias="credential-alias"/>
I found that currently this is not possible with the SAML adapter
configuration.
Are there any plans/issues to allow the passwords to be read from a
credential store?
If there aren't any: Could you please guide me to a document on how to
create this issue and the process of submitting a PR for keycloak?
If you have any other ideas regarding this configuration, this would
also be great.
Best regards
Daniel Schmidt
[1]:
https://access.redhat.com/documentation/en-us/jboss_enterprise_applicatio...
7 years
Role mapping capabilites in SAML adapter
by Stefan Guilhen
Hi all,
I'm working on KEYCLOAK-7264 to add support for role mapping in the SAML
adapter and I wanted to discuss some of the options we have to do implement
this.
1- My first take[1] was to enhance keycloak-saml.xml to allow for the
specification of the role mappings. We already have configuration for the
attributes of the assertion that contain roles, so it seemed natural to me
to add the ability to map the extracted roles into roles that exist in the
JEE container there. Implementation was straightforward, only piece missing
is applying the same changes to the SAML subsystem that has to mirror the
configuration found in keycloak-saml.xml. This solution is portable across
containers as keycloak-saml.xml is common to all adapters.
2- We could introduce a small SPI to map roles, similar to what we have for
the ClientCredentialsProvider [2], with a default implementation that, for
example, reads the mappings from a properties file. This allows for
different implementations of a role mapper but introduces another SPI and I
believe it can be a bit overkill - if all that is required is a way to
perform some simple mapping I don't see the value of making this extensible
via an SPI.
3- Use the mapping capabilities from Elytron. In WildFly, Elytron has some
built in mappers that could probably be reused but this option is not
portable across containers. It would work for WildFly or EAP but not for
the rest (at least not OOTB and I don't see people wanting to setup Elytron
for other containers just to be able to perform some simple mappings).
Also, implementation of the subsystem becomes a little more complex with
the wiring required to get the Elytron mapper injected into the adapters.
I'm still personally inclined towards the first approach but wanted to know
your thoughts before proceeding with the subsystem changes.
[1]
https://github.com/sguilhen/keycloak/commit/bd784f38fe2dd027b076d03f90a8f...
[2]
https://github.com/keycloak/keycloak/blob/master/adapters/oidc/adapter-co...
Cheers!
--
Stefan Guilhen
Principal Software Engineer
Red Hat <https://www.redhat.com/>
sguilhen(a)redhat.com IM: sguilhen
@RedHat <https://twitter.com/redhat> Red Hat
<https://www.linkedin.com/company/red-hat> Red Hat
<https://www.facebook.com/RedHatInc>
<https://www.redhat.com/>
7 years
