Sorry, for the delay.
but where I do set up the claims and integrate the Identity and claims into AbpSession? There must be another class for that?
Yes. Create your own AbpSessionWithClaims following the same approach as Abp.Zero.
In my case, the Identity is determined before my app even starts. Our corporate STS puts our identity in a cookie. I guess I'm looking for the Abp version of the ClaimsTransformation - where I have access to the cookies and the database so I can assemble all the claims together.
Not sure if I understand correctly. Abp does not support claims so far. You can pretend that permissions are claims. I'm using something like this: [AbpPermission("MyClaim=MyValue")] public void MyAppMethod() {..}
and my implementation of IPermissionChecker parses such permission text into claim objects. Then you need to verify these claims against user claims:
{
...
ClaimsPrincipal userPrincipal = ... get current from session ...;
var (claimType, claimValue) = ParsePermission(permissionName);
bool isPermissioned = AbpSession.UserPrincipal.HasClaim(claimType, claimValue);
...
}
Tuple<string,string> ParsePermissionInfo(string permission) {...}
I hope that implementing just what ABP needs will be simpler.
I've made the same conclusion some time ago and have made a wrapper around the ASP.Net Identity.
The Zero table structure and Permission methods don't take Organization into account.
It looks like claims-based authorization can help you. They are supported by ASP.Net Identity.
My table structures to support User-Organization-Role already exist.
To use this data you need a custom implementation of IPermissionChecker interface which will be able to handle permissions in the form "Organisation=1234". You can use this permisson either by an attiribute [AbpAuthorize("Organisation=1234")] or by injecting IPermissionChecker and using it directly.
Hi Halil, I'd like to use Claims-based security in my project because it is more universal than Roles-based. Particularly, Roles can be implemented as claims. With the current Abp.Core design, IPermissionChecker is based on Permission concept which can be identified by some string. To use claims (using my own implementation of IPermissionChecker), I'm using&parsing permissions in the form:
[AbpAuthorize("MyClaimType=MyClaimValue")] public MyResult MyAction(MyInput input) {...}
Unfortunately claims typically have long uri-based names (see System.Security.Claims.ClaimTypes standard .Net type) and it not convenient to have these names in an AbpAuthorizeAttribute. More convenient approach would be to extend AbpAuthorizeAttribute and permission checker such that it will be possible to write:
[AbpAuthorize(ClaimTypes.Role, "MyClaimValue")] public MyResult MyAction(MyInput input) {...}
What do you think?
-- Bogdan
Hi,
Wouldn't it be better to avoid server-side localization and do it only on a client side? IMO it will lead to a more modern&simple approach for web development and significantly improve speed because now pages will be simple HTMLs.
For instance, in angular, following code: <label>@L("ContactFullName")</label> can be rewritten as: <label>{{L("ContactFullName")}}</label> where L is a function on $rootScope. BTW, redefining L on a nested scope can be used for multi-language websites. And yet another benefit: changing '$rootScope.L' will change all relevant UI and will not cause bugs fixed by page reloading, as it is now.
Please note that I'm talking about best practice and not about removing razor-localization support because for many projects it may not be applicable. In general, I'm thinking about use case when razor&mvc are not used at all (only webapi and core asp.net). This kind of web apps may suffer from some limitations but are significantly easier to maintain, create and port.
-- Bogdan
True, ABP does not force Anemic but IMO ABP is also to demo for best practices. It means that adding at least basic AggregateRoot to show how to do things properly before project becomes too large will be very useful. Anyway it's just my 5c.
Hi Halil, Any guidelines on adding new abp modules? I was thinking on adding functionality which will deliver Application/DTO metadata (properties, types, validation rules) to the client such that it will be easy to auto generate angular-ui-grid based list-pages and view/edit pages. It looks redundant to create CRUD UI manually over and over again.
Hi Halil,
It does not look like tenant concept is used in the sample and I cannot imagine simple enough project which can show benefits of this concept. Also descriptions of multi-tenancy which I was able to find in web are kind of blur. What about making it optional if there are no strong reasons to do otherwise. Maybe there is a need to have separate module for this?
BTW, great project. Thanks for ABP and let me know if you need any help.
