Grails 2.0

Only one property must be specified in SecurityConfig.groovy - 'active' defaults to false, so you have to change it to true to enable the plugin.

Other properties that are most likely to be overridden are the User, Role, and Requestmap class and field names:

If you want to send emails to newly-registered users, configure these properties:

URL attributes:

Attributes for rememberMeServices bean (cookie management):

To use LDAP, configure these properties:

To use OpenID, configure these properties:

To use Kerberos, configure these properties:

To use CAS, configure these properties:

To use NTLM, configure these properties:

To use Facebook Connect, configure these properties:

To use Channel security (declaring which URLs must use HTTPS or HTTP), configure these properties:

There are two ways to configure channel security, either using 'channelConfig' or 'secureChannelDefinitionSource'. If your configuration is simply a list of URL patterns that require HTTPS and a list that require HTTP (either can be omitted), e.g.

channelConfig = [secure: ['/admin/**', '/admin2/**'],
                 insecure: ['/foo/**']]

then specifying channelConfig is the better option. If you need full control over the configuration string then you can specify the entire thing as secureChannelDefinitionSource, e.g.

secureChannelDefinitionSource = '''
   CONVERT_URL_TO_LOWERCASE_BEFORE_COMPARISON
   PATTERN_TYPE_APACHE_ANT
   /admin/**=REQUIRES_SECURE_CHANNEL
   /admin2/**=REQUIRES_SECURE_CHANNEL
   /foo/**=REQUIRES_INSECURE_CHANNEL
'''

then specifying the full secureChannelDefinitionSource is the better option.

To use IP address restrictions, configure these properties:

For example, given this configuration:

ipRestrictions = ['/pattern1/**': '127.0.0.1',
                  '/pattern2/**': '10.**',
                  '/pattern3/**': '10.10.200.63']

then 'pattern1' URLs can only be access from localhost, 'pattern2' URLs can only be accessed from an intranet address, and 'pattern3' URLs can only be accessed from the one specified address. All other URL patterns are accessible from any IP address.

You can use either Ant-style patterns (e.g. 10.**) or masked patterns (e.g. 192.168.1.0/24 or 202.24.0.0/14), and can specify either IPV4 or IPV6 patterns.

Note that all addresses can always be accessed from localhost regardless of IP pattern.

Password encryption attributes:

Logout Handlers:

Spring Security allows you to register a list of logout handlers (implementing the org.springframework.security.ui.logout.LogoutHandler interface) that will be called when a user explicitly logs out.

By default, a 'securityContextLogoutHandler' is registered to clear the SecurityContextHolder. Also, if you're not using Facebook or OpenID, 'rememberMeServices' is registered to reset your cookie (Facebook and OpenID authenticate externally so we don't have access to the password to create a remember-me cookie). If you're using Facebook, a 'facebookLogoutHandler' is registered to reset its session cookies.

To customize this list, you define a 'logoutHandlerNames' attribute with a list of bean names. The beans must be declared either by the plugin or by you in resources.groovy or resources.xml. So if you have a custom MyLogoutHandler in resources.groovy, e.g.

beans = {
   myLogoutHandler(com.foo.MyLogoutHandler) {
      // attributes
   }
}

then you'd register it in SecurityConfig.groovy as:

security {
   ...
   logoutHandlerNames = ['securityContextLogoutHandler',
                         'rememberMeServices',
                         'myLogoutHandler']
}

Voters:

Spring Security allows you to register a list of voters (implementing the org.springframework.security.vote.AccessDecisionVoter interface) that check that a successful authentication is applicable for the current request. By default a 'roleVoter' is registered to ensure users have the required roles for the request, and an 'authenticatedVoter' is registered to support IS_AUTHENTICATED_FULLY, IS_AUTHENTICATED_REMEMBERED, and IS_AUTHENTICATED_ANONYMOUSLY.

To customize this list, you define a 'decisionVoterNames' attribute with a list of bean names. The beans must be declared either by the plugin, or yourself in resources.groovy or resources.xml. So if you have a custom MyAccessDecisionVoter in resources.groovy, e.g.

