Bug 1253857 - ipsilon client saml nameid kerberos authentication issue
ipsilon client saml nameid kerberos authentication issue
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: ipsilon (Show other bugs)
Unspecified Unspecified
unspecified Severity unspecified
: rc
: ---
Assigned To: Rob Crittenden
Namita Soman
Depends On:
  Show dependency treegraph
Reported: 2015-08-14 19:07 EDT by Scott Poore
Modified: 2015-08-20 09:21 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2015-08-20 09:21:29 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
idp http logs (10.86 KB, application/x-gzip)
2015-08-14 19:09 EDT, Scott Poore
no flags Details
sp http logs (1.03 KB, application/x-gzip)
2015-08-14 19:10 EDT, Scott Poore
no flags Details

  None (edit)
Description Scott Poore 2015-08-14 19:07:31 EDT
Description of problem:

Trying to use the kerberos nameid for saml on an Ipsilon client, I'm having problems authenticating.

This is what I'm seeing from the web interface when I try to log in:


This server could not verify that you are authorized to access the document requested. Either you supplied the wrong credentials (e.g., bad password), or your browser doesn't understand how to supply the credentials required.
Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1.  Install IPA server and 2 clients
2.  On one client install Ipsilon IDP with ipa support
3.  On other client install with nameid set to kerberos

ipsilon-client-install --saml-auth /secure --saml-idp-url https://idp.testrelm.test/idp --saml-sp-name $(hostname -s) --saml-nameid kerberos

4.  Configure /secure httpd access:

kinit admin
ipa service-add HTTP/`hostname` --force
ipa-getcert request -f /etc/pki/tls/certs/server.pem \
    -k /etc/pki/tls/private/server.key \
    -K HTTP/`hostname`
vim /etc/httpd/conf.d/ssl.conf
SSLCertificateFile /etc/pki/tls/certs/server.pem
SSLCertificateKeyFile /etc/pki/tls/private/server.key
systemctl restart httpd
mkdir -p /var/www/html/secure
cat > /var/www/html/secure/index.html <<EOF
<html><title>Secure</title>Hello there...from $hostname ...<br>
<a href="/saml2/logout?ReturnTo=https://$hostname/logged_out.html">Log out</a>
<!--#printenv -->

cat > /var/www/html/logged_out.html <<EOF
Congratulations, you've been logged out!
Now try to <a href="/secure/">log back in</a>

sed -i '/\/secure/a \    Options +Includes' /etc/httpd/conf.d/ipsilon-saml.conf
sed -i '/\/secure/a \    AddOutputFilter INCLUDES .html' /etc/httpd/conf.d/ipsilon-saml.conf

systemctl restart httpd

5.  Access from web browser

Actual results:

Error shown above.

Expected results:

Access without errors.

Additional info:

Will attach web logs for both SP and IDP soon.
Comment 1 Scott Poore 2015-08-14 19:09:47 EDT
Created attachment 1063191 [details]
idp http logs
Comment 2 Scott Poore 2015-08-14 19:10:09 EDT
Created attachment 1063192 [details]
sp http logs
Comment 4 Rob Crittenden 2015-08-18 12:05:02 EDT
It is definitely related to the nameid. For some reason it is being rejected despite being in the allowed list:

[Fri Aug 14 17:59:31.216350 2015] [:error] [pid 26989] [14/Aug/2015:17:59:31]  DEBUG(providers/saml2/provider.py:195 ServiceProvider.get_valid_nameid()): Requested NameId [urn:oasis:names:tc:SAML:2.0:nameid-format:kerberos]
[Fri Aug 14 17:59:31.216956 2015] [:error] [pid 26989] [14/Aug/2015:17:59:31]  DEBUG(providers/saml2/provider.py:200 ServiceProvider.get_valid_nameid()): Allowed NameIds ['unspecified', 'persistent', 'transient', 'email', 'kerberos', 'x509']
[Fri Aug 14 17:59:31.217824 2015] [:error] [pid 26989] [14/Aug/2015:17:59:31]  DEBUG(ipsilon/providers/common.py:28 AuthenticationError.__init__()): Unavailable Name ID type [urn:oasis:names:tc:SAML:2.0:status:AuthnFailed]
Comment 5 Rob Crittenden 2015-08-18 14:11:03 EDT
Scott, I think I figured out what you did.

Did you authenticate using username/password instead of having a valid Kerberos ticket?

If so, that explains it, as the only NameId allowed is Kerberos so if you don't authenticate with Kerberos, it fails to log you in and explains the 401.

So basically you authenticated ok but with the wrong kind of credentials so you aren't allowed in.
Comment 6 Scott Poore 2015-08-20 09:21:29 EDT

Yes, that was it.  With a kerberos ticket, I'm able to connect and do see the nameid-format as kerberos as expected.

So, closing as not a bug.

Thanks for the help.

Note You need to log in before you can comment on or make changes to this bug.