OES: How to install WebLogic SSM?

Question

Hi,
I have a small test configuration consisting of:
- IDM (for OID) and IDAM (for OAM) 11g
- a test Apache (not OHS) instance with a 10g webgate, proxying to (using the WebLogic plugin) - this is configured for X509 authentication
- a test WebLogic instance with the OAM ID Asserter and a small test portal app
I have the above configuration working, and I can protect/access control both static resources on the Apache and the portal app on the WebLogic (via the ID Asserter).
I've also stood up an instance of Oracle Entitlement server/OES on a separate WebLogic domain, and that seems to be working, by itself.
Now, I want to integrate these pieces, i.e., I want to be able to control access to the portal app using OES.
I understand that I have to install a "WebLogic SSM" into the security realm on the target WebLogic domain, but I'm having difficulty figuring out how to do that. My understanding is that what's eventually involved is that some additional ATZ and role mapping provider(s) will be added to the security realm, and actually, I'd really like to be able to just drop the appropriate JARs into the mbeantypes directory, then configure the necessary providers in the security realm, e.g., via the WL console, as this would give me a better understanding of what's going on.
Has anyone done something like that? If so, can you provide the "steps" to accomplish that?
Thanks,
Jim

Answer 1

Hi Matt,
Thanks for that info on the options.
I'd really prefer to integrate the WLS SSM into the existing WL domain, but I'm unclear about where you said "That should give you API access to OES within a WebLogic application.".
If I take the 2nd approach you suggested, creating a Java SSM using ConfigTool, etc., are you saying that we'd have to have code in our portal app code specifically to have things work with OES (policies, protections, etc.)? Does it (OES+SSM) not work like other providers in the WebLogic security framework (Authentication providers, Authorization providers, etc.), but rather our app code actually has to be aware of OES and call OES APIs in order to work with OES in-place?
I will also take a look at your 1st suggestion, i.e., running ConfigTool to create a new WL domain, and see what that looks like. In my test environment, I think that will be ok, but in our real environment, where we already have the WL domain(s) established and configured, I think that this (creating a new WL domain, just so that we can integrate OES/SSM) will probably be a no-go longer-term :(, as you can probably understand, since those domains (and security realms) have a lot more stuff in them already than I have in my test environment. Plus, in my test environment, I can blow things away and recover back fairly easily, but we don't have that luxury in production.
Thanks again,
Jim