Novell makes a number of products to solve the problems users experience in their day to day operations, in regards to logging in to various services. Geoffrey Carman explains how he uses Novell's password management software to create a single sign on for improved productivity and security.

There are basically two basic issues, and a couple of approaches to resolving each.

Usually as a consultant, I end up focusing on the first of the two problems, which is trying to keep all the passwords and accounts in sync, within the various back end systems.

For this purpose, Novell Identity Manager is a great fit, as it can connect all sorts of different systems together, and when the connected system allows it, synchronize the passwords.

Novell Identity Manager has well over a dozen different drivers, and there are numerous third party drivers. You can see a list of some of the drivers, in this article about association values: http://www.novell.com/communities/node/1696/open-call-idm-association-values-edirectory-objects

While the above article is about what value each driver uses to uniquely identify objects in the connected system, as a side effect it happens to also list many of the available drivers. If you happen to be a developer and have your own driver for Novell Identity Manager, and it is not listed in my article, please let me know so I can add it!

You can see the wide diversity of systems supported. The major email systems (Exchange, Lotus Notes/Domino, GroupWise) are supported, as are the major HR applications (SAP HR and Peoplesoft). Many other systems like Linux Unix systems running NIS, NIS or just plain standalone can be integrated, along with Mainframes (IBM z Series hardware) and midrange boxes (IBM AS400 or i5os servers).

Additionally, there are a number of generic drivers like the SOAP, JDBC, LDAP, Delimited Text, and Scripting drivers that can connect many different systems with each driver.

For example the LDAP driver can connect most well-known LDAP servers out there in the market. Thus one driver really supports ten or more different connected systems. The same is true for the JDBC Database driver, where many different databases that have JDBC database drivers (JDBC is the Java approach to OBDC, for generic database access) are supported by one actual driver from Novell.

Then there are the Delimited Text drivers, one of the least common denominator drivers. If you can get your connected system to dump to a CSV or other format text file, then you can connect to it. It is amazing how many system administrators would prefer to use this approach over any other.

The SOAP driver is nice and generic for systems that have exposed web services, which talk SOAP. This lets you connect to many web based systems, like Salesforce.com or Google Apps, if you needed too.

Finally when all else fails, if there is a command line way to do it, then you can run the Scripting driver on Windows, Linux, or Unix and write your own scripts to manage the connected system.

With all these options, you should be able to connect to pretty much whatever you need too.

Once you have all these connections in place, then the back end can keep all the accounts in sync. This is great, since as you hire someone they get all the accounts they need, and best of all when you have to let them go, you know you killed all their access to accounts managed this way.

We often find that the selling point for doing this back-end integration is that last reason, making sure everyone's access is revoked when they are let go.

What is even better is when you can synchronize passwords as well as other attributes. Passwords are always tricky. The connected system needs some way of sending password change events, with the actual password. In the case of Active Directory (and SunOne LDAP) the password is known in clear text at the moment it is changed, by the server (Domain controller in the Active Directory case) on which the change is taking effect.

Thus for Active Directory and SunOne you need to install a small password filter that catches the events and forwards them on. Other systems like eDirectory, Linux (with NIS or NIS ), or AS400 can send on the password, without any additional filters required.

However, in some systems, they can only accept passwords (Subscriber channel) and not send out password changes from the system (Publisher Channel). This is very frustrating, but is something to be lived with, since that is how the application works.

In the case of Lotus Notes it gets really annoying, and once you understand why the passwords can never be captured based on how the system works, it is more tolerable. In Lotus Notes, you log in by presenting a ID file, that contains the RSA private key for your account. It is encrypted with a password, since you leave local copies lying around in your files system on computers using the Lotus Notes client.

What is interesting, is that you can have three copies of the Notes ID file, with different passwords on each of them, and all three are perfectly valid to login, since each password decrypts its specific file, to get the private key out to login.

The downside is the Domino server has no clue what your password really is. It just cares that the ID file decrypts a valid ID file. This is basically an intractable problem, and just has to be accepted. However there are tricks to make things better.

On top of all the great options for connecting systems, you can add an additional layer of entitlements, such that users get some accounts automatically, since everyone in the company needs certain access. But only people in Accounting need access to the Mainframe for certain job functions.

But what about the times where a user is not in Accounting, but has a valid job function that needs access? Well then we have the User Application, that lets us use a Provision Request to ask for access. We usually know who everyone's manager is, so the workflow that gets started by the user's request for more access can route to their manager, possibly their manager's manager, or any which way you need, to get as complicated an approval policy as you need.

The other use for this is, after all the effort of automating everything so that people are taken out of the loop, we still need to get people back in the loop in order to have a human being responsible for the action of approving some kind of access.

Thus with Provisioning, we can shove people back into an automated system, in an automated way, and track who has approved what.

