I am using mod_auth_cas to SSO into Alfresco Community 5.2 through Keycloak 4.0, with with the keycloak-cas-protocol plugin.
Alfresco sits behind a first Apache reverse proxy while Keycloak runs behind another one, on a different machine. SSL certificates are handled by a front Apache server.
My issue is the following : as I login, I get redirected to the Alfresco URL with way too many CAS tickets :
http://alfresco-server-url/alfresco?ticket=ST-eyJhbAbdOiJkaXIiLCJlbmMiOiJBMTI4Q0JDLUhTMjU2In0..2fzwwcMChdFFNk49ucH56A.aHDDlnXrignL4oCAXzrSmIinjqVqaisUQtaioLTzRlLoHjPGD8k-PRrUA0U5S09Wh0Z8MV2JkK2_2CUh5efDFnVdrLqvCtFUOakAtTH9b8MK_7NLU6H_K6tM0cItB7tGAooUZmoKhHAc5DlzIx7n7QrbThk5nrwt5BBl4luIK0k9zeLUOjn5Cp6_nRyCK6uJZZu2-l0qbeMSPjTOktbGZUb2S0F4l1Af5be6sYwQO95XTLEyny8mPKhexEnFR6vx.9BDatlhtuxg17oqopjwpdw&ticket=ST-eyJhbAbdOiJkaXIiLCJlbmMiOiJBMTI4Q0JDLUhTMjU2In0..SCWcwVtbK9xcZKCYm12Tpw.9h03gCwnzeC6xBNwvDojAJs1b6zIIn4AxA02jrx_CZ5m8r2enNjIiS70wJWvSx_a1bq_EekSTCAFU01b93UopZNuEPDExZ1A9S1hur6t-IWTYfDS1WfKKh9CyKRSvUTqPkug-lf3UoPR4KTXgjhrXIC_nTxX_TJX6lIXsTEKTDPA0GZXRkHAB9PGTy98X1orm10qN_q8zMefo7aCqVIcx3WRrqs4XvwBVqY3oGv8oNN4dE1jONTUonGZSWtwfHlk.s_1V8uVC7XArWHVc6ICYRA&ticket=ST-eyJhbAbdOiJkaXIiLCJlbmMiOiJBMTI4Q0JDLUhTMjU2In0..T56R8c7F8tQoSnZ2uAkckw.GB7WHWpTURuSxsMITJblSNTuYf4Rd3TiDult_HBWXm7AEOIiiHC0n2Af9SvrjOjdEGxPhkfMimQzOZgigbYG2SoQ2I0xuBRVSv0to8ib-gATbBSWoKayAqaT5CdXQuAxii1bqQ1ysdOK00jQKweaQoa-NAbDr6lTtZf9hwS5bj0x05yiczD2Pzf-w57oqPOdmmr_YrbHNy8qiMXNMp8HqmFAF0Brtpu-m_PW5skSHTpWGHXr_vPKLHsFcSHeKwTz.NkCBgoCEtf4_7xevG2_04w&ticket=ST-eyJhbAbdOiJkaXIiLCJlbmMiOiJBMTI4Q0JDLUhTMjU2In0..h7WkA0L-0cir8OxkNjXbRA.xnYyOrOAD8_fVXwrQ-kydcbTrVlEVLvACdmNAi-DVKbBF53HllKmFE2HBe3PSjaYcmI85y1xzVuZEd6JgzzfdCKPHkGY4AUAFICcxyFjruxvBULo-tp2BCSunGKp-0vwJ4Ty8fYRkj2l5AphnSaBdn_A6_lM4pW1Ietm6PxJkvUvvFE1J00LSB0mU35ys--V_ri7T-NOvRyc5hBTWdU_qun8464vTdEaDXpKADLEr4gn5VnKEOGp5M9KOkfOgVB8.jzb3spHhYsO8unDITNjHyw&ticket=ST-eyJhbAbdOiJkaXIiLCJlbmMiOiJBMTI4Q0JDLUhTMjU2In0..HblYkRPxMSEe2_11COlOYQ.V6BNdvgAqrJfh2OW2Mm5ZnnZpvu6qjdoPofumFbMo0-prIc9x92qgPIkFQPn2JCKIA8esDS-R7X4DNNq59-KBS6pnQfBgdZDD1KviF07G4xtDjCrc0PCrpnxM6Z_OovmtuRsMeXpAlBb-eQ5FuF1-LKtZAy2h_mIACsJD0GZEaD2PNKi-xRrzi0MU1NEE9y8T73ZxBzxt30LFU9NpmPHAfmXXuhRMk97326L34ae-7Uh-TMgcEeUTukFTvn0rDi1.5ACqkhDwdBwIGcaFrYb1IA&ticket=ST-eyJhbAbdOiJkaXIiLCJlbmMiOiJBMTI4Q0JDLUhTMjU2In0..1m-5uj9sJcsU4Jzu1DmDfg.H8fgd0W_xOo4IB0AKsm27NEnNM9YP8XdZURip3aW0yqgprsrfOBSlNL0jssP_YjwuNT_-IR8O5TB4iw8_tP_kf32D6vA8YavIOEPKFks3a2s8pIqk0zfp1SXn-c2g228cBctDYVh7gHANR2UgQt_WZt2A6fg2OJveD2Lan11udD1bFojIP6ADWVbkwohhwHyAIPiuXUTELCvytT3y_q_QhPqT7JEBQrRCHawRMLAnhZjXBBTJxrJEXOTE2Qiad5C.sO7povpRpOU-G3rRsN7zcg&ticket=ST-eyJhbAbdOiJkaXIiLCJlbmMiOiJBMTI4Q0JDLUhTMjU2In0..93a2rMaFy9lGj_0HN2349Q.KIkpwoYROOKglvJ5EjMkQtY2D7jacyNJ8f6viNWSj3SFOjZIXGGYwXqnOL3Wrk7M6DQAB3bGw2X4OJQ3UJY7SANYO-cUBvjgMueZ7TxtMZTE87Xl0Vo1KkFVFdP1hTwIQ1fQhRLQKOSzvOun_FXHRnWG-7rHMPBR9LX6qk1L1E5Y8Zo7edTrUEqOLIKmp719q3MUaUs5mGQimjv_MwOHbVb5c5KCnndn9jbG9CNexVxpkFt9CRpO_c4MC3WP-LlY._DCqAqUVZYJgcddeJkdVxw&ticket=ST-eyJhbAbdOiJkaXIiLCJlbmMiOiJBMTI4Q0JDLUhTMjU2In0..s41OanknH97t3zX-jUOU-A.0mhgL6z_WRdSyy5nZt8JJ-JASNl93xgAB6IBEsbFs_elu84DGASNfBtYmhIktk9PTlSYQzPTD_FEveME_ThDEEGXS3ojTQ4vRDJuR5crV41kXmrcm9kjDxtlUz_nlT0HOtuSmyQdUwHyVoNcEITkvr63-jbvBD3Z5yEWD8uZGkKLHvnOwZ6tc4tJcqsb52W5AMU3Lh6sqAidwOVtObjQvSXw9Otzk0mkKpCdIksBeeHaP9sIAalVwK6vHHHN-ean.n-VJaIwSJZxvviopuJdpYQ&ticket=ST-eyJhbAbdOiJkaXIiLCJlbmMiOiJBMTI4Q0JDLUhTMjU2In0..PPIdjwnNIqHFm0B-eimXEA.iiDs_2mHMt9yGzSjyNWMeg2tkNRKatK8Xd5vOmBg0zgfVhAxqPDii1J3SauIK9ujEJ_7oFLqnDiPWJjp-EFJVRq59Ihf6g3un5n1yNGaNUolXhVxqZ1kwZrLer0kulX1GxKWKi_YWiCJH6Zupc322GgmE8ZFAX_rB__vH8PbdtWvoTPcYE3GrmgVASPxzC0EDj1sf552F6BSk5XrmWDH6ipGaY_rTEWJ6NdPYrb0k1vAkuonhAc2zdfloaXEe3c3.6zYuKHuXrm-zlxMV3UW-RA&ticket=ST-eyJhbAbdOiJkaXIiLCJlbmMiOiJBMTI4Q0JDLUhTMjU2In0..nGaDNtyvKsn8C0ziVB-2_Q.L9DuWHfKGNumX8cd-H0UphZfjgnhBxd8clZopkWLMQOWr6VFKjPi2IM9H9Gb9hXji31txiLJoRnCc6DG75oE6-hwvWjiF4hy2tHRbm0zmnia4l0ILS2hW_Te1Wdi9Dc2XilGBrI2mjQky1YFODC0o2B5MBjKbRuCM83hliRBxFE1PgujQpl3AGvF3H4iCDKC6aYDqvFVeyJr_Bv8tVAj2gRko0z8jH4-7mjRIoEmZOt4iqWPlrdS023ZQJxyFX7h.wErxn32g48QZOn4rLWMHYg
It looks like mod_auth_cas keeps redirecting me to Keycloak, stacking the ticket tokens on each other ; this leads to Alfresco returning a 401 Unauthorized error.
Removing all the tickets but one from the URL works and redirects to the Alfresco explorer with the authenticated user.
I am unsure if this is related, but I also get the following error in the logs as soon as the server starts :
WARN [org.alfresco.wcm.client.util.impl.GuestSessionFactoryImpl]
WQS unable to connect to repository: Unauthorized
Which is caused by the following :
127.0.0.1 - - [18/May/2018:17:24:38 +0200] "GET /alfresco/service/api/login?u=admin&pw=admin HTTP/1.1" 403 425
127.0.0.1 - - [18/May/2018:17:24:38 +0200] "GET /alfresco/cmisatom HTTP/1.1" 401 5
Here are the relevant config snippets :
alfresco-global.properties :
authentication.chain=external1:external
external.authentication.proxyUserName=
external.authentication.enabled=true
external.authentication.defaultAdministratorUserNames=admin
external.authentication.proxyHeader=X-Alfresco-Remote-User
### Initial admin password ###
alfresco_user_store.adminusername=admin
#alfresco_user_store.adminpassword=209c6174da490caeb422f3fa5a7ae634
share-config-custom.xml :
<config evaluator="string-compare" condition="Remote">
<remote>
<ssl-config>
<keystore-path>alfresco/web-extension/alfresco-system.p12</keystore-path>
<keystore-type>pkcs12</keystore-type>
<keystore-password>alfresco-system</keystore-password>
<truststore-path>alfresco/web-extension/ssl-truststore</truststore-path>
<truststore-type>JCEKS</truststore-type>
<truststore-password>password</truststore-password>
<verify-hostname>false</verify-hostname>
</ssl-config>
<connector>
<id>alfrescoCookie</id>
<name>Alfresco Connector</name>
<description>Connects to an Alfresco instance using cookie-based authentication</description>
<class>org.alfresco.web.site.servlet.SlingshotAlfrescoConnector</class>
</connector>
<connector>
<id>alfrescoHeader</id>
<name>Alfresco Connector</name>
<description>Connects to an Alfresco instance using header and cookie-based authentication</description>
<class>org.alfresco.web.site.servlet.SlingshotAlfrescoConnector</class>
<userHeader>X-Alfresco-Remote-User</userHeader>
</connector>
<endpoint>
<id>alfresco</id>
<name>Alfresco - user access</name>
<description>Access to Alfresco Repository WebScripts that require user authentication</description>
<connector-id>alfrescoHeader</connector-id>
<endpoint-url>http://localhost:8080/alfresco/s</endpoint-url>
<basic-auth>false</basic-auth>
<identity>user</identity>
<external-auth>true</external-auth>
</endpoint>
<endpoint>
<id>alfresco-feed</id>
<parent-id>alfresco</parent-id>
<name>Alfresco Feed</name>
<description>Alfresco Feed - supports basic HTTP authentication via the EndPointProxyServlet</description>
<connector-id>alfrescoHeader</connector-id>
<endpoint-url>http://localhost:8080/alfresco/s</endpoint-url>
<basic-auth>false</basic-auth>
<identity>user</identity>
<external-auth>true</external-auth>
</endpoint>
<endpoint>
<id>alfresco-api</id>
<parent-id>alfresco</parent-id>
<name>Alfresco Public API - user access</name>
<description>Access to Alfresco Repository Public API that require user authentication.
This makes use of the authentication that is provided by parent 'alfresco' endpoint.</description>
<connector-id>alfrescoHeader</connector-id>
<endpoint-url>http://localhost:8080/alfresco/api</endpoint-url>
<basic-auth>false</basic-auth>
<identity>user</identity>
<external-auth>true</external-auth>
</endpoint>
</remote>
Apache config :
ProxyPass /alfresco http://127.0.0.1:8080/alfresco
ProxyPassReverse /alfresco http://127.0.0.1:8080/alfresco
ProxyPassReverseCookiePath /alfresco /alfresco
ProxyPass /share http://127.0.0.1:8080/share
ProxyPassReverse /share http://127.0.0.1:8080/share
ProxyPassReverseCookiePath /share /share
ServerName my-apache-server-url
RequestHeader set Host "my-apache-server-url"
RequestHeader set X-Real-IP "my-apache-server-url"
RequestHeader set X-Forwarded-Server "my-apache-server-url"
RequestHeader set X-Forwarded-Host "my-apache-server-url"
RequestHeader set X-Forwarded-For "127.0.0.1:8080, my-apache-server-url"
mod_auth_cas config :
CASCookiePath /var/cache/httpd/mod_auth_cas/
CASLoginURL https://my-keycloak-server-url/keycloak/realms/my-client-id/protocol/cas/login
CASValidateURL https://my-keycloak-server-url/keycloak/realms/my-client-id/protocol/cas/serviceValidate
CASProxyValidateURL https://my-keycloak-server-url/keycloak/realms/my-client-id/protocol/cas/proxyValidate
CASDebug On
<Location /share>
Authtype CAS
AuthName "CAS"
require valid-user
CASAuthNHeader X-Alfresco-Remote-User
CASScope /share
</Location>
<Location /alfresco>
Authtype CAS
AuthName "CAS"
require valid-user
CASAuthNHeader X-Alfresco-Remote-User
CASScope /alfresco
</Location>
Below is the HTTPD debug log :
[Tue May 22 18:12:37.738754 2018] [:debug] [pid 63283] mod_auth_cas.c(2058): [client XXX.XX.XXX.XXX:XXXXX] Entering cas_authenticate()
[Tue May 22 18:12:37.738817 2018] [:debug] [pid 63283] mod_auth_cas.c(580): [client XXX.XX.XXX.XXX:XXXXX] CAS Service 'http%3a%2f%2fXXX.XX.XXX.XX%2fshare%3fticket%3dST-eyJhbGciOiJkaXIiLCJlbmMiOiJBMTI4Q0JDLUhTMjU2In0..RR2EyToZ7ciuGy3XPKUVcg.oZBjcuS7OrZxk_OqU-cQDdXSzkzCq5bsKmlX3Ixt9XLAvjyPV2zoeoBjxol3zmL0hF1COsWt9QzkaF0_rWABvWPUEC9hT3QqtwMrmZMtivcdo9EDkV_3J8xSCtAjP45wPEDc0cYM50L7X6dcF76PCsgxIjEt5KUQVzDoNHwzocvdjk4_KpZEplx1l2WVJdD3UzsSoYN1YbXnPQU4kyGL33d8F1eW0VOfshrV9fz9WaKGzFG3K1ADdvADGfjSGoT3.zv7i2QPMu3AiwfXZOj3Dvw'
[Tue May 22 18:12:37.738846 2018] [:debug] [pid 63283] mod_auth_cas.c(528): [client XXX.XX.XXX.XXX:XXXXX] entering getCASLoginURL()
[Tue May 22 18:12:37.738859 2018] [:debug] [pid 63283] mod_auth_cas.c(505): [client XXX.XX.XXX.XXX:XXXXX] entering getCASGateway()
[Tue May 22 18:12:37.738865 2018] [:debug] [pid 63283] mod_auth_cas.c(595): [client XXX.XX.XXX.XXX:XXXXX] entering redirectRequest()
Why is mod_auth_cas redirecting to the SSO server while Keycloak has already returned a ticket ?
I found the issue after some time.
mod_auth_cas seems to use a CAS version above 5.2.2 which prevents tickets from having underscores.
This is a problem because the Keycloak CAS add-on generates tickets with underscores.
I worked around the issue by modifying the validCASTicketFormat function in mod_auth_cas.c and recompiling the Apache module, thus allowing tokens to contain underscores.
In the latest mod_auth_cas version, only dots, dashes and alphanumeric characters are allowed.
Related
What is the proper way to logout?
These are the keycloak client settings:
Realm: REALM
Client ID: pkce-client
Client Protocol: openid-connect
Access Type: public
Standard Flow Enabled: ON
Valid Redirect URIs: http://localhost:4200/
Backchannel Logou: ON
OpenID Connect Compatibility Modes
Use Refresh Tokens: ON
Advanced Settings:
Proof Key for Code Exchange Code Challenge Method: S256
Is there a good documentation?
My idea was to delete the token on the client side, but then the session is still active in keycloak.
The solution was to call the following URL:
http://localhost:8180/auth/realms/REALM/protocol/openid-connect/logout?id_token_hint=InR5cCIgOiAiSldUIiwia2lkIiA6ICIxUVJwMXAtbmk1WmcyZmlyRHFoRS1iS1hwemZDaWFocGs4Zi1XRkQtRDZ3In0.eyJleHAiOjE2NDE3NjUyNjYsImlhdCI6MTY0MTc2.......
OIDC standard (implemented by Keycloak) supports RP initiated logout. So make browser redirect (not a XMLHttpRequest request only) to end_session_endpoint with proper logout parameters.
BTW: end_session_endpoint is not the same as revocation_endpoint; logout != revocation.
But this is OIDC logout only (logout from the Keycloak). You may have still own app session (it depends on the app implementation), so app needs to destroy app session ("delete refresh token on the client side", ...) to have logout from the app.
You can create a logout service backend that you make available on /logout endpoints of all your services.
When the service is called, it first obtains the ID token for the client used to connect:
curl -k https://<keycloak-host>/auth/realms/<realm>/protocol/openid-connect/token \
-d "grant_type=client_credentials" \
-d "client_id=<client-id>" \
-d "client_secret=<secret>" \
-d "scope=openid"
See this answer.
Then it constructs a redirect URL in a format like this based on host of user:
https://<host>?cache-buster=1445660571
With an optional cache buster.
Create a redirect URL to the authorization server in this format:
https:///auth/realms//protocol/openid-connect/logout?id_token_hint=&post_logout_redirect_uri=<url encoded redirect URL>
Then create a response with status code 303 (See Other) with as Location the URL constructed above, and as headers you set the "kc-access", "kc-state", "OAuth_Token_Request_State" and "request_uri" cookies to expired. Clojure example:
(defn- expired-cookie [host cookie-name]
(str cookie-name "=; "
"domain=." host "; "
"path=/; "
"expires=Thu, 01 Jan 1970 00:00:00 GMT; "
"HttpOnly"))
Example response:
status: 303
headers:
{"Location" "https://<keycloak host>/auth/realms/<realm>/protocol/openid-connect/logout
?id_token_hint=<id token you obtained>
&post_logout_redirect_uri=<url encoded redirect URL>"
"Set-Cookie"
["kc-access=; domain=.https://<domain>; path=/;
expires=Thu, 01 Jan 1970 00:00:00 GMT; HttpOnly"
"kc-state=; domain=.https://<domain>; path=/;
expires=Thu, 01 Jan 1970 00:00:00 GMT; HttpOnly"
"OAuth_Token_Request_State=; domain=.https://<domain>; path=/;
expires=Thu, 01 Jan 1970 00:00:00 GMT; HttpOnly"
"request_uri=; domain=.https://<domain>; path=/;
expires=Thu, 01 Jan 1970 00:00:00 GMT; HttpOnly"]}
This returned response will log the user out and redirect to the constructed redirect URL (for example, where the user came from).
This /logout endpoint can be made available as a route on all services that use Keycloak.
The solution was to call the following URL:
http://localhost:8180/auth/realms/REALM/protocol/openid-connect/logout?id_token_hint=InR5cCIgOiAiSldUIiwia2lkIiA6ICIxUVJwMXAtbmk1WmcyZmlyRHFoRS1iS1hwemZDaWFocGs4Zi1XRkQtRDZ3In0.eyJleHAiOjE2NDE3NjUyNjYsImlhdCI6MTY0MTc2.......
Is it possible to set up a reverse proxy in ISPConfig?
I tried this setting on a subdomain, but I only receive a error 500.
The /var/www/influxdb2.*******.***/log/error.log says the following:
==> error.log <==
[Fri Jan 01 21:24:15.963158 2021] [proxy:warn] [pid 30333] [client ***.***.***.***:59356] AH01144: No protocol handler was valid for the URL /favicon.ico (scheme 'http'). If you are using a DSO version of mod_proxy, make sure the proxy submodules are included in the configuration using LoadModule., referer: https://influxdb2.*******.***/
For me, the proxy_http mod was missing.
Enable it via sudo a2enmod proxy_http and restart your apache with systemctl restart apache2 (thanks to https://serverfault.com/questions/773449/no-protocol-handler-valid-for-the-url-with-httpd-mod-proxy-balancer).
Also note that the "redirect type" setting sometimes seems to reset itself to "none" on saving (or at least does not display the correct value on loading the page as of ISPConfig 3.2.1). So double check that setting if something does not work.
For the "Domain" tab, settings are pretty straightforward. Just enter your domain and probably enable Let's Encrypt.
Note that this seems to use mod_rewrite for proxying. The Apache2 documentation on mod_rewrite states that better ProxyPass of mod_proxy should be used instead. So if anything breaks with some applications, this might be a starting point for further investigations (worked for me for reverse proxying to the HTTP endpoint of InfluxDB 2.0.3 at http://localhost:8086).
We are trying to setup kerberos, initially we had to initialize with kinit for the authentication to work. We have created our principals like everyone else on the team. Now all of a sudden three users are not able to get their kerberos working. Because we are all developers our machines needs to act as servers, so we have our principals created for every machines.
The weird thing is it worked for everyone at the beginning, now it is working only for few. We are able to see our keytab names in klist
This is how we created the keytabs
C:\Windows\system32>ktpass -princ HTTP/<complete system name>#<domain>
-pass <password> -mapuser <keytab_filename>#<domain> -ptype krb
5_nt_principal -kvno 0 -out c:\keytabs\<keytab_filename>Targeting domain controller: <domain server>.<domain>
Successfully mapped HTTP/<complete system name> to <keytab_filename>.
Password succesfully set!
Key created.
Output keytab to c:\keytabs\<keytab_filename>:
Keytab version: 0x502
keysize 84 HTTP/<complete_system_name>#<domain> ptype 1 (KRB5_NT_PR
INCIPAL) vno 0 etype 0x17 (RC4-HMAC) keylength 16 (some hash number)
The only difference I can see (from the kerberos working machine to the non-working machines) is that the response headers are having authorization with negotiate but response headers are not responding with a token. We are not able to figure out what the issue is.
Pragma: no-cache
Connection: keep-alive
Content-Length: 71
Cache-Control: no-cache, no-store, must-revalidate
Content-Type: text/html;charset=UTF-8
Date: Fri, 30 Jun 2017 20:18:06 GMT
Expires: 0
Server: JBoss-EAP/7
WWW-Authenticate: Negotiate
X-Powered-By: Undertow/1
I made sure that the browser is using kerberos with this
Any help is greatly appreciated.
My application was missing the jboss security negotiation dependency in the web module.
<jboss-deployment-structure>
<deployment>
<dependencies>
<module name="org.jboss.security.negotiation"/>
</dependencies>
</deployment>
</jboss-deployment-structure>
Once this dependency was added, the kerberos ticket started to appear in the request and responses
I want to access other servers from my server.
When I try to sent a GET/POST request to www.posttestserver.com, it is established successfully.
In response, that server provides me response header as:
Access-Control-Allow-Origin:*
Connection:Keep-Alive
Content-Encoding:gzip
Content-Length:129
Content-Type:text/html; charset=UTF-8
Date:Tue, 13 Jun 2017 07:24:27 GMT
Keep-Alive:timeout=5, max=100
Server:Apache/2.4.18 (Ubuntu)
Vary:Accept-Encoding
Then, how do I set this same type of header:
Access-Control-Allow-Origin:*
over my server, so that other websites accessing my server receive this in their response headers?
My server is apache2 hosted on ubuntu 16.04.
Note:
I have set this header:
Header set Access-Control-Allow-Origin "*"
in /etc/apache2/apache2.conf in section,
and in .htaccess file in /var/www/html.
Since you're on ubuntu, it would be preferable to create a short config file in /etc/apache2/conf-available/ and then use a2enconf to enable it.
This allows you to keep the shipped configuration files unmodified.
I have one problem when i am configuring 2 way SSL (client certificate) with mod_cluster on wildfly 9.0.2
-Direct connection on wildfly on port 8443 (like https://wildflyserver:8443/context) is working,
-AJP connector connection between apache and wildfly and mod_cluster is not working
-There is no HTTPS connector ?
<mod-cluster-config advertise-socket="modcluster" proxies="mc-proxy1" advertise="false" connector="http-default">
<dynamic-load-provider>
<load-metric type="cpu"/>
</dynamic-load-provider>
<ssl key-alias="aofweb" password="XXXXXX" certificate-key-file="${jboss.domain.config.dir}/keystoreWeb.jks" cipher-suite="ALL" protocol="TLSv1" ca-certificate-file="${jboss.domain.config.dir}/keystoreWeb.jks"/>
</mod-cluster-config>
-When i am using http redirect to https with web.xml configuration and redirect-socket binding the URL changes from https://apacheserver/context to https://wildflyserver:8443/context, if i had a directive preserveProxyhost it does'nt work too,
anybody have a solution ?
i manage to do it , i configure "ajp" connection , in listener scheme https,
in case of in httpd listener certificate-forwarding=true and redirection on https,
in web.xml auth-method to CLIENT-CERT and transport-guarantee to CONFIDENTIAL,
and then the most important in apache, client verification mandatory and forward cert data :
SSLHonorCipherOrder on
SSLVerifyClient require
SSLVerifyDepth 10
#THE CA USED TO GENERATE CLIENT CERTIFICATE
SSLCACertificateFile /etc/httpd/certs/cacert.pem
SSLOptions +ExportCertData
SSLOptions +StdEnvVars
Require all granted
tell me if you have problem :
widlfy 9.0
apache 2.4
mod_proxy_ajp
mod_ssl
mod_proxy
modcluster 1.3.1