<< April 2013 | Home | June 2013 >>

IBM Connect Japan2013 出展及びセッションのご案内

This week OnTime is back in Tokyo spending time with our very good partner Axcel Corp. Besides customer meetings we are going to the IBM Connect 2013 Japan tomorrow Thursday where OnTime have a session and my boss Jens is giving the introduction in Japanese. It's going to be great.

IBM Connect Japan2013 出展及びセッションのご案内

Tags : ,

Authentication vs. Authorization

When ever I talk to customers and partners about single-sign-on (SSO) and the concepts of "authentication" I'm quite often baffled by the level of misunderstanding, misconception and lack of knowledge about just how "authentication" works. Now the reason I put "authentication" is quotes is that when we talk about authentication it's really not just authentication we're talking about. When we talk about confirming the identity of a user and confirming that the user is allowed to access a given resource we actually talk about two related concepts which are always performed - 1) authentication and 2) authorization.

Authentication is the process by which we authenticate the user i.e. find out that the user is authentic and is who he or she claims he or she is. This is most often done using a username and a password but there are numerous ways of doing this. The authentication step is most often followed immediately by authorizing the user to perform a certain task or access a certain resource. A user may be authenticated but not authorized i.e. we know who the user is with certainty but the user is not allowed to perform the operation or access the resource he or she set out to perform or access. A user may also be authorized without being authenticated in which case we allow an non-authenticated user (e.g. Anonymous in IBM Domino) to have certain rights in the system. The latter is the case where an Anonymous user is allowed to open a database, browse a web site etc.

The failure to distinguish between these two steps can lead to a lot of SSO issues and errors not being easily understood and/or debugged. Consider the case where a user signs into System A (i.e. authenticates and the user account authorized to perform the task at hand) and then moves on to System B to access another resource or perform a task which the user is "suddenly" unable to perform. Why? The user was able to work in System A so why not in System B?

This is the time where the person debugging this should stop and think...

Is the reason not because the user isn't authenticated but because he or she isn't authorized? Could it be that the user is authenticated both by System A and System B but that System B wasn't able to authorize the user? Maybe because the username was in another format or the particular username permutation not listed in the ACL or group authorizing the user to work in System B. Knowing about the steps performed can make it a lot easier (or just possible) to diagnose.

Using a good old Notes database with a wide open ACL and a simple page displaying the username of the current user (i.e. using @UserName in a piece of computed text) can make all the difference. It easily shows issues with the user being known by a LDAP username (e.g. cn=Mikkel Flindt Heisterberg,ou=Users,dc=intravision,dc=dk) and not by a Domino distinguished name (CN=Mikkel Flindt Heisterberg/O=IntraVision) or SSO not working due to misconfigured domain names, no shared secrets etc. by the user being known as "Anonymous" because the LtpaToken(2) was never sent to the server due to the cookie rules not being fulfilled. Same goes for Websphere Application Server - a simple WAR based application with a servlet displaying the current username is great for debugging.

Hope it clarifies matters and is helpful to someone.

Websphere Application Server WIM LDAP adapter log trace

When debugging LDAP login issues for Websphere Application Server (WAS) you're actually debugging the WIM (Websphere Identity Manager) part of WAS. The actual login piece is part of the adapters (database, ldap, file) which is the repository specific piece that WIM delegate the actual authentication to. The best debug string to use is "com.ibm.ws.wim.adapter.ldap.*=finest" as it limits the debugging to the LDAP piece of WIM.

Setting up LDAP failover for Websphere Application Server

As you may know LDAP is crucial to Websphere Application Server (WAS) when using it for IBM Connections so it makes good sense to configure failover for LDAP. If the LDAP server becomes unavailable you can no longer log in (actually you can't even log into ISC - see Websphere Application Server Security - make sure file based auth continues if federated repository is unavailable) and WAS can have a hard time reconnecting to the LDAP. Failover is set up using either the ISC Federated Security UI or by editing wimconfig.xml directly (or using wsadmin commands). Using wimconfig.xml have some advantages as you can set some additional parameters. The screenshot below shows a secondary LDAP server added to the ISC.

Editing wimconfig.xml (see the wim/config-subdirectory of the cell configuration directory e.g. c:\wasprofiles\dmgr\config\cells\LCCell01\wim\config\wimconfig.xml) is easy as well. You simply add an additional LDAP server to the config:ldapServers tag as shown below. The parameters in bold can be used to make sure that WAS return to the primary LDAP server (first listed) and optionally what the poll time should be (in minutes).

<config:ldapServerConfiguration primaryServerQueryTimeInterval="15" 
   returnToPrimaryServer="true"
   sslConfiguration="">
   <config:ldapServers authentication="simple" bindDN="cn=LDAP User,o=Example"
      bindPassword="{xor}removed :)" connectionPool="false" connectTimeout="0"
      derefAliases="always" referal="ignore" sslEnabled="false">
      <config:connections host="cph001.intravision.dk" port="389"/>
      <config:connections host="cph002.intravision.dk" port="389"/>
  </config:ldapServers>
</config:ldapServerConfiguration>

Full info in the info center under Primary and secondary LDAP server failover.