airavata-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Amila Jayasekara <>
Subject Re: Handling security context in airavata
Date Tue, 12 Feb 2013 18:37:33 GMT
Hi Suresh,

Please see some inline comments.

On Tue, Feb 12, 2013 at 10:28 AM, Suresh Marru <> wrote:
> Hi Amila,
> Thank you for bringing the discussion back to the mailing list. I have few questions
embedded below:
>> 1. In the new GFac handler architecture we can set a security context.
>> This security context is used through out handler executions. We need
>> to populate security credentials retrieved from ACS (Airavata
>> Credential Store) to the security context. But we need to make sure
>> the populated security context will work for all providers (E.g :-
>> XSEDE, EC 2, Local Cluster etc ...).
>> So we thought of storing credentials in a generic object within the
>> security context and allow provider implementation to convert
>> credentials to correct object type (Keys, Tokens etc …).
> Will this generic object be limited to X509 Certificates [1] ? I wonder if there is any
current security mechanism which is not covered by this standard.

Not really. Its an abstraction of the credential. Only specific
provider know how to decode it and get the actual value. So the GFac
"framework" doesn't need to deal with the specific information about
the credential.

>> 2. We also discussed about how to handle security when there are
>> multiple providers per request. E.g :- for a single request we may
>> need to transfer files between 2 GRID providers. Maybe from EC2 to
>> XSEDE. To handle such scenario we need to have more than one security
>> credentials in the security context. Inorder to support this use case
>> we can pass more than one community user names in the request.
> Will this be a community user name or a handle to the ACS credential (not the temporarily
created certificate/token but the registered security identity)? I ask because, if we register
EC2 or GCE (google compute engine), there will be no user names but a registered security
certificates and I assume its client responsibility to manage these handles.

I would say its a handle to the ACS credential. In the case of XSEDE
it will be same as community user name. But in the case of some other
type of credential such as EC2, GCE, it will be a unique name given by

>> 3. Another concern that arose during the chat was about renewing
>> credentials. As per now OA4MP (OAuth for My Proxy) does not support
>> credential renewing. This might have an impact on current deployments
>> once 0.7 is released. I guess the ideal solution would be to have
>> credential renewing at OA4MP side. Until we have that feature in OA4MP
>> we can use a configuration file to read my proxy data. (As we do now).
>> So if "credential store" credentials are expired or not available we
>> will use configured default my proxy security data.
> I would recommend against having the need for a my proxy password again, that counters
the whole purpose of ACS right?

I am referring to "my proxy proxy renewal beyond the default life time
of 11 days", and yes, it does counters the purpose of ACS. But how
would we go with 0.7 release ? Are we going to ask users to renew
credentials every 11 days ?

Please suggest if you think there is a better way to tackle this problem.


I understand its a work around but still. There are two renewal issues
here are, which one are you referring to here? The my proxy proxy
renewal beyond the default life time of 11 days? or a delegated proxy
which currently is defaulted to 2 hours?
> Cheers,
> Suresh
> [1] -
>> Also it was proposed to store encrypted user name/passwords in ACS in
>> addition to SSH keys and myproxy keys.
>> Appreciate your feedback on above suggestions.
>> Thank you
>> Regards,
>> Amila

View raw message