I have jasig 3.4.7 installed with OpenLDAP and ssl enabled. I can login through CAS to an account created in the LDAP : fine.
Now I need to declare services via the management interface : I realized I've no "admin" account. So I tried to add a group "ADMIN" to my user. My first question : is it the right way ?
I've contextSource declared this way :
<bean id="contextSource" class="org.jasig.cas.adaptors.ldap.util.AuthenticatedLdapContextSource">
What do I need in order CAS to retrieve my user admin group. I tried :
<bean class="org.springframework.security.ldap.userdetails.DefaultLdapAuthoritiesPopulator">
<constructor-arg ref="contextSource"/>
<constructor-arg value="ou=Groups"/>
<property name="groupRoleAttribute" value="cn"/>
<property name="groupSearchFilter" value="(uniqueMember={0})" />
</bean>
But DefaultLdapAuthoritiesPopulator is incompatible with jasig AuthenticatedLdapContextSource.
What bean should I use instead. I've seen some people dont use jasig context source but default spring org.springframework.ldap.core.support.LdapContextSource instead. Is it correct ? Would it help ?
Thanks,
Related
In my Grails 3.3.10 application I'm using Spring security plugin , for a specific pages that got critical information I need the user to enter the credentials again although this user logged in before while entering to the application, Any ideas to achieve this.
You can configure this in your application.groovy. For example
grails.plugin.springsecurity.controllerAnnotations.staticRules = [
[pattern: '/', access: ['permitAll']],
[pattern: '/sensitivepage/**', access: ['ROLE_USER', 'isFullyAuthenticated()']]
]
Anything under /sensitivepage/ will require re-authentication.
It's explained in the Spring Security Documentation.
You can try to create a filter chain for endpoints that do need to log in again and register a custom filter. In that filter, you can revoke the existing token. Make these endpoints secure so that if a request comes without token then it would redirect the user to the login page.
Here is a sample code for your reference: (Please note that I haven't tried this scenario, it just a thought that I'm sharing here.)
<bean id="reauthenticateFilterChain" class="org.springframework.security.web.DefaultSecurityFilterChain">
<constructor-arg index="0" ref="reauthenticateResourceRequestMatcher"/>
<constructor-arg index="1">
<list>
<ref bean="reauthenticateFilter"/>
</list>
</constructor-arg>
</bean>
This is how you can register your custom filter chain.
<bean id="springSecurityFilterChain" class="org.springframework.security.web.FilterChainProxy">
<constructor-arg>
<list>
<ref bean="reauthenticateFilterChain"/>
</list>
</constructor-arg>
</bean>
I have a cas server that authenticate and send back some attributes corerectly. Now i want to add a service that check user roles in principal attributes and allow access to a service only if logged in user has the Specific role ( like admin role!).
I read about 'requiredHandlers' and thought it can help, but i can not make it work!
For service, i have something like this:
<bean class="org.jasig.cas.services.RegexRegisteredService">
<property name="id" value="1"/>
<property name="name" value="Admin panel service"/>
<property name="serviceId" value="http://localhost:8080/admin"/>
<property name="evaluationOrder" value="0"/>
<property name="ignoreAttributes" value="true"/>
<property name="requiredHandlers" value="supporterAuthenticationHandler"> <!-- this is what i found so far -->
</property>
</bean>
where supporterAuthenticationHandler is defined in authenticationManager
<bean id="authenticationManager" class="org.jasig.cas.authentication.PolicyBasedAuthenticationManager">
<constructor-arg>
<map>
<entry key-ref="proxyAuthenticationHandler" value-ref="proxyPrincipalResolver"/>
<entry key-ref="primaryAuthenticationHandler"><null /></entry>
<entry key-ref="supporterAuthenticationHandler"><null /></entry>
</map>
</constructor-arg>
<property name="authenticationPolicy">
<bean class="org.jasig.cas.authentication.AnyAuthenticationPolicy"/>
</property>
</bean>
And supporterAuthenticationHandler is a simple implemention of AuthenticationHandler (nothing implemented in it yet.
problem is i can not make cas to check supporterAuthenticationHandler so that i can go further (and probably fall into another hole where i need the new Principal with attributes).
Am i going completely the wrong way? Shall i check user role in my admin application? is it even possible to check roles with cas with different services?
This goes to the point that CAS is an authentication service not an authorization service. CAS only ensures that users are who they say they are not what they can do in an application (service).
please see this answer
https://security.stackexchange.com/questions/7623/can-central-authentication-service-cas-do-authorization
I have a sample Spring application for registering the student. I even created a SQLDB Service using Bluemix. I am unable to bind the service in the spring application in Jpacontext.xml.
If someone could please help me in providing the syntax how to call that would really help me.
The following entries in server.xml enabled me to connect my Spring application to SQLDB Service instance running in Bluemix.
I kept db2jcc4.jar and db2jcc_license_cu.jar in shared/db2 folder.
Please look at the credentials for SQLDB instance in Bluemix to get the database instance name, username, password and host ip address.
<jdbcDriver id="DB2JDBCDriver" libraryRef="DB2"/>
<library id="DB2" name="DB2 Shared Library">
<fileset dir="${shared.resource.dir}/db2" includes="*.jar"/>
</library>
<dataSource id='MyDataSource' beginTranForVendorAPIs="false" jdbcDriverRef="DB2JDBCDriver" jndiName="jdbc/MyDataSource" type="javax.sql.DataSource">
<properties.db2.jcc id='MyDataSource-props' currentLockTimeout="10s"
databaseName='<Database instance name>'
password='<password>'
portNumber='50000'
serverName='<host ip address>'
user='<username>'/>
<connectionManager connectionTimeout="10s" maxConnectionsPerThread="10" maxPoolSize="25" minPoolSize="5"/>
</dataSource>
Hope this helps !
I agree, I think we need more information to be of any real value, however, it may be helpful to begin by reviewing the link below which discusses the SQLDB service
https://www.ng.bluemix.net/docs/services/SQLDB/index.html#cli
and the following link which discusses how to bind to a service in Bluemix.
https://www.ng.bluemix.net/docs/services/reqnsi.html#config
If you still have problems after reviewing this material, then please provide a code snippet and the errors you're encountering.
You may refer to sqldb as JNDI resource. See more details on this here:
https://developer.ibm.com/answers/questions/178223/how-to-connect-to-db2-with-spring/
Taken from the link, example:
datasource-config.xml
<bean id="dataSource" class="org.springframework.jndi.JndiObjectFactoryBean">
<property name="jndiName" value="jdbc/[some-jndi-name-from-server.xml]" />
</bean>
<bean id="transactionManager"
class="org.springframework.jdbc.datasource.DataSourceTransactionManager"
p:dataSource-ref="dataSource" />
<bean id="jdbcTemplate" class="org.springframework.jdbc.core.JdbcTemplate">
<constructor-arg ref="dataSource" />
</bean>
<bean id="namedParameterJdbcTemplate"
class="org.springframework.jdbc.core.namedparam.NamedParameterJdbcTemplate">
<constructor-arg ref="dataSource" />
</bean>
web.xml
<context-param>
<param-name>contextConfigLocation</param-name>
<param-value>classpath:WEB-INF/datasource-config.xml</param-value>
</context-param>
<listener>
<listener-class>org.springframework.web.context.ContextLoaderListener</listener-class>
</listener>
basically what you need is JNDI name to refer, from server.xml path in your application:
Dashboard -> Your application -> Logs and Files -> app -> .liberty -> usr -> servers -> defaultServer -> server.xml
Than it's possible to refer to your "dataSource" bean in application.
I have a question in regards to
SSLHandshakeException talking to a https Web service using Spring WebServiceTemplate
answerd by borodark
"No need to import keys into keystore."
If we dont provide a keystore then what will Httpclient use for sending the Client certificate for SSL handshake ?
I have a requirement to invoke web services on a bussiness partner -
a) Authenticate using SSL using a public key certificate X
b) Encrypt and Sign SOAP messages using public key certificate Y
I guess I will need to specify certificate Y to the following :
<bean class="org.springframework.ws.soap.security.wss4j.Wss4jSecurityInterceptor">
<property name="securementActions" value="Signature"/>
<property name="securementSignatureKeyIdentifier" value="DirectReference"/>
<property name="securementUsername" value="mycert"/>
<property name="securementPassword" value="certpass"/>
<property name="securementSignatureCrypto">
<bean class="org.springframework.ws.soap.security.wss4j.support.CryptoFactoryBean">
<property name="keyStorePassword" value="123456"/>
<property name="keyStoreLocation" value="classpath:/keystore.jks"/>
</bean>
</property>
</bean>
I am not sure how/where to specify certificate X for SSL handshake. I think its the HttpClient but I dont see it in the XML posted by borodark.
Please help !
in the xml file where you have configured the keystore you should have something like this:
<beans>
<bean id="keyStoreHandler" class="org.springframework.ws.soap.security.xwss.callback.KeyStoreCallbackHandler">
<property name="keyStore" ref="keyStore"/>
<property name="privateKeyPassword" value="changeit"/>
</bean>
<bean id="keyStore" class="org.springframework.ws.soap.security.support.KeyStoreFactoryBean">
<property name="location" value="classpath:keystore.jks"/>
<property name="password" value="changeit"/>
</bean>
</beans>
the cue here is
<property name="location" value="classpath:keystore.jks"/>
that is the path to the keystore.. now, possibly you can use a certain alias inside the keystore for ssl handhshake (and that's what you configure here), additionally the security policy leverages on the same file, but then again in the securitypolicy file you can specify a different alias.. and that should do the trick..
Consider that while
<property name="location" value="classpath:keystore.jks"/>
indicates classpath you can use other form to reference resources outside the war itself, and that lets you change the certificate without touching the war at all..
I managed to authentify the user against the Ldap using the username found in the certificate. What I would like to obtain is to authentify the user using directly the certificate on the Ldap.
I cannot found how to pass the certificate to the Ldap.
here is the current config (using the certificate's username) :
<security:x509 subject-principal-regex="CN=(.*?)," user-service-ref="userService"/>
<bean name="userService" class="org.springframework.security.ldap.userdetails.LdapUserDetailsService">
<constructor-arg ref="ldapUserSearch"/>
<constructor-arg ref="ldapAuthoritiesPopulator"/>
</bean>
<bean name="ldapUserSearch" class="org.springframework.security.ldap.search.FilterBasedLdapUserSearch">
<constructor-arg value=""/>
<constructor-arg value="sAMAccountName={0}"/>
<constructor-arg ref="contextSource" />
</bean>
<bean name="ldapAuthoritiesPopulator" class="org.springframework.security.ldap.userdetails.DefaultLdapAuthoritiesPopulator">
<constructor-arg ref="contextSource" />
<constructor-arg value="" />
<property name="groupSearchFilter" value="member={0}" />
<property name="searchSubtree" value="true" />
</bean>
I was looking in to this issue myself. I have yet to find an authentication stack that does X509->account resolution "right". I got hung up on the fact that Spring Security's UserDetailsService interface insists on a string uid for lookup, but in many cases it is impossible to derive such a UID from the information contained in an X509 certificate's subject (e.g. there are many cn=John Smith in the world, or even within a single organization, nor is email required in a certificate DN). The uniqueness of a certificate lies in the Issuer + Serial Number combination, not the Subject.
After looking through the API there are a couple ways to go about this. Either way probably precludes using the namespace and setting up the filter chain and beans yourself:
1) Implement your own AuthenticationUserDetailsService and bind this to the PreAuthenticatedAuthenticationProvider. By default, I believe, the namespace sets up a UserDetailsByNameServiceWrapper using the passed-in user-service-ref. Going this route means you have to do everything to set up the UserDetails, including granted authorities resolution. Of course you can delegate all this, but its more work.
2) If your LDAP store is keyed by some UID, and this is the route I am leaning towards, implement your own X509PrincipalExtractor and bind it to the X509AuthenticationFilter and return the string uid that your LDAPUserDetailsService is configured to expect. Within the extractor implement the logic to search your LDAP store for the stored certificate. I do not know of any strategies that will work across LDAP servers, the easiest way would be if your LDAP supports RFC4523 certificateMatch or certificateExactMatch and you can configure a search filter that will return you a unique account from which you can then return the attribute you need (e.g. sAMAccountName). If not, if your certificates contain a value that you can filter on (e.g. certificate cn = LDAP cn) that you can use to retrieve a candidate set of LDAP results for, extract their certificates to X509Certificate and do .equals() against the passed in certificate to find the account that matches and return its uid.
Set up the LDAP server to use SSL with client authentication.
Finally, I've implemented the following sollution in my NON-web application :
<bean id="x509ContextSource" class="org.springframework.security.ldap.DefaultSpringSecurityContextSource">
<constructor-arg value="ldap://hostname:389/DC=base,DC=com" />
<property name="authenticationStrategy">
<bean class="org.springframework.ldap.core.support.ExternalTlsDirContextAuthenticationStrategy">
<property name="sslSocketFactory">
<bean class="yourOwnSocketFactory"/>
</property>
<property name="shutdownTlsGracefully" value="true" />
</bean>
</property>
</bean>
where yourOwnSocketFactory takes the user's certificate to establish the TLS connection.
A successfull TLS connection means the user is authenticated. That's the case with a well configured LDAP, which should check the user including certificate revokation list.
Once the connection established, you have to recover the user's informations with a custom BindAuthenticator which could extract (X509PrincipalExtractor) Certificate DN (or other usefull info) to match the LDAP user.