Hitting Shibboleth from a Cloud Service

Say you use a mobile browser to hit a web resource which is protected as an SP (service provider), authenticated by a Single Sign-On service's IdP (Identity Provider). Say you authenticate, get your resource, and then switch from wifi to your cellular data provider. If you then refresh the resource, this will hide your SP session (so, it will send you back to the IdP login page), because your IP has changed -- although your original session will probably still work if you switch back to your wifi network. This is the system behavior if your SSO uses the default settings.

But you can configure Shibboleth SP to ignore the changing IP address, by adding this property to the Sessions element in /etc/shibboleth/shibboleth2.xml:

consistentAddress="false"

so that it looks something like:

<Sessions
lifetime="28800"
timeout="3600"
relayState="ss:mem"
consistentAddress="false"
checkAddress="false"
handlerSSL="false"
cookieProps="http">

... and then restart shibd.

What does this have to do with a cloud service? Well, if you tried to turn your Google App Engine cloud-based application, on appspot.com or some configured domain, into a User Agent (UA), in the UA/SP/IdP trinity, and you check the logs on the SP or IdP, you will notice that as a UA Google changes IP addresses constantly. So, as said above, you need to turn off the SP's hidden default 'true' value for consistentAddress.

If you want your SSO system to work in this scenario, you'll probably also need to ignore different IP's on the IdP. This is a little harder: you need to re-install shibboleth (without overwriting the existing configuration). But first -- go to the directory you installed the Shibboleth IdP from, then go to src/main/webapp/WEB-INF, and edit the web.xml file. Add the following within the filter section, right after the end of the definition of the filter class:

<init-param>
  <param-name>ensureConsistentClientAddress</param-name>
  <param-value>false</param-value>
</init-param>

Then you need to: 

• stop tomcat
• run the install script again -- make sure to answer "no" to "Would you like to overwrite this Shibboleth configuration?"
• start tomcat

Then you can use HTTPClient or your favorite user-agent framework to interact with the Shibboleth IdP and SP from Google App Engine or Google Cloud Platform.

Shibboleth IdP: "Error Message: SAML 2 SSO profile is not configured for relying party"

Say that your service has suddenly stopped letting you sign on, and you get this error message: "SAML 2 SSO profile is not configured for relying party".

This is an 'accurate' but confusing bit of text for people who are using an SP (Service Provider) which suddenly can't authenticate against an IdP (Identity Provider) in the Shibboleth SAML 2 Single Sign-On system. 

Although there are other possibilities, the probability is that your SP's metadata has expired. 

The metadata (which is an XML response available through a URI, which, after it is fetched from the SP, sits as an XML text file on the IdP) has a 'validUntil' property that you can check, if you have access to the metadata directory of the IdP. If you aren't the admin of the IdP, but are the admin of the SP, you need to contact the IdP, so you can get new metadata to the them, and set up a regular pull of metadata.

If you're a user, you need to contact the SP, the 'service provider', i.e. the administrator of the application you were trying to use, or the web resource you were trying to access.

So, why this error message? If you read the debug output in the logs, it is possible to comprehend. The '/conf/relying-party.xml' file has entries that point to files in the metadata directory, one for each 'relying party', i.e. SP. If the metadata file is no longer valid, then there's no configuration information for the relying party. Just about any configuration problem with the SP could trigger this error, but expiration is clearly the most common occurrence. 

So, I'd recommend to the Shibboleth team that they spend a moment and provide a more detailed reason in this error message ... this increase in detail will actually make it easier to see what's going on, from a non-expert's standpoint. Because 'profile' and 'relying party' may be 'technically correct' here, but these terms don't provide enough hints for human comprehension. 

This is a pretty pervasive issue with Shibboleth ... the software is not written with sufficient quality explanation. This makes it far less useful than it deserves to be. If the meaning of the messages and operations and technical directions of a human-made system are not explained sufficiently and simply enough for smart people, outside of the culture of developers for a project, then the meaning of the software is still locked within the minds of that team, and will die with them, making the software useless. 'Good code' is not enough. It's not good, in fact, if simple things that people need to understand take months of unnecessary study. I would advocate for a consortium to provide grants to some good technical writers to try again at documenting Shibboleth for the rest of humanity.