March 2019 - keycloak-user - Jboss List Archives

Concurrent OAuth handshakes overwrites OAuth_Token_Request_State cookie

by Belser, Ted L CTR DIA (US)

Hello, I'm encountering an issue with the OAuth sequence that occurs because of a unique combination of components. We are deploying keycloak protected web applications into an OpenShift environment. The web applications must be accessible through an Ozone Widgets Framework (OWF) portal. These are immovable constraints. It's a government system and therefore cannot be easily changed. I'd drop OWF if I could. The OWF portal is mapped to a client in Keycloak and is a protected resource. OWF is a way to bring multiple applications into a single browser window (via inline frames). Each application (mapped into an Iframe in OWF, and an App in Openshift) is protected by keycloak. The applications are each keycloak clients within the same realm as the OWF client. When the OWF page loads, it first attempts to authenticate the user via normal keycloak mechanisms. This authentication and authorization completes successfully. However, once the OWF portal is loaded into the browser, it begins opening the user's widgets concurrently. Each of the widgets is an OpenShift application (specifically a wildfly application using the Keycloak client adapter). As a consequence, each of the widgets needs to establish a security context. While running thought the redirect sequence between the app, keycloak, and back to the app, a cookie is exchanged. The cookie's name is OAuth_Token_Request_State. The problem arises when there are multiple apps attempting to establish their security context concurrently. When this happens, the OAuth_Token_Request_State is overwritten. As a result, all but one of the apps fail to establish the security context because the cookie value does not match the OAuth state. As a result, most of the widgets on the screen do not load. It's possible to reload the widgets and the authentication process completes successfully, but forcing users to reload is clearly a UX problem. Is it possible to fix this by changing the name of this cookie to include a unique string? If the cookie name is unique, it won't be overwritten. When the user agent is redirected back to the client, it will include the uniquely named cookie and the verification of the OAuth state will succeed. The name of the cookie appears to be an implementation detail of OAuth 2.0, not a SHALL. It seems like this could be changed and still comply with the standard. I cloned the code and found where the cookie name is set. I can make the modification and rebuild the adapter, but I wanted to be sure I wasn't causing another problem. It seems pretty straightforward. Again, I'd prefer to drop OWF from the architecture and not worry about this, but that's not an option. Thanks, Von Belser

5 years, 10 months

1
0
0 / 0

Removing JaxrsBearerTokenFilter

by Marek Posolda

Keycloak team things about removing JaxrsBearerTokenFilter. Just to add some context, the JaxrsBearerTokenFilter is the "adapter", which we have in the codebase and which allows to "secure" the JaxRS Application by adding the JaxrsFilter, which implements our OIDC adapter.This filter is not documented and we don't have any examples/quickstarts of it. Hence it is not considered as officially supported Keycloak feature. And you can probably always secure your application through some other officially supported way (HTTP Servlet filter or any of our other built-in adapters). Anyway, if someone is aware of any reason why to not remove this filter from Keycloak, please let me know, ideally by the Monday Feb 25th. See some details in keycloak-dev thread "Removing JaxrsBearerTokenFilter" . Thanks, Marek

5 years, 10 months

3
8
0 / 0

Keycloak 4.8 check if user has role

by Filip Andersen

Hello Is there any way to check via Rest API if a user has the appropriate role for accessing the resource? I was thinking it would return a boolean depending on the outcome? Thanks in advance

5 years, 10 months

1
0
0 / 0

[ Keycloak - user ] Spring boot application configuration - How can I inject ROLE got from OtherClaims to configuration class?

by Eddy Rowking

