Security

Owned by Xiaoyan Kong (Unlicensed)
Last updated: Oct 25, 2012Version comment
2 min read

Requirements
Reference Framework 2.0 runs against Nexaweb Platform 4.5.33 or higher.

Authentication

Reference Framework security is built to utilize Spring's security framework, which provides support for such things as JDBC and LDAP authentication.
The applicationContext-security.xml file contains the configuration settings. The sample we ship with, does DAO authentication against an in-memory DAO. The support for this is provided for by the Spring framework.

The login() call to the SecurityManager of the RefrenceFramework, will trigger the authentication as configured.  In your case you could configure this to perform authentication against your LDAP implementation.
Processing the result of the validation can be done by either handling the security events (onLoginSucceeded or onLoginFailed) or by configuring an error page that gets processed. 

See /security/LoginFailed.xml, which appends text to the login screen. 


Roles

Roles are stored in the SecurityManager as part of the UserDetails. The UserDetails is just that, a class designed to store information about the user. The BasicUserDetails calss, holds just the user name and the roles for the user. The idea is that this class could be extened to hold information like department, full name, address, etc.

The UserDetials are retrieved from the server after a successful login, by calling the getUserDetails() of the SecurityService class. The SecurityService is a Spring bean definied in the applicationContext-security.xml file. The implementation shipped with the example, will get the roles from the in-memory DAO and return it in a BasicUserDetails class. This would be replaced by a class implementing the SercurityService interface by returning the roles as looked up in the LDAP implementation.

A user can be assigned multiple roles.  For example,  DEPT_ENGINEERING;ROLE_CODER or DEPT_ENGINEERING;ROLE_MANAGER


Applying roles to UI elements

The role attributes on the page, menu items, command buttons and on component that make up the page, can be used to control whether or not the element is enabled/disabled, visible/invisilbe, or read only.

The concept was that the roles that make a a UI element visible or invisible, wouldn't change often (e.g. a menu item would be available to managers and not regular users).

More than one role can be assigned to a UI element. This is a semi-colon separated string. For example, ROLE_ADMIN;ROLE_USER.

The role voter can be configured to match all the roles (unanimous) or just match one of the roles (affirmative).  The role voter is configured in the security section of the nexaweb-refrence-framework.xml file. See more about roleVoter.

Choose below topics to learn more about Reference Framework Security: