#81: support for user authorization
------------------------+---------------------------------------------------
Reporter: sxw | Owner: smoku
Type: enhancement | Status: new
Priority: major | Component: sm
Version: 2.1 | Resolution:
Keywords: | Blocking:
------------------------+---------------------------------------------------
Comment (by 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.
--
Ticket URL: <http://jabberd2.xiaoka.com/ticket/81#comment:5>
jabberd2 <http://jabberd2.xiaoka.com/>
jabberd2 project
_______________________________________________
jabberd2 mailing list
[email protected]
http://lists.xiaoka.com/listinfo.cgi/jabberd2-xiaoka.com