That's the first problem, getting everything connected, synced, and ready to roll on the back end.

But how much does that help the end user? Well there is a great benefit of knowing that if you change your password in one system, then the password will change in all the other systems. That is actually a pretty big win, and while the user might have to login to five or ten different systems over the course of the day, they at least are still using the same username and password combination. This is a big win over five or ten different passwords to remember and track.

Yet, even this is not enough, and we get into the second major issue. Let's make it easier on the end user every day.

In this space, Novell has two different approaches, depending on the problems you are facing.

If your applications are web based, as more and more applications are becoming, then Novell Access Manager is a great choice for you.

You can see this in action at Novell.com. If you go to any page on Novell.com, there is almost always a Login button in the header at the top. If you go to a resource that needs a logged in account, say Customer Center to look at your products you have bought from Novell or to find a license code, or even to the support forums, and want to post a message, you will get sent to a common login page. Once you login on that single page, the browser remembers that you have been logged in, and when you get to, say, Cool Solutions, you get the logged in view, showing your inbox, workspace, and so on.

This way, you can do web based single sign on. (Web SSO).

What is nice about Novell Access Manager is that it supports many different authentication types, so if you want to do something more secure than just username and password combinations, then you can. There is support for RSA Tokens, X.509 PKI Certificates, smart cards, other tokens, and proximity cards.

This way, you can have different levels of authentication for different resources. Maybe your email system only needs a username and password combination (something you know), but when you want to start looking at financial information via your web application, you can require an RSA Token (something you have) or some kind of biometric (something you are)

This makes securing your network in rational ways much more doable. Really, does everybody in the company need an 'expensive' RSA token to login to run Word on your Citrix server? Or just the people who need to connect to a mainframe hosted application that does not support anything other than username and password combinations. Well you can layer on additional security to require something that the application itself does not support using Novell Access Manager.

However this only covers applications that use the web as their primary interface. Which to be fair, in this day and age, includes more and more applications. But still not all.

To handle Single Sign On for desktop thick clients, there is Novell SecureLogin. This is a really great product that is very powerful. Out of the box, it can handle many dozens of applications. As soon as a login window pops up, it fills in the username and password for the application and click ok, login, Next, or whatever.

From the user perspective, they double-click to launch the app, the login window flashes by and suddenly they are logged in.

For one particular client, we setup a href="http://www.novell.com/products/identitymanager/">Novell Identity Manager to link their AS400 retail system, their Lotus Notes email system, Novell NetWare file and print system, with Active Directory for domain logins.

That was just the first step. What that means to them is that once a user is created by the Helpdesk (we did not integrate their HR system at this point), they immediately get Active Directory, eDirectory (for NetWare) accounts.

Then they have two entitlements for Lotus Notes and AS400. Which once they are added to the user (or taken away) an account is provisioned (or disabled).

However that makes the life of the Helpdesk easier, as they only have to create a single account instead of manually creating three or four accounts. For that reason alone it is worth the cost of implementing this solution.

However there is great synergy in using the various products together, since on top of a 'simple' Identity Manager configuration, they also added Novell SecureLogin.

This makes life for the end user a piece of cake.

Once the user logs into their desktop, that's it. No more logins. Double-click on the shortcut to launch Lotus Notes, the login screen flashes, and bam, you are logged in. In fact, it even does it for you, when you lock your Lotus Notes client session, to unlock, SecureLogin will auto fill that too! We had to disable that functionality, for security reasons, for some users, but that too is one of the beauties of SecureLogin. It reads its policies for how it works from the directory, so some users get one policy, others get a different policy.

Time to do some work on the retail system, running on an AS400? No problem, launch the TN5250 emulator session (Like Telnet, SSH, or TN3270 (for mainframes), TN 5250 is a terminal type used by IBM's midrange servers), Novell SecureLogin knows to pop in the username and password and hit the right key stroke to log in.

On top of that, SecureLogin supports Internet Explorer and Firefox for web pages that ask for credentials. So when the user wants to hit the company portal, and needs to be authed to do something, SecureLogin sticks its nose in, drops in username and password information and Bam (as Emeril might say) you are logged in, no extra typing.

As you can imagine this makes the end users happy, and life better for them.

However, you do not want users SSO'ing their personal bank account stuff or stock trading accounts with SecureLogin. No problem, the policy only allows SSO for a small set of web pages that the company is willing to be responsible for.

But if there is a group of people, say VIP's of some sort who REALLY like the convenience and decide they must have SSO for other web apps, well that is easy, just add a policy for them that allows them to SSO whatever else they want.

At the end of the day everyone is happier, and the company does its day to day work much easier and more smoothly.

More Articles about Password Management Software

• Implementing a Business-to-Consumer Custom Password Reset Function using User Application

• Password Management Made Easy