I am implementing a SAML authentication in a Spring project, with the spring-security-saml plugin and I achieved SSO without problems. Now I need to migrate a function in which we do a POST to another servlet in my app, where we previously managed the security with HTTP basic. We used org.apache.commons.httpclient.HttpClient library, in this way:
HttpState hs = new HttpState();
AuthScope autScope = new AuthScope("host", "port");
hs.setCredentials(autScope, credentials);
Now, since we do not have the password, I was wondering which approach should be used to fix that. I am getting a 302 response since it tries -logically- to redirect to my SSO page.
I read extensively the documentation of SAML but is difficult to me to understand where is the key. Maybe some work with SAML Assertion? Please give me some directions so I could read in a more precise way.
Thanks in advance!
Do I understand correctly that both the calling code and the POST endpoint are part of the same application? If so, I'm not sure why are you using an HTTP call instead of passing the call internally within the application.
In any case, one way to make it work is by sending JSESSIONID cookie of the authenticated user together with the POST call.
Related
In my application, user management is done through Keycloak. While testing my application end-to-end through Cypress, I came across an issue. When I sign up a user, it gives the following error:
We're sorry. An error has occurred, please login again through your application.
Cypress is adding something to a generated URL after I click the submit button, which is causing this issue. The same scenario tested through Protractor ran fine. I have noticed Cypress is appending session_code to the request URL. While doing manual testing, I don't get session_code.
Below is the URL generated through Cypress:
.../login-actions/registration?session_code=LsZbmsVVLwEH9s-xwFJ2JdDtaCu1_xzqAGOQCpjxGJI&execution=06fac3bb-fb19-474b-8659-2572586ae371&client_id=web_app&tab_id=PSlmfgdv0ls
Where as a manually generated URL is like following:
.../login-actions/registration?client_id=web_app&tab_id=PSlmfgdv0ls
My application backend is Spring Boot and the front-end is in React and Next.js.
It would be really helpful if anyone could guide us through this issue. Please let me know if you need more information about our application.
The Keycloak Authenticator documentation explains that the authenticate method checks the current HTTP request to determine if authentication requirements have been satisfied, and, if not, a challenge response is sent back. If the challenge response itself is authentication, then you'll see a URL with the session_code parameter.
It goes on to say that session_code, in the first URL example, pertains to the code generated from AuthenticationFlowContext.generateAccessCode(), which further explains:
String generateAccessCode()
Generates access code and updates clientsession timestamp. Access codes must be included in form action callbacks as a query parameter.
However, the "manually" generated URL, that does not include the session_code parameter, seems to indicate that the initial registration of the client has been successful and a client configuration endpoint is being used to make a GET request - a client read request - and all is well. Everything works fine.
Therefore, it seems that Cypress is being sent a challenge response (and potentially exposing a security flaw in your application). Possible reasons for this might be further explained within Cypress's documentation on Web Security.
Common Workarounds might provide you with a remedy, or, if all else fails, you might try Disabling Web Security for testing purposes as well.
I'm learning Web services. I have created an Rest API on local machine in eclipse. And the url looks like this http://localhost.com/Web/Test/Client
What It does is when I call this url as POST method with username and parameters in url's body, I get one token which I'm using somewhere else. Upto here its working fine. I pass username and password and I get a token once my API's code verifies the credentials coming in url's body.
So after that I read about security of Rest API so that no body could access my credentials which are coming with url. It says it needs to be converted into HTTPS from HTTP.
But I could not understand more how and where this security needs to be configured in my code. Do I need to write any code to achieve this or any settings are required ? I'm totally blank here.
Can anyone please help me to understand this and tell me what needs to be done to get HTTPS for my url ?
What you need to do here is create a self signed certificate and configure channel security. I highly recommend you to use spring security framework to get this thing done. This article will help you.
To require HTTPS for the login page modify your security configuration by adding the following:
http.requiresChannel()
.antMatchers("/login*").requiresSecure();
I'm very new to web security and I'm trying to implement CSRF Gaurd on my web application.
I have done all the required configuration on my web application and I can see that token (FWJY-N767-M4HG-DHXT-WCE4-5J08-MV4G-LNV4) is getting generated/injected when I do a ajax call or when a html page loads. I have notice that token is same on every request.
However, I'm not able to validate token at server side. According to my research it should go to CsrfGuardFilter.java class and validate the token but when I'm debugging I can see that it is not going to CsrfGuardFilter.java class and it not validating the request based on token. I'm getting the response for the requests which doesn't contain token also.
Can someone guide me to implement CSRF Guard properly on my web application. Thanks for your help.
In my web application I'm using GWT to generate front-end JavaScript after doing bit of research on various forum I have figured out that because of GWT generated JavaScript code token was not getting injected into any ajax call. So to implement CSRF guard over GWT code I need to inject the csrf guard script before the *.nocache.js script.
Helpful link
you have to declare CsrfGuardFilter, CsrfGuardServletContextListener and CsrfGuardHttpSessionListener in your web.xml in the correct location. In my application, I placed it after the session was created. Also, you have to define mapping for JavaScriptServlet.
NOTE : I used owasp csrfguard 3.1.0 in my application and I only had to define mappings for the above mentioned components. For older versions, you might have to define more properties/components.
I took help from the following example for my implementation :
https://github.com/aramrami/OWASP-CSRFGuard
I hope you got your issue resolved and my answer will help someone in future.
I'm struggling to design a SAML2.0 authentication for a REST API using a gateway. REST is used between my backend and my application. I'm using Java Servlet filter and Spring.
I see two possibilities:
Adding the SAML tokens into the header each time.
Authenticate once with SAML, then using a session or similar (secure conversation) between the client and the gateway.
Case 1: It's a good solution because we are still RESTful but:
SAML tokens are quite big. It's may generated problem due to big header size.
Replaying tokens is not the best way for security concern.
Case 2: It's no more stateless and I have to managed a link with the client. Since I use a gateway, the underlying services can still be RESTful.
Case 2 looks for the better choice despite the fact that it does not follow the rest constraints.
Is someone had already to do it and give me some pointers (for design or implementation)?
Is there a better way to do it with SAML?
Any help or advice are welcome.
It is still draft, but: the OAuth2 SAML bearer profile may a possible solution.
https://datatracker.ietf.org/doc/html/draft-ietf-oauth-saml2-bearer-17
Use a SAML2 to authenticate to an OAuth2 provider, then call your service with the OAuth2 token.
Also, you could generate a jwt token and put it inside of a SAML attribute: from this moment on you could pass the jwt inside of an http header.
It is sort of mixing oauth with saml but if you still need the latter for authentication it could be the way to go.
I'm hosting a REST web service in a Grails application, using Spring Security, i.e.:
#Secured(['IS_AUTHENTICATED_REMEMBERED'])
def save = {
println "Save Ride REST WebMethod called"
}
I'm calling it from an Android app. (Calling the unsecured service works just fine.)
To call the service, I'm manually building up a request (HttpUriRequest) and executing it with an HttpClient.
I'm wondering what the best practices are, and how to implement them... Specifically, should I:
Perform a login once, to retrieve a JSESSION_ID, then add a header containing it into the HttpUriRequest for each subsequent request?
Or (not sure how I would even do this) include the login and password directly on each request, foregoing the cookie/server-side session
I think I can get option 1 working, but am not sure if Spring Security permits (2), if that's the way to go... Thanks!
--also, there isn't any library I'm missing that would do all this for me is there? :)
Spring security does support both basic authentication and form based authentication (embedding the username/password in the URL).
A REST service is generally authenticated on each and every request, not normally by a session. The default spring security authentication (assuming you're on 3.x) should look for basic authentication parameters or form parameters (j_username and j_password) (in the form http://you.com/rest_service?j_username=xyz&j_password=abc).
Manually tacking the j_username/j_password onto the URL, adding them as post parameters (I believe), or setting the basic authentication username/password should all work to authenticate a REST service against the default Spring Security interceptors, right out of the box.
I will admit that I haven't tried this on REST services, though I do clearly recall reading exactly this in the docs as I did the same for basic page logins on spring security recently. Disclaimer over.
I think you can use a login-once-and-get-a-token method that's similar to how oauth works.
sending username and password across the network outside of secured channel(https/ssl) is a terrible idea. anyone on the network can sniff your request package and see the clear text password.
on the other hand, if you use a token method, since the token string is randomly generated, even the token is compromised, the worst case is someone can use the token accessing your REST API.
another solution is going through ssl tunnel(HTTPS). i have actually done a comparison and result shows: 80 requests/min(https) vs 300 requests/min(http)