shibboleth attribute “scope () not accepted” and “value () could not be validated by policy, rejecting it”

I have a client who acts as a Shibboleth Service Provider (SP), and the corresponding Identity Provider (IdP) needed to update some of their information, so I had to spend a few hours debugging shibboleth again this morning.

The punchline: in the metadata for an IdP, there are TWO places you need to specify the scope of the IdP, once in the <IDPSSODescriptor> to cover authentication, and once later in the <AttributeAuthorityDescriptor> to cover any attributes.

Shibboleth is all about trust, and the lack thereof. The SP and IdP share a few keys, and then each maintain their own configuration files specifying how much information to trust. When a user logs in, they get bounced from SP->IdP to authenticate, then again from IdP -> SP with an auth token. From there, the SP can assume an authenticated user. If the SP wants any more information about the user (say, a username), it can make SOAP calls to the IdP requesting more attributes. The IdP checks it’s config files to see how many attributes to release to that particular SP, and sends back the attributes. The SP doesn’t trust the IdP on it’s word, so the SP checks it’s config files to validate that it can accept these attributes from this IdP. This is where I ran into a problem, getting an error like:

attribute (username) scope ( not accepted

This brings up another aspected of attributes, the scope.  An attribute’s scope seems somewhat akin to a namespace to me, it’s a way of grouping related attributes and prevent name conflicts between attributes.  In my case, my IdP was “”, and my SP was configured to accept the username attribute from any site with any value (in my AAP.xml).  However, the IdP was returning the username scoped under a different domain, so the SP, being a paranoid creature, assumes the IdP is trying to falsify information and refused the attribute.  To convince the SP to accept the different scope, you have to change the metadata for the IdP, and specify that it is allowed to provide attributes in the new scope.  Unfortunately for me, there are 2 kinds of scopes you can change:

  1. Scope of the initial authentication
  2. Scope of the attributes

There are both children of <EntityDescriptor>.  This led to a frustrating morning of restarting IIS (because you need to restart everything under the sun for the configuration to get reloaded), and not seeing any change.  There are many ways to alter your attribute policy, and along to way to discovering the second place to specify scope I ran across another error message:

attribute (username) value (my-user) could not be validated by policy, rejecting it

This seemed to happen when my SP config tried to treat the username as an unscoped attribute.  You can’t just ignore the scope of an attribute if the IdP is sending one.

The end solution is to add another <shibmeta:Scope> specification to the attributes configuration section in the IdP’s metadata:

  <AttributeAuthorityDescriptor protocolSupportEnumeration="urn:oasis:names:tc:SAML:1.1:protocol">
      <shibmeta:Scope xmlns:shibmeta="urn:mace:shibboleth:metadata:1.0" 
      <shibmeta:Scope xmlns:shibmeta="urn:mace:shibboleth:metadata:1.0" 


Comments (35)


Debugging Shibboleth and “error:14094412:SSL routines:SSL3_READ_BYTES:sslv3 alert bad certificate” errors

Mucking about with Shibboleth again, and ran into some errors on the SP, specifically:

2007-07-10 19:49:42 DEBUG SAML.libcurl [79] sessionGet: SSL read: error:14094412:SSL routines:SSL3_READ_BYTES:sslv3 alert bad certificate, errno 0

This is the “catch-all” error message for Shibboleth OpenSSL Errors. After much research and testing, it was a problem with the IdP, their server was rejecting my client certificate.

How it should work (I think)

  1. User requests protected content on the SP
  2. SP redirects to the IdP for authentication
  3. IdP authenticates user, sends an SSL (with client certificae) SOAP request to the SP with some info, and then redirects the user back
  4. SP validates SOAP request by comparing client certifacte with a white-list in the shibboleth metadata
  5. SP sends an SSL (with client certificate) SOAP request to IdP to get more information about the user (in my case, a username so I can identify them in my database)
  6. IdP validates SSL cert of SP with a white-list in their shibboleth metadata, responds with whatever information was requested
  7. SP uses that information to serve or deny access to the user from step 1

SSL cert problems can happen at steps 4 and 6. You can test these somewhat by using openssl on the command line. Openssl has about a brazillion options, but the one useful here is s_client(1).

Be sure the SP recognizes the IdP’s certs

First up, check that the SP has the IdP’s certs in order:

openssl s_client -connect HOST:443 -showcerts

That will give you back the certificate chain:

Certificate chain
i:/C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=Terms of use at (c)05/CN=VeriSign Class 3 Secure Server CA
1 s:/C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=Terms of use at (c)05/CN=VeriSign Class 3 Secure Server CA
i:/C=US/O=VeriSign, Inc./OU=Class 3 Public Primary Certification Authority

Server certificate
issuer=/C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=Terms of use at (c)05/CN=VeriSign Class 3 Secure Server CA

some other stuff…

The issuing certificate (in the example, cert 1) should be in your shibboleth metadata. All you need is the top-most issuer, and shibboleth will look down the certificat chain until it finds a certificate it trusts, and all will be well.

If that doesn’t solve it, then we see if the IdP has the SP cert straight.

Be sure the IdP recognizes the SP’s certs

This is harder to debug from the SP’s side, but you can try make an SSL connection using the SP cert and key:

openssl s_client -connect HOST:443 -showcerts -cert SP.crt -key SP.key

If that connects, then you know the server isn’t rejecting you outright, but it’s possible that Apache config is rejecting you elsewhere. The best way to check is to just ask your IdP if your config is still in their shibboleth white-list.

If that doesn’t solve it, check the apache config.

Be sure everyone’s apache config is OK

The possible failure here is that the certificate is being rejected before making it to shibboleth. You don’t want to tell your whole server to accept any client certificate, you want to just pass those through to shibboleth and let shibboleth decide. You’ll want to have SSLVerifyClient optional_no_ca in your Apache location blocks for shibboleth URLs.


Certificates are a good idea, but a pain in the ass. The shibboleth-users mailing list is a good source of information, and you can get prompt replies from there. And next time I have this problem, I’ll know where to look for debugging tips.

open source

Comments (4)