Technical Blog Post
Abstract
Understanding Application Authentication and Authorization Security
Body
There are 2 parts to security in an application.
Authentication - Where someone is allowed to access the application
Authorization - Where someone is given privileges within the application to access particular functions like admin, work, accounting, etc
Authentication mechanisms can be generic because they do not need to know anything about what happens inside the application. They just allow or disallow access to the application.
Authorization mechanisms must be built by the application since only the designer of the application understands what authorities must be in place to perform any given function.
Maximo has only 2 Authentication mechanisms.
Native Authentication - Where Maximo stores the username and encrypted password in it's own tables. When using native authentication, the user must enter their credentials each time they access the application and the credentials are unique to just the Maximo application. After login, the username is then used to access the security tables to determine what authorities the user has within the application.
LDAP or Application Server Authentication - Where the username and password are stored in an enterprise directory server along with other profile information about the user. When using LDAP (Without SSO) the user must enter their credentials each time they access the application BUT, the credentials are shared with any other applications that use the same directory server. This saves the user from having to maintain a long list of credentials for the various applications they use. When using LDAP, the application server (WebSphere or WebLogic) intercepts the application access request and authenticates to the directory server. Once authenticated, the username is passed to the application with a token that indicates the user has been authenticated. After login, the username is then used to access the security tables to determine what authorities the user has within the application.
Since LDAP is what is used to do authentication in an LDAP configuration and that means the application server is actually responsible for that authentication, when you configure Single Sign-on (SSO) you are really configuring the application server and it has nothing to do with the application. SSO will integrate to the LDAP/Directory server for a one time sign in and subsequently pass the same authentication token to any application authorized for use.
So far we have talked all about Authentication and not much about Authorization. As I said, after login, the username is passed to the application for authorization but how did the usernames that are in the directory server get from the directory server to the application? Enter synchronization. Maximo has 2 types of synchronization driven by cron tasks on a timed basis.
LDAPSYNC - A specific synchronization task dedicated to connecting only to Microsoft Active Directory (MSAD), retrieving user information and copying it (synchronizing it) to the application database. LDAPSYNC can be used with WebLogic or WebSphere but can ONLY connect to Microsoft Active Directory Server. LDAPSYNC uses familiar standard LDAP syntax that users familiar with MSAD will be familiar with.
VMMSYNC - A specific synchronization task dedicated to connecting to a WebSphere virtual directory server, retrieving user information and copying it (synchronizing it) to the application database. VMMSYNC can ONLY be used with WebSphere Application Server (not WebLogic) but can theoretically be used with any directory server that can be hooked up to the WebSphere virtual directory. VMMSYNC uses a unique LDAP syntax that users may need to become familiar with to get synchronizing working properly. WebSphere says they can connect to many directory servers. Maximo and other TPAE based applications only support MSAD and Tivoli Directory Server (TDS) because we do not want to support a broad range of third party products as part of our support contract. However, if the data from any directory server can be realized by WebSphere in its virtual directory, the VMMSYNC task should work to synchronize users into the Maximo DB. People interested in using other directory severs can work with WebSphere support to configure use with the WebSphere virtual directory but Maximo support teams will not be able to support concerns or issues for configurations that are not supported.
On a final note, authorization in Maximo can be user based or role based and can be controlled by groups that users are a member of. If the implementation wants to manage groups on the directory server side, both sync tasks can be configured to bring over both the users and the groups they are a member of. This will eliminate the need to manage the user once they are in the Maximo DB. If the decision is that groups are not managed by the directory server, once a new user is synchronized to the Maximo environment, an administrator will have to manage the user to assign application authorities.
Example: New User "Joe Jones" is added to the directory server and put in a group on the directory server called "Work Management". Using WebSphere configuration, WebSphere is connected to the directory server where WebSphere builds a virtual directory of the users configured. VMMSYNC runs and picks up the new user "Joe Jones" in the WebSphere virtual directory along with the "Work Management" group and copies them to the Maximo DB. Assuming the Maximo application has been configured to use a group called "Work Management" to authorize capabilities in the application, the user is now able to login and perform work management functions.
Note that configuring groups in WebSphere may require some additional configuration and this is discussed in my colleague Shane Howard’s blog on custom attributes at the link below.
UID
ibm11133043