How to retrieve identity provider name in a UserStorageProvider
by Joy Kent
We have implemented a *UserStorageProvider* that stores the user
information (username, email) in an external PostgreSQL database. To be
more specific, it implements the following:
public class MyUserStorageProvider implements UserStorageProvider,
>
> UserLookupProvider,
>
> UserRegistrationProvider,
>
> UserQueryProvider
As I understand it, for identity federation, the identity provider name is
stored in keycloak through *UserFederatedStorageProvider*, which is stored
in KeycloakSession instance. My question is at the time when *addUser() *in
* MyUserStorageProvider* is called, is it possible to retrieve an
*FederatedIdentityModel* object or something similar from the
KeycloakSession instance? The main piece of information I need is the
identity provider name.
Thanks,
Joy
8 years, 1 month
Client roles in Access Token
by Henning Waack
Dear all.
Using KC 4.2.1, I get the following access token for a "Service Account
User":
{
"jti": "af460ad9-e436-481f-aa4c-2d0ee0a19878",
"exp": 1534251578,
"nbf": 0,
"iat": 1534251278,
"iss": "https://xxx/auth/realms/NAK",
"aud": "nak-portal",
"sub": "f19b3205-1f3c-4a7e-8e76-c5d8e47ef0e4",
"typ": "Bearer",
"azp": "nak-portal",
"auth_time": 0,
"session_state": "a47e50aa-2ed2-40fa-9ba7-453d5632ced0",
"name": "nak portal",
"given_name": "nak",
"family_name": "portal",
"preferred_username": "service-account-nak-portal",
"email": "service-account-nak-portal(a)placeholder.de",
"email_verified": true,
"acr": "1",
"allowed-origins": [
"http://dummy:8008"
],
"realm_access": {
"roles": [
"source_system"
]
},
"resource_access": {
"realm-management": {
"roles": [
"manage-users",
"view-users",
"query-clients",
"query-groups",
"query-users"
]
}
},
"scope": "email profile",
"clientId": "nak-portal",
"clientHost": "80.242.181.71",
"clientAddress": "80.242.181.71",
"client_id": "nak-portal",
"username": "service-account-nak-portal",
"active": true
}
Please note the five realm-management client roles. Problem is that for the
given service account I have assigned many more roles, please see attached
screenshot
Why don't I see all effective roles (or assigned roles) in my access token?
Interestingly enough I am also missing some of my realm roles. I have
mapped 4 realm roles, but in the token I only have 1. Am I missing
something?
Thanks in advance, greetings
Henning
8 years, 1 month
Fine-grained permissions along hierarchy paths
by Thomas Darimont
Hello,
I have a realm with nested groups that denotes a hierarchical corporate
structure.
/corp
-/org
--/branch1
---/divsion1
----/team1
----/team2
---/divsion2
----/team3
----/team4
--/branch2
-/infra
...
Users belong to one particular group along the /corp/org subtree, but might
also be members of one or more groups from a different subtree, e.g.,
/corp/infra.
Is it possible to have dedicated admin users at /corp, /branchX, /divisionX
level who can only view and manage the users from their group or subtree
with an admin-console scoped to a fixed realm?
admin-console scoped to group-hierarchy-demo realm:
http://localhost:8080/auth/admin/group-hierarchy-demo/console/#/realms/gr...
If a user logs in as divsion1-admin-user, he should only be able to see and
manage the users beneath the path (/corp/org/branch1/division1/*).
Does the fine-grained permission system already support use cases like this?
Cheers,
Thomas
8 years, 1 month
Re: [keycloak-user] CORS ?Access-Control-Allow-Origin? missing
by Jan Garaj
Hi,
Actually, Access-Control-Allow-Origin is not missing, because it should be
available in the preflight (OPTIONS) response and not in GET/POST response.
My assumption is that 3.4.2+ Keycloak CORS implementation is broken and it
doesn't support any JS cross-domain access at the moment.
More details: https://issues.jboss.org/browse/KEYCLOAK-8006
You can find this CORS problem also on StackOverflow:
https://stackoverflow.com/questions/51706569/angular-keycloak-cant-get-to...
Workaround: downgrade to 3.4.2- and use insecure "Web Origins": "*"
*Jan Garaj*
Web: http://www.jangaraj.com / http://monitoringartist.com
LinkedIn: http://www.linkedin.com/in/jangaraj
On Wed, Aug 15, 2018 at 8:09 AM <keycloak-user-request(a)lists.jboss.org>
wrote:
> Send keycloak-user mailing list submissions to
> keycloak-user(a)lists.jboss.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.jboss.org/mailman/listinfo/keycloak-user
> or, via email, send a message with subject or body 'help' to
> keycloak-user-request(a)lists.jboss.org
>
> You can reach the person managing the list at
> keycloak-user-owner(a)lists.jboss.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of keycloak-user digest..."
> Today's Topics:
>
> 1. CORS ?Access-Control-Allow-Origin? missing (Ryan Slominski)
> 2. How to force client to use PKCE code exchange? (Eric B)
> 3. Client roles in Access Token (Henning Waack)
>
>
>
> ---------- Forwarded message ----------
> From: Ryan Slominski <ryans(a)jlab.org>
> To: keycloak-user <keycloak-user(a)lists.jboss.org>
> Cc:
> Bcc:
> Date: Tue, 14 Aug 2018 16:21:54 -0400 (EDT)
> Subject: [keycloak-user] CORS ‘Access-Control-Allow-Origin’ missing
> Hi Keycloak Users,
>
> I'm attempting to save my users a few button clicks by automatically
> trying brokered identity providers in the background with AJAX requests
> before redirecting them to the Keycloak login form (AJAX requests using
> kc_idp_hint parameter). In most cases users will already be logged into
> one of the brokered identity providers (the client is often on one of
> several SPNEGO protected subnets) and instead of showing users the login
> form with buttons to try the brokered providers manually one by one I was
> hoping to simply do it for them in the background and when directed to the
> login form for the realm the common case would be for users to be
> immediately redirected back because they're logged in already. I'm using
> the Wildfly client adapters (Java servlet container managed security)
> configured as confidential clients. I have the client "Web Origins" set to
> "*". In the Wildfly standalone.xml I have the clients configured with
> "<enable-cors>true</enable-cors>". I'm using Keycloak!
> 4.1.0. On the client side I'm using jQuery and have "crossDomain: true"
> and "xhrFields:{withCredentials: true}" set on the XHR object. The
> keycloak server still doesn't respond with a Access-Control-Allow-Origin
> header though so the login fails. It works if not using AJAX. The
> network trace of an AJAX request from the web browser console looks like:
>
> --- Request 1 ---
> GET
> https://myhost.example.com/myapp/protected?kc_idp_hint=broker1-keycloak-o...
> Host: myhost.example.com
> User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101
> Firefox/52.0
> Accept: text/html, */*; q=0.01
> Accept-Language: en-US,en;q=0.5
> Accept-Encoding: gzip, deflate, br
> Referer: https://myhost.example.com/myapp/mypage
> Cookie: OAuth_Token_Request_State=<REDACTED>; JSESSIONID=<REDACTED>.myhost
> Connection: keep-alive
>
> --- Response 1 ---
> Cache-Control: no-cache, no-store, must-revalidate
> Connection: Keep-Alive
> Content-Length: 0
> Date: Tue, 14 Aug 2018 19:48:46 GMT
> Expires: 0
> Keep-Alive: timeout=5, max=100
> Location:
> https://keycloak1.example.com/auth/realms/myrealm/protocol/openid-connect...
> <REDACTED>&login=true&kc_idp_hint=broker1-keycloak-oidc&scope=openid
> Pragma: no-cache
> Server: WildFly/11
> Set-Cookie: OAuth_Token_Request_State=<REDACTED>; HttpOnly
> X-Powered-By: Undertow/1
>
> --- Request 2 ---
> GET
> https://keycloak1.example.com/auth/realms/myrealm/protocol/openid-connect...
> <REDACTED>&login=true&kc_idp_hint=broker1-keycloak-oidc&scope=openid
> Host: keycloak1.example.com
> User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101
> Firefox/52.0
> Accept: text/html, */*; q=0.01
> Accept-Language: en-US,en;q=0.5
> Accept-Encoding: gzip, deflate, br
> Referer: https://myhost.example.com/myapp/mypage
> Origin: https://myhost.example.com
> Cookie: AUTH_SESSION_ID=<REDACTED>.keycloak1; KC_RESTART=<REDACTED>
> Connection: keep-alive
>
> --- Response 2 ---
> Status: 401
> Cache-Control: no-store, must-revalidate, max-age=0
> Connection: Keep-Alive
> Content-Length: 615
> Content-Type: text/html;charset=UTF-8
> Date: Tue, 14 Aug 2018 19:48:48 GMT
> Keep-Alive: timeout=5, max=100
> Server: Apache/2.4.6 (Red Hat Enterprise Linux) OpenSSL/1.0.2k-fips
> mod_auth_kerb/5.4 PHP/7.1.18 mod_wsgi/3.4 Python/2.7.5
> Set-Cookie: AUTH_SESSION_ID=<REDACTED>.keycloak1; Version=1;
> Path=/auth/realms/myrealm/; Secure; HttpOnly
> KC_RESTART=<REDACTED>; Version=1; Path=/auth/realms/myrealm/; Secure;
> HttpOnly
> WWW-Authenticate: Negotiate
>
> --- Request 3 ---
> GET
> https://keycloak1.example.com/auth/realms/myrealm/protocol/openid-connect...
> <REDACTED>&login=true&kc_idp_hint=broker1-keycloak-oidc&scope=openid
> Host: keycloak1.example.com
> User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101
> Firefox/52.0
> Accept: text/html, */*; q=0.01
> Accept-Language: en-US,en;q=0.5
> Accept-Encoding: gzip, deflate, br
> Referer: https://myhost.example.com/myapp/mypage
> Origin: https://myhost.example.com
> Cookie: AUTH_SESSION_ID=<REDACTED>.keycloak1; KC_RESTART=<REDACTED>
> Connection: keep-alive
> Authorization: Negotiate <REDACTED>
>
> --- Response 3 ---
> Cache-Control: no-store, must-revalidate, max-age=0
> Connection: Keep-Alive
> Content-Length: 0
> Date: Tue, 14 Aug 2018 19:48:48 GMT
> Keep-Alive: timeout=5, max=99
> Location:
> https://keycloak1.example.com/auth/realms/myrealm/broker/broker1-keycloak...
> <REDACTED>&client_id=client1&tab_id=FP3hTW-bfQ8
> Server: Apache/2.4.6 (Red Hat Enterprise Linux) OpenSSL/1.0.2k-fips
> mod_auth_kerb/5.4 PHP/7.1.18 mod_wsgi/3.4 Python/2.7.5
> Set-Cookie: AUTH_SESSION_ID=<REDACTED>.keycloak1; Version=1;
> Path=/auth/realms/myrealm/; Secure; HttpOnly
> KC_RESTART=<REDACTED>; Version=1; Path=/auth/realms/myrealm/; Secure;
> HttpOnly
>
> Notice I must redirect off a protected URL on my client app since Wildfly
> client adapter only works on pages which are explicitly protected by the
> container managed security. Also notice in the third and final request the
> response is missing the Access-Control-Allow-Origin header, which results
> in the error in the browser web console and the process ending. Any ideas?
>
> Thanks,
>
> Ryan
>
>
>
>
>
> ---------- Forwarded message ----------
> From: Eric B <ebenzacar(a)gmail.com>
> To: keycloak-user(a)lists.jboss.org
> Cc:
> Bcc:
> Date: Tue, 14 Aug 2018 23:23:57 -0400
> Subject: [keycloak-user] How to force client to use PKCE code exchange?
> I'm using keycloak 3.4.3. Is there a way in the client configuration to
> require PKCE code exchange? I can't seem to find an option that would
> require to support this vs just the standard code exchange flow.
>
> Thanks
>
> Eric
>
>
>
>
> ---------- Forwarded message ----------
> From: Henning Waack <henning.waack(a)codecentric.de>
> To: keycloak-user(a)lists.jboss.org
> Cc:
> Bcc:
> Date: Wed, 15 Aug 2018 09:08:41 +0200
> Subject: [keycloak-user] Client roles in Access Token
> Dear all.
>
> Using KC 4.2.1, I get the following access token for a "Service Account
> User":
>
> {
> "jti": "af460ad9-e436-481f-aa4c-2d0ee0a19878",
> "exp": 1534251578,
> "nbf": 0,
> "iat": 1534251278,
> "iss": "https://xxx/auth/realms/NAK",
> "aud": "nak-portal",
> "sub": "f19b3205-1f3c-4a7e-8e76-c5d8e47ef0e4",
> "typ": "Bearer",
> "azp": "nak-portal",
> "auth_time": 0,
> "session_state": "a47e50aa-2ed2-40fa-9ba7-453d5632ced0",
> "name": "nak portal",
> "given_name": "nak",
> "family_name": "portal",
> "preferred_username": "service-account-nak-portal",
> "email": "service-account-nak-portal(a)placeholder.de",
> "email_verified": true,
> "acr": "1",
> "allowed-origins": [
> "http://dummy:8008"
> ],
> "realm_access": {
> "roles": [
> "source_system"
> ]
> },
> "resource_access": {
> "realm-management": {
> "roles": [
> "manage-users",
> "view-users",
> "query-clients",
> "query-groups",
> "query-users"
> ]
> }
> },
> "scope": "email profile",
> "clientId": "nak-portal",
> "clientHost": "80.242.181.71",
> "clientAddress": "80.242.181.71",
> "client_id": "nak-portal",
> "username": "service-account-nak-portal",
> "active": true
> }
>
> Please note the five realm-management client roles. Problem is that for the
> given service account I have assigned many more roles, please see attached
> screenshot
>
> Why don't I see all effective roles (or assigned roles) in my access token?
> Interestingly enough I am also missing some of my realm roles. I have
> mapped 4 realm roles, but in the token I only have 1. Am I missing
> something?
>
> Thanks in advance, greetings
>
> Henning
> _______________________________________________
> keycloak-user mailing list
> keycloak-user(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user
8 years, 1 month
How to force client to use PKCE code exchange?
by Eric B
I'm using keycloak 3.4.3. Is there a way in the client configuration to
require PKCE code exchange? I can't seem to find an option that would
require to support this vs just the standard code exchange flow.
Thanks
Eric
8 years, 1 month
CORS ‘Access-Control-Allow-Origin’ missing
by Ryan Slominski
Hi Keycloak Users,
I'm attempting to save my users a few button clicks by automatically trying brokered identity providers in the background with AJAX requests before redirecting them to the Keycloak login form (AJAX requests using kc_idp_hint parameter). In most cases users will already be logged into one of the brokered identity providers (the client is often on one of several SPNEGO protected subnets) and instead of showing users the login form with buttons to try the brokered providers manually one by one I was hoping to simply do it for them in the background and when directed to the login form for the realm the common case would be for users to be immediately redirected back because they're logged in already. I'm using the Wildfly client adapters (Java servlet container managed security) configured as confidential clients. I have the client "Web Origins" set to "*". In the Wildfly standalone.xml I have the clients configured with "<enable-cors>true</enable-cors>". I'm using Keycloak 4.1.0. On the client side I'm using jQuery and have "crossDomain: true" and "xhrFields:{withCredentials: true}" set on the XHR object. The keycloak server still doesn't respond with a Access-Control-Allow-Origin header though so the login fails. It works if not using AJAX. The network trace of an AJAX request from the web browser console looks like:
--- Request 1 ---
GET https://myhost.example.com/myapp/protected?kc_idp_hint=broker1-keycloak-o...
Host: myhost.example.com
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Firefox/52.0
Accept: text/html, */*; q=0.01
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate, br
Referer: https://myhost.example.com/myapp/mypage
Cookie: OAuth_Token_Request_State=<REDACTED>; JSESSIONID=<REDACTED>.myhost
Connection: keep-alive
--- Response 1 ---
Cache-Control: no-cache, no-store, must-revalidate
Connection: Keep-Alive
Content-Length: 0
Date: Tue, 14 Aug 2018 19:48:46 GMT
Expires: 0
Keep-Alive: timeout=5, max=100
Location: https://keycloak1.example.com/auth/realms/myrealm/protocol/openid-connect...<REDACTED>&login=true&kc_idp_hint=broker1-keycloak-oidc&scope=openid
Pragma: no-cache
Server: WildFly/11
Set-Cookie: OAuth_Token_Request_State=<REDACTED>; HttpOnly
X-Powered-By: Undertow/1
--- Request 2 ---
GET https://keycloak1.example.com/auth/realms/myrealm/protocol/openid-connect...<REDACTED>&login=true&kc_idp_hint=broker1-keycloak-oidc&scope=openid
Host: keycloak1.example.com
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Firefox/52.0
Accept: text/html, */*; q=0.01
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate, br
Referer: https://myhost.example.com/myapp/mypage
Origin: https://myhost.example.com
Cookie: AUTH_SESSION_ID=<REDACTED>.keycloak1; KC_RESTART=<REDACTED>
Connection: keep-alive
--- Response 2 ---
Status: 401
Cache-Control: no-store, must-revalidate, max-age=0
Connection: Keep-Alive
Content-Length: 615
Content-Type: text/html;charset=UTF-8
Date: Tue, 14 Aug 2018 19:48:48 GMT
Keep-Alive: timeout=5, max=100
Server: Apache/2.4.6 (Red Hat Enterprise Linux) OpenSSL/1.0.2k-fips mod_auth_kerb/5.4 PHP/7.1.18 mod_wsgi/3.4 Python/2.7.5
Set-Cookie: AUTH_SESSION_ID=<REDACTED>.keycloak1; Version=1; Path=/auth/realms/myrealm/; Secure; HttpOnly
KC_RESTART=<REDACTED>; Version=1; Path=/auth/realms/myrealm/; Secure; HttpOnly
WWW-Authenticate: Negotiate
--- Request 3 ---
GET https://keycloak1.example.com/auth/realms/myrealm/protocol/openid-connect...<REDACTED>&login=true&kc_idp_hint=broker1-keycloak-oidc&scope=openid
Host: keycloak1.example.com
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Firefox/52.0
Accept: text/html, */*; q=0.01
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate, br
Referer: https://myhost.example.com/myapp/mypage
Origin: https://myhost.example.com
Cookie: AUTH_SESSION_ID=<REDACTED>.keycloak1; KC_RESTART=<REDACTED>
Connection: keep-alive
Authorization: Negotiate <REDACTED>
--- Response 3 ---
Cache-Control: no-store, must-revalidate, max-age=0
Connection: Keep-Alive
Content-Length: 0
Date: Tue, 14 Aug 2018 19:48:48 GMT
Keep-Alive: timeout=5, max=99
Location: https://keycloak1.example.com/auth/realms/myrealm/broker/broker1-keycloak...<REDACTED>&client_id=client1&tab_id=FP3hTW-bfQ8
Server: Apache/2.4.6 (Red Hat Enterprise Linux) OpenSSL/1.0.2k-fips mod_auth_kerb/5.4 PHP/7.1.18 mod_wsgi/3.4 Python/2.7.5
Set-Cookie: AUTH_SESSION_ID=<REDACTED>.keycloak1; Version=1; Path=/auth/realms/myrealm/; Secure; HttpOnly
KC_RESTART=<REDACTED>; Version=1; Path=/auth/realms/myrealm/; Secure; HttpOnly
Notice I must redirect off a protected URL on my client app since Wildfly client adapter only works on pages which are explicitly protected by the container managed security. Also notice in the third and final request the response is missing the Access-Control-Allow-Origin header, which results in the error in the browser web console and the process ending. Any ideas?
Thanks,
Ryan
8 years, 1 month
Problem Integration with OAuth2 provider
by Graham Burgess
I am trying to use Keycloak to broker our internally managed OAuth2 provider. I am unable to get it complete the "First Broker Login" workflow. The logs show "No token from server" as an error but I have thus far being able to get my Google-fu to help me figure out what the issue might be.
I even went as far as looking at the code based on the stack trace and that would suggest that it is looking for an id_token, but my understanding for response_type=code as chosen by Keycloak, id_token isn't returned. I suspect I am doing something wrong but I don't know what and I am at a point that I don't know where to look to figure it out.
I have looked at the different requests as they go through the workflow and can see all the redirects, etc. but it hasn't shown anything that has help me either. Anyone have any suggestions on how to proceed with troubleshooting this issue?
Best regards,
Graham Burgess
RΛZΞR|stormmore
Sr. DevOps Engineer (USA)
Email: graham.burgess(a)razer.com
DID: (415) 374 0639
[http://assets.razerzone.com/email/email-sig.jpg]
Razer.com<https://www.razer.com/> | Razer Game Store<https://gamestore.razer.com/> | Razer Insider<https://insider.razer.com/> | Razer zVault<https://zvault.razer.com/>
[https://upload.wikimedia.org/wikipedia/commons/thumb/c/c2/F_icon.svg/200p...]<https://www.facebook.com/Razer> [Twitter_Social_Icon_Rounded_Square_Color] <https://twitter.com/Razer> [glyph-logo_May2016] <https://www.instagram.com/razer/> [youtube_social_squircle_red] <https://www.youtube.com/Razer?sub_confirmation=1>
Razer Inc. (San Francisco)
201 3rd Street, Suite 900
San Francisco CA 94103, USA
Tel: +1 (415) 266 5300
Razer Inc. Stock Code: 1337.HK
IMPORTANT NOTICE: This e-mail may be confidential, legally privileged or otherwise protected from disclosure. If you are not an intended recipient, do not copy, distribute or use its contents. Do inform the sender that you have received the message in error and delete it from your system. E-mails are not secure and may suffer errors, computer viruses, delay, interception and amendment. Razer accepts neither risk nor liability for any damage or loss caused by this e-mail. To the extent permitted by applicable law, Razer reserves the right to retain, monitor and intercept e-mails to and from its systems.
8 years, 1 month
Re: [keycloak-user] How to logout
by Ryan Slominski
Hi Stan,
I'm not sure if it is an issue or just the way it is supposed to work. Again, HttpServletRequest.logout() does work when the servlet container itself believes a user is logged in. The case in which it appears to be a no-op is when the servlet container is not aware of any login. This might be okay? Not sure? The problem is that a user can be logged into Keycloak, but not logged into the servlet container. In this case how do I log the user out? Perhaps I should use the alternative method, the URL: https://authserver/auth/{realm-name}/protocol/openid-connect/logout?redir... However, having a logout anchor (link) that navigates to that URL does not destroy the Keycloak login. Perhaps I need to add some authentication header, bearer token, or something else along with the GET HTTP request? Watching the network requests using the developer console of a web browser I see that even after the logout request to Keycloak if I attempt a login immediately after I see the KC_RESTART cookie is used (so a token must still exist?) and I am logged in automatically without being prompted for username or password - so... the logout URL didn't seem to work.
Thanks,
Ryan
----- Original Message -----
From: "Stan Silvert" <ssilvert(a)redhat.com>
To: "keycloak-user" <keycloak-user(a)lists.jboss.org>
Sent: Monday, August 13, 2018 7:15:15 PM
Subject: Re: [keycloak-user] How to logout
HttpServletRequest.logout() should not be a no-op. It was implemented a
long time ago:
https://urldefense.proofpoint.com/v2/url?u=https-3A__issues.jboss.org_bro...
If there is an issue with it you should report it in JIRA.
Stan
On 8/13/2018 4:19 PM, Ryan Slominski wrote:
> Hi Keycloak Users,
>
> I'm using the Wildfly client adapter and trying to logout of Keycloak, even if a client application container doesn't think it is logged in. This is a problem because login state with Keycloak and login state with JSESSION_ID in servlet container are two separate things that can get out-of-sync. The documentation says you can logout in one of two ways:
>
> 1. Call HttpServletRequest.logout()
> 2. Navigate to URL https://urldefense.proofpoint.com/v2/url?u=http-3A__auth-2Dserver_auth_re... {realm-name}/protocol/openid-connect/logout?redirect_uri=encodedRedirectUri
>
> See: https://urldefense.proofpoint.com/v2/url?u=https-3A__www.keycloak.org_doc...
>
> The first appears to be a no-op because the Java container itself isn't logged in, in this case. This does work if the client container is aware that it is logged in, but doesn't otherwise. The second also doesn't seem to do anything and just redirects back to redirect_uri. Any tips?
>
> A forceful logout is useful in the scenario when one client (client A) logs into Keycloak, and a different client (cilent B) wants to forcefully logout as to switch users. In this scenario client B doesn't think it is logged in because the client adapter is using container managed security with JSESSIONID, and locally the client isn't logged in. However if a login was attempted it would succeed automatically without prompting for a username and password and therefore the user wouldn't get a chance to provide an alternate username. A switch user ability is useful when users need to login with separate admin credentials or also in scenarios where a user says "move over and I'll drive" to a colleague.
>
> Thanks,
>
> Ryan
> _______________________________________________
> keycloak-user mailing list
> keycloak-user(a)lists.jboss.org
> https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.jboss.org_mail...
_______________________________________________
keycloak-user mailing list
keycloak-user(a)lists.jboss.org
https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.jboss.org_mail...
8 years, 1 month
Keycloak configuring SAML clients
by Rafael Weingärtner
Hello Keycloakers,
I am trying to integrate Keycloak with an SP using SAML. I downloaded
keycloak metadata using
https://<server>/auth/realms/<realmName>/protocol/saml/descriptor.
I configured this metadata in my metadata provider (for the whole
federation). The SPs now can see the IdP (Keycloak). How do I configure
Keycloak to use my federation metadata? I mean, instead of configuring
each client manually, keycloak could read this descriptor file, and get the
Keys (public keys of service provides) and URLs from there. At least that
is how we are used to do when using Shibboleth.
--
Rafael Weingärtner
8 years, 1 month
Staging Configuration
by Gregor Tudan
Hi!
We are running a multi-tenant setup and therefore have a lot of realms which are identical to one another in terms of clients - the only differences are the urls.
This leaves us with two challenges:
- how can we sync the settings of the realms (i.e. when adding a new client).
- how can we sync the settings of the realms to different stages (development, test, production…)
Has anybody faced similar problems and found a nice solution?
Our best idea is to script as many changes as possible through the admin-client, but comparing different realms and instances would be nice as well.
Thank you,
Gregor
8 years, 1 month
