Bugzilla – Bug 227
Auth information made available in runtime environment
Last modified: 2009-04-19 08:37:14
You need to log in before you can comment on or make changes to this bug.
On the PPDG SiteAAA and the DOESG mailing lists, we've identified the need for authentication and authorization info in the GRAM execution environment. Specifically, there should be a fairly standard, easy and reasonably secure way of identifying the original certificate that a job was authenticated with. Further, it should be possible to identify and examine any authorization information that came in - for example, if a CAS auth attribute was attached to the cert, it should be made available as well within the GRAM API (for people writing job manager or job manager extensions) as well as in the execution environment (for the batch scripts/programs to examine).
As I interpret this is there is a desire in the future to have some authentication and attribute information available to the job environment so that customization can be done for the user. For example, if the user uses CAS credentials to gain authorization, the DN of the CAS server should be made available so that the job environment could say "ah, this person is a CMS user" and do some CMS-specific environment setup. I'm not sure what this requirement boils down to into todays GT2 world. Steve - are there any use cases today for GT2.0 or is this for future stuff?
In the next few months, no particular use cases come to mind. However, when CAS starts to show up as a functioning service, we will need these things. If CAS is released without authorization support in GRAM, it will not be particularly useful.
With the introduction of the web services container, this functionality is fulfilled there. I'm betting similar functionality will not be implemented in the pre-WS version of GT, so this is either FIXED or WONTFIX depending on your point of view.
Marking long-resolved bugs as CLOSED.