COmanage Users List

[Benn Oshrin <>]

On 3/22/19 10:51 AM, Richard Frovarp wrote:
> I'm trying to figure out how to use COManage Registry to replace what we
> have for several different usecases. I'm sure that we can use it to do
> these sorts of things, but I'm rather struggling with trying to figure
> out how exactly to do it, and what it is that Registry can do, and what
> external systems need to do.
>
> Guest accounts:
>
> Right now we have a process by which certain individuals on campus can
> request guest accounts. They can fill out a form to request N accounts
> that are valid for a max of Y days (9 days?). When the process is
> finished, they are presented with the usernames and password. Looks like
> Registry limits it to one account at a time? Also not sure how to set a
> max of a certain number of days. And finally, not sure how to present
> the user doing the enrollment with the generated ePPN (without having to
> do additional clicks) and where an initial password would be generated.
> Are there any solutions with the API for my to build a system to loop
> over the 20 guest accounts being requested?

I don't think there are existing capabilities that match exactly what 
you're looking for, though there are a couple of RFEs floating around in 
various states of proposal and development that could eventually get you 
most of the way there.

In the short term, you could write a plugin that presents the form (or 
exposes an API for the form data), creates the records (directly, not 
using Enrollment Flows), and then presents a results page for the 
Petitioner. The plugin could generate the usernames or trigger 
Identifier Assignment to assign them, and store the initial passwords 
(which it would generate) using Password Authenticator. Since the plugin 
would run within Registry, you could access the internal model calls to 
do this.

Registry doesn't really have the concept of "accounts", so what you'd 
probably be doing is creating a CO Person record and attaching a CO 
Person Role to the CO Person, where the CO Person Role would have a 
valid through date of today+Y. You would then attach a Password to the 
CO Person. In order to actually trigger the expiration, you would define 
an appropriate Expiration Policy (and make sure the expirations JobShell 
is running via cron).

If you didn't want to write a plugin, you could do most of the record 
management over the API, but at the moment Authenticators are not 
available over the REST API. This might change for v3.3.0, but I don't 
think the work has been committed to yet.

> Affiliate accounts:
>
> Basically the same as guests, but they live longer. Same problem of
> showing the person doing the enrollment the ePPN and doing something
> about initial password. We also have the problem not wanting to allow
> unlimited duration expire times. We'd rather have them renew ever 120
> days or something than putting the date out 80 years.

So this would basically be the same solution, but the CO Person Role 
would have a valid through date of today+Z, and probably an affiliation 
of "affiliate" instead of "guest" (or whatever). You'd then have a 
different Expiration Policy that (eg) advised the affiliate that their 
record will expire in N days, and what the process is for renewal.

> Emeritus:
>
> We have a pool of individuals that were are NDSU, but no longer are
> being paid, such as emeritus. We want to provide them and/or
> administrative assistants in the right area the ability to update things
> like phone numbers and office locations since they are no longer in the
> HR data feed. Looks like this is going to be easy, but just looking for
> any suggestions people might have about this. We'll have to eventually
> have a process that automatically provisions the person into a COU when
> they drop off of the HR data feed.

I'd probably do this as one or more COUs, depending on how you want to 
authorize the administrative assistants, who would be COU admins. You 
would then set up Self Service Permissions to allow Emeriti to update 
their own records (or direct them to a website that updated the records 
over the REST API).

For conversion after dropping from the HR feed, you could use an 
Expiration Policy, where the conditions would be something like (cou=hr 
& affiliation=faculty & status=expired) and the actions would be 
(cou=emeritus & status=active). There might be some choreography 
required to properly handle the records if they came from an Org 
Identity Source (ie: the record might have to disappear from the OIS 
before the Expiration Policy runs, to avoid the record "bouncing back").

> Social Login:
>
> We don't have this right now, but want to start researching it. I have
> Registry using Shibboleth SP. We will likely want to be able to support
> social logins at some point. What are people using to do that auth and
> have it feed into COManage?

Others can probably chime in with more details about proxies and 
bridges, but in general the idea is the complexity happens "behind the 
SP" from the perspective of Registry, and all Registry ever sees is the 
ePPN or something.

Thanks,

-Benn-

> I'm guessing that some of what we need might require that we write a
> plugin, I just want to make sure I'm not missing something already in
> the system.
>
> Thanks,
>
> Richard