[ZAuth/OAuth/Users] User account policies

[Kaik]

This title might be misleading, if you have a better idea to describe this issue please feel free to update the title.

I'm writing it because on slack it might get diluted and disappear and it is important IMHO. So looking at users table schema we can see what user account policies can be created with this schema.

By user accounts polices I mean a set of rules that are controlling the way accounts are created and how those accounts are treated by the system. The reason I'm writing this is that since PostNuke it has changed. We used to have unique username, then unique email, then duplicate emails and now emails are unique only for authMethod... All below policies are important because some people might need these, policies in most cases are not compatible with each other so policy change on a system, with users already registered might cause issues.

The basic idea behind policy is which field in users table we will use as unique, and how we proceed with other fields.

1. uid - it is unique by default so the simples policy would be to type uid and password - some systems might need this simple policy. Hard to think about an example but all systems where you type your number and password are example of this policy.

2. uname - this is classical login password policy user names are unique.

3. email - policy where uname is not considered to be important in terms of user identification in the system and email address is. In real life this is relatively common policy as an email address is in most cases what we use to identify one user.

4. additional indirectly unique policies - for example current core3 policy that makes emails unique only in conjunction with authentication method. see below* ...

Above are basic policies that can be develop upon. So for example uid or uname policy can have duplicate emails allowed and this can indicate that those accounts belong to the same person (connected via email). Easy account switch can be implemented so single person can act as different users without the need to log out and log in again.

Uname and email can be both required to be unique this way you can use any of those informations to log in to the right account.

*Current option in core3 that restricts email to be unique per authorisation method is quite unusual situation, but fully legitimate as a policy - just unusual IMHO.

The problem I have with this is that I don't think generally website owners want that, and it is actually against commonly expected behaviour. It might be needed in special cases tho. So I don't have a problem with the policy itself but in that it is implemented before more common basic ones.

Most common situation (I think) is that when person uses his email address to identify himself in the system, method that he is using to provide this email address is irrelevant and should point to the same account. So when I use methods -> email or either or facebook or google (assuming same email address) to register an account it should be one account and it should be accessible via any of those methods. That of course in case I use unique email policy. Same email policy also indicates that in Table: zauth_authentication_mapping all methods with the same email are pointing to the same account.

The matter is complicated because many different policies can be created and whole system may react to them differently. For example my current setup is allowing some users to have multiple accounts with the same email, but that can be created only by admin everybody else will have to use unique uname unique email, and all auth methods will point to one account.

[craigh]

First, thank you for writing a carefully thought out post that is logical and thought provoking. I appreciate the extra time you likely took to make sure the post makes sense to us.

I think you have left out a presumption that your points are founded upon and that is that a site will provide multiple methods of authentication. I know this is becoming more common on larger sites (login with google, apple, facebook, etc). But I would say it is quite unusual on most sites on the internet. IMO, most sites provide one method.

I think if you look at Zikula as a platform that works well with one authentication method, then this solves many of the issues presented. Yes, Zikula provides several to choose from, but in the end, a site should only provide one of them.

You are correct in your argument that it doesn't work well when trying to provide multiple methods at the same time. Users end up creating several unrelated accounts with no option to merge them. That is what this ticket was attempting to address.

The system as it stands is a product of choices over time. The issues you raise are valid but would likely require some major changes and BC breaks. Accommodating the needs of a small population of users with existing installations and making the system instantly usable "out of the box" remains a challenge. At one point, I considered dropping ZAuth entirely and requiring the use of OAuth only. This would remove the authentication 'responsibilities' of Zikula but this makes installation more complicated (at least).

A discussion on the matter is always worthwhile, but to be fair, since PostNuke we have had this discussion many times. Reworking the User management is a MAJOR task that very few have been willing to take responsibility - only Robert Burkhead and myself in the last 10 years.

So, any changes this large without BC would of course be scheduled for Zikula 4.0 at least and would need a developer willing to do the work.

[Kaik]

Thank's @craigh for your reply! It actually sums up whole this matter.

At one point, I considered dropping ZAuth entirely and requiring the use of OAuth only. This would remove the authentication 'responsibilities' of Zikula but this makes installation more complicated (at least).

I was actually wondering what was the reason behind ZAuth, it seems not needed at least not for native methods I know its 3 methods but if you look at it its just native either... and all the data needed to log in is in users table. Maybe it looks weird because it evolved from those two methods separated.

From what I see now an easy way to solve all that without too much input is to remove ZAuth and all that reentrant stuff and support only native either, as a main zikula method. In admin we could have a switch just to change the label - "Enter your username" or "Enter you email" or "Enter your username or email" and native either will work with this anyway.

Yes it would be BC so 4.0 etc...

Everything else like facebook and other stuff would have to use their own login register controllers and procedures. This could simplify everything.

I'm actually doing that now on OAuth. I think I will make dedicated module for facebook - will see. I'm in testing stage so have to see if I can reuse the code for google and other ones.

Anyway thank you for your reply it did clarified a lot for me.

[Guite]

ZAuth and custom authentication systems are gone; hence, I'll close this issue