Per https://developer.microsoft.com/en-us/graph/docs/concepts/extensibility_overview#permissions (section "Schema extensions lifetime", State "Available"): "The schema extension is available for use by all apps in any tenant. "
What is the reasoning to not allow limiting schema extensions to a single tenant only? (or did I miss the HowTo on this one)
There is a way to limit this by not moving the schema to "Available" and leaving it in "InDevelopment". The lifecycle is documented here under Schema Extensions Lifecycle. However we are investigating some tighter controls around visibility (my tenant only, any tenant) and authorization for schema extensions and which apps can get/set schema extension properties.
Be interested to hear more about your scenarios and the kinds of controls you are thinking of.
Hope this helps,
Related
We have a medium sized business app and we use Spring Security roles and permissions (RBAC) heavily with a big kludge to turn roles on and off for certain instances plus rules hidden in SpEL within #PreAuthorize tags.
I think what we have actually implemented (without knowing it is ABAC). XACML looks very complicated and bloated so I'm not keen on the answer here:
How to change Spring Security roles by context?
Has anybody done a light weight ABAC implementation without XACML? I have hopes that would give us separation of concerns as the domain objects just do #PreAuthorize(WRITE) etc and our authorisation policy would be decoupled from it.
From what I've read the basic principal of ABAC is very simple. You have an Action (very like a Permission) and a mechanism to resolve if the current Principal has that permission on a given Subject.
I'm aware of AccessDecisionVoter which is roughly the right sort of interface but I don't think it was intended for voting on permissions. However implementing our authorisation policy with instances of something like those seems very attractive.
Sorry for the rambling question! Basically I'm interesting in ABAC but would like to avoid home brew but worried what XACML is a jumbo jet when we need a Cessna.
There seems to be two things you are aiming for:
externalized authorization, where you want to move access control policies out of the code (or at least into a central place in the code and not scattered across the Spring code)
attribute based authorization, where you want to use richer attributes than roles and permissions
I am not very sure of (2) since what you say you want to do, "action and a mechanism to resolve if the current Principal has that permission", is still, in my books, RBAC. Do you have other conditions on which access grant decisions will need to be based on? Location of the user, time of day, value of certain data in a database, properties of the resource being acted on etc.? If so, we stray into the ABAC world. Either way, I would say that RBAC is a subset of ABAC since a role is just one attribute.
Now, as for (1), the general pattern would be to first centralize the authorization engine and use the Spring annotations to call this authz. engine for access decisions. You have two choices here:
embedded authz. engine: where a library implements the engine and is called by the code just as a Java function. Could be a XACML engine or could be your own RBAC/ABAC implementation
as a network service: where a network based (micro) service answers access control decision questions. Could be a XACML engine or could be your own RBAC/ABAC implementation
In order to get the Spring based code to call this authz. engine, one approach would be to write your own Spring Security voter. Another way, which I found much easier, would be to write your own Spring Expression Language based expressions that you can then call with the existing #PreAuthorize, #PostAuthorize, #PreFilter and #PostFiler, sec:authorize tags and even from intercept-url conditions.
This is what I used when I worked on our Spring Security XACML PEP SDK. The approach should work equally well even if you decide not to use XACML for your access decision policies or the request/response communication.
A pretty nice approach without XACML can be found here. It's basically what you wanted. A lighweight approach on ABAC without implementing XACML.
https://dzone.com/articles/simple-attribute-based-access-control-with-spring
I know this question is rather old, but recently we had need for similar ABAC permissions implementation. At first I tried to find something existing which would fill our needs, but everything seemed to be over the top and very hard to use.
So I came up with very simple library called jaclp which can be found on GitHub. It supports classical RBAC approach and more complex ABAC which can be used for example on JPA entities acting as resources. The integration and setup should be fairly simple.
One of the disadvantages is that for now, definition of permissions is programmatically only. I plan to introduce configuration file from which permission rules would be loaded. Also jaclp library for now supports only static permission rules defined in code, this means that you cannot load permission rules dynamically for example from database.
Example Usage:
// Applying permissions on REST endpoints
#GetMapping("groups/{id}")
#PreAuthorize("hasPermission(#id, 'group', 'viewDetail')")
public GroupDetailDTO getGroupDetail(#PathVariable long id) {
return this.groupService.getGroupDetail(id);
}
// Defining role with both RBAC and ABAC approach
Role userRole = RoleBuilder.create("user")
.addAllowedRule("group",
(UserDetails user, GroupEntity group) -> group.isPublic(),
"viewDetail")
.addAllowedRule("group", "viewAll")
.build();
Hi I have a question related to SAAS model and multi-tenancy.
As far as I know SAAS multi-tenancy application means common functionality
for all clients, with some customizations of UI and functionality underNeath.
If I need make for some customers additional client specific-customization , how I can achieve it?
I know about approach of SalesForce
As for answer I apreciate to see you experience with such
- customizations under database level,
- architecture of backend in general or in
- any links for this topic.
There are the following two ways of customizing a multi-tenant application
1. Presentation tier changes
2. System change.
The following are the typical customization options preferred in web applications in a multi-tenant environment, they are
1) user interface and branding,
2) workflow and business rules,
3) data model extensions, and
4) access control
In which 1 belongs to the presentation tier change and the rest all form the system level change in a multi-tenant application.
MVC is considered as presentation tier customization option where in we have the option of allowing the tenant to have their own theme , logo and custom layout or custom controllers and custom page sections.
For System settings, there are many ways to achieve this, however the following are the most pervasive
Customization at the database level
Customization at the middleware level.
In SaaS app, there are features and implementation. In the case of the later, there will be a tenant specific configuration that governs which implementation to be invoked for the tenant under consideration based on his configuration and then provides the service. These are achieved using a custom dependency injection mechanism which is tenant aware and also will be required a tenant specific configuration that can be consumed during the runtime to facilitate this process.
In the case of (1), the data in the db should be isolated based on the tenant identifier so that the configuration or the metadata are not shared between the tenants in a multi-tenant environment.
So the main components will be
a tenant identifier obtained from a tenant context
multi-tenant datastorage
Tenant specific authentication [form signing / Single SignOn etc..]
IMHO, since your topic is broad, if you can present us more specific areas, we will discuss on their implementation.
Hope this answers your query, please do post your update.
I've found out n-Tier web application concept like following categories:
1- Database (including database business and table or store procedures and all database stuff)
2- Web. Data (including entities and repositories)
3- Web. Model (including not entities some simple model can transfer to client)
4- Web. Business (in some application is admitted it is not mandatory but it includes some functionality such as how to calculates things)
5- Web. Service (including web API on SOAP restful application)
6- Web. Security (it includes some custom security as you wish but it is not mandatory)
7- Web. Client (including client-side functionalities like jquery, mvvm and some other like authentication, securities implemented in UI)
8- Web. Extension (including extra helper methods and wrapper objects)
9- Web. Handler (including all handler and modules)
These layers could be placed on different projects they could be implemented by MVC or even by asp.net of course with the same concept.
I was wondering if my understanding was right or not? or got any better idea? Could you expand them more or are they limited and enough?
Please guide me what are standards about them?
Did you look MyPrettyCMS Framework in codeplex ?
It's exactely that...
https://myprettycms.codeplex.com
In the next release, it includes Web API and Web API OData Handling.
If you want to follow the developer group, find the Linked in group : myPrettyCMS Happy Contributors Associates
N-tier concept is wider than just listing the exact tiers. This concept helps to divite your application to manageble and isolated levels, which you could change, re-design, substitute without breaking and re-writing the entire application. The number of tiers could vary depending on technology stack you use.
read more here: http://en.wikipedia.org/wiki/Multitier_architecture
You should try looking into the XWA architecture if your primary concern is web applications.
http://madeyski.e-informatyka.pl/download/23.pdf
XWA architecture builds atop the concepts know from the MVC and PCMEF.
I have a site which has an area that requires authentication. Right now I use the roles attribute on all the controllers in that area, and I run a query to retrieve that users ID, and all their settings.
It seems like a code or design smell to me that I am retrieving the userid and settings each time a controller in that area loads up? I'm not sure if I should be using sessions, or if ASP.Net MVC 2.0 provides some unique way to handle this. Another concern is security.
Overall, I don't really know which way to turn. Design wise I would like the userId and settings retrieved only once when the user logs into the area. Right now I grab the userId each time a controller loads up, and then if required, I query the database for their settings each time as well.
One of the rules about security is that you shouldn't try to do it yourself. There are many pitfalls in doing an authentication system correctly without leaving loopholes or backdoors. Thus, in that regard, you might consider the SqlMembershipProvider that comes with .NET. It can be used with MVC and provides the means to get roles and the current security context, is easy to setup and configure and will be more secure than rolling your own.
If you are not using SQL Server, you have a couple of choices. One solution would be to use something like SQL Server Express or SQL Server Compact Edition to maintain the credentials. Another solution would be to mimic the SqlMembrershipProvider database schema and then write a custom provider that communicates with that schema.
The last choice would be to write a custom MembershipProvider class. While this is still rolling your own, it forces you into the structure of the MembershipProvider so that you can swap it out at a later date for a different one (e.g. ActiveDirectoryMembershipProvider) and provides a common interface for interacting with credentials and logins which for example enables easy use of the built-in Login control.
If you are already using a MembershipProvider and are asking about storing additional user-specific data, then I would suggest the SqlProfileProvider with all the caveats I mentioned above about the SqlMembershipProvider. the ProfileProvider provides a structure for maintain user-specific data with the currently logged on user.
For more information:
Introduction to Membership
Implementing a MembershipProvider
ASP.NET Profile Providers
You could also implement a custom identity. They are very easy to implement, and they let you store whatever user information you want in Identity, which is then stored in the cookies that Identity puts down, so you're not hitting the DB every time to get that info.
Just create a new class that inherits from GenericIdentity, and you'll be on your way.
You of course have to be careful how much info you put there since it's in a cookie, but usually user related information in the case you're talking about here isn't so big.
We use a custom identity to store a few bits of info about the user, and it works out pretty well.
You could store an object in session that holds all the required user information. You will just need to add a property in the Controllers, Views or other base classes where you want to retrieve the user information/profile. This would be the authorisation info as opposed to any authentication info (eg Forms authentication)
You might try "Windows Identity Foundation". I've been using it on one of my projects for a while. It allows for "claims-based authentication", which basically means that you get to designate "claims", strings of information that describe the user when she logs on.
Once logged on, the user's claims can be read from the HttpContext.Current.User field. You can also use "Role" claims that seamlessly integrate with a role-based authentication schema; meaning that you can give the user a "manager" role claim and then use `if (User.IsInRole("manager")).
As an added bonus, WIF makes it very easy to re-use your login screen in other applications.
All in all, it's very flexible, but the documentation is very poor. I've asked and answered a number of questions about "Windows Identity Foundation" on StackOverflow.
We have done this quite a few times in the past. Similar to what Thomas mentions, what we have generally done is implemented a new Membership provider based on the Microsoft SQL Memberhsip provider to do this. We inherit from the base MembershipUser class and add any custom properties we would want to have on the user object. You have to implement a database read for the Membership provider on the GetUser implementation, so you can consolidate your extra properties you need into that database read.
If you are using SQL server, Microsoft has release the 2.0 code for it. You can get more information at Scott Gu's blog.
http://weblogs.asp.net/scottgu/archive/2006/04/13/442772.aspx
If you want to start from scratch, they also have good resources at MSDN.
http://msdn.microsoft.com/en-us/library/f1kyba5e.aspx
and
http://msdn.microsoft.com/en-us/library/6tc47t75.aspx
Once you have implemented your provider, you can then add the Membership user to the Items collection of the current web context to get access to it from your code. The non extended properties from the base base user class are also available on the Request thread like normal.
With the Microsoft release of the 2.0 version of the source code , we found it helped us alleviate some concerns that exist about reinventing. Another thing to consider for your implementations is based on your scenario, you can bypass implementing some of the code. An example of this would be the CreateUser code if you are hitting a back end system that already has the credential information.
It seems like you're relatively happy with your authentication process but you want to explore other options for session/settings.
My suggestion has to do with settings only (roles, preferences, etc.)
In my opinion, having to traverse the whole technology stack from UI to Business Tier to DB tier to DB is sometimes a bit overkill.
For data that isn't likely to change during a session, this adds a lot of overhead... There are potentially several data transformations happening (DB (Relational Format) -> ORM -> Web Service XML Serialization -> Web Tier deserialization).
You might consider a session system that doesn't rely on a heavy RDBMS system or on the ASP.NET Caching / Session model. There are options that are very performant and that scale well.
You could use RavenDB by Ayende Rahien (Built for .NET). Its main goal is to provide low latency, high performance access to schema-less JSON documents.
Using this solution, you would set up ravenDB in the web tier so that access to data is very quick.
The first time you authenticate and retrieve settings, you would store the userID and settings information in this session DB.
Every time you load your controller after that, the settings data is accessible without having to go back to the RDBMS.
This DB could also be used to cache other web related data.
As for security, the settings data makes it to the web tier regardless of the method you use. This solution would be no more or less secure than the other options (more secure than an unencrypted cookie). If you needed to, you could encrypt the session data - but that will increase your overhead again.
Just another one of the million options to consider.
Good Luck,
Let us know what you decide!
Patrick.
I'm using Ruby on Rails for an internal site. Different users of the site have access to a wide variety of data and highly disparate perspectives of the data. Within those different classes of users, there needs to be levels of access. Within the levels of access I need to be able to add features from other classes of users.
In the released "Version 1.0" of the intranet site I have implemented the general classes of users. I am now needed to implement much finer-grained control of a users access.
The question is how?
What is the generally accepted practice for coding up user preferences (display the map (or not); access to this feature, but not this feature) without exploding the database schema and populating the view code with <% if feature_allowed %> tags everywhere.
Another totally different approach would be to use acts_as_authenticated and authorization plugins. The tables will be built by the plugins (ie users, roles and roles_users). From the doc:
The authorization plugin provides the following:
A simple way of checking authorization at either the class or instance method
level using #permit and #permit?
Authorization using roles for the entire application, a model class, or an
instance of a model (i.e., a particular object).
Some english-like dynamic methods that draw on the defined roles. You will be
able to use methods like "user.is_fan_of angelina" or "angelina.has_fans?",
where a 'fan' is only defined in the roles table.
Pick-and-choose a mixin for your desired level of database complexity. For
all the features, you will want to use "object roles table" (see below)
populating the view code with <% if
feature_allowed %> tags everywhere.
I don't think you want to do that. Assuming none of the alternatives suggested are practicable, at the very least you should consider shifting those checks into your controllers, where you can refactor them into a before_filter.
See section 11.3 in "Agile Web Development With Rails" (page 158 in my copy of the 2nd edition) where they do exactly that.