Bug 1067730

Adding mgencur as needinfo for a final ack from QE.

https://access.redhat.com/site/documentation/en-US/Red_Hat_JBoss_Data_Grid/6.3/html/Developer_Guide/chap-Security_for_Cluster_Traffic.html#sect-Node_Authentication_and_Authorization

9.1  The Node Authentication and Authorization section appears to document only the Client-Server mode. How is node authentication/Aurthorization done in Library mode ?

(In reply to Divya Mehra from comment #12)
> https://access.redhat.com/site/documentation/en-US/Red_Hat_JBoss_Data_Grid/6.
> 3/html/Developer_Guide/chap-Security_for_Cluster_Traffic.html#sect-
> Node_Authentication_and_Authorization
> 
> 9.1  The Node Authentication and Authorization section appears to document
> only the Client-Server mode. How is node authentication/Aurthorization done
> in Library mode ?

Hey Diyva,

Thanks for the review! I'll move this comment over th BZ#1067744 for ease of tracking.

Thanks,

Gemma.

I'd defer to Vojtech

Requested node authentication info was provided under BZ #1067744.

For completeness add a role mapper to the Example 8.1:

Example 8.1. CacheManager Authorization (Declarative Configuration)

<cache-container name="local" default-cache="default">
        <security>
           <authorization>
             <identity-role-mapper />
             <role name="admin" permissions="ALL"/>
             <role name="reader" permissions="READ"/>
             <role name="writer" permissions="WRITE"/>
             <role name="supervisor" permissions="ALL_READ ALL_WRITE"/>
           </authorization>
        </security>
</cache-container>

The management realm in JDG 6.3 now has an authorization section, so example 8.9 should be:

Example 8.9. Configuring Security Realms Declaratively
<security-realms>
            <security-realm name="ManagementRealm">
                <authentication>
                    <local default-user="$local" skip-group-loading="true"/>
                    <properties path="mgmt-users.properties" relative-to="jboss.server.config.dir"/>
                </authentication>
                <authorization map-groups-to-roles="false">
                    <properties path="mgmt-groups.properties" relative-to="jboss.server.config.dir"/>
                </authorization>
            </security-realm>
            <security-realm name="ApplicationRealm">
                <authentication>
                    <local default-user="$local" allowed-users="*" skip-group-loading="true"/>
                    <properties path="application-users.properties" relative-to="jboss.server.config.dir"/>
                </authentication>
                <authorization>
                    <properties path="application-roles.properties" relative-to="jboss.server.config.dir"/>
                </authorization>
            </security-realm>
        </security-realms>

Procedure 8.4. Configure SASL GSSAPI/Kerberos Authentication

In bullet b. QOP stands for Quality of Protection (not Production).
I would also add some explanation:

The qop attribute specifies the SASL Quality of Protection value for the configuration. Supported values for this attribute are auth (authentication), auth-int (authentication and integrity, which means that messages are verified against checksums to detect tampering), and auth-conf (authentication, integrity and confidentiality which means that messages are also encrypted).
Multiple values can be specified (e.g. "auth-int auth-conf") and the ordering implies preference, i.e. the first value which matches both the client and server's preference is chosen.

Thanks for your feedback Tristan.

I have updated the topics with comments 27-29, they should appear in the working build shortly.

The JDG Server (although based on EAP) does not require the use of a SecurityManager. For the application connecting to the JDG Server (let's use JDG Client), the SecurityManager configuration is ininfluential.
In library mode, setting the SecurityManager and policy is usually done by configuring the JVM (regardless of the container, if any, in use). However, containers such as EAP, might need special attention/configuration/etc.

I wrote *ininfluential* not *influential*.


a) No. Forget that JDG server is based on EAP. We don't want users to run it under a SecurityManager, although we might provide a configuration to do so for 6.4.

b) Those topics are specifically for library mode. If the user wishes to use the SecurityManager, she will need to configure the JVM and/or container to enable it before deploying the application. This is where linking to the EAP security manager docs is relevant.

(In reply to Tristan Tarrant from comment #38)
> I wrote *ininfluential* not *influential*.
> 
> 
> a) No. Forget that JDG server is based on EAP. We don't want users to run it
> under a SecurityManager, although we might provide a configuration to do so
> for 6.4.
> 
> b) Those topics are specifically for library mode. If the user wishes to use
> the SecurityManager, she will need to configure the JVM and/or container to
> enable it before deploying the application. This is where linking to the EAP
> security manager docs is relevant.

In that case, I suggest leaving these topics exactly where they are.

Setting this bug to ON QA.

Now available on access.redhat.com under the JBoss Data Grid 6.3 documentation label.