We recently answered several questions relating to Skyway’s feature to generate Spring Security 2.0 as well as general questions relating to Spring Security itself.  Here is a FAQ listing of those questions.  To learn more about Skyway’s Spring Security feature in Standard Edition, please take a look at the Security Feature Page.

1. Before running Scaffolding > Scaffold spring security on the Spring DSL, Skyway requires that the user define a new Model package. Example video shows creating one named pkg.domain.security which Scaffolding then complements by creating a pkg.dao.security. Are there assumptions, limitations, or guidelines to where this domain.secuirty package should be placed (e.g. does the package have to be suffixed with security; does the dao package get created at the same level always)?
   Only assumption is if the package ends with “.domain”.  If so, Security Scaffolding places the DAO in a .dao package, and the Authorities and Users Domain Objects in the .domain package.
2. After running Scaffold spring security will all newly added and domain objects have their Service and DAO objects added to Secured Resources when they have their CRUD scaffolded?
   Yes, new Services and DAOs will automatically be added to the Secured Resources.
3. Skyway Project > Enterprise Configuration: What are the other Access values for Secured URLs and Secured Resources?
   Access can be used for Authentication and Authorization:
   Here are the 3 Authentication types:
   http://static.springsource.org/spring-security/site/docs/2.0.x/apidocs/org/springframework/security/vote/AuthenticatedVoter.htmlFor AUTHORIZATION, the Access string needs to be prefixed by “ROLE_” to indicate to  Spring Security that the Access is role based.  If the ROLE_  prefix is left off, deploy errors will occur. See example screenshot below.
   
4. Skyway Project > Enterprise Configuration: How does the Secured URLs work in general? Is the default rule /secure/* allow pre-authentication for pages in this URL and then NO access for all others or is the no-access assumed for all other URLs?
   In the “/secure/*” scenario, all access to anything under the /secure/ path will require authentication.  Other URL paths do not require authentication.One note to consider is via the springSecurityFilterChain in the web.xml, all requests, specified by the url-pattern will go through Spring Security.  If a request is not intercepted by the login form, the user will be an anonymous user, and the security context will have something like the following:
   org.springframework.security.providers.anonymous.AnonymousAuthenticationToken@9611881d: Principal: roleAnonymous; Password: [PROTECTED]; Authenticated: true; Details: org.springframework.security.ui.WebAuthenticationDetails@fffd148a: RemoteIpAddress: 127.0.0.1; SessionId: 478A01F999A8CD50D40E069428B71306; Granted Authorities: ROLE_ANONYMOUS(Invalid property ‘principal.username’) Errors
   Due to the above paragraph, this error may appear with pages that have not been authenticated, but use the sitemesh decoration because the login.jsp uses <sec:authentication property=“principal.username”/> which does not exist when the security context authentication is authenticated with an anonymous user.

   If the desired behavior is to remove Spring Security entirely from certain requests, the springSecurityFileChain url-pattern should match the intercept-url pattern in the security context.

   A good way to see the security context is use the code in the login.jsp page to create a sample page that displays the entire “auth” variable.

5. Skyway Project > Enterprise Configuration: Configured Views: The Skyway training video describes the out-of-the-box operation as using the spring provide screens for login challenge. Allowing these values to be blank. However there are several default generated pages in a Skyway project that seem to appropriate to wire in here. Can you provide details into what pages become obsolete when security is enabled and provide a general description of how the login URL navigation works? In essence walking through the URL navigation from index.html through the security scenarios would help.
   Security Flow(click to enlarge)
   
   Files involved in security:

resources/[ProjectName]-generated-security-context.xml	Central Spring Security config file. All configurations from the Spring DSL > Enterprise Configuration tab are emitted into this file.
WebContent/secure/welcome.jsp	Welcome page used after someone logs in. Used in the chain of Sign-in link (from login.jsp) to /spring_security_login to welcome.jsp
WebContent/pages/logout-redirect.jsp	Straight redirect to logout-success.jsp
WebContent/pages/logout-success.jsp	Static HTML page that states “You have successfully logged out of the system.”
WebContent/WEB-INF/sitemesh-common/login.jsp	Contains top “Sign-in” tab that changes based on if a user is authenticated.  Not authenticated: sign-in link that goes to the welcome.jsp.  Authenticated: Sign out link that goes to /j_spring_security_logout
WebContent/WEB-INF/decorators.xml	Two URLs are excluded: /j_spring_security_logout, and /pages/logout-redirect.jsp to prevent the sitemesh decoration framework from intercepting these URLs and adding the decorations to them.
/spring_security_login	Default URL path to sign in to Spring Security.  Displays the default Spring Security form.  This can be overridden via the Login View field in the Enterprise Configuration tab. (not an actual file in the project)
/j_spring_security_logout	Default URL path to logout/sign out of Spring Security. By Default this will go back to the /spring_security_login URL.  A logout success/error view can be added via the Enterprise Configuration > Configured Views fields. (not an actual file in the project)

6. Skyway Project > Enterprise Configuration: Security Information Source: Is there ever a case where the Connection in this section does not match the User & Authorities DAO connection?
   Only if a different connection is required for authentication rather than just CRUD operations.
7. Are there any required naming conventions for the authority names (e.g. ROLE_<name>)?
   The only recommendation is to avoid using the “ROLE_” prefix in the authority names.  Spring Security adds the “ROLE_ “, for internal purposes as explained in #3 above and #2 below.  For example, if the ROLE prefix is used, Spring Security will add another role prefix resulting in something like “ROLE_ROLE_ADMIN”
8. How do you apply the authority rules to the application? Is there a standard convention, approach to using them?
   See Question #3 above for URL authorization.
   For view element authorization, e.g. displaying buttons on a page only to ADMIN users, use the spring security tag library.  E.g.

   <sec:authorize ifAllGranted="ROLE_ADMIN">
        <input type="button" value="Save">
   </sec:authorize>
   

9. Security: What would happen if you had /secure/* secured, but tried to access a Secure Service via /*?
   As noted in the Securing Applications – Authentication recipe, (http://www.skywayperspectives.org/documentation/6.3/chunk/recipes/ch02s30.html), the Service and DAO Secured Resources section controls external access to those services.  It is assumed that the developer secures the entry point in the Web Application via the URL.  For example, if one of your services is a web service (JAX-WS tab on the service), and you have the Service checked in the Secured Resources pane, you will see an entry in the list of the securedServiceEndPointNames element in the resources/jaxws/jaxws-web-context file.
10. Why is the ROLE_ prefix emitted in the security config when DB is selected?
    From the Spring API docs: “If this is set to a non-empty value, then it is automatically prepended to any roles read in from the db. This may for example be used to add the ROLE_ prefix expected to exist in role names (by default) by some other Spring Security classes, in the case that the prefix is not already present in the db.” In other words, Spring Security expects the role to have “ROLE_” as a prefix, (like in the case for the intercept url authorization) so we generate this by default so developers can create any named role in the database without the need to prefix it with “ROLE_”.

Resources

Some good resources for Spring Security:

• Spring Security
• http://www.mularien.com/blog/2008/07/07/5-minute-guide-to-spring-security/
• (tutorial on Acegi Security, which became Spring Security in 2.5 – some concepts still apply):
  http://www.tfo-eservices.eu/wb_tutorials/media/SpringAcegiTutorial/HTML/SpringAcegiTutorial-1_1-html.html
• http://java-x.blogspot.com/2006/12/spring-security-with-acegi-security.html
• http://static.springsource.org/spring-security/site/docs/2.0.x/reference/springsecurity.html