Spring Security RememberMe & RESTful API

Ich versuche, eine API zu implementieren, die entlang der Linien von diese Anleitung

Der grundlegende Ablauf ist:

• mobile app bettet web-Ansicht zum Benutzer-login (normaler web-app-Sicherheit)
• auf "login", webapp gibt ein Sicheres cookie mit einem token
• mobile app verwendet das token in Zukunft alle API-Anfragen

So versuche ich sichere meine webapp zu normalen login-flow (mit Spring Security) über das login-Formular, und dann werden alle Anfragen an /api/** gibt die Authentifizierung basierend auf dem token übergeben-request-header.

Ursprünglich hatte ich begonnen, die Umsetzung dieser, indem er zwei web-configs - eine für die normale webapp-Sicherheit:

@Override protected void configure(HttpSecurity http) throws Exception {
        http
            .csrf()
                .disable()
            .authorizeRequests()
                .antMatchers("/resources/**").permitAll()
                .antMatchers("/sign-in").permitAll()
                .antMatchers("/success").authenticated()
                .anyRequest().authenticated()
                .and()
            .formLogin()
                .loginPage("/")
                .loginProcessingUrl("/loginprocess")
                .failureUrl("/sign-in?loginFailure=true")
                .permitAll();
    }

Oben nur definiert standard-spring security-Authentifizierung (custom userDetailsService zu bekommen userdetails von DB) und authentifizieren er login und Erfolg Seiten.

Dann noch (zwei Dateien nur für Klarheit/Einfachheit der Messung) für die API-Authentifizierung:

@Override protected void configure(HttpSecurity http) throws Exception {
    http
        .antMatcher("/api/**")
        .csrf()
            .disable()
        .authorizeRequests().anyRequest().authenticated().and()
        .addFilterBefore(authenticationTokenFilter(), BasicAuthenticationFilter.class )
            .sessionManagement().sessionCreationPolicy(SessionCreationPolicy.STATELESS).and()
            .exceptionHandling().authenticationEntryPoint(new Http403ForbiddenEntryPoint());
}

Die hat oben ein pre-auth-filter, der packt die relevanten HTTP-Header aus der Anfrage (token etc.) und fügt Sie an das Sicherheits-Kontext - die benutzerdefinierten Authentifizierungsanbieter dann prüft das token/user details.

Alles gut - aber es fühlt sich an wie ich bin, neu zu erfinden, ein paar Sachen. Angeschaut Spring Security ist RememberMe Funktionalität, es sieht aus, dass Sie bereits viel von dieser - auf login wird ein cookie mit einem token kann dann sein verwendet für die automatische Anmeldung auf zukünftige Anforderungen. Von die java-docs:

<bean id="rememberMeFilter" class=
 "org.springframework.security.web.authentication.rememberme.RememberMeAuthenticationFilter">
  <property name="rememberMeServices" ref="rememberMeServices"/>
  <property name="authenticationManager" ref="theAuthenticationManager" />
</bean>

<bean id="rememberMeServices" class=
 "org.springframework.security.web.authentication.rememberme.TokenBasedRememberMeServices">
  <property name="userDetailsService" ref="myUserDetailsService"/>
  <property name="key" value="springRocks"/>
</bean>

<bean id="rememberMeAuthenticationProvider" class=
 "org.springframework.security.authentication.rememberme.RememberMeAuthenticationProvider">
  <property name="key" value="springRocks"/>
</bean>

Das problem ist nur, dass ich die token in Zukunft Anfragen als header params, nicht ein cookie. Ich habe mir die Quelle für die oben genannten Klassen und die TokenBasedRememberMeServices Klasse autoLogin() Methode explizit untersucht die cookie. Der code wird auch verwendet, MD5 als Standard für das hashing.

Meine Fragen sind:

1. Ist es eine standard-Spring-Klasse, kann RememberMe
   Funktionalität request-Header anstatt cookies
2. Gibt es etwas, das verwendet einen besseren hashing-Algorithmus, der als MD5? (kann es sein
   leicht gewechselt werden ohne zwingende?). Oder, noch besser - ich komme
   über die KeyBasedPersistenceTokenService, die aussieht wie ein
   viel besser, token-generation service (SHA512 & zusätzliche info-Taste),
   gibt es gute Beispiele für die Verwendung, die zu erstellen/validieren
   sichere token.

Ich würde es vorziehen, nicht zu haben, zu erweitern, alle diese Klassen, als einen Haufen des Kerns wäre die gleiche, und scheint übertrieben zu haben, um Sie zu verlängern, nur um die Quelle von den token und den Hash-Algorithmus.