beans = {
   myAccessDecisionVoter(com.foo.MyAccessDecisionVoter) {
      // attributes
   }
}

then you'd register it in SecurityConfig.groovy as:

security {
   ...
   decisionVoterNames = ['authenticatedVoter',
                         'roleVoter',
                         'myAccessDecisionVoter']
}

Authentication managers:

The plugin registers autentication managers (implementing the org.springframework.security.providers.AuthenticationProvider interface) that perform authentication. By default, three are registered: 'daoAuthenticationProvider' to authenticate using the User and Role database tables, 'rememberMeAuthenticationProvider' to login with a remember-me cookie, and 'anonymousAuthenticationProvider' to create an 'anonymous' authentication if no other provider authenticates.

Also, if configured, one of 'kerberosAuthProvider', 'casAuthenticationProvider', 'ldapAuthProvider', 'facebookAuthProvider', or 'openIDAuthProvider' are registered.

To customize this list, you define a 'providerNames' attribute with a list of bean names. The beans must be declared either by the plugin, or yourself in resources.groovy or resources.xml. So if you have a custom MyAuthenticationProvider in resources.groovy, e.g.

beans = {
   myAuthenticationProvider(com.foo.MyAuthenticationProvider) {
      // attributes
   }
}

then you'd register it in SecurityConfig.groovy as:

security {
   ...
   providerNames = ['myAuthenticationProvider',
                    'anonymousAuthenticationProvider',
                    'rememberMeAuthenticationProvider']
}

Filters

There are four ways to configure filter chain(s). The default way is to use configuration attributes to determine which extra filters to use (e.g. Basic Auth, OpenID, etc.) and add these to the 'core' filters. For example, setting "useOpenId=true" adds an 'openIDAuthenticationProcessingFilter' filter to the filter chain (and in the correct order). The filter chain built here is applied to all URLs, so if you need more flexibility then you can use one of the other approaches.

If you'd like to define custom filters, remove a core filter from the chain (not recommended), or otherwise have control over the filter chain, then you can specify the 'filterNames' property to a list of strings, e.g.

security {
   ...
   filterNames = ['httpSessionContextIntegrationFilter',
                  'logoutFilter',
                  'authenticationProcessingFilter',
                  'myCustomProcessingFilter',
                  'rememberMeProcessingFilter',
                  'anonymousProcessingFilter',
                  'exceptionTranslationFilter',
                  'filterInvocationInterceptor']
}

As with the default approach, the filter chain built here is applied to all URLs, so if you need more flexibility then you can use one of the other approaches.

The most flexible approach uses the 'filterInvocationDefinitionSource' config attribute. This allows you to define the entire mapping of URL pattern(s) to filter chain(s). This is a string in the format that you'd use in a traditional Spring application, e.g.

filterInvocationDefinitionSource = '''
   CONVERT_URL_TO_LOWERCASE_BEFORE_COMPARISON
   PATTERN_TYPE_APACHE_ANT
   /**=httpSessionContextIntegrationFilter,authenticationProcessingFilter,…
'''
</value>

The fourth approach specifies one or more lists of filter bean names, each with a corresponding URL pattern, in a SecurityConfig map using the 'filterInvocationDefinitionSourceMap' property, e.g.:

filterInvocationDefinitionSourceMap = [
   '/urlpattern1/**': 'httpSessionContextIntegrationFilter,authenticationProcessingFilter,..',
   '/urlpattern2/**': 'httpSessionContextIntegrationFilter,authenticationProcessingFilter,..',
   '/**': 'httpSessionContextIntegrationFilter,authenticationProcessingFilter,..',
]

Additionally, you can specify 'JOINED_FILTERS' as the filter list for a pattern, and it will use the standard filter list that's configured in the default approach above.

Other miscellaneous attributes:

URL <-> Role configuration

The configuration options for configuring URL <-> role mappings are described here