Security
Security
Core Commerce uses the Spring Security 3.0 to handle authentication, authorization, HTTP/HTTPS switching, RESTful web request authorization, and session fixation protection for the following Elastic Path Web Applications: Commerce Manager Server, Storefront Server, Search Server. We'll give you a quick overview of how Elastic Path uses Spring Security, but for more details we refer you to the Spring Security's comprehensive documentation: http://static.springsource.org/spring-security/site/docs/3.0.x/reference/springsecurity-single.html
Why does Elastic Path use Spring Security?
Spring Security is an open source access-control framework that is powerful and easily customizable. Some of the main reasons why Elastic Path uses Spring Security:
- Support for SHA-256 hashing
- AspectJ pointcut expression language support, which allows developers to apply cross-cutting security logic across their Spring managed objects
- Annotations support - including using Spring Expression Language
- Comprehensive support for RESTful web request authorization
- OpenID integration (the emerging single sign on standard for the Web)
- Session Fixation Protection
- Simplified namespace-based configuration syntax, which requires much less XML configurations.
How Spring Security Filters Works with Elastic Path
Spring Security uses standard servlet filters to apply its security services. The example below describes how a simple URL filter works with Spring Security and Elastic Path's SNAP it UP storefront.
SNAP it Up storefront servlet receives URL http://snapitup.com/storefront/edit-account.ep. The Storefront servlet filters the URL through the storefront's web.xml. In the web.xml, any URL pattern matching *.ep maps to Spring Security, so the URL is then filtered through Spring Security's security.xml. The URL pattern *edit-account.ep is set in security.xml to require a user to be logged in to access this address. The customerAuthenticationDao bean, which is the security.xml's authentication bean, checks if the user attempting to access the URL is logged in to the storefront and has sufficient privileges to access the *edit-account.ep URL. If the user is not logged in, the servlet forwards the user to the login page defined in security.xml. If the user is logged in and the user has privileges to the URL, the servlet forwards the user to the edit-account.ep address. See Authorization process and Authentication process for more information on the authorization and authentication processes.