Type: New Feature
The current state of Java EE (Java EE Security, JAAS, JASPIC, etc) is geared towards defining application security constraints and security provider vendor pluggability. Actual authentication/authorization/security providers and role mapping is left non-standard.
This model is certainly viable in the case where these concerns need to be administered outside the application and role mapping is complex. The model also works well in allowing application server vendors to provide a broad range of features/security providers (and they clearly generally do). The main shortcoming of the model is that it leaves important parts of the application non-standard/non-portable, even for very simple, well-understood, widely used cases. Having to learn non-standard features also makes things more difficult for Java EE beginners. Perhaps most importantly, this model is problematic in cloud/PaaS environments where developers do not necessarily have easy access to non-standard vendor runtime features and a self-contained application is much easier to manage.
A simple way to address these issues is standardizing a small number of annotations to configure security providers that make some simplifying assumptions such as simple role mappings and only targeting the most common types of security providers. In fact, most application servers like Resin, JBoss and GlassFish already provide these sorts of simple security providers.
As a basic starting point, I suggest security providers for embedded security data, database storage and LDAP storage. Here are some examples:
This type of security provider is very useful for small prototype/RAD applications as well as unit/integration tests. Besides embedding user credentials, they could also be stored in XML, JSON, YAML or property files.
@DatabaseSecurityProvider(lookup="somedatabase", userQuery="SELECT password FROM principals WHERE username=?",
rolesQuery="SELECT role FROM roles where username=?", ...)
@LdapSecurityProvider(url="...", dnPrefix="...", dnSuffix="...", ...)
These simple providers could work additively with containers that already provide non-standard security providers, especially to cover cases beyond the very simple such as OAuth, OpenID, SAML, etc a well as complex role mapping.