Mechanism for Simplifying User Password Creation via Client-Side Applications

Once upon a time, I came up with an idea, which can probably be viewed as a major enhancement on top of what Firefox's built-in password manager already has to offer.

I developed this idea with both the common folks and the tech savvy in mind:

The aim is to reduce the number of unique passwords a user has to remember by employing an application to generate new ones on behalf of the user.
In the simplest use case, the user only needs to remember one unique password. The application will use the value provided by the user and a context value (that uniquely identifies the Service Providers with which to authenticate) to produce new passwords.

It got published in the Research Research Disclosure Journal in April 2007 under Disclosure Id: 516023.

All that remains is finding the time to implement it :p

As I dig deeper, it seems that a lot of plugins already do something similar with LastPass probably coming the closest.

How to list multiple encrypted passwords in properties files

Jasypt is an extremely useful toolkit for encrypting and decrypting passwords. It provides simple instructions for those who want to use Spring and load properties files with encrypted passwords in them.

But, what if you need to provide a whole series of usernames and passwords. How would you accomplish this?
Jasypt's out-of-the-box implementations only read one encrypted value per key=ENC(value) pair in a property file.

Here's a solution:

1. Override the EncryptablePropertyPlaceholderConfigurer's convertPropertyValue() method. Then you can split a list like the following:
   

   listOfUsernamePasswords=LIST(username1,ENC(encryptedPassword1),username2,ENC(encryptedPassword2))

   into separate values and only send the encrypted values to the parent convertPropertyValue() implementation to get the decrypted values.
   
2. Sew the list back together as a string and return a value that now reads:
   

   username1,password1,username2,password2

3. You may be wondering as to who will do the work of breaking up these comma-separated values when they get to your spring bean? The answer is simple: Spring will! For ex: If you had configured you spring bean like so:
   

   <bean id="someBean" class="com.MyBean">
       <property name="multipleUsernamePasswords" value="${listOfUsernamePasswords}" />
   </bean>

   and the multipleUsernamePasswords property is of type String[] in MyBean class, then StringArrayPropertyEditor will be used implicitly, which will break it up into a string array auto-magically. If you are interested, you can read this blog about how various structures interpret property values for Spring.
   
   
4. Now its up to use that String[] to your advantage in your code.
   

SSO, Pre Authentication & Spring Security 2.0.x

The Spring Security 2.0.x documentation does a great job of explaining:

• how the pre-authentication concept ties in with SSO systems,
• what classes are offered out-of-the-box,
• and how to configure them

but it doesn't explicitly state how the the preAuthN Provider is reading the authentication data accumulated by the preAuthN Filters.

One would imagine that there would be a default UserDetailService implementation as well, which can be configured with the preAuthN Provider but if you go looking into the UserDetail package summary, there is no such thing.

What to do? Well if we look closer, the AuthenticationUserDetailsService interface in the org.springframework.security.userdetails package is implemented by PreAuthenticatedGrantedAuthoritiesUserDetailsService which sits in the org.springframework.security.providers.preauth package.

This works out well but the spring documentation offers a "Siteminder Example Configuration" where they place the UserDetailsByNameServiceWrapper inside the preAUthN user details service and PreAuthenticatedGrantedAuthoritiesUserDetailsService is nowhere to be seen ... so it can seem a bit confusing as to how it should be used or where it should be specified.

I found my a clue through this forum entry and apparently PreAuthenticatedGrantedAuthoritiesUserDetailsService can be specified as the class attribute of the preAuthenticatedUserDetailsService property ... and the use of an UserDetailService is strictly optional depending on whether or not one needs to pull anymore information about the user.

That's all folks, hope this sends you on your way to a successful integration.

Ramp Up on Spring Security 2.0.x

1. What allows web.xml to leverage spring style configuration for Spring Security?
   Configuring a DelegatingFilterProxy in web.xml links the two together.
   
   
2. How does Spring Security simplify the use of DelegatingFilterProxy?
   Usually we would have to create a Filter and then configure it by naming its bean the same as the filter-name for DelegatingFilterProxy. BUT instead the process is simplified if we provide springSecurityFilterChain as the filter-name and use the <http/> configuration element, which auto creates a default springSecurityFilterChain for us.
   
   
3. Are the positions for the standard Filters in Spring Security always fixed?
   Yes.
   
   
4. What does the concept of "authentication mechanism" refer to in Spring Security?
   It refers to collecting authentication credentials/details from a user agent (usually a web browser).Examples are form-based login and Basic authentication. Once the authentication details have been collected from the user agent, an Authentication "request" object is built and then presented to the AuthenticationManager.
   
   
5. What is the function of an AuthenticationProvider?
   An AuthenticationProvider takes an Authentication request object and decides whether or not it is valid and then it will either throw an exception or return a fully populated Authentication object. Most AuthenticationProviders will ask a UserDetailsService to provide a UserDetails object. The resultant UserDetails object - and particularly the GrantedAuthority[]s contained within the UserDetails object - will be used when building the fully populated Authentication object.
   
   
6. What is the function of an AuthenticationManager? What are its benefits?
   An AuthenticationManager is responsible for passing requests through a chain of AuthenticationProviders. Each Provider will be fed its respective "authentication mechanism" counter-part and proceed to validate the request, therefore, having a chain allows us to support various forms of authentication.
   
   
7. What is the purpose of the <security:custom-authentication-provider/> element?
   AuthenticationProvider bean definitions can be marked for addition to the list maintained by AuthenticationManager using the <custom-authentication-provider/> element.
   
   
8. What is the major difference between the configuration for spring-security 3.0.x vs 2.0.x?
   TBD
   
   
9. How/Where does SecurityContextHolder store details of the principal currently using the application?
   By default, it uses a ThreadLocal to store these details. But you can choose between one the following modes:
   
   • SecurityContextHolder.MODE_GLOBAL
   • SecurityContextHolder.MODE_INHERITABLETHREADLOCAL
   • SecurityContextHolder.MODE_THREADLOCAL (default)
10. What can be used for storing a SecurityContext between HTTP requests?
    HttpSessionContextIntegrationFilter
    
    
11. What is the function of a ChannelProcessor?
    A ChannelProcessor will review the request, and if it is unhappy with the request (e.g. if it was received across the incorrect transport protocol), it will perform a redirect, throw an exception or take whatever other action is appropriate.
    
    
12. How do you decide whether a security check belongs in a ChannelProcessor or an AccessDecisionVoter?
    ChannelProcessor is designed to handle unauthenticated requests, whereas AccessDecisionVoter is designed to handle authenticated requests.
    
    
13. Question TBD
    Answer TBD