August 2019 - keycloak-user - Jboss List Archives

Re: [keycloak-user] Accessing Keycloak from Okta Dashboard

by Matteo Restelli

Yeah, the idea is to use a sort of Okta bookmark with the kc_idp_hint parameter, and keep hidden the okta SAML app, and assign the bookmark & the hidden app to the users (i don't know if it's possible, i need to speak with the colleague responsible of Okta). I know it's a big workaround but maybe it can work. It's something like using an SP initiated login as it was "an IDP one" :) Thank you, Matteo On Wed, Aug 7, 2019 at 10:43 AM Tom Billiet <tom.billiet(a)airties.com> wrote: > Please keep me posted if you find anything. > > Tried myself something like that last week, but no luck. > > I could make the okta app pass the hint parameter, so that part worked. > But in the end you’re still trying to start and IDP initiated login, your > app does not understand it, but due to the hint parameter it will start an > SP initiated login. Unfortunately the change I had to do for that in okta > broke the SP initiated login flow, so in the end nothing worked anymore. > > I hope to find some more time in the coming weeks to have a better look at > it. Will keep you posted if I find something. > > > > Best regards, > > Tom > > > > *From:* Matteo Restelli <mrestelli(a)cuebiq.com> > *Sent:* Wednesday, 7 August 2019 10:27 > *To:* Tom Billiet <tom.billiet(a)airties.com> > *Cc:* keycloak-user <keycloak-user(a)lists.jboss.org> > *Subject:* Re: [keycloak-user] Accessing Keycloak from Okta Dashboard > > > > Hi Tom, > > Yeah you're right, they are two completely separated flows. > > We're currently trying to understand if it's possible to create an Okta > application which redirects to the login page with the kc_idp_hint > parameter in querystring. Specifying as a value of the parameter the name > of the configured identity provider. This should do the trick. Currently > i'm not into the Okta Configuration part so i cannot confirm that, i'll > write here if something new comes up! > > > > Thank you for your suggestions, > > Matteo > > > > On Wed, Aug 7, 2019 at 10:22 AM Tom Billiet <tom.billiet(a)airties.com> > wrote: > > Hi Matteo, > > You're talking about 2 different flows here: > * the "login with okta" button on keycloak. Then the flow is started from > keycloak and it's called SP initiated login. > * clicking the keycloak button in okta. Then the flow is started from okta > and it's called IDP initiated login > > To my understanding this will depend on what type of client you're using. > > If your client is a SAML client, you should look at IDP initiated login > section in the docs (never tried it myself): > https://www.keycloak.org/docs/latest/server_admin/index.html#idp-initiate... > On the other hand, if your client is an Openid connect/OAuth client, to my > understanding oauth does not support this and hence it's not possible > out-of-the-box. > > I'm in the same situation myself, and at the moment we've "solved" this by > not showing the keycloak button in okta (you can configure that). > However it would be much more convenient to get it working, so if anybody > has a workaround on this, I'd be happy to know. I was thinking myself if > there isn't a possibility to put a "fake" SAML client in between to handle > the IDP initiated login and then redirect to the oauth app would be an > option. But haven't found time to try it out. > > Best regards, > Tom > > -----Original Message----- > From: keycloak-user-bounces(a)lists.jboss.org < > keycloak-user-bounces(a)lists.jboss.org> On Behalf Of Matteo Restelli > Sent: Wednesday, 7 August 2019 09:46 > To: keycloak-user <keycloak-user(a)lists.jboss.org> > Subject: [keycloak-user] Accessing Keycloak from Okta Dashboard > > Hi all, > we're trying to configure Keycloak with Okta. We've no problems in > configuring the button "Login with okta" on the Keycloak login page. The > problem now is how to configure Keycloak to have the possibility to access > Keycloak from the Okta dashboard. Once we've configured the app in Okta, > we've received the following error message inside the Keycloak logs: > > 07:44:13,487 INFO > [org.jboss.aerogear.keycloak.metrics.MetricsEventListener] (default > task-4) Received user event of type IDENTITY_PROVIDER_LOGIN_ERROR in realm > master > 07:44:13,487 WARN [org.keycloak.events] (default task-4) > type=IDENTITY_PROVIDER_LOGIN_ERROR, realmId=master, clientId=null, > userId=null, ipAddress=10.1.3.6, error=invalidRequestMessage > 07:44:13,487 ERROR [org.keycloak.services.resources.IdentityBrokerService] > (default task-4) invalidRequestMessage > > We've followed this guide: > https://ultimatesecurity.pro/post/okta-saml/ > > Any thoughts on that? > > Thank you very much, > Matteo > > -- > > Like <https://www.facebook.com/cuebiq/> I Follow < > https://twitter.com/Cuebiq>I Connect < > https://www.linkedin.com/company/cuebiq> > > > This email is reserved > exclusively for sending and receiving messages inherent working > activities, and is not intended nor authorized for personal use. Therefore, > any outgoing messages or incoming response messages will be treated as > company messages and will be subject to the corporate IT policy and may > possibly to be read by persons other than by the subscriber of the box. > Confidential information may be contained in this message. If you are not > the address indicated in this message, please do not copy or deliver this > message to anyone. In such case, you should notify the sender immediately > and delete the original message. > _______________________________________________ > keycloak-user mailing list > keycloak-user(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user > > > This message has been scanned for malware by Websense. www.websense.com > > > > [image: Image removed by sender.] > > Like <https://www.facebook.com/cuebiq/> I Follow > <https://twitter.com/Cuebiq>I Connect > <https://www.linkedin.com/company/cuebiq> > > > > This email is reserved exclusively for sending and receiving messages > inherent working activities, and is not intended nor authorized for > personal use. Therefore, any outgoing messages or incoming response > messages will be treated as company messages and will be subject to the > corporate IT policy and may possibly to be read by persons other than by > the subscriber of the box. Confidential information may be contained in > this message. If you are not the address indicated in this message, please > do not copy or deliver this message to anyone. In such case, you should > notify the sender immediately and delete the original message. > > > > Click here > <https://www.mailcontrol.com/sr/NZ2Bjs_H_U_GX2PQPOmvUizKrmxxhcEGgyl_7rOGMK...> > to report this email as spam. > -- Like <https://www.facebook.com/cuebiq/> I Follow <https://twitter.com/Cuebiq>I Connect <https://www.linkedin.com/company/cuebiq> This email is reserved exclusively for sending and receiving messages inherent working activities, and is not intended nor authorized for personal use. Therefore, any outgoing messages or incoming response messages will be treated as company messages and will be subject to the corporate IT policy and may possibly to be read by persons other than by the subscriber of the box. Confidential information may be contained in this message. If you are not the address indicated in this message, please do not copy or deliver this message to anyone. In such case, you should notify the sender immediately and delete the original message.

