Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 10 months ago.
This post was edited and submitted for review 10 months ago and failed to reopen the post:
Original close reason(s) were not resolved
Improve this question
Currently, we have a spring boot REST application connecting to a mysql database in which we have a table named "User" with several fields. Among them, the field "email" and the field "password" stored as sha256(email + plain_password).
We also have an endpoint named "login" that receives 2 strings: email & password. If a user with such an email exists, we proceed to calculate sha256(email + plain_password) and then compare against the one we have in the database. If the strings are equal, the identity is verified and a signed "token" (with expire time and more user related data) is issued and returned to the client.
Now, every time we need to "secure" any endpoint, we ask for a "token" in the request header of the http call. An Interceptor reads every header for every call and in case one of those headers is the issued "token", we verify the signature, the expiration time and the name for whom it was issued.
The "secured" endpoint also has a custom annotation that indicates which role is allowed to invoke it. So if the interceptor verifies the token and the token belongs to a user with the role annotated, then we proceed with the normal flow of the endpoint. Otherwise, we throw an UnauthorizedException.
Question: Does Spring Security provides "out of the box" a token generation / verification mechanism like the one described above?
You have implemented custom security model for authentication and authorization. If someone else is to look at your code, they would be able to eventually figure it out but they would have many questions. Spring security based implementation is easier to understand and extend. Spring security also provides support for testing.
If you were to switch to an oauth based auth model, you would have to do it yourself. Spring security would make this transition mush faster.
Related
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 3 years ago.
Improve this question
Previously I was using md5 for decryption but then later on I switched on to BCrypt which is a better alternative.
So Let's say I developed an API and in that there is a service for User Log In. I try to call this service using postman and by passing the required parameters i.e username and password.
Now, I don't know if its possible or not but what If some hacker intercepts my requests? If he can intercept it then that means he can see the plain password which I've sent in the request param, right?
What's the best thing to do here if it's possible? Do I have to pass in password encrypted in Bcrypt in the API?
P.s. I use JWT based authentication for my API's.
Use HTTPS instead of HTTP for your API requests. Then it is difficult or impossible for man in the middle attacks.
Always use post method instead of get or any other method to send confidential data
"Implementing the use of TLS and HTTPS would provide effective encryption and authentication of transmitted data to protect the website from Man-in-the-Middle attacks. This effectively obstructs the decryption of confidential data like authentication keys" << Read More.....
Closed. This question is not reproducible or was caused by typos. It is not currently accepting answers.
This question was caused by a typo or a problem that can no longer be reproduced. While similar questions may be on-topic here, this one was resolved in a way less likely to help future readers.
Closed 4 years ago.
Improve this question
I'm putting in place a Spring web server and I want my API to be secured with Oauth2 Password Flow. Everything seems to be working fine for the AuthorizationServer part (No problem authenticating and getting an access token) but on the ResourceServer part I keep getting the following error :
org.springframework.security.authentication.ProviderNotFoundException: No AuthenticationProvider found for org.springframework.security.web.authentication.preauth.PreAuthenticatedAuthenticationToken
Am I right in assuming that since any Oauth2 configuration is by nature split between the authorization server which grants the access token and the resource server which will check for this token validity, any access token granted by the AuthorizationServer to a client will be seen as some sort of pre-authentication by the Resource Server, and thus making it look for a provider able to support this kind of Authentication ?
If it is the case, what would be the best way to provide one ? I'm struggling to find any concrete example.
Or is my assumption wrong and the problem is coming from my setup being incorrect somewhere else ? Maybe I missed the part where I should make such a Provider available.
Thanks in advance !
I ended up solved my problem by starting over from a fresh configuration. It works well now, no more PreAuthentication related error. I am not sure exactly what I did wrong the first time but my configuration is simpler now than it was before, so I guess I disabled something I shouldn't have by trying too hard to give Spring something I thought was missing.
Anyway thanks for trying to help me #dur.
In Spring RESTful application I have User, Game and GameRequest resources. User can join a Game by sending a request. So far everything is ok. But how can I achieve that User accept a request? I thought about deleting GameRequest but then how can I know if User accepted or rejected request?
POST some parameter like accepted=true to GameRequest/xyz to change accepted attribute.
Or make GameRequestAccepted resource and then
PUT /GameRequestAccepted/xyz
But this will modify your GameRequest anyway (implicitly).
The web service(using POST) allows the requester to update details of a user.
The web service accepts the id of the user to be updated.
I think accpeting the id of the request as a parameter is risky. Someone could create a post request and
insert the id of any user and update the details of that user.
To ensure to an acceptable level that user details cannot be updated what are the options. Here is
what I think :
There is currently no security framework in place.
encrypt the request at the transport layer user SSL
encrypt just the id itself
To use https for secure transport is a good start.
Since you have tagged your question with "spring" and there is no security framework in place, I would suggest you take a look at Spring Security, which integrates nicely with Spring.
I used Spring and Apache CXF to create a REST webservices application. I'm using x.509 certificates to authenticate the users, and then a custom authorization service to get all of the user groups and details. I've implemented a custom UserDetailsService that extracts the user information and populates a UserDetails object. Part of the process of populating this object involves a request to the corporate authorization service. The authorization service is unfortunately a proprietary system, but at least they provide a Java API. The authorization service, among other things, returns a list of groups that the user belongs to.
I'm still in the development stage, but my observations so far seem to indicate that the UserDetailsService is called once upon initial connection. Then each request uses a cached authorization object.
So my question and potential problem are this... Corporate policy states that applications are only allowed to cache the users authorization details for a set period of time. So, how long does Spring keep these UserDetails objects cached before refreshing them? And, how can I control this cache time to make sure I comply with policy?
There was a ticket submitted for something similar to this request:
https://jira.springsource.org/browse/SEC-898
The advice in the ticket is to create your own filter than periodically sets the Authentication.setAuthenticated property to false, forcing a look up of the user. You might be able to achieve the same by setting a smaller session timeout