I'm using Spring Ldap and everything works fine except one point :
How can I enforce the password policy when updating a user password ?
I read that rootdn can bypass all policies. Is there a way to test a password against the policy before updating it?
Related
I'm working on a project to setup oauth2 authorization. I already have brief knowledge on authentication process for spring security, but here when i setup oauth, i'm wondering how to do the authentication part? as here i both need to authenticate the clients credentials and also the user credentials( user authenticate will be do by LDAP), as the grant type would be 'password'. and after authentication, the final authenticated authentication object would be the user with his/her authorities, instead of the client.
If you either use Resource Owner Credentials or whatever other grant type that could potentially take client(program) credential and user's credential when issuing a access token, then Authentication instance you are going to get from AuthenticationManager#authenticate() will be OAuth2Authentication. And inside of OAuth2Authentication, you'll able to see another Authentication which includes user's authentication information.
With that OAuth2Authentication, you can either manaully add logic to check different stuff you'd like to by accessing OAuth2Authentication itself by getting it from SecurityContextHolder.getContext()and then typecasting to OAuth2Authenticaiton, or simply use existing PreAuthorized annotation with SpringEL.
I am using symfony2.7 and I would like to authenticate my users whether by form login or by token in the url request. I am able to do both separately but how could I configure my firewall to be able to listen for both authentication methods whether user logs in by form or by token.
I recommend using a Guard. With a Guard it doesn't matter which authentication method you choose.
General question. Server admin setup SPNEGO. The LTPA bullet is marked under Global Security in admin console. My understanding is that SPNEGO captures username from an initial sign-on (ie network). Later, if user goes to an app's URL, few of the many things happening is SPNEGO is going through user's ldap groups (admin console-securtity roles) trying to find group that is tied to app's role names. If match is found, user authorized and can go directly into app without having to use login form to enter credentials. But have problem trying to implement this. Checking HttpServletRequest - getUserPrincipal().getName() and getRemoteUser() at front end of app are coming up null. If SPNEGO is in fact setup correctly, should a null ever be found?
You are confusing a few things. SPNEGO is a mechanism to pass user authenticated in the Kerberos realm to the given service without need to pass user password. It has nothing to do with authorization - this part is done by WebSphere security service based on the id retrieved from the request (in short).
Null username usually is effect of not enabling Application Security in the server or not protecting application with Java EE security (security constraints defined in the web.xml).
For some basic information about SPNEGO in WebSphere, check the following page Single sign-on for HTTP requests using SPNEGO web authentication
Setup
JBoss using LdapExtLoginModule to auth to Microsoft ADAM (Lightweight Directory Server)
Drupal using ldap_integration module to auth to the same Microsoft ADAM above
Url within JBoss realm that requires user to auth (again) using HTTP Basic Auth
Use Case
User logs in to Drupal , auth'ed by ADAM. At this point Drupal only knows the username (password is stored in Microsoft ADAM/LDAP)
User accesses secured URL within JBoss realm, and browser prompts for username and password. At this point we'd avoid the login prompt but how ?
Is there a way to link JBoss and Drupal session?
Hacky solution:
Remember the password that user entered into the password textbox while logging in to Drupal and use this to authenticate later.
Is there any better solution, maybe by introducing another security layer or something else?
Your hacky solution certainly seems to be the easiest. Have you looked into CAS?
http://drupal.org/project/cas
http://www.jasig.org/cas
I'm wanting to secure ELMAH in an internet facing application. The system uses Forms Authentication, but doesn't currently have any non-user accounts (e.g. Admins). The user accounts are set up in an automated fashion.
I don't really want to shoehorn any admin accounts into the system (the current DB schema for the users would be quite inappropriate for storing an admin user in), so I was thinking of corrupting the Forms authentication by checking for an SSL client certificate. If I pick all the right options in IIS, I believe I can ensure that only certificates issued by our internal CA (currently used for non-production sites needing SSL certs) will get passed through to ASP.Net.
I can then use the presence of a Valid ClientCertificate (checking IsPresent and IsValid properties of Request.ClientCertificate) to know that this is a connection from an internal user, and set the Forms Authentication cookie as "Diagnostic" or "Admin" (Or any other special username), and then secure elmah.axd using any of the usual methods suggested for doing it via Forms Authentication.
So my question is - am I overcomplicating things, missing something obvious, opening a massive security hole, etc?
Why don't you just store an admin user account credentials within Web.Config and lock down the URL using Forms Authentication anyway?
Edit
Ok, if the application is entirely internal anyway, why not secure a subdirectory of your site (e.g. myapplication.domain.com/exceptions/elmah.axd or even just myapplication.domain.com/elmah.axd) using Active Directory and set authorisation through IIS?