nickwallen opened a new pull request #1355: METRON-2035 Allow User to Configure 
Role Names for Access Control
URL: https://github.com/apache/metron/pull/1355
 
 
   
   This change allows a user to map groups defined in LDAP to the roles used 
internally in Metron.  
   
   For example, currently you must define a role named 'admin' in LDAP to grant 
administrative access.  With this change that LDAP group can be named whatever 
you like.
   
   This is not currently a limitation with traditional LDAP because the group 
can be nested under a tree dedicated to Metron.  This is more preparation for 
the introduction of Active Directory support.
   
   ## Changes
   
   * Created a Spring Security `GrantedAuthoritiesMapper` that maps the groups 
in LDAP to the roles defined in Metron.
   
       * This mapper defaults to the existing scheme where `admin` maps to 
administrative access and `user` maps to user level access.
   
       * The mapper can be customized in `rest_application.yaml` as follows.
           ```
           authorities:
             user: METRON_USERS_AT_ACME_CO
             admin: METRON_ADMINS_AT_ACME_CO
           ```
   
   * The Mpack was updated to allow a user to configure these role mappings.  
There is an additional "Roles" panel under Metron > Config > Security where the 
user can customize this.
   
   ## Testing
   
   These instructions are heavily borrowed from @jleet 
[here](https://github.com/apache/metron/pull/1246#issuecomment-433175628).
   
   1. Deploy this code in an environment like Full Dev.  
   
   1. Create an LDIF file to your local workstation at `/tmp/ldif/test.ldif`.
   
       ```
       version: 1
   
       # Please replace with site specific values
       dn: dc=hadoop,dc=apache,dc=org
       changetype: add
       objectclass: organization
       objectclass: dcObject
       o: Hadoop
       dc: hadoop
   
       # Entry for a sample people container
       # Please replace with site specific values
       dn: ou=people,dc=hadoop,dc=apache,dc=org
       changetype: add
       objectclass:top
       objectclass:organizationalUnit
       ou: people
   
       # entry for sample user metron admin
       dn: uid=admin,ou=people,dc=hadoop,dc=apache,dc=org
       changetype: add
       objectclass:top
       objectclass:person
       objectclass:organizationalPerson
       objectclass:inetOrgPerson
       cn: Admin
       sn: Admin
       uid: admin
       userPassword:{SSHA}DzE0WdguvPfBGXkoYSztB3DoXPRrT4LB
   
       # entry for sample user sam
       dn: uid=sam,ou=people,dc=hadoop,dc=apache,dc=org
       changetype: add
       objectclass:top
       objectclass:person
       objectclass:organizationalPerson
       objectclass:inetOrgPerson
       cn: sam
       sn: sam
       uid: sam
       userPassword:sam-password
   
       # entry for sample user tom
       dn: uid=tom,ou=people,dc=hadoop,dc=apache,dc=org
       changetype: add
       objectclass:top
       objectclass:person
       objectclass:organizationalPerson
       objectclass:inetOrgPerson
       cn: tom
       sn: tom
       uid: tom
       userPassword:tom-password
   
       # create FIRST Level groups branch
       dn: ou=groups,dc=hadoop,dc=apache,dc=org
       changetype: add
       objectclass:top
       objectclass:organizationalUnit
       ou: groups
       description: generic groups branch
   
       # create the admin group under groups
       dn: cn=admin,ou=groups,dc=hadoop,dc=apache,dc=org
       changetype: add
       objectclass:top
       objectclass: groupofnames
       cn: admin
       description:admin group
       member: uid=admin,ou=people,dc=hadoop,dc=apache,dc=org
   
       # create the user group under groups
       dn: cn=user,ou=groups,dc=hadoop,dc=apache,dc=org
       changetype: add
       objectclass:top
       objectclass: groupofnames
       cn: user
       description: user group
       member: uid=sam,ou=people,dc=hadoop,dc=apache,dc=org
       ```
   
   1. Launch a container running an LDAP server.
   
       ```
       docker run \
         -p 33389:389 \
         --name metron_ldap_demo \
         --env LDAP_ORGANISATION=Hadoop \
         --env LDAP_DOMAIN=apache.org \
         --env LDAP_TLS_FALSE \
         --volume 
/tmp/ldif:/container/service/slapd/assets/config/bootstrap/ldif/custom \
         osixia/openldap:1.2.2 --copy-service
       ```
   
   1. If running in Full Dev, run the following command to find the externally 
addressible IP.
   
       ```
       netstat -rn | grep "^0.0.0.0 " | cut -d " " -f10
       ```
   
   1. In Ambari make the following changes under Metron > Config > Security > 
LDAP.
   
       * Turn on LDAP using the toggle.
   
       * Set "LDAP URL" to `ldap://10.0.2.2:33389`.  Use the externally 
addressable IP from the previous step.
   
       * Set "Bind User" to `cn=admin,dc=apache,dc=org`.
   
       * Set "Bind User Password to `admin`.
   
   1. In Ambari make the following changed under Metron > Config > REST.
   
       * Set "Active Spring Profiles" to `dev,ldap`
   
   1. The following user/password credentials can be used to test authorization.
   
       * admin/admin-password
       * sam/sam-password
       * tom/tom-password
   
   1. Ensure that authorization is working.
   
       * Ensure that you can login to the Alerts UI.
   
       * Ensure that you can login to Swagger.
   
       * Ensure that the `/whoami/roles` endpoint returns the correct roles.
   
       * Ensure that only the admin user can delete settings in the Alerts UI 
with the [`DELETE 
/api/v1/alerts/ui/settings`](https://github.com/apache/metron/tree/master/metron-interface/metron-rest#delete-apiv1alertsuisettings)
   
   1. Stop the container running LDAP.  Clean-up any persisted state.
   
   1. Alter the LDIF file at `/tmp/ldif/test.ldif` and use the following which 
changes the group names.
   
       ```
       version: 1
   
       # Please replace with site specific values
       dn: dc=hadoop,dc=apache,dc=org
       changetype: add
       objectclass: organization
       objectclass: dcObject
       o: Hadoop
       dc: hadoop
   
       # Entry for a sample people container
       # Please replace with site specific values
       dn: ou=people,dc=hadoop,dc=apache,dc=org
       changetype: add
       objectclass:top
       objectclass:organizationalUnit
       ou: people
   
       # entry for sample user metron admin
       dn: uid=admin,ou=people,dc=hadoop,dc=apache,dc=org
       changetype: add
       objectclass:top
       objectclass:person
       objectclass:organizationalPerson
       objectclass:inetOrgPerson
       cn: Admin
       sn: Admin
       uid: admin
       userPassword:{SSHA}DzE0WdguvPfBGXkoYSztB3DoXPRrT4LB
   
       # entry for sample user sam
       dn: uid=sam,ou=people,dc=hadoop,dc=apache,dc=org
       changetype: add
       objectclass:top
       objectclass:person
       objectclass:organizationalPerson
       objectclass:inetOrgPerson
       cn: sam
       sn: sam
       uid: sam
       userPassword:sam-password
   
       # entry for sample user tom
       dn: uid=tom,ou=people,dc=hadoop,dc=apache,dc=org
       changetype: add
       objectclass:top
       objectclass:person
       objectclass:organizationalPerson
       objectclass:inetOrgPerson
       cn: tom
       sn: tom
       uid: tom
       userPassword:tom-password
   
       # create FIRST Level groups branch
       dn: ou=groups,dc=hadoop,dc=apache,dc=org
       changetype: add
       objectclass:top
       objectclass:organizationalUnit
       ou: groups
       description: generic groups branch
   
       # create the admin group under groups
       dn: cn=admin,ou=groups,dc=hadoop,dc=apache,dc=org
       changetype: add
       objectclass:top
       objectclass: groupofnames
       cn: acme_admin
       description:admin group
       member: uid=admin,ou=people,dc=hadoop,dc=apache,dc=org
   
       # create the user group under groups
       dn: cn=user,ou=groups,dc=hadoop,dc=apache,dc=org
       changetype: add
       objectclass:top
       objectclass: groupofnames
       cn: acme_user
       description: user group
       member: uid=sam,ou=people,dc=hadoop,dc=apache,dc=org
       ```
   
   1. Restart the container running LDAP.
   
   1. In Ambari make the following changes under Metron > Config > Security > 
Roles.
   
       * Set "User Role Name" to "ACME_USER".
   
       * Set "Admin Role Name" to "ACME_ADMIN".
   
   1. Restart the UI and REST service.
   
   1. Ensure that authorization continues to work.
   
   ## Pull Request Checklist
   
   - [ ] Is there a JIRA ticket associated with this PR? If not one needs to be 
created at [Metron 
Jira](https://issues.apache.org/jira/browse/METRON/?selectedTab=com.atlassian.jira.jira-projects-plugin:summary-panel).
   - [ ] Does your PR title start with METRON-XXXX where XXXX is the JIRA 
number you are trying to resolve? Pay particular attention to the hyphen "-" 
character.
   - [ ] Has your PR been rebased against the latest commit within the target 
branch (typically master)?
   - [ ] Have you included steps to reproduce the behavior or problem that is 
being changed or addressed?
   - [ ] Have you included steps or a guide to how the change may be verified 
and tested manually?
   - [ ] Have you ensured that the full suite of tests and checks have been 
executed in the root metron folder via:
   - [ ] Have you written or updated unit tests and or integration tests to 
verify your changes?
   - [ ] If adding new dependencies to the code, are these dependencies 
licensed in a way that is compatible for inclusion under [ASF 
2.0](http://www.apache.org/legal/resolved.html#category-a)?
   - [ ] Have you verified the basic functionality of the build by building and 
running locally with Vagrant full-dev environment or the equivalent?
   

----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
[email protected]


With regards,
Apache Git Services

Reply via email to