airavata-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Amila Jayasekara <thejaka.am...@gmail.com>
Subject Re: Handling security context in airavata
Date Tue, 12 Feb 2013 20:07:23 GMT
Hi Raminder,

I agree with you. Lets create create context per "application"/service.

Thanks
Amila

On Tue, Feb 12, 2013 at 2:25 PM, Raminder Singh
<raminderjsingh@gmail.com> wrote:
> Its ok to send all the credentials at once to the workflow but it would be good to create
the context per application. In a case where the grid credential was about to expire in few
hours and user started the workflow. The first service may take few hours to complete. Admin
went ahead and update the credentials during that time. Now if we have created the context
at workflow level, workflow have expired credential but Credentials are already updated in
ACS. This problem can be solved if we create the security context per application. That way
we don't need to create multiple security contexts also.
>
> Thanks
> Raminder
>
> FYI: Application means, a node in the workflow.
>
>
> On Feb 12, 2013, at 1:59 PM, Amila Jayasekara wrote:
>
>> On Tue, Feb 12, 2013 at 1:52 PM, Raminder Singh
>> <raminderjsingh@gmail.com> wrote:
>>> A workflow can have multiple application (service). Is it invocation context
of the complete workflow or invocation context of individual application in a workflow?
>>
>> It is the "invocation context of the complete workflow". If user has
>> applications talking to multiple grid providers, all credential ids
>> (community user names) should be sent  in the request.
>>
>> Thanks
>> Amila
>>
>>>
>>> Raminder
>>> On Feb 12, 2013, at 1:46 PM, Amila Jayasekara wrote:
>>>
>>>> Hi Raminder,
>>>>
>>>> More answers inline.
>>>>
>>>> Thanks
>>>> Amila
>>>>
>>>> On Tue, Feb 12, 2013 at 11:28 AM, Raminder Singh
>>>> <raminderjsingh@gmail.com> wrote:
>>>>> 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.
>>>>
>>>> I would say a security context for each invocation. I am not sure
>>>> whether you meant the same thing by saying "per application". If not
>>>> please describe.
>>>>
>>>>>
>>>>> 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?
>>>>
>>>> Before invoking the WF (Workflow) credentials should be in ACS
>>>> (Airavata Credential Store). At the time of storing credentials to
>>>> ACS, user need to specify a name. This name is unique to a gateway.
>>>> Then afterwards when user invokes workflow he/she needs to send
>>>> "credential user names" as a list.
>>>>
>>>>>
>>>>> Do you have ETA on  OA4MP service to renew proxy automatically?
>>>>
>>>> No, I dont have. We may need to check with OA4MP debs how to achieve
>>>> this. Also we need to check how to renew credentials for other types
>>>> of providers. (Mainly IaaS ones)
>>>>
>>>> Thanks
>>>> Amila
>>>>
>>>> That would be much needed for production gateways to use OAUTH credentials.
>>>>>
>>>>> Thanks
>>>>> Raminder
>>>>>
>>>>>> 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
>>>>>
>>>
>

Mime
View raw message