Workers: Proposal

1 Ease of certificate Management
The scripts and certificate docmentation done in Y1Q1. The myProxy deployement done in Y1Q2

User certificate issues (1.b)

Create a script interface for requesting and retriving user certificate (1 week Y1Q1)

• script to that would use grid-cert-request, the globus-{host,user}-ssl.conf and curl to generate the key pair and send a certificate request to the DOEGrids CA. The private key would be stored in $HOME/.globus/userkey.pem
• script to retrieve the request using the URL that was mailed to the user and store the result in $HOME/.globus/usercert.pem
• requires working with DOEGrids CA to ensure that it presents a documented interface that can be used for script access.
  

Deploy a myProxy server that stores long term credentials for users. (6 weeks for software development and server deployment at LBNL + 2 weeks/year support Y1Q2)

• Violates the DOEGrids CA policy, so we would need to use a different CA.
• Would need a web interface to create credential and assign a password to it.
• Need a proxy init program that accesses the server to get a local proxy to use for globus job submit requests
• The advantage to this solution is that users would not need to store their credentials locally.

Service certificates (1.c) (1 week Y1Q1)

Script interface for bulk issusance of host certificates.

• Would enable a designated GridAdmin to request host certificates that would be automatically issued
• requires working with DOEGrids CA to ensure that it presents a documented interface that can be used for script access.
  

Certificate renewal (1.d) (2 weeks Y1Q1)

• Create a script interface that uses the userpem.cert and the userkey.pem to make an https connection to the DOEGrids CA interface.
• Needs a suitable interface on the DOEGrids CA that will do the renewal automatically when the requester has the private key.

Clean, consise documentation for Certificates (1.f) (2 Weeks Y1Q1)

Sounds like it is covered in the Certificate tutorial and documentation that GA is proposing to write. We would certainly provide help with the content.

Extension of myProxy server to a VO management server (8 weeks initial design, development and deployment, 4 weeks for later refinements (Y2Q2)

Would be done in year 2 of contract if the use of the myProxy server was popular. A VO managment server defines all the members of the organization, provides a retieval point for all user certificates and possibly host certifcates. It can provide information about the users. Could keep track of resource usage across the whole collaboratory. As the number of members increases and as more resources come on-line, it would provide a central point to add a user and specify what access they should have to what resources.

2 Authorization Issues

Ability of the resource owner to control access to resources (2.a) (4-8 weeks/year depends on number of new codes and sites)

• Continue to work with the resource owners on setting up access policy.

• Implementing the enforcement of daily, monthly quotas and preemptive scheduling needs to be done in co-operation with the scripts that run the codes.

Interface for the resource owner to set policy. (2.b)

Existing Akenti GUIs allow users to create the Akenti certifcates that express policy. We would like to create an interface that presents the access policy to the resource owner in a more resource specific manner, so that his decisions would be more obvious. One interface would be to create and add members to groups. It would show all the groups and what actions they allow. The Akenti attribute certificates would get created behind the scenes. (4 weeks per resource domain. Y1Q3 for TRANSP)

Another interface would display all the resources and offer some simple policies to apply to them, e.g. this group has execute access. This interface has to be customized for each resouce domain, so its design would require input from the resouce owner as to what sort of policies were desired. (6 weeks per resource domain, Y2Q1)

Develop a CheckPolicy interface that displays to the user all the Akenti policy for a resource and checks the validity of the pieces as it collects them. This will find errors introduced by the command-line generation of Akenti certificates and will give the stakeholder an overview of the resource policy. (6 weeks, Y13Q)

Single interface for all users to all Grid Resources (2.c)

There are several issues here:
A public web interface that displays all the available resources and what groups/projects are allowed to use them would be an enticement to all members of the fusion community to join the FusionGrid. This would probably be part of GA's outreach/documentation effort

A web interface displaying all the resources from a SSL-enabled web site that requires client side certificate, could allow a user to click on a resource and have his acccess to that resource evaluated. LBL could help integrate the first web site with a secure site which would use the user's certificate and Akenti to evaluate his access to a resource. For this to span resource sites, the site policy would need to be accessible from outside the sites.(2 weeks, Y2Q3)

Authorization errors (2.d)

Improve the error messages generated by the Akenti authorization process with an eye to making them meaningful to the user. There reamains the problem of passing them back to the user (1 week. Y1Q1)

As an additional help, we could wrap our check access tool that allows a user to check his access to a specific resource. This tool is currently run in a non-secure fashion that allows anyone to check anyone else's access. This is good for helping people debug access problems but potentially gives access information to unauthorized parties. It could be run as a Globus job that will only permit a user to find her own access. (3 weeks to deploy for TRANSP, Y1Q4)

Documentation of how access is set for each resource domain and the probable sorts of errors that can occur: expired policy certificates, expired signing certificates, not member of the right group, etc. (1 week/resource domain)

3. Certificate issuing

Continue to act as the NFC RA and contact to the DOEGrids CA. Represent the needs of the FusionGrid to the CA, and keep Fusion Grid members aware of changes to the CA.(4 weeks/year)

4. Year 3 tasks

team contact info | about the fusion grid | fusiongrid research Last modified 12/12/03. Comments? webmaster