User Tools

  • Logged in as: anonymous (anonymous)
  • Log Out

Site Tools


mantisbt:issue:4235

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision
Previous revision
mantisbt:issue:4235 [2008/01/28 14:38] – Drafting NTmantisbt:issue:4235 [2008/10/29 04:36] (current) – external edit 127.0.0.1
Line 1: Line 1:
-====== Requirements for Plugable Authentication ======+====== Pluggable Authentication ======
  
    * **Author**: NT    * **Author**: NT
-   * **Status**: Draft+   * **Status**: Proposal
    * **Associated Issue**: http://www.mantisbt.org/bugs/view.php?id=4235    * **Associated Issue**: http://www.mantisbt.org/bugs/view.php?id=4235
 +
  
  
 ===== Introduction ===== ===== Introduction =====
 There are lots of requirements to support extra authentication methods,  There are lots of requirements to support extra authentication methods, 
-and lots of patches supplied against various different releases to add an authentication method. +and lots of patches supplied against various different releases to add an authentication method.\\  
-We need a means of adding an Authentication method that does not need to patch core functionality.+We need a means of adding an Authentication method that does not need to patch core functionality.\\ 
 Setting up a system of plugins for authentication would be the best way to acheive this. Setting up a system of plugins for authentication would be the best way to acheive this.
 +
 +
 +
 +
  
 ===== High Level Requirements ===== ===== High Level Requirements =====
-  - Support for authentication via Mantis plugins by supporting protocols that validate a user name/ password, as well as others that delegate the authentication process to another application (e.g. Open ID / CAS)+ 
-  - Support for single sign-on (e.g. Windows Login, CMS integration, etc). The single sign on should work for both Login and Logout scenarios. +-> In general terms: Mantis should focus on authorisation, not on authentication. Authorization is the domain of either an internal module, or delegated away to an external Identity Provider (IdP) 
-  - Support for hybrid authentication. For example, employees are authenticated against LDAP where customers are authenticated using Mantis standard infrastructure. + 
-  - Avoid sign-up when a user is authenticated but doesn't yet have a record in the DB. In this case, Mantis should pull the required data from the authentication plugin. For example, pull user information from LDAP when a user logs in for the first time.+  - Support for authentication via Mantis plugins by supporting protocols that validate a user name/ password
 + 
 +-> The addition of name/password is not needed, as some protocols may not use passwords for validation (but e.g. use certificates). A suggestion for a   description here would be: "supporting protocols that provide a validated identity". Mantis should not care how this validation came to be. 
 + 
 +  -  Support for authentication methods that delegate the authentication process to another application
 +    * e.g. Open ID / CAS. 
 +  - Support for single sign-on
 +    * e.g. Windows Login, CMS integration, etc.  
 +     
 +-> Requirement for both examples are very different: Windows login crosses the os - browser border, CMS integration doesn't. I would suggest to name both as separate requirements. 
 + 
 +    * The single sign on should work for both Login and Logout scenarios. 
 + 
 +-> When authentication is delegated, Login and Logout are not the responibility of the application, but are in fact links to the pages on the IdP whare a user can logon or logoff 
 + 
 +  - Support for hybrid authentication.  
 +    * For example, employees are authenticated against LDAP where customers are authenticated using Mantis standard infrastructure. 
 +  - Avoid sign-up when a user is authenticated but doesn't yet have a record in the DB.  
 +    * In this case, Mantis should pull the required data from the authentication plugin.  
 +    * For example, pull user information from LDAP when a user logs in for the first time.
   - Prepopulate sign-up form with fields from authentication plugin (e.g.LDAP, OpenId, X.509).   - Prepopulate sign-up form with fields from authentication plugin (e.g.LDAP, OpenId, X.509).
