[jitsi-users] SSO for Jitsi


#1

Hi all,

We've been rolling our jitsi quite nicely in our organisation via group policy but one part of it that we've not been able to find a solution to is some form of an SSO method. That is, instead of the user having to manually setup their account when jitsi runs, it would be great to have the users credentials that they are logged onto the computer with (AD) fed into Jitsi to auto authenticate them/sign them in.

We have previously used Spark for IM which had this feature (SSO) but it's video chat side of things leaves a lot to be desired in comparison to Jitsi.

We're running an Openfire server which has an LDAP sync with active directory for the account side of things.

Has anyone managed to find a solution to this?


#2

Please do not assume everyone knows what each acronym stands for. I
for one have no clue what SSO stands for. So you only save a few bytes
by using an acronym but leave some people in the dark.

TIA.
FC

···

On Wed, Jun 15, 2011 at 00:45, Matthew Reymond <mattr@scottparkgroup.com.au> wrote:

to find a solution to is some form of an SSO method.


#3

Hey Matthew,

На 15.06.11 05:45, Matthew Reymond написа:

Hi all,

We’ve been rolling our jitsi quite nicely in our organisation via group
policy but one part of it that we’ve not been able to find a solution to
is some form of an SSO method. That is, instead of the user having to
manually setup their account when jitsi runs, it would be great to have
the users credentials that they are logged onto the computer with (AD)
fed into Jitsi to auto authenticate them/sign them in.

We've never really looked into integrating SSO although it seems like a
practical feature. We may work on it at some point and would of course
be more than happy to integrate a patch.

Until then however, isn't online provisioning going to be a better
option for you? You can configure all your Jitsi instances to provision
against a central server of yours that could feed to them things every
single property from account properties to things like where to update
from.

How does this sound?

Emil


#4

Thanks for the response Emil, would be great to have the feature out of the box so to speak.

Sorry Fernando, I sort of tried to explain what SSO is (it stands for Single Sign On). Basically it means the user signs on (logs onto their computer) once and the software uses the credentials that they logged on with to authenticate with. So instead of the user having to sign into the computer, then sign into the application with the same credentials they just sign on once and the application starts working. The user experience is much better this way as they're not prompted for credentials all the time.

To date, I've been using a group policy to copy over a pre-configured "sip-communicator.properties" file from a central fileserver to the users %APPDATA% folder on logon. This has a fair chunk of the settings configured for the user (start on logon, change status after 10 minutes away etc). This seems to work well and is basically why we haven't look at provisioning as I believe it gives the same sort of functionality? The problem is that the user still has to enter in their credentials at least one and then they have to update them when their AD password expires or is reset (something SSO takes care of).

In the Advanced settings setting of Jitsi I see that there is an LDAP configuration menu - what functionality is gained by using this?

Regards,

Matt


#5

На 15.06.11 10:40, Matthew Reymond написа:

To date, I've been using a group policy to copy over a pre-configured
"sip-communicator.properties" file from a central fileserver to the
users %APPDATA% folder on logon. This has a fair chunk of the
settings configured for the user (start on logon, change status after
10 minutes away etc). This seems to work well and is basically why we
haven't look at provisioning as I believe it gives the same sort of
functionality?

Provisioning lets you configure _all_ account params, including the
passwords. The provisioning plugin would make sure that the passwords
retrieved from the on-line service are encrypted using the user's master
password.

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.

In the Advanced settings setting of Jitsi I see that there is an LDAP
configuration menu - what functionality is gained by using this?

It's basically an on-line address book. It allows users to search for
contacts that they can call or add to their address book.

Cheers,
Emil


#6

Hey

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.

Regards
Ingo


#7

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.

Regards,

Matt Reymond

···

-----Original Message-----
From: Bauersachs Ingo [mailto:ingo.bauersachs@fhnw.ch]
Sent: Wednesday, 15 June 2011 5:16 PM
To: users@jitsi.java.net
Subject: [jitsi-users] Re: SSO for Jitsi

Hey

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.

Regards
Ingo


#8

На 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.

Cheers,
Emil

···

Regards,

Matt Reymond

-----Original Message----- From: Bauersachs Ingo
[mailto:ingo.bauersachs@fhnw.ch] Sent: Wednesday, 15 June 2011 5:16
PM To: users@jitsi.java.net Subject: [jitsi-users] Re: SSO for Jitsi

Hey

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.

Regards Ingo

