I am trying to implement SSO in CMDBuild by using CAS. I have installed CMDBuild and CAS in my local centos 6.5 machine. But i am unable to do SSO successfully.
Environmental Details are stated below
Centos 6.5
CAS 4.2.0
CMDBuild 2.4.1
My Cas configuration inside auth.conf is
auth.methods=CasAuthenticator,DBAuthenticator
cas.server.url=https://localhost:8443/cas
cas.login.page=/login
cas.service.param=http://localhost:8080/cmdbuild/index.jsp
cas.ticket.param=ticket
But while i try to access cmdbuild from browser after changing the configuration. Some parameters are appending to the URL like below which causes cmdbuild not to start.
https://localhost:8443/cas/login?http://localhost:8080/cmdbuild/index.jsp=http%3A%2F%2F192.168.50.161%3A8080%2Fcmdbuild%2Findex.jsp%3Fskipsso
Also in CMDBuild log i found the same error,
INFO 2016-09-21 08:35:44 [cmdbuild] trying to login with no username or password
INFO 2016-09-21 08:35:44 [cmdbuild] Redirecting to https://localhost:8443/cas/login?service=http%3A%2F%2F192.168.50.161%3A8080%2Fcmdbuild%2Findex.jsp%3Fskipsso
As per the documentation,
"The CAS authenticator sends the request to the CAS server (${cas.server.url} + $ {cas.login.page}) specifying the CMDBuild access url (in the ${cas.service.param} paramter)"
I have configured CMDBuild access url in cas.service.param
I am having some doubts on what i have to configure in cas.service.param and cas.ticket.param. What i have to add in cas.service.param and cas.ticket.param.
Any help would be appreciated.
Thanks
For version 3.3.2 at least, these are the correct key values:
./cmdbuild.sh restws setconfig org.cmdbuild.auth.modules=cas
./cmdbuild.sh restws setconfig org.cmdbuild.auth.module.cas.server.url=https://…
./cmdbuild.sh restws setconfig org.cmdbuild.auth.module.cas.login.page=/login
./cmdbuild.sh restws setconfig org.cmdbuild.auth.module.cas.service.param=service
./cmdbuild.sh restws setconfig org.cmdbuild.auth.module.cas.ticket.param=ticket
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
I am spinning a big wheel now. please shed some light.
Reverse proxy is working with Apache. So, when I access https://hostname/app/default.html, it opens Tomcat app url. No issue.
The tomcat app currently redirects to https://hostname/app/login.html which has a login box.
1) Do I need to disable UserDatabase on Tomcat server.xml ?
<Resource name="UserDatabase" auth="Container"
type="org.apache.catalina.UserDatabase"
description="User database that can be updated and saved"
factory="org.apache.catalina.users.MemoryUserDatabaseFactory"
pathname="conf/tomcat-users.xml" />
2) Is this Shibboleth configuration correct ?
But, when I try configure this with OKTA- Shibboleth(3.0), it's looping OKTA SSO url.
In shibboleth2.xml
<ApplicationDefaults id="default"
entityID="https://hostname/shibboleth-sp"
REMOTE_USER="userid" >
<SSO entityID="http://www.okta.com/~~~~">
OKTA's metadata is downloaded and located with shibboleth2.xml file.
cert is also generated and placed in the same folder.
3) Is this OKTA configuration correct ?
In OKTA widget configuration menu,
- Single sign on url :https://hostname/Shibboleth.sso/SAML2/POST
- recipient url : https://hostname/Shibboleth.sso/SAML2/POST
- destination url :https://hostname/Shibboleth.sso/SAML2/POST
- audience restriction :https://hostname/shibboleth-sp <-- above SP entityID
- default relay state : ??
right now, when I click on the widget on OKTA, it's looping.
https://hostname/Shibboleth.sso/SAML2/POST
contains SAML response.
then, it redirects to OKTA SSO url. It never ends.
https:// xxx.oktapreview.com/app/xx_reverse_proxy_/xxxx/sso/saml?SAMLRequest=~~~&RelayState=~~~
This contains SAML request but it looks like this.
<samlp:AuthnRequest
xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
AssertionConsumerServiceURL="https://hostname/Shibboleth.sso/SAML2/POST"
Destination="https://okta sso/sso/saml"
ID="xx"
IssueInstant="2018-11-02T15:39:24Z"
ProtocolBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"
Version="2.0">
<saml:Issuer
xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">https://hostname/shibboleth-sp
</saml:Issuer>
<samlp:NameIDPolicy
AllowCreate="1"/>
Is this Issuer url correct? Why is it looping and how to fix ?
Re Q#1: You only need Tomcat users if you're going to protect an application with it, such as the Tomcat manager. Otherwise, no.
Re Q#2: You list <SSO entityID="http://www.okta.com/~~~~"> but Destination="https://okta sso/sso/saml" from the SAML. You might want to check http/https. This is a very common cause of looping. Eliminate any potential http/https inconsistency.
FWIW Issuer looks correct to me... that's what you specify in entityID="https://hostname/shibboleth-sp"
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.
Our Java app is federated with customers ADFS 3.0 server.
There is an issue after sending authentication requests (SP initiated) to ADFS server over SAMLP.
It is for intranet use case, where windows authentication was specified on ADFS server in authentication policy.
SP app is using ForgeRock's Fedlet library that is forcibly sending RequestedAuthnContext attribute withing SAML authentication request :
samlp:RequestedAuthnContext xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
Comparison="exact"
>
<saml:AuthnContextClassRef xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">urn:oasis:names:tc:SAML:2.0:ac:classes:Password</saml:AuthnContextClassRef>
</samlp:RequestedAuthnContext>
We had initially also issue with extranet authentication, where Forms authentication was selected on ADFS. We have solved that with adding Claim custom rule for our RP :
exists([Type == "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier"]) => issue(Type = "http://schemas.microsoft.com/ws/2008/06/identity/claims/authenticationmethod", Value = "urn:oasis:names:tc:SAML:2.0:ac:classes:Password");
Now we are stacked down with intranet use case.
On ADFS side we got following error :
MSIS7102: Requested Authentication Method is not supported on the STS.
at Microsoft.IdentityServer.Web.Authentication.GlobalAuthenticationPolicyEvaluator.EvaluatePolicy(IList`1 mappedRequestedAuthMethods, AccessLocation location, ProtocolContext context, HashSet`1 authMethodsInToken, Boolean& validAuthMethodsInToken)
at Microsoft.IdentityServer.Web.Authentication.AuthenticationPolicyEvaluator.RetrieveFirstStageAuthenticationDomain(Boolean& validAuthMethodsInToken)
at Microsoft.IdentityServer.Web.Authentication.AuthenticationPolicyEvaluator.EvaluatePolicy(Boolean& isLastStage, AuthenticationStage& currentStage, Boolean& strongAuthRequried)
at Microsoft.IdentityServer.Web.PassiveProtocolListener.GetAuthMethodsFromAuthPolicyRules(PassiveProtocolHandler protocolHandler, ProtocolContext protocolContext)
at Microsoft.IdentityServer.Web.PassiveProtocolListener.GetAuthenticationMethods(PassiveProtocolHandler protocolHandler, ProtocolContext protocolContext)
at Microsoft.IdentityServer.Web.PassiveProtocolListener.OnGetContext(WrappedHttpListenerContext context)
Could I add/do something for it ? Is it possible to say in custom rules IF IT IS INTRANET, AUTH METHOD IS WINDOWS or something like that?
You could always try authnContextClassRef="urn:oasis:names:tc:SAML:2.0:ac:classes:unspecified", which should let the IdP choose whatever it can use. As the SP, you don't really know (and should you care?) which methods are available to the IdP...
We have solved this by sending more authentication options and specifying Comparison to minimum
<samlp:RequestedAuthnContext xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
Comparison="minimum"
>
<saml:AuthnContextClassRef xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">urn:oasis:names:tc:SAML:2.0:ac:classes:unspecified</saml:AuthnContextClassRef>
<saml:AuthnContextClassRef xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">urn:oasis:names:tc:SAML:2.0:ac:classes:Password</saml:AuthnContextClassRef>
<saml:AuthnContextClassRef xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport</saml:AuthnContextClassRef>
<saml:AuthnContextClassRef xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">urn:oasis:names:tc:SAML:2.0:ac:classes:Kerberos</saml:AuthnContextClassRef>
<saml:AuthnContextClassRef xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">urn:federation:authentication:windows</saml:AuthnContextClassRef>
</samlp:RequestedAuthnContext>
Jenkins v 1.597
SAML plugin v 0.3
We are using an internal PingFederated server and I have entered the xml metedata contents into the Security configuration of Jenkins.
I have tried on two servers, one set up HTTPS (SSL) and one just HTTP.
We get errors when trying to login using SSO that pertain to the https://servername/securityRealm/finishLogin redirect and the same for non-SSL server.
We are stumped on what to check here, the PingFederated administrator has it set for the postback to the securityRealm/finishLogin URL, which is what is in the code for the plugin, we just are not sure how to proceed.
The contents of the xml metadata:
<md:EntityDescriptor ID="MNkL_uYrUsdEca2oWqH6gdgG4t3" cacheDuration="PT1440M" entityID="ACIWW:Saml2:POC" xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata"><md:IDPSSODescriptor protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol" WantAuthnRequestsSigned="false"><md:KeyDescriptor use="signing"><ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#"><ds:X509Data> <ds:X509Certificate>CERTIFICATECODE HERE</ds:X509Certificate></ds:X509Data> </ds:KeyInfo></md:KeyDescriptor><md:NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified</md:NameIDFormat><md:SingleSignOnService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="https://SSOSERVERNAME/idp/SSO.saml2"/><md:SingleSignOnService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect" Location="https://SSOSERVERNAME/idp/SSO.saml2"/><md:SingleSignOnService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Artifact" Location="https://SSOSERVERNAME/idp/SSO.saml2"/><md:SingleSignOnService Binding="urn:oasis:names:tc:SAML:2.0:bindings:SOAP" Location="https://SSOSERVERNAME/idp/SSO.saml2"/></md:IDPSSODescriptor><md:ContactPerson contactType="administrative"><md:Company>COMPANYNAME</md:Company></md:ContactPerson></md:EntityDescriptor>
Any help or suggestions would be greatly appreciated.
John