COmanage Users List

[Benn Oshrin <>]

On 9/9/16 4:44 AM, Niels van Dijk wrote:

> * Certificates:
> Storing certificates as part of the users attributes seems similar to
> the ssh scenario, so should probably work. A user could manually
> upload a certificate, or we could create a setup where the certificate
> is getting auto-genereated at some other place during enrollment of
> the user. Is the latter perhaps something CIlogon2 is looking into?

There are various discussions underway for integration between COmanage 
and CILogon2, though we don't have any immediate plans that would 
address your scenario.

> * Application specific passwords:
> In this scenario a user stores an application specific password as
> part of his/her attribute set. This passwrd gets provisioned to a
> server to allow a user in. Technically, storing a string as part of
> the users attributes in comanage is trivial ofcause. But we have some
> questions and thoughts:
> - - We would like to have strong passwords, so preferably we would like
> to auto-generate these for a user. Is there some way to put an auto
> generated value on a field in an enrollment flow?

Not exactly in the way you're describing, though you could create an 
Identifier Assignment consisting of a long random collision number.

> - - Can we encrypt these passwords in the comanage db in a sensible way?
> Any suggestions on what key could we use for (de)crypting? Perhaps we
> should have the user provide some pin or the likes? Clearly using
> anything already stored in the db as part of the users attributes
> would not be a good idea..

If you wanted per-user encryption keys, you'd basically need a separate 
service to manage them if you didn't want to store them in the database. 
HA considerations would also preclude (eg) storing them on the local 
file system.

While a standalone service would be better in the event of a database 
compromise, Registry would still need a trusted way to decrypt the keys 
when provisioning them to the target application.

We are considering credential management as an area for development for 
v1.2.0, so it might be interesting to try to factor the above 
requirements into the planning.

> For provisioning data to the 'right' server, we would need the ability
> to tie a specific token to a specific service/server. However, the
> concept of an application or service does not exist yet in comanage. I
> am sure hard-coding this into a provisioning plugin would work, but
> perhaps there is a more generic way?

Not at the moment. There will be a capability in v1.1.0 to restrict 
provisioning based on a person's group memberships, but that would only 
take you part of the way there.

> Furthermore: Are there some examples of how I could setup a
> provisioning plugin that would start a shell based provisioning
> script? I am considering a scenario where a bunch of
> ansible(/chef/puppet/yourfavoritehere) scripts would be fired off to
> provision a VM with some of the credential info stored in comanage.
> Using something like ansible seems like a better suited way then
> programming this in php. From the comanage perspective this would
> entail writing some attributes into credentials in a yaml file and
> firing of the ansible playbook.

I'm not aware of any, but as plugins are just PHP scripts you should be 
able to use exec/system/passthru/etc as normal. Keep in mind that the 
script will execute with the permissions of your web user, and in an HA 
scenario you won't know in advance which server the script is running from.

More elegantly, you could also try something like

 https://packagist.org/packages/asm/php-ansible

Thanks,

-Benn-