COmanage Users List

[Michiel Uitdehaag <>]

Hi,

I am currently investigating how I can use the authorative SAML
attributes that auth_mod_mellon passes through configurable environment
variables to the PHP application.
The intended goal is to have these environment variables override any
information in the associated COOrgIdentity records whenever the
application finds a difference. A second best would be to populate the
new OrgIdentity record with these values after completing an enrollment
flow. In either case, the user should not be able to override these
values. However, I fail to find the correct combinations of
configurations to achieve this behaviour.

I am using the 3.0.0-rc2 release. I understand that new behaviour is
introduced in the 3.1.0 release to accomodate a more flexible way of
incorporating these values, but that the 'old' way would remain
functional until the 4.0.0 release.

What I am currently doing is configuring CMP Enrollment Configuration
and defining a set of variables as passed by mod_auth_mellon to the
application. This contains the option:
'Enable Organizational Attributes Via CO Enrollment Flow'

The help text for this option seems to indicate I should enable it,
although the text is confusingly talking about features not being supported.

If I enable this and try to send out an Invitation petition, the
relevant fields are already filled (and not editable) when I create the
petition. But that means these values are derived from the current
(administrator) user and not from the invited person. In fact, I cannot
even change the e-mail address, which prevents me from sending out the
invitation to the new user. This seems a silly feature and I am unsure
of its use case.

If I disable this option, I can set 'Optional', 'Required' or 'Not
Permitted' flags for each of the variables. I am not sure what these do
exactly, but I assume it will enforce something in the enrollment flow.
Unfortunately, I get a database error on a missing co_person_id field
while creating the Invitation petition. No e-mail is sent, but the
petition is created. I did not yet check what specific SQL statement is
failing here, because I am not sure this is the correct way to go either.

Does someone have a suggestion where I should look in this respect? Do I
perhaps need to create a new Organizational Identity Source plugin to
accomodate this?

Thanks in advance,

Michiel Uitdehaag