Closed abdul-jabbar01 closed 4 years ago
@one-t can you take a look?
Hi, @abdul-jabbar01 - can you provide the associated log entries for this failed login?
Just checking back @abdul-jabbar01 - let me know if this is still an issue.
Thanks!
Closing due to age.
Hi guys,
I am facing the same issue and hard stuck at this problem. My current IdP configuration within AWX looks like the following:
{
"ent-idp": {
"attr_last_name": "lastname",
"url": "<idp provided SP initiated SAML login link>",
"attr_first_name": "firstname",
"entity_id": "<idp provided url to entity specific metadata document>",
"attr_username": "ssoid",
"attr_user_permanent_id": "subject",
"x509cert": "<redacted, non-breaking string cert>"
}
}
with the SAML org map:
{
"Default": {
"users": true
}
}
Attributes are from a 3rd party IdP that has metadata formatted that looks like the following:
<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="<saml base url>+"/>
<md:SingleSignOnService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect" Location="<saml base url>"/>
<saml:Attribute xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" Name="ssoid" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic"/>
<saml:Attribute xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" Name="st" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic"/>
<saml:Attribute xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" Name="firstname" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic"/>
<saml:Attribute xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" Name="c" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic"/>
<saml:Attribute xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" Name="mail" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic"/>
nginx.conf
#user awx;
worker_processes 1;
pid /tmp/nginx.pid;
events {
worker_connections 1024;
}
http {
error_log /var/log/nginx/error.log debug;
include /etc/nginx/mime.types;
default_type application/octet-stream;
server_tokens off;
log_format main '$remote_addr - $remote_user [$time_local] "$request" '
'$status $body_bytes_sent "$http_referer" '
'"$http_user_agent" "$http_x_forwarded_for"';
access_log /dev/stdout main;
map $http_upgrade $connection_upgrade {
default upgrade;
'' close;
}
sendfile on;
#tcp_nopush on;
#gzip on;
upstream uwsgi {
server 127.0.0.1:8050;
}
upstream daphne {
server 127.0.0.1:8051;
}
server {
listen 8052 default_server;
server_name _;
# Redirect all HTTP links to the matching HTTPS page
return 301 https://$host$request_uri;
}
server {
listen 8053 ssl;
ssl_certificate /etc/nginx/awxweb.pem;
ssl_certificate_key /etc/nginx/awxweb.pem;
# If you have a domain name, this is where to add it
server_name _;
keepalive_timeout 65;
# HSTS (ngx_http_headers_module is required) (15768000 seconds = 6 months)
add_header Strict-Transport-Security max-age=15768000;
add_header Content-Security-Policy "default-src 'self'; connect-src 'self' ws: wss:; style-src 'self' 'unsafe-inline'; script-src 'self' 'unsafe-inline' *.pendo.io; img-src 'self' *.pendo.io data:; report-uri /csp-violation/";
add_header X-Content-Security-Policy "default-src 'self'; connect-src 'self' ws: wss:; style-src 'self' 'unsafe-inline'; script-src 'self' 'unsafe-inline' *.pendo.io; img-src 'self' *.pendo.io data:; report-uri /csp-violation/";
# Protect against click-jacking https://www.owasp.org/index.php/Testing_for_Clickjacking_(OTG-CLIENT-009)
add_header X-Frame-Options "DENY";
location /nginx_status {
stub_status on;
access_log off;
allow 127.0.0.1;
deny all;
}
location /static/ {
alias /var/lib/awx/public/static/;
}
location /favicon.ico { alias /var/lib/awx/public/static/favicon.ico; }
location /websocket {
# Pass request to the upstream alias
proxy_pass http://daphne;
# Require http version 1.1 to allow for upgrade requests
proxy_http_version 1.1;
# We want proxy_buffering off for proxying to websockets.
proxy_buffering off;
# http://en.wikipedia.org/wiki/X-Forwarded-For
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
# enable this if you use HTTPS:
proxy_set_header X-Forwarded-Proto https;
# pass the Host: header from the client for the sake of redirects
proxy_set_header Host $http_host;
# We've set the Host header, so we don't need Nginx to muddle
# about with redirects
proxy_redirect off;
# Depending on the request value, set the Upgrade and
# connection headers
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection $connection_upgrade;
}
location / {
# Add trailing / if missing
rewrite ^(.*)$http_host(.*[^/])$ $1$http_host$2/ permanent;
uwsgi_read_timeout 120s;
uwsgi_pass uwsgi;
include /etc/nginx/uwsgi_params; proxy_set_header X-Forwarded-Port 443;
uwsgi_param HTTP_X_FORWARDED_PORT 443;
}
}
}
The SAML document does seem to be getting generated with my sso specific attributes, and I cannot see any errors from the browser nor the nginx controller. The response document sequence is identical to what @abdul-jabbar01 had above along with a couple of GET calls being made to the AWX api like so:
When looking through each of the calls, I cannot seem to find any messages related to errors or anything else mentioned in the AWX docs.
I have also verified the ACS url is reflected from the IdP side, as well as the base url, and updated the AWX fqdn within the system settings.
Any guidance or suggestions as to where to look would be greatly appreciated!
Update: Turns out it was an issue with the attribute mappings and the IdP url. Nothing on the AWX side for anyone else having a similar issue :)
@brocc0lee I am facing the same issue, can you be more specific, with the IdP URL that you mention and the attribute mappings? AWX is Deployed in Kubernetes, I used SAML Tracer and I am getting the 302/301 redirects like you
@pkatopodi , the issue was that the actual SAML configuration values I had were not matching the values I set in my provider.
Primarily, ensure the SAML Service Provider Entity ID is _exactly_ the same as your provider as well as your ACS URL being the same on both sides. Additionally, your url
and x509cert
inside the SAML ENABLED IDENTITY PROVIDERS is correct as well.
@brocc0lee Thanks for the Quick Response, I was able to figure it out and it was EXACTLY that, AWX should do a better job of SAML integration documentation at least. The /sso/error suffix is not sufficient to trouble shoot and SAML Tracer doesnt give you much more info either. Thanks Again
I have the same problem and I couldn't find anything in the logs, i deployed keycloak and awx to k8s cluster in the cloud, can anyone share a screenshot where to verify the problem
Hello @Chamssiddine I have the same problem, have you found a solution? AWX version: 20.1.0 Operator version: 0.24.0
Hello @Chamssiddine I have the same problem, have you found a solution? AWX version: 20.1.0 Operator version: 0.24.0
I followed this blog:
PS: I didn't do "Click Generate new keys" from the blog
I'm still in the testing stage and the semi-solution I found is not production ready so take it we a grant of salt, anyway you need to tinker with the client settings ( I don't remember which one did work for me) activate and deactivate them one by one, and test the SSO
Email me if you want to hope in a quick meeting to sort it out for you and try to harden it to production afterward
Hello
I have the same problem
AWX integrated with my IdP via SAML. After autentification it redirects to /login page. In logs i can see string like "social Authentication failed: SAML login failed: ['invalid_response'] (Signature validation failed. SAML Response rejected)." and nothing else useful in logs. I experimented with different settings in IdP like Sign assertions, Encrypt assertions, Encrypt NameIds, but I have various errors related to signature:
I use IdP very similar to keycloak. x509cert inside the SAML ENABLED IDENTITY PROVIDERS is the same as cert of my IdP. But for some reason it writes about the problem of Signature validation.
ENVIRONMENT AWX version: 22.7.0 AWX install method: Kubernetes Operating System: Windows 11 Web Browser: Vivaldi, Edge
ADDITIONAL INFORMATION: AWX SAML IdP configuration:
{
"IdP": {
"url": "https://sso.ppod.online/blitz/saml/profile/SAML2/Redirect/SSO",
"x509cert": "MIIDLz.....................................Xt2qx",
"entity_id": "https://sso.server/blitz/saml",
"attr_email": "email",
"attr_username": "preferred_username",
"attr_last_name": "last_name",
"attr_first_name": "first_name",
"attr_user_permanent_id": "uid"
}
}
SAML Service Provider Entity ID matches SAML Assertion Consumer Service (ACS) URL except for added /sso/complete/saml/. x509cert looks like correct, it on one line without spaces and taken straight from metadata of idp.
What is the problem? This is a bug?
you can follow this small documentation I made a good while ago in a project, there is short videos of what I configured etc... to make AWX integrate with Keycloak https://rdeplatform.netlify.app/docs/Single%20Sign-On%20with%20Keycloak/Integration%20with%20AWX
ISSUE TYPE
SUMMARY
I've integrated the SML Authentication with AWX. It redirects to my IDP (I get 200 OK). Authenticate it there. And then redirects back to the http://localhost:8052/sso/complete/saml/ (here I get 302 Found) But after this, it redirects to the http://localhost:8052/sso/error/ (And here I get 301 Moved Permanently) and then to http://localhost:8052/#/login . I'm unable to login into the AWX by SAML. Please resolve the issue.
ENVIRONMENT
STEPS TO REPRODUCE
Install AWX with following docker-compose file:
Then Navigate to Settings => Authentication > SAML
And I had following configurations for IDP:
EXPECTED RESULTS
It should login into the AWX after getting response from the IDP.
ACTUAL RESULTS
It redirects to http://localhost:8052/#/login
ADDITIONAL INFORMATION
This is what I'm getting from SAML Tracer.
Sending Request to IDP
Response of IDP
And here I'm getting 301 Moved Permanently