Cool Solutions

GroupWise: Partner Profile – TDP


August 21, 2013 3:46 pm





Novell would like to introduce you to one of our partners – TDP. You may have met them at one of Novell’s events that they sponsor and attend – Open Horizons, GWAVACon or BrainShare. Václav is a very recognizable member of the GroupWise and Novell community. Get to know Václav and TDP.

I would like to introduce you to my guest blogger – Václav Šamša. He has provided the content for this blog and will help me respond to any questions or feedback you provide.

Václav’s Profile

Václav graduated from Czech Technical University, specializing in the design of electrical machines. He is a programmer and co-founder of TDP, TDP-Ontrack, CEALogs and BonPart companies. He has worked with Novell technologies since NetWare ELS II and WordPerfect Office days. He is now focused on GroupWise, GWAVA and all new Novell products like Vibe & FILR.

Vaclav is a proud father of 5 children and he lives with his family in Prague, the heart of Europe.

TDP Profile

TDP was founded in 1988 as a project for top quality software design and coding. The name itself means “factory producing perfect programs” and we are pushing hard to maintain the standard of perfection defined by our company name. TDP is one of the biggest local Novell partners in the Czech Republic. TDP has developed projects like NLM SQL server, tdprcon, and TDP is currently focused on and The KeyShield SSO project is deeply integrated with Novell products. Our goal and top priority today is to overcome NTLM technology of Microsoft, and offer really quick and easy SSO environments for all common client platforms.

Companies and user are utilizing so many different systems and applications that SSO is more important today than ever before. Of course, we have a huge list of options on browser based SSO systems, from open source Shibboleth and CAS to commercial NetIQ’s NAM. If you can live within single browser environment, you are set and we have a solution for you!.

This is why the chromebook is, in fact, a hardware browser. I, personally, like this return to the world of terminals. I started with DEC, HP, and IBM mainframes when PC’s were anything but inexpensive.

The problem is that there are so many browsers and more challenging because these browsers are not able to talk to each other. We have so many desktop clients and apps, which we sometimes need just because we need a local CPU, RAM, storage, and intelligence. The majority of users are still sitting in the office in front of a windows workstation. Even though they are using mobile devices, they still do 95% of their job from a workstation. Because of this, they are authenticating to an eDirectory or an Active Directory environment, which allows them to consume network services.

Ideally, it would be nice to authenticate just once, in the early morning, and then work with any browser and desktop systems without any further login – right?

We received just such a request from our customers in the fall of 2009 and for that reason we have developed the first version of KeyShield SSO. At that time, this product was called WSTrust. Of course, due to lack of time and other resources, it was a simplified version. But it did exactly what was requested.

When you are using a Windows workstation, you are likely using two techniques for authentication.

First – windows workstation is always caching your username and password. Then it tries to use these credentials whenever you try to consume any network service. If this fails, then you get an authentication prompt. Of course, it sounds a little bit crazy, but from the user point of view, it’s perfect and SSO compliant – the only easy thing you have to do is have the same username and password for every thing!

Second – new services and their specialized clients (of course, it’s a browser as well) raised a problem – a browser is not able to get your username and password directly from the desktop OS, it’s such a high risk, that even Microsoft did not implement it. That is why the NTLM authentication came on the scene. Using this protocol, the server can ask your client (desktop) for hashed credentials used for domain authentication. Once the server gets it, it asks the domain server for validation. If it passes, it’s you. For years, this mechanism was a winning force for Microsoft. With NTLM you do not need to authenticate even when you are using Outlook in offline mode. NTLM is implemented for MS SQL, ISA, IIS, Exchange, and Sharepoint … Almost everything is using NTLM. In addition, outside the Windows desktop platform, there is a Safari plugin for NTLM.

Novell is now developing systems, which are able to work with NTLM as well. But what about customers who are using eDirectory, OpenLDAP, SunOne, etc.? What about customers without any directory or domain system? What about client devices which do not support NTLM? We still need a solution for the majority of LAN users, a transparent solution for their desktops, mobile phones, pads etc, regardless of whether they are using Windows, Linux, MacOS X, iOS, Android or BlackBerry. While OpenID is perfect for external users, who are accessing files shared by FILR, we will focus on various aspects of SSO implementation within the company environment.

If this is what you need – stay tuned for another blog post or we encourage you to visit TDP and check out our solutions. We will sponsor another blog with additional content on this topic in the future.

Václav Šamša

1 vote, average: 5.00 out of 51 vote, average: 5.00 out of 51 vote, average: 5.00 out of 51 vote, average: 5.00 out of 51 vote, average: 5.00 out of 5 (1 votes, average: 5.00 out of 5)
You need to be a registered member to rate this post.

Tags: ,
Categories: Expert Views, GroupWise, GroupWise Blog

Disclaimer: This content is not supported by Micro Focus. It was contributed by a community member and is published "as is." It seems to have worked for at least one person, and might work for you. But please be sure to test it thoroughly before using it in a production environment.

Comments are closed.