Grails Spring Security X509 for Authentication and LDAP for Authorities - authentication

Some pointers more than anything required here.
I'm trying to get both X509 and LDAP working in my application. I want users to be authenticated using their PKI certs and then for the APP to get their authorities from our LDAP server.
I have LDAP working with a customer userDetailsContextMapper at the moment however how to add the x509 properly stumps me a little.
I think what I want is a PreAuthenticatedAuthenticationProvider that uses an injected ldapUserDetails service.
How can I do that? Do I need a UserDetailsByNameServiceWrapper to wrap the LdapUserDetailsService up to be used within the pre-authentication provider?
I ask because unfortunately the testing platform and the development environment at the moment is detached, and I don't have local LDAP or PKI set up to test against so its about a 6 hour process getting a new war onto the dev environment... Restrictive I know... So I want to get it right first time.
Cheers!

NOTE: THE FOLLOWING WORKS WITH Spring-Security-Core v1.2.7.3, Configuration names are different in 2.0RC2
Following a few different ideas, this is what I came up with. This assumes you already have LDAP working with a custom and UserDetailsContextMapper (see: ldap documentation):
Ensure both the LDAP and a PreAuthenticatedAuthentication Provider are in the provider list:
grails.plugins.springsecurity.providerNames = [
'preAuthenticatedAutehnticationProvider',
'ldapAuthProvider',
'daoAutehnticationProvider',
'anonymousAuthenticationProvider',
'rememberMeAuthenticationProvider']
Then in your spring resources (grails-app/conf/spring/resources.groovy) configure the following beans:
ldapUserDetailsService(org.springframework.security.ldap.userdetails.LdapUserDetailsService,
ref('ldapUserSearch'),
ref('ldapAuthoritiesPopulator')) {
userDetailsMapper = ref('ldapUserDetailsMapper')
}
userDetailsByNameServiceWrapper(org.springframework.security.core.userdetails.UserDetailsByNameServiceWrapper) {
userDetailsService = ref('ldapUserDetailsService')
}
preAuthenticatedAuthenticationProvider(org.springframework.security.web.authentication.preauth.PreAuthenticatedAuthenticationProvider) {
preAuthenticatedUserDetailsService = ref('userDetailsByNameServiceWrapper')
}
And bobs your uncle and you have some aunts!
For reference the pages I used to come up with this solution are:
No AuthenticationProvider found using spring security
Wrap your LdapUserDetailsService in a UserDetailsByNameServiceWrapper
Instead of the LdapAuthenticationProvider configure a PreAuthenticatedAuthenticationProvider that will be able to process the PreAuthenticatedAuthenticationToken issued by your CustomX509AuthenticationFilter.
Inject the wrapped LdapUserDetailsService into the PreAuthenticatedAuthenticationProvider.
http://blog.serindu.com/2011/05/26/grails-spring-security-using-preauthenticated-authentication-provider/
Covers how to wire up a preAuthenticationAuthenticationProvider in grails
http://forum.spring.io/forum/spring-projects/security/108467-combine-pre-authentication-with-ldap-for-user-details-and-authorities
there's an LdapUserDetailsService that does all the good things the LdapAuthenticationProvider does - except for authentication
http://pwu-developer.blogspot.co.uk/2012/02/grails-security-with-cas-and-ldap.html more on how to wire up that ldapUserDetailsService
Hope this helps someone else!

Related

DNN LDAP Authentication with DNN.ActiveDirectory

