1 260
szerkesztés
Módosítások
Profile module
# Enable module at '''<code>Administer -> Site building -> Modules</code>'''
==== Compatibility ====
The module assumes that you use Shibboleth SP 2.x. It's possible to use the module with Shibboleth SP 1.3, but that version is not supported anymore.
{{ATTENTION_EN|If you upgrade from 3.x (or previous versions) to 4.x, '''you must update the database'''. After overwriting the files in the <code>modules/</code> directory, open up <code>YOUR_DRUPAL_INSTALLATION/update.php</code> in your browser and run update for the <code>shib_auth</code> module. '''This is required to let your user info persist.'''
}}
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 ====
}}
===== 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 ====
# 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):
* Support for redirecting users to HTTPS on login
[[Category: AAI]] [[Category: Drupal]] [[Category: Shibboleth SP]] [[Category: HOWTO]] [[Category: English]]
