airavata-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Raminder Singh <>
Subject Re: Handling security context in airavata
Date Tue, 12 Feb 2013 16:28:47 GMT
Thanks Amila for describing it well. Are you planning to create the security context per workflow(Workflow
interpreter level) or per workflow application(GFAC API level)? Difference is, GFAC knows
the type of application and can create/request a particular credential as needed fill it into
the conext. Then context can be shared between input/output chain and provider. Workflow interpreter
does not know anything about the type of service and need to fill all the different credentials
into context before invoking any application and one of them will be left unused. I thing
having a single security object per application is required. I can think about cases where
user want to transfer gridftp files to EC2 provider but i dont think we are addressing that
problem yet.  Problems of having multiple security in the context will make the context object
bulky and lot of time object will be not used.  

How do you expect users to send security information (Format)? Means if i have workflow with
Grid and EC2 service, i need to call some API functions to set both with different object
types. How do you think this to work for non java clients?  

Do you have ETA on  OA4MP service to renew proxy automatically? That would be much needed
for production gateways to use OAUTH credentials. 


> Hi All,
> We had an offline discussion about handling security contexts at GFac
> level. Some of the ideas discussed are as follows,
> 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 ...).
> 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.
> 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.
> 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