Tuesday, August 23, 2011

Shibboleth and Liferay Part 2: Configuring Apache

This is part 2 of a set of blog posts detailing the procedure for setting up Shibboleth to provide Web SSO functionality to Liferay.

This is the part that sounds a LOT more complicated than it is.

Apache's configuration is handled in a file called httpd.conf. This file is usually found in the/etc/httpd/conf directory.

There are a few settings in this file we need to pay attention to, but keep in mind that often additional configuration items are kept in separate files and imported into httpd.conf. This allows the user to more easily keep track of related configuration items without having to navigate through one, massive file. if that's the case on your server, then somewhere in your httpd.conf file (usually near the beginning) there should be a statement that looks like this:

Include conf.d/*.conf

That statement is telling Apache to include all the files in the subdirectory conf.d that end in .conf. Yours should be similar. It may also include specific individual files.

General Settings

Open up your httpd.conf file and find your way to the ServerName setting. Set this to the name of the server. That's NAME not IP ADDRESS. The next setting below that should be UseCanonicalName. Set that to "On" in order to get the server to use the ServerName you just set. So if our server is named test.awesome.server.dude then your configuration should look like this:

ServerName test.awesome.server.dude
UseCanonicalName On

And leave the rest alone... Maybe. If your configuration is spread out over multiple separate configuration files as described above, then the rest of this will probably be located in those files. Otherwise stay in httpd.conf to do the rest.

Shibboleth Settings

Next, you should have a file called shib.conf in the directory where all of your other Include files are. It will have been pre-generated for you in some cases by the Shibboleth installation, otherwise these settings should appear in your httpd.conf file. Most of these can be left alone, but the Location tag is the one we're interested in. When Liferay is bundled with Tomcat it is the ROOT application, so for the location in the following setting, we just use / alone.

<Location />
AuthType shibboleth
ShibRequestSetting requireSession 1
require valid-user
</Location>

If your Liferay were installed in Tomcat as some other context, then the name of the folder in [Tomcat Home]/webapps/ would be the correct Location setting.

And that's it for the Shibboleth configurations in Apache.

To be continued...

2 comments:

  1. Thank you for this great tutorial once again (I asked a silly question before, hopefully this time it is actually a valid one)!
    How would I go about only protecting a part of the Liferay portal? As in, there are a few pages with general information that should be available to people not logged in, but some parts, say "my.sp/secure" that should only be available to people after authentication with the IdP. I tried changing the Apache config:
    "Location /secure"
    which seems to do just that: I get to see the portal without an account. Then I try to access my.sp/secure, Shibboleth kicks in and redirects me to our WAYF page, but after picking an IdP (but before being actually redirected there) the I end up back in Liferay and get told that the URL
    https://my.sp/Shibboleth.sso/Login?SAMLDS=1&target=cookie%3A6d75e3f8&entityID=https%3A%2F%2Fmy.selected.IdP%2Fidp%2Fshibboleth
    could not be found.
    I also tried fiddling with the RequestMap in the Shibboleth config, but to far unsuccessfully. Do you have any idea what is going wrong?

    ReplyDelete
  2. You might try allowing connections on port 80 to the portal, where a non-authenticated user can see the page and whatever resources in Liferay you've configured to be visible to non-authenticated users. You could then use a custom theme to cause the "Sign In" link in the upper corner to send the user to the secure port where Shibboleth is listening, and can handle the authentication from there. When the user is then redirected back to the portal, they're now authenticated and can view whatever additional resources they have permissions to see.

    ReplyDelete