Prosody currently supports only authentication (identification of users, e.g. by password or tokens). What is missing are authorization providers (allowing identified users to do certain actions, e.g. login!).
This is especially important for the cyrus authentication provider. SASL is, as the name implies, an authentication provider, and only an authentication provider. Just because a user is able to present a valid Kerberos ticket of my companies realm, doesn't mean she has also access to the Server.
This new authorization provider should then also replace the 'admins' configuration.
Zash
on
Authentication providers can already influence the admin status by way of providing an 'is_admin' method, eg like <http://modules.prosody.im/mod_auth_ldap2.html>. Development of authentication providers is unfortunately poorly documented, we're sorry about that.
Does this cover your needs?
Skruppy
on
Sorry, the 'is_admin' method is only suitable for some authentication providers. But for example cyrus can, by design, only be used for authentication (A valid Kerberos ticket or it's client certificate only says "Hi I'm Jon" but not "... and I'm allowed to login").
As for most software, a separation of authentication and authorization is also for prosody a good idea. Because the used methods can be completely different. Using LDAP for authentication doesn't mean I want to use it also for authorization. Maybe I want to use something like mod_authz_static (which could use the configuration variable 'admins' for white listing admins and two others for black and white listing users) or mod_authz_ldap (as in the current mod_auth_ldap2) or mod_authz_nss (which could check linux group memberships) or mod_authz_mysql (for checking an simple table, filled by a simple web front end) or mod_authz_file (for checking a simple text file, filled by even simple bash scripts) or mod_authz_exec (for checking the return value of a script) or mod_authz_random (to annoy users or test a system :) or ....
You see, there are n times m (useful) combinations of authn and autz providers. It's not matter whether an authentication provider can also provide authorization, more a matter whether it should.
MattJ
on
We're going to finally take a run at this soon! (at least laying the framework for authz providers).
Changes
owner MattJ
tags Status-Accepted
MattJ
on
Ok, mod_authz_* modules supported in trunk as of this commit: https://hg.prosody.im/trunk/rev/d1cc6af0fb97
Currently it just exposes a prosody:admin role that behaves just like the previous code did. If we want to extend this, let's do that in small steps and new tickets.
I'm going to mark this one as fixed. Thanks!
Prosody currently supports only authentication (identification of users, e.g. by password or tokens). What is missing are authorization providers (allowing identified users to do certain actions, e.g. login!). This is especially important for the cyrus authentication provider. SASL is, as the name implies, an authentication provider, and only an authentication provider. Just because a user is able to present a valid Kerberos ticket of my companies realm, doesn't mean she has also access to the Server. This new authorization provider should then also replace the 'admins' configuration.
Authentication providers can already influence the admin status by way of providing an 'is_admin' method, eg like <http://modules.prosody.im/mod_auth_ldap2.html>. Development of authentication providers is unfortunately poorly documented, we're sorry about that. Does this cover your needs?
Sorry, the 'is_admin' method is only suitable for some authentication providers. But for example cyrus can, by design, only be used for authentication (A valid Kerberos ticket or it's client certificate only says "Hi I'm Jon" but not "... and I'm allowed to login"). As for most software, a separation of authentication and authorization is also for prosody a good idea. Because the used methods can be completely different. Using LDAP for authentication doesn't mean I want to use it also for authorization. Maybe I want to use something like mod_authz_static (which could use the configuration variable 'admins' for white listing admins and two others for black and white listing users) or mod_authz_ldap (as in the current mod_auth_ldap2) or mod_authz_nss (which could check linux group memberships) or mod_authz_mysql (for checking an simple table, filled by a simple web front end) or mod_authz_file (for checking a simple text file, filled by even simple bash scripts) or mod_authz_exec (for checking the return value of a script) or mod_authz_random (to annoy users or test a system :) or .... You see, there are n times m (useful) combinations of authn and autz providers. It's not matter whether an authentication provider can also provide authorization, more a matter whether it should.
We're going to finally take a run at this soon! (at least laying the framework for authz providers).
ChangesOk, mod_authz_* modules supported in trunk as of this commit: https://hg.prosody.im/trunk/rev/d1cc6af0fb97 Currently it just exposes a prosody:admin role that behaves just like the previous code did. If we want to extend this, let's do that in small steps and new tickets. I'm going to mark this one as fixed. Thanks!
Changes