Hello i am new to spring.
I am trying to connect to ActiveDirectory from my server using Spring-security1.3.0 spring2.0.1.
I am using the documentation example (18.4.5)
I can see the the LdapAuthenticationProvider object is constructed at page load in the application-context.xml. few Questions:
I wonder where and when will the answer from the Active directory returns?
I think i should see the result in UserDetails object. but how to see this? what code does this?
My goal is to get the user role from the Active directory and search my DB(in my server) what this role is permitted to do. So i would like to know what object contains the role of the user.
thanks,
You could try
SecurityContextHolder.getContext().getAuthentication().getAuthorities();
to see, if any roles (authorities) have been added to the current user (authentication). This should work no matter how you authenticate/authorize your users.
Spring security is a great framework for securing your applications. However, for everything a little bit more complex than the demos, it's best to get a good "feeling" for the basics first. Try to get an understanding how everything works together, before you implement something non-trivial like an LDAP-DB-based solution. It might take some time at first, but it definitely pays off.
Related
I am a relatively inexperienced programmer.
I have managed to build a web api which uses basic authentication as per the following:
https://weblog.west-wind.com/posts/2013/Apr/18/A-WebAPI-Basic-Authentication-Authorization-Filter which is working very nicely (forced over ssl obviously). Inside the OnAuthorizeUser i check the un/pw against an mssql database, via a call to an internal class called "DB" where all my database interaction occurs.
So all Controller methods are filtered by the Basic Authentication ("decorated" at the Controller level) however, access to certain Controller Methods also needs to be limited depending on the user - so there is a need to understand the user permissions. Based on my limited former ASP.NET experience I think I would have stored the relevant user details in a Session (or possibly cache) however I have so far steered clear of this based on wanting to stick to the concept of having a RESTful application etc
Rightly or wrongly, in playing around I realised I could use a private static (instance?) of my User class inside my internal DB class and populate it at the time of initial authorisation. I also added a public method (public User getThisUser()) to return the private User. From within my Controller methods I create an instance of DB and am able to check the values etc.
I was very worried that I would have issues with the "scope" of this "static" User, so to test, I created a Controller method to simply return the User information from DB.getThisUser(). In doing so I have found that I can log in as multiple different users (using different browsers concurrently for example) and each one consistently returns the correct user information (as logged in).
I'm still not entirely convinced this is "safe" however reading through the details of implementing something like ASP.NET Identity as a possible alternative makes my head spin and really seems like massive overkill in this case - I'm not using Entity Framework and after much searching I could not find a single example of NOT using an ORM (I need a solution to work with an existing DB).
Is this destined to fail? Do I go back to considering session or cache? Something else? I would really appreciate any feedback / advice on this from all of you who are more experienced than me. Thanks in advance for any help.
i think you're getting a bit confused.
an API is supposed to be stateless, meaning no session. Yes, you have a controller which translates into an endpoint.
You can hit an endpoint with all the information required to satisfy the request and this is it. Don't think of an API as an actual application where all requests are linked somehow. Instead, think of it at an application where each request is separate and can come from anywhere and any user.
How does the application know which user sent a request? Well, it doesn't unless you pass that information in.
You don't fire a request saying GetMeUserDetails. The api has no idea what you want. Instead you would say GetMeUserDetails for userId 12345. Now, since your request contains all the information required to satisfy the request, the API can now give you what you expect.
If some calls require authentication, you might use some sort of tokens to identify the user, but again, the information is passed in via the token.
You probably realize what static means and how it works. you are not going to see problems until you try to send two or more requests at the same time and then you'll realize that the first call now contains the details of the second request because well, static ...
I have to implement a login authentication & user registration feature for my product.
What is the standard and effective way of doing this using spring which would provide standard security (meaning nothing super fancy, but nothing easy to get around as well)?
As this has been done so many times there has to be a standard way to achieve this ?
The implementation should include :
user registration form after registering through g+ or fb etc
login form
storing user profiles, passwords, preferences in some backend
db or system
role management : different roles like admin would have
access to all etc
Standard : that which can put in production.
I found too many things scattered all around the net and although this seems like a broad topic its difficult to get started with especially when this going straight into production and not as a hobby project. The tutorials are always good to get started however are a starting point only. I want to know whats the best route or path that can be used for a product in production.
Securing a web application is not small topic, so you will need to read some tutorials.
You'll find very quick an easy to understand guides (with working examples)
at Spring Boot guides web site.
Spring Boot guides
Securing web application
JPA for your hibernate requirement
If you want going deeper you could read these great tutorials:
Spring security form login
In Parse.com client APIs, it is possible to perform create/update/delete on object of any class. It would be good to set a minimal level of security that restrict these operations only to requests that are made by a Parse.User. This way, someone with access to say your REST or JS key can't just spam create or delete a ton of objects in your database.
I have 2 working solutions but they seem a tad too complicated for something so simple. If you know of a simpler way to accomplish this on Parse.com, please let me know.
Solution 1: Create a RegularUser role and assign all your users that role. Set up class level permission to this role. Undefined users (from requests made without a user) naturally do not have this role, thus access is revoked.
Solution 2: Create beforeSave and beforeDelete cloud code for every class and reject all requests without a user.
I'm pretty new to Parse and I have a feeling that I've missed a simple setting somewhere that lets you lock down your data for logged in users only. Please point that out if that is the case. If you are experienced in Parse.com and in your experience, there is no simpler way, I'd appreciate the confirmation as well. Thanks
I'm answering this a bit late, but I thought I would answer to help out other readers. Like Akshay pointed out, you should definitely set the appropriate Class Level Permissions. But I think what you were getting at can be addressed through ACLs, as suggested by the Parse docs: https://www.parse.com/docs/ios/guide#security-access-control-lists
You can set different types of ACLs for each class, or if you only want to allow users to access their own objects, it's really easy to implement that across all classes:
To make it super easy to create user-private ACLs for every object, we
have a way to set a default ACL that will be used for every new object
you create:
In Swift for iOS:
PFACL.setDefaultACL(PFACL(), withAccessForCurrentUser: true)
I have this set up in my app's AppDelegate, which has the effect that any object the user creates can only be read/updated/deleted by that user.
I am trying to integrate two separate web applications - one is an existing custom web application with it's own security paradigm and the other is a reporting platform (JasperServer). I want to be able to use Jasper's web services interface to integrate the reporting functionality into our application. Our security model is complex and is home grown but I think there is hope.
We set a cookie that is an encrypted string containing a web service URI as the authentication source and a token which is stored in the database that is created when the user logs in and is destroyed when he/she logs out. I think I can leverage this to implement a kind of SSO in Jasper since it uses Spring Security.
What I THINK I should do is implement a pre-authentication filter that checks for the cookie I mentioned above. It could then decrypt it, make a web service call to the authentication source provided to verify the token is active in the database. If it is, that token can be used to point to user and role information that could be returned as a UserDetails object.
Unfortunately, I know enough to be dangerous but not enough to be effective. Am I on the right track? Does this solution sound tenable? If so, where would be a good place to start and are there any examples of something similar you could point me to? I've searched around quite a bit and have found nothing that quite fits the bill.
Thanks in advance to any and all who can provide me a glimmer of hope
Cookies are tied to a domain/subdomain/path and port. It is possible to set a cookie at the domain level so if you have something like webapp.mydomain.com and jasper.mydomain.com you may be ok assuming they are on the same port.
However be very careful about implementing your own SSO/Authentication framework. It requires a great deal of thought. As it stands your proposed implementation would be vulnerable to: replay, man in the middle, and XSRF attacks ... there may be other vulnerabilities but these are just 3 that come to mind ... sorry! :D
I'm using TurboGears with PyAMF behind a Flex client, and everything works well.
What I want to do is expose just a AMF login method to the world, and only allow access to other AMF functions once the user has logged in.
Also, once the user is known, I'd like the protected AMF methods to get the username from the auth information, so not every function has to start with the user_id.
Is there support for this sort of integration out there anywhere?
I have not done it, but I happened to have this bookmarked the other day via del.icio.us.
Hope it helps.
Using PyAMF With TurboGears 2
I ended up spending over a day hitting the /login url with html posts until it all worked. I couldn't use the repoze.who mechanism from within the Amf controller.
I don't think I'll choose Turbogears for my next project though... there have been problems with setup every time I've set it up, and having to do work-arounds like this is just because it's not a well thought out architecture.