SAP NW Java IdP allows you to add unlimited range of attributes to SAML token. These attributes can be:
In this blog, I wil create a simple policy script to create an attribute which does not exit in the UME.
Scenario: SAP Business Objects BI Platform 4.1(BO) is configured as a Service Provider (using Apache HTTP Server and Shibboleth) and SAP NW Java(SAP IdP) is configured as an Identity Provider. BO uses BW as a user source and SAP IdP uses Active Directory as a user source. Trusted Authentication is enabled on BO server, hence BO expects username in the REMOTE_USER variable.
An example username in BO is aakbal, but its value in BO CMS DB is <BW_SID>~<BW_Client>/<username> which is SID~200/aakbal in this scenario. Therefore BO expects REMOTE_USER variable to be SID~200/aakbal . However this value exists neither in AD, nor in SAP NW Java. Somehow, we have to create this attribute on-the-fly and pass it to BO Server.
It is also possible to change username format in BO by implementing SAP Note 1343537, but BO has already been in use for a long time and customer does not want to lose authorizations and favorites. Hence; this option is inoperative
You can also manipulate Shibboleth or Apache Configuration and add “SID~200/” value before LogonID, but it is not easy to concatenate strings in the xml format, and you cannot manipulate SAML token.
Therefore I must do this operation on IdP side. AD username should be converted to BO username format before sending SAML Assertion from IdP to SP.

Prerequisities:
Configuration
To start with:
Example code :
AssignBOUsername function is a parametric function which concatenates given SID, ClientNo and username on the fly and assign this value to a SAML Attribute called BOUsername
Next time you initiate SAML Authentication ; besides other attributes, SSO Server will send BOUsername attribute in the format specified in the procedure.
Example :

Attribute in the SAML Assertion
More information can be found in help.sap.com (Configuring Policy Scripts for Identity Provider Extensions ) and SAP SSO Policy Scripts Implementation Guide.
- Default Assertion Attributes: Same attribute value for every user
- User-based Assertion Attributes: Values differ from user to user depending to user data source. For example, phone number or e-mail
- Authorization based Assertion Attributes: These attributes can include users group and role assigments in NW Java UME. Source can be LDAP, UME DB or ABAP, depending on the UME configuration
- Policy-based Assertion Attributes: Attribute values can be created on-the-fly depending on the result of the policy. For example, custom SAML attributes which uses existing user attributes or environment values.
In this blog, I wil create a simple policy script to create an attribute which does not exit in the UME.
Scenario: SAP Business Objects BI Platform 4.1(BO) is configured as a Service Provider (using Apache HTTP Server and Shibboleth) and SAP NW Java(SAP IdP) is configured as an Identity Provider. BO uses BW as a user source and SAP IdP uses Active Directory as a user source. Trusted Authentication is enabled on BO server, hence BO expects username in the REMOTE_USER variable.
An example username in BO is aakbal, but its value in BO CMS DB is <BW_SID>~<BW_Client>/<username> which is SID~200/aakbal in this scenario. Therefore BO expects REMOTE_USER variable to be SID~200/aakbal . However this value exists neither in AD, nor in SAP NW Java. Somehow, we have to create this attribute on-the-fly and pass it to BO Server.
It is also possible to change username format in BO by implementing SAP Note 1343537, but BO has already been in use for a long time and customer does not want to lose authorizations and favorites. Hence; this option is inoperative
You can also manipulate Shibboleth or Apache Configuration and add “SID~200/” value before LogonID, but it is not easy to concatenate strings in the xml format, and you cannot manipulate SAML token.
Therefore I must do this operation on IdP side. AD username should be converted to BO username format before sending SAML Assertion from IdP to SP.

Prerequisities:
- You need to have RBA_POLICY_ADMIN role in NW Java.
- Business Objects BI Platform is already configured for SAML SSO
Configuration
To start with:
- Login to NWA and go to SAML Configuration Page, then select Extensions
In this tab select Attribute Providers in the Extension Type dropdown list

- Login to Policy Script Administration Console: https://<NW_JAVA_hostname>:<port>/ssoadmin/scripts
- Click on Create

- Create a library named AssignBOUsername

Example code :
function AssignBOUsername (sid,client) {
var BOusername = sid + '~' + client + '/' + user.getUniqueName() ;
var BOAttribute = saml2AttributeDatabag.addAttribute('BOUsername', BOusername);
}- Then Release and Activate the library

- You will see the content

- Now create a new procedure in which you can use function created above. Click on Create again

- Create a procedure named SetBOAttribute
I intentionally put a black mark on SID part to hide real SID.
#include "AssignBOUsername";
AssignBOUsername ('SID','200')
result.put('saml2.attributes', saml2AttributeDatabag);AssignBOUsername function is a parametric function which concatenates given SID, ClientNo and username on the fly and assign this value to a SAML Attribute called BOUsername
- Save and release the procedure

- Now go back to SAML Configuration Page

- Select Policy-Based Assertion Attributes and Click on Reload

- From Policy Name dropdown list select SetBOAttribute procedure

- You will see the content of the procedure below

- Save and Enable SAML configuration.
Next time you initiate SAML Authentication ; besides other attributes, SSO Server will send BOUsername attribute in the format specified in the procedure.
Example :

Attribute in the SAML Assertion
<Attribute Name="BOUsername">
<AttributeValue xmlns:xs=http://www.w3.org/2001/XMLSchema xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:string">
SID~200/aakbal
</AttributeValue>
</Attribute>More information can be found in help.sap.com (Configuring Policy Scripts for Identity Provider Extensions ) and SAP SSO Policy Scripts Implementation Guide.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.