1 260
szerkesztés
Módosítások
Profile module
Drupal '''shib_auth''' module enables [http://shibboleth.internet2.edu Shibboleth] authentication for [http://drupal.org Drupal CMS].
== Installation and bootstrapping ==
{{STOP|The following documentation assumes that
* You [https://spaceswiki.internet2shibboleth.edunet/confluence/display/SHIB2/FlowsAndConfig understand how Shibboleth works]* You have [https://spaceswiki.internet2shibboleth.edunet/confluence/display/SHIB2/Installation successfully installed and configured Shibboleth SP] on your host running Drupal.
}}
=== Installing the module ===
# Enable module at '''<code>Administer -> Site building -> Modules</code>'''
==== Compatibility ====
The module is supported for Drupal 6assumes that you use Shibboleth SP 2.x. No new features and patches (excepting security fixes) are backported It's possible to 5.x. There is an '''initial development version for Drupal 7.x''', however at use the moment this documentation is not yet adjusted to Drupal 7. Both module with Shibboleth SP 1.3 and Shibboleth 2.x are , but that version is not supported, although some features will require Shibboleth 2.xanymore.
=== Upgrading the module ===
The upgrade script makes slight changes to the database. You only need to run this script once, however running it several times does no harm to your installation apart from showing some SQL errors.
{{NOTE_EN|although the upgrade script was designed to be robust, please '''back up your database''' before upgrading.}}
==== Moving from Drupal 6 to Drupal 7 ====
To migrate your working installation to D7, first you must update your module to the latest 4.x version. After that, you can perform the Drupal update.
=== Get it running ===
==== Configuring Shibboleth ====
You should be familiar with protecting resources with Shibboleth before using this module. (See [https://spaceswiki.internet2shibboleth.edunet/confluence/display/SHIB2/NativeSPProtectContent Shibboleth Wiki] for comprehensive information) Please check that Shibboleth authentication is working for the location of your Drupal installation and all the necessary attributes are exported to the headers. You can enable [[Drupal Shibboleth module#DEBUG mode | 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:
}}
===== Example Shibboleth configuration =====
{{NOTE_EN|this example uses lazy sessions. Configuration for Shibboleth 1.3 is quite similar.}}
'''/etc/shibboleth/shibboleth2.xml snippet''':
AuthType Shibboleth
ShibRequireSession Off
ShibUseHeaders On
require shibboleth
</Location>
</source>
==== DEBUG mode ====
If you enable DEBUG mode on the module configuration interface, you can dump the whole '''$_SERVER''' array, '''$_SESSION''' arrays and additionally the '''$user''' object, if the user is logged in. This mode shows you all the available attributes and helps you diagnosing possible Shibboleth attribute problems.
:: <small>Keep in mind that some users might have a specific attribute while others don't.</small>
# Enable Shibboleth protection
# Login with your own credentials, you should have 'Administrator' rights now.
==== Pre-creating users ====
Versions before 4.0 allowed pre-creating users without any tweaks; if the username matched, the user was logged in.
Since 4.0 the module only logs in users who exist in <code>{shib_authmap}</code> and the update script only takes care of users tagged with 'shib_auth' in <code>{authmap}</code>. When there is no mapping in the <code>{shib_authmap}</code>, a new user is attempted to be created, which fails because of the mail being duplicated. So what was accidentally working with pre-created users, do not work anymore with 4.0.
To pre-create users, you should first create the Drupal users in your preferred way (either by using the administration interface or by direct SQL query), and then you '''MUST''' manually run the following '''three queries''':
<source lang="SQL">
INSERT INTO shib_authmap (uid, targeted_id)
SELECT uid, name
FROM users
WHERE uid > 1 AND (uid) NOT IN
(SELECT uid
FROM shib_authmap);
INSERT INTO authmap (uid, authname)
SELECT uid, targeted_id
FROM shib_authmap
WHERE (uid) NOT IN
(SELECT uid
FROM authmap);
UPDATE authmap SET module = 'shib_auth'
WHERE (uid) IN
(SELECT uid
FROM shib_authmap);
</source>
{{NOTE_EN|These queries add all your existing users to <code>shib_authmap</code> with their usernames and make sure that your <code>authmap</code> table contains all of the user entries. You should optimize these queries if you have a large number of users.}}
{{ATTENTION_EN|You should repeat these queries each time after you add pre-created users.}}
=== Role assignment ===
* the roles will be in effect regardless of the login procedure.
=== User profile mapping ===
From the 7.x-4.2 version (D6 is not supported) it is possible to define a mapping between Shibboleth attributes and Drupal Fields. You must have the ''Field UI'' and the ''Shibboleth profile fields'' modules enabled to use this functionality. Unlike other features of the module, this mapping is configured together with the field definition.
Go to ''Administration » Configuration » People » Account settings » Manage fields'' (<code>admin/config/people/accounts/fields</code>) and create a new field or edit an existing one. The Shibboleth mapping is available on the Field Edit form and can be used in three ways:
* ''Disabled'': no mapping (this is the default);
* ''Initial value from Shibboleth, later editable by User'': the value of the mapping is only assigned to the field if the field has no values;
* ''Always update value on User login, not editable by User'': the field is updated on every login.
You can use the values of the server variables by referring to them with square brackets like <code>[sn]</code>. You can reference multiple server variables in one mapping. Anything that is not matched to a server variable will be treated as string and copied to the value of the field. The server variable match is case insensitive.
As an example, consider the user's request containing the following server variables (regardless of being set by Shibboleth or by something else):
[givenName] -> John
[sn] -> Doe
[email] -> jdoe@example.com
The following mappings would produce the results as indicated:
{|
|<code>[sn], [givenName] <[email]></code> || '''''Doe, John <jdoe@example.com>''''' ||
|-
|<code>[firstName] [sn]</code> || '''''[firstname] Doe''''' (note the mistaken header name)
|}
=== Account linking ===
There might be cases when you have a number of existing users and you want them to (optionally) log in through the federation. If you enable '''account linking''', a user can add her SSO login to her existing Drupal account. The process of adding an SSO login -> Drupal account association is the following (all steps are performed by the user):
By using this option, you can auto-login users who are already logged in to the IdP even if you are using lazy sessions. If auto-login can not be performed, the user returns to Drupal unauthenticated without seeing any error message.
{{ATTENTION_EN|You need to instruct Shibboleth to redirect errors back to Drupal to handle passive authentication failures. This is done by setting <code>redirectErrors</code> parameter in the RequestMap. See [https://spaceswiki.internet2shibboleth.edunet/confluence/display/SHIB2/NativeSPContentSettings Shibboleth wiki] for details.
'''IMPORTANT''': current implementation does not handle any errors except for NoPassive error. This means, that on every possible Shibboleth SP error you will get an unauthenticated Drupal page instead of a Shibboleth error page.}}
* Support for redirecting users to HTTPS on login
[[Category: AAI]] [[Category: Drupal]] [[Category: Shibboleth SP]] [[Category: HOWTO]] [[Category: English]]
