Support for policy

[gregoan]

Hello,

Some of our instances are really sensitives and customers added security on top of JMS queues.
Today with WDT there is no capability to export policy but neither create policy.

This is really problematic for us to enforce our customers to migrate because thy will have something less secured than what they can have with legacy infrastructure.

Will it be possible to have the capability to create policies ?

Regards.

[robertpatrick]

Policies are stored in the Embedded LDAP Server where, by default, the credentials required to make an LDAP connection are randomly generated. As such, discovery of such policies seem beyond the scope of what WDT is reasonably able to do.

We can look at extending our limited support for seeding the domain's generated LDIFT files with the ability to add policies to the list of data that can be seeded. However, these policies are written in a pretty complex language that will make it not only difficult to model but also difficult to generate the necessary changes to the LDIFT file. We will look into this again as a possible future enhancement request.

[robertpatrick]

@gregoan Can you give me an example or two of what the policies you need to create look like? We are discussing this and may be able to do something but the input needed is complex so I am trying to find a way to model the input in a more natural way.

[gregoan]

Hello,

Here are multiple examples (the format is the one of our old framework) :

1. Policy for DataSource

security.policies.0.mode = CREATE
security.policies.0.resource = type=<jdbc>, application=, module=,
resourceType=ConnectionPool, resource=Sysper2JDBCTxDataSource
security.policies.0.realm = myrealm
security.policies.0.authorizer = XACMLAuthorizer
security.policies.0.expression =
Rol(Deployer,Admin,Monitor,Operator)|Grp(sysper2_ecas_user_group,sysper2_group)

2. Policy for JNDI

security.policies.1.mode = UPDATE
security.policies.1.resource = type=<jndi>
security.policies.1.realm = myrealm
security.policies.1.authorizer = XACMLAuthorizer
security.policies.1.expression =
Rol(Deployer,Admin,Monitor,Operator)|Grp(sysper2_ecas_user_group,sysper2_group)
security.policies.1.expression.update.mode = REPLACE

3. Policy for WS

security.policies.393.resource = type=<webservices>, application=SEP-SDS-PROP-INFO-WS, contextPath=/sep-datastore-proposal-information-ws, webService=ProposalInformationServiceV3Port, method=checkServiceHealth, signature={eu.europa.ec.research.fp.services.proposal_information.interfaces.v3.CheckServiceHealthRequestType}
security.policies.393.realm = myrealm
security.policies.393.authorizer = XACMLAuthorizer
security.policies.393.expression= Grp(ProposalInformationServiceGroup)

4. Policy for JMS

security.policies.4.realm = myrealm
security.policies.4.authorizer = XACMLAuthorizer
security.policies.4.expression= Grp(EdaInternalFullAccessGroup)
security.policies.5.mode = CREATE
security.policies.5.resource = type=<jms>, application=EDA_Jms_Module, destinationType=queue, resource=eda_inbound3, action=browse

Regards.

[robertpatrick]

Fix for this issue merged into the develop-4.0 branch. WDT 4.0 is on track for release next month.

[gregoan]

Thanks for all. Le lun. 8 janv. 2024 à 21:12, Robert Patrick ***@***.***> a écrit :

…

Fix for this issue merged into the develop-4.0 branch. WDT 4.0 is on track for release next month. — Reply to this email directly, view it on GitHub <#1496 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AB3C76QCB2GXCJQF3JELQKTYNRHKLAVCNFSM6AAAAAA46D2E76VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQOBRG42TENJZG4> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[tdferreira]

Hello, I'm looking forward for this feature. Do you have a date for WDT 4.0 to be released?

[robertpatrick]

@tdferreira I am hoping to release it in the next week or two. We have been waiting on our QA to test and identify bugs related to our new SSH support. All issues that they have found have already been fixed so I am just awaiting their sign-off.

Please note that if you are deploying into Kubernetes using WebLogic Kubernetes Operator with Model-in-Image, WDT 4.0 will require the upcoming WKO 4.2.0 release to support the use of WDT 4.0 in that use case. As such, I am also waiting for WKO 4.2.0 to be released prior to releasing WDT 4.0.

You can get a sense for WDT 4.0 changes at https://github.com/oracle/weblogic-deploy-tooling/blob/develop-4.0/documentation/4.0/content/release-notes/_index.md.

[robertpatrick]

WDT 4.0.0 released so closing as resolved.

[tdferreira]

Just to clarify, the Discover Domain Tool in WDT 4.0.0 does not export the existing policies, right?

[robertpatrick]

@tdferreira Much like other security data fields (users, groups, credential mappings, etc.), WDT does not support discovery of these policies.

[tdferreira]

I have found an issue related to this.
When using, for example, the oracle weblogic 12 dev docker image:
container-registry.oracle.com/middleware/weblogic:12.2.1.4-dev-ol8
it already has a JNDI Policy with Resource ID type=<jndi> defined by default.
Basically, this exists already in the Root Level:

    WLSPolicies:
        JNDI:
            ResourceID: 'type=<jndi>'
            Policy: 'Grp(everyone)'

If I try to create my domain with this:

    WLSPolicies:
        MyJNDIPolicy:
            ResourceID: 'type=<jndi>'
            Policy: 'Rol(Deployer,Admin,Monitor,Operator)|Grp(my_user_group)'

I get the following error:

19.58 SEVERE Messages:
19.58 
19.58         1. WLSDPLY-12601: The policy MyJNDIPolicy is invalid because the ResourceID attribute value type=<jndi> matches built-in policy ResourceID field value with a policy of Grp(everyone)
19.58         2. WLSDPLY-20001: createDomain did not complete the operation because validation failed
19.58         3. WLSDPLY-12409: createDomain failed to create the domain: createDomain did not complete the operation because validation failed
19.58 
19.58 Total:   SEVERE :    3  WARNING :    0

It would be good if we could have an extra parameter that would tell what to do if there's an existing policy.
Something like:

    WLSPolicies:
        MyJNDIPolicy:
            ResourceID: 'type=<jndi>'
            Policy: 'Rol(Deployer,Admin,Monitor,Operator)|Grp(my_user_group)'
            **ReplaceIfExists: true|false**

Also, if we have multiple realms, how can we specify for which realm the policy is?
Couldn't we also have a parameter for that?
Something like:

    WLSPolicies:
        MyJNDIPolicy:
            ResourceID: 'type=<jndi>'
            Policy: 'Rol(Deployer,Admin,Monitor,Operator)|Grp(my_user_group)'
            Realm: myrealm
            ReplaceIfExists: true|false

[robertpatrick]

@tdferreira

1. Hmm... It would have been good to have had this requirement upfront. Please file another issue to enhance the support to accommodate this behavior. One concern that I have is that if you do something wrong, the domain may fail to start/work properly.
2. I do not believe that this is feasible. We are copying/updating an LDIFT file with a well-known name into the $DOMAIN_HOME/security directory that the Admin Server will load on first start. As far as I know, this is loaded into the embedded LDAP server without any accommodation for multiple security realms. Feel free to peruse the $ORACLE_HOME/wlserver/server/lib/XACMLAuthorizerInit.ldift that we use as the starting point and let me know if you figure out how to make it work without modifying WLS proper.