Aaron,
Thanks, that clears things up quite a bit.
Regards,
Chris
-----Original Message-----
From: Aaron Coburn [mailto:[email protected]]
Sent: Friday, August 15, 2014 1:56 PM
To: [email protected]
Cc: <[email protected]>
Subject: Re: Shibboleth/InCommon authentication/authorization
Hi, Chris,
There is a page on the VCL website that describes setting up
Shibboleth-based authentication:
https://vcl.apache.org/docs/shibauth.html
> Has anyone had experience setting up VCL to
> authenticate/authorize against InCommon? I've seen, but not explored,
> what appears to be shibboleth code in conf.php.
Depending on what you want to do, you may need to touch .ht-inc/conf.php,
.ht-inc/authmethods/shibauth.php and shibauth/index.php for any site-based
customizations.
> My understanding is that I need to map the attributes provided by LDAP,
etc.
> into the data structure in conf.php. However, I foresee a few
> pitfalls, and am not sure how best to accommodate them. First, user
> names (first, last) are not provided for students for privacy reasons.
All of the attribute mapping happens in shibauth/index.php and
.ht-inc/authmethods/shibauth.php.
Typically, the shibauth.php:updateShibUser($id) function expects that either
the 'displayName' attribute exists OR both the 'givenName' and 'sn'
attributes exist. If none of those exist, the users' names will simply be
set to empty strings. As far as I know, there is no problem with that.
The only value that is absolutely needed is 'eppn'
> Second, depending on type of account (staff, student, admin, etc.)
> different attribute stores/IPs are available, with different attribute
names.
You can certainly use shibboleth attributes to inform the VCL about
authorization privileges. For this you may need to customize
shibauth/index.php
There are two relevant functions here:
updateShibGroups($userid, $groupname) and updateGroups($array_of_group_ids,
$userid)
For instance, if you are going to pull data from the
eduPersonScopedAffiliation (i.e. [email protected]), you may want
to dynamically add users to specific groups. The VCL will automatically do
this if the value of this attribute is mapped to $_SERVER['affiliation'] --
which depends on how you have shibboleth configured on the SP. If that field
is mapped to a different $_SERVER value, you'll need to modify
shibauth/index.php or the underlying /etc/shibboleth/attribute-map.xml file.
There is another field that some people use (eduPersonEntitlement) which can
also be used for these purposes. Typically this is used for informing the SP
application about authorization-level information. Personally, I don't ever
use that, preferring to let shibboleth handle AuthN while keeping AuthZ
local to the application.
What we do regarding authZ is this: users from each institution are
automatically placed into an "All Users@{$affiliation}" group. Users are
also placed into groups according to the value of
eduPersonScopedAffiliation, but we don't really make use of those groups in
the privilege hierarchy. Otherwise, I don't do any further automatic
processing. Admin (and other) groups are controlled by human administrators
rather than relying on shibboleth to assert certain privileges.
> Regarding the first point, is it possible to supply a generic name for
> all users (i.e. John Doe)? Would this cause problems with VCL?
No. There is no strict requirement for first and last name values.
> Regarding the second point, is it sufficient to add an entry to
> authMechs for each provider?
Adding code to authMechs is a necessary precondition, and it will get you
most of the way there. If you want users automatically assigned to certain
groups, you'll need to look at shibauth/index.php
> The code appears to be structured this way, so I assume so. If so, how
> is the mechanism selected for a particular login? Is each mechanism
> tried until one succeeds or all fail?
No. With SAML-based logins, you can't use this approach, as authN happens
through the browser, not through a backchannel by the application. So, the
user needs to inform the VCL application how he/she is going to login,
either by selecting from a dropdown list, clicking on a link or being
redirected to a WAYF (where are you from) page that your Shibboleth SP
provides.
> If so, how could I achieve
> preferential ordering of mechanisms (I believe Perl 5.18+ hashes are
> randomized, and so we can't rely on the ordering specified in conf.php)?
The web UI is written in PHP, and there is no such issue with random hash
orderings. There are different ways of achieving this, but this is the
approach we take (i.e. by baking the WAYF selector directly into the VCL
homepage):
https://vcl.fivecolleges.edu
Here, we have users from five institutions. Each institution uses
Shibboleth, though it is possible to mix in LDAP (just keep in mind that
there are security implications to using LDAP in a multi-institution
context). Local logins (there are very few of these) must use the dropdown
list. You'll notice that these logos are hyperlinked directly to URLs that
will establish sessions with particular identity providers. The main point,
though, is that you just need users to land on /shibauth after
authenticating with the IdP and establishing a session on the SP.
I hope that helps. Let me know if you would like any more information.
Regards,
Aaron Coburn
>
>
>
> Thanks,
>
> Chris Wolfe
>
>
>
