mantisbt:issue:4235
Differences
This shows you the differences between two versions of the page.
Both sides previous revisionPrevious revisionNext revision | Previous revision | ||
mantisbt:issue:4235 [2008/01/28 14:38] – Drafting NT | mantisbt:issue:4235 [2008/10/29 04:36] (current) – external edit 127.0.0.1 | ||
---|---|---|---|
Line 1: | Line 1: | ||
- | ====== | + | ====== |
* **Author**: NT | * **Author**: NT | ||
- | * **Status**: | + | * **Status**: |
* **Associated Issue**: http:// | * **Associated Issue**: http:// | ||
+ | |||
===== 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 single sign-on | + | -> In general terms: Mantis should focus on authorisation, |
- | - 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' | + | |
+ | |||
+ | -> The addition of name/ | ||
+ | |||
+ | - Support for authentication methods | ||
+ | * e.g. Open ID / CAS. | ||
+ | - Support for single sign-on. | ||
+ | * e.g. Windows Login, CMS integration, | ||
+ | |||
+ | -> Requirement for both examples are very different: Windows login crosses the os - browser border, CMS integration doesn' | ||
+ | |||
+ | * 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, | ||
+ | |||
+ | - 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' | ||
+ | * 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. | ||
- | - 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, | ||
- | ===== 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 | + | -> This way you run the risk of breaking log-in again if the IdP desides |
- | Anonymous authentication needs to be as simple as enabling | + | - 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. |
- | which would then create | + | |
- | We should | + | -> Mantis |
- | (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 | + | * For example, if a user is authenticated against Active Directory, then removed from Active Directory, then he/she should |
- | to add a form to the login/ | + | |
- | They may also be required to display a different page instead. | + | |
- | Plugins | + | -> Pref. this should |
- | We would wish to check for methods that require fetching no extra resources | + | |
- | (Anonymous | + | |
- | and 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. | + | * 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. |
- | Plugins may need to fill in missing credentials for later plugins to check against | + | -> If the above condition is met, this 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 | + | * 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 | ||
- | There should be a plugin configuration page which plugins can | + | -> When you introduce delegated authentication, |
- | override | + | |
- | The signup process should | + | - 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, | ||
+ | |||
+ | - Check if user exists on another system, and if not delete/ | ||
+ | |||
+ | -> I fear this will not work as this will require the other applications to open up that authorization db. | ||
+ | |||
+ | - Fetch security levels/ | ||
+ | - (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/ | ||
+ | - 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:// | ||
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, | ||
==== Database Changes ==== | ==== Database Changes ==== |
mantisbt/issue/4235.1201549092.txt.gz · Last modified: 2008/10/29 04:36 (external edit)