We just upgraded out app to spring 5. I'm using an ldap server and I wanted to know if I can encode the manager-password.
<ldap-server id="contextSource" url="ldap://n.n.n.n" manager-dn="myuser" manager-password="cleartextpassword"/>
The spring security encoding I've read is in regard to the authentication manager.. This would be more similar to encoding them in a properties file. I haven't found anything withing BCrypt that may do this for me..
My current option that I can think of would be to
1. Use bcrypt to encode the password and then extend the LdapSourceContext and decrypt it there.
2. add Jasypt to do the encryption/decryption
If there is anything in Spring 5 that I missed let me know.
I was just wondering if I had missed anything already in spring that may help.
I did end up using Jasypt. Everything I found with spring5 and Boot point to Jasypt.. It is simple to use..
Related
Preamble
I'm designing an API gateway for a Grails microservice federation. This issue seems related to a bunch of issues already filed in this repository but nothing provides a solution.
Versions and Configurations
Grails: 3.2.2
Tomcat: 8.5
Plugin versions:
compile 'org.grails.plugins:spring-security-core:3.1.2'
compile "org.grails.plugins:spring-security-rest:2.0.0.M2"
I'm using spring security rest plugin for only token authentication. I'm doing the authorization part myself by returning ROLE_NO_ROLES for all the users in getAuthorities(). I intercept all the requests and authorize the access based on my own authorization schema stored in DB.
Problem:
With these configurations and strategy, my code works as desired when I run it on my local system. When I deploy it on a server as a war file in tomcat, it works fine for all the requests to the gateway, i.e., for all requests of the pattern /umm/controller/action. Spring security context is there and the user is evaluated perfectly.
When I try to call other microservices by redirection with requests of the form /umm/microservice/controller/action, springSecurityService.getCurrentUser() and springSecurityService?.principal?.username start to return null. Although my token gets evaluated perfectly, yet I'm not getting any security context.
For details, have a look on this issue. The details for reproducing the bug are also provided in the aforementioned issue.
The whole project is available here.
Update: May 19, 2017
I tried deploying my war in a Tomcat on my local machine. This question and this question provide following solutions.
disabling tomcat cache
setting
grails.plugin.springsecurity.sch.strategyName = org.springframework.security.core.context.SecurityContextHolder.MODE_INHERITABLETHREADLOCAL
Nothing seems to work so far. SecurityContextHolder is returning null anyway. All the user retrieving functions of SpringSecurityService viz. getCurrentUser(), getPrincipal(), getAuthentication() and loadCurrentUser() return null.
Update: May 23, 2017
To narrow down the problem, I executed the standalone war using
java -Dgrails.env=prod -jar build/libs/mywar-0.1.war
Now for any non-umm request, I get a 404, page not found. I think the problem is with the production environment. The app works completely fine in the development.
Also tried grails run-app which works fine. To rule out the problem with the production environment, I created the war using grails dev war but to no avail. Nothing works so far for the war.
Update: May 25, 2017
I should probably ask this http://security.stackexchange.com but for the record, I'm asking it here too.
The answer provided by me below contains a workaround fix. The mechanism by which the fix works is explained in the answer. My question is:
Does this approach introduce any vulnerability or loophole in the security system?
Is this authorization schema safe or needs to be revised?
I'm authenticating through the plugin but authorizing myself. Can somebody bypass the security filters and hit the authorization interceptor directly? Because if someone can do that, he will only have to give me an admin's username in the same format as the token does and he'll have access to everything.
Workaround
I got a workaround fix to the problem. Since I needed only the username, I grabbed the rest token in my interceptor, decoded it and extracted the username out of it.
Here goes:
def extractUsername(def token){
Base64 coder = new Base64()
def tok = token - "Bearer "
def principal = tok.tokenize(".")
def dec = coder.decode(principal[1])
def sub = new String(dec)
def user = sub.tokenize(",")
def username=user[1].tokenize(":")
username = username[1]-"\""
return username-"\""
}
It worked for me because I didn't need to check the springSecurityService.Principal object. Had it been the case, I wouldn't have been able to get the username. springSecurityService.Principal and springSecurityService.getCurrentUser() are still returning null. The issue is not resolved yet. I'm answering because I didn't get even a single comment despite having a bounty. Answer to the original question is still welcome if anybody can explain why spring-security-plugin is behaving this way.
Edit: May 25, 2017
The workaround I used is based on the structure of the token and the fact that username is embedded in the token and token is simply base64 encoded.
This is the original token generated by spring security REST plugin for grails:
eyJhbGciOiJIUzI1NiJ9.eyJwcmluY2lwYWwiOiJINHNJQUFBQUFBQUFBSlZTUDBcL2JRQlJcL0RrRkJpbWdCcVpVNjBLVjBxeHlKanBsSVNwRXFLNmthc2xDcDZHSVwvM0lQem5iazdrMlNwTXBXQkFVU0xWSld2d0RlQmhROVF0VU5YNXE1OVp3aE91eUJ1c2ZYdTU5K1wvNTdNcm1EWWFYc2FhY1dIOFZHUXhsNzVKTlpleHdURFQzQTc5ektDTzBPYUl0UnpZcFFsY0g2OEVYZ0FsSGxsWUNMYlpIcXNKSnVOYXU3ZU5vYTBQTkN3ckhkOHdibW1XWUZcL3BIZitXTzFRYVwveEVvcUwzdkphaHN3RHdMUTVWSjIxSnlkWkJ5amRFR3pCV3pRSVU3YnZRb3BCdVVsak5oSnFFVmxLd25NQXFneWpMN1VaRXFSMlBoNGJYWnpISlI2NkN0QnpDVE1tUEkzWDlKT3RaWmRcL2ZPcHFRRXVcL0FKeW9QVW8wUGRQWGRRM1wvSDRUU1VFcGVaS21xV3VURlRFdDdnVEpcLzdSNHZIbDRlbW9Xd0tnVGw3Y1wvVTB4ZjlLQTBmbUhQMFwvem9yM1F3dU1KNndXc1Brakp6WHpCdks3UktmXC80OXZiTHlkWCsreWxTZG9qWDk5XC9IMHNwTmM4T21TbEttbVZVVE95TGFmdG05RTNuamJ2THhGb1oraHllcFFQcWpwTVhvVnFJZ3ByaGxyY1M0Ynd1ejc5ckI2bWFydmVtZUhUZXBzQ2poOGxXRHBCXC9reWQzS1wvRURSd2c1K0gxMGNQdnRKTkc5Z2VvK0pES240dVFMVXlwSWU2czluSjR2VnI3OE84aGpqWFwvb3Z4RG9UU3hZREFBQT0iLCJzdWIiOiJhZG1pbkRCIiwicm9sZXMiOlsiUk9MRV9OT19ST0xFUyJdLCJleHAiOjE0OTU3MTU3OTMsImlhdCI6MTQ5NTcxMjE5M30.MPEXURGhJo5s75LfUSm5ckG99Byc7FCLyj1gYZJu1zk
This is decoded version:
"principal":"H4sIAAAAAAAAAJVSP0/bQBR/DkFBimgBqZU60KV0qxyJjplISpEqK6kaslCp6GI/3IPznbk7k2SpMpWBAUSLVJWvwDeBhQ9QtUNX5q59ZwhOuyBusfXu59+/57MrmDYaXsaacWH8VGQxl75JNZexwTDT3A79zKCO0OaItRzYpQlcH68EXgAlHllYCLbZHqsJJuNau7eNoa0PNCwrHd8wbmmWYF/pHf+WO1Qa/xEoqL3vJahswDwLQ5VJ21JydZByjdEGzBWzQIU7bvQopBuUljNhJqEVlKwnMAqgyjL7UZEqR2Ph4bXZzHJR66CtBzCTMmPI3X9JOtZZd/fOpqQEu/AJyoPUo0PdPXdQ3/H4TSUEpeZKmqWuTFTEt7gTJ/7R4vHl4emoWwKgTl7c/U0xf9KA0fmHP0/zor3QwuMJ6wWsPkjJzXzBvK7RKf/49vbLydX++ylSdojX99/H0spNc8OmSlKmmVUTOyLaftm9E3njbvLxFoZ+hyepQPqjpMXoVqIgprhlrcS4bwuz79rB6marvemeHTepsCjh8lWDpB/kyd3K/EDRwg5+H10cPvtJNG9geo+JDKn4uQLUypIe6s9nJ4vVr78O8hjjX/ovxDoTSxYDAAA=","sub":"adminDB","roles":["ROLE_NO_ROLES"],"exp":1495715793,"iat":1495712193
The principal here is signed and encrypted but the username is not encrypted. So it can be easily extracted by the code given above.
I have a Spring Cloud Config app with the Spring Cloud Security dependencies. I'm trying to hit the /encrypt endpoint to encrypt a password.
According to the docs at http://cloud.spring.io/spring-cloud-config/spring-cloud-config.html#_key_management I believe I need to set a symmetric key using "encrypt.key". But I can't figure out where to put this; all combinations I've tried result in {"description":"No key was installed for encryption service","status":"NO_KEY"} when I attempt to POST to /encrypt.
If I POST a key to /key, the /encrypt works perfectly, so I'm pretty sure that everything else is setup correctly. It also works fine using the environment variable ENCRYPT_KEY, or by using a system property encrypt.key. I just can't figure out where to place the encrypt.key within a configuration file. Is there a sample on this?
Thanks #pVilaca, this is indeed what the documentation says, but setting the key in application.properties or application.yml won't work.
Through experimentation I've found that the only place you can set the encrypt.key property is an ENCRYPT_KEY environment variable, a system property, bootstrap.properties, bootstrap.yml, or calling the /key endpoint.
Not sure why application.properties or application.yml don't work in this case. Setting this key must have more of an impact on the startup process than it would appear.
Setting Spring Cloud Version to 'Brixton.SR5' worked for me. For some reason, setting 'encrypt.key' in either application.properties/yml or bootstrap.properties/yml in later Spring Cloud Version does not work anymore.
check properties tag of pom.xml file. If you are using version 2 or 3 of Dalston, change it to:
<spring-cloud.version>Dalston.SR1</spring-cloud.version>
and it should be working fine. In my case i was using version 3 and changing it to version 1 resolved the issue for me.
Reference:
https://github.com/spring-cloud/spring-cloud-config/issues/767
If you're using spring cloud with spring boot, that is the method that is described on the documentation that you mentioned, you've two 'main' properties files.
bootstrap.[properties,yml]
To modify the startup behaviour you can change the location of the config server using bootstrap.properties (like application.properties but for the bootstrap phase of an application context)
application.[properties,yml]
where the "application" is injected as the "spring.config.name" in the SpringApplication (i.e. what is normally "application" in a regular Spring Boot app)
source: Spring Cloud Config Documentation
So, it should be enough to set the encrypt.keyin your application.[properties,yml] file (or the alternative name if specified)
my project recently opted for LDAP authenctication from HTTP, is it possible to change them with out re-running the steps,. or pls let me know how we can do this.
It is possible, however you need to do some manual steps.
Please check out the following link for some hints (it is for OpenId to LDAP migration, but you need to do some manual work in the same database tables):
https://groups.google.com/forum/#!topic/repo-discuss/VMpG0k119AY
I am using Grails 2.3.2 and am trying to upgrade my Spring Security Core Plugin from 1.2.7.3 to 2.0.
I made all the import changes and got my app to start, but I was unable to login. One of the changes in 2.0 is that it uses the bcrypt algorithm for passwords, making all my old passwords useless. So, I went through the password reset process in my app and sure enough after that I could log in just fine.
But, I want to keep my old passwords for all my users, so I went and found the documentation for the 1.2.7.3 version of the plugin and looked up what algorithm it used: http://grails-plugins.github.io/grails-spring-security-core/docs/manual.1273/guide/12%20Password%20and%20Account%20Protection.html
According to these docs its default is SHA-256. So, I added that config change, yet I still cannot log in.
So, how can I migrate all my user's passwords to the 2.0 version of the plugin? As of right now it doesn't seem possible...
There's another change - the number of hash iterations. In 1.2.x the password was hashed once but in 2.0 it's hashed 10,000 times for password stretching - see http://grails-plugins.github.io/grails-spring-security-core/2.0.x/guide/passwords.html#hashing
Add this to revert to the old behavior:
grails.plugin.springsecurity.password.algorithm = 'SHA-256'
grails.plugin.springsecurity.password.hash.iterations = 1
So I have an application that works perfectly on my desktop, and also works perfectly when deployed to tomcat on a windows machine. However, when I attempt to use this application while deployed on the same version of tomcat, but on AIX, it fails to retrieve data out of LDAP.
A user is able to successfully authenticate, but the context is null. DirContextOperations is passed into my ContextMapper as null. Does anyone know what ports that need to be open to get this data or what other configuration may need to be done? Based on what I am seeing it has to be a server configuration issue somewhere.
If you are using Spring Security LDAP plugin then it will be easy to co-relate the below mentioned configuration in AIX with the app. I prepared few snapshots for the configuration so that I do not clutter the answer space here. Have a look at LDAP config in AIX and try to setup the same in AIX Server.
Now coming to the LDAP plugin, there is nothing much other than setting up a bunch of properties is required. Values for these properties will be available once the LDAP configuration is done in AIX (as mentioned in the above mentioned slide).
Note:-
After creating a standalone LDAP, you might need to add realm if the user is associated to a group. I have not mentioned the same in the slides since I do not have an active LDAP host available now.
UPDATE
Instead of using BindAuthenticator can you try switching to PasswordComparisonAuthenticator for authentication.
Using the below setting in Config forces to use PasswordComparisonAuthenticator to authenticate and return back the DirContextOperations. Can this setting be tried?
grails.plugins.springsecurity.ldap.authenticator.useBind = false
#Refer LdapAuthentication Implementations.
I am not sure if this will be the answer in your case. I was also getting null in DirContextOperations object when trying to obtain values from Active Directory.
I was trying to get ldap attributes like this as the Grails LDAP plugin Documentation states:
String mail = ctx.originalAttrs.attrs['mail'].values[0]
and all those were null. So I have changed the line above for this one instead and it works for me:
String mail = ctx.attributes.getAt('mail').values[0].toString()