Release 6.8.2
Release 6.8.2 has just gone live. This adds title-specific login pages, so you could direct someone to

/login/peerage

or

/login/timeoutlondon

and they'll see a page tailored for that publication. We pick up the publication name and any branding (logo, favicon, colours).

This is particularly aimed at librarians, so that they can add the appropriate link to their catalogue. Library users who might have been confused by our generic login page can now see exactly what it is they're trying to access, and be reassured that they've arrived at the right site.

T

Labels: library cards, release

- posted by Tim Bruce @ 12:47 PM 0 comments

 
Blake
Supporting Shibboleth is all well and good, but you need to communicate with other parties to make it worthwhile. Participating organisations are commonly arranged into federations; we need to join one.

Each federation has its own rules about who they'll trust, and one of the qualifications for joining our local collective is that we have a server certificate issued by one of their approved certificate authorities. Our existing SSL certificate isn't on the list, so it (and we) are not coming in...

Tomorrow to set about acquiring a revised certificate which ticks all relevant boxes.

One test machine is now running with a freshly-built Shibboleth installation, though it's not configured to secure anything yet. Let's see how it holds up overnight.

T

Labels: shibboleth

- posted by Tim Bruce @ 1:12 AM 0 comments

 
OpenSAML 2 compilation
Compilation of OpenSAML 2.1 is failing on my linux machine with

make[2]: Entering directory `/home/exact/shibuild/opensaml-2.1/saml'
if /bin/sh ../libtool --silent --tag=CXX --mode=compile g++ -DHAVE_CONFIG_H -I. -I. -I..   -I/opt/shibboleth-sp/include -pthread -Wall -O2 -DNDEBUG -I/usr/kerberos/include     -pthread  -Wall -O2 -DNDEBUG -MT SAMLConfig.lo -MD -MP -MF ".deps/SAMLConfig.Tpo" -c -o SAMLConfig.lo SAMLConfig.cpp; \
then mv -f ".deps/SAMLConfig.Tpo" ".deps/SAMLConfig.Plo"; else rm -f ".deps/SAMLConfig.Tpo"; exit 1; fi
In file included from saml2/core/Protocols.h:26,
                 from SAMLConfig.cpp:47:
../saml/saml2/core/Assertions.h: In static member function `static 
   opensaml::saml2::Condition* 
   opensaml::saml2::ConditionBuilder::buildCondition(const 
   xmltooling::QName&)':
../saml/saml2/core/Assertions.h:480: cannot convert `
   opensaml::saml2::Statement*' to `opensaml::saml2::Condition*' in return

and a similar error in saml/saml2/core/Assertions.h .

Looking at the code I can't see why you'd expect it to work - though it's been a while since I've done much C so I'm definitely missing something subtle!

The lines are

            static Condition* buildCondition(const xmltooling::QName& schemaType) {
                const ConditionBuilder* b = dynamic_cast<const ConditionBuilder*>(
                    XMLObjectBuilder::getBuilder(xmltooling::QName(samlconstants::SAML1_NS,Condition::LOCAL_NAME))
                    );
                if (b) {
#ifdef HAVE_COVARIANT_RETURNS
                    return b->buildObject(samlconstants::SAML1_NS, Condition::LOCAL_NAME, samlconstants::SAML1_PREFIX, &schemaType);
#else
                    return dynamic_cast<Statement*>(b->buildObject(samlconstants::SAML1_NS, Condition::LOCAL_NAME, samlconstants::SAML1_PREFIX, &schemaType));
#endif
                }
                throw xmltooling::XMLObjectException("Unable to obtain typed builder for Condition.");
            }

so it looks as if it's trying to cast the return value to a Statement* before handing it back as a Condition*. I'm changing the dynamic_cast instruction to match the declared return type and crossing my fingers - I can't see any discussions about this on the web so I must be missing something.

T

Labels: c, shibboleth

- posted by Tim Bruce @ 4:25 PM 0 comments

 
Imports and uploads
Uploading the Shibboleth tarballs to our first live test machine while the Wednesday imports chug along in the background.

There are only a couple of days left before I'm off for a week. Planning to consolidate the Shibboleth work so we're in a position to hook up with external IdPs when I'm back.