-  - An authentication plugin should be able to mark some of the user profile information as read only. For example, user name or email may be marked as read only. 
-  - Once a user is signed up using a protocol, this protocol should be stamped on the user record and in the future the user should only be able to login via this protocol. For example, if a user is authenticated against Active Directory, then removed from Active Directory, then he/she should not be able to login against their user record in Mantis (use in termination of employment scenarios). (This may cause a problem when a user logs in via Windows auth at work, but would like to login from home where he/she is not authenticated in Windows. 
-  - When a user signs on, the protocol used needs to be recorded so that reauthentication and logout use the same protocol.    -- storing this on the database may be a problem if users are sharing userids. 
-  -  Once we have authenticated we should be able to use our credentials to automatically sign the user into another system (e.g. a wiki) and log then out of that system when we log out of mantis. 
-  - Provide functions that can be used by cms integration. e.g. when you log into a cms, one of its plugins logs you into mantis. 
-  - On starting mantis, if the users identity can be immediately detirmined, then they should be automatically logged in without seeing the login pages. 
-  - Easy Customisation of login, signup and reauthentication pages. 
  
 +-> Mantis should only store user attributes that it needs for authorisation, not for authentication. Therefor propolulation fields containing authentication data is not a good idea. This will break log-in's as the IdP providing authentication might decide to change these (e.g. change the password after 30 days)
  
-===== Detailed Requirements =====+  - An authentication plugin should be able to mark some of the user profile information as read only.  
 +    * For example, user name or email may be marked as read only.
  
-The existing authentication methods (e.g. LDAP, HTTP) need refactoring to become plugins.+-> This way you run the risk of breaking log-in again if the IdP desides to change one of the "read only" params
  
-Anonymous authentication needs to be as simple as enabling plugin +  - Once user is signed up using a protocolthis protocol should be stamped on the user record and in the future the user should only be able to login via this protocol
-which would then create the required anonymous user (if not already existing).+
  
-We should be able to take credentials from other active logins  +-> Mantis should only care about the fact that the user is authenticated, not how this came to be.
-(e.g. a cms token,http or X.509 authentication) and use that to automatically  +
-login (and reauthenticate ?) the user without asking them to supply another set of credentials.+
  
-Authentication systems which use credentials other than userid/password should be able  +    * For example, if a user is authenticated against Active Directory, then removed from Active Directory, then he/she should not be able to login against their user record in Mantis (use in termination of employment scenarios).
-to add a form  to the login/reauthentication/signin pages for their credentials (e.g. openid url)+
-They may also be required to display a different page instead.+
  
-Plugins should have a means of specifying their priority.  +-> Pref. this should be done by having mantis request access to mantis for the user, not by periodically syncing the user database.
-We would wish to check for methods that require fetching no extra resources  +
-(Anonymous user or X.509) firstthen those which require database accesses,  +
-and finally those that require fetching an external resource (e.g. LDAP, CAS).+
  
-Plugins could be allowed to deny request authorised by an earlier executing plugin.+    * This may cause problem when a user logs in via Windows auth at work, but would like to login from home where he/she is not authenticated in Windows.
  
-Plugins may need to fill in missing credentials for later plugins to check against  +-> If the above condition is metthis is no longer a problem.
-(e.g OpenId plugin to supply userid that the url relates to +
-or http plugin to supply userid (and password ?).+
  
-Plugins should be able to be marked as protected,  +  - When a user signs on, the protocol used needs to be recorded so that reauthentication and logout use the same protocol.     
-to prevent users from accidentally removing access to their site.+    * storing this on the database may be a problem if users are sharing userids. 
 +    * storing in a cookie would be a security concern. 
 +  -  Once we have authenticated we should be able to use our credentials to automatically sign the user into another system (e.g. a wiki) and log them out of that system when we log out of mantis.
  
-There should be plugin configuration page which plugins can  +-> When you introduce delegated authentication, single sign-on is not the  responsibility of the application. Single sign-on is the result of the fact that different applications, e.g. Mambo and Mantis share common identity provider and are able the take note of a common authentication token, e.g. a cookie containing an authentication information. This leads to the fact that the application itself does not have controle over login and logout and does not need to care about it. It just needs to check if the delegated authentication system provides a go or no-go and act accordingly
-override to add extra fields as needed+
  
-The signup process should be able to be configured so that it does not have to send  +  - Provide functions that can be used by cms integration.  
-a confirmation email, as this is a problem for some sites  +    * e.g. when you log into a cms, one of its plugins logs you into mantis. 
 + 
 +- seems like the domain of the cms to me. 
 + 
 +  - On starting mantis, if the users identity can be immediately determined, then they should be automatically logged in without seeing the login pages. 
 +    * e.g. http or X.509 authentication. 
 +  - Easy Customisation of login, signup and reauthentication pages. 
 + 
 +-> For delegated authentication, these pages are part of the idp, not of the local application. The local application redirects the user to the idp in case of an access denied 
 + 
 +  - Check if user exists on another systemand if not delete/disable them in mantis 
 + 
 +-> I fear this will not work as this will require the other applications to open up that authorization db 
 + 
 +  - Fetch security levels/permissions from another system to allow central administration. 
 +  - (Slightly off topic) What user details are help in mantis long term and are there data protection issues if users cannot remove their accounts. 
 + 
 + 
 + 
 +===== Detailed Requirements =====
  
-Basic/http authentication to get web server to display sign-in dialogue where possible.+  - The existing authentication methods (e.g. LDAP, HTTP) need refactoring to become plugins. 
 +  - Anonymous authentication needs to be as simple as enabling a plugin,  
 +    * This would create the required anonymous user (if not already existing). 
 +  - We should be able to take credentials from other active logins and use that to automatically login (and possibly reauthenticate) the user without asking them to supply another set of credentials. 
 +    * e.g. a cms token,http or X.509 authentication 
 +  - Some Authentication systems use credentials other than userid/password. These should be able to modify the login / reauthentication / signin pages by doing one of the following :- 
 +    - add a new fields to the existing form. 
 +    - add a new form to the existing page for their credentials. 
 +    - display a different page instead. 
 +  - Plugins should be able to be marked as protected, to prevent users from accidentally removing access to their site. 
 +  - Plugins should have a means of specifying their priority.  
 +    - first run methods that require fetching no extra resources (e.g. Anonymous user or X.509) 
 +    - then those which require database accesses   
 +    - finally those that require fetching an external resource (e.g. LDAP, CAS). 
 +  - Plugins could be allowed to deny a request authorised by an earlier executing plugin. 
 +  - Plugins may need to fill in missing credentials for later plugins to check against  
 +    * e.g OpenId plugin to supply username that the url relates to  
 +    * http plugin to supply username (and password ?) 
 +  - There should be a plugin configuration page which plugins can override to add extra fields as needed.  
 +    * Need to make sure this //only// affects the performance of the manage plugins page. 
 +  - The signup process should be able to be configured so that it does not have to send a confirmation email, as this is a problem for some sites.    
 +  - Basic/http authentication to get web server to display sign-in dialogue where possible. 
 +    * Also for reauthentication. 
 +  - Authentication libraries, such as [[http://pear.php.net/package/Auth|PEAR::Auth]] or [[http://framework.zend.com/manual/en/zend.auth.html|Zend_Auth]] , should be taken into consideration 
  
  
Line 74: Line 126:
   * usually if already_verified is set plugin will just pass these parameters to the next in the chain unchanged.    * usually if already_verified is set plugin will just pass these parameters to the next in the chain unchanged. 
   * when all the events have been processed the user will be logged in if already_verified is true, otherwise the current error message will be displayed.   * when all the events have been processed the user will be logged in if already_verified is true, otherwise the current error message will be displayed.
 +  * We might wish to specify the plugins and their order in the configuation file. This would give an easy way to reset a site where all access had been accidentally removed. It would also simplify how to get plugins to run in the correct order.
 +  * An AuthenticationManager class should be used (initially fronting the current authentication_api, but eventually replacing it). This should make it easier to set up unit tests.
  
 ==== Database Changes ==== ==== Database Changes ====
mantisbt/issue/4235.1201549092.txt.gz · Last modified: 2008/10/29 04:36 (external edit)

Driven by DokuWiki