Deployment of custom mbeans (security providers)

[kenneth-olwing]

Actually, I just noticed issue #944 sorted, and my interest coincides with that isse in general, but at this time most specifically regarding deployment of custom mbeans (we have several, for both authorization and auditing for example). I figured I'd put this as separate issue so as not to cloud the original.

===

I'm researching how to convert our present domain-creation style to use WDT instead. But at present I'm in a bind :-(

For this issue I've created a repro'able setup; project attached. I have created a nonsense Auditor ('local.ken1.SampleWlsAuditor') that does nothing except printing to stdout on calls. My goal is to model this and deploy it using WDT, during a createDomain. I'm using WDT 1.9.16, Java 11 and WLS14.

Once I started reading up on it, The Documentation is pretty clear - I apparently have to put the mbean jar (and the schema jar) inside the Oracle_Home in order for this to work (and it does). This is really bad IMHO; at least for us.

I have experimented far and wide to break this limitation, but no success.

My problem is first, that our WLS installs are effectively read-only - the Oracle_Home should not be touched by projects using it. The second problem is that even if we managed to relax this, there is simply no good answer as to what would happen when multiple projects use a single Oracle_Home. At best, they would simply contaminate it for everyone (e.g. project A would see securityproviders particular to project B), but at worst they would need to use different versions of the 'same' provider. I can't see any provision to handle that situation (other than installing 'private' Oracle_Home's for every project - while theoretically possible, not very palatable...).

I believe that there must be a mechanism to allow WDT/WLST to find the requisite mbean/schema jars by some alternate mechanism so the Oracle_Home will not need to be touched. The weblogic.alternateTypesDirectory property appears not to impact domain creation (and unclear if that would work for a schema jar also?).

I'm hoping there is a possible workaround for this - or, one can be devised (likely in terms of #944). At present, this is a bit of a deal-breaker for me. I appreciate the suggestion on using WIT, but involving docker containers at this point would complicate the situation too much (we're moving in that direction, but for the vast majority of several thousand projects this is not practical just now).

Any suggestions? Please? :-)

Thanks,

ken1

sample_wls_auditor.zip

[CarolynRountree]

The schema jar is WebLogic Server way to allow us to read and create your custom provider in offline mode. It is a WLST limitation unfortunately. And they do not have a way to reference another directory, they just reference that directory. Your one workaround would be to create a minimal domain, no security providers, and then start the admin server and run update to add in the security configuration. No schematype jar is needed in this case. The only other suggestion is to open a bug with WebLogic to be able to reference a different location for the schema jar, stating all that you have stated here.

[kenneth-olwing]

Hi, thanks for your help and insight.

Yep, I was afraid it was a problem which was out of 'your'/WDT purview :-/ - clearly you're constrained by things you can't control. At least I've confirmed that I'm not doing something wrong or have just missed the right docs...

As you say, I'll need file a bug/enhancement request in the WLS support channels for this. While waiting, I'll investigate workarounds, we'll se what I can turn up; your suggestion is one way, I have some other ideas too.

Having said that, I'm also hoping 'you'/WDT might have some pull to achieve this - I believe it puts a severe crimp in the value prop for WDT, when you actually can't describe the model fully without dropping things into Oracle_Home (which, I still honestly think is a bad idea in general).

Considering that for the past 15-20 years we've had an inhouse tool to describe and create domains declaratively, it has become a monstrosity, with lots of weird magic to massage a domain into working the way we want/need it to. I was overjoyed to find WDT and am (still) hoping to let it become the 'heavy lifter' of that stuff, but then be able to build on top of it and taking care of things it doesn't cover (for good reason) particular to us, while still allowing projects to drop down to plain WDT when our stuff is inadequate for some reason. However, if WDT can't stand fully on it's own, I'm back to doing weird magic to make things work. It makes my trailblazing with WDT harder to justify unfortunately.

I'm still excited by WDT, so kudos to you and the team regardless, keep up the good work & responsiveness here.

Thanks,

ken1

[kenneth-olwing]

To any who might be interested:

The above was turned into an SR and with a repro case it was confirmed and turned into an enhancement request:

Enh 33225987 - WLST REQUIRES MBEAN JARS BE PHYSICALLY PRESENT INSIDE THE ORACLE_HOME

i.e. requesting a way to avoid having to physically copy any security provider jars (mbean/schema) into the ORACLE_HOME, instead to be able to point to arbitrary locations. As yet I haven't seen it turn up on the bug tracker, but I assume it will make it there.

As I note above, I think this is of great importance to WDT as such, as without this it makes it impossible to roundtrip a domain properly. I have no idea if it's possible (?), but I hope anyone else also requiring this would 'vote' for this enhancement - in particular the WDT team :-)...

Thanks,

ken1

[kenneth-olwing]

The enhancement req is now visible in the bug tracker for me as well and I hear it will be implemented, although when is of course more unclear. I'm told that others can vote for it so if you feel this thing is for you, please vote...:-)

Thanks all,

ken1

[kenneth-olwing]

While dev is on the case, the support engineer came back to me after having found what seems to be missing pieces. In at least 12.2.1.4 and up, two properties exists for pointing out mbean types and their schemas to WLST.

fmwconfig.alternateTypesDirectory=<comma-separated list of paths to dirs containing "mbean.jar" files>
fmwconfig.alternateSchemaDirectory=<comma-separated list of paths to dirs containing "mbean.schema.jar" files>

Exactly how this relates to 'weblogic.alternateTypesDirectory' prop is unknown to me. In several tests it seems to work exactly like I need it. Props can be passed in many ways of course, but for WDT stuff using 'WLSDEPLOY_PROPERTIES=...' seems to work fine.

The enh request is still active in case something problematic crops up, but in any case this would likely be good stuff to include on the section for "Custom Security Providers" in "Samples/Modeling Security Providers" as it obviates the prereq of stuffing things into the Oracle_Home tree.