COmanage enrollment using auth_mod_mellon

COmanage enrollment using auth_mod_mellon

2017-11-30 Technology 0

Welcome in the world of SAML federation and Single Sign On. COmanage is a work-in-progress revolving around the use-case of managing groups of people (entities?) in a virtual organisation. While this use case has been solved a million times in the technological domain, it is somewhat more complex if you have to work with less tech-savvy people from all over the world that just want things to work. They want to log in to their favorite service provider and not wonder too much about the technical and privacy-related details of passing along names, mail addresses and such. So, COmanage does that in a nice, ‘industry standard’ way. As I said, work-in-progress, so there is not necessarily a solution for every real-life use case, but it works.

Then enter SAML authentication. There are apparently two main standards for solving this on an Apache server: JAVA based Shibboleth and using a module called auth_mod_mellon.The latter was chosen for the project I am currently working on, but as with any community supported code, it does not exactly work as expected once you delve into the details.

The problem we ran into today is COmanage Enrollment Flows. Whereas technical users appoint ‘moderators’ and have them pick through a huge list of subscription requests, this SAML world requires well defined and auditable work flows with authentication and authorisation at various configurable moments. Two basic flows are: ‘invitation’ and ‘self-enrollment’. In the first case, you enter somebodies information and have the system send an e-mail. In the latter case, somebody visits a link and enters their own information. Of course, you don’t want people to just enter anything, so using SAML authentication, we would like some information to be entered for the new petitioner and not allow changes.

By default, auth_mod_mellon will expose all SAML attributes with a MELLON_ prefix. This is not documented as far as I can read (and if it is, not clearly), but it means you do not need to use the MellonSetEnv configuration. You can use these to rename the environment variables. Please note that the Apache configuration will have two Location blocks for auth_mod_mellon: one that enforces authentication and one that only sets the environment variables. It is in the latter block that you need to put the MellonSetEnv statements, because all relevant COmanage related code is executed in that Location. Only authentication, login and logout are executed in the first path (obviously).

In theory, this works okay. Here come the issues:

  • The COmanage version we work with (3.0) only supports importing SAML attributes using environment variables. This has the added down-side that this only works for the self-enrollment flow, so the invitation flow is not usable
  • This configuration can only be set for the entire platform, so no CO defined on the COmanage registry can ever use the invitation work flow once you decide to use the SAML environment attributes
  • If you receive SAML attributes from multiple IdP sources, you might get a mix of all kinds of SAML standards, all of which are prefixed with MELLON_ and you can only rewrite so much…
  • During the COmanage Petition flow, the user is redirected using mod_rewrite from authentication to actual form 2 or 3 times. Every time, Apache includes all previous environment variables and adds a ‘REDIRECT_’ prefix to them, so you end up with variables called: ‘REDIRECT_REDIRECT_MELLON_urn:oid:1_3_6_1_4_1_5923_1_1_1_6_1’. Luckily, you can forget about those.

Anyway, you end up specifying for example ‘MELLON_urn:oid:0.9.2342.19200300.100.1.3’ as the mail address of new users for the self-enrollment petition flow. And funny enough, this seems to work fine.

I cannot wait for the COmanage 3.1 release, where they will rework this whole problem and introduce all kinds of overly complicated pipeline and workflow management configurations that allow you to adjust COmanage to exactly mimic your specific use case.I simply have to accept that it is always easier to adjust the code than to adjust people.

 

Geef een antwoord

Het e-mailadres wordt niet gepubliceerd.