Roadmap: System Authentication Library and Third Party Authentication
EDIT: Updated the link (old one was dead.)
Also, should this spec cover avatar support in some way? It'd be nice to be able to import facebook avatars, for example, but I think this may be outside this spec.
I think that the core login method should be disable-able, but if the active one does not exist then fallback to it.
How do you want to store the userinfo? each auth type has its own table? user attributes?
For the tabs, jQueryUI?
Could we possibly get a branch for this? so that we don't have a few people working from scratch on this at the same time.
Thanks for the Spec :)
The PK column is the primary key (e.g. the handle for the authentication type is unique and should be all that is necessary to make this system work.) It's also not user-enterable so it should be fine. If it's necessary to add an authTypeID column that's a numeric primary key field, that'd be fine too.
I wrestled with whether to make the core login disable-able or not. The problem is that if you disable it and screw things up you'll be unable to log back into your site. I'd entertain ways to solve this while making the core login form disable-able. You can also obviously disable it with a custom single page, if you know what you're doing. Perhaps we include a ENABLE_CORE_LOGIN_FORM define() in config/base.php, and it's set, by default, to true, but you can also set it to false?
I wasn't sure about the tabs. jQuery UI makes sense for how to get them up and running quickly, probably (Though we might have to customize it heavily for presentation.)
For User Info, let's store this data in User Attributes. It works well. Generally, all of these methods will ultimately create concrete5 user objects (like how the login via facebook add-ons and the openID code works.)
Once we iron out some of this stuff I will definitely create a branch. Good suggestion.
How about if you disable the core login, then only people in the Administrators group can login via that form and its "hidden", like you have to add site.com/login?auth=core to view that form but normal users won't see it?
What do you mean they will create userinfo objects? like get a user by their facebook ID and using that ID get the user?
and a new question, most (all?) services require a return url, how do you want to handle that? tool?
I like the idea of adding a define() named ENABLE_CORE_LOGIN_FORM and being able to set it to false, and having that be able to hide the core login form. Then, if you get tripped up, you can temporarily enable it to get back into your site. Plus it makes you go through a couple extra steps to disable it, but you don't have to fork code a lot to make it happen.
Check out the bundled OpenID code currently in concrete5 for examples on how we create user objects that come from OpenID providers. This is usually how we handle single sign on: the first time a user signs in from the third party provider, we create the user account in concrete5 seamlessly, and then log them in as this. This is how the facebook signon providers work that have been just added to the marketplace.
Usually these user accounts will have a few extra user attributes (like the facebook add-on gives you users a facebook UID attribute.)
Why don't you fork the current concrete5 authentication repository into a new repo and give people commit access to it as they want it. I imagine jshannon might want it. I'll want it. etc...
And yes, we'll typically use a tools URL for callbacks.
there isn't a current one, just checked github to make sure, do you want me to make one?
Just my 2 cents.
Not knowing much about these SSO auth mechanisms, I would think that adding avatar support simply means having:
a) an "avatar URL" property/attribute on the userinfo account. I expect that most web services prefer that you hotlink to the avatar on their site, rather than download and store locally.
b) an easy API to import the avatar image to c5, for those that don't support a.
The individual auth plugins would then be responsible for updating the avatar, probably on every login (though a 3rd party URL shouldn't change).
This would require a change to the avatar html helper.
I'm not sure exactly how this would work with gravatar, which was a popular request until I created an add-on. It would be easy enough to integrate into the core auth plugin, but it might make more sense to have it at a "higher" level (ie, as a system-wide default). On the other hand, maybe the "model" of having facebook/google/whatever auth means you always rely on them for avatars, and don't really do a default from another service.
I needed something like this for a project, with some extra bells and whistles. 'Normal' users are just C5 users, but there are 3 levels of admin that need to be authenticated against ADS, and get given privileges based on AD group membership. With the additional requirements that if the AD server goes AWOL admin users must still be allowed in using the last password verified against AD, and if the AD account is revoked the corresponding C5 account needs to be closed too.
Fairly simple to do hacking around in controllers/login.php a bit, but these requirements are probably not the typical use case for 3rd-party authentication.
Also, what happens in case of password changes? In the SSO scenario we have AD is the master, and if AD says the password is OK, we update the C5 user. Again, not sure if that should always happen though.
I wrote an AD 3PA add-on for c5 that would update the password of the c5 user so that if LDAP was determined unusable, it would then check the c5 userbase so that the c5 account wasn't unusable.
However, it could be extended to read the account attributes received through LDAP to determine account legitimacy, as well as to ignore all login attempts while the AD server is unreachable (at least for all accounts that require authentication via LDAP).
1) The current markup for the login single_page is very difficult to comprehend and hence not conducive to styling. I would suggest that before any new features are added to it, it should be cleaned up a bit. The reason I thought of this is because my initial look at the tabs in your mockup made me think "that's probably good enough for a generic default that works with anything, but if I were building a client site I would need to style it so everything is on one page with big logos for the various services", and then I shuddered at the thought of having to customize the login page as it currently stands :)
Here's a forum thread where some people have already cleaned it up a bit -- perhaps this can be rolled into the core first before additional modifications are made:
(specfifically, the attachment from MrNiceGaius -- not the one Carlos is working on because that's less of a customizable template and more of the beginnings of a complex addon he's building)
2) I would think it's important that site owners know who's logging in with the third-party credentials, and that the best way to do this is to have a C5 user account for these logins. The specification should provide as much detail as possible about how this is going to work in both the underlying data model as well as how one needs to integrate the account creation process into their own code (and also how to check if the account has already been created and be able to match them up).
It's not clear to me if there's a 1-1 relationship between c5 accounts and the 3rd party auth accounts from birth of the c5 account.
So what I mean is that, say you have a pool of c5 accounts (A, B, C).
1. Can I retroactively associate my account B with my Facebook account?
2. If I create an account D through the facebook mechanism, can I then associate with twitter and login that way? Or can I go back to core login?
I would think the desired answer is "no". And thus, shouldn't there be some sort of "auth id" on the user object, and some check that the correct auth mechanism is logging you in?
Like, user register via c5, that makes an acct,
User registers via facebook, that makes an acct with a user attribute?
or are we somehow connecting accts?
If that happens, and the email addresses exist, I think you dump the user to a screen where they have to login via their concrete5 account.
Check out the open ID portion of the login flow in the login.php single page to see this. There is a conditional for whether a user is logging in via open ID and their email already exists in the system.
So, if the accounts aren't permanently linked, there'll definitely have to be something that allows a post-facto linkage...
example we have Facebook account, Twitter, Google, Yahoo and others.
by having this connections. there is possibilities that someone will create add on for displaying Facebook status, twitter tweet and others at concrete5 wall.
by doing this we can make user more stick to concrete5 wall. and no need to leave it because they want to check facebook status or twitter and others
Just my 2c
$u = new User($username, $password);
I could see how this might cause some legacy issues, so this probably just wishful thinking, but... It would be nice to see the User class get a little more fluid.
$u = User($username, $password_1, $password_2, ..., $password_X);
This is much the same way that current Facebook and twitter addons work, just a more unified way of building them so that they all show up in one spot in the core, all can be built In the same way generally speaking.
So, the idea of validating a user in this way (ie, passing a password to a function) won't work. Theoretically, today, I could call User('a', 'a'), User('b', 'b'), User('c', 'c') in succession and end up with 3 different users objects... I don't think this model will work with, e.g., facebook.
Instead, add-ons would basically just run a function which loads a new page (or ajax) which pops up the oauth window.
... this is all based on my memory of looking into this last year...
Is there any news about this topic?
Is there any news about this ?
I Think it is useful.
I hope it will be released soon.
Or maybe any add on ?
Is there any add on which can fill the gap for a while ?
Objective is to enable modular registration and authentication.
A c5 account has associated data which is important to retain. (ie, c5 accounts "disposable" like in some "use these third parties to comment".) An association to a c5 account has to be made.
1. User with existing c5 account wants to associate that account with an additional authentication method.
2. User wants to create a new account using 3PA provider.
3. Use wants to log in to existing account using 3PA.
4. User has existing account, possibly with an associated 3PA, but forgets provider. Tries to "log in" with incorrect one.
So... there are 3 Actions: New Account, Associate Existing Account, Log in using association
What's the best way to create a new c5 user with my FB credentials? I don't think you make them create a c5 account, then associate. It has to be one logical action. Plus, that would require that password auth sticks around.
Can probably get most info from provider
Might need additional info (attributes required on registration)
Probably not wise to automatically create a new account without confirmation (such as case #4 -- user should be told that they couldn't be automatically logged in, so we're creating an account... or they can try to log in with another provider)
--> 3PA plugin should drop a new user into a core page to finish off registration
Probably not safe to associate automatically (based, e.g., on email address being the same). Also, might be a different identifier (e.g., linkedin provides an unrecorded email address).
--> association requires you to be logged in, or to log in, to complete association
--> --> might get complex to authenticate with, e.g., Google in order to associate with Facebook. At least for v1, assocations can only be done by using the core password authentication (which will be "hardcoded" into this process)
Nothing special identified
Some callbacks are programmatic, others are client redirects. The redirects will have to go to the auth controller, with an argument to specify the plugin, which will then get invoked. The programmatic callbacks can use tools, but the /tools/? handler will have to be modified (tools are hardcoded) and the 3PA plugin won't necessarily be a package.
Storage of data
I can see some plugins having to store lots of various bits. Maybe the "advanced password" authentication would store last date password changed, last 5 password hashes, number of failed attempts, etc. And oauth stuff could have a few different fields, per plugin. If you're trying to use attributes to store, you might end up with 20 new attributes, not all of which should be cluttering up the user's profile. If the plugins want to use attribute, fine, but I think managing their own table should be an option.
Many plugins won't have much of an interface. FB, Google, etc are just a button. Even OpenID is just a single text field, and doesn't have all the "forgot password" stuff. I don't think tabs make much sense. I can imagine people will download a half dozen 3PA plugins for their c5 site (google, fb, linkedin, twitter, etc). Seems silly to have 6 tabs, most of which will just be a button. Plugins should be able to say that they only need a button, and provide the code... the login page will show a list of buttons outside of the tab box.
Usernames and email addresses in c5 need to be unique. It appears that the openid auth creates a username from the openid ID. This isn't very clean and lots of sites use the usernames publicly (so we can't set the username to FB1234).
The registration page should be similar to today, but with a tab setup similar to the login page. It should have the "list of buttons". If I click on one of those, I go through the "association" and come back to the registration page, but with as many fields as possible filled out. I still need to fill out the remaining required fields. An OpenID style plugin would work similarly. Password authentication would add a password box, etc. (not sure how to best implement this into the UI)
Associate / Log In
At least for v1, association happens through the log in. No post-login association.
User goes to log in. They have the normal tabbed choice of plugins, plus the one-click buttons. There are really 3 outcomes (success, failed, success-without-association). Success and fail are treated normally, but without-association would have to redirect to the registration page.
Tonight i am working on the settings page per authentication type, when that is working i will share the code on github. I looking forward to build twitter, facebook and google authentication asap.
I will also look into how to associate profile information from facebook with a user profile. Thinking about listing the custom attributes on a profile, and then provide a select box with the options that facebook provides. This will allow you to capture all the good stuff that facebook has.
Screenshot of the dashboard attached
It's in approval process from ~november and it seems to work without bugs, even to other users.
Hope it will be approved, as some people may be interested in it.
the only issue I still have with the core login is with the helper functions- like forgot password. I can't figure out how to load the correct controller and call the function. I tried using the __call magic method but still get a page not found error.
Should I just assume that core login is the only one that has these functions?
The other forms that core login is complicating other things too. Any advice appreciated.
I don't think it's safe to assume that core login is the only one with a forgot password. Probably one of the few, but it seems artificially limiting.
Is it ready to get hacked up? I've only looked at the code (not installed), but the first thing that pops out at me is the lack of "extensions". For example, you have 3 (or 4?) "AuthenticationControllers" and none extend others. Maybe I'm missing another class, but I think that thoughtful extending of a core class also solves the "helper function" problem.
However... I'd really like some responses (and consensus) to my detailed post of a month ago (not just from you, from others). For example, I really don't think each "icon" login should get a tab (which seems to be how this package does it). Imagine having FB, LI, Google, Github, etc, etc, etc... all with their own tab (and you know that site owners will go with the "more is better" approach with 3PA plugins).
Similarly... what about registration? I think we're missing any "registration" here as well.
Similarly, ljessup's comment about how this is exposed to blocks and packages.
Really... andrew's doc was a good start, but I don't think there's enough understanding of the big picture or consensus of the details to do much coding before a simple proof of concept.
I don't think thoughtful extension will work because basically you would need to dynamically extend the class, because you don't know what authentication library controller you nee to use.
I think registration should be taken care of actually. The way the core does it with open id seems to be fairly elegant. (but needs the use of those helper functions)
I disagree on the tab login structure. I think its a fairly elegant way to present the data, and it doesn't clutter the screen unnecessarily.
The package situation seems to be fairly straightforward. Am I missing something about it?
Now, in response to your older comment
First, take everything witha grain of salt. Im far from an expert on these authentication systems.
this is pretty much the way the core does it right now with open id. I think thats a good
approach. It just gives you a form with some information already filled out with the info openid provides.
think thats probably about right. you might be able to get by without using tools. Either way, Id say this is a library by library thing, not one that involves the framework.
makes sense. Id think that installing the attribute and not using show attribute on profile would work.
think this is really personal preference. you could probably put up a wrapper with a setting for either one.
the open id plugin gets users to fill in a username for themselves in the sign up process. I think that would be good for most cases.
i don't know if the registration needs to be cluttered with all the buttons. maybe just a link to the button/tab page or something like that.
But not sure if it's really in your plans or not... the URL is 404'd
Here is the post (not sure when it got moved):http://www.concrete5.org/about/blog/open-source-and-strategy/authen...
Obviously that document is a little out of date and the UI would have to conform to our 5.5/5.6 plans. Send me a private message if you'd like to know more.
So are there any updates? Is there any progress that needs testing? We can definitely help with that if there's something to play with.
We have done considerable SSO implementations for some of our large fortune 1000 clients. And could lend a hand in this if still needed