E9.2 General purpose credentials storage in JDE

BOster

BOster

Legendary Poster
Is there a general purpose place to store usernames and passwords, with the password encrypted that can be easily retrieved in a BSFN? For example we have the Soft Coding application P954000 where we can store various information including credentials for use in Business Services that can easily be retrieve in the BSSV by calling SoftCodingRecordAccess.getSoftCodingRecord. Is there an equivalent mechanism for BSFNs? Is there a C API to retrieve the soft coding info in P954000?
 
Did you find away to do this. I am wanting to do the same thing where I can get BOOMi string with Boomi Auth to access a Boomi URL to display all the X12 PO Transactions with E1 from a Cafe1 Layout.
 
No, I I ended up rolling my own general purpose Credential Store. It salts and encrypts the PW before storing. It was secure enough for my purposes at the time. There may be a better "out of the box" solution but no one responded and I didn't find one so I created my own.

Key is application specific.
Params are just additional delimited KVP values as defined by the calling application.

CredStoreSS.JPG
 
No, I I ended up rolling my own general purpose Credential Store. It salts and encrypts the PW before storing. It was secure enough for my purposes at the time. There may be a better "out of the box" solution but no one responded and I didn't find one so I created my own.

Key is application specific.
Params are just additional delimited KVP values as defined by the calling application.

View attachment 19447
Very cool Brian, you salt & encrypt, and vice versa, using a busfun or something?
 
