Subject: COmanage Users List
- From: Benn Oshrin <>
- To: Richard Frovarp <>
- Cc: "" <>
- Subject: Re: [comanage-users] Usage questions
- Date: Fri, 22 Mar 2019 17:08:28 -0700
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.
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.
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.
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").
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.
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
- [comanage-users] Usage questions, Richard Frovarp, 03/22/2019
- Re: [comanage-users] Usage questions, Benn Oshrin, 03/23/2019
Archive powered by MHonArc 2.6.19.