--
Emil Ivov, Ph.D. 67000 Strasbourg,
Project Lead France
Jitsi
emcho@jitsi.org PHONE: +33.1.77.62.43.30
http://jitsi.org FAX: +33.1.77.62.47.31


#9

Hi everybody,
I am not sure if this is the right list for this...
I just wanted to say that I finished the translation in Greek and
uploaded all the stuff to the translation page
(http://translate.sip-communicator.org/)

I tried to see how to embed (=incorporate) the Greek translation into Jitsi.
Not being a programmer and not knowing anything about Java syntax, I was
unable to do it.

Can anybody give me some clues about the right way to do this ???

Thanx!

Constantine


#10

Hi Emil

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 implementation.

···

-----Original Message-----
From: Emil Ivov [mailto:emcho@jitsi.org]
Sent: Monday, 20 June 2011 6:21 PM
To: users@jitsi.java.net
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.

Cheers,
Emil

Regards,

Matt Reymond

-----Original Message----- From: Bauersachs Ingo
[mailto:ingo.bauersachs@fhnw.ch] Sent: Wednesday, 15 June 2011 5:16
PM To: users@jitsi.java.net Subject: [jitsi-users] Re: SSO for Jitsi

Hey

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.

Regards Ingo

--
Emil Ivov, Ph.D. 67000 Strasbourg,
Project Lead France
Jitsi
emcho@jitsi.org PHONE: +33.1.77.62.43.30
http://jitsi.org FAX: +33.1.77.62.47.31


#11

Hey Constantine,

На 20.06.11 21:28, Kostas Mousafiris написа:

Hi Emil, I am sorry to disturb inappropriately but I was not sure
whom to contact anyway...

You've come to the right place :wink:

I just wanted to notify that I finished the translation in Greek and
uploaded all the stuff to the translation page
(http://translate.sip-communicator.org/)

Awesome! I've just committed it! Thanks! You should be able to upload
them personally from the user interface from now on.

Cheers,
Emil

···

I tried to see how to embed (=incorporate) the Greek translation into
Jitsi. Not being a programmer and not knowing anything about Java
syntax, I was unable to do it.

Can anybody give me some clues about the right way to do this ???

Thanx!

Constantine

--
Emil Ivov, Ph.D. 67000 Strasbourg,
Project Lead France
Jitsi
emcho@jitsi.org PHONE: +33.1.77.62.43.30
http://jitsi.org FAX: +33.1.77.62.47.31


#12

Something probably went wrong. Many language resources were updated but
there is no resources_gr.properties yet.

Cheers,
Andreas

···

Am 20.06.2011 21:31, schrieb Emil Ivov:

Awesome! I've just committed it!

---

$ svn update
U src/net/java/sip/communicator/service/httputil/HttpUtils.java
U resources/languages/resources_ja.properties
U resources/languages/resources_id.properties
U resources/languages/resources_el.properties
U resources/languages/resources_ar.properties
U resources/languages/resources_cs.properties
U resources/languages/resources_si.properties
U resources/languages/resources_pl.properties
U resources/languages/resources_ro.properties
U resources/languages/resources_pt.properties
U resources/languages/resources_ru.properties
Aktualisiert zu Revision 8730.


#13

There was a resources_el.properties though (r8721).

-- sent from my mobile

···

On Jun 20, 2011 10:33 PM, "Andreas Kuckartz" <A.Kuckartz@ping.de> wrote:

Am 20.06.2011 21:31, schrieb Emil Ivov:

Awesome! I've just committed it!

Something probably went wrong. Many language resources were updated but
there is no resources_gr.properties yet.

Cheers,
Andreas
---

$ svn update
U src/net/java/sip/communicator/service/httputil/HttpUtils.java
U resources/languages/resources_ja.properties
U resources/languages/resources_id.properties
U resources/languages/resources_el.properties
U resources/languages/resources_ar.properties
U resources/languages/resources_cs.properties
U resources/languages/resources_si.properties
U resources/languages/resources_pl.properties
U resources/languages/resources_ro.properties
U resources/languages/resources_pt.properties
U resources/languages/resources_ru.properties
Aktualisiert zu Revision 8730.


#14

Oh yes, sorry.

ISO 639-1 for Greek = el
ISO 3166 for Greece = GR

Cheers,
Andreas

···

Am 20.06.2011 22:40, schrieb Emil Ivov:

There was a resources_el.properties though (r8721).