COmanage Users List

[Benn Oshrin <>]

The "old" (current) mechanism does not work with invitation based flows.
(It was originally intended for self signup flows, where the attributes
available are those of the authenticated enrollee.) That's one of many
limitations of the old mechanism, which is why we're replacing it... The
old mechanism also does not allow users to override values (at least not
easily), and it conflates CO Person and Org Identity attributes.

The "new" mechanism, EnvSource, will address all of these issues. The
version in the develop branch (which will become 3.1.0) currently only
supports Self Signup and Account Linking, but it should support
Invitation in the next week or so, and certainly by the time 3.1.0 is
released.

In summary, there is no good support for authoritative attributes in
invitation based flows for 3.0.0 and earlier. Your could write your own
plugin, but you won't be able to set default values in the enrollment
form without hacking the core code (or waiting for 3.1.0). Alternately,
you could switch to a self signup based flow until 3.1.0 is available.

BTW, required/optional/not permitted simply refer to the self asserted
attributes collected in the petition during enrollment. Required means
the petitioner must provide the value, optional means the petitioner may
provide the value, and not permitted means the field is not rendered in
the form.

Thanks,

-Benn-

On 11/22/17 5:32 AM, Michiel Uitdehaag wrote:
> 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
>