Personal tools
You are here: Home → Developer → Infrastructure Teams → Architecture → Archive → Kepler Authentication Framework
Log in


Forgot your password?
New user?
 

Kepler Authentication Framework

STATUS:

Red TriangleThe content on this page is outdated. The page is archived for reference only. For more information about current work, please contact the Framework team

Overview

Requirements for a Joint Authentication Framework in Kepler

  • Coordinating between the different security architectures
    • GEON uses GAMA which requires a single certificate authority. GAMA uses CACL (Certificate Authority CLient) as its operating a CA (GEON CA).
    • Example: GEON has a community account on TeraGrid which is available because of a trusted that allows to use TeraGrid resources.
    • SEEK uses LDAP with has a centralized certificate authority with distributed subordinate CAs
  • To connect LDAP with GAMA
  • Coordinating between 2 different GAMA servers
  • Single authentication at the initialize step of the run for multiple actors that are using authentication
    • This has issues related to single GAMA repository vs multiple, and requires users to have accounts on all servers.
      • Multiple server single time login SHOULD be discussed more!
      • Some actors (e.g. DBQuery, SRB, Globus, etc...) should be able to use the credentials generated.
      • A special director might be used, maybe???
      • Kepler needs to be able to handle expired certificates for long-running workflows and/or for users who use it for a long time.
    • A trust relation between the different GAMA servers must be established in order to allow for single authentication.

Related Kepler Architecture Requirements:

  • We need a certificate store mechanism in the Kepler architecture to store the generated certificates as a mechanism for the UI to insert/collect information from/to the certificate store.
    • An option to do this is to establish a trust relationship between GAMA servers of different communities.
    • Have a kepler GAMA server and establish (role-based) trust relationship between the Kepler CA and the different communities (this will enable users with no community accounts to access Kepler).
  • The actors that require a certificate needs to be triggered automatically in the workflow.

Roles in the System

  • Currently GAMA supports 4 roles:
    • Public
    • User
    • Advanced User
    • Administrator
  • SEEK would require the institution (==community role) as a role. This role needs to give specific rights based on Distinguished Names (DNs).

The Login Interface Requirements

  • The login interface should consists of domain, username and password. (Similar to the wiki interface.)
  • Use case 1: A user with an account on a specific domain trying to login.
    In this case the user should be able to use her existing username and password.
    • Once logged in, the system will show the servers that the user has access to.

  • Use case 2: A new user trying to login
    • The user request an account on a specific domain, and gets ane mail back.
    • For the first time, he/she gets to login with a demo account.
    • Once a trust is established, the user gets access to public resources.

Open Questions

  1. When would the certificate expire?
  2. What is the action to follow when the certificate expires?
  3. When will the user be considered as logged out? Assuming a detached workflow in batch mode, will the certificate be renewed in the case that it expires?
    1. Ideas: If a workflow is running in batch mode, the director/system should automatically renew it. If the user is running Kepler from Vergil, a notification window asks if the certificate would be renewed. (e.g. bank systems)
  4. Do we need a demo account for a new user?
  5. How do we know which certificate will be sent to which certificates.
  6. How to we set an expiration time for the certificate using GAMA services?
  7. Once a proxy is created by the Kepler login UI, where is it stored/hanging before it is delegated to components that require it?

Required Follow Ups

  • BIRN is moving to GAMA. Better to ask about their experience.
  • Jing will install the GAMA server at NCEAS and will try to connect between LDAP and GAMA.
  • Get more information from the GAMA team on how to create a Kepler server on top of multiple GAMA servers. (i.e. As a connection for different GAMA servers.)
  • Send requirements to GAMA team for comments.

 

User interface mockup

After consulting with Ilkay I (Laura Downey) drafted the following screen designs for the authentication UI's. The wording can be tweaked, I just wanted to give a general idea. I also added an item to the Tools menu that would let a user check which resources they have access to. Those screens would basically be the same as the success screens below without the authentication message.

Authentication UI

Authentication Framework: Authentication Dialog

Successful Authentication UI's - both local access and other resources.

Authentication Framework: Success 1

Authentication Framework: Success 2

Error UI if there is an authentication error.

Authentication Framework: Error

Comments

Matt Jones