For the salt I generate a string of random characters (don't use jdePTRand, jdePPRand, jdePPSRand, these have issues), then after applying salt to the password, I encrypt using jdeSystemEncryptText (jdeSystemDecryptText to decrypt) and save along with the username and calling application defined kvp params.

I am no security expert so there may be holes in my implementation but for what I needed at the time it for it was secure enough... I don't think anyone that could read the records in the DB would be able to easily decrypt, it would probably take a skilled hacker at least five or ten minutes. :)

To really do it correctly it would probably be best to find some type of open source vault library/framework or whatever and write JDE wrappers around that.
 
For the salt I generate a string of random characters (don't use jdePTRand, jdePPRand, jdePPSRand, these have issues), then after applying salt to the password, I encrypt using jdeSystemEncryptText (jdeSystemDecryptText to decrypt) and save along with the username and calling application defined kvp params.

I am no security expert so there may be holes in my implementation but for what I needed at the time it for it was secure enough... I don't think anyone that could read the records in the DB would be able to easily decrypt, it would probably take a skilled hacker at least five or ten minutes. :)
Thanks good info! I agree, past a point we must be able to say we've done a reasonable effort and not left anything in plain sight, and that's good enough. The value to soft coding is too great.
 
No, I I ended up rolling my own general purpose Credential Store. It salts and encrypts the PW before storing. It was secure enough for my purposes at the time. There may be a better "out of the box" solution but no one responded and I didn't find one so I created my own.

Key is application specific.
Params are just additional delimited KVP values as defined by the calling application.

View attachment 19447
Hi Brian,

Just curious if you looked at P95400. You can create an XML document to store the credentials or basically, anything. Plus it uses the Environment/group hierarchy for dynamic configuration.

Craig
 
Hi Brian,

Just curious if you looked at P95400. You can create an XML document to store the credentials or basically, anything. Plus it uses the Environment/group hierarchy for dynamic configuration.

Craig
I was thinking of adopting Brian's salt & encrypt (via Groovy) in conjunction with this so I can stay within orchestrator and stop from rolling a custom app
 
Hi Brian,

Just curious if you looked at P95400. You can create an XML document to store the credentials or basically, anything. Plus it uses the Environment/group hierarchy for dynamic configuration.

Craig
Hi Craig,

That's soft coding records correct? Actually I think I proposed that to someone just the other day in a thread when they needed something similar to this. I obviously had to use it for BSSVs and now Orchestrator so in all honesty, I don't know why I didn't use it two years ago when I created the Credential Store - I feel like there was a reason but I can't remember now. I probably should have used it since obviously Oracle had to put a lot of thought into making sure it was secure.

Edit.
LOL. Just looked at my original post in this thread from two years ago and I mentioned it. I guess I need to start documenting more in my posts to remind myself later what I was thinking. We were in the middle of an upgrade so I had a lot of things going on and probably wasn't thinking straight.
 
Last edited:
Hi Craig,

That's soft coding records correct? Actually I think I proposed that to someone just the other day in a thread when they needed something similar to this. I obviously had to use it for BSSVs and now Orchestrator so in all honesty, I don't know why I didn't use it two years ago when I created the Credential Store - I feel like there was a reason but I can't remember now. I probably should have used it since obviously Oracle had to put a lot of thought into making sure it was secure.

Edit.
LOL. Just looked at my original post in this thread from two years ago and I mentioned it. I guess I need to start documenting more in my posts to remind myself later what I was thinking. We were in the middle of an upgrade so I had a lot of things going on and probably wasn't thinking straight.
Brian,

Haha. Yet that happens to all of us. Especially for me working at multiple clients and forgetting what went where (maybe it's an age thing ;)). We created a generic wrapper BSFN to call a BSSV that uses the JDE JAVA API to extract elements from the soft coding record. Now, my Orchestrator skills are limited but I would think you could call the BSFN to retrieve the credentials from the soft coding records.

Craig
 
Hi Craig,

That's soft coding records correct? Actually I think I proposed that to someone just the other day in a thread when they needed something similar to this. I obviously had to use it for BSSVs and now Orchestrator so in all honesty, I don't know why I didn't use it two years ago when I created the Credential Store - I feel like there was a reason but I can't remember now. I probably should have used it since obviously Oracle had to put a lot of thought into making sure it was secure.
It's not secure by default (giant text field), I think if we were being thorough, we'd still have to salt & encrypt the sensitive data within the xml. I was a bit resistant to the fact that the soft coding values are within an xml framework but I've warmed to the concept. It's nice storing multiple related variables within the same record.

XMLSlurper is great within Groovy for parsing thru the XML file in a softcoding record.
 
Craig,
That's a good idea (BSFN->BSSV) to get soft coding records. Its unfortunate that there is not a native JDE C API to get a soft coding record - maybe there is and I have not found it.

Dave,
I never actually looked in the table itself to see how the soft coding records were stored. Kind of surprises me that it is stored in plain text. I figured since it stored sensitive data like usernames and passwords that it would be encrypted at the application layer before persisting in the DB. Maybe my Credential Store is more secure. ;)
 
Craig,
That's a good idea (BSFN->BSSV) to get soft coding records. Its unfortunate that there is not a native JDE C API to get a soft coding record - maybe there is and I have not found it.

Dave,
I never actually looked in the table itself to see how the soft coding records were stored. Kind of surprises me that it is stored in plain text. I figured since it stored sensitive data like usernames and passwords that it would be encrypted at the application layer before persisting in the DB. Maybe my Credential Store is more secure. ;)
I stand corrected there's a way to do this! https://docs.oracle.com/cd/E24705_01/doc.91/e24218/working_with_softcoding.htm#EOTDE00130 I might need to go back and do some rework :D I was reading the softcoding recs via data request, might need to go in via form request to get the unencrypted XML
 
Interesting. So it encrypts parts of the XML document. I suspect however that an Orchestrator Form Request (I assume that is what you mean... I still know very little about Orchestrator) is not going to work since I don't believe the password is ever displayed back in P954000 when pulling up and existing record (just did a quick test by pulling up one of our BSSV soft coding records and unless it is hidden some place, it simply displays the password as *********). It also probably means you can't simply read the record out the the table unless you can reverse engineer how to decrypt the pieces that are encrypted (you might get lucky and jdeSystemDecryptText might work on it if they are not salting it somehow). My guess is to use P954000 and encrypt pieces of it you will have to do what Craig did and effectively use the Java API to retrieve via BSFN call to a BSSV. That is unless you can find a C API that is the equivalent to the Java API or maybe get really lucking and find a Groovy call so you can do it all in Orchestrator.

You might actually try that since Orchestrator would have to decrypt as well someplace since when you call an external web service it uses a soft coding record. Maybe you can deconstruct what it does in that situation and stumble upon a Groovy call you could use.
 
Interesting. So it encrypts parts of the XML document. I suspect however that an Orchestrator Form Request (I assume that is what you mean... I still know very little about Orchestrator) is not going to work since I don't believe the password is ever displayed back in P954000 when pulling up and existing record (just did a quick test by pulling up one of our BSSV soft coding records and unless it is hidden some place, it simply displays the password as *********). It also probably means you can't simply read the record out the the table unless you can reverse engineer how to decrypt the pieces that are encrypted (you might get lucky and jdeSystemDecryptText might work on it if they are not salting it somehow). My guess is to use P954000 and encrypt pieces of it you will have to do what Craig did and effectively use the Java API to retrieve via BSFN call to a BSSV. That is unless you can find a C API that is the equivalent to the Java API or maybe get really lucking and find a Groovy call so you can do it all in Orchestrator.

You might actually try that since Orchestrator would have to decrypt as well someplace since when you call an external web service it uses a soft coding record. Maybe you can deconstruct what it does in that situation and stumble upon a Groovy call you could use.
Oh wow I was going to try some things out today as I freed up a bit of time. This will be interesting. I need to retrieve/unencrypt the values to pass to components downstream, I just want them to be encrypted in DB. I was hoping the frontend would work for encrypt/decrypt and that we could just secure the app or row as needed.
 
Any way to get documentation for 9.2? I have to use JDE on a daily basis and training where I work is much to be desired. Thx.
 
Any way to get documentation for 9.2? I have to use JDE on a daily basis and training where I work is much to be desired. Thx.
LearnJDE.com


Google searching "e1" + whatever you're trying to find out about is generally a help

We were just talking about it at my company the other day. The documentation is good enough if you're getting technical, but gaining the concepts of each module and technical skill takes time and practice and trial and error. With Oracle by Example and all of the conference content I can't remember a time with more relevant content freely available, but you do have to put in the work ultimately.
 
Back
Top