Any spare time's going to go into S3 research.

T

Labels: projects, shibboleth

- posted by Tim Bruce @ 1:16 PM 0 comments

 
Release 6.8.1
Release 6.8.1 has just gone live on the site. New features in this release:

Library card logins

The institutional login system now supports library cards, so members of a library can log in from any machine - not just their nominated IP range.

Revised login page

There's a new Javascript switcher to offer a selection of login methods. You'll always see "username" and "library card"; depending on your location you may see "IP" in the list too.

If your browser doesn't support Javascript you'll see all the options at once, stacked from top to bottom.

Experimental Shibboleth support

The bit that links your authenticated Shibboleth login to an existing account is in place. Not yet in place: live site Shibboleth configuration and WAYF service.

T

Labels: library cards, release, shibboleth

- posted by Tim Bruce @ 12:41 AM 0 comments

 
Card tricks
The library card login system is just about ready - we can set up new schemes, recognise valid cardholders and log them in. The last thing to do is to rationalise the presentation of the various options on the login page. Soon you may have to choose from:

• IP authentication


• Username / password


• Library card


• Institutional (Shibboleth)

and it's going to be confusing for the user if we present all the forms at the same time.

Working with the ever-useful prototype library to show and hide the different forms on the fly.

T

Labels: javascript, prototype, Tools

- posted by Tim Bruce @ 5:52 PM 0 comments

 
Pause
Added a suitable error message to display when we don't recognise you from your Shibboleth login, and merged the code into the main trunk. Once this is live I can start some more realistic tests with public ID providers before addressing the where-are-you-from side of things.

Switching to a different kind of institutional feature this afternoon - library cards, here we come.

T

Labels: projects, shibboleth

- posted by Tim Bruce @ 2:21 PM 0 comments

 
Thank you, RequestMap
I was getting into a tangle between mod_rewrite and Shibboleth, trying to get Shibboleth to filter access to a particular URL, which would then be rewritten to go through our standard login handler. Trying to fix the ordering so that the Shibboleth filter got to handle the URL before it was rewritten was perhaps impossible - and turns out to be unnecessary.

In the shibboleth2.xml you can specify which requests Shibboleth should intercept, down to the level of query strings. So in the RequestMap I can specify

<Host name="sp.machine">
	<Path name="/path/to/loginServlet">
		<Query name="action" regex="loginShibboleth"  authType="shibboleth" requireSession="true"/>
	</Path>
</Host>

and have Shibboleth leave all the existing requests to the login page alone, catching only those which ask for the new authentication mechanism. The documentation notes one caveat:

Query string matching can be difficult, because the client totally dictates the information, and case matters. It should be used only when the case of the parameter name is significant to the application consuming it, because then the client can bypass your rule, but not actually get the application to run.

which suits us fine - you're either invoking the Shibboleth login (for which you need the query parameter as specified), or you're not (in which case you meet our existing authentication code).

T

Labels: config, shibboleth

- posted by Tim Bruce @ 11:20 PM 0 comments

 
Remote User
Shibboleth is now telling our application the "identity" of the athenticated user, so we're good to go: based on that, we can log them into our own authentication service and serve them the correct content.

The identity we receive turns out to be very flexible. In the service provider's shibboleth2.xml you can nominate a list of options in the REMOTE_USER attribute:

REMOTE_USER="affiliation eppn persistent-id targeted-id"

and the first available attribute in the list is set as your request's REMOTE_USER. Attributes are available if they have been supplied by the IdP and are defined in the SP's attribute-map.xml.

We can then pull the supplied ID out in Tomcat with:

s_logger.info("Remote user: "
                  + hsreq.getRemoteUser());

so we'll aim to package up the eduPersonScopedAffiliation attribute as the REMOTE_USER and check for a known scope to identify the institution.

T

Labels: config, shibboleth

- posted by Tim Bruce @ 2:29 PM 0 comments

 
Behold: the weekend
My local apache is now running a test installation of our site, alongside the modified Shibboleth sample install. Tweaked the config to require Shibboleth authentication before access to the login page is granted (this is for test only - the real implementation will protect a dedicated Shibboleth gateway page).