These mockups look good in general. I think we need to streamline the "local" accounts. Its not clear that the user should have to log in to access local resources -- they already logged into their OS, and will simply be confused as to what this means. Also, calling it a "demo" account is misleading too. I think it would be better to limit the login function to external services that require authentication.

Also, once logged in, the list of accessible resources will be essentially impossible to determine. Resources are controlled via access rules that reference authentication credentials, and are spread out across many systems. We really don't need to list separate grid resources to which someone has access. Plus, what does 'access' mean in this context? Do they have read access, or read and write, or other levels? For each resource, access levels may even vary in capability (e.g., DiGIR resources don't support write).

As an alternative, I think it is better to simply list the 'Domains' to which someone has been authenticated, e.g., GEON Portal, SEEK Portal). The term 'Domain' might be confusing, but I can't immediatley think of a better term -- it could refer in our context to the GAMA authentication systems that Kepler knows exist. If we go this way, we may want to show previously authenticated domains in the inital login screen so that people can log into more than one domain -- ie, they are authenticated as both SEEK and GEON users at the same time for accessing resources that are controlled using each of those auth systems.

The final dialog that says 'email XXX for an account' needs to be revised, as different authentication systems will have different procedures for gaining accounts. Probably better to point at a web page that can explain each system's requirements and instructions?

API

Chad Berkley

October 2006 re-design

The authentication framework was originaly designed to work with only GAMA. Since the SEEK group has had problems implementing GAMA on their framework, it was necessary for the authentication system to be more flexible and to incorporate other auth frameworks into the design. For this reason, the authentication system was re-designed in Oct. 2006.

The original design made calls in this pattern:

AuthenticationManager -> LoginGUI -> AuthenticationService -> ProxyEntity
This was problematic because not all auth services can use the same gui to get the needed user information. Also, AuthenticationService needed to be subclassed so that different services could process authentications differently. LoginGUI was also doing the actual work of creating the ProxyEntity, which should be done in a non-gui class. The new call order became this: 
AuthenticationManager -> AuthenciationService
                              |
                              +-> LoginGUI
                              |
                              +->ProxyEntity

Where the subclassed Authentication Service creates the appropriate gui login screen then creates the ProxyEntity from that information.

The Domain and DomainList interfaces are still the same, as are the ProxyEntity and ProxyRepository interfaces. An AuthenticationException class was added to provide exception handling for the auth system. There are currently two subclasses of AuthenticationService: GAMAAuthenticationService and LDAPAuthenticationService. The both implement the authenticate() method appropriately to their own service. A new sub-package, gui, was also added to contain the GUI components of the system. Currently there are two different login screens in org.kepler.authentication.gui: GAMALoginGUI and LDAPLoginGUI.

The new api for AuthenticationService is this:

public abstract class AuthenticationService {

	/**
	 * @param operationName The operationName to set.
	 */
	public void setOperationName(String operationName)
	
	/**
	 * @param password The password to set.
	 */
	public void setPassword(String password)
	
	/**
	 * @param serviceURL The serviceURL to set.
	 */
	public void setServiceURL(String serviceURL)
	
	/**
	 * @param userName The userName to set.
	 */
	public void setUserName(String userName) 
	
	/**
	 * Checks if this service has already authenticated
	 * @return True/False to state if the user get authenticated or not
	 */
	public boolean isAuthenticated()
          throws AuthenticationException

	/**
	 * @return Credential to the user
	 */
	public String getCredential()
	
	/**
	 * Authenticate a user
	 */
	public abstract ProxyEntity authenticate(Domain domain)
          throws AuthenticationException;
}

The calls needed to kick off the authentication of a user are the same as before except that you must provide a domain when calling getProxy():

AuthenticationManager authMan = AuthenticationManager.getManager();
ProxyEntity pentity = authMan.getProxy("SEEK");

This will find the correct AuthenticationService subclass based on the domain and call the authenticate() method for that subclass.

Domains are now listed in the configs/ptolemy/configs/kepler/authServiceBundle.properties file instead of being hard coded into an array in DomainList. A configuration for a service looks like this:

domain1=SEEK
serviceOperation1=ldap
serviceURL1=http://library.kepler-project.org/kepler/services/EcoGridAuthLevelOneService
serviceClass1=org.kepler.authentication.LDAPAuthenticationService
The field "serviceClass" was added to allow the subclass of AuthenticationService to be loaded by reflection.

