Advances in Middleware Security - a Globus perspective

International Grid Trust Federation PKIs for Grids have now reached world-spanning size. http://www.gridpma.org

X509 Delegation and Single Sign-on Standardized RFC 3820 defines format and path validation for Proxy Certificates Allows for single sign-on and delegation across domains ECC Single Sign-on Proxy Delegation Domain A Proxy Service Domain B

Web Services Security Stands are slowly evolving (Jan ‘04) WS-Secure Conversation WS-Federation WS-Authorization WS-Policy WS-Trust WS-Privacy WS-Security In progress SOAP Foundation proposed promised

Web Services Security Stands are slowly evolving (today) WS-Policy WS-Federation WS-Authorization XACML WS-Secure Conversation WS-Trust WS-Privacy SAML WS-Security Evolving In progress SOAP Foundation proposed promised

Pluggable Authorization Strong success in developing and deployment of interfaces for plugable authorization. Designed in collaboration (GGF or “back room”). Image from Micha Bayer Image from OSG National Fusion Collaboratory Image from M. Thompson

Operational experiences Security the #1 support errand Incorrect configuration Multiple CAs to install Multiple software layers and distributed systems make error reporting difficult CRL handling awkward Periodic pull requests cause high peak loads Failed updates cause stalled systems

Users, Trojans, and Attacks 15 months ago: SSH attacks Password and key sniffing software on users’ home PCs By stealing user keys at one site, they got immediate access to other sites as well Attack targeted ~/.ssh/ Weak or no password protection Many people keep their grid keys in ~/.globus/ We learned a lot from this Incident response Incident reporting across organizations

“This Grid stuff is all too much for me…” The power of portals Low learning curve Can be made domain specific Can hide “all the X509 stuff” from user Toolkits for Grid Portals PURSE, OGCE, GAMA, GridSphere, GridSite, etc. But, we must also understand the limitations of portals An 80/20 solution Power-users easily get annoyed Difficult for “tinkering-centric” research

Grid Portal Gateways The Portal accessed through a browser or desktop tools Provides Grid authentication and access to services Provide direct access to TeraGrid hosted applications as services The Required Support Services Searchable Metadata catalogs Information Space Management. Workflow managers Resource brokers Application deployment services Authorization services. Builds on NSF & DOE software Use NMI Portal Framework, GridPort NMI Grid Tools: Condor, Globus, etc. OSG, HEP tools: Clarens, MonaLisa Workflow Composer Slide Credit: Nancy Wilkins-Diehr

Grid Services (e.g. Job submission) MyProxy and LTER Grid LTER Portal LDAP Username & Password MyProxy server Creds Proxy PAM LTER LDAP Grid Services (e.g. Job submission) GridFTP

Kerberos-CA: Site Authentication Integration KCA/Kx509 deployment at FNAL has shown X509 integration with site authentication works well Alternate to traditional user-managed credentials Kerberos Logon KCA Kerberos X509

MyProxy 3.0

GridShib (Simplified) SAML Shibboleth Attrs Attributes IdP call- out DN Grid IDs DN SSL/TLS, WS-Security DN

GridShib: current status Beta release since early Sept 2005 Information Provider plugin to Shib 1.3b Authorization callout to GT4.0.1 Attributes-only for now

GridShib and MyProxy Integration SAML Shibboleth Attrs Attributes IdP call- out DN Grid IDs MyProxy w/ online CA DN SSL/TLS, WS-Security DN

It’s not SAML vs PKI … Legacy deployments SAML == Web Browers authentication today Very short-lived bearer credentials Lots of redirection in protocol - assumes web browser SAML seems to be good source of attributes Used for GGF OGSA-Authz Authorization Interface

GT4’s Use of Security Standards Supported, Supported, Fastest, but slow but insecure so default

GT-XACML Integration eXtensible Access Control Markup Language OASIS standard, open source implementations XACML: sophisticated policy language Globus Toolkit ships with XACML runtime Included in every client and server built on GT Turned-on through configuration … that can be called transparently from runtime and/or explicitly from application … … and we use the XACML-”model” for our Authz Processing Framework

GT Authorization Framework

GT Authorization Framework PERMIS VOMS Shibboleth LDAP … Authorization Decision Attributes PIP PIP PIP PDP GT4 Client GT4 Server

GT4 WS GRAM 2nd-generation WS implementation optimized for performance, flexibility, stability, scalability Streamlined critical path Use only what you need Leverage SUDO for critical code Flexible credential management Credential cache & delegation service GridFTP & RFT used for data operations Data staging & streaming output Eliminates redundant GASS code

GT4 WS GRAM Architecture Service host(s) and compute element(s) Job events SEG GT4 Java Container Compute element GRAM services GRAM services Local job control Local scheduler Job functions sudo GRAM adapter Delegate Client Transfer request Delegation Delegate GridFTP User job RFT File Transfer FTP control FTP data Remote storage element(s) GridFTP

More user requirements Installation of special software … and updates thereof Prestaging of datasets Operating additional services … and debugging when they fall over There is a need for “VO services” Continuation of GRAM saga. Maintenance of VO applications - beachhead into local environment. Ian/Miron & Kate WORMS paper. E.g. need version of PERL, or locally compiled application that depends on L2 cache size. Currently guy sitting at CERN with 100s of local accounts and perl scripts that use SSH.

VO services need to be managed Ensure they don’t consume more resources than allocated Provide persistency and management functions (start, stop, suspend, resume) Adhere to site security, auditing, and accounting policies All that could be done by site admins but it would be favorable to have infrastructure services taking care of that

Example: current gLite CE Infrastructure Services VO Services VO admin Submit job Grid GT GRAM LCAS LCMAPS WSS CEMon Notifications Launch Condor-C Many of the experiments have had years of ongoing distr. system effort. Some of it works well and they are not prepared to drop it (immediately) in favor of a comparable grid service. In this example, they use condor and a homegrown monitor checking current system conditions (load etc). Blahpd == condor version of job manager, deployed by sys admin to interface with local scheduler. Condor-C is read because VO admin stands it up. CEMon is VO service that monitors job state, reports when things are done, ready for new input etc. Blahpd Condor-C CE Should evolve into a VO scheduler Local batch system LSF PBS/ Torque Condor

Workspace Service: The Hosted Activity Policy Negotiate access Initiate activity Monitor activity Control activity Activity Client Environment Resource provider Interface

Activities Can Be Nested Client Policy Client Client Environment Resource provider Interface

For Example … Provisioning, management, and monitoring at all levels JVM Deploy service JVM Deploy container VM Deploy virtual machine Hypervisor/OS Deploy hypervisor/OS Physical machine Procure hardware Provisioning, management, and monitoring at all levels

The Future We now have a solid and extremely powerful Web services base Next, we will build an expanded open source Grid infrastructure Virtualization New services for provisioning, data management, security, VO management End-user tools for application development Etc., etc. And of course responding to user requests for other short-term needs

Short-Term Priorities: Security Improve GSI error reporting & diagnostics Trust root provisioning, GridLogon/MyProxy Identity/attribute assertions in GT auth. callouts (e.g., Shib, PERMIS, VOMS, SAML) Extend CAS admin & policy support Security logging with management control for audit purposes MyProxy integration with Shibboleth Ian’s slides.

Integration of all the pieces We’re close…

And for Portals too…

Thank you Questions? Von Welch (vwelch@ncsa.uiuc.edu)