COmanage Users List

["Basney, Jim" <>]

On 9/9/16, 6:33 AM, Benn Oshrin wrote:
>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.

I expect we're going to want to store the user's certificate subject
distinguished name so it can be pulled down via LDAP for GridFTP
authorization (for example). In the typical CILogon case using short-lived
certificates for authentication, storing the certificate itself isn't too
useful. I could imagine wanting to store long-lived certificates for
S/MIME encryption, to look up the intended recipient's certificate, but
that's not a use case I have in mind for CILogon.

>> * Application specific passwords:
>>[...]
>> - - 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.

What I have in mind for application-specific passwords in CILogon 2.0 is
storing LDAP-style password verifiers (hashes). I wouldn't want to store
encrypted passwords. If a user loses an application-specific password,
they should generate a new one. Of course this will restrict us to
supporting only those applications that can use LDAP-style password
verifiers.

Regards,
Jim