You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@vcl.apache.org by Christopher Wolfe <ch...@vt.edu> on 2014/08/15 17:19:53 UTC
Shibboleth/InCommon authentication/authorization
All,
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.
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. Second, depending on type of account (staff,
student, admin, etc.) different
attribute stores/IPs are available, with different attribute names.
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? Regarding the second point, is it sufficient to add an
entry to authMechs for each provider? 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? 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)?
Thanks,
Chris Wolfe
Re: Shibboleth/InCommon authentication/authorization
Posted by Josh Thompson <jo...@ncsu.edu>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Chris,
Jim is a great resource for this. I wrote the VCL Shibboleth code, but Jim
knows much more about Shibboleth than I do.
Aaron Coburn wrote up a good page on configuring VCL and Shibbleth:
http://people.apache.org/~acoburn/
Here is a page I wrote that is quite old, but the information is still
relevant:
https://cwiki.apache.org/confluence/display/VCLDOCS/Setting+up+Shibboleth+Authentication
Entries in the $authMechs array in conf.php for authenticating users via
Shibboleth are quite different than entries for authenticating via LDAP.
First and last name are not required to be available. So, those do not need
to be passed in attributes from Shib. EPPN is the only thing required. A
single Shib entry in conf.php allows users from different institutions to
authenticate. VCL will take the part after the @ in the EPPN to create an
affiliation for that user/institution. For example, here at NCSU, we can
(among others) authenticate users from NCSU and UNCP. A user from NCSU could
have an EPPN like user1@ncsu.edu, which would be converted to user1@NCSU in
VCL. A user from UNCP could have an EPPN like user2@uncp.edu, which would be
converted to user2@UNCP in VCL.
I hope that helps.
Josh
On Friday, August 15, 2014 8:39:23 AM James O'Dell wrote:
> Hi Chris,
>
> A few years back, I set up CSUF's VCL to authenticate and use the
> attributes from InCommon.
> (Thanks again Josh!)
>
> I even added a few attributes like 'eduCourseMember' and 'isMemberOf' (
> based on ldap groups )
>
> I'd be happy to help. Send me a message if you're interested
>
> __Jim
>
> On 8/15/2014 8:19 AM, Christopher Wolfe wrote:
> > All,
> >
> > 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.
> >
> > 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. Second, depending on type of account (staff,
> > student, admin, etc.) different
> >
> > attribute stores/IPs are available, with different attribute names.
> > 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? Regarding the second point, is it sufficient to add an
> > entry to authMechs for each provider? 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? 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)?
> >
> >
> >
> > Thanks,
> >
> > Chris Wolfe
- --
- -------------------------------
Josh Thompson
VCL Developer
North Carolina State University
my GPG/PGP key can be found at pgp.mit.edu
All electronic mail messages in connection with State business which
are sent to or received by this account are subject to the NC Public
Records Law and may be disclosed to third parties.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
iEYEARECAAYFAlPuM8gACgkQV/LQcNdtPQOO0gCfaib7nwcOVPy2zBKGEetJpMVG
aHEAn00dHTq1gcjwm3wqAmHexjj07NeE
=8jR7
-----END PGP SIGNATURE-----
Re: Shibboleth/InCommon authentication/authorization
Posted by Josh Thompson <jo...@ncsu.edu>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Chris,
Jim is a great resource for this. I wrote the VCL Shibboleth code, but Jim
knows much more about Shibboleth than I do.
Aaron Coburn wrote up a good page on configuring VCL and Shibbleth:
http://people.apache.org/~acoburn/
Here is a page I wrote that is quite old, but the information is still
relevant:
https://cwiki.apache.org/confluence/display/VCLDOCS/Setting+up+Shibboleth+Authentication
Entries in the $authMechs array in conf.php for authenticating users via
Shibboleth are quite different than entries for authenticating via LDAP.
First and last name are not required to be available. So, those do not need
to be passed in attributes from Shib. EPPN is the only thing required. A
single Shib entry in conf.php allows users from different institutions to
authenticate. VCL will take the part after the @ in the EPPN to create an
affiliation for that user/institution. For example, here at NCSU, we can
(among others) authenticate users from NCSU and UNCP. A user from NCSU could
have an EPPN like user1@ncsu.edu, which would be converted to user1@NCSU in
VCL. A user from UNCP could have an EPPN like user2@uncp.edu, which would be
converted to user2@UNCP in VCL.
I hope that helps.
Josh
On Friday, August 15, 2014 8:39:23 AM James O'Dell wrote:
> Hi Chris,
>
> A few years back, I set up CSUF's VCL to authenticate and use the
> attributes from InCommon.
> (Thanks again Josh!)
>
> I even added a few attributes like 'eduCourseMember' and 'isMemberOf' (
> based on ldap groups )
>
> I'd be happy to help. Send me a message if you're interested
>
> __Jim
>
> On 8/15/2014 8:19 AM, Christopher Wolfe wrote:
> > All,
> >
> > 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.
> >
> > 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. Second, depending on type of account (staff,
> > student, admin, etc.) different
> >
> > attribute stores/IPs are available, with different attribute names.
> > 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? Regarding the second point, is it sufficient to add an
> > entry to authMechs for each provider? 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? 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)?
> >
> >
> >
> > Thanks,
> >
> > Chris Wolfe
- --
- -------------------------------
Josh Thompson
VCL Developer
North Carolina State University
my GPG/PGP key can be found at pgp.mit.edu
All electronic mail messages in connection with State business which
are sent to or received by this account are subject to the NC Public
Records Law and may be disclosed to third parties.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
iEYEARECAAYFAlPuM8gACgkQV/LQcNdtPQOO0gCfaib7nwcOVPy2zBKGEetJpMVG
aHEAn00dHTq1gcjwm3wqAmHexjj07NeE
=8jR7
-----END PGP SIGNATURE-----
Re: Shibboleth/InCommon authentication/authorization
Posted by James O'Dell <jo...@fullerton.edu>.
Hi Chris,
A few years back, I set up CSUF's VCL to authenticate and use the
attributes from InCommon.
(Thanks again Josh!)
I even added a few attributes like 'eduCourseMember' and 'isMemberOf' (
based on ldap groups )
I'd be happy to help. Send me a message if you're interested
__Jim
On 8/15/2014 8:19 AM, Christopher Wolfe wrote:
> All,
>
> 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.
>
> 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. Second, depending on type of account (staff,
> student, admin, etc.) different
>
> attribute stores/IPs are available, with different attribute names.
> 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? Regarding the second point, is it sufficient to add an
> entry to authMechs for each provider? 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? 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)?
>
>
>
> Thanks,
>
> Chris Wolfe
>
>
>
>
RE: Shibboleth/InCommon authentication/authorization
Posted by Christopher Wolfe <ch...@vt.edu>.
Aaron,
Thanks, that clears things up quite a bit.
Regards,
Chris
-----Original Message-----
From: Aaron Coburn [mailto:acoburn@amherst.edu]
Sent: Friday, August 15, 2014 1:56 PM
To: dev@vcl.apache.org
Cc: <us...@vcl.apache.org>
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. employee@myinstitution.edu), 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
>
>
>
Re: Shibboleth/InCommon authentication/authorization
Posted by Aaron Coburn <ac...@amherst.edu>.
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. employee@myinstitution.edu), 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
>
>
>
Re: Shibboleth/InCommon authentication/authorization
Posted by Aaron Coburn <ac...@amherst.edu>.
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. employee@myinstitution.edu), 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
>
>
>