Hao Wang Computer Sciences Department University of Wisconsin-Madison Authentication and Authorization in Condor

Outline › General Requirements › Issues › Our Design › Current Status › Plans and Issues

General Requirements › Why do we need security?  A question of trust › We need security in a distributed environment  Control resources usage  Privacy reason  And much more

General Requirements › Secure channel  We want to have a secure way to communicate Send commands, messages or data securely  Secure channel should provide Privacy – no one can eavesdrop on the channel Integrity – no one can tamper with the communication Authenticity – who am I talking to and how can I make sure it’s true

General Requirements › Authentication – who are you?  Provide a positive identification  Mutual authentication is often required › Credentials  Forms of identification  Normally a product of a successful authentication

General Requirements › Authorization  I know who you are, but what can you do?  Map a user to a set of rights Many different ways to setup the mapping e.g. Host based, role based › Data Integrity  Make sure that the data is not tampered › Data Security

Issues › Different authentication protocols  Normally incompatible with each other  Different strength › Non-interactive authentication  User may not be present when authentication is required › How to deal with credentials  Credentials can expire  How to store them

Our Design › Authentication  Support multiple protocols  Independent of actual protocol used  Use API to provide consistency and hide complexity of the protocols › Authorization  User based access control policy  Separation of policy from mechanism

Our Design KerberosNTSSPIX Condor Daemons Authentication API (partial) authenticate forward_credential receive_credential is_valid remove_credential update_credential.....

Authentication in Action A Condor User Condor Scheduling Agent Connect User initiate the action

Authentication in Action A Condor User Condor Scheduling Agent Connect Authenticate yourself Server requires authentication

Authentication in Action A Condor User Condor Scheduling Agent Connect Authenticate yourself Handshake User provides a list of supported protocols Server decides which ones to use and in what order

Authentication in Action A Condor User Condor Scheduling Agent Connect Authenticate yourself Handshake Authentication(s) One or more authentication might be required

Current Status › Authentication  API is already in place One API for authentication –Mechanism independent One API for credential management –Mechanism independent –Dealing with issues such as expiration, forwarding, proxies

Current Status › Authentication (cont.)  Protocols already supported: NTSSPI, Claimtobe, Filesystem  X.509 and Kerberos support is coming soon Supports mutual authentication Supports encryption Supports proxy/delegation Use GSS-API for X.509

Current Status › Authorization  Defining access control policy  Defined in Condor’s configuration file Currently host based HOSTALLOW_ADMIN = beak.cs.wisc.edu HOSTDENY_READ = *.wisc.edu HOSTALLOW_WRITE = *.cs.wisc.edu Will be user based soon ALLOW_ADMIN = DENY_READ =

Current Status › Data Encryption  Using X.509 and Kerberos’ built-in support for now › Data Integrity  Still an open issue

Plans and Issues › Authorization  Look at software and tools for enforcing security policies Keynote, SPKI › Role Based Access Control  Dealing with Access Control based on Roles, not users  More structural

Plans and Issues › Data Security  Would like it to be independent of authentication method  Deal with large amount of data (> GB) Use private key based encryption? › Data Integrity  Deal with large amount of data (> GB)

Conclusion › Our goal is:  Make Condor a secure environment to work with › Where are we?  Worked primarily in authentication and authorization  Still much to be done

That’s it for now! › Questions? › Comments? › Ideas?