IVOA Single Sign-On security

Transcription

1 IVOA Single Sign-On security Guy Rixon Presentation to ACCIS meeting Caltech, February 2007

2 Grid of secured services VOSpace App-server Restricted archive IVOA SSO, ACCIS meeting, February

3 Client-server authentication Digital signature VOSpace (SOAP) Restricted archive (HTTP) HTTPS Digital signature App-server (SOAP) See IVOA docs for details This is well understood IVOA SSO, ACCIS meeting, February

4 Delegation Signed request Impersonation proxy Delegation service App server Signed request in user's name VOSpace This is imperfectly understood and needs prototyping. IVOA SSO, ACCIS meeting, February

5 Getting certified Long-term cert. National/regional CA MyProxy This is reasonably well understood......but poorly documented Astro community CA IVOA SSO, ACCIS meeting, February

6 Proving membership Assertion: J. R. Astronomer works at Caltech and can use Caltech's account on TeraGrid -- the authority Attribute authority Signed request + assertion(s) Service This is poorly understood IVOA SSO, ACCIS meeting, February

7 SSO across web-sites Desktop app Desktop app AstroRuntime Web browser PubCookie MyProxy, attribute auth. App-server etc. MyProxy attribute auth. Web site Web site This is well understood (in NVO)......but contentious. IVOA SSO, ACCIS meeting, February

8 IVOA Single Sign-On security Guy Rixon Presentation to ACCIS meeting Caltech, February 2007 IVOA SSO, ACCIS meeting, February

9 Grid of secured services VOSpace App-server Restricted archive IVOA SSO, ACCIS meeting, February We have to restrict access to some of our IVO services. Some resources already have an access policy (some archives); some are private to a user (VOSpace); some are paid for on behalf of only some users (the compute grids); some are logically open but delegate work to restricted services. This is control of access to data and services, not of access to the host computers. Since some of the target resources are grids outside our control, we've tended to use their security ideas.

10 Client-server authentication Digital signature VOSpace (SOAP) Restricted archive (HTTP) HTTPS Digital signature App-server (SOAP) See IVOA docs for details This is well understood IVOA SSO, ACCIS meeting, February Given that a desktop app can get an identity certificate out of a PKI, we just use digital signature to SOAP services and HTTPS to the simple services.

11 Delegation Signed request Impersonation proxy Delegation service App server Signed request in user's name VOSpace This is imperfectly understood and needs prototyping. IVOA SSO, ACCIS meeting, February When a client needs a service (e.g. App server) to use a subordinate service in the user's name (e.g. VOSpace), then the client first delegates credentials to the site of the first service. This uses the delegation-service design from the Globus toolkit. The service receiving the credentials can then sign on the user's behalf using a delegated proxy chained to the client's original proxy. As as result, all services doing IVOA SSO need to handle chains of proxy certificates. This includes the HTTPS services, for which we need some server tweaks.

12 Getting certified Long-term cert. National/regional CA MyProxy This is reasonably well understood......but poorly documented Astro community CA IVOA SSO, ACCIS meeting, February The desktop apps get RFC3820 (grid-style) proxy certificates out of a MyProxy service that is registered in the IVO registry and is typically associated with the user's registration point ( community in AstroGrid terms) The proxies get into the MyProxy cache either because the user puts them there directly using desktop tools or because the community operators put them there on the user's behalf. The credentials can either come from national grid certificate authorities or from authorities within the IVO. In the latter case, the authority is typically run by the community that operates the MyProxy, at whatever level (research group; HEI; national Vobs project).

13 Proving membership Assertion: J. R. Astronomer works at Caltech and can use Caltech's account on TeraGrid -- the authority Attribute authority Signed request + assertion(s) Service This is poorly understood IVOA SSO, ACCIS meeting, February Usually to get into a resource you have to prove your user's membership of a virtual organization. This is to be done by getting signed assertions of membership from an authority representing that VOrg. The service trusts the assertions and uses them when it checks authorization. Service providers say which VOrgs can use the service and let the authorities manage membership. (paranoid service providers can run their own VOrgs internally). There are several protocols for doing this and no common standard. IVOA needs to pick one. EuroVO would like to use VOMs because it's needed to get into EGEE.

14 SSO across web-sites Desktop app Desktop app AstroRuntime Web browser PubCookie MyProxy, attribute auth. App-server etc. MyProxy attribute auth. Web site Web site This is well understood (in NVO)......but contentious. IVOA SSO, ACCIS meeting, February In EuroVO, SSO between desktop apps is easy because the Astro Runtime does the logging in and shares the credentials between all apps. With web portals, it's harder because the web browser doesn't know how to share the right credentials. NVO are solving this with the PubCookie system. I don't know much about that. I presume it to be caching credentials in HTTP cookies. The PubCookie thing should work for desktop apps too. For them, it's an alternative to the AR approach.