How straightforward to support this usage mode?

[Jon Eliot Strømme]

Drupalsimplesaml as a drupal module is great news, thanks for the good work.

I have been using a split-off, privately modified version for years, and it would be very good to move to the main version when upgrading to Drupal7. The reasons for splitting off were the ones given below. What I wonder is, with this usage mode, how hard will it be to use the new module?

Caveat: I have not read the new code. I am, in other words, bothering the list before getting all the info. It is not all laziness, rather a hope that my own possible misinterpretation of the code will not make me conclude that the official code is insufficient if it is, in fact, good for my usage.

Please, please, do not turn this into a discussion of usage modes. It is an interesting and relevant question, but a very different debate. As far as my project is concerned, that debate has terminated, and we are committed to this way of doing things, with a lot of structure and code relying on it. I fully respect that other contexts give other results.

To the usage mode:

• We use real names with uid suffix as Drupal names. My name, for instance, is "Jon Strømme _29". Names are extracted from Feide, exclusively, the users have no control. It is important that they do not. Feide being what it is, some code is necessary to decide whether to use the full name or combine first and last names. A hook that takes Feide attributes as input and returns the desired user name string would seem a good solution, or something to the same effect.
• We use email addresses to identify people. Ideally, we would rather use Feide id, perhaps. Some institutions are not really avoiding reuse of Feide ids, but they take care with email addresses. At any rate, a hook that takes Feide attributes and returns the existing user id, if any, would be one possible solution. Here we are getting into algorithmic variants. What we need to do, is to not create a new user if the user with that Feide id exists (but the id and his Drupal name are totally unrelated). However, we want to update his Drupal name to the name he has at login. He may have married and taken his wife's name. This may be at odds with the standard behaviour, it certainly was earlier.
• We extract a number of other attributes from the Feide attributes and use them in several contexts, not just in user objects. Some of these attributes have no natural place in user objects, so I introduced module_invoke_all hooks at some spots (before and after user creation or modification). This could be handled in a number of ways, including adding things to the user object and extracting it for other use later, given that there is a usable hook somewhere. The details do not matter, so long as we get hold of the data at login.

That is it. Should I be looking at using the official Drupal 7 module?

Best regards,
Jon

[Steve Moitozo II]

To the usage mode:

• We use real names with uid suffix as Drupal names. My name, for instance, is "Jon Strømme _29". Names are extracted from Feide, exclusively, the users have no control. It is important that they do not. Feide being what it is, some code is necessary to decide whether to use the full name or combine first and last names. A hook that takes Feide attributes as input and returns the desired user name string would seem a good solution, or something to the same effect.

This is easily accomplished by defining an Auth Proc in your simpleSAMLphp SP so the Drupal module has what it needs to meet your requirements. I did this on one site by defining a core:PHP Auth Proc for my SP that concatenated displayName and principleName to create a string (e.g., "Steve Moitozo - 1...@idp.example.org") that I use for Drupal username . Drupal requires the username to be unique and this site is hooked into a number of different IDPs. So, we needed a construct that could guarantee uniqueness. Then all I did was specify the name of this new attribute as the one for the Drupal module to use for the user's name. There's no need to duplicate functionality in our module that already exists in simpleSAMLphp, since our module depends upon it.

• We use email addresses to identify people. Ideally, we would rather use Feide id, perhaps. Some institutions are not really avoiding reuse of Feide ids, but they take care with email addresses. At any rate, a hook that takes Feide attributes and returns the existing user id, if any, would be one possible solution. Here we are getting into algorithmic variants. What we need to do, is to not create a new user if the user with that Feide id exists (but the id and his Drupal name are totally unrelated). However, we want to update his Drupal name to the name he has at login. He may have married and taken his wife's name. This may be at odds with the standard behaviour, it certainly was earlier.

The module uses whatever identity attribute you specify, usually this is a principle name or targeted ID. If our module doesn't do what you want in this area it could be patched to update the user's name in Drupal, similar to the way we handle role evaluation.

• We extract a number of other attributes from the Feide attributes and use them in several contexts, not just in user objects. Some of these attributes have no natural place in user objects, so I introduced module_invoke_all hooks at some spots (before and after user creation or modification). This could be handled in a number of ways, including adding things to the user object and extracting it for other use later, given that there is a usable hook somewhere. The details do not matter, so long as we get hold of the data at login.

The simplesamlphp_auth module doesn't support this but it sounds like you could use our module and create a trimmed down custom module to deal with just your special attribute handling. Let simplesamlphp_auth connect your Drupal to simpleSAMLphp and your new trimmed down module could pickup where our module leaves off. The other option, if you think your additional functionality might be useful to others, is to send over a patch that adds this functionality to our module.

That is it. Should I be looking at using the official Drupal 7 module?

Overall, it sounds like our module covers 90% of your use case. I think you should consider it.

[Jon Eliot Strømme]

Thanks a lot. The d7 module it is, then, if and when resources for actually doing something materialize, or the addiction to software abuses my spare time (again...).

--
You received this message because you are subscribed to the Google Groups "Drupal SimpleSAMLphp integration" group.
To post to this group, send email to drupalsi...@googlegroups.com.
To unsubscribe from this group, send email to drupalsimplesa...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/drupalsimplesaml?hl=en.