I need to secure my Rest (https://spring.io/guides/gs/securing-web/),
But I need to secure only the if the access from outside my local network, from my local network I dont need to secure,
It`s possible to do this?
tks
One idea is to do IP Whitelisting. Then you can do a pre-authentication filter that for request coming from those IPs would pre populates the request with an Authentication object (like setting up a generic system session) as suggested by this answer: Spring Security: IP Address Whitelist Before Deferring to HTTP Basic Auth
Related
I have implemented spring security with a restful API using spring boot and everything work perfectly.
I wan't to prevent multiple login with the same username and password from the same client. how can I do that ?
The only approach that I can think of is to identify the clients by their IP and then only allow one login per client. Here‘s a tutorial on how to block accounts after several login failed attempts from the same IP / client.
http://www.baeldung.com/spring-security-block-brute-force-authentication-attempts
Maybe it could give you an idea on how to solve your problem.
Please be aware that there are some problems coming with this, like dynamic IP addresses (the user gets a new IP address after disconnecting) and if more than one user uses the same proxy and therefore all of them have the same IP address.
I have users in my db and each user has IP address. I must give access to site only users whose IP address exist in my db. Users not have login and password. They have phone number, id, details and IP address. When user open web page I detect his IP address, faind in db and I give access or deny access. If access successfully I need save this user to session.
Can I use spring security for this?
When I tried use spring security I saw that need login and password for it. But my user not have login and password.
You can, but I am unsure whether you should.
First, for common use cases, using IP based authentication is really poor security practice: only one element, and any admin of a single machine on the network can change its IP address and pretend to be someone else.
Assuming you have a real reason to do that, Spring security can easily to it. You will have to setup a custom authentication processing filter that would use the IP address to build a valid Authentication. It could derive from AbstractAuthenticationProcessingFilter or AbstractPreAuthenticatedProcessingFilter.
The filter could do the heavy job and directly put a fully authenticated authentication token in the SecurityContext obtained from the static methods of the SecurityContextHolder class. But the Spring Security way would be to only put a WebAuthenticationDetails in a custom Authentication token, pass it to the AuthenticationManager and let a custom AuthenticationProvider builds the fully authenticated Authentication.
I'm rather new with Rails and I decided to bust my own authentication system that checks for 3 variable constants: IP address, Rails session ID and HTTP client. The way I am getting those are:
ip_address = request.env['action_dispatch.remote_ip'].to_s
session_id = request.env['action_dispatch.request.unsigned_session_cookie']['session_id'].to_s
http_client = request.env['HTTP_USER_AGENT'].to_s
Basically, since this is for personal use (for my blog) only, all I want is a single user access at a time.
My question is besides the 'HTTP_USER_AGENT', how can one fake those pieces of information from my web app? Is it possible to send a different IP address and session ID to Rails? Just theoretically. I'd like a glimpse of what's possible here...
Thanks.
Anything that the browser sends can be forged from another browser to impersonate what your own browser is sending.
The only exception here is the remote IP address. That one is extracted from the connection by the web server and cannot be easily forged.
So using your authentication mechanism you might as well forget the session ID and user agent. Both are vulnerable to replay attacks.
So basically your method of protection then becomes IP address protection. That's fine for some simple personal pages, but if you store sensitive information on those pages you might want to think about using something more secure.
You can read the Rails Security Guide to get a better understanding of which attacks are possible and some basic security principles with Rails.
I use OAuth 2 for authorization and need to implement it in a load balanced cluster. I've considered a few approaches, but it seems there is no way around a centralized approach. Here are my thoughts:
1. Balancing using source IP
Caching the tokens on one server and balancing by IP would be ideal, however, the IP can not assumed to be static. So when the same user tries to access services that require authorization from another IP with a valid token, it will fail, because it is not cached on this machine. Also other devices logged in with this user will not reach the same machine.
2. Balancing using a load balancing cookie
Also not really an option, since it cannot be assumed that every client implements cookie storage.
3. Balancing using the Authorization header
Balancing by hashing the Authorization: Bearer token header is problematic, because the first request (for requesting the authorization token) has no Authorization header, thus, the following request might not hit the same instance.
My current approach is to use a central Redis instance for authorization token storage.
Is there an option left, where a centralized approach can be avoided?
I think you still have two options to consider.
One is to balance by session ID. Application servers usually can be configured to manage sessions either by cookie or a GET parameter added to every link, so it does not definitely needs cookie storage. Additionally, there are very few HTTP clients left that still do not implement cookie storage, so you may want to reconsider item 2 of your list.
The other one is using self-contained tokens, e.g. JSON Web Tokens (JWT) with signatures (JWS). Validation of self-contained tokens may not need central database, each server instance can check token signatures alone and extract authorization details from the token itself. However, if you need support for revoking tokens, you may still need a central database to store at least a blacklist of revoked tokens.
Though I cannot provide you a full-fledged solution, hope this gives you some ideas.
I have a single URL accessible through a servlet that I have locked down using Spring Security's DaoAuthenticationProvider. I now have the requirement that certain incoming IP addresses must be whitelisted and so are not requested to authenticate.
I can hack around this easily enough by overriding DaoAuthenticationProvider's authenticate method and bypassing the superclasses's implementation if the IP address matches a known IP address but this then only works when the sender of the request supplies a username and password (even if it's nonsense). Otherwise the provider doesn't get called.
What would be the best way to do this? Should I be using a filter to bypass the authentication procedure if a known IP address is incoming?
Could you just use the hasIpAddress() expression? We're doing that for what appears to be a similar case.
<security:intercept-url pattern="/services/**" access="hasIpAddress('192.168.1.0/24')"/>
I think the idiomatic Spring Security way to do it is to implement a pre-authentication filter that would populate security context with a valid Authentication object when client is in the whitelist. You can implement such a filter from scratch (for example, as here) or use AbstractPreAuthenticatedProcessingFilter (though it seems to be overcomplicated for your task).