Migrating from Wildfly 18 + Keycloack adapter, to Wildfly 26 w/ build-in OIC support.
Previously, to allow Sign-Out (I mean really Signing out from Keycloack, not just invalidating the session) I fetched the token from the session attributes and added to the logout URL (see below. That was tied to wildfly server, but it worked).
How do I get the OIC token in Wildfly 26 ?
org.keycloak.KeycloakSecurityContext securityContext = (org.keycloak.KeycloakSecurityContext) request.getAttribute(KeycloakSecurityContext.class.getName());
String token = securityContext.getIdTokenString();
Got it,
use org.wildfly.security.http.oidc.OidcSecurityContext
instead of wildfly-elytron-http-oidc-1.19.0.Final.jar
Related
I'm trying to setup Apache Guacamole with KeyCloak as OpenID Connect Authorization Server.
Guacamole is redirecting me to KeyCloak, I can Log in with my user I created on KeyCloak and I get redirected back to Guacamole, but there it says that my token is invalid
08:08:11.477 [http-nio-4432-exec-7] INFO o.a.g.a.o.t.TokenValidationService - Rejected invalid OpenID token: Unable to process JOSE object (cause: org.jose4j.lang.UnresolvableKeyException: Unable to find a suitable verification key for JWS w/ header {"alg":"RS256","typ" : "JWT","kid" : "8ZNpgh_vnmG0HMMNYdOz1lw4ECoWxmsiUGte1mJfvyI"} due to an unexpected exception (javax.net.ssl.SSLException: java.lang.RuntimeException: Unexpected error: java.security.InvalidAlgorithmParameterException: the trustAnchors parameter must be non-empty) while obtaining or using keys from JWKS endpoint at https://172.16.47.229:12345/auth/realms/Guacamole-test/protocol/openid-connect/certs): JsonWebSignature{"alg":"RS256","typ" : "JWT","kid" : "8ZNpgh_vnmG0HMMNYdOz1lw4ECoWxmsiUGte1mJfvyI"}->eyJhbGciOiJSUzI1NiIsInR5cCIgOiAiSldUIiwia2lkIiA6ICI4Wk5wZ2hfdm5tRzBITU1OWWRPejFsdzRFQ29XeG1zaVVHdGUxbUpmdnlJIn0.eyJleHAiOjE2MDIzOTczODgsImlhdCI6MTYwMjM5NjQ4OCwiYXV0aF90aW1lIjoxNjAyMzk2NDcwLCJqdGkiOiI5Y2RiZDVjZC01MDJhLTRjNmItYTM3Mi1jZDIxMTNjNTE1NTMiLCJpc3MiOiJodHRwczovLzE3Mi4xNi40Ny4yMjk6MTIzNDUvYXV0aC9yZWFsbXMvR3VhY2Ftb2xlLXRlc3QiLCJhdWQiOiJHdWFjYW1vbGUiLCJzdWIiOiI1YzQ3N2NiZC04ZjIzLTRlMjEtYmNhMi1kMzNlMTRhZGY0ZDYiLCJ0eXAiOiJJRCIsImF6cCI6Ikd1YWNhbW9sZSIsIm5vbmNlIjoiaTQyZDBpZTc4c2s0MjRjMHJzMmJvdTM4YnUiLCJzZXNzaW9uX3N0YXRlIjoiMjNlZjdhMTYtMDhhNS00YTNkLTgxYTItYTQ2ZmE1NmM1NjE3IiwiYWNyIjoiMCIsImlzX3N1cGVydXNlciI6IlRydWUiLCJlbWFpbF92ZXJpZmllZCI6ZmFsc2UsIm5hbWUiOiJ0ZXN0IHRlc3QiLCJwcmVmZXJyZWRfdXNlcm5hbWUiOiJ0ZXN0dXNlciIsImdpdmVuX25hbWUiOiJ0ZXN0IiwiZmFtaWx5X25hbWUiOiJ0ZXN0IiwiZW1haWwiOiJ0ZXN0QHRlc3QuY29tIn0.eOhkDqcgfdJnO12PRDqLIHACRNVdVHoSDFjThHWc6Ug1gdoz9t_T2K7F_B6dJSbNygAJrGvc5BVRx9XCJH1fVFSYhpXVqCO0jrHm0XJKhw_kBce4x3ZluGAtktx614j9qFzUwZHXOkFAUGPtyPQKuRTfdzHqQUILLJhVdSRPmou40rX31-l7VwqWZk_Yp1JCdQsA61XvJcQrU_aiKivZFaDGiY5GrnpL8zcEwJcFemptVoGKrG63O_LjxDCxhLpO1C1fi8GjngMSfco9aAp4AaGpHWy8ofJAu-TWbLGf-UPLUhC3lf903-Q_BU3eehYxtMyN1eet0HeGm0x_gV_wvA
In KeyCloak I created a Client as follows:
(Will change the Valid Redirect URI`s once I have it working)
And my guacamole.properites look like this:
guacd-port: 4822
guacd-hostname: localhost
# OpenID Connect Properties
openid-authorization-endpoint: https://172.16.47.229:12345/auth/realms/Guacamole-test/protocol/openid-connect/auth
openid-jwks-endpoint: https://172.16.47.229:12345/auth/realms/Guacamole-test/protocol/openid-connect/certs
openid-issuer: https://172.16.47.229:12345/auth/realms/Guacamole-test
openid-client-id: Guacamole
openid-redirect-uri: http://172.16.47.229:4432/guacamole/
# Postgresql Properties
postgresql-hostname: 172.16.47.229
postgresql-port: 4444
postgresql-database: guacamoledb
postgresql-username: guacamoleuser
postgresql-password: test
What do I have to change for guacamole to accept the token?
Update: I found the configuration to be working, if I use KeyCloak with HTTP instead of HTTPS, but that is not desirable. I have now also configured Guacamole, or more precisely the tomcat that's hosting guacamole, to use https, but I still can not get it to work (without having to use HTTP for KeyCloak).
I've caught the same issue. Most probably you just have to provide valid SSL certificate for your IdP (Keycloak).
Possible workaround was found here: How to configure Keycloak to work with Guacamole's OpenID plugin?.
I've re-compiled guacamole-auth-openid extension with this change:
diff --git a/extensions/guacamole-auth-openid/src/main/java/org/apache/guacamole/auth/openid/token/TokenValidationService.java b/extensions/guacamole-auth-openid/src/main/java/org/apache/guacamole/auth/openid/token/TokenValidationService.java
index 5efb09dab..27d818ee5 100644
--- a/extensions/guacamole-auth-openid/src/main/java/org/apache/guacamole/auth/openid/token/TokenValidationService.java
+++ b/extensions/guacamole-auth-openid/src/main/java/org/apache/guacamole/auth/openid/token/TokenValidationService.java
## -79,6 +79,7 ## public class TokenValidationService {
// Create JWT consumer for validating received token
JwtConsumer jwtConsumer = new JwtConsumerBuilder()
+ .setSkipSignatureVerification()
.setRequireExpirationTime()
.setMaxFutureValidityInMinutes(confService.getMaxTokenValidity())
.setAllowedClockSkewInSeconds(confService.getAllowedClockSkew())
And this solved the issue. Don't think it's applicable for production needs but in production self-signed certificates should not be used.
With Guacamole 1.4.0 and Keycloak 15.0.2 I fixed the HTTPS issue by mounting a custom cacerts keystore in the the Guacamole container. This custom keystore is just the OpenJDK 8 cacerts with Let's Encrypt CA bundle https://letsencrypt.org/certs/isrgrootx1.pem imported. Because my Keycloak and Guacamole instance use Let's Encrypt certificates.
On the host I had OpenJDK 8 installed. So Docker mount was
/etc/ssl/certs/java/cacerts:/usr/local/openjdk-8/jre/lib/security/cacerts
When user clicks login, redirected to Keycloak login page & then after successful login, user comes back to application with 400 error page.
Server log shows following:
[Server:node-00] 13:40:00,709 WARN
[org.keycloak.adapters.OAuthRequestAuthenticator] (default task-30)
state parameter invalid
My application conf is:
<subsystem xmlns="urn:jboss:domain:keycloak:1.1">
<secure-deployment name="appWEB.war">
<realm>demo</realm>
<resource>app</resource>
<public-client>true</public-client>
<auth-server-url>http://localhost:8180/auth</auth-server-url>
<ssl-required>EXTERNAL</ssl-required>
</secure-deployment>
</subsystem>
Application URL is https://localhost:8443/app & redirect_url is https://localhost:8443/app/private.jsf.
When I use http, it works. But the error comes when I use same with https.
Any thoughts?
Here it can be many scenario which may failing with https
Keycloak running in https
Create self sign certification for keycloak.
Import this certificate to your local Java environment.SO handshake can be possible.
I hope you generate the certificates in keycloak you can find the the certificate inside keycloak/security/ssl.
[AspNet.Security.OpenIdConnect.Server] 2.0.0-rc2-final
Doubt about refresh token.
Is there any mechanism so that after updating a .net core project (DLLs), or with the application restart (IIS), a token can be revalidated so that the user remains valid and logged in?
today with each new update of my project, the token is invalidated and the user is disconnected from the application and a new login is required.
after an update the returned message is:
The specified refresh token is invalid.
thanks.
Are you using a developer certificate to sign the token? It seems that you don't use a fixed certificate. The certificate is used to encode and decode the token. If the certificate changes (on restart of the app) then all tokens become invalid.
To set a fixed signing certificate:
var cert = new X509Certificate2("TokenCertificate.pfx", "MySecret",
X509KeyStorageFlags.MachineKeySet |
X509KeyStorageFlags.PersistKeySet |
X509KeyStorageFlags.Exportable);
services
.AddAuthentication( ... )
.AddJwtBearer( ... )
.AddOpenIdConnectServer(options =>
{
options.SigningCredentials.AddCertificate(cert);
...
});
I just installed OpenAM 13.0.0, created an hosted IDP, and registered a remote SP.
Within the remote SP (a product called Questetra), I configured the entityID, login URL, logout URL, and certificate using values found in the XML at http://idp:8080/openam/saml2/jsp/exportmetadata.jsp?entityid=http://idp:8080/openam&realm=/
Problem: OpenAM says 500 Internal Server Error at the step where the browser loads the successURL.
Any idea what is happening?
Any tips on how to debug? There is nothing special in the Tomcat and OpenAM logs.
Shortened Wireshark trace
HTTP/1.1 200 OK
[...]
{"successURL":"/SSORedirect/metaAlias/idp?ReqID=a41de50e29c99ff3422f82b7g660ch6&index=null&acsURL=http%3A%2F%2Fthesp%3A8080%2Fuserweb%2Fsaml%2FSSO%2Falias%2Fbpm&spEntityID=http%3A%2F%2Fthesp%3A8080%2Fuserweb%2F&binding=urn%3Aoasis%3Anames%3Atc%3ASAML%3A2.0%3Abindings%3AHTTP-POST"}
GET /openam/SSORedirect/metaAlias/idp?ReqID=a41de50e29c99ff3422f82b7g660ch6&index=null&acsURL=http%3A%2F%2Fthesp%3A8080%2Fuserweb%2Fsaml%2FSSO%2Falias%2Fbpm&spEntityID=http%3A%2F%2Fthesp%3A8080%2Fuserweb%2F&binding=urn%3Aoasis%3Anames%3Atc%3ASAML%3A2.0%3Abindings%3AHTTP-POST HTTP/1.1
[...]
HTTP/1.1 500 Internal Server Error
[...]
<html>[...]HTTP Status 500 - Unable to do Single Sign On or Federation[...]</html>
Full trace at https://gist.github.com/nicolas-raoul/5ff26f37a95bc8088c6af7fe6ea5e468
Tomcat 7.0.72, Ubuntu 2016.04.1 LTS, Firefox 50.1.0
I solved this same error by taking the Certificate value directly from the metadata file exported from OpenAM and entering that directly again, to ensure that it was the exact same.
We are currently trying to deploy CAS 4.0.1 on a JBoss EAP 6.3.0 server.
The login webflow was customised in order to redirect to a specific login form depending on the service calling CAS for authentication. Depending on these forms, we use specific authentication handlers, and a specific Credential model. Besides that, the configuration is rather standard.
At the moment, we are experiencing the following issue: when a user attempts to access a service secured by CAS, he is correctly redirected to the portal, and the expected login view is rendered ; upon successful login, the Service Ticket is delivered to the authentication filter on the service side (standard j_spring_cas_security_check), which then validates it successfully against CAS' ticket registry. We see in the logs that CAS is rendering the cas2ServiceSuccessView ; however, instead of delivering the expected XML response, the user is redirected to the login form.
We then confirmed that we were in fact getting a 404 error after the cas2ServiceSuccessView... Any idea what could trigger such behaviour/what we could have done wrong ?
Note that we are getting the same error regardless of how we call CAS for the ST validation: whether it is manually through /serviceValidate?ticket=ST-YYY&service=XXX, or via the /j_spring_cas_security_check on the service side...
Edit: we have the same behaviour running CAS on Tomcat 7.
Thanks in advance.
Below the debug logs that we are getting:
08:54:10,806 DEBUG [org.springframework.web.servlet.DispatcherServlet] (http-/0.0.0.0:8080-7) Last-Modified value for [/cas/serviceValidate] is: -1
08:54:10,809 INFO [org.perf4j.TimingLogger] (http-/0.0.0.0:8080-7) start[1433314450807] time[2] tag[VALIDATE_SERVICE_TICKET]
08:54:10,810 INFO [com.github.inspektr.audit.support.Slf4jLoggingAuditTrailManager] (http-/0.0.0.0:8080-7) Audit trail record BEGIN
=============================================================
WHO: audit:unknown
WHAT: ST-3-uecoOwdbdIn4bc2WvXfe-cas-test
ACTION: SERVICE_TICKET_VALIDATED
APPLICATION: CAS
WHEN: Wed Jun 03 08:54:10 CEST 2015
CLIENT IP ADDRESS: 127.0.0.1
SERVER IP ADDRESS: 127.0.0.1
=============================================================
08:54:10,810 DEBUG [org.springframework.validation.DataBinder] (http-/0.0.0.0:8080-7) DataBinder requires binding of required fields [renew]
08:54:10,811 DEBUG [org.springframework.web.servlet.DispatcherServlet] (http-/0.0.0.0:8080-7) Rendering view [org.springframework.web.servlet.view.InternalResourceView: name 'cas2ServiceSuccessView'; URL [/WEB-INF/view/jsp/cas2ServiceSuccessView.jsp]] in DispatcherServlet with name 'cas'
08:54:10,811 DEBUG [org.springframework.web.servlet.view.InternalResourceView] (http-/0.0.0.0:8080-7) Added model object 'assertion' of type [org.jasig.cas.validation.ImmutableAssertion] to request in view with name 'cas2ServiceSuccessView'
08:54:10,811 DEBUG [org.springframework.web.servlet.view.InternalResourceView] (http-/0.0.0.0:8080-7) Removed model object 'pgtIou' from request in view with name 'cas2ServiceSuccessView'
08:54:10,811 DEBUG [org.springframework.web.servlet.view.InternalResourceView] (http-/0.0.0.0:8080-7) Forwarding to resource [/WEB-INF/view/jsp/cas2ServiceSuccessView.jsp] in InternalResourceView 'cas2ServiceSuccessView'
08:54:10,812 DEBUG [org.springframework.web.servlet.DispatcherServlet] (http-/0.0.0.0:8080-7) Successfully completed request
08:54:10,814 DEBUG [org.springframework.web.servlet.DispatcherServlet] (http-/0.0.0.0:8080-7) DispatcherServlet with name 'cas' processing GET request for [/cas/login]
08:54:10,814 DEBUG [org.springframework.webflow.mvc.servlet.FlowHandlerMapping] (http-/0.0.0.0:8080-7) Mapping request with URI '/cas/login' to flow with id 'login'
In SpringSecurity 4.x, CasAuthenticationFilter's defaultFilterProcessesUrl path is changed.
So Change '/j_spring_cas_security_check' to '/login/cas' in Configuration.
... and of course, the cause was rather silly: somehow (I have to look at our merge/git history), the viewResolver bean defined in cas-servlet.xml did not have a basenames property set.