ProxyRepository still allows ProxyEntities to be saved, which keeps users from having to login everytime they need to use a service. The ProxyRepository just needs to be checked to see if a valid proxy exists for that user. ProxyRepository, as well as DomainList are now singletons.

Zhijie Guan

This proposed API is based on Jing’s email on Aug. 17, 2005. This API bridges Kepler code to the GAMA services for proxy management. Your feedbacks are appreciated!

API specification:

/* A ProxyEntity is an entity to store user’s proxy */
public Class ProxyEntity {
  String userName;	//User name
  String domain;	//User domain
  String proxy;	//User proxy

  boolean setUserName(String userName);	// set user name string
  String getUserName();	// get user name string
  boolean setDomain(String domain);	// set domain string
  String getDomain();	// get domain string
  boolean setProxy(String proxy);	//set proxy string
  String getProxy();	// get proxy string
  boolean isExpired();	// check if the proxy is expired
}

/* LifeTime is a class for setting the lifetime of a proxy */
public Class LifeTime {
  // private
  int hour, minute, second;

  // public
  boolean setHour(int hour);		// set hours for lifetime
  boolean setMinute(int minute);	// set minutes for lifetime
  boolean setSecond(int second);	// set seconds for lifetime
  int getLifeTimeInSeconds();		// get the lifetime in seconds
}

/* Domain is a class to record the user’s domain information */
public Class Domain {
  //private
  String domainName, subDomainName;

  //public
  boolean setDomainName(String domainName);		//set domain name
  boolean setSubDomainName(String subDomainName);	//set sub-domain name
  String getFullDomainName();		//get the full domain name
}

/* AuthenticationManager class is responsible for the management of user’s proxy.
 * We use singleton design pattern to make sure there is only one unique instance
 * of this class is running.
 */
Class AuthenticationManager {
  //Public: 
  ProxyEntity getProxy(); 
  //getProxy returns a default proxy to the user (actor) if user gets authenticated. 
  //returning a proxy means the user had been authenticated
  //returning null means the user is not authenticated

  ProxyEntity getProxy(Domain domain);
  //getProxy returns a proxy within the specific domain

  PorxyEntity getProxy(LifeTime lifetime);
  //getProxy returns a proxy with the specific lifetime

  ProxyEntity getProxy(Domain domain, Lifetime lifetime);
  //getProxy returns a proxy with specific lifetime within the specific domain
}

 

Notes for conference call on Oct. 4, 2005

Basically we were talking about what the API between actor and AuthenticationManager is and how to manager the proxy. We got agreement on the following design issues.

  1. One workflow may need multiple proxies (from different domain) for one user. So we need add a ProxyRepository class to manage these proxies.
  2. The API should be simplified to one method (getProxy) with different sets of parameters. The getProxy method will return a Proxy instance for actor to use.
  3. Usually there is only one user for each workflow. So the actor does not need to provide user name to retrieve the proxy. We will, in the future, consider the case of workflows which need multiple users in the same domain.
  4. The AuthenticationManager will create the proxy via GAMA server and store it in ProxyRepository, when the actor requests to do so by calling getProxy.
  5. The proxy sent to the actor is derived from the proxy got from the GAMA server. If the actor asks for special expiration time, the derived proxy will be created with that life time. Otherwise the proxy will be created with default life time, 12 hours.
  6. The AuthenticationManager will keep all the stored proxies alive. When the proxy expires in half an hour, the AuthenticationManager will automatically renew the proxy. This requires the AuthenticationManager running as a daemon thread, to keep proxies updated.
  7. The Class Proxy, LifeTime, and Domain will be public classes for actors to access getProxy method.
  8. The getProxy has the following four sets of parameters, as polymorphism.

Proxy getProxy(): No parameters required. The AuthenticationManager will return a proxy in the ProxyRepository.

Proxy getProxy(Domain): The AuthenticationManager will return a proxy with the specific domain.

Proxy getProxy(LifeTime): The AuthenticationManager will return a proxy in the ProxyRepository with the specific lifetime.

Proxy getProxy(Domain, LifeTime): The AuthenticationManager will return a proxy with specific domain and lifetime.

 

Collaboration Diagrams

Authentication Framework: Manager

 

 

Document Actions