Seems to be working! Next to check from the login action that Shibboleth really is setting the additional HTTP headers we expect, then the integration work can begin.

T

Labels: shibboleth

- posted by Tim Bruce @ 5:19 PM 0 comments

 
MarsEdit
is looking mighty useful - this is my first, test post using it and I only downloaded it a moment ago.

It creates a great first impression by

• demanding the minumum of configuration possible


• hooking into Growl


• using familiar navigation keystrokes in the editor


• displaying a live preview as you type

So far, so great. Blogger's own interface doesn't work too well in Safari (the "log in as another user" link is broken) or Firefox (my finger habits for start/end of line in the text editor try to move me through my browse history instead).

Rediscovered tune of the day:



T

Labels: Music, Tools

- posted by Tim Bruce @ 3:38 PM 0 comments

 
Attributes and dependencies
The test IdP is now sending the eduPersonScopedAffiliation attribute, as well as a new attribute I created for testing. It all seems pretty reasonable, provided you remember to hook the AttributeDefinition up to some actual data - I forgot to add the

<resolver:Dependency ref="staticAttributes" />

element and wondered why the scoped affiliation attribute wasn't showing up in the session.

Another gotcha: you can use the aacli.sh tool to check from command line what your IdP is going to send to the SP. This is really useful. However, at least on the default Leopard JDK you need to install the Xerces and Xalan jars to work around a bug in the built-in XML parser. This is fine, and the documentation points you in the right direction - but don't put the jars in the

/System/Library/Frameworks/JavaVM.framework/Home/lib/endorsed

directory, where you might expect them to go. Instead they need to go into the idp/lib/endorsed directory; the aacli.sh script sets up the location for endorsed jars explicitly.

T
- posted by Tim Bruce @ 5:11 PM 0 comments

 
sudo and DYLD_LIBRARY_PATH
I've installed the shibboleth service provider modules on my macbook under /opt/shibboleth-sp. This means that shared libraries are under /opt/shibboleth-sp/lib, and this isn't somewhere OS X expects to look for shared libraries.

That's a problem when you run apache or shibd, which will both complain that they can't find what they need.

You can tell the OS where to find the libraries with

export DYLD_LIBRARY_PATH=/opt/shibboleth-sp

before you attempt to run any of the apps, and you can even add it to your .bash_profile so it's always set. However, if you need to run one of these apps as root:

sudo /opt/apache2/bin/apachectl restart

you'll still see the errors about missing libraries.

I've been trying to find a way to set the library path for root, but because of the way sudo invokes the shell (non-login, non-interactive) there don't seem to be any suitable .profile-like scripts which will get read. If you actually log in as root:

sudo su -l

then your root .profile will certainly get read - but I don't want to log in as root every time I need to restart apache.

There's an env_keep option in the sudoers file to keep existing environment variables for the subshell, but from what I can see in other discussions, setuid apps like sudo don't get the option to inherit anything related to dynamic library paths. I can see there would be a good reason for that.

So: current plan is to create a very small wrapper script which sets the DYLD_LIBRARY_PATH and invokes a supplied command, then use that through sudo.

T
- posted by Tim Bruce @ 12:49 PM 0 comments

 
The local Shibboleth test installation is now working - I can set up users on the IdP and require them to login to access a protected resource on the SP side. Woohoo!

Labels: shibboleth

- posted by Tim Bruce @ 5:29 PM 0 comments

 
IdP Machine Name

This error:

Please include the following error message in any email:

