COmanage Users List

[Niels van Dijk <>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi all,

At SURFnet/AARC we are investigating the possibilities of using
comanage to support various so called "non-web sso" scenarios for
allowing access to hpc and grid resources for CO members.

All scenarios have in common that there is a federated, web based
environment, typically called a 'portal' that binds the federated user
to some additional token which can be used for gaining access to the
non-web sso resource.

* SSH keys
We have already tested the use of ssh keys as part of the AARC
project. The SSH public key keys is entered by the user as part of the
enrollment and gets stored in comanage as part of a users attributes
and next gets provisioned with a plugin to non-web sso targets. (ask
Benn for the demo!).

* 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?

* Yubikeys
For AARC we are experimenting with storing the identifier part of a
yubikey (a second factor device) in the users profile. This is
basically a string, which again needs to get provisioned to the server.
Using a yubikey either replaces the users password, or is used as a
step-up e.g. to give the user sudo capabilities.

* 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?
- - 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..

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?

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 would be interested to learn if these scenarios would also be
interesting to others and if any of you have been testing these already.

Best,
Niels

- -- 
Niels van Dijk        Technical Product Manager Trust & Security
Mob: +31 651347657  |   Skype: cdr-80  |  PGP Key ID: 0xDE7BB2F5
SURFnet BV | PO.Box 19035 | NL-3501 DA Utrecht | The Netherlands
www.surfnet.nl                                www.openconext.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)

iQIcBAEBAgAGBQJX0nZoAAoJECCFeCvee7L1wpoP/RQaSwvtZCCwdyAJycpOTRED
7qjyP5ny/14JQcsDvUEdHjnNB5gb13W41vYHuIED6LDz8h1xRU7ywWUxVQEtsg/1
p5wBvaByJhdwPTY2ngKnp6lGOj/0LSLr3CLIHPyC83Z1Ko2dvVeR5UnUgRM2A5T0
pu6J5NcDbKqeH6DA4sncMRLB1C/fwxBVFfkIl3fQmGqVs6K30PS8rW16fGFyoF5u
NALi4Vwk1Q61FIz/nku9TVGs9P3yKF9Z9jRMgaKMxs0haPhCvpr9FKD+0B1RHHoH
e49EpSQsf6iBkPG9blTmh1Wvzcs6FvVMoo/t562nAztXKQJOh8/myGcdk4xC2EGA
FxvkZCbljEpAhTVhQqsJ0LY9relKRo6NZVyqwb4sd8AWkbSo5/9/YwNiH6Dz5s1d
x1TvyxF2g7CVpwR+nSlif5UXRmTa5OEkKcaWLsaysua/C/rcQDZ69ixqi2NAIJpj
YcQajYrqECSvEIX8qbuQSV+WYnBPv/lYUi3yDfh9TSs18h0ECsVfUtoZYsE/eeQ5
2JBxEnSHnE8c3v1iMcw7lbYvkcn+zAHjrJ+CM0dXXUeJ6xPFrCtuxsWhNeOAU0E3
91VKATRWI8PNFij1Q55Gl/48xJAqQvZq4ief0QR/Hg27H1e4pLyrtwQMw9aHTd6T
1AB97WKkrYHmQCZEbswc
=Q9oV
-----END PGP SIGNATURE-----