Comments (3)
I have been struggling with getting Guac to work with OIDC in Authentik as well. I may have slightly different issues than you but one thing I learned may be of use to you. It appears that when you access Authentik via IP address, it will always serve up the default self-signed certificate (which may or may not be the same as the default self-signed cert that you can see in the GUI for use with providers). If you want Authentik to serve up the certificate that you created you will have to access it via hostname. If you don't have one configured you can always use the container name and an entry in your hosts file.
One other important note is that I believe the certificate configured in the provider is going to be used to sign the JWTs and NOT necessarily for the HTTPS connection. The way I was able to ensure that my own cert was used for HTTPS when accessing Authentik via hostname was to set the certificate to be used by the default brand and restart the Authentik container (System > Brands > Edit the authentik-default branhd > Other Global Settings > Web Certificate).
Don't forget to also make sure the certificates you are using have been added to the Guacamole truststore.
Doing all this has not fully solved my issue but it does get you to a point where curl via hostname will serve the correct certificate. Currently my issue is that even adding these certificates to the Guacamole truststore results in failure during JWT validation all due to various javax.net.ssl.SSLHandshakeExceptions listed below.
Using only my self-signed certs results in an apparent inability of Guac to find the correct certificate even when the configured URLs are using hostname. (sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target)
Additionally adding the default certificate that gets served with accessing Authentik via IP results in a verification error due to Guac being unable to find a certificate with a valid SAN matching the Authentik hostname. (javax.net.ssl.SSLHandshakeException: No subject alternative DNS name matching authentik-server-1 found.) This new error appearing as a result of adding this certificate suggests to me that the default certificate is still being used for some reason when it should not be.
Lastly, I updated my self-signed certificate to have an SAN set for the Authentik hostname and receive a certificate verification failure suggesting that the certificate being used for HTTPS signing is still the default certificate rather than the one I have set with an SAN value.
The main problem with this is that the default certificate being used is generated fresh at every container startup so there is no way to change it. At this point the only thing I have left to try is to set up a reverse proxy which I had been avoiding as it wasn't really necessary for my use case. I'm hoping that now that I understand more about which certs are served up and when, putting a proxy between the two services will result in the correct certs being used/expected on both sides.
If you have any breakthroughs please post them here. This is driving me insane.
from authentik.
I don't have much to add but thanks for the comment Huckleberry. I've tried various reverse proxy setups myself, since I already have one deployed for Guacamole and TLS termination. The problem with throwing both Authentik and Guac behind the TLS reverse proxy is that at some point, the browser needs to redirect in the flow and relying on internal IPs doesn't work. I'm sure there's an aspect of my configuration that was incorrect at that point, but I never got Authentik to work behind a reverse proxy either.
The only time I had Authentik+Guac working was on a completely "internal" setup with all HTTP connections and no TLS anywhere, which is totally unsuited for internet access.
from authentik.
I have been struggling with getting Guac to work with OIDC in Authentik as well. I may have slightly different issues than you but one thing I learned may be of use to you. It appears that when you access Authentik via IP address, it will always serve up the default self-signed certificate (which may or may not be the same as the default self-signed cert that you can see in the GUI for use with providers). If you want Authentik to serve up the certificate that you created you will have to access it via hostname. If you don't have one configured you can always use the container name and an entry in your hosts file.
One other important note is that I believe the certificate configured in the provider is going to be used to sign the JWTs and NOT necessarily for the HTTPS connection. The way I was able to ensure that my own cert was used for HTTPS when accessing Authentik via hostname was to set the certificate to be used by the default brand and restart the Authentik container (System > Brands > Edit the authentik-default branhd > Other Global Settings > Web Certificate).
Don't forget to also make sure the certificates you are using have been added to the Guacamole truststore.
Doing all this has not fully solved my issue but it does get you to a point where curl via hostname will serve the correct certificate. Currently my issue is that even adding these certificates to the Guacamole truststore results in failure during JWT validation all due to various javax.net.ssl.SSLHandshakeExceptions listed below.
Using only my self-signed certs results in an apparent inability of Guac to find the correct certificate even when the configured URLs are using hostname. (sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target)
Additionally adding the default certificate that gets served with accessing Authentik via IP results in a verification error due to Guac being unable to find a certificate with a valid SAN matching the Authentik hostname. (javax.net.ssl.SSLHandshakeException: No subject alternative DNS name matching authentik-server-1 found.) This new error appearing as a result of adding this certificate suggests to me that the default certificate is still being used for some reason when it should not be.
Lastly, I updated my self-signed certificate to have an SAN set for the Authentik hostname and receive a certificate verification failure suggesting that the certificate being used for HTTPS signing is still the default certificate rather than the one I have set with an SAN value.
The main problem with this is that the default certificate being used is generated fresh at every container startup so there is no way to change it. At this point the only thing I have left to try is to set up a reverse proxy which I had been avoiding as it wasn't really necessary for my use case. I'm hoping that now that I understand more about which certs are served up and when, putting a proxy between the two services will result in the correct certs being used/expected on both sides.
If you have any breakthroughs please post them here. This is driving me insane.
Not sure if I can "ping" a user here - @huckleberry1989
So, I ended up abandoning Authentik in favor of Keycloak. I got it working, forgot how I got it working, and then had to re-solve the problem today. Ultimately its pointing towards a hosts/DNS type problem, though it could be also certs/SAN. Probably a few ways to skin this cat.
tl;dr: I had to translate the external IP address to the internal IP address of my server for Guacamole to properly pull the JWT. I'm not sure if the same answer works when Authentik produces the self-signed cert upon SSL connect (this is still with Keycloak, see). The exact command I ran was:
iptables -t nat -A PREROUTING -d <PUBLIC IP> -p tcp -j DNAT --to-destination <PRIVATE IP>
Im not sure how deep I got into my own config, but currently I have a docker-compose file with Guacamole and its various components, and then another directory with the docker-compose for Authentik (now Keycloak) in its own folder. The intended goal was to "bolt on" the IdP to the existing deployment in my homelab. So ultimately both services run on the same host with the same internal IP, but on different docker networks. I did double check my hosts file, and I placed the public IPs with the resolution to my actual DNS name in it, but my internal IP is only shown with the host name, not the actual web DNS name.
So ultimately, I solved it with an iptables NAT rule, but there might be other options, including SAN names and proper reworking of the hosts file. I did previously test a "combined" deployment with both services + dependencies in the same docker-compose and docker networks, but never got it to work before. It too could probably be tweaked to work. Hope that helps with your attempts here with Authentik. I'm not sure yet what the "optimal" solution is.
from authentik.
Related Issues (20)
- Blueprint validation failures not returned to web UI
- How to use apache2 auth_openidc? HOT 1
- Redirect failing on initial login HOT 1
- 404 errors for flows on full development environment HOT 1
- authentik Embedded Outpost Proxy Doesn't work when there are many Providers HOT 1
- UI is messed up when forcing light mode with system set to dark mode
- Nextcloud SAML: Found an Attribute element with duplicated Name HOT 1
- What is the TLS version of the OIDC provider of Authentik?
- Authentik occasionally times out HOT 1
- Add documentation surrounding configuring PhotoPrism in Integrations section of website HOT 1
- How about semantic versioning? HOT 1
- No outposts found with given token, ensure the given token corresponds to an authenitk Outpost HOT 2
- Docker Compose Setup Does Not Work on MacOS or Other POSIX OSes
- Application icons disappear after a few weeks
- GET /api/v3/flows/executor/google-enrollment-flow/
- Discord docs expression policy doubt
- Getting 500 error on subpages
- (1, 'failed to sign') when using ECDSA certificate for SAML HOT 3
- LDAP outpost doesn't work with if user has TOTP HOT 1
- Can't create new application HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from authentik.