Identity provider lookup failed at (http://sp.machine/secure)

EntityID: https://idp.machine/idp/shibboleth

opensaml::saml2md::MetadataException: Unable to locate metadata for identity provider (https://idp.machine/idp/shibboleth)

arises because the default config in

/opt/shibboleth-idp-2.0.0/metadata/idp-metadata.xml

uses a different machine name in the entityID attribute from the "idp.machine" used elsewhere in the example.

Fixed that, now onto a ssh error...

T

Labels: config, shibboleth

- posted by Tim Bruce @ 3:56 PM 0 comments

 
Looking better - apache's up and running and talking to the SP side of Shibboleth. This is a straightforward apache install with

./configure --prefix=/opt/apache2 --enable-proxy --enable-ssl

Now receiving config errors in the browser (a definite improvement):

Unknown or Unusable Identity Provider

The identity provider supplying your login credentials is not authorized for use with this service or does not support the necessary capabilities.

T
- posted by Tim Bruce @ 3:20 PM 0 comments

 
Setting up Shibboleth.

I'm starting with a test installation on my MacBook before we roll it out across our Linux servers. To get a better idea of what's going to be involved I'm building from sources throughout, rather than using the Mac ports option.There's a guide, but I've run into a few problems.

My initial goal is to get the local end-to-end sample running.

Tomcat is up and serving the IdP side of things fine, as far as I can tell - at least I can get an error/login page from the servlet, so it's fine for now.

What I couldn't do last night was to get Apache to load the Shibboleth module. This is the Apache 2.2 which ships on OS X Leopard. Checking the config:

sudo apachectl -t

it failed with:

Syntax error on line 13 of /private/etc/apache2/other/shibboleth.conf: Cannot load /opt/shibboleth-sp/lib/shibboleth/mod_shib_22.so into server: dlopen(/opt/shibboleth-sp/lib/shibboleth/mod_shib_22.so, 10): no suitable image found. Did find:\n\t/opt/shibboleth-sp/lib/shibboleth/mod_shib_22.so: mach-o, but wrong architecture

Checking to see what kind of a module I'd built:

file /opt/shibboleth-sp/lib/shibboleth/mod_shib_22.so

shows

/opt/shibboleth-sp/lib/shibboleth/mod_shib_22.so: Mach-O bundle i386

which seems to be the source of the problem. The Apache shipped with Leopard expects 64-bit modules, and this is 32.

I then went back through the build process, supplying

CFLAGS='-arch x86_64' LDFLAGS='-arch x86_64'

to the "configure" steps:

./configure CFLAGS='-arch x86_64' LDFLAGS='-arch x86_64' APXSLDFLAGS='-arch x86_64' --with-apxs=/usr/sbin/apxs --with-log4shib=/opt/shibboleth-sp --prefix=/opt/shibboleth-sp

in the hope building a suitable binary.

One gotcha with this: the test suite for the log4shib package uses C++, and if you forget to add

CXXFLAGS='-arch x86_64'

(ie duplicate the C compilation flags for C++), you'll get link errors like this:

ld: warning in testmain.o, file is not of required architecture
Undefined symbols:
"_main", referenced from:
start in crt1.10.5.o
ld: symbol(s) not found
collect2: ld returned 1 exit status
make: *** [testmain] Error 1

as one architecture bounces off the other...

So: all was going well until I re-ran the shibboleth configuration step. This ended with

checking Xerces version... OK
configure: error: unable to link with Xerces

as Xerces was still 32-bit. Trying to recompile Xerces-C as a 64-bit binary led to all kinds of exciting and seemingly platform-specific problems, like:

MacOSPlatformUtils.cpp: In function ‘XMLCh* xercesc_2_8::XMLCreateFullPathFromFSSpec_Classic(const FSSpec&, xercesc_2_8::MemoryManager*)’:
MacOSPlatformUtils.cpp:1395: error: ‘CInfoPBRec’ was not declared in this scope
MacOSPlatformUtils.cpp:1395: error: expected `;' before ‘catInfo’
MacOSPlatformUtils.cpp:1396: error: ‘catInfo’ was not declared in this scope
MacOSPlatformUtils.cpp:1396: error: ‘struct FSSpec’ has no member named ‘name’
MacOSPlatformUtils.cpp:1397: error: ‘struct FSSpec’ has no member named ‘vRefNum’
MacOSPlatformUtils.cpp:1399: error: ‘struct FSSpec’ has no member named ‘parID’

This was all getting rather deep and distant from my original goal of testing Shibboleth...

Which brings us to the new plan. Build and install a fresh 32-bit apache server and use that for testing. The production server's going to be 32-bit anyway.

T
- posted by Tim Bruce @ 11:57 AM 0 comments

 
That was then, this is now.

Hello! Hope you're all well.

Time to keep an online notebook again. I've been using text files on a thumb drive - but it's just not the same. Googling your thumb is inconvenient.

More, later.

T
- posted by Tim Bruce @ 10:31 AM 0 comments