support for user authorization

[sxw]

At the moment the authreg plugin system doesn't have any support for authorization. Whilst user_exists() could be used as an authorization mechanism, there are situations where it is appropriate to know that a user exists in the authentication database, but not to allow them to access a service. The authorization check should also be seperate from any password checks, so that users which are authenticated through mechanisms that don't use passwords (such as SASL GSSAPI or EXTERNAL) can also be authorized.

An authorization system could be used with any of the authreg backends that use an external datasource such as PAM (where calling the pam_account stack would be appropriate) or LDAP (where the user's membership of a particular set of LDAP groups could be verified).

I'd like to propose creating a new authreg callback to provide authorization. As always, I'm happy to write the code if this approach sounds reasonable.

[smoku]

Authorisations does not belong in C2S. With SASL you may authenticate as different ID, than then authorise yourself in SM. This should be handled by SM at the session bind request.

And I do agree that specifying authentication <-> authorisation mappings in SM is usefull. And using a specific error condition for a mapping (allow, specific error) could be used for disabling specific users for access to specific domain.

[sxw]

Surely all of the connection authentication & authorisation happens before the SM is started? The user needs to either be authenticated and authorised, or rejected, as part of the initial stream authentication handshake - so the authorisation has to happen at the c2s layer. By the time the sm is invoked with the bind request, the stream is already authenticated - and the only thing that's being requested there is tying a particular JID to the request.

From a jabberd2 architecture point - the authreg layer is the logical place to do authorization. For instance, even for users authenticated via GSSAPI or EXTERNAL, the pam account layer should be called when the PAM authreg module is in use. Either both c2s and sm need to have access to PAM (and there needs to be a way or passing PAM handles between the two processes - which is not pretty)), or all of the PAM calls have to happen from the same process.

[sxw]

s/JID/resource in the first paragraph of the above.

[smoku]

Not quite right.

The SASL authentication happens at the begining.

Once the stram is authenticated (we know who is connected), there is a JID bind and session start offers. And these are the things we authenticate. It's not up to C2S to decide whether the authenticated ID is allowed to bind to a specific SM (we might have many on the router and user is allowed to bind other JID that was authenticated).

So it's SM that replies to a JID bind request with a full JID or with an not-allowed error.

[sxw]

Okay - this is getting into the lack of clarity of RFC3920's description of the SASL process. It may be worth raising this on the standards list.

My experience, both of XMPP, and other other SASL using protocols, is that when a protocol responds with success to a SASL negotiation, it is indicating both that the authentication succeeded, and that any required authorization has also succeeded.

In particular, see section 3.6 of RFC4422 - "Authentication Outcome" which states ...

The outcome is not sucessful if 
[ ... ]
- the identity associated with the client's credentials is not authorized 
to act as the requested authorization identity

So, responding with <success> to the SASL handshake indicates that we have already determined that the client is allowed to act as the authorization identity they've requested.

I think also that the resource binding language of RFC3920 indicates that if we receive

<iq type='set' id='bind_1'>
    <bind xmlns='urn:ietf:params:xml:ns:xmpp-bind'/>
</iq>

we MUST generate a resource identified for that client - so we can't send a <not-authorized> at this point.

I agree that having a list of permitted authentication identifiers for a give JID stored with the rest of that JID's data in the sm process would be nice - but I think we need to do so by allowing the c2s and sm modules access to the same database, rather than putting authorisation into the sm process.

[smoku]

I've reread through the thread once again and now I do agree with you.

+1 let's do it.