User Managed

Authentication Setup

NOTE: This section relies on terminology outlined in
KB 22643.
Please refer to it for more details.

CAE Managed

There's no direct filesystem access provided for CAE Managed Wordpress vhosts, so we currently
preconfigure your site for for anyid Shibboleth authentication. Additionally, the
Session Initiator URL, Logout URL, Username settings are automatically forced
to their correct values for you so that you don't need to worry about setting them. Some others are
setup to reasonable defaults (as in the suggestions we outline below), but are up to the site admin to
adjust as they see fit. However, we recommend that you review the tables and documentation below in the
User Managed sections for a description of what the settings are, how they may affect
your site.

User Managed

Unfortunately, the settings for the Wordpress Shibboleth Plugin and those on the filesystem that
instruct Apache how to behave, must be synchronized.

Shibboleth .htaccess Settings

Then, assuming you've installed Wordpress into the root html/ path of your vhost, configure
your /home/vhosts/your.site.fqdn/html/.htaccess file for Shibboleth for that
authentication scheme. A full example is as follows, though yours may or may not have other settings as
your needs dictate.

NOTE: If you don't want to allow public viewing of your site, remove the
ShibRequestSetting isPassive On line and change
ShibRequireSession to On.

Shibboleth Plugin Settings

Next, you need to configure the Shibboleth plugin for Wordpress using the forms at
https://your.site.fqdn/wp-admin/options-general.php?page=shibboleth-options.
The 3 most important settings are the Session Initiator URL, Logout URL, and
Username.
The first two tell Wordpress how to initiate a login request given your site's Shibboleth config, and
must match the URLs provided by your chosen scheme and include the isPassive=On
setting. The last tells Wordpress how to map your Shibboleth identity into a Wordpress user account.

This table tries to outline each of the available settings relating to authentication and what we think
some appropriate settings are.

Wordpress Plugin Options

Required

Template Value

Example

Comments

Session Initiator URL

Y

https://your.site.fqdn/SessionInitator URL?isPassive=On

https://your.site.fqdn/Shibboleth.sso/Login?isPassive=On

?isPassive=On must be set if you set it in your
.htaccess file. See
KB 22643
for other scheme possibilities.

This will depend on the authentication provider, and is usually best just to leave blank.

Password Reset URL

No

This will depend on the authentication provider, and is usually best just to leave blank.

Shibboleth is default login

No

No

No

This will disable local Wordpress account logins and may prevent you from
administering your site in the case that you break Shibboleth authentication.
It is therefore recommended to leave it disabled.

Authorization Configuration

This section applies to both CAE Managed and
User Managed type vhosts.

User Profile Data

When Shibboleth is enabled, accounts that login using it still get Wordpress accounts created for them.
The table below tries to describe how data is synchronized between those two sources. The
Managed option determines whether or not the Shibboleth attribute data will overwrite changes
to the local Wordpress shadow account. Enabling the Managed setting on attributes will help
keep your site in sync with campus data and more secure.

It should be noted that depending upon the authentication source, not all attributes may be available
for mapping use. See KB 22643 for details on
how to discover what attributes are available for use for your site.

User Profile Data Option

Managed

Attribute Example

Comments

Username

yes

eppn

eppn is a scoped username that includes a realm name
describing the authenticated user. It is not an email address even
though it looks like one. It is strongly recommended to leave this as the
Username attribute map. Another possibility is the uid attribute,
which is typically unscoped however this may result in collisions with
your other local Wordpress accounts or other authentication sources in the case
that you have them. NOTE: For CAE Managed vhosts we force this
setting to eppn.

First name

yes

givenName

givenName is about the only option for this, but it's usually FERPA
protected and not available, so user's names may remain blank. Similarly for
sn, and cn.

Last name

yes

sn

See comments on givenName.

Nickname

yes

eppn

There isn't really a good mapping for this based on currently known/provided Shibboleth attributes.

Display Name

yes

cn

See comments on givenName.

Email Address

yes

mail

See comments on givenName.

User Role Mappings

When a user logins via Shibboleth, the web server receives some attributes about the user in
headers or environment variables. You may use these attributes to discover
information about the authenticated user, as seen above, or to perform authorization checks. In the
case of Wordpress's Shibboleth plugin, you can use these them to map authenticated users with a given
attribute value into a particular Wordpress role, thus giving them more or fewer privileges on your
site. The table below tries to outline some examples for using these attributes to control access to
your site. See
http://codex.wordpress.org/Roles_and_Capabilities#Capability_vs._Role_Table
for details on Wordpress Roles.

Role Mappings

Header Name

Header Value Template

Header Value Example

Comments

Administrator

eppn

vhost-owner-login@cae.wisc.edu

bpktest@cae.wisc.edu

This example will map the vhost owner to an Administrator role, which
will, among other things, allow them to make further configuration changes to
the Wordpress Shibboleth Plugin settings.
You may find it more helpful to extend full access like this to all members of
the editing group by using the settings listed in the Editor
example.

Editor

caegroup

vhost-editing-group

bpk-test

This will example will map all members of the CAE group bpk-test
into the Wordpress Editor role. It is probably most beneficial to use
the editing-group for your vhost here.

NOTE: While the examples above illustrate the default values
for CAE Managed vhosts, and appear to us to be reasonable, the remaining
examples are just hypothetical, and not necessarily recommended, but rather just
here to give you some other examples of how Shibboleth attributes might be used.

Author

unscoped-affiliation

STAFF

This would allow Shibboleth authenticated users who carry the STAFFunscoped-affiliation attribute, as determined by the authentication
source, to be mapped into the Author role.

Contributor

unscoped-affiliation

STUDENT

This would allow Shibboleth authenticated users who carry the
STUDENTunscoped-affiliation attribute, as determined
by the authentication source, to be mapped into the Contributor role.

Subscriber

People in this role are allowed to read content. Unless you wish to require
logins for your site even to read content, it's usually advisable to leave this
section blank, and instead use the Default Role setting to map any
Shibboleth authenticated login to a Subscriber role.

Default Role

If none of the preceding rules match a user (and they must match exactly), then Shibboleth authenticated
users will be mapped into the role selected by the Default Role setting. As noted above, it is
usually recommended to map this into Subscriber so that authenticated users can at least view
content, if not edit it.

Update User Role

Finally, the Update User Role setting should be enabled for security reasons. Like the
Managed setting does for User Profile Data settings, this setting will check all
Shibboleth authenticated logins against the User Role Mappings rules each time they login to
ensure that they are given the appropriate level of access according to your attribute rules, whether
that be more or less than the last time. This helps reduce the maintenance you must do on your set of
Wordpress shadow accounts.