Security creates barriers, while trust establishes confidence that an organization can deliver a portal or Web Services with advertised capability and with acceptable levels of risk. In the past organizations have protected enterprise assets by erecting high walls (firewalls) which prevent access at a transport level; it is assumed that inside the high walls everyone is to be trusted. Today, inadequacies of such assumptions are recognized. Firewalls are inadequate and more fine-grained control over access, usage and reporting is essential. Web Services provide fine-grained control, but have the potential to increase exposure to greater levels of risk.  This is why NeoSmartSuite™ was designed with the understanding that security is never absolute; the best technical security will always be under threat from determined individuals. NeoSmartSuite™ provides the required levels of protection that are relevant to a portal framework. 

NeoSmartSuite™ stores all user related data such as accounts, roles and permissions in a Microsoft SQL Server database. If forms authentication is used, passwords are encrypted (MD5) and stored in a database table. Strong Passwords can be enforced through the use of case sensitivity, and role privilege expiration dates. NeoSmartSuite™ can also be integrated into existing user store environments such as Microsoft® Active Directory, Microsoft® SQL Server user databases, LDAP, and 3^rd Party SSO solutions like Netegrity®.

NeoSmartSuite™ further enhances security by providing fine-grain control using Role Based Access Control (RBAC). NeoSmartSuite™’s RBAC Portal security is based on three key concepts; Authentication, Authorization and Privileges.

ID-Based Security (Authentication) - which determines if a user is trusted and tracks activities during their login session. After a user provides their credentials, NeoSmartSuite™ authenticates their identity and the system issues an authorization key to acquire the user’s identity. Subsequent requests from the browser automatically include the key. For example a user may have access to a module (application) on a page but will only see their own records.

Role-Based Security (Authorization) - which defines clearly who is authorized to access what. Provided through Access Control Lists (ACLs), these lists define which users and roles can access the portal, modules, and any electronic assets such as documents. For example, a user might have access to the portal, but have limited views to Pages and Modules (Applications).

Activity-Based Security (Privileges) - which defines who can perform what actions. Provided through Activity Privileges assigned to roles. For example, a user might have the privileges to perform administrative tasks as an Administrator of a particular Community or Module yet not be able to view/add/modify other areas of the page or portal.

Simply defined, RBAC enables a company to control WHO will have access to WHAT, and HOW much control should be given.