Auth layer refactoring

[fenek]

The idea for a new auth layer involves following concepts:

• Auth DB - responsible for access to auth data but doesn't deal with the auth process (except for check_auth_data function required by some methods)
• Auth method - authorisation logic itself; uses data provided by auth DB; uses exactly one SASL mechanism
• SASL mechanism - SASL logic used by auth method. Not configurable by user.

So configuration-wise following aspects will change:

• Auth backends will still be configurable in similar manner, except for...
• No auth_opts tuple, every method or backend will have its options provided in the same tuple
• No direct SASL mechanisms configuration. They will be enabled by choosing proper auth methods.
• New tuple for enabling auth methods.

For one major release there will be a compatibility layer that will forward calls from new API to classic ejabberd_auth. We also need to provide migration scripts for Mnesia, RDBMS and Riak because...

I thought about storing auth data for these backends in new tables. It will spare us creating extra logic in new implementations to handle both old and new format. New tables will store following columns/fields:

• luser
• lserver
• data_type
• auth_data

Where data_type for now will have following values (may be int instead of string):

• scram_sha1_password
• certificate
• token
• jwt(?)

I'm pretty sure I haven't covered all aspects of such refactoring but I'd like to hear from you, what do you think about the idea in general. What are your ideas, thoughts, doubts? :)

[bartekgorny]

The idea seems fine, except for I wouldn't change the db structure. The benefit from it is limited, since we rarely have to implement new auth method, while the hassle in updating production installations will be significant.

[bartekgorny]

I'd also suggest a general rule "one major refactoring per release". This one would then saturate the spring one.

[erszcz]

1. How does this play together with non-local authentication mechanisms? I mean what if we want an integration with an external identity provider / authentication service for users logging in to the XMPP system? I'm not sure how the refactoring affects this.

2. Somewhat related to the above, but still not the same thing - the idea behind mongoose_credentials and the auth backend authorize() function was to enable the authentication/authorisation service to also return extra user information or capabilities. These could be used immediately, like a JID/resource for the session, or stored in #session.info to govern server behaviour for the session (for example, require regular reauthentication and terminate sessions which do not reauthenticate). We already have use cases for this. Does the refactoring touch this aspect?

3. What is the token store type used for? If it's just the so called SASL X-OAUTH mechanism, then I suggest dropping it and providing our users a way of switching to JWT instead (probably just a tutorial / article about the change and one version of deprecation period).

[chrzaszcz]

No activity for a long time. We could come up with a new concept for the auth rework, but it could be done in internal JIRA tickets. Anyway, the auth layer has gone through some refactoring already.