There are lots of requirements to support extra authentication methods, 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.
Setting up a system of plugins for authentication would be the best way to acheive this.
→ 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)
→ 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.
→ 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.
→ 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
→ 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)
→ This way you run the risk of breaking log-in again if the IdP desides to change one of the “read only” params
→ Mantis should only care about the fact that the user is authenticated, not how this came to be.
→ Pref. this should be done by having mantis request access to mantis for the user, not by periodically syncing the user database.
→ If the above condition is met, this is no longer a problem.
→ 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 a 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.
- seems like the domain of the cms to me.
→ 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
→ I fear this will not work as this will require the other applications to open up that authorization db.