Introduction:
After a big crash of my Laptop hard drive I had to rebuild my system, so I am a little behind my time schedule now. Never the less I will try to hurry up and post my next two Blogs till the end of this year before Project work gets a hold of me again. First I hope everyone of you out there had a marry Christmas! Hope the days were very regenerating and that you will be able to take a deep breath and hold still before work will start again.
Connecting MDM Part II
Getting the Session in a SSO Scenario:
In my last Blog I showed you how to get a connection to the MDM Server. On top of this connection we set up a User Session addressing a repository and authenticated the session towards the repository.
Thinking of a scenario like SSO where we might not want to authenticate the User towards the repository with Username and Password again, there could be a need to have an alternative method to authenticate the user session without password. If the application we build runs in an SAP Enterprise Portal, we do not have the password of the user in clear text ( only hash) unless we make a system mapping in the User Management Engine for the MDM System.
So how can we arrange to authenticate the user session without a password. This is very simple and can be done by building a trust relation between the Client (e.g. Portal Server) and the MDM Server. This trust relation is build by telling the MDM Server which IP addresses to trust. So the next question will be how to tell the MDM Server the IP addresses of the trusted clients. As usual this is done with a configuration file called “allow.ip” and the counterpart is “deny.ip”. Those two files tell the MDM Server who to trust and is a plain text file which is not present after the installation of the MDM Server.
A sample file with the name allow.ip could look like followed:
192.168.2.1
192.168.1.*
10*
As you can see wildcards are allowed in the file. Maybe in the range specified might be a host that should not be trusted, you can place the IP address of that host in the deny.ip file and it will not be trusted then.
So where should this file be put then? The easiest way is to put the file in the same folder on the hard disk where the mds.ini file resides.
e.g. C:Program FilesSAP MDM 5.5Server
If you want to place the files in a different location you need to add a line to the mds.ini file like:
TrustFiles Dir=C:{path}something
Where both the files (allow.ip and deny.ip) should be put then.
For a detailed description please see the following link on page 9 and 10 of the document. (Source SDN)
How To identify identical master data records using SAP MDM 5.5 ABAP API’shttp://www.sdn.sap.com/irj/sdn/go/portal/prtroot/docs/library/uuid/e060251e-b58d-2910-02a2-c9a1d60d9...
Also see:
Wiki entry on allow.ip
I have tested the method and it worked fine for my application.
On my project where I used the code we had the following setup. My application was running on a SAP Portal, where the username can be read from the portal context but not the password. There is the same username on portal as in the MDM Server. I used this method with the username from Portal to authenticate the users to the MDM Server / repository.
Let me show you some code you could use to authenticate a user session using a trusted connection or if the connection is not trusted fall back to normal authentication.
/**
* Create and authenticate a new user session to an MDM repository.
*
* @throws ConnectionException
* is propagated from the API
* @throws CommandException
* is propagated from the API
*/
public String getAuthenticatedUserSession(ConnectionAccessor mySimpleConnection) throws ConnectionException, CommandException{
/*
* We need a RepositoryIdentifier to connect to the desired repository
* parameters for the constructor are:
* Repository name as string as read in the MDM Console in the "Name" field
* DB Server name as string as used while creating a repository
* DBMS Type as string - Valid types are: MSQL, ORCL, IDB2, IZOS, IIOS, MXDB
*/
RepositoryIdentifier repId = new RepositoryIdentifier(RepositoryNameAsString,
DBServerNameAsString, DBMSTypeAsString);
// Create the command to get the Session
CreateUserSessionCommand createUserSessionCommand = new CreateUserSessionCommand(connection);
// Set the identifier
createUserSessionCommand.setRepositoryIdentifier(repId);
// Set the region to use for Session - (Language)
createUserSessionCommand.setDataRegion(dataRegionAsString);
// Execute the command
createUserSessionCommand.execute();
// Get the session identifier
String session = createUserSessionCommand.getUserSession();
// Authenticate the user session
try {
// Use command to authenticate user session on trusted connection
TrustedUserSessionCommand tuscTrustedUser =
new TrustedUserSessionCommand(mySimpleConnection);
// Set the user name to use
tuscTrustedUser.setUserName(UsernameAsString);
tuscTrustedUser.setSession(session);
tuscTrustedUser.execute();
session = tuscTrustedUser.getSession();
} catch (com.sap.mdm.commands.CommandException e) {
/* In Case the Connection is not Trusted */
AuthenticateUserSessionCommand authenticateUserSessionCommand =
new AuthenticateUserSessionCommand(connection);
authenticateUserSessionCommand.setSession(session);
authenticateUserSessionCommand.setUserName(UsernameAsString);
authenticateUserSessionCommand.setUserPassword(USerPasswordAsString);
authenticateUserSessionCommand.execute();
}
// For further information see: http://help.sap.com/javadocs/MDM/current/com/sap/mdm/commands/SetUnicodeNormalizationCommand.html
// Create the normalization command
SetUnicodeNormalizationCommand setUnicodeNormalizationCommand =
new SetUnicodeNormalizationCommand( mySimpleConnection);
// Set the session to be used
setUnicodeNormalizationCommand.setSession(session);
// Set the normalization type
setUnicodeNormalizationCommand.setNormalizationType(
SetUnicodeNormalizationCommand.NORMALIZATION_COMPOSED);
// Execute the command
setUnicodeNormalizationCommand.execute();
// Return the session identifier as string value
return session;
}But at the end I also have to tell you the critical aspect of this method. If you create a trusted relationship between some host and the MDM Server, you have to keep in mind that any code could be executed on the MDM Server if the admin username is known. So anyone can get access with full admin privileges only by knowing the administrator name on MDM side. So you have to make sure that only authorised persons can access the host and / or deploy code to it. In my project this was not very critical, because the access to the host running my application was very restricted. Only and hand full of people were allowed to deploy applications and all of them were absolute trustworthy.
If you are in need o
So far so good. Hope this will help you to implement an SSO szenario with MDM.
In my next Blog before I will get to data manipulation I want to give you some tip on accessing MDM System information in a SAP Portal with some very useful forum thread I found. Then I will lead to data manipulation (CRUD) with some examples. The first steps will be searching in MDM.
Best regards,
Tobi
8 Comments