Hello everyone, I am trying to configure a spring boot application. How can I inject ROLE got from OtherClaims to configuration class? I get Roles from other claims the user endpoit url as you can see below: public class GetRolesFromOtherClaims { private final String keycloakServerUrl = "https://my-authentication-server.fr"; private final String keycloakRealm = "MY-REALM"; public RolesDto[] getRoles() throws IOException { URI userInfoUri = KeycloakUriBuilder.fromUri(this.keycloakServerUrl).path("/auth/realms/MY-REALM/protocol/openid-connect/userinfo").build(this.keycloakRealm); KeycloakClientRequestFactory factory = new KeycloakClientRequestFactory(); KeycloakRestTemplate template = new KeycloakRestTemplate(factory); ResponseEntity<UserInfo> response = template.getForEntity(userInfoUri, UserInfo.class); UserInfo infos = response.getBody(); String autorisations = infos.getOtherClaims().get("autorisations").toString(); ObjectMapper mapper = new ObjectMapper(); RolesDto[] rolesDtos = mapper.readValue(autorisations, RolesDto[].class); return rolesDtos; } } You can see below my configuration classes: @Configuration @EnableWebSecurity @ConditionalOnProperty(name = "keycloak.enabled", havingValue = "true", matchIfMissing = true) @ComponentScan(basePackageClasses = KeycloakSecurityComponents.class) public class KeycloakConfigurationAdapter extends KeycloakWebSecurityConfigurerAdapter { @Bean @Override protected SessionAuthenticationStrategy sessionAuthenticationStrategy() { return new NullAuthenticatedSessionStrategy(); } @Bean public KeycloakConfigResolver KeycloakConfigResolver() { return new KeycloakSpringBootConfigResolver(); } @Autowired public void configureGlobal(AuthenticationManagerBuilder auth) { KeycloakAuthenticationProvider keycloakAuthenticationProvider = keycloakAuthenticationProvider(); SimpleAuthorityMapper simpleAuthorityMapper = new SimpleAuthorityMapper(); keycloakAuthenticationProvider.setGrantedAuthoritiesMapper(simpleAuthorityMapper); auth.authenticationProvider(keycloakAuthenticationProvider); } @Override protected void configure(HttpSecurity http) throws Exception { http .sessionManagement() .sessionAuthenticationStrategy(sessionAuthenticationStrategy()) .and() .addFilterBefore(keycloakPreAuthActionsFilter(), LogoutFilter.class) .addFilterBefore(keycloakAuthenticationProcessingFilter(), X509AuthenticationFilter.class) .exceptionHandling().authenticationEntryPoint(authenticationEntryPoint()) .and() .logout() .addLogoutHandler(keycloakLogoutHandler()) .logoutUrl("/logout").logoutSuccessHandler( (HttpServletRequest request, HttpServletResponse response, Authentication authentication) -> response.setStatus(HttpServletResponse.SC_OK)) .and().apply(new CommonSpringKeycloakSecuritAdapter()); } } public class CommonSpringKeycloakSecuritAdapter extends AbstractHttpConfigurer<CommonSpringKeycloakSecuritAdapter, HttpSecurity> { @Bean CorsFilter corsFilter() { return new CorsFilter(); } @Override public void init(HttpSecurity http) throws Exception { http .csrf().disable() .addFilterBefore(this.corsFilter(), SessionManagementFilter.class) .sessionManagement() .sessionCreationPolicy(SessionCreationPolicy.STATELESS) .and() .authorizeRequests().antMatchers(HttpMethod.OPTIONS).permitAll() .anyRequest().authenticated(); } } Thanks for you help! Eddy,

5 years, 10 months

1
0
0 / 0

Fine Graned user permission in Admin console

by Pavel Micka

