E9.2 Where to store RSA Private Key for Orchestration Integration

DaveWagoner

DaveWagoner

Reputable Poster
Hi folks! Your friendly neighborhood Orch newbie here.

I have need to pass a RSA Private Key (begins with "-----BEGIN PRIVATE KEY-----", 5000+ chars) to a scripting component in order to generate a JWT and auth to an external system for API access. I'd prefer not to either hardcode it into the text of the script or even as default mapping in the orchestration, and would also prefer not to keep it on our middleware which calls the orchestration. Ideally I'd have a spot within a JDE table to store integration-specific credentials per environment, kind of like the Orchestrator Cross Reference, but in this case for a larger text file. A BLOB wouldn't ruin my day, so a text attachment somewhere?

Was wondering if anyone else had this issue and had figured something out?

Thanks!
 
BOster said:
Could you leverage P954000 for this purpose?
Click to expand...
I'm new to actually using E9* and didn't know this existed! F954001.WSTPVAL is size 32000 so that should work swimmingly for what I'm after if I do nothing else other than a data lookup within an orchestration. Will give this a shot, thanks!
 
I know in BSSVs we used it (P954000 Soft Coding Records) to store credentials as well as other things like this. There are predefined templates for credentials and other things but I believe you could store whatever you want or leverage an existing template to store what you need. It is also where Orchestrator stores the End Point, etc. for connecting to an external Web Service if I am not mistaken. What I don't know is if there are are Orchestrator APIs or Groovy calls to retrieve and parse Soft Coding records like there is in BSSV that would allow you to store "user defined" data.
 
Yeah this will work just fine. I just have to store things there in xml compliant tags, and then parse the content into usable strings using groovy xmlslurper. This will work great. Thanks!!
 
You know, I wanted to say that... but then, it stores in plain text, and I started thinking.... it's a private key. Sure, you don't have the public key, but.... well... this stuff all makes my head hurt depending on which security department I get stuck working with which week.
 
I made the assumption that since the soft coding records are used to store things like credentials that it would be considered a secure place to store sensitive data like a private key. Now, how secure it actually is and what is needed to make sure it is secure may be a different discussion...
 
BOster said:
I made the assumption that since the soft coding records are used to store things like credentials that it would be considered a secure place to store sensitive data like a private key. Now, how secure it actually is and what is needed to make sure it is secure may be a different discussion...
Click to expand...
Yeah. In my specific case the private key without a lot of other info is useless. It's like an unlabeled key sitting around on the desk. If you don't know exactly what to do with it and other magic words, it's not very useful.

The most nightmarish scenario i can think of is if someone with access pops into the soft coding and messes around without knowing what they're doing, because they see plain text instead of blob text
 
Back
Top