BO SSO with AD and Row Level Security of BW universe

[amrsalem1983]

Hello All,

i've my BO XI3.1 authorizations configured using Active Directory SSO and its working so great, but lately we i had to connect to some BW universes and apply some row level restrictions for those BW universe without using the BW security methods.

i tried to use aliases but it didnt work as the passwords are not identical for both systems (AD and BW)

any solution for this issue?

Regards

Amr

[former_member184468 · Accepted solution]

What you'll want is aliases as described here,

http://wiki.sdn.sap.com/wiki/display/BOBJ/How+to+map+SAP+users+and+AD+users+in+XI3.1+CMC

however rather than relying on password, setup SSO to the BW system, there are quite a few wikis and whitepapers, i think this one may be a good start http://wiki.sdn.sap.com/wiki/display/BOBJ/How+to+configure+SNC+in+XI3.1+CMC

This will setup a trust between the BO & SAP system, so a user can SSO to BOE using Active Directory, and then SAP SSO tickets will be generated and passed down to your BW connection to establish SSO to the data source.

Hope that's what you're looking for.

[amrsalem1983 · Accepted solution]

Thanks Greg, I already did those configurations but i dont want to go through the SNC stuff. my idea was to have a row level security same as we do for the relational data warehouses using access restrictions, i will have one single user in BW as common user used to connect to BO universes and from BO itself i wanna do the row level security and any other required authorizations.

[former_member202789 · Accepted solution]

Hi Amr,

A BOE user can have two or more aliases with different passwords e.g. WindowsAD, SAP etc.

You may not want to use BusinessObjects Credential Mapping option because as you mentioned," i will have one single user in BW as common user used to connect to BO universes".

Now there seems to be two options.

1: You use BO User-Group restriction at Universe level

2: Or you may also configure BO User & BO Pass @variable function.

Note: In order to implement this option, you will need to have intermediate level expertise on Universe Designing.

~Animesh

[amrsalem1983 · Accepted solution]

I believe row level restrictions not available for BW universes using access restrictions groups, did you check that? its available for relational univereses since they are more flexible to handle

[former_member202789 · Accepted solution]

Yes you are right, I missed that. Row level User/Group restriction is not supported for OLAP Universes. So that is not an option.

[amrsalem1983 · Accepted solution]

Hi Greg, there is something called STS in BI4, does it allow SSO between BI4 and BW 7.02 SP06

anyway we are planning to upgrade from XI3.1 to BI4.

we can replicate all AD users to BW  (the ones accessing the BI system), does it help if we used this STS option for SSO with BW?

Regards

Amr

[former_member184468 · Accepted solution]

STS is a replacement/enhancement of the SNC trust that was used in xir3.

I have it described in some more detail here http://scn.sap.com/docs/DOC-33875

The xir3 method of SSO to BW is still supported in BI4, and which one you use will depend on which clients you are using. 

Now I have to confess that I'm not an expert on the user replication of AD to BW workflow.  If in this case BW is really just replicating the user accounts but maintains its own passwords for those users in BW (in other words it is not really relying on AD to perform the actual authentication but just making a copy of user accounts) then indeed the option you describe would work, because the actual authentication would be performed by BW still, meaning that the trust established between BI4 and BW would still allow for SSO.

[rama_shankar3]

Yes, this should work as long as your client is not particular about tight security.

The right way to do this would be to  use the centralized LDAP user ID accounts  for both BW and BOBJ. Then synch of password and aliasing will work fine.

[former_member184468]

Both have their pros and cons.  Certainly synchronizing and storing passwords is by no means a good security practice either. 

In the "trust" option, the risk is that the administrator can impersonate any user to access the BW backend.

In the password synchronization, option, you're synchronizing passwords, and obviously those could fall into the wrong hands (again - would require an evil administrator or a complete exploit of the BI system).  Additionally if your traffic is unencrypted you will risk man-in-the-middle attacks.  On top of that, you have to deal with expired passwords (problematic if you're doing SSO to BOBJ and aren't updating passwords especially for offline scheduling).

Without getting off topic and into a security discussion, generally SSO 'tickets' is the preferred method of authentication to using passwords, but this is a generalization and your millage and risk may vary depending on the setup.

From a user adoption and usability standpoint, SSO will always win.