Hello everyone, we will be using fine grained user permissions in admin console in our application. The motivation is simple: customers will be managing their realms directly in Keycloak and we want to make sure that they will not jailbreak (assign higher privileges than they currently have). We have noticed that this feature is in preview, even though it seems that is in Keycloak from version 3.2.0 (https://issues.jboss.org/browse/KEYCLOAK-3444). We would like to ask if there are any plans to make it "official"/default part of installation. Or if there are some plans to change the functionality in upcoming versions (so we do not base our solution on this feature only to be discontinued in next version of Keycloak). Thanks very much for any info. Regards, Pavel

5 years, 10 months

1
0
0 / 0

Javascript Check SSO and Token Validity

by Tom Barber

Hi folks, I need some help understanding the flow a bit to make sure I can explain stuff, or just figure out if things are wired up correctly. Using the Javascript adapter we login using Check SSO to check the validity of the session. My developer then has a token validity check in place keycloak .updateToken( KC_UPDATE_TOKEN_INTERVAL / 1000 /* 1s = 1000 milliseconds */ ) .success(refreshed => { if (refreshed) { console.log('Token was successfully refreshed'); updateLocalStorage(keycloak); } else { console.log('Token is still valid'); } }) .error(() => { // Failed to refresh the token, or the session has expired keycloak.logout(); }); This runs on a timer. But, if you terminate a session in key cloak it doesn’t log you out( we also have the checkLoginIframe disabled). So, if checking the token a valid way of detecting a session? And what’s the deal with terminating your session? Thanks and apologies for the relatively dumb question! Tom -- Spicule Limited is registered in England & Wales. Company Number: 09954122. Registered office: First Floor, Telecom House, 125-135 Preston Road, Brighton, England, BN1 6AF. VAT No. 251478891. All engagements are subject to Spicule Terms and Conditions of Business. This email and its contents are intended solely for the individual to whom it is addressed and may contain information that is confidential, privileged or otherwise protected from disclosure, distributing or copying. Any views or opinions presented in this email are solely those of the author and do not necessarily represent those of Spicule Limited. The company accepts no liability for any damage caused by any virus transmitted by this email. If you have received this message in error, please notify us immediately by reply email before deleting it from your system. Service of legal notice cannot be effected on Spicule Limited by email.

5 years, 10 months

1
0
0 / 0

How to add custom details to login event

by Michael Dailous

We've added an additional field on the Keycloak login page that requires justification for system use. I've been searching for how to include this in the login event, and have found references to a login event "details", which allows the addition of "any custom field you want", but I can't find any information regarding how to actually add new fields. The thread I found this on is rather old (September 2016), but I'm hoping the information is still valid: http://lists.jboss.org/pipermail/keycloak-dev/2016-September/008179.html Can someone provide some information on how to add a new value to the details of the login event so that information gets logged? Thank you, Michael [cid:c78eef4c-3b3b-4bbc-bf12-c060eb7502c7] Michael Dailous Sr. Software Engineer Forensic Logic / COPLINK 520.732.1725 mdailous(a)forensiclogic.com<mailto:mdailous@forensiclogic.com> www.forensiclogic.com<http://www.forensiclogic.com/>

5 years, 10 months

1
0
0 / 0

Concurrent OAuth handshakes overwrites OAuth_Token_Request_State cookie

by Belser, Ted L CTR DIA (US)

Hello, I'm encountering an issue with the OAuth sequence that occurs because of a unique combination of components. We are deploying keycloak protected web applications into an OpenShift environment. The web applications must be accessible through an Ozone Widgets Framework (OWF) portal. These are immovable constraints. It's a government system and therefore cannot be easily changed. I'd drop OWF if I could. The OWF portal is mapped to a client in Keycloak and is a protected resource. OWF is a way to bring multiple applications into a single browser window (via inline frames). Each application (mapped into an Iframe in OWF, and an App in Openshift) is protected by keycloak. The applications are each keycloak clients within the same realm as the OWF client. When the OWF page loads, it first attempts to authenticate the user via normal keycloak mechanisms. This authentication and authorization completes successfully. However, once the OWF portal is loaded into the browser, it begins opening the user's widgets concurrently. Each of the widgets is an OpenShift application (specifically a wildfly application using the Keycloak client adapter). As a consequence, each of the widgets needs to establish a security context. While running thought the redirect sequence between the app, keycloak, and back to the app, a cookie is exchanged. The cookie's name is OAuth_Token_Request_State. The problem arises when there are multiple apps attempting to establish their security context concurrently. When this happens, the OAuth_Token_Request_State is overwritten. As a result, all but one of the apps fail to establish the security context because the cookie value does not match the OAuth state. As a result, most of the widgets on the screen do not load. It's possible to reload the widgets and the authentication process completes successfully, but forcing users to reload is clearly a UX problem. Is it possible to fix this by changing the name of this cookie to include a unique string? If the cookie name is unique, it won't be overwritten. When the user agent is redirected back to the client, it will include the uniquely named cookie and the verification of the OAuth state will succeed. The name of the cookie appears to be an implementation detail of OAuth 2.0, not a SHALL. It seems like this could be changed and still comply with the standard. I cloned the code and found where the cookie name is set. I can make the modification and rebuild the adapter, but I wanted to be sure I wasn't causing another problem. It seems pretty straightforward. Again, I'd prefer to drop OWF from the architecture and not worry about this, but that's not an option. Thanks, Von Belser ----- Ted L. Belser II Contractor - EAMS Software Engineer sub-contracting to Northrop Grumman Burnt Toast Labs Inc.

5 years, 10 months

1
0
0 / 0

Token Exchange “Permission Upgrade”

by Robert Oxspring

Hi I’ve been reading about token exchange and wondered if somebody could confirm whether it’s the right choice for my situation... We have users connecting to a “front end” service and are able to establish an audit trail of who did what. We also have a “back end” service which the end users typically don’t have permission to use, but is needed to power some functions of the “front end” service. So far we’ve been using a service token within “front end” to make calls on the “Back end” on behalf of the requesting user. This correctly allows the user to trigger some restricted back end behaviour without having direct access to the back end service, but means that the backend service has lost track of who it’s operating on behalf of and so the audit trail becomes unclear. Would it be viable & sensible to instead have the front end exchange the user token for one that has elevated privileges (that the user doesn’t normally have) to the backend service and use that token to make downstream calls? The token exchange docs explicitly mention the possibility of using exchange to downgrade permissions, I’m not clear if they can also be used to upgrade permissions as I describe! https://github.com/keycloak/keycloak-documentation/blob/master/securing_a... Am I on the right track here or should I be looking at something else entirely? Thanks, Rob

5 years, 10 months

1
0
0 / 0

CVE-2018-14637 temporary mitigation with compensating controls?

by pkboucher801＠gmail.com

This https://nvd.nist.gov/vuln-metrics/cvss/v3-calculator?name=CVE-2018-14637&vec tor=AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H says that a SAML response from an external IdP can be replayed, because the expirations of the assertions are not checked (fixed in 4.6.0). The questions I have are about temporary mitigation before deploying version 4.6.0+. 1) Doesn't Keycloak enforce a one-time use restriction, so that no SAML response from an IdP could be reused? 2) If you have "last mile" TLS, so that the SAML responses are never transmitted in the clear, wouldn't that preclude an attacker from capturing a response in order to replay it? 3) Are there any other configurations or controls useful in temporary mitigation (e.g., IP whitelisting, so that SAML responses can only get in from the IdP's CIDR ranges)? Thanks! Regards, Peter

5 years, 10 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

keycloak-user March 2019