Michal Krawczyk delivers again with the above weblog that addressed a common problem that I only raised yesterday in the forums. I took this additional info and I have a proposed approach to extending this for the enterprise. Within that Weblog and mine, not all answers are there, so input from the community is definitely appreciated. First some background: Secure Store API's work with a client id key, which effectively relates to the application running the code. This is the way it's meant to work (as I understand it) based on the fact that passwords stored by one application should not be accessible by another. For example; if you run the code in the above weblog in a real XI scenario; the password gets retrieved from the application: sap~com~com~sap~xi~services~aii~mt~rt~jar However, if you run the mapping within the test tool with the Integration Builder then the password gets retrieved from the application: sap~com~com~sap~xi~repository~aii~mt~rt~jar Here's an example of me playing around with the functionality:
So since I can't see how you can maintain passwords directly in the J2EE Admin tool; I came up with the proposed approach (which can obviously be improved significantly if required) but can work from an enterprise perspective (to be proven). Firstly, using your standard custom XI Software Component that your company has; define a namespace for the password functionality. Within this software component; include the frame and security jars as imported archives*. Put them in this location as this is the logical location to store these archives from a maintenance perspective. Now we'll create an interface who's sole purpose is to set passwords. A candidate API looks like this:
I've included the namespace in this as all passwords are stored in the same location so this will help differentiate the passwords (see above example of how this may look). Now within a message mapping we create a user based function to take these 3 inputs, store the password then return a success or failure message:
Then using a local file adapter or something better; we allow our basis team to upload and change passwords by dropping the file into the upload directory. note - I haven't written the above code to change passwords; but that's a fairly simple change. Now all of this said; wouldn't it be a nice feature for PI/XI to support mapping password functionality with a proper administration feature going forward (if this exists, let me know). So finally, I have a solution to give me some SOX control over passwords required for web services and the like which are stored in clear text or configured in unsecured development systems. Regards, Matt * The imported archives is the step I would like to see improved as this would require that these jars are updated manually after every support pack stack application and I don't understand why they couldn't be made available to the mapping runtime.
So since I can't see how you can maintain passwords directly in the J2EE Admin tool; I came up with the proposed approach (which can obviously be improved significantly if required) but can work from an enterprise perspective (to be proven). Firstly, using your standard custom XI Software Component that your company has; define a namespace for the password functionality. Within this software component; include the frame and security jars as imported archives*. Put them in this location as this is the logical location to store these archives from a maintenance perspective. Now we'll create an interface who's sole purpose is to set passwords. A candidate API looks like this: I've included the namespace in this as all passwords are stored in the same location so this will help differentiate the passwords (see above example of how this may look). Now within a message mapping we create a user based function to take these 3 inputs, store the password then return a success or failure message:public String SetPassword(String PasswordKey,String PasswordNamespace,String Password,Container container){ String sSuccess = "failed"; try { javax.naming.Context ctx = new InitialContext(); Object o = (Object) ctx.lookup("tc~sec~securestorage~service"); if (o != null) { SecureStorageRuntimeInterface secStore = (SecureStorageRuntimeInterface) o; RemoteSecureStorageClientContextInterface myContext = secStore.getSecureStorageClientContext(); myContext.storeObject(Password, PasswordNamespace+'/'+PasswordKey); sSuccess = "Success"; } } catch (Exception e) { sSuccess = e.toString(); } return sSuccess; }Error handling could obviously be better Then using a local file adapter or something better; we allow our basis team to upload and change passwords by dropping the file into the upload directory. note - I haven't written the above code to change passwords; but that's a fairly simple change. Now all of this said; wouldn't it be a nice feature for PI/XI to support mapping password functionality with a proper administration feature going forward (if this exists, let me know). So finally, I have a solution to give me some SOX control over passwords required for web services and the like which are stored in clear text or configured in unsecured development systems. Regards, Matt * The imported archives is the step I would like to see improved as this would require that these jars are updated manually after every support pack stack application and I don't understand why they couldn't be made available to the mapping runtime.
3 Comments
