Authentication and Authorization in Condor

transcript

Hao WangComputer Sciences DepartmentUniversity of Wisconsin-Madison

hbwang@cs.wisc.eduhttp://www.cs.wisc.edu/condor

www.cs.wisc.edu/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

Kerberos NTSSPIX.509 .....

Condor Daemons

Authentication API (partial)• authenticate• forward_credential• receive_credential

• is_valid• remove_credential• update_credential

Authentication in Action

ACondor

CondorScheduling

Connect

• User initiate the action

ACondor

CondorScheduling

Connect

Authenticate yourself

• Server requires authentication

ACondor

CondorScheduling

Connect

Handshake

• User provides a list of supported protocols• Server decides which ones to use and in what order

ACondor

CondorScheduling

Connect

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.eduHOSTALLOW_WRITE = *.cs.wisc.edu

• Will be user based soon ALLOW_ADMIN = alice@cs.wisc.eduDENY_READ =

charlie@somewhere.net

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?

Authentication and Authorization in Condor

Documents