Configuring Security with Cordys is easy or ..

Introduction

The last week we had to implement some Authorization functionality on Cordys BOP4 (CU9) services. During this journey I discovered that there were several ways in defining the security and this makes it very complex (if you’re a first user just like me). So this blog item describes some ways to define the security and my experiences.

Ways to Identify

Cordys supports several ways to identify users:

1. No identification is used, in this case this is mapped to an “anonymous” authenticated user within Cordys.
2. Cordys. The credentials are put in the soap header request and are mapped to a Cordys user.
3. WS-Security SAML. This can be used for single-sign-on
4. WS-Security User name token. The user puts its identity (user and password, clear text or encrypted are possible) within the soap header

This blog item uses the last with clear text user and password.

You can set Cordys identification within the LDAP Explorer:

1. Open LDAP Explorer
2. Goto Organization (HRM) > soap nodes > AddEmployee
3. On the right window, select “...” at the bussoapnodeconfiguration
4. Add <authenticator implementation="com.eibus.security.authentication.CARSAuthenticator" />

ACL

Access Control lists are used to define security at several levels. These levels can be:
* Service Group. This is best used when webservices are bundled and all of them should have the same restrictions. * Webservice interface. This is best used when the several interfaces need different restrictions. * Webservice operation. The restriction can also be set op webservice operation level.
In this example we use the unconditional ACL in which the security setting is put stactically on an object.

Defining security

This example uses the service as build within my previous post.
When you try to call this service from soapui:
<soapenv:Envelope xmlns:emp="http://www.examples.com/employee/" xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
  <soapenv:Header>
  </soapenv:Header>
  <soapenv:Body>
     <emp:Employee>
          <emp:EmployeeNr>1</emp:EmployeeNr>
          <emp:Name>Roger</emp:Name>
          <emp:LastName>van de Kimmenade</emp:LastName>
     </emp:Employee>
  </soapenv:Body>
</soapenv:Envelope>
you will get a soap fault that contains: <faultstring xml:lang="en-US">Anonymous access is denied for the method 'Employee'.</faultstring>

First we create a Role and a new User with no roles attached

1. Create Users Folder
2. Create HRMEmployee Role within this Folder
   
   

3. Publish the Users
4. Goto User Manager
   Note: This is also the place to remove roles and users, because when removed from the workspace and republish does not give the wanted effect. They are still within the LDAP (CARS). So remove them from within the User Manager.
5. Create a New User with no roles attached

Next we define the security on the AddEmployee service that the HRMEmployee Role is permitted to execute the webservice.

1. Goto Workspace > AddEmployee Service > EmployeeBinding
2. Right click Define Runtime Security
3. Add HRMEmployee Role, Save and Publish
   
   

4. When you run the service from within soapUI again you get the error:
   Access is denied for the method 'Employee'. This is because you did not give the new User the needed Role, so that is what you do next. Note: You can add the WS-Security name token within the Aut tab and then right click Add WSS Username Token, remove soapenv:mustUnderstand="1" and Nonce and Create elements.
5. Goto User Manager > Users Roles > Assign HRMEmployee to New User
6. Execute the service request again from soapUI and the service should execute

User Manager

When you goto the User Manager and select Roles - Roles you will see the Organization Roles.
Right-click on HRMEmployee > Security on you will see the defined ACL on the Role:

When you click on the “Key” you will see the actual ACL:

You see that the state is “open”. In case the webservice should be blocked it would be “blocked”.

Note that this is also the place to remove the binding of the Role to the webservice !!
When you remove the Runtime Security on the AddEmployee Service and republish again the service is still accessible by the New User. I think this is a bug within Cordys.

Define on Service Group level

You can also set the security on Service Group level in which case all services within that group have the same security settings.

1. Goto System Resource Manager
2. Show All Service Groups
3. Right click Define Security
   
   

4. Add HRMEmployee , Allow, and click OK

Note: If you goto the User Manager > Roles - Roles and Select HRMEmployee and right click Security you will see that two ACL sets are defined on this Role: