„Drupal Shibboleth module” változatai közötti eltérés

Innen: KIFÜ Wiki
a (Handler settings: prettify)
(Automatic role assignment)
87. sor: 87. sor:
  
 
=== Automatic role assignment ===
 
=== Automatic role assignment ===
 +
It's possible to assign roles to users based on their Shibboleth attributes.
 +
 +
An assignment rule is made of three parameters:
 +
* '''$_SERVER''' header name: name of the Shibboleth-derived attribute
 +
* '''Value regexp''': regexp applied to (all) the value(s) of the Shibboleth-derived attribute
 +
* '''Role(s)''': checklist of roles to be assigned for the matching users
 +
 +
All these rules are evaluated at module initiation time. That would cause that revoking/adding a Shibboleth attribute would end in removing/adding the Drupal role immediately (next page refresh).
 +
 +
Additional roles can be assigned statically to the user (as an individual) by the administrator as normally.
  
 
== Using module ==
 
== Using module ==

A lap 2008. szeptember 3., 15:02-kori változata

Drupal shib_auth module enables Shibboleth authentication for Drupal CMS.

Installation


Compatibility

Module is being developed for Drupal 6.x. We try to backport new features to 5.x from time to time, though it might take several weeks. If you can help backporting, please contact aai _AT_ niif _DOT_ hu!

Older versions of Drupal are not supported, nor is Drupal 7 as long as it is not the stable branch.

Both Shibboleth 1.3 and Shibboleth 2.x are supported.

Upgrading module

There is no upgrade procedure (yet). Please uninstall the module before upgrading. It is reported that sometimes disabling module and removing its directory is not enough.

Configuration

Configuring Shibboleth

You should be familiar with protecting resources with Shibboleth before using this module. (See Shibboleth Wiki) Please check that Shibboleth authentication is working for that location and all the necessary attributes are exported to the headers. You can enable DEBUG mode to dump the whole $_SERVER array. If you can see Shibboleth attributes there, you're fine.

In Shibboleth there are two modes for protecting resources:

  • Lazy Sessions: session is only initiated if an application redirects user to the SessionInitiator URL. In this module, it is done by clicking the "Login with Shibboleth" link. Anonymous access is possible.
Detailed description of lazy sessions in Hungarian.
  • "Strict" Sessions (normal sessions): users can only access Drupal content if they have a valid Shibboleth session. This case, no anonymous access can be granted (not even read-only).


Example Shibboleth configuration

Note: this example uses lazy sessions. Configuration for Shibboleth 1.3 is quite similar.

/etc/shibboleth/shibboleth2.xml snippet:

<RequestMapper type="Native">
  <RequestMap applicationId="default">
    <Host name="your.host.name">
      <Path name="location_of">
        <Path name="your_Drupal">
          <Path name="installation" authType="shibboleth" requireSession="false" />
        </Path>
      </Path>
    </Host>
  </RequestMap>
</RequestMapper>


Apache config file snippet (ie. /etc/apache2/sites-enabled/your.host.name, or you can even use .htaccess without the <Location> tags):

<Location /location_of/your_Drupal/installation>
  AuthType Shibboleth
  ShibRequireSession Off
  require shibboleth
</Location>


Setting Shibboleth parameters for the module

Handler settings

If you are using lazy sessions, you have to define the Shibboleth SessionInitiator to which the user should be directed when she clicks on "Login with Shibboleth". SessionInitiator URL is constituted of the following:

  • protocol scheme (http:// or https://)
  • host name
  • shibboleth handler URL (usually: /Shibboleth.sso)
  • 'location' part of the SessionInitiator definition

/etc/shibboleth/shibboleth2.xml snippet:

<Sessions lifetime="28800" timeout="3600" checkAddress="false"
          handlerURL="/Shibboleth.sso" handlerSSL="false"
          exportLocation="http://localhost/Shibboleth.sso/GetAssertion"
          idpHistory="false" idpHistoryDays="7">
  <SessionInitiator type="Chaining" Location="/Login" isDefault="true" id="Intranet" 
                    relayState="cookie" entityID="https://idp.example.org/shibboleth">
    <SessionInitiator type="SAML2" defaultACSIndex="1" template="bindingTemplate.html"/>
    <SessionInitiator type="Shib1" defaultACSIndex="5"/>
  </SessionInitiator>
  <!-- other things -->
</Sessions>

For this example, you should have:

  • /Shibboleth.sso for Handler URL
  • HTTPS or HTTP for scheme, depending on whether you are using SSL or not
  • /Login for WAYF location

Attribute settings

Specify here the $_SERVER headers to look up the user's username and e-mail address. Please check DEBUG mode to look for the available headers. If you can not find the desired attribute, then something is wrong with your IdP-SP attribute release flow.

It is possible that some users have a specific attribute while others don't. Such is life. Check your Shibboleth settings.

Both fields can have the same value, if you wish.

Automatic role assignment

It's possible to assign roles to users based on their Shibboleth attributes.

An assignment rule is made of three parameters:

  • $_SERVER header name: name of the Shibboleth-derived attribute
  • Value regexp: regexp applied to (all) the value(s) of the Shibboleth-derived attribute
  • Role(s): checklist of roles to be assigned for the matching users

All these rules are evaluated at module initiation time. That would cause that revoking/adding a Shibboleth attribute would end in removing/adding the Drupal role immediately (next page refresh).

Additional roles can be assigned statically to the user (as an individual) by the administrator as normally.

Using module

Automatic user creation

Drupal CMS requires all users to be in its internal SQL database. If the module detects that no user exists in the database with the received Shibboleth user identifier, it creates a new (Drupal) user.

Disallowing password change

There is no way for the module to detect if a user has been deleted from Shibboleth. This simple fact has a number of consequences.

When a user is first logged in, a Drupal account is automatically created for her. Because Drupal requires a password, a random string is generated for password. Normally the user doesn't need it.

Now suppose that your user is about to leave your institution. If she is malicious enough, she can go to the password change form, reset her password to a known one, and even after she is deleted from the IdP, she still can log in to your precious resource with the (now known) password. (Note that it is only achievable with lazy sessions!).

Therefore, if your requirements are such that only Shibboleth-authenticated users can log in, YOU MUST DISABLE PASSWORD CHANGE for users.

Steps for disallowing your users to change their passwords
  1. Install Drupal User Protect module
  2. At Administer -> User management -> User Protect -> Protected roles tab check password for the authenticated user role.
  3. At Administer -> Permissions -> userprotect module: uncheck change own password for authenticated user
  4. Log in with a normal account, go to "My account" -> Edit. You shouldn't see the possibility for changing password; except for the case when the user has user administrator rights.

Administrator / password login

If you are using lazy sessions, you can still login with password. If you disabled the username/password login block, append the following to your normal Drupal URL: /?q=user

Administering Drupal with strict sessions

If you use strict sessions, you can not log in with a password. It's quite tricky to circumvent it:

  1. Enable Shibboleth protection
  2. Login with your own user credentials, so that your Drupal user profile is created
  3. Disable Shibboleth protection
  4. Login as 'admin', grant your own user 'Administrator' rights.
  5. Enable Shibboleth protection
  6. Login with your own credentials, you should have 'Administrator' rights now.

Change log