-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Airavata API client stubs can be deployed as Rave/SpringMVC controllers that can be added on to Rave via Maven overlays.
The idea is that the client (which could be a gadget, XBaya web start, a non-gadget JavaScript-based web client) has access to the Airavata services via REST calls to the Rave controllers. The client would not directly contact Airavata services but would do so through the security context provided by Rave. The client stubs that encapsulate the API in the controllers would need to be kept in sync with the API implementation on the Airavata server. Versioning may help here. Also, we could co-deploy Rave and Airavata on the same server. The Rave controllers then communicate with the Airavata API directly rather then going through Web service calls. It would take a fat Tomcat to handle all this, though. Marlon On 4/11/12 10:02 AM, Raminderjeet Singh wrote: > My comments are inline. > On Apr 11, 2012, at 1:06 AM, Saminda Wijeratne wrote: > >> Following is a result of a discussion last week on how we could use Apache >> Rave to manage Authentication for Airavata. >> >> There will be 2 servers. An Airavata server & a Rave portal hosted on 2 >> Tomcat servers where each configured to trust the SSL certs of the other. >> > +1. These things are easy to do when we are close to production but with > development systems its difficult as you don't want developers to deal with > setup problems. >> Airavata Server will expose the Airavata API (under construction) >> Airavata API - has Airavata related tasks available for 3rd party clients >> (eg: registry access, workflow execution/monitoring etc.) >> >> Using Rave, >> Authentication for Airavata users (Airavata doesn't handle this yet) >> A portal for the XBaya web application > With Xbaya web as PHP application we are introducing another web server. We > need to do SSL trust store these also. We need to block all other calls on > the apache server. >> Rave exposes the same Airavata API but with authentication headers. 3rd >> party clients should use this instead of the API exposed in Airavata server. >> Once Rave performs proper authentication, the request is forwarded to the >> Airavata Client module. > Is this mean Airavata API's need to be deployed on same server and all the > service ERP's need to be exposed by Rave? My suggestion is to have 2 services > in rave 1. Authenticate (which will create a token with life time) and 2. > Token validation service called by Airavata API to validate the token. We can > discuss more on this and may need other services. >> The Airavata Client module (a controller in Rave) invokes the Airavata API >> in the Airavata Server. Airavata Server will only accept requests coming >> from this Rave instance. > Its better if we keep the Airavata API close to Airavata server to avoid SSL > authentication and any jar versioning issues. >> After authentication, XBaya gadgets can also directory work with the >> Airavata Client to perform its' tasks. > Xbaya gadget is a good idea and is going to help users to have a central > service. We need to address how we will pass security tokens to webserver > hosting xbaya. I believe that server also need user information to load user > workflows from the registry. >> >> This is just a sketch of an idea. Any thoughts? >> > I liked the idea and lets work together to see where Rave need to be > extended. Other important thing to consider is Authorization. >> Note: the Airavata Server can be considered as the collection of following >> services >> GFac Service >> Workflow interpreter service >> XBaya Service >> msgbox service >> msgbroker service >> >> Thanks & Regards, >> Saminda > > Thanks > Raminder >> >> > > -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.16 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJPhZVxAAoJEEfVXEODPFIDVhcH/3D18gKCjwtyt4+yHOurFr5F 7tPPQ3ZbvjQgSfzKJOL6RhU78IWVZyP++P3Rhgg2SctgkYFHHFqmPwbQ8fYI7U8W QOM6WIFKotWRcigdvU4KR0XNvL1DFiYZstkwMGgrR9gbcGYZDFUURlaGwiD5UmZT b54NZaR0F6gOzR0FXOsbUZtb+4vyUcDP+ZxscFOuRWT6pZz7JMYfhQCg/l08gWCL DvgTTtLWsNvX3kaFK0/BTMN62dSd7og5Qeo6dfCqAwnMGsGWVEwVkZb7e+w/Cp4i zG3ZAle9pRbg50VIl00wLabsWYcFXGjxiI60HCUGoQBmmc5+ZdLp27Wbn6wmVAU= =aFSK -----END PGP SIGNATURE-----