I am having some trouble and need some help. I am trying to connect a website to authenticate to Active Directory through LDAP using DNN.ActiveDirectory, but I can only get the "Check Root Domain" portion to pass. Using ldp.exe on the server I am able to connect to the domain controller and query the users on it with the same user name and password I am trying to use with the plugin, and even using my domain admin account makes no difference. I have tried it with every authentication type, changing the root domain (only way that would get the check root domain to pass is the LDAP://domain.local), with/without the domain in front of the username, and with/without the default domain filled out.
I don't have access to the error logs at the moment since I am not at that office yet, so I will get those posted when I can. If I remember correctly the error being logged was an authentication error. LDAP initially wasn't configured on the domain controller so I had to set that up, and admittedly I am not too familiar with it so I followed this guide: https://techcommunity.microsoft.com/t5/sql-server-blog/step-by-step-guide-to-setup-ldaps-on-windows-server/ba-p/385362. I am using the default ports. I stopped before setting up LDAPS, but when I couldn't get that to work I continued through up to the signing the certificate part. I was working on getting the certificate signed when I came across notes that DNN.ActiveDirectory doesn't support LDAPS. My tests with successful connections using ldp.exe were all against port 389. Are there some extra configurations that are needed to get DNN.ActiveDirectory working that weren't covered in that guide, or any common snags I should be aware of?
DNN.ActiveDirectory has not been maintained for a while, and does not support LDAPS afaik - see Checking Root Domain step fails.
My recommendation is to have a look at AD-Pro Authentication.

Google Sign-in and Spring Security

I am ashamed to admit that I burned four full days trying to get Spring Security 3.1 to play nicely with Google Sign-in in a standard JSF web application. Both are awesome frameworks in their own right but they seemed incompatible. I finally got it to work in some fashion but strongly suspect that I have missed some fundamental concept and am not doing it the best way.
I am writing an app that our helpdesk uses to track system testing during maintenance activities when our systems are down and cannot host the app, so it is hosted externally. Our Active Directory and IdP are down during this activity so I cannot use our normal authentication systems. Google Sign-in is a perfect solution for this.
Google Sign-in works great in the browser using Google Javascript libraries and some simple code. The browser communicates with Google to determine if the user is already signed in, and if not, opens a separate window where the user can submit credentials and authenticate. Then a small bit of Javascript can send a concise, ephemeral id_token returned from Google to the server which the server can use to verify the authentication independently with Google. That part was easy. The beauty is that if the user is already signed into Gmail or some other Google app, authentication has already happened and Google does not challenge the user again.
Spring Security works great on the server side to protect specified resources and authenticate a user with a username and password. However, in this case, we never see the username or password - the credentials are protected by secure communication between the browser and Google. All we know is whether or not the user is authenticated. We can get the Google username, but Spring Security expects credentials that it can use to authenticate, to a database, in-memory user base, or any other system. It is not, to my knowledge, compatible with another system that simply provides yea-or-nay authentication in the browser.
I found many good examples online that use Spring Boot with EnableOAuth2Sso (e.g. here) but surprisingly few that use Spring Security in a standard app server which does not support EnableOAuth2Sso, and those few did not show any solution I could discern.
Here is how I've done it. I followed Google's simple directions here to provide authentication in the browser. I added this code to the onSignIn() method to send the id_token to the server.
var xhr = new XMLHttpRequest(); // Trigger an authentication for Spring security
xhr.open("POST", "/<my app context>/j_spring_security_check", true);
xhr.setRequestHeader('Content-Type', 'application/x-www-form-urlencoded');
var params = "profileID=" + profile.getId() + "&fullname=" + profile.getName() + "&email=" + profile.getEmail() + "&id_token=" + googleUser.getAuthResponse().id_token
+ "&j_username=" + profile.getEmail() + "&j_password=" + id_token;
xhr.send(params);
window.location.replace("/<my app context>/index.xhtml");
Unfortunately the Spring Authentication object, when passed to the AuthenticationProvider that I provided, did not contain anything but the j_username and j_password parameters as Authentication.getPrincipal() and Authentication.getCredentials(), but this is all I really needed. This is a bit of an abuse of those parameters since I have set them to email and id_token, not username and password.
I wanted to pass the user's full name and email, which Google provides in Javascript as googleUser.getName() and googleUser.getEmail(), to the backend as well. Since Spring Security does not accommodate anything but the username/password, and I was using Primefaces/JSF, I used Primefaces RemoteCommand to call a method on the backing bean with this information. This also feels a little clumsy.
In addition, I had to use window.location.replace() (in code above) because Spring Security did not redirect to my index.xhtml page as expected when I set this in the context with:
<security:form-login login-page='/login.xhtml' authentication-failure-url="/login.xhtml?error=true" default-target-url="/index.html" always-use-default-target="true" />
I have no idea why this does not work.
However, the app does now behave as I want in that it authenticates the user and the authenticated user can access the resources specified in Spring Security, and I wanted to share this in case anyone is doing a similar thing. Can anyone suggest a cleaner/better way? Thanks in advance.

Symfony 3.1: configuration of ldap component as service

I'm writing my first Symfony app and and I need authenticate users over LDAP/AD, but I run out of documentation...
I found many solutions for use LdapClient, but it tagged as deprecated. So, i check for use the new one Ldap class as recommended, but I not found documentation for use it. The documentation of Ldap component for the current version (3.1) suggest to use LdapClient yet! It isn't updated yet?
I don't know how to do: must we create an adapter for add a Ldap service? If so, how to proceed?
Any help will be appreciated, thanks!
Check out this cookbook article for configuring LDAP authentication using the builtin Symfony component:
http://symfony.com/doc/current/cookbook/security/ldap.html
I also have a bundle I maintain that includes LDAP authentication that works well with AD called LdapToolsBundle. It has documentation on the main page for the app/config/config.yml entries needed to configure your domain for use in the bundle, and also some details on configuring authentication in app/config/security.yml here.
The bundle above provides a LDAP service called ldap_tools.ldap_manager that can be used to query/create/modify different types AD objects.
take a look at my Blog:
https://alvinbunk.wordpress.com/2016/03/25/symfony-ad-integration/
This requires FOSUserBundle and FR3DLdapBundle, but I think if you go through all that documentation you should be able to get LDAP/AD integration with Symfony3 working.
EDIT #2
Below is a second easier solution:
https://alvinbunk.wordpress.com/2017/09/07/symfony-ldap-component-ad-authentication/

Authenticate against EJB via RESTeasy webservice

I am trying to setup a REST-webservice with RESTeasy that access EJBs that are deployed on a JBoss 7.1.1.
I've been successful in:
Setting up Beans to be accessed via REST
Configuring SSL for the connection
Setting up a PreProcessInterceptor that uses HTTP Basic Auth to ask the User for his credentials.
Currently I basically just check the credentials hardcoded in the interceptor.
This works to make sure that the User is authenticated, but our Beans query for the name of the currently logged in Principal for some Beancalls like this:
#Resource
private SessionContext context = null;
[...]
String userName = context.getCallerPrincipal().getName();
Currently userName is now always anonymous. What is the right way to set the caller principal? Do I do this in an Interceptor? Or in the Bean itself? My goal is to basically be able to call a method loginUserWithEJBOnJboss(String user, String pass) that uses the login-methods that are configured within the jboss and sets the principal correctly.
I am at a loss here, google didn't find anything. Maybe I am just searching for the wrong words.
So yeah, as always soon after asking I find the solution myself. I think sometimes I only ask because I know this will happen.
So the solution are these methods:
SecurityContextAssociation.setPrincipal(new SimplePrincipal(username));
SecurityContextAssociation.setCredential(password.toCharArray());
They do pretty much all I wanted :)

JAAS Authentication to Windows Domain

Using a provided username, password, and domain name, how can I retrieve a boolean value indicating if a user has successfully authenticated with a primary domain controller? Authentication should be performed using the Kerberos protocol for windows domain controllers. Thanks in advance, Dan
There's a free implementation of a windows-only JAAS login module and of an SSO Negotiate (Kerberos/NTLM) authenticator: Waffle.
You need to either write your own or use third party Authentication Module for that. When I was doing this, there was nothing available from JDK, so I used this tool. Note that it's GPL, but you can learn from there. You will have to create conf. file describing your authentication module and feed it into your JVM with java.security.auth.login.config property (e.g. using -D, or either way). In case of Tagish it looks something like this:
NTLogin
{
com.tagish.auth.win32.NTSystemLogin required returnNames=true returnSIDs=false defaultDomain="domain";
};
Another thing you will need is to specify kerberos configuration file via java.security.krb5.conf property. I don't have the details of this file handy, but you can easily find it on the net -- google about for krb5.conf. Settings in this file will have to match your windows domain and other windows specific settings.
It's a bit tricky to configure, but for me it worked very well, pretty robust.