Java CoG Kit Keystore Manager

From Java CoG Kit

Jump to: navigation, search

This project is looking for volunteers

Contents

Problem Statement

In a system we developed in 1994 we used to store clear text passwords in a database to authenticate to a number of machines a user has access to. With hightened security concerns this application is no longer feasable. We like to develop from scratch a new mechanism that is based on public key technology that can manage a number of keys used to authenticate to a number of remote computers with SSH.

Usage Scenario

You are a user which has access to a number of remote computers. You maintain a list of these computers and like to use ssh keys to access thes computers. A number of these computers may have the same public key installed but some other may not.

We like to use a Java keystore to enable single sign on on these machines.

We like to demonstrate a Karajan workflow that submits jobs (a simple /bin/date will do for now) on the machines. The program should be able to run multiple times without that you have to reupload the paswords everytime. Once the keystore manager is shut down, the application can no longer authenticate.

Requirements

This must be secure

Links and Pointers

Initial Technical Aspects

One way of aproaching this problem is as follows:

Assumtions

  • Assume you have multiple machines on he net with possibly different public and private keys for the machines.
  • Assume we place these keys in .ssh and name the public and private keys in a fashin that is easy to remember. E.g. id_rsa_<hostname> and id_rsa_<hostname>.pub

Then name is created based on the cypher and the hostname of the machine.

What we need is a small program that can

a) generate such keys b) manage such keys c) reuse the keys as part of karajan

Demonstration

  • Develop a commandline and GUI program that allows the management of the keys
  • Design the GUI
  • demonstrate and develop an example that shows the use of this with three different computers.
    • One example has the same public key stored on each of the hosts (allowing single sign on)
    • One example has different public keys for each machine (allowing single sign on once all the keys are in the keystore)
  • Develop a commandline interface to the functionality that does not require a GUI. Provide a man page as ASCII document.

Issues

Take a look at the ssh provider and see if it is necessary to modify it to deal with different keys.

The GUI will have different panels that should be assiting the user in its tasks. The panels must be reusable individually in other components, but a Frame will exists that demonstrates how they all fit together

Here a suggestion for the look and feel

CoG Kit Keystore Manager

Tree of the          | The panel as called when selected in the tree 
available panels     |

the tree could be something like

  • manage
    • create host key  % creates a key pair
    • add/import % adds an existing key to the keystore (if the key is not already there
    • delete  % deletes a key from teh keystore
    • export  % exports the keys to files
    • destroy  % destroys a key or keypair from the filesystem
  • register hosts
    • rename alias
    • add a host to a key % this assumes that you place the pub key on the remote host and associate the hostname to a key. E.g. the key is now used for a group of hosts.
  • info
    • list  % lists the keys
    • select  % seelct a specific key for display
    • serach  % serach for a specific key
    • verify  % verifies if we can authenticate to the hosts, displays them in a group fashion.

TASK: design a simple gui for each of the panels as suggested above

once this is done, you can now use the keystore to upload one/some key according to your machines.

Now one should create a karajan workflow where one task is to submit /bin/date to different machines that have different keys.

To make this even more interesting develop a task that loads in all the keys first with the help of potentially the karajan forms library or through the invokation of your keystore. This is done while simply passing a list of all the machine names that you like to authenticate agains. One thing to remember is that a hostname could also represent a group of hosts, hence wee need in the management tool some kind of mechanism to register multiple host names with the same key.

Essentially what we do is create always a group for a key to which we add the hostnames in some datastructure (preferably we reuse the graph datastructure from the cog kit or use a hashtable based on the alias).

I realize this is pretty preliminary in its design and function, but I it would be great if someone picks this up as a project and helps with the completion.


Appendix

Panel: Add Host to Key

Adds a host to a list of hosts that use the same key represented by the Alias. An additional browser panel allows the easy display of the available aliasses. They are displayed in a tree and list under the key the names of the machines. The [+] [-] indicate if the authentication has been in the past sucessfully performed with that machine. A [?] indicates that this has not been tested before. The test feature can be enabled or disabled. The position of the list can be specified (left, right, top, botom. Selecting the key alias in the browser will modify it in the editing panel.

Key Alias:  ____________________ [Browse]
Hostname:   ____________________ 

            [Add] [Remove] [Cancel]
------------------------------------------
List of hosts assigned to the Alias:
+ <key alias> 
  + [+] host1.mcs.anl.gov 
  + [-] host2.ncsa.edu    
  + [?] host3.uchicago.edu 
  ...
+ <other key alias>
...

Panel: Rename an Alias

Adds a host to a list of hosts that use the same key represented by the Alias. An additional browser panel allows the easy display of the available aliasses. (compare #Panel Add Host to Key)

Old Alias:  ____________________ [Browse]
New Alias:  ____________________ [Browse]

            [Rename] [Cancel]
------------------------------------------
List of hosts assigned to the Alias:
+ <key alias> 
  + [+] host1.mcs.anl.gov 
  + [-] host2.ncsa.edu    
  + [?] host3.uchicago.edu 
  ...
+ <other key alias>
...

If the new alias aready exists print an error


The test to authenticate to the host with the old alias has succeded.
The test to authenticate to this host with the new alias has failed.

You have failed to move the key on the remote o=host. 

Are you sure you like to proceed? We do not recommend that yo od so before you have not made that change.
Proceed? [Yes] [No]

Panel: Move a host to a different Alias/key

Assume you have changed the key of a host to a different key, than you can use the Move panelAn additional browser panel allows the easy display of the available aliasses. (compare #Panel Add Host to Key)

Hostname:   ____________________ [Browse]
Old Alias:  ____________________ [Browse] (
                                 (or automatically determined from hostname)
New Alias:  ____________________ [Browse]

            [Rename] [Cancel]
------------------------------------------
List of hosts assigned to the Alias:
+ <key alias> 
  + [+] host1.mcs.anl.gov 
  + [-] host2.ncsa.edu    
  + [?] host3.uchicago.edu 
  ...
+ <other key alias>
...

After the move a test is performed and if the test fails a question is asked as follows

Panel: Create Keystore

Filename: ____________________
Password: ____________________

Panel: Import

Key:      _____________________
Password: _____________________

Create Key

Type: [ ] RSA [ ] DSA (depending on the type the panel is changing)
RSA
Size:    20048 [v] ( a selector box with different sizes
Version: __ the version number (set by default to 3?)
Signing Algorithm: [ ] MD5 with RSA ...
Validity in hours or days: ______ [ ] hours [x] days

DN Panel

(should the dn have the hostname included, this could help searching for it)

Personal tools
Collaboration and Jobs