First of all, you must either create responsibilities in Siebel with exactly the same name as groups in RPD, or vice versa. The important point is that there must be groups in the RPD and responsibilities in Siebel with exactly the same name:
Groups in RPD
Responsibilities in Siebel
When a user logs into OBIEE an initialisation block named "Authorization" runs some SQL against the Siebel database and gets the responsibilities for the current user. It sets the session variable GROUP to the set of responsibilities returned.
If there are groups in the RPD which have identical names to any of the responsibilities held in the GROUP variable after the initialisation block has run then the user will be added to those groups, and will then inherit all the security (object and data level) for that group.
This example is based on Siebel as a source, but there is no reason why this can't work for any source. The important point is the session initialisation block which runs and gets the groups to add the user to. In Siebel this is controlled through responsibilities, in another source system it could be through another mechanism; as long as it is possible to retrieve through SQL then the initialisation block can be changed to use this.
If there are groups in the RPD which have identical names to any of the responsibilities held in the GROUP variable after the initialisation block has run then the user will be added to those groups, and will then inherit all the security (object and data level) for that group.
This example is based on Siebel as a source, but there is no reason why this can't work for any source. The important point is the session initialisation block which runs and gets the groups to add the user to. In Siebel this is controlled through responsibilities, in another source system it could be through another mechanism; as long as it is possible to retrieve through SQL then the initialisation block can be changed to use this.
No comments:
Post a Comment