Security
The Sports Sponsorships Engine (SSE) on which the SAP Sailing Analytics and the SAP Tennis Analytics are based, uses Apache Shiro to implement security. This in particular includes authentication and authorization. This document does not aim to replace the Shiro documentation which is available, e.g., at http://shiro.apache.org/configuration.html, http://shiro.apache.org/permissions.html and http://shiro.apache.org/web.html.
Users, Sessions, Roles, and Permissions
Users are identified in an authentication process. This can currently be a username/password login implemented by posting a form, through HTTP basic authentication (an "Authorization: Basic " HTTP header field) or by using an OAuth-like bearer access token that can be obtained by an authenticated user through a RESTful web service. OAuth-based authentication by external OAuth providers and SAP ID is planned (see [Bug 2482](http://bugzilla.sapsailing.com/bugzilla/show_bug.cgi?id=2482)).
The response for an HTTP request by an authenticated user contains the JSESSIONID cookie whose value is the session key. Our sessions have a default timeout of 30 minutes which is provided as the Shiro default (see org.apache.shiro.session.mgt.DefaultSessionManager.DEFAULT_GLOBAL_SESSION_TIMEOUT and its use in the org.apache.shiro.session.mgt.SimpleSession constructor). Each request performed with this session key will renew the session timeout.
Logging out, e.g., by invoking the /security/api/restsecurity/logout service, invalidates the session key, and a new authentication will be required to obtain a new session.
An authenticated user has zero or more roles and zero or more immediate permissions assigned. Roles, in turn, can imply more permissions which are added to the immediate permissions to result in the complete set of permissions the user has. Roles and immediate permissions are stored persistently in an instance of com.sap.sse.security.UserStore and can be dynamically adjusted during application run-time.
The inference from roles to the permissions implied by those roles happens by implementations of the com.sap.sse.security.shared.PermissionsForRoleProvider interface. Authentication is mainly performed by so-called "Realm" implementations. SSE provides an abstract base class com.sap.sse.security.AbstractUserStoreBasedRealm. It supports setting a PermissionsForRoleProvider. Additionally, a PermissionsForRoleProvider can be used with com.sap.sse.security.ui.shared.UserDTO.getAllPermissions(...) so that UI clients can have the same set of permissions inferred for a user that the Shiro back-end will use for permission checks, so as to enable an disable UI features based on the user's permissions.
How to Configure
Shiro security is largely configured by shiro.ini files in OSGi Web Bundlesand their WEB-INF/web.xml descriptors. Shiro web security hinges on the use of servlet filters that are configured in web.xml. The corresponding section to enable Shiro security for a Web Bundle looks like this:
<context-param>
<param-name>shiroEnvironmentClass</param-name>
<param-value>org.apache.shiro.web.env.IniWebEnvironment</param-value>
</context-param>
<listener>
<listener-class>org.apache.shiro.web.env.EnvironmentLoaderListener</listener-class>
</listener>
<filter>
<filter-name>ShiroFilter</filter-name>
<filter-class>org.apache.shiro.web.servlet.ShiroFilter</filter-class>
</filter>
<!-- Make sure any request you want accessible to Shiro is filtered. "/*"
catches all requests. Usually this filter mapping is defined first (before all
others) to ensure that Shiro works in subsequent filters in the filter chain: -->
<filter-mapping>
<filter-name>ShiroFilter</filter-name>
<url-pattern>/*</url-pattern>
<dispatcher>REQUEST</dispatcher>
<dispatcher>FORWARD</dispatcher>
<dispatcher>INCLUDE</dispatcher>
<dispatcher>ERROR</dispatcher>
</filter-mapping>
For this to work, the Web Bundle requires at least the two bundles org.apache.shiro.core and org.apache.shiro.web which are provided by the target platform. Furthermore, the bundle should require com.sap.sse.security so as to get support for the common user store, session replication support and the common roles and permissions management.
The Web Bundle then provides a shiro.ini file in its classpath root, e.g., directly within its src or resources source folder. The shiro.ini file contains essential configuration information about which realms, which session and which cache manager to use. It also configures URLs for login pages, default success pages and permissions required for access to URLs. The file com.sap.sse.security/resources/shiro.ini serves as a reasonable copy template. In the [urls] section the shiro.ini flie provides so-called filter chains for specific or pattern-based sets of URLs. In particular, the configuration can require the authenticated user to have specific roles and / or specific permissions to access the URL. Note the use of the AnyOfRolesFilter and how it is different from the regular roles filter.