I'm learning spring oauth2 framework, and want to custom users and clients by using database storage, but I'm very confuse about one thing, the interface of both userdetails and clientdetails have a field "authorities", are they the same things? if not how can I specify the authorities about my protected resource separately with user and client? if they point to the same thing, which one is useless? By the way I use annotation to configure the application.
Related
I am currently using Token based authorization via OWIN to keep my APIs from being exposed to everybody.
However, there is a flaw attached to this method. Once a user gets a token, he can access any API across my website and get the response for any parameters posted; which is dangerous in my case.
Right now, I need to give API access to my mobile application but I want to strengthen the security of my APIs in such a way that the requests are filtered based on user access.
Use case:
I generate a token when the user logs in and will append it with each request to the API. It works absolutely fine but... the generated token can be used to fetch the details of any other user.
What I want to achieve:
I want to prevent the above case from happening. I want to filter the illegal requests/responses to/from API.
How do I go about it? How do mobile apps generally restrict users from accessing their API. I am very interested to know about it. Please guide me.
What you have implemented till now is only authentication part, it is not going to help you much for securing your website, to implement security in proper way you need to do proper authorization also.
For this you need to implement following things.
RBAC - Role Based Access Control in your web api actions, by this you can achieved using the default Authorize filter provided by the framework.
For example
[Authorize(Roles = "Administrator")]
public void DoSomething()
{
}
If you are using OWIN, you can set the roles in GrantResourceOwnerCredentials method like following
identity.AddClaim(new Claim(ClaimTypes.Role, "Administrator"));
Data Level Security: This is very important, as people belonging to same role can access only a set of data, to implement this type of security, the best place is your database. You can implement Row Level Security/Cell Level Security in your database, or you can restrict the access of data based on logged in user from your database directly.
Implementing Data Level Security is not straight forward as it is driven through your business requirements (Who can access what). Out of the box no framework will be able to give you complete solution, you need to implement rules by yourself only.
Apart from above two points, you can also consider looking Cross-Site Request Forgery (CSRF) and Data integrity between server and client.
I have an MVC4 ASP.net financial application with a WCF service. The current scenario isn't secure enough and I need you help with that.
The current scenario:
The user login using a login form, and I send his login details using a JSON object containing the UserID and the Password to the WCF service:
http://example.com:22559/Login
This returns a JSON object with a true or false.
If it's true, I use the ASP function
FormsAuthentication.SetAuthCookie(loginModel.UserID, loginModel.RememberMe);
to set authorization cookies to use it later.
When the user adds a new Transaction I send a JSON object containing the transaction details without the password to:
http://example.com:22559/AddTransaction
I depend here that the MVC controller will not allow the user to access the transaction page if he isn't logged in.
The problem is anyone can now sneak-out and add a transaction without entering the password!, using the URL:
http://example.com:22559/AddTransaction
What I need to do now, is to make the WCF service itself secured, but I don't know how to do that without making the user enter his username and password each time he adds a new transaction!, so, what is the proper way to do that?
Thanks in advance.
MVC 4's controllers typically use MemberShipProvider for authentication and RoleProvider for authorization. So your WCF services may share the providers.
For authentication, you don't need to do anything in WCF codes. For authorization, it is handy to decorate respective operation implementation function (not interface) with PrincipalPermissionAttribute with the Role name defined. The rest will be done in config and by runtime.
For more details, just search "membershipprovider wcf", you will find a lot articles/tutorials in MSDN, CodeProject and StackOverflow.
Please be mindful that in MVC 5 if you will be moving to MVC5, Identity 2.0 is used by default, and MembershipProvider and RoleProvider will not be their by default. Nevertheless, your WCF codes should remain unchanged, and only some elements under ServiceModel will need to adapt the new custom authentication and authorization, and the client codes should remain the same as well, no config change needed.
I'm writing an admin panel in ASP.NET for an existing set of web service calls. My goal is to use some of the existing login stuff (locking out pages if your not logged in) etc but using my login mechanism. This works by hitting an http post request with a username and password, if you're good you get a session id back, if not you get a 401. Here is the WCF for that:
[WebInvoke(UriTemplate = "/Login/", Method = "POST")]
public String Login(User user)
{
// If we are good return sessiond id
// Otherwise throw 401 etc
So to get this working in ASP.Net what is needed?
I think this:
Implement a user that overrides MembershipUser and has a session id in it.
Implement a membership provider that overrides MembershipProvider and does all the WCF calls etc.
In the Web.Config set up a custom membership provider.
Is this correct or am I missing something major?
Rather than do this yourself, you might want to take a look at the WCF Authentication Services.
Before you go down this route, be aware that the authentication services supports login and logout, but that is about it. The usual Membership methods such as CreateUser aren't available. If you need them, you'll need to create three projects:
A WCF Service Application with a single service called WCFMembershipService that wraps the core Membership Provider requirements, i.e. calling Membership.Provider.Method(). Configure the standard SQLMembershipProvider in the web.config, and
A custom membership provider to be used in the ASP.NET application that calls your WCF service from step 1, and
An ASP.NET Application with the custom membership provider configured
You will find that the Membership and Role providers are extremely easy, but the Profile provider is more challenging, because you cannot serialize the default properties that the provider requires, such as SettingsPropertyValueCollection.
In this case, you would need to convert the SettingsPropertyValueCollection into a serializable type first, and then reconstruct it at the other end. Probably a Dictionary<string, string>() would suffice.
I have a ASP.NET MVC site with a private site administration application secured with ASP.NET sql-backed authorization. I need to add a login for the public site to allow visitors to sign up for an account.
I am thinking I should create totally seperate storage for the public site, rather than extend the existing user db and rely on roles to keep public users out of the back office. Is there any reason not to do this?
Yes there is. You can isolate the private database from the public database. Create 2 database user accounts, make sure they only have access to the 1 database they need. The public and private apps will use different accounts. Then lock down the database accounts to make sure they only have the rights needed for the web app to function. (I'm not sure what database you are using. if you are using ms-sql make sure they don't have access to xp_cmdshell, if you are under mysql make sure the account doesn't have FILE privileges. There are other considerations but this is outside the scope of this question.)
If a SQL Injection vulnerability is found in the public part of your site then they will be able to access that one database leaving your private site unaffected by the attack.
Time and potentially money would be one reason. Otherwise, if you have the time. Depending on the need, not knowing exactly the issues at hand, it could also add a lot of complexity...
HTH.
Will you ever have a user with more than one role? Could you end up storing the same user in more than one database? If so, I would keep your users in a unified DB.
I've been playing around with ASP.NET Application Services. I've implemented the Authentication Service, Profile Service and Role Service successfully, able to log in and get Profile information for the logged in user and Role information.
Now I've noticed a major shortfall in the fact that I can't work out how to create a new user account with the Application Services stuff. Does anybody know how?
Seems like the Application Services AuthenticationService only supports validating existing users. You should enable creating users through some other part of your application, either your own web service or a web page.
I'm not sure about Application Services, but I know that you can create new users with Membership Services.
That's like this:
Dim mbmr As MembershipUser
mbmr = Membership.CreateUser(newUserName,newUserPwd)
There are something like 6 overrides for the CreateUser method.
I think not many people are not fully understanding the role of application services and thus feel frustrated when they do not find the full asp.net provider stack exposed over a store bought json endpoint......
Application services are exposed publicly. They are meant to provide an authentication and identification facility.
Think...
Your user is not logged in. To log in you must access application services to authenticate.
Right?
Do you really think that exposing membership management api such as Create/Delete user on that endpoint is wise?
Exposing management functions on a public facing api presents a huge challenge to get right for ONE scenario, much less to capably facilitate every scenario so perhaps you can see why application services exposes only what you need to do identify and authenticate a user.