Gap Analysis JRA3

1. Gap AnalysisJRA3 10/23/2019 www.eu-egee.org EGEE is a project funded by the European Union under contract IST-2003-508833

2. Architecture (non-complete) Trustanchors Trustanchors processspace Credstore AA VOpolicy Revo- cation Revo- cation “sudo” Accesscontrol Accesscontrol service Proxycert Sitepolicy Sitepolicy delegation Audit Audit Intrusion Intrusion <event>, <date> - 2

3. What we have (UNIX native) Trustanchors Trustanchors processspace MyProxy VOMS GRAM +LCMAPS Credstore AA VOpolicy Revo- cation Revo- cation EDG CRLscripts “sudo” Accesscontrol Accesscontrol service GACL gSoap Proxycert Sitepolicy Sitepolicy LCAS delegation HTTPG Audit Audit ??? Intrusion snort(*) (*) Almost there <event>, <date> - 3

4. What we have (hosted) Trustanchors Trustanchors MyProxy(client) processspace CAS Credstore AA VOpolicy GT,EDG Java GRAM Revo- cation Revo- cation “sudo” Accesscontrol Accesscontrol SAML(*)XACML(*) service Axis Proxycert Sitepolicy Sitepolicy EDGAuthZ(*) delegation various Audit Audit ??? Intrusion (*) Almost there <event>, <date> - 4

5. What we want (non-complete) Trustanchors Trustanchors Credstore VOMS VOpolicy Revo- cation Revo- cation Policybased authZ Accesscontrol Accesscontrol service Proxycert Sitepolicy Sitepolicy delegation Audit Audit Provisioning ??? Intrusion <event>, <date> - 5

6. Configuration issues • Many different policy configuration languages… • EDG Java AuthZ, LCAS, GACL, XACML … • No single solution adequate for all scenarios (coarse-grained, fine-grained, combination) • We need to combine them! • XACML is best suited to handle policy arbitration, but you don’t want to code in it (ugly) • Sun has a full (and free) java implementation, performance issues? • Whatever we use, make sure they all can be mapped into a common form (XACML?) • Allows for rule combinations from different authorities • Local site policy always overrules <event>, <date> - 6

7. Provisioning (2-year effort) • Many CA certs to keep track of, new ones are added • CRLs get outdated • Much of this stuff is only understood by experts • Provision user with this type of configuration at login • Similar ideas elsewhere, should be able to collaborate on this <event>, <date> - 7

8. WHAT ARE OUR PERFORMANCETARGETS? TLS MODS AREINVASIVE Transport • SOAP over HTTP (message level security) • Flexible (integrity vs. encryption) • Standard (WS-Security spec) • Enables routing and endpoint trust • Issue: performance penalty in Java (slowdown due to xmlsec.jar) • Issue: replay attacks (dealt with in e.g. GT4) • SOAP over HTTPS (transport level security) • We know how to do it • Accepted by WS-I • Issue: TLS needs mods due to proxy certs • Issue: no endpoint trust (trust server, not service) <event>, <date> - 8

9. Delegation • Separate delegation WSDL portType • Orthogonality and zero cost for non-delegation services • Easy transition path from any chosen transport solution • Issue: Non-existing but prototype can quickly be conjured • Issue: Additional complexity in applications and clients for environments w/out operation provider solutions • Delegation in HTTPS headers • G-HTTPS (GSI) • SPNEGO over WWW-Authenticate (GSSAPI) <event>, <date> - 9

10. Delegation (cont.) • Delegation coupled with authentication (GSI) • We know how to do it, solutions exist • #1. SOAP over HTTPG • #2 GSI-SecureConversation (SOAP over HTTP) <event>, <date> - 10

11. Our recommendation • Transport #1: SOAP over HTTP and message-level security • Pending performance requirements of course… • Transport #2: SOAP over HTTPG • TLS impl needs to be patched anyhow, doesn’t matter if protocol is bent as well • Delegation #1: Delegation portType • Delegation #2: GSI-based delegation • 2.a: GSI-SecureConversation (if T.#1) • 2.b: SOAP over HTTPG (if T.#2) <event>, <date> - 11

12. But that won’t work with my browser… • It shouldn’t! • Use portal and standard TLS server certificates for end-user interaction <event>, <date> - 12

13. Software platform:Most leverage in the java world • Many free third party products • SAML, XACML, XMLSec, Axis, GT • The gaps we need to fill are “our own” • GACL, VOMS, LCAS, … • Assuming Axis, we need to integrate with it • Work already underway with AuthZ framework in GT from KTH • EDG Java AuthZ as backup • Portability requirement way easier to fulfill • new java.io.File(“/etc/grid-security”).getAbsoluteFile() = C:\etc\grid-security • Performance may be an issue <event>, <date> - 13

14. In the C world… • gSOAP • Better performance • No WS-Security • GSI plugin (CERN or Italy) needed for HTTPG • Axis C++ • Buggy still • Would avoid it at this point • Stability issues • A crash means a core dump <event>, <date> - 14

15. ONE MUST REMEMBER • In the end, we should settle on PROTOCOLS and SYNTAX, not on toolkits • But, above everything else, it is the available toolkits that controls our choice <event>, <date> - 15

16. Other requirements • Encrypted storage • Higher-level service, on top of existing storage infrastructure • Secure and redundant storage of encryption keys (M-of-N) • Anonymity • Hard <event>, <date> - 16

17. Who toblame?A, B, V ? ! “Members of Vmay consumemy quota” VO member User B Playing the Blame Game Resource quota AllocationsCommittee VO V User A <event>, <date> - 17