Hi,
I have a question about authorization. CSLA authorization mechanism is object level. I have a problem with my current project.
My application maintains a list of customer. Each customer can have CRUD permission to CRUD an order and then submit. I implemented CSLA authorization based on role. Everything work fine but there is still a problem: each customer can see all orders. I need a solution to force a customer can see only order they created. Ex: a customer A can see orders that he was created, and can't see order customer B was created.
Thanks.
This is typically something you'd resolve at the database level.
The DataPortal_XYZ methods have access to the current principal, just like the rest of your object's code. You can use that principal/identity information to provide required parameters to your database queries so those queries can filter out data that shouldn't be available to the current user.
We have the same need. We haven't fully decided yet, but we are leaning to using Criteria to pass the needed customer information to DP calls. Just like Rocky suggested, we will be passing the information directly to the SP for the fetch (and the others as well).
The authorization stuff is strictly to control access to functions and BO. This would be more of a filter on the data.
I would be curious to hear from others who may have already implemented something along these lines or another solution that can handle this.
I use Rocky's solution.
Provide the right set of criteria to the SP or query and let the DB filter it out.
If you need the userkey then it should be available to you as part of the Principal and you don't need it in your Criteria class. Other info may need to be passed in though.
Joe
The problem with putting the info in Criteria is that it gets
passed to the app server twice on every call. The user’s identity is already
in the current principal, so duplicating that data in the criteria seems like a
waste.
If you have other peripheral data about the user (beyond their
name and roles) then I recommend adding that data into your custom identity
object so it is part of the current principal, and is automatically available
on both client and server.
Rocky
From: JoeFallon1
[mailto:cslanet@lhotka.net]
Sent: Wednesday, December 05, 2007 9:03 AM
To: rocky@lhotka.net
Subject: Re: [CSLA .NET] Authroization for specific user.
I use Rocky's solution.
Provide the right set of criteria to the SP or query and let the DB filter
it out.
If you need the userkey then it should be available to you as part of the
Principal and you don't need it in your Criteria class. Other info may need to
be passed in though.
Joe
Thanks for the input. We will add the needed additional info to our identity object.
Stan
Copyright (c) Marimer LLC