6 years, 8 months

2
3
0 / 0

Accessing Keycloak from Okta Dashboard

by Matteo Restelli

Hi all, we're trying to configure Keycloak with Okta. We've no problems in configuring the button "Login with okta" on the Keycloak login page. The problem now is how to configure Keycloak to have the possibility to access Keycloak from the Okta dashboard. Once we've configured the app in Okta, we've received the following error message inside the Keycloak logs: 07:44:13,487 INFO [org.jboss.aerogear.keycloak.metrics.MetricsEventListener] (default task-4) Received user event of type IDENTITY_PROVIDER_LOGIN_ERROR in realm master 07:44:13,487 WARN [org.keycloak.events] (default task-4) type=IDENTITY_PROVIDER_LOGIN_ERROR, realmId=master, clientId=null, userId=null, ipAddress=10.1.3.6, error=invalidRequestMessage 07:44:13,487 ERROR [org.keycloak.services.resources.IdentityBrokerService] (default task-4) invalidRequestMessage We've followed this guide: https://ultimatesecurity.pro/post/okta-saml/ Any thoughts on that? Thank you very much, Matteo -- Like <https://www.facebook.com/cuebiq/> I Follow <https://twitter.com/Cuebiq>I Connect <https://www.linkedin.com/company/cuebiq> This email is reserved exclusively for sending and receiving messages inherent working activities, and is not intended nor authorized for personal use. Therefore, any outgoing messages or incoming response messages will be treated as company messages and will be subject to the corporate IT policy and may possibly to be read by persons other than by the subscriber of the box. Confidential information may be contained in this message. If you are not the address indicated in this message, please do not copy or deliver this message to anyone. In such case, you should notify the sender immediately and delete the original message.

6 years, 8 months

2
2
0 / 0

Authenticate against CAS server

by ext.jose.luis.anton＠altia.es

