Shared Code for Login Users and Management: Difference between revisions
No edit summary |
No edit summary |
||
Line 1: | Line 1: | ||
=Discussion points= | =Discussion points= | ||
== | ==Wish list== | ||
===Interchangeable backends=== | |||
An implementation should have the ability to run off of the local filesystem (for a smaller group sized app) or communicate with a remote third-party server. To some extent, the former may be more important. | |||
===Reusable user identities=== | ===Reusable user identities=== | ||
A person could have a single login across multiple GO applications. Similarly, if somebody did implement their own backend server, they'd be able to use it for single identities across multiple pieces of our software (or use it as a base for their own). | |||
===Simple management=== | ===Simple management=== | ||
It would be nice if there was an easy easy to add and drop users, as well as control what permissions they had for applications that used this system. | |||
===Simple implementation (many languages)=== | ===Simple implementation (many languages)=== | ||
It would be very nice if this was not locked into a single language. This would either mean that is relatively easy and has been implemented many times with a lot of client and server libraries (like OpenID) or had a web API that makes it easy to interoperate with alien software. | |||
===Role-based users=== | |||
A good way to hand;e application permissions. | |||
===One-stop shopping=== | ===One-stop shopping=== | ||
It would be nice to handle everything through a single unified interface (thinking about Drupal users and permissions here). | |||
==Risks== | ==Risks== | ||
Line 43: | Line 52: | ||
| colspan="2" | Drupal | | colspan="2" | Drupal | ||
| Seems heavy when all we would want is the user code | | Seems heavy when all we would want is the user code | ||
|- | |||
| colspan="2" | Mediawiki | |||
| ??? Do they even provide such a thing? | |||
|} | |} | ||
= | =Consumers= | ||
* GOLD database administration | * GOLD database administration |
Revision as of 20:37, 12 July 2011
Discussion points
Wish list
Interchangeable backends
An implementation should have the ability to run off of the local filesystem (for a smaller group sized app) or communicate with a remote third-party server. To some extent, the former may be more important.
Reusable user identities
A person could have a single login across multiple GO applications. Similarly, if somebody did implement their own backend server, they'd be able to use it for single identities across multiple pieces of our software (or use it as a base for their own).
Simple management
It would be nice if there was an easy easy to add and drop users, as well as control what permissions they had for applications that used this system.
Simple implementation (many languages)
It would be very nice if this was not locked into a single language. This would either mean that is relatively easy and has been implemented many times with a lot of client and server libraries (like OpenID) or had a web API that makes it easy to interoperate with alien software.
Role-based users
A good way to hand;e application permissions.
One-stop shopping
It would be nice to handle everything through a single unified interface (thinking about Drupal users and permissions here).
Risks
Things that we're particularly worried about in an implementation.
Accidental exposure
This would cover things like web crawlers somehow finding an "erase all" link
Hacking
I think in general we're not super worried about security (for example, a man in the middle after login was something that got a lot of shrugs), but want the general bases covered. As we're not security experts, reusing a tested stack by somebody else would be nice.
Packages considered
Login/Authentication | Roles/Auth | Notes |
---|---|---|
OpenID | OAuth | Unsure how to tie together and handle management |
Drupal | Seems heavy when all we would want is the user code | |
Mediawiki | ??? Do they even provide such a thing? |
Consumers
- GOLD database administration
- TermGenie