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 > > >
signature.asc
Description: Message signed with OpenPGP using GPGMail
