1 / 21

Authentication and Authorization in Condor

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

cherihicks
Download Presentation

Authentication and Authorization in Condor

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Authentication and Authorization in Condor

  2. Outline • General Requirements • Issues • Our Design • Current Status • Plans and Issues

  3. 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

  4. 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

  5. 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

  6. 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

  7. 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

  8. 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

  9. Our Design Condor Daemons ..... Authentication API (partial) • authenticate • forward_credential • receive_credential • is_valid • remove_credential • update_credential Kerberos X.509 ..... NTSSPI

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

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

  12. 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

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

  14. 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

  15. 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

  16. Current Status • Authorization • Defining access control policy • Defined in Condor’s configuration file • Currently host based HOSTALLOW_ADMIN = beak.cs.wisc.eduHOSTDENY_READ = *.wisc.eduHOSTALLOW_WRITE = *.cs.wisc.edu • Will be user based soon ALLOW_ADMIN = alice@cs.wisc.eduDENY_READ = charlie@somewhere.net

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

  18. 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

  19. 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)

  20. 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

  21. That’s it for now! • Questions? • Comments? • Ideas?

More Related