Web applications Security Check List

Following a list of web security related functionalities that need to be implemented in a typical web application

• channel processing checks - redirect certain requests automatically to https and vice versa.
• maintain a list of urls which will automatically redirect to https
• concurrent session checks - user is not logged in more than once
• Http Session Integration processing - populate security context using http session, remembers prev authentication stored in session
• Logout checks
• Exception Translation checks - handles authentication and access denied exceptions
• Authenication processing - delegates to authentication entry point, filter and finally manager
• Authentication entry points and filters - http basic auth, http form based, http digest, X509 certificates, SiteMinder based
• login form url ; force use of https ; auth failure url ; default url if target url is blank
• Remember me checks - no need to relogin if revisiting website within http session timeout
• Anonymous processing checks - no need to login at all for accessing some resources
• Filter Security Interceptor - delegates to authentication manager and access decision manager
• access decision manager associates url / resources with roles
• Associates url / resources with roles
• authentication manager -> Authentication Providers
• Anonymous DAO based ; LDAP based ; Jaas based ; Remote ; X509 based

SOA Design - Service Coupling

Following figure depicts less-than-ideal service coupling. Service coupling can occur at various levels including at the persistence layer, where we can have services "being aware of each others data models, through query joins

---

Following figure depicts ideal services coupling. Services should be decoupled and should inteact with each other through "formal service interfaces"

---

A common problem in SOA deals with deciding data access with respect to services. Should each service have its own data model?Should one service be allowed to access another service data tables at cost of increased coupling?Should a common data access service be modelled?What about interaction / coupling between such a data access service and other functional services?

The following is one proposed approach for data access in context of SOA service design

The challenge here is to try and reduce:
the common data model size and keep it to minimal
the amount of access to common data model, instead prefering formal interfaces
the extent of access to common data model, prefer giving read access as compared to write access