Archive for January, 2009

Spring Security: Default AuthenticationManager der namespace-Konfiguration austauschen

Saturday, January 24th, 2009

Die namespace-Konfiguration legt einen eigenen AuthenticationManager an, der sich nicht über die XML-Konfiguration austauschen lässt:

You can’t use a custom AuthenticationProvider if you are using either HTTP or method security through the namespace, but this should not be a problem as you have full control over the AuthenticationProviders that are used.

http://static.springframework.org/spring-security/site/reference/html/ns-config.html (Kapitel 2.6).

Es gibt aber Situationen, wo man genau dies möchte. Beispielsweise im Osgi-Umfeld: In einem Bundle wird ein AuthenticationManager deklariert, der von anderen Web Bundles wiederverwendet werden soll.

Der Trick (bzw. der Hack) ist, dass die BeanId des AuthenticationManager genau “_authenticationManager” heissen muss. Wenn eine solche Bean existiert, dann verwendet die namespace-Konfiguration genau diesen AuthenticationManager statt einen eigenen zu erzeugen. Der Beanname wird in der BeanIds Klasse definiert.

Vorteil der Lösung: Copy&Paste wird in den Web Bundles reduziert.
Nachteil der Lösung: Man verwendet einen nicht-dokumentierten, implementierungsabhängigen Key.

Die Vorteile überwiegen jedoch. Credits für diese Lösung gehen an Eberhard Wolff (Springsource).

Spring Security 2.0.4 - namespace-based configuration. Teil 3.

Sunday, January 11th, 2009

Für jeden LDAP-Server wird mit dem ldap-server Tag eine DefaultSpringSecurityContextSource Instanz registriert.

  1. <s:ldap-server id="ldapA" url="ldaps://ldapA.ads"
  2.                 port="636"
  3.                 manager-dn="cn=LDAPAdmin, cn=Users, dc=ldapa, dc=ads"
  4.                 manager-password="1234"/>
  5.  
  6.     <s:ldap-server id="ldapB" url="ldap://ldapB.ads"
  7.                 port="389"
  8.                 manager-dn="cn=LDAPAdmin, cn=Users, dc=ldapb, dc=ads"
  9.                 manager-password="1234"/>

Jetzt fehlen für die beiden Server nur noch zwei AuthenticationProvider:

  1. <s:ldap-authentication-provider server-ref="ldapA"
  2.                 user-search-base="ou=Customer,dc=ldapa,dc=ads"
  3.                 user-search-filter="(sAMAccountName={0})"
  4.                 group-search-base="ou=Groups,dc=ldapa,dc=ads"
  5.                 group-search-filter="(member={0})" />
  6.  
  7. <s:ldap-authentication-provider server-ref="ldapB"
  8.                 user-search-base="ou=Customer,dc=ldapb,dc=ads"
  9.                 user-search-filter="(sAMAccountName={0})"
  10.                 group-search-base="ou=Groups,dc=ldapb,dc=ads"
  11.                 group-search-filter="(member={0})" />

Das ldap-authentication-provider Tag erzeugt einen LdapAuthenticationProvider mit einem BindAuthenticator und einen DefaultLdapAuthoritiesPopulator.
(Ein BindAuthenticator prüft ob Passwort korrekt ist, ein LdapAuthoritiesPopulator erzeugt GrantedAuthorities aus der Gruppenzugehörigkeit des Users)

Mit der namespace-Konfiguration werden diese Objekte automatisch erzeugt. Soll für eine der beiden Objekte eine eigene Implementierung greifen, so kann das ldap-authentication-provider Tag nicht verwendet werden. Hier kommt wieder das custom-authentication-provider ins Spiel.