As per our discussion on Facebook (https://www.facebook.com/ThinLinc/posts/482426561875308) I'd like to suggest a different approach to how profiles are assigned to users.

This is not to say that the current way is "bad" in any way (it definitively has its merits too) ... I just found it a bit awkward at first and I think it could be improved.

As you may know or not there are many commercial + closed source "remote access solution" products out there that in many ways are very similar to ThinLinc (e.g. they too offer a "web top" and remote access to e.g. Linux or Windows desktop sessions). One example of such a product that I happen to know very well (due to historical reasons and my former employer being a former SUN partner) is this one:

Sun/Oracle Secure Global Desktop:
http://en.wikipedia.org/wiki/Secure_global_desktop


There are several "problems" with that software:

- it's an ORACLE product ;-)
- it's as much "closed source" as it possibly could ever be
- licenses cost a fortune
- it is widely used, especially by former SUN customers / current ORACLE customers, especially those who also use ORACLE's "Sun Ray" / "Oracle VDI" software and thin client products ("SGD" serves as web interface for those products)


As you guys already are in the business of "freeing" former ORACLE customers from their proprietary "Sun Ray" thin client solution ... why not expand to this area as well? Your current ad campaign on your web site only mentions "Sun Ray" users ("... Looking to replace your existing Sun Ray installation? ..."). But there are many many "SGD" users out there too.

Yes, ThinLinc totally can replace the "Sun Ray" solution (been there, done that). But it could also just as easily replace the "Secure Global Desktop" solution.

The only problem here is that ThinLinc's profile editor should be a bit closer to what these "SGD" users are used to? If it's too different from what they expect it will put them off ... which is a shame, ThinLinc is a very good and solid product and everyone who's got a "SGD" installation should give it a closer look.


Now, as for editing profiles:  As I said above ... these are just suggestions. In my opinion implementing them would help win over many of the current "SGD" users. So I will go ahead and simply explain how things are done in "SGD" ... and you can think of implementing such a feature in ThinLinc too ... or not :D


1.) Application list: Which user has access to which applications?

SGD uses a LDAP-like database internally (it's not really LDAP but its structures resemble LDAP very much) so that this kind of relationship is easy to establish. You have an internal category "Applications" and to that you can add sub-categories (shown as sub-folders) and name them whatever you wish, e.g. "MY-USERS". You can then create application objects ... and taddaaa, the users in question get an icon they can click on and launch programs when they login. ThinLinc solves this with the "test-script" section ... IMHO the approach SGD uses is much more elegant and user friendly.

Screenshot of the Admin UI showing the available applications for the group "MY USERS":
https://dl.dropboxusercontent.com/u/1614648/tmp/SGD1_Apps-List.jpg



2.) Application details: Defining what an application icon is supposed to do

In the previous screenshot there was an entry for "VDI Session". Clicking on that entry leads to this part:

https://dl.dropboxusercontent.com/u/1614648/tmp/SGD2_Apps-Details__General.jpg

Here I can define what an application is supposed to look like (e.g. icon), I can rename it, etc.



3.) Application launch details:  Defining how exactly an app is launched?

In that previous screenshot were multiple tabs: "General" and "Launch" and many others. So here I went to the "Launch" tab and here I can define the path to the executable or the session I want to provide. This is very very similar to the web-based profiles editor in ThinLinc.

The screenshot shows the properties of a RDP session object:
https://dl.dropboxusercontent.com/u/1614648/tmp/SGD3_Apps-Details__Launch.jpg



4.) Assigned users:  Who's got access to that application?

And finally this tab can answer the question which users have access to this. "SGD" is able to communicate to LDAP and Active Directory servers, it can also use local UNIX users. In this example we're talking to a Windows 2008 R2 AD server:

https://dl.dropboxusercontent.com/u/1614648/tmp/SGD4_Apps-Details__Assigned-Users.jpg



5.) User Profiles

An different section: User Profiles. Which users do I even have in this installation? Again ... everything is very LDAP-like, although I am only displaying local users (setting "Repository: Local" on the right side of the screen).

https://dl.dropboxusercontent.com/u/1614648/tmp/SGD5_User-Profiles__Overview.jpg


When setting the "Repository" to "Local + LDAP" I can dig deeper in the LDAP or AD server's structures:

https://dl.dropboxusercontent.com/u/1614648/tmp/SGD6_User-Profiles__LDAP_CN-users.jpg


I can click on a user, e.g. CN=sysadm ... and take a look what applications he'd have access to:

https://dl.dropboxusercontent.com/u/1614648/tmp/SGD7_User-Profiles__App-Assignments.jpg



To get back to our Facebook discussion after showing all these screenshots:

As you can see: With this UI approach I can easily find out which user would have access to which application and which application would be reachable for which user profile.

The key here is this LDAP-like internal mini-DB where SGD keeps track of all these relationships. "User A has access to application B" or "application B is available to user A" is pretty much the same query (A=B, B=A ... same thing!).

IMHO it would greately add to the user friendliness (and adoption too?) of ThinLinc if editing user < > session type relationships were possible in a similar manner?


Again, these comments are just suggestions based on my own experience with both products :-)


Kind regards,

DJ.