In this tutorial I show how to get the Shibboleth Identity Provider (IdP) to release a user’s mail attribute from an LDAP store. If you don’t have an IdP installed, perhaps you’d like to spend a happy half hour reading my other tutorial - Coffee break Shibboleth IdP install with custom certificate, login page and LDAP.
In this tutorial I show how to install the Internet2 Shibboleth IdP, link its authentication to LDAP, customise its login page and use custom certificates. I’ll be using SAML2 rather than Shibboleth as that’s the main use case these days and installing on unix (OS X in my case). For an overview of the relationship between Shibboleth and SAML you could do worse than read my contribution to the SCURL Walk In Access Report which tries to clear up the confusion that can arise when people talk about Shibboleth and SAML. It’s on page 30, Section 3.1 Security Assertion Markup Language of the PDF report. You’ll also register and test your new IdP with the TestShibb2 service and hopefully along the way keep your sense of humour while dealing with middleware configuration. What’s that about coffee break though? Surely it takes more than 15 minutes to install a Shibboleth IdP? Well, it took me about an hour the first time, what with having to search around for how to do the various things but after blowing it away and doing it again, it did take about 15-20 minutes. Enough time for a refreshing brew. So, let us begin…
Guanxi releases are pretty rare these days as I don’t really do much with the SP now and moving to the ‘standard’ IdP is prolly a good long term move. However, I needed to make a Guanxi IdP release to cope with the new SAML2 attribute landscape.
The Internet2 Embedded Discovery Service (EDS) was recently released on beta so I thought I’d plumb it into the Guanxi Service Provider. The install instructions are pretty simple and The JSON schema is here. You basically just copy the files to somewhere on your SP and then feed it JSON generated from the metadata the SP consumes as part of its normal duties and bob’s your uncle.
Embedding it in Guanxi was fairly simple since I rejigged the profile handling into what is essentially a Profile Controller, called the Generic Profile Service (GPS). Guards redirect to this when requesting federated access and inserting a new handler, SAML2DiscoveryProfileService, I could easily create a feedback loop to replay the Guard request but populated with an entityID, chosen by the user from the EDS.
I’ve now released v1.1.0 of the GuanxiAuthenticator that lets you use Shibboleth or SAML2 Web Browser SSO to get into Blackboard. Download it from my github repo.
I’ve just finished Shibboleth enabling Blackboard so I thought I’d publish a gist on how to access attributes from a Guanxi Guard. The Guard is a simple Servlet Filter that sits in front of your web application and does the Shibboleth or SAML2 handshakes. Once it’s finished, your application has access to the attributes from the Identity Provider that released them. There are two ways to do this. If your code doesn’t have access to the ServletContext, you can extract them from the request headers using this code. If you do have access to the context, you can load up the Pod directly and gain access to the attributes and the raw SAML they came in using the Pod API, using this code. The whole gist is here.
I’ve been working on a messaging system using Apache ActiveMQ embedded in Apache Camel, exposing JMS and Stomp topics that applications can use to provision themselves. As it’s basically a view of digital reality in how it relates to account creation, I decided to call it The Matrix. I’ve already plugged ActiveDirectory into it using GADfly and now Blackboard has a Head Plug. It’s a Building Block I developed that pulls from its own topic in The Matrix and the control page is Shibboleth enabled using Guanxi. Access is determined by the value of your urn:mace:dir:attribute-def:eduPersonEntitlement attribute. The control page lets you start and stop the topic consumer as well as troubleshoot and get diagnostic reports, once I’ve done that bit.
It’s nice to see the original concept coming together. Shibboleth, Messaging, Provisioning and a plethora of programming languages. It’s been a real journey to get this point, plugging two high profile systems into The Matrix.
WAYFless URLs are great. They let you bypass the WAYF monster and go straight to your IdP and then to your chosen electronic resource but you have to be aware that they can break without warning. There are two types of WAYFless URL. Managed and Unmanaged. A Managed WAYFless URL is provided by the Service Provider and works entirely on their domain:
this type of URL will direct you straight to your IdP. An Unmanaged URL looks like this:
https://uni.ac.uk/shibboleth/sso?SHIRE=https://supplier.com/blah/& ... (more...)
Back when it was first touted as the next generation access management paradigm, Shibboleth was hailed as the hero that would free electronic resource providers and consumers from the shackles of local account administration. One username/password would get you into all resources to which an institution subscribed. Turns out, the shackles were indeed removed from the suppliers but were then divvied up and redistributed among the suppliers and subscribing institutions. How can this be? A Shibboleth enabled supplier just consumes attributes and opens its digital doors in accordance with the values of those attributes. Therein lies the problem though. Most suppliers in the UK Federation just want eduPersonTargetedID (ePTID) for personalisation and maybe eduPersonScopedAffiliation or eduPersonAffiliation. They assume the Identity Provider (IdP) is working on behalf of one institution. So if you assert ePTID you get access to the resources. But what if the IdP is working on behalf of a federation of institutions? and the supplier has all the resources lumped into one access bundle? It can take up to 6 months to partition those resources based on attribute names/values. (more…)
I had word from the interweb that the Guanxi SP Engine was having a bit of trouble trusting Internet2 Shibboleth IdPs, throwing the error:
The Reference for URI #_1f08ed98488ed7e4f602628fa9d194cb has no XMLSignatureInput
That’s a pretty garbled message but I’d previously come across this in the Engine to Guard comms: XMLBeans and DOM3. The problem is, the I2 IdP is signing the SAML Response using a “non standard” ID attribute, which is only supported in DOM3 and XMLBeans does not support DOM3 and there are no plans to do so. So the only way round it is to break out into DOM land. However, if you’re dealing with signature verification, toString() breaks everything, when injecting the SAMLResponseDocument into a DocumentBuilderFactory. The improved solution is to use an InputStream: (more…)