Bugzilla – Bug 227
Auth information made available in runtime environment
Last modified: 2009-04-19 08:37:14
You need to
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
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.