I am currently working with a liferay portlets. Spring security is used on the Rendering layer( in jsp pages). However, it is not safe, because my dispatch controllers and services do not have any security/authorization checks.
In my application, Spring-MVC controller receives the request, and passes to the Service Layer. Service Layer builds the result and passes it to the JSP pages. In jsp pages we have the security authorization using spring-security taglibs.
I want to know the following:
Best practises regarding implementing authorization for portlets.
Which is better choice to implement security either on Dispatch layer or Service layer?
How to implement security for dispatch layer or service layer?
Please consider that I have security in my application on use-case bases.
Thank you!
My favorite answer matches here: "it depends".
Here's what it depends on:
Liferay defaults to the *LocalService being without any permission checks - e.g. if you have access to the API, you get to do whatever you want. The remote services however are supposed to check permissions before they delegate the actual execution of a service to the local services.
If you want to use Liferay's permissionChecker (which is readily available and runtime-configurable), you should do this in the non-local service methods. I tend to recommend this, as you'll be able to tap into Liferay's permissioning system - and you already have the user identity, roles, memberships etc. managed by Liferay anyway. Create a custom role, grant custom permissions and you have everything configurable at runtime.
Secondly, while you definitely want to check the permissions in the backend services, you'll probably want to do it again on the UI layer: If a user is not allowed to manipulate some object, you don't want to display the button that suggests they can change it, only to get a "permission denied" reply.
That being said, I've never tied spring security (especially the taglibs) to Liferay's permission system.
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.
Current 2-tier application
ASP.NET (Membership/Roles) – BL – DAL – DB
After the user is authenticated (membership) we use roles to facilitate authorization to different menu items such as “Reporting” and “Administration”. However as part of authorization, we must also take into account response filtering. For example regardless of the user’s role, a method to retrieve a statement by id should be limited to the user being able to retrieve only the statements that belong to them via some established database relationship. To facilitate this, the web application maintains in session a profile (POCO) which is injected into each BL object (perhaps this object should have been incorporated into IIdentity). Subsequently inside BL we’re able to determine if the request for id X should indeed return a statement, because we know the user that is requesting this statement, and we know the relationship between the statement and the users that should be able to access it.
Future 3-tier application
ASP.NET (Membership/Roles) – WCF - BL – DAL – DB
Authentication seems to stay the same, the WCF service can be password secured to make sure that only our web application (or any other that has the user/password) has access to it. However how do I go about facilitating response filtering? Are there seamless mechanisms to pass ASP.NET’s IPrincipal/IIdentity to the service? If yes, how will this limit me if down the line I have a non-ASP.NET client to the same service? If not, should this information be part of the request dto or request header?
You could apply XACML to your 3-tier application. You would have authorization in the widgets (menus, buttons...), the business logic, and the WCF tier.
All requests will go against the same authorization policy written outside in XACML. Your rules can say:
adminstrators can view the admin button
users can view statements they own (i.e. users can view a statement if statement.owner==user.id)
You no longer need to implement a database relationship. Your authorization becomes much easier.
HTH
Re:
Are there seamless mechanisms to pass ASP.NET’s IPrincipal/IIdentity to the service?
you could look at WS-Trust: weblogs.asp.net/cibrax/archive/2006/09/08/SAML-2D00-STS-implementation-for-WCF.aspx
Is there a way I can configure my asp.net web service to work with only some applications? In other words, I am saying "only these applications have access to this web service and can therefore use it. Others can't".
When other applications tries to discover the service, it shouldn't even show up, or at least it should conceal it web methods.
PS: I am wondering if this scenario is even applicable to the whole concept/domain of web services? Plus, I am asp.net 2.0 oriented, but you can give me answers based on higher framework versions, but be specific...Thanx in advance.
I'd look at WCF (after all ASMX web services are now regarded as legacy)- there is a whole load of options regarding security configuration. Patterns and Practises have Security Guidance here. It sounds like you are most interested in authorization, so read about Access Control Mechanisms.
Also to make the service non discoverable in WCF you just don't expose a MEX endpoint. That doesn't stop clients connecting, but makes it hard for people to work out how to call the service. That said you can also secure the MEX endpoints so that is another option.
Can you put some authorization or login method to initialize usage of webservice?
We control usage of services by explicitly logging into the webservice or provide some authorization token.
I have a business logic layer (the "repository") which is exposed as a set of .NET interfaces backed by swappable concrete implementations.
Originally I had this business layer implement authentication and authorization (authn/authz), meaning I had interfaces such as IUserIdentity and IUserRole, and all methods that accessed sensitive data took an IUserIdentity and performed authorization before allowing the action.
The business layer has been very front-end agnostic up to this point... but now when I am trying to integrate into an ASP.NET web site, I realized that ASP.NET itself has a rich authentication/authorization system built into it via the Membership and Role APIs.
So the question is, should I remove all the authn/authz from the business logic layer and rely on the web front end to do this? This would simplify things alot but I don't know whether I will later regret moving it out.
The alternative is to keep the authn/authz in my business logic but integrate it with ASP.NET via custom Membership/Role providers. However this seems real cumbersome... I still need to investigate the cost of doing this.
What would you do (or have done) and why?
I think security is a cross-cutting concern that belongs in aspects. I don't know if .NET has aspects, unless you use Spring.NET.
Keep it. Forms Authentication in ASP.NET is very easy to customize and your business logic layer remains front-end agnostic.
Consider staying away from this approach and instead try Forms Authentication. Basically, you can call your established methods from an Authenticate event of a Login control.
I suggest you keep the existing logic, and write a custom membership/role provider around your existing security classes if you want to use the same directly using asp.net. This should be easier than you think.
http://www.codeproject.com/KB/aspnet/customaspnetproviders.aspx
As you already have classes for managing security permissions, this just means wrapping your existing logic.
This will also help you to use your security logic later, let us say, when you create a Winform client that consumes your business logic, or when you expose your business logic as web services
Are you planning to use multiple front-ends (asp.net, winforms, mobile?), or exposing the business layer via (web) services? Then you should probably implement authentication on top of the business layer.
When all you want is to grant / deney access, you could use integrated security on IIS, and never wite custom code for it.
You could also look into the asp.net membership provider.
I believe the Role Based security should be in the Business Layer, which is where CSLA puts it.
I have a .NET web service which is publically accessible since it needs to be accessible via Flex. It currently only has read operations.
http://www.example.com/webservices/weather.asmx?wsdl
I want to add some admin only web methods to the same webservice such as UpdateWeather and StartRainstorm. Obviously I don't want my end user being able to do change weather patterns.
So I just want to hide the wsdl so that it cannot be accessed via the standard ?wsdl parameter. Ultimately I'll add on better security etc. but I need a quick fix for now. I figure if they don't know the method name they won't be able to access it.
I want to be able to disable the WSDL generation - which I can do by adding <add name="Documentation" /> to my web.config. BUT I want to be able to access the WSDL in some other 'secret' way that only I know so I dont have to keep going to the server. How could I achieve this. I'm fine if its a secret URL or a secret parameter or whatever.
I'm fine with this security through obfuscation approach for now.
One thing you could do is expose another endpoint for the admin contract. Then turn off the WSDL publisher on that admin endpoint. Eventually you could configure security just on the administrative endpoint if you wanted.
This is assuming you are using WCF.
Update: Check out this WCF getting started tutorial. You'll like WCF more than ASP.NET/ASMX services once you learn a bit about it.
why won't you just create another web service? Seems simpler
For update references, you could use your development server.
The production server cannot expose wsdl docs unless you provide public access.
Or, if you have access to the wcf assembly, you can use svcutil against the wcf assembly. This will generate language code to be used in your application.
If you really, really want to expose wsdl to limited users, you can use the iis url rewriting to block access from unauthorized ip addresses.