A quick note in case anyone would be interested in contributing support
for SSO in Jitsi.
As far as BlueJimp is concerned we'll probably do it at some point but
the exact would depend on resources, funding and/or customer demand.
-------- Оригинално писмо --------
Тема: [jitsi-users] Re: SSO for Jitsi
Дата: Thu, 23 Jun 2011 09:00:16 +0000
От: Neil McIntyre <Neil@scottparkgroup.com.au>
Отговор до: firstname.lastname@example.org
До: email@example.com <firstname.lastname@example.org>
I'm glad that you see the value in this; the lack of SSO makes it a slow
and painful roll out to our users.
Would you be so kind as to pass this suggestion on to the Dev list? I
think it's more likely that someone would volunteer to patch there than
on the users list.
For reference, the Spark client has a very simple and effective SSO
From: Emil Ivov [mailto:email@example.com]
Sent: Monday, 20 June 2011 6:21 PM
Cc: Matthew Reymond
Subject: [jitsi-users] Re: SSO for Jitsi
На 20.06.11 11:00, Matthew Reymond написа:
Sorry for the delayed response here;
Ingo is spot on, in a Windows/AD SSO environment we have a Domain
Controller which handles the authentication side of things for the
user logging onto the PC that has Jitsi installed on it. Openfire
also syncs with the Domain Controller such that the accounts are all
automatically created in Openfire once setup on the Domain.
Therefore we can't really extract the password of the user and
provision it to them as such.
What we really want is an encrypted trust setup that Jitsi can use to
pass the existing Kerberos ticket through to the DC to authenticate
with the credentials that the user is logged on with.
I understand. Well this does sound like something that's worth
implementing. We'll keep it in mind. Of course patches are always welcome.
I personally believe this is a better option than SSO since it
allows administrators to provision both account credentials and
account properties rather than having to maintain two separate
mechanisms to handle them.
That is impossible in most SSO scenarios: Usually the server doesn't
even know the user's password. When Matt talks about AD and Group
Policy, then he's using a Windows Domain and probably a Server that
authenticates the user with his Windows Credentials using the
so-called "integrated authentication" (SSPI).
In this regard, the request is to reuse the Windows Credentials for
Sign-On, either by using Kerberos (preferably) or NTLM (if need be).
Of course that all depends on the (SIP)-Server being used as well.