Hi!
I just added support for SASL authorization identities to my client
connection manager (jadc2s). This allows to authenticate as an admin
user to the Jabber server, but to authorize as someone else.
I'd now like to know if there is already a client, that supports having
a different authorization identity. Currently I could only test this
feature using telnet and sending the XML myself.
Matthias

I just added support for SASL authorization identities to my client
connection manager (jadc2s).
of curiosity: are there other servers supporting this ?
cheers,
Remko

No, that's not what I am looking for. I know enough clients, that have
support to authenticate using SASL. But they all transmit no
authorization id, and therefore they authorize as the same identity as
they authenticate.

SASL has the concept of authorizing as someone else as you
authenticated. But this does not seem to be supported by any Jabber
client yet. E.g. the user admin (AT) example (DOT) com could have the right to
authorize as user (AT) example (DOT) com. In that case the user admin (AT) example (DOT) com
would have to provide "admin (AT) example (DOT) com" as the authentication id, the
password for the user admin (AT) example (DOT) com, and "user (AT) example (DOT) com" as the
authentication id. But it would NT have to know or to provide the
password for user (AT) example (DOT) com.

this is a nice feature. I would be interested to add support for that in
agsXMPP, and also add it to my test.

Alex

Hi Alexander!

Alexander Gnauck schrieb:
this is a nice feature. I would be interested to add support for that in
agsXMPP, and also add it to my test.

Cool. I'd like to see this SASL feature having more widespread support
in Jabber implementations.

Matthias

26 Jul 2006, at 9:15, Matthias Wimmer wrote:

Cool. I'd like to see this SASL feature having more widespread
support in Jabber implementations.

I agree on the server side. However, this feature is handy for
administrators (of big servers), but that's where it stops, isn't
it ? a client that wants to implement everything would be
interested in implementing this, but i don't think most client want
to provide that feature to their users (it's confusing to have a
username and a login as).

cheers,
Remko

Hi Remko!

Remko Troncon schrieb:
I agree on the server side. However, this feature is handy for
administrators (of big servers), but that's where it stops, isn't it ?
a client that wants to implement everything would be interested in
implementing this, but i don't think most client want to provide that
feature to their users (it's confusing to have a username and a login as).

We have clients that support other admin functionality as well. Even
features like setting a message of the day, that is not even standardized.
Some clients separate the essential settings from expert-settings. The
authorization identity could be one of these expert-settings.

Also I don't think, that this feature is admin-only. This was only an
example I gave. Let me give another example: There could be an account
sales (AT) example (DOT) com where all people of the sales departement of example
corp. will be allowed to authorize as. So that customers can send a
Jabber message to this address and will get a response from one of the
example corp. sales people.
Having individual authentication identities for these people will allow
to delete someones access to this JID when he changes the departement or
leaves the company without the need, that the other people having access
to this JID have to reconfigure anything (setting a new password).

Matthias

26 Jul 2006, at 08:25, Remko Troncon wrote:

26 Jul 2006, at 9:15, Matthias Wimmer wrote:
>
>Cool. I'd like to see this SASL feature having more widespread
>support in Jabber implementations.
>
I agree on the server side.

Just to add - I've got patches implementing this feature for jabberd2
(where
we use it to deal with JIDs that can't have matching Kerberos
identities)

Cheers,

Simon.

Even features like setting a message of the day, that is not even
standardized.

Don't get me started on that one ;-)

Some clients separate the essential settings from expert-settings.
The authorization identity could be one of these expert-settings.

You're right, your other example makes sense to me as well, there
might be a broader interest. Are there servers with which clients can
test authzid support ?

cheers,
Remko

Matthias Wimmer schrieb:
Also I don't think, that this feature is admin-only. This was only an
example I gave. Let me give another example: There could be an account
sales (AT) example (DOT) com where all people of the sales departement of example
corp. will be allowed to authorize as. So that customers can send a
Jabber message to this address and will get a response from one of the
example corp. sales people.
Having individual authentication identities for these people will allow
to delete someones access to this JID when he changes the departement or
leaves the company without the need, that the other people having access
to this JID have to reconfigure anything (setting a new password).i

i totally agree with Matthias, this is a very good point and use case.

Alex