Módosítások

The module is supported for Drupal 6assumes that you use Shibboleth SP 2.x. No new features and patches (excluding security fixes) are backported It's possible to 5.x. Drupal 7 support will be added after it becomes an official stable version. If you want to contribute to development or porting, please contact '''aai _AT_ niif _DOT_ hu'''! Both use the 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.

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.

{{NOTE_EN|this example uses lazy sessions. Configuration for Shibboleth 1.3 is quite similar.}}

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.

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.}} = Dynamic role == Role assignment ===

Revoking==== Dynamic rules (default) ====Dynamic rules add roles to the user, but '''do not save them to the user's profile'''. This means that* the roles assigned by dynamic rules are '''NOT displayed on the user page''', even though the permissions assigned to the role are in effect* the roles assigned by dynamic rules are '''automatically revoked''' if the Shibboleth attributes change (ie. <code>eduPersonAffiliation</code> changes from <code>student</adding a code> to <code>alum</code>),* thus if the user logs in by other means than Shibboleth attribute , the rule will take effect immediately on next page refresh. The same applies when not be triggered, so the set of headers is happened to roles will not be changedassigned.

{{NOTE_EN|although dynamic Additional roles are can be assigned statically to the user (as an individual) by the administrator as normally. Every logged in user gets the role <code>Authenticated user</code> automatically.==== Sticky rules ====On the other hand, sticky rules do '''save the roles to the user'NOTs profile''' . Thus* the roles assigned by sticky rules are displayed on the user page, * the permissions assigned to roles are not revoked automatically by the module,* the role are roles will be in effect for regardless of the userlogin procedure. <br><small>This is a feature, not a bug</small>}}

Additional roles === 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 statically to the user (as an individual) field if the field has no values;* ''Always update value on User login, not editable by User'': the administrator as normallyfield is updated on every login. Every logged in user gets  You can use the values of the role server variables by referring to them with square brackets like <code>Authenticated user[sn]</code> automatically.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

* if the Shibboleth session is lost, all the Shibboleth-derived attributes disappear, therefore the user loses the [[#Dynamic role assignment|assigned Shibboleth dynamic roles]]** on the other handare lost, the roles assigned to the ''Drupal account of the user'' persist as long as the Drupal session is validtoo* Shibboleth session might get lost if you use a clustered SP without a central session cache* '''Never ever leave this option off if you want support Single Logout'''. Otherwise the user will remain logged in to Drupal even after doing single (global) logout.}}

{{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.

* Support for sticky rules (roles saved permanently to the users' profile)* Basic support for account linking* Basic support for getting user consent on personal data* Support for isPassive and forceAuthn session initiation* Support for redirecting users to HTTPS on login

[[Category: AAI]] [[Category: Drupal]] [[Category: Shibboleth SP]] [[Category: HOWTO]] [[Category: English]]