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.