Good morning, I am working with keycloak 5.0.0 and I need to do the following: * I need to be able to invoke Keycloak using the token generation rest endpoint. * This Invocation must trigger an an authorization request against the target CAS Server * If the auth request success I should get back a jwt token. So far I have installed keycloak-protocol-cas-5.0.0.jar in my local Keycloak instance and I have tried to configure a client with the client protocl cas (but don't know where to place tue url to my cas server) How should I proceed? Thanks in advance. Best regards

6 years, 8 months

1
0
0 / 0

Re: [keycloak-user] How does the public key rotation in Keycloak work?

by Chandrashekhar, Nithin

Hi Björn, https://www.keycloak.org/docs/latest/server_admin/index.html#rotating-keys - Here is the documentation for rotating keys. Keys can be in three states active, passive and disabled. - Key in active state with the highest priority will be used for signing and validating jwt token. - If the key is passive, it will be used for validating the already issued jwt token. - If the key is disabled or deleted, jwt tokens signed with these keys will be invalidated. Thanks Nithin On 8/6/19, 11:19 PM, "keycloak-user-bounces(a)lists.jboss.org on behalf of Peemöller, Björn" <keycloak-user-bounces(a)lists.jboss.org on behalf of Bjoern.Peemoeller(a)berenberg.de> wrote: [External Email] ________________________________ Hi all, I have some questions regarding the public key rotation in Keycloak. We have an Spring Boot 2.1 application providing a rest api that is secured by Keycloak, and we occasionally get requests that are rejected with a 401 Unauthorized and the following information in the log: Failed to verify tokenorg.keycloak.exceptions.TokenNotActiveException: Token is not active at org.keycloak.TokenVerifier$2.test(TokenVerifier.java:84) at org.keycloak.TokenVerifier.verify(TokenVerifier.java:370) at org.keycloak.RSATokenVerifier.verify(RSATokenVerifier.java:89) at org.keycloak.adapters.rotation.AdapterRSATokenVerifier.verifyToken(AdapterRSATokenVerifier.java:56) at org.keycloak.adapters.rotation.AdapterRSATokenVerifier.verifyToken(AdapterRSATokenVerifier.java:37) at org.keycloak.adapters.BearerTokenRequestAuthenticator.authenticateToken(BearerTokenRequestAuthenticator.java:99) at org.keycloak.adapters.BearerTokenRequestAuthenticator.authenticate(BearerTokenRequestAuthenticator.java:84) at org.keycloak.adapters.RequestAuthenticator.authenticate(RequestAuthenticator.java:68) at org.keycloak.adapters.springsecurity.filter.KeycloakAuthenticationProcessingFilter.attemptAuthentication(KeycloakAuthenticationProcessingFilter.java:147) ... Didn't find publicKey for kid: <some kid> Failed to verify tokenorg.keycloak.common.VerificationException: Didn't find publicKey for specified kid at org.keycloak.adapters.rotation.AdapterRSATokenVerifier.getPublicKey(AdapterRSATokenVerifier.java:47) at org.keycloak.adapters.rotation.AdapterRSATokenVerifier.verifyToken(AdapterRSATokenVerifier.java:55) at org.keycloak.adapters.rotation.AdapterRSATokenVerifier.verifyToken(AdapterRSATokenVerifier.java:37) at org.keycloak.adapters.BearerTokenRequestAuthenticator.authenticateToken(BearerTokenRequestAuthenticator.java:99) at org.keycloak.adapters.BearerTokenRequestAuthenticator.authenticate(BearerTokenRequestAuthenticator.java:84) at org.keycloak.adapters.RequestAuthenticator.authenticate(RequestAuthenticator.java:68) at org.keycloak.adapters.springsecurity.filter.KeycloakAuthenticationProcessingFilter.attemptAuthentication(KeycloakAuthenticationProcessingFilter.java:147) ... We tuned our logging to have a look at the provided Bearer token, and discovered that the rejected call performed at 2019-08-07T03:00:00Z used a token which was issued at 2019-08-05T03:00:00Z and expired at 2019-08-05T11:00:00Z. Thus, the call was performed using an expired token. However, the above stack trace did not directly lead us into this direction. Obviously, the token is checked whether its active (leading to the first two errors) and its kid is verified (leading the third error). My guess is that the provided token is so old that the kid has already been removed from the Keycloak server. Could anybody explain to me how the key rotation is implemented in Keycloak? Is there a fixed interval? Are older keys kept for a while? Another question: I would expect dealing with invalid tokens to be regular business for the Keycloak client adapters, therefore I don't understand why an expired token leads to three error log entries with two stack traces. Is there a reason for this behavior I'm not aware of? Can this be configured using log settings? Personally, I rather would have expected warning level entries with a stack trace. Regards, Björn Bei Berenberg hat der Schutz Ihrer Daten seit jeher höchste Priorität. Informationen zum Umgang mit personenbezogenen Daten finden Sie hier: https://www.berenberg.de/files/Rechtliche%20Hinweise/DSGVO/DSGVO-Kundenin... Diese Nachricht einschliesslich etwa beigefuegter Anhaenge ist vertraulich und kann dem Bank- und Datengeheimnis unterliegen oder sonst rechtlich geschuetzte Daten und Informationen enthalten. Wenn Sie nicht der richtige Adressat sind oder diese Nachricht irrtuemlich erhalten haben, informieren Sie bitte sofort den Absender über die Antwortfunktion. Anschliessend moechten Sie bitte diese Nachricht einschliesslich etwa beigefuegter Anhaenge unverzueglich vollstaendig loeschen. Das unerlaubte Kopieren oder Speichern dieser Nachricht und/oder der ihr etwa beigefuegten Anhaenge sowie die unbefugte Weitergabe der darin enthaltenen Daten und Informationen sind nicht gestattet. Wir weisen darauf hin, dass rechtsverbindliche Erklaerungen namens unseres Hauses grundsaetzlich der Unterschriften zweier ausreichend bevollmaechtigter Vertreter unseres Hauses beduerfen. Wir verschicken daher keine rechtsverbindlichen Erklaerungen per E-Mail an Dritte. Demgemaess nehmen wir per E-Mail auch keine rechtsverbindlichen Erklaerungen oder Auftraege von Dritten entgegen. Sollten Sie Schwierigkeiten beim Oeffnen dieser E-Mail haben, wenden Sie sich bitte an den Absender oder an info(a)berenberg.de. Unsere Hinweise zum Schutz personenbezogener Daten finden Sie unter https://www.berenberg.de/files/Rechtliche+Hinweise/DSGVO/DSGVO-Kundeninfo.... _______________________________________________ keycloak-user mailing list keycloak-user(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-user

6 years, 8 months

2
2
0 / 0

Input field for IPD query parameter

by Romstorfer, Georg

Hi, Is it somehow possible to implement a text input field on the login page and send its value as an additional query parameter to the federated IDP? What must be done to accomplish this? Best regards, Georg

6 years, 8 months

1
0
0 / 0

AuthnRequest Customizations

by Romstorfer, Georg

Hello, We want to migrate from OpenAM to Keycloak. There are some customizations implemented in OpenAM, which we have to implement in Keycloak as well, because we cannot change all the SPs. All the SPs are using SAML at the moment. Here is a sample AuthnRequest which shows the customizations: <samlp:AuthnRequest xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" ID="s29d5b47" Version="2.0" IssueInstant="2010-03-08T12:10:48Z" AttributeConsumingServiceIndex="1"> <saml:Issuer>https://demo-sp.cryptas.com</saml:Issuer<https://demo-sp.cryptas.com%3c/saml:Issuer>> <samlp:NameIDPolicy Format="urn:com:cryptas:idp-service:names:nameid-format:PEID" AllowCreate="true" /> <samlp:RequestedAuthnContext Comparison="minimum"> <saml:AuthnContextClassRef>urn:li:llv:ida-service:names:ac:classes:assurance-level:2</saml:AuthnContextClassRef> </samlp:RequestedAuthnContext> </samlp:AuthnRequest> Here is the description of the customizations implemented for this request. It would be very helpful if you could provide me with some hint on how this could be implemented in Keycloak. 1. The AttributeConsumingServiceIndex attribute maps to a list of attributes that should be returned. 2. We are using a custom Format for the NameIDPolicy. We will also implement a custom User Storage SPI. Can I handle that format in there, or do I have to implement something else so that Keycloak can cope with it? 3. There is an AuthnContextClassRef. Its value maps to a list of IDPs which should be selectable on the Login Page. I have seen that there is a static configuration value “hideOnLoginPage” for each IDP. But we need that more dynamic and dependant on this AuthnContextClassRef value. Thanks for your help, Georg

6 years, 8 months

1
0
0 / 0

How does the public key rotation in Keycloak work?

by Peemöller, Björn

Hi all, I have some questions regarding the public key rotation in Keycloak. We have an Spring Boot 2.1 application providing a rest api that is secured by Keycloak, and we occasionally get requests that are rejected with a 401 Unauthorized and the following information in the log: Failed to verify tokenorg.keycloak.exceptions.TokenNotActiveException: Token is not active at org.keycloak.TokenVerifier$2.test(TokenVerifier.java:84) at org.keycloak.TokenVerifier.verify(TokenVerifier.java:370) at org.keycloak.RSATokenVerifier.verify(RSATokenVerifier.java:89) at org.keycloak.adapters.rotation.AdapterRSATokenVerifier.verifyToken(AdapterRSATokenVerifier.java:56) at org.keycloak.adapters.rotation.AdapterRSATokenVerifier.verifyToken(AdapterRSATokenVerifier.java:37) at org.keycloak.adapters.BearerTokenRequestAuthenticator.authenticateToken(BearerTokenRequestAuthenticator.java:99) at org.keycloak.adapters.BearerTokenRequestAuthenticator.authenticate(BearerTokenRequestAuthenticator.java:84) at org.keycloak.adapters.RequestAuthenticator.authenticate(RequestAuthenticator.java:68) at org.keycloak.adapters.springsecurity.filter.KeycloakAuthenticationProcessingFilter.attemptAuthentication(KeycloakAuthenticationProcessingFilter.java:147) ... Didn't find publicKey for kid: <some kid> Failed to verify tokenorg.keycloak.common.VerificationException: Didn't find publicKey for specified kid at org.keycloak.adapters.rotation.AdapterRSATokenVerifier.getPublicKey(AdapterRSATokenVerifier.java:47) at org.keycloak.adapters.rotation.AdapterRSATokenVerifier.verifyToken(AdapterRSATokenVerifier.java:55) at org.keycloak.adapters.rotation.AdapterRSATokenVerifier.verifyToken(AdapterRSATokenVerifier.java:37) at org.keycloak.adapters.BearerTokenRequestAuthenticator.authenticateToken(BearerTokenRequestAuthenticator.java:99) at org.keycloak.adapters.BearerTokenRequestAuthenticator.authenticate(BearerTokenRequestAuthenticator.java:84) at org.keycloak.adapters.RequestAuthenticator.authenticate(RequestAuthenticator.java:68) at org.keycloak.adapters.springsecurity.filter.KeycloakAuthenticationProcessingFilter.attemptAuthentication(KeycloakAuthenticationProcessingFilter.java:147) ... We tuned our logging to have a look at the provided Bearer token, and discovered that the rejected call performed at 2019-08-07T03:00:00Z used a token which was issued at 2019-08-05T03:00:00Z and expired at 2019-08-05T11:00:00Z. Thus, the call was performed using an expired token. However, the above stack trace did not directly lead us into this direction. Obviously, the token is checked whether its active (leading to the first two errors) and its kid is verified (leading the third error). My guess is that the provided token is so old that the kid has already been removed from the Keycloak server. Could anybody explain to me how the key rotation is implemented in Keycloak? Is there a fixed interval? Are older keys kept for a while? Another question: I would expect dealing with invalid tokens to be regular business for the Keycloak client adapters, therefore I don't understand why an expired token leads to three error log entries with two stack traces. Is there a reason for this behavior I'm not aware of? Can this be configured using log settings? Personally, I rather would have expected warning level entries with a stack trace. Regards, Björn Bei Berenberg hat der Schutz Ihrer Daten seit jeher höchste Priorität. Informationen zum Umgang mit personenbezogenen Daten finden Sie hier: https://www.berenberg.de/files/Rechtliche%20Hinweise/DSGVO/DSGVO-Kundenin... Diese Nachricht einschliesslich etwa beigefuegter Anhaenge ist vertraulich und kann dem Bank- und Datengeheimnis unterliegen oder sonst rechtlich geschuetzte Daten und Informationen enthalten. Wenn Sie nicht der richtige Adressat sind oder diese Nachricht irrtuemlich erhalten haben, informieren Sie bitte sofort den Absender über die Antwortfunktion. Anschliessend moechten Sie bitte diese Nachricht einschliesslich etwa beigefuegter Anhaenge unverzueglich vollstaendig loeschen. Das unerlaubte Kopieren oder Speichern dieser Nachricht und/oder der ihr etwa beigefuegten Anhaenge sowie die unbefugte Weitergabe der darin enthaltenen Daten und Informationen sind nicht gestattet. Wir weisen darauf hin, dass rechtsverbindliche Erklaerungen namens unseres Hauses grundsaetzlich der Unterschriften zweier ausreichend bevollmaechtigter Vertreter unseres Hauses beduerfen. Wir verschicken daher keine rechtsverbindlichen Erklaerungen per E-Mail an Dritte. Demgemaess nehmen wir per E-Mail auch keine rechtsverbindlichen Erklaerungen oder Auftraege von Dritten entgegen. Sollten Sie Schwierigkeiten beim Oeffnen dieser E-Mail haben, wenden Sie sich bitte an den Absender oder an info(a)berenberg.de. Unsere Hinweise zum Schutz personenbezogener Daten finden Sie unter https://www.berenberg.de/files/Rechtliche+Hinweise/DSGVO/DSGVO-Kundeninfo....

6 years, 8 months

1
0
0 / 0

Problem with upper case user names of Identity Provider

by David Sautter

Hello, we noticed a problem trying to use Keycloak as Identity Provider with a SAML IdP Backend. The IdP returns user names in upper case (e.g. “USER”) and keycloak converts them to lower case to store them internally (“user”), this works as expected. It also seems to store “USER” for reference in a separate field, so this information isn’t lost. Now, as soon as a user loses the session of KC and the SAML IdP, KC tries to parse the new response from the IdP trying to find “USER” in it’s database, which it doesn’t. It the triggers the first login flow, which fails because of unique key violation. Federated user not found for provider 'saml' and broker username ‘USER’ ERROR: duplicate key value violates unique constraint "constraint_40" Detail: Key (identity_provider, user_id)=(saml, <uuid removed by me>) already exists. I have the strong suspicion, that KC is missing a toLowercase() at that process somewhere. Can somebody confirm this behavior so we can turn this into a bug report? Is there a workaround for this? Kind regards, David

6 years, 8 months

1
0
0 / 0

OIDC protocol extension

by Karipineni, Neelima,M.D.

We have a use case where we’re trying to implement an OAuth2 profile which requires an extra claim on the access token when a certain auth request scope is used. The expected behavior is that when a certain scope is present in the auth endpoint request then during the Authorization flow the user is shown an extra screen where they input an identifier which ultimately is included as a claim in the access token. Details are at http://docs.smarthealthit.org/authorization/ (Standalone launch sequence) for reference. Any suggestions on how to accomplish this in keycloak? I considered using an ActionToken like in the quickstarts external action token example, but the additional execution needs to happen even when the user has previously authenticated. It’s like an additional consent step after user and client authentication rather than an additional authentication step. My current thought is to implement a custom LoginProtocol that wraps OIDCLoginProtocol, as shown in https://github.com/keycloak/keycloak/tree/openshift-integration/services/..., and have an additional redirect in the authenticated method that functions similarly to the external action token example. The callback endpoint would persist the extra claim against the client session until the access token is requested. I’m not sure it’s possible to extend the OIDC protocol within a new protocol. Preliminarily after installing a shell wrapper protocol, it’s missing the OIDC configuration properties and mappers in the admin console. Is something like this possible without copying/recreating large chunks of the OIDC code? If not, any suggestions on alternative ways to accomplish this? As an additional wrench, we’re still on v3.3.0 and upgrade is not on the schedule as of now. The information in this e-mail is intended only for the person to whom it is addressed. If you believe this e-mail was sent to you in error and the e-mail contains patient information, please contact the Partners Compliance HelpLine at http://www.partners.org/complianceline . If the e-mail was sent to you in error but does not contain patient information, please contact the sender and properly dispose of the e-mail.

6 years, 9 months

3
4
0 / 0

SAML NameID case issue

by Tony Harris

We have a client that when connected to their network internally the SAML NameID parameter comes across in all Uppercase, when they connect VIA their VPN the NameID format is in lowercase, example <NameID Format="urn:oasis:names:tc:SAML:1.1:nameid-format:WindowsDomainQualifiedName">DOMAIN\USERNAME</NameID> <NameID Format="urn:oasis:names:tc:SAML:1.1:nameid-format:WindowsDomainQualifiedName">DOMAIN\username</NameID> This causes KC to think they are two separate user and complains that a user with the same email address already exists. Is there any setting in Keycloak that I can change or does anyone have any ideas if there is an ADFS seeing that might help. P.S. This is KC 3.1.0.FInal Tony ________________________________ Please consider the environment: Think before you print! This message has been scanned for malware by Websense. www.websense.com

6 years, 9 months

1
0
0 / 0

Lots of errors in cross-datacenter replication mode with Infinispan Server 9.4.x

by Juan Antonio Farre Basurte

Hello, We've built an installation of Keycloak 6.0.1 with cross-datacenter replication using Infinispan Server 9.4.15.Final. About three minutes after starting Keycloak, we start getting lots of sequences of the following three errors: ISPN000136: Error executing command RemoveExpiredCommand on Cache 'work' ISPN000136: Error executing command RemoveCommand on Cache 'work' ISPN000071: Caught exception when handling command SingleXSiteRpcCommand Please, see the attached log for more detail. The attached log is the server.log one of the Infinispan servers. There you can see that around 17:49 the Keycloak server started and a couple of warnings regarding cache activity are shown. These warnings are normal as per Keycloak documentation troubleshooting. At 17:52, the errors start appearing in a non-stop fashion. This goes on until one of the infinispan sites automatically goes offline (only one repetition included in the log file, because it was too big for the mailing list). The errors are always related to the work cache only. Note that the log has been anonymized and host, node, site names, IP's, ports, etc. do not correspond to the real ones. We have made a best effort not to obfuscate any relevant information, however. This log corresponds to an Infinispan 9.4.15 and a Keycloak 4.8.3, both in domain mode, with one node per data center each. No error appears in Keycloak logs, even in debug mode (or we haven't found it). To discard possible mistakes in the configuration, we have also tested it with the exact configuration in: https://www.keycloak.org/docs/latest/server_installation/index.html#setup These are the results for serveral combinations of versions, always with the exact example configuration from the docs: Keycloak Infinispan Result ======== ======== ====== 6.0.1 9.4.15 Error 4.8.3 9.4.15 Error 4.8.3 9.4.0 Error 4.8.3 9.3.6 Works 6.0.1 9.3.6 Does not connect 5.0.0 9.3.6 Does not connect In the three first setups, the log looks exactly the same as the attached log. In the fourth setup, everything works fine. In the two last setups, Keycloak couldn't connect to infinispan, probably because it's too old. Our conclusion is that there is a bug showing up only for Infinispan 9.4.x and not for Infinispan 9.3.x. Given that the same version of Keycloak works with Infinispan 9.3 and doesn't work with Infinispan 9.4, this may be an Infinispan bug, but we have not been able to reproduce it by directly writing onto the work cache; we have always needed to start Keycloak to reproduce it. For this reason, we cannot totally discard a problem in Keycloak which would show up only with later versions of Infinispan. Any help will be appreciated. If you need any further information, don't hesitate to ask. Thank you very much, Juan Juan Antonio Farré Basurte Arquitectura e Innovación Avda. de Extremadura s/n 37187, Aldeatejada - SALAMANCA M: +34 647 35 09 72| T: +34 923 70 17 75 E-mail: jafarre(a)viewnext.com | Web: www.viewnext.com ------------------------------------------------------------------------------------------------------------------------------------ Este mensaje va dirigido únicamente a la(s) persona(s) y/o entidad(es) arriba relacionada(s). Puede contener información confidencial o legalmente protegida. Si no es usted el destinatario señalado, le rogamos borre del sistema inmediatamente el mensaje y sus copias. Asimismo le informamos que cualquier copia, divulgación, distribución o uso de los contenidos está prohibida. --------------- This message is addressed only to the person (people) and / or entities listed above. It may contain confidential or legally protected information. If you are not the recipient indicated, please delete the message and its copies immediately from the system. We also inform that any copy, disclosure, distribution or use of the contents is forbidden --------------------------------------------------------------------------------------------------------------- Viewnext, S.A. Domicilio Social: Avda. de Burgos 8-A 28036 de Madrid. telf: 913834060, Fax: 913834090. Reg. M. Madrid: Tomo 3238, Libro:0, Folio: 78, Seccion: 8ª, Hoja M-55112, N.I.F.: A-80157746

6 years, 9 months

1
0
0 / 0

Custom Social Login, cache access_token, Enterprise Wechat

by kkzxak47

Hi, I'm building a SSO service for my company (~1000 employee). After investigation I decided to adopt Keycloak as the core component. We are using Wechat Work as IM tool (https://work.weixin.qq.com/), employee DB is based on its Contacts. So it's natural to integrate it as a social login into Keycloak SSO service. In the process of implementing the 'WechatIdentityProvider' and 'WechatIdentityProviderFactory' classes I encountered some trouble. Just like Twitter / Google and other providers, some of Wechat Work's OAuth2 flow is not aligned with standards. For example, the processing of retrieving the access_token is relatively independent of other OAuth2 code flow, the access_token is valid for 7200 seconds, its API is limited to be called 2000 times per day for a single client. We are forced to cache a global access_token for each client. I noticed that Keycloak is heavily using Infinispan. My question is can I use it for caching access_token too? Is it safe to do so? What is your recommendation? And I'm working based on version 6.0.1 in standalone mode, is it appropriate? My main programming language is not Java by the way. I learned it ~10 years ago and Spring is new to me. So I'm still learning. It's of great help to give relevant document links or code snippets, thanks! Victor

6 years, 9 months

1
3
0 / 0

Keycloak 7

by Ernedin Zajko

Hi everyone, as Keycloak was tagged with 8.0.0-SNAPSHOT, any news on 7.0.0 release (or will it be skipped) ? regards, --- eZ

6 years, 9 months

2
1
0 / 0

Question about CBAC + Pushing Claims + Authorization Scopes

by Álvaro Gómez

Hi, We are applying RBAC and CBAC models to evaluate permissions in a multi-tenant UMA application. We are using Pushing Claims to let custom policies determine if an user has an specific role in a provided context (tenant) via Pushing Claims. Everything works fine if we use non-scoped resources but things get a bit confusing when we use scoped ones since the pushing-claims (representing the tenants) end up mixed in the RPT permission claim without leaving any trace of the scopes with which they were pushed along. Consider the following example: We have an application which manages products (represented by resources). There are profiles (represented by roles) which allow users to sell, modify or delete products (represented by scopes). A certain user may interact with one product in the context of a tenant (Determined by the Pushing claim) with an specific role and with some different role from other tenant. - Resource: * product (With scopes sell and update) - Roles: * Seller * Product-Manager - Policies: * Is-Seller (In the Tenant specified in the Pushing Claim "tenant") * Is-Product-Manager (In the Tenant specified in the Pushing Claim "tenant") - Permissions: * product:sell -> Provides the "sell" scope of the resource "product" if the "Is-Seller" policy evaluates to grant. * product:update -> Provides the "update" scope of the resource "product" if the "Is-Product-Manager" policy evaluates to grant. - Users: * Alice -> Alice is "Seller" in the tenant "Organization-1" and is "Product-Manager" in the tenant "Organization 2" so she should be able to sell products in the context of the tenant "Organization-1" and update products in the context of "Organization-2" but neither "update" products in the context of "Organization-1" or sell products in the context of "Organization-2". 1.- Alice requests an RPT using the following ticket: { "resource": "product", "resource_scopes": ["sell"], "claims": { "tenant": ["Organization-1"] } } Since Alice is "Seller" in the "Organization-1" (meaning the Policy "Is-Seller" will evaluate to "grant" if the provided claim value is "Organization-1" and the evaluated Identity is Alice) an RPT is emitted with the following "permission" claim: [{ "resource": "product", "resource_scopes": ["sell"], "claims": { "tenant": ["Organization-1"] } }] 2.- Alice upgrades the previous RPT with the following ticket: { "resource": "product", "resource_scopes": ["update"], "claims": { "tenant": ["Organization-2"] } } Here is were things get confusing to us. We'd expect Alice to be granted when requesting the scope "update" in the context of "Organization-2" since Alice has the role "Product-Manager" in that tenant. That would be what happened if Alice was requesting the RPT for the first time instead of upgrading a previous one. However, since we are upgrading the RPT obtained in Step 1, when the policy "Is-Product-Manager" is evaluated, the claim "tenant" is mixed with the one in Step 1 (Since they are not grouped by scope) resulting in the following permission: { "resource": "product", "resource_scopes": ["sell", "update"], "claims": { "tenant": ["Organization-1", "Organization-2"] } } The policy can't evaluate to grant since Alice is not "Product-Manager" in both tenants "Organization-1" and "Organization-2" (Obtained through $evaluation.getPermission().getClaims()). When evaluating this policy we would only be interested in the pushing-claim `{ "tenant": ["Organization-2"] }` which was pushed along with the scope "update" (which is the one being evaluated by the permission "product:update" associated with this Policy). Shouldn't the claims be grouped by the scopes which with they were pushed along? (See example at the end of this text), Are we missing something? Example: { "resource": "product", "resource_scopes": [ { "name": "sell", "claims": { "tenant": ["Organization-1"] } }, { "name": "update", "claims": { "tenant": ["Organization-2"] } }, ] Thanks in advance, Álvaro.

6 years, 9 months

2
7
0 / 0

CDI Support in keycloak

by Christian Froehlich

Hi, CDI (Weld subsystem) is deactivated inside the keycloak server if I understood it right in the documentation. Is there a specific reason why you explicitly deactivate CDI? Regards Christian

6 years, 9 months

2
1
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

keycloak-user August 2019