Last time I've added to our project one more authentication provider in order to authenticate user through windows active directory server:
<security:authentication-manager id="authenticationManager" erase-credentials="true">
<security:authentication-provider ref="ldapActiveDirectoryAuthProvider" />
<security:authentication-provider ref="authenticationProvider1"/>
<security:authentication-provider ref="authenticationProvider2"/>
</security:authentication-manager>
<bean id="customLdapUserDetailsMapper" class="security.authentication.customLdapUserDetailsMapper">
</bean>
<bean id="ldapActiveDirectoryAuthProvider" class="org.springframework.security.ldap.authentication.ad.ActiveDirectoryLdapAuthenticationProvider">
<constructor-arg value="my.domain"/>
<constructor-arg value="ldap://my.custom.host:389" />
<property name="useAuthenticationRequestCredentials" value="true" />
<property name="convertSubErrorCodesToExceptions" value="true" />
<property name="userDetailsContextMapper" ref="customLdapUserDetailsMapper" />
</bean>
Alsmost work fine except existing integration tests that work with authentication flow. Namely each test tried to connect to server when ActiveDirectoryLdapAuthenticationProvider.bindAsUser then failed because my.custom.host is unavaible for this type of test.
I've started googling in order to find some mock for this type of test, but unfortunatly I found only this post Integration tests with spring-security and ldap where Luke Taylor recommended use existing integration tests as a guide. I've took a look into it but it doesn't contain any tests for this type of provider.
I'm new in such stuff and would be good to know the following things:
Will be it correct to reuse in any manner this approach with new ApacheDSContainer("dc=springframework,dc=org", "classpath:test-server.ldif"); that was mentioned in LDAP integration test(I am not sure wheter it suites to me because I didn't create ldap ebbedded ldap server in my application context and didn't specify any .ldif files in mentioned configuration as well).
In which way the following provider can be mocked in proper way?
Actually you just have to provide another configuration which will be loaded for Testing purposes. There you can define a different Authentication Provider, which for example just can authenticate everyone.... Or just simply deactivate Authentication at all.
Since you don't want to test the functionallity provided by spring.
Related
I have a Java JSF 2, Spring 3, Hibernate 4 Java EE Application which uses a third party library to authenticate the users. I imported the required CA certs into my JVM, added the third library to the project and configured in web.xml. The library reads the users details from smart card. This whole setup is working and users are taken to the home page by the third party library.
Here are my requirements to secure the application.
Check one more time if the user exist in the application specific database
Get the roles of that user from the application database
Protect my JSF pages
Protect my application services
I looked at this link and it seems "AuthenticationProcessingFilter" is deprecated and not applicable for Spring 3!
http://codersatwork.wordpress.com/2010/02/13/use-spring-security-for-authorization-only-not-for-authentication/
I also looked this one but I did not understand what other steps/configuration is needed.
spring-security: authorization without authentication
I would really appreciate if someone can outline what are all the items I need to implement Spring Security with Authorization only. This is what I came up with.
1) Update pom with spring 3 security, add a filter (which filter I should pick)
2) Custom User Detail
3) Custom DaoAuthenticationProvider
4) register this custom authentication provider in application-context.xml
5) register access decision managers for authorization
The base Spring Security classes suited for this use-case are org.springframework.security.web.authentication.preauth.AbstractPreAuthenticatedProcessingFilter and org.springframework.security.web.authentication.preauth.PreAuthenticatedAuthenticationProvider.
In case your current authentication library results in the user being authenticated in the standard Java EE way (i.e. calls to getUserPrincipal() on HttpServletRequest instance return the authenticated user's Principal) the things you need to do should be similar to:
Implement interface org.springframework.security.core.userdetails.UserDetailsService which checks that the user exists in your application database and throws UsernameNotFoundException if it doesn't
Add the following settings for the Spring Security:
<!-- Declare the user details for database check -->
<bean id="userDetails" class="com.yourpackage.DatabaseUserDetails"/>
<!-- Default empty auth manager -->
<security:authentication-manager alias="authenticationManager"/>
<!-- Use default settings from the jee namespace -->
<security:http>
<security:jee mappable-roles="IS_AUTHENTICATED_FULLY" user-service-ref="userDetails"/>
</security:http>
Configure your Spring Security to perform authorization based on your requirements
The security:jee initializes both a filter and authentication provider and plugs your user-service to the provider.
In case your current authentication library doesn't use Java EE mechanisms, you will need to implement your own subclass of the AbstractPreAuthenticatedProcessingFilter which knows how to recognize that the user has authenticated.
You would then replace the default pre-auth filter with your own, so the configuration would look like:
<!-- Declare the user details for database check -->
<bean id="userDetails" class="com.yourpackage.DatabaseUserDetails"/>
<!-- Define provider -->
<bean id="preauthAuthProvider" class="org.springframework.security.web.authentication.preauth.PreAuthenticatedAuthenticationProvider">
<property name="preAuthenticatedUserDetailsService">
<bean id="userDetailsServiceWrapper"
class="org.springframework.security.core.userdetails.UserDetailsByNameServiceWrapper">
<property name="userDetailsService" ref="userDetails"/>
</bean>
</property>
</bean>
<!-- Define alias for the authentication manager -->
<authentication-manager alias="authenticationManager">
<security:authentication-provider ref="preauthAuthProvider" />
</authentication-manager>
<!-- Declare the custom filter -->
<bean id="authenticationFilter" class="com.yourpackage.AuthenticationFilter">
<property name="authenticationManager" ref="authenticationManager"/>
</bean>
<security:http>
<security:custom-filter ref="authenticationFilter" position="PRE_AUTH_FILTER"/>
</security:http>
You can find some more details in Spring Security documentation.
Current Status
I using a CAS Server for SSO (Single Sign On).
I using Ozone Widget Framework as a CAS client.
I've setup an LDAP Server, being used for verification with Ozone Widget Framework
On the CAS Server I can authenticate with two LDAP and Active directory server.
I'm using an Spring version 3.0.5 and Spring Security version 3.0.2.
Problems
I can't perform similar functionalities to the LDAP Server with an Active directory Server on Spring Security.
The active directory server is completely pre-configured.
I can't use more than 1 LDAP/AD service at once.
I've searched Google for 'mapping LDAP/AD groups to Spring Security roles'
every result leads programming a Java Class
I can't find a valid method of role mapping without custom code.
In terms of the OWF Server, I found a number of mapping classes 'MapBaseAttributes2GrantedAuthoritiesMapper' and 'SimpleAttributes2GrantedAuthoritiesMapper' that theoretically provide the required functionality (LDAP/AD groups mapped
to roles) the only problem is both classes implement interface 'Attributes2GrantedAuthoritiesMapper' and 'LdapUserDetailsService'
requires a mapper interface type 'UserDetailsContextMapper'.
When using 'CAS Authentication Provider' (with 'ProviderManager' or 'authentication-provider' tag (research results)) the 'Authentication Manager' doesn't perpetuate to next 'CAS Authentication Provider'.
Examples (Interesting search results)
opennms
<beans:bean id="UserGroupLdapAuthoritiesPopulator" class="org.opennms.web.springframework.security.UserGroupLdapAuthoritiesPopulator">
<beans:constructor-arg ref="contextSource"/>
<beans:constructor-arg value="OU=SomeDept,OU=SomeOrgUnit"/>
<beans:property name="searchSubtree" value="true" />
<beans:property name="groupRoleAttribute" value="cn" />
<beans:property name="groupSearchFilter" value="member={0}" />
<beans:property name="groupToRoleMap">
<beans:map>
<beans:entry>
<beans:key><beans:value>myusersgroup</beans:value></beans:key>
<beans:list>
<beans:value>ROLE_USER</beans:value>
</beans:list>
</beans:entry>
<beans:entry>
<beans:key><beans:value>myadminsgroup</beans:value></beans:key>
<beans:list>
<beans:value>ROLE_ADMIN</beans:value>
<beans:value>ROLE_USER</beans:value>
</beans:list>
</beans:entry>
</beans:map>
</beans:property>
</beans:bean>
Handling roles when authenticated to active directory
Requests
I would like use Spring Security default classes to configure the following: -
Map LDAP/AD groups to Spring Security roles using only XML configuration (note: no custom code, such Java Class).
Verify if the above is possible or not (with unquestionable evidence).
I would like to know if 'MapBaseAttributes2GrantedAuthoritiesMapper' or 'SimpleAttributes2GrantedAuthoritiesMapper' can be configured with an Official Spring LDAP/AD library to achieve the first request.
Finally use 2 or more CAS Authentication Providers
I currently have spring security configured and working correctly. I want to get CAS working so I can have a single sign on across multiple apps I've written. I am confused how I can make cas use my custom userdetailService.
Currently I have this is my spring-security.xml
<authentication-manager alias="authManager">
<authentication-provider user-service-ref="userDetailsService">
<password-encoder ref="passwordEncoder">
<salt-source ref="saltSource"/>
</password-encoder>
</authentication-provider>
</authetication-manager>
From all the cas examples I have found they say to do implement the manage this way:
<beans:bean id="casAuthenticationProvider" class="org.springframework.security.cas.authentication.CasAuthenticationProvider">
<beans:property name="authenticationUserDetailsService">
<beans:bean class="org.springframework.security.core.userdetails.UserDetailsByNameServiceWrapper">
<beans:constructor-arg ref="userDetailsService"/>
</beans:bean>
</beans:property>
<beans:property name="serviceProperties" ref="serviceProperties"/>
<beans:property name="ticketValidator">
<beans:bean class="org.jasig.cas.client.validation.Cas20ServiceTicketValidator">
<beans:constructor-arg index="0" value="https://localhost:8443/cas"/>
</beans:bean>
</beans:property>
<beans:property name="key" value="1234554321"/>
</beans:bean>
<authentication-manager alias="authManager">
<authentication-provider ref="casAuthenticationProvider"/>
</authentication-manager>
The documentation is confusing. How do I go from a working spring-security app to one that implements cas and still use my custom user details? Also what do I need to change on the jsp pages? Any help would be much appreciated.
Thanks
I think you want CAS to authenticate the password using your own password+salt encoder.
Unfortunately, it is not a straight forward configuration and the configuration is not in your Spring apps.
You need to recompile CAS to include your custom password+salt encoder.
Thus, when Spring calls CAS for authentication, the same custom password+salt encoder will be used.
Fortunately, CAS team has created WAR Overlay approach so that it is easy for the user to recompile CAS server in order to include custom password+salt encoders
The documentation is here
https://wiki.jasig.org/display/CASUM/Best+Practice+-+Setting+Up+CAS+Locally+using+the+Maven2+WAR+Overlay+Method
You need to be very patient to follow the steps and make sure that your system has Maven2
You need not to download any library as Maven will take care of that.
The basic idea of WAR Overlay approach is to create a maven controlled folder where you can create subfolders to add your custom java libraries.
Maven will used to recompiled the custom java code together with the CAS files to produce a WAR file where you can publish it to a SSL server.
Just make sure that both CAS and your Spring Apps are using SSL.
Good luck!
Here are the steps I would recommend when setting up a CAS infrastructure
First of all, you should be aware of what CAS is, and how it works. Check out this article and the jasig-webpage.
Then download the examples from Spring Source, make the cas-sample run, and play with it to get a better feeling of it. (I'm not sure whether there is a readme file or you get infos on how to use it on the spring source webpage, but there is definitely info out there)
Make your app authenticate against this simple CAS-Server (find config examples on the CAS webpage)
Setup and configure your own CAS-Server that uses your current authentication system to authorize a user.
you may use the SAML protocol to transfer roles etc from the CAS to the client app after authentication
to apply the roles at the client app you may need to implement that on your own.
Adapt other apps to use the CAS-Server
I am creating a Spring MVC application which is a SOAP client. To communicate with SOAP web-service I am suppose to pass the login credentials. My application doesn't need to store any details dynamically and hence I am not using any db for this application. So kindly suggest a recommended practice to store the sensitive credential for my application. This credential will we managed by the system admin and must be easy for him to change according to the requirement.
Thanks in advance.
Store the username and password in a properties file external to your webapp spring context. That way the sysadmin can easily lock down read access on the properties file to the relevant parties (e.g. your application and himself). That should stop prying eyes seeing the password.
In your spring context have something like:
<bean class="org.springframework.beans.factory.config.PropertyPlaceholderConfigurer">
<property name="location">
<list>
<value>/path/to/config.properties</value>
</list>
</property>
<property name="ignoreUnresolvablePlaceholders" value="true"/>
</bean>
<bean id="myBean" class="...">
<property name="username" value="{usernameFromExternalPropFile}" />
<property name="password" value="{passwordFromExternalPropFile}" />
</bean>
The sysadmin will then also be able to change the username/password independently from a build.
See http://www.javaworld.com/community/node/8309/
The simplest option would be to store them in your application context XML configuration file as properties to the bean which is communicating with the SOAP webservice.
I have a web application using JPA and JTA with Spring. I would like to support both JBoss and Tomcat. When running on JBoss, I'd like to use JBoss' own TransactionManager, and when running on Tomcat, I'd like to use JOTM.
I have both scenarios working, but I now find that I seem to need two separate Spring configurations for the two cases. With JOTM, I need to use Spring's JotmFactoryBean:
<bean id="transactionManager"
class="org.springframework.transaction.jta.JtaTransactionManager">
<property name="userTransaction">
<bean class="org.springframework.transaction.jta.JotmFactoryBean"/>
</property>
</bean>
In JBoss, though, I just need to fetch "TransactionManager" from JNDI:
<bean id="transactionManager"
class="org.springframework.transaction.jta.JtaTransactionManager">
<property name="transactionManager">
<bean class="org.springframework.jndi.JndiObjectFactoryBean">
<property name="resourceRef" value="true" />
<property name="jndiName" value="TransactionManager" />
<property name="expectedType"
value="javax.transaction.TransactionManager" />
</bean>
</property>
</bean>
Is there a way to configure this so that the appropriate TransactionManager - JBoss or JOTM - is used, without the need for two different configuration files?
I think you have missed the point of JNDI. JNDI was pretty much written to solve the problem you have!
I think you can take it up a level, so instead of using the "userTransaction" or "transactionManager from JNDI" depending on your situation. Why not add the "JtaTransactionManager" to JNDI. That way you push the configuration to the JNDI where it is supposed to be instead of creating even more configuration files [ like there aren't enough already ;) ].
You can use PropertyConfigurerPlaceholder to inject bean references as well as simple values.
For example if you call your beans 'jotm' and 'jboss' then you could inject your TM like:
<bean class="org.springframework.beans.factory.config.PropertyPlaceholderConfigurer">
<property name="systemPropertiesModeName" value="SYSTEM_PROPERTIES_MODE_OVERRIDE">
<property name="location" value="classpath:/path/to/application.properties"/>
</bean>
<bean id="jotm">...</bean>
<bean id="jboss">...</bean>
<bean id="bean-requiring-transaction-manager">
<property name="transactionManager" ref="${transaction.strategy}"/>
</bean>
Then you can swap transaction managers using
transaction.strategy=jotm in a properties file
-Dtransaction.strategy=jotm as a system property
This is one possible approach. See my blog for a more complete example.
Hope this helps.
If you are using Spring 2.5 you can use <tx:jta-transaction-manager/>. I have not used it with JBoss but it should work for you according to section 9.8 Application server-specific integration from the Spring reference manual.
The <tx:jta-transaction-manager/> approach will look for a transaction manager in several default locations listed here. If your JBoss transaction manager is not in one of those locations, I suggest you move it, if possible, or move it in Tomcat so that both containers have their TM in the same JNDI location.
Just adding my experience here so I don't have to re-suffer the experience again.
As bmatthews68, Chochos and these posters have said, use <tx:jta-transaction-manager/> in your Spring bean file; it definitely provides the appropriate level of abstraction and there's no need to do anything extra on the Spring side.
As for Tomcat, I declared <Transaction factory="org.objectweb.jotm.UserTransactionFactory" jotm.timeout="60" /> in the default/shared conf/context.xml file, which binds to java:comp/UserTransaction. As this is one of the places searched for by Spring, you shouldn't need to do anything else.
One gotcha though: if like me you use Maven, make sure you exclude any dependencies on the javax.transaction:jta jar or set the scope to provided. Otherwise you will experience classloader issues.