Configuring Security

[Eliza]

I'm trying to achieve single sign-on and need information on how it can be done. Currently, I have 2 LDAP servers. 1 server authenticates the user and 1 that determines the role of the user. Is Cognos able to leverage on both these LDAP servers for login and to determine the user class? Do I still need to configure the users and the user class through Access Manager? Thanks!

[Darek]

You will always have to use dedicated Cognos LDAP server (or at least a container) due to the nature of Access Manager (users are not really users and neither are groups or classes). As long as REMOTE_USER will be populated by LDAP1 after authentication, you can leverage it as an OS SignOn in Access Manager. The only way you could use what you have in LDAP2 is through some scripted, hand-crafted, replication.

[Eliza]

Hi Darek, at the moment, we have an LDAP directory(say LDAP1) that authenticates the users when they log into windows. I believe a session is created once the user is log onto the network. On the other hand, I will configure Cognos to point to LDAP2 for authorization of user classes and roles. LDAP2 will have exactly the same users in LDAP1. My question is, can Cognos point to LDAP2 and still use this session created by LDAP1? Is REMOTE_USER a Cognos environment variable and how does it get populated? Thanks a million!

[Darek]

A word of caution regarding LDAP2: Access Manager will not use anything you have in there, and will change schema accordingly to it's needs, which might brake your existing directory if you have any. It's probably safer to keep it separate, meaning have an LDAP3 for AccMgr exclusively.

Most of the web access control software out there, like SiteMinder for example, after authenticating a user with some LDAP directory, create a HTTP header variable, which contains the user id token that can be collectively recognized by all web agents using same LDAP. What this variable will be called is entirely up to the administrator. Sometimes it is SM_USER, sometimes LOGON_USER, sometimes REMOTE_USER. If it is REMOTE_USER, you are lucky and don't have to do anything at all, as every Cognos web app will automatically recognize it and attempt to match it agains an OSSignOn for a particular user (thus OSSignOn has to be unique in AccMgr LDAP, meaning you will not be able to create same OSSignOn for two different users).
If it is not REMOTE_USER, than you have to leverage TrustedSDK for Series7 applications, or TrustedProvider for ReportNet. You will have to write some C or JAVA code respectively; however, this also helps in more elaborate authentication scenarios where user's trusted signon needs to be validated before processing (I did something very interesting in the past for The ARMY).

[Eliza]

Thanks Darek, I've got a few other question to add.
1.  The status of a user on the ADAM directory is flagged with values of A (Active), S (Suspended), and T (Terminated). Can Cognos handle/use this attribute or do we need to write a script to handle this?

2.  How does Cognos handle archiving accounts? Do we need a termination date or something similar?

3. Is a user's authorization cached or updated real-time? We might have manual updates on ADAM when needed. If a user is logged in when a change is made, will the users role get reflected immediately or does the user have to log out and re-log in to get the changes ?

Thanks a million!

[Darek]

Your problem sounds like a good case for TrustedSDK plug-in. You can extend Access Manager authentication, by writing bits and pieces of C code, and accomodate any extra requirements you might have (like status, termination date, etc). However I'd like to reapeat myself in saying, you'll have to have a standalone LDAP server for EXCLUSIVE Access Manager use. There is no other way.

You can disable old accounts without actually removing them.

Changes made to user's account are not reflected until his ticket expires and he needs to authenticate again. But you can make expiration time as short as you want.

[Eliza]

Thanks again Darek,
I needs another tip on security. We are trying to establish if Cognos is capable of providing the security authorization to users connecting to the source system. I understand that ad-hoc queries and reports are build using the metadata modelled in Framework Manager. The roles and responsibility on the metadata governs the visibility of metadata to reports developer and ad-hoc queries developer. Does this mean that the connection to the source system is based on service accounts used by the Framework Manager to connect to the source system? Are report consumers directly connected to the source system or does their connection stop at the Framework Manager?

[Darek]

I'm not sure. Could you explain the scenario a little bit more, please?