Maybe I'm using the wrong terms, but I've been Googling for two days and just can't find anything on this: grouping roles/permissions. Or maybe I don't quite understand membership in the ASP.Net model.
Currently I have a homegrown authentication system in a PHP site, with users, permissions, and roles. Each role (such as "User" or "Technician") is made up of individual permissions (such as "Add New User" or "Close Ticket"). The site is MVC-based, so when the controller action is called, it looks for a basic permission. If not found, it displays an unauthorized page. When it searches for permissions, it looks inside the role groups. However, a user can be a part of the "User" role and have additional permissions without being part of another role.
How would that translate over to MVC2?
The website has a database tables for the user, user_to_permissions, user_to_roles, permissions, roles, and roles_to_permissions. I think the relationships are pretty self-explanatory. I think I'll need to maintain my own database tables for the users, so I'll have custom forms to add/update their info, and obviously a custom login routine.
Can this even work?
RoleProvider "roles" are really just permissions. You can roll them up and present them however you like in your UI (see, for example, AzMan and AuthorizationStoreRoleProvider), but that's up to you. They're not really hierarchical.
Related
I have a tenant admin account for a SharePoint online tenant. I am tasked with looking at all the sites on the tenant and all the SharePoint groups on each site. Getting a list of sites is easy using PNP libraries (Get-PnPTenantSite). My next step is to loop through each site and get all the security groups associated with each site - also easy using Get-PnPGroup commandlet.
The problem I'm running into is that my tenant admin is not added to some sites - not Site Admin, Not Site Owner, not even Site Reader - and so when my script executes against one of these sites, I'm getting a 403 Forbidden when asking for the groups on the site. Yes, I could avoid this by just adding my tenant admin as an owner on every single site in the tenant, and could probably even do this using a fairly simple powershell script.
However, my question is, why is this necessary? Shouldn't I be able to just run a script with some kind of "tenant admin super-read-permissions" or something that will just temporarily give me all access to everything without having to go through the middle step of adding myself everywhere?
Depending on the needs of your business with SharePoint, it may seem like an unnecessary or extra layer of security. After all, why not allow an administrator to access all the things?
The answer lies in the fact that SharePoint security is designed to allow separation of roles. These roles may not necessarily match exactly how responsibilities are defined in your company.
From Microsoft:
Global Administrators and SharePoint Administrators don't have
automatic access to all sites and each user's OneDrive, but they can
give themselves access to any site or OneDrive.
See https://learn.microsoft.com/en-us/sharepoint/sharepoint-admin-role
Tenant admins have several responsibilities:
Create sites
Delete sites
Manage sharing settings at the organization level
Add and remove site admins
Manage site storage limits
To perform these responsibilities, very little access to the actual sites and their content is required.
Management of access to a site collection and its content is the responsibility of the site collection administrator and site owners.
It sounds like in your company, you wear both hats. You might be creating and deleting sites, and also getting involved in access control or auditing at the site collection level. In these cases, you must use the privilege of the tenant admin (e.g., add and remove site admins) to grant yourself the site collection privileges required to access the information you need.
I recommend not granting yourself these privileges forever. It is helpful to consider that having constant administrative access to all sites is undesirable for a few reasons. For instance:
Search is supposed to be filtered to content that is relevant to the user. If the user is an admin with access to all content, search will not be filtered in a useful way.
While an administrator may certainly grant themselves access to a site, some collaborators would prefer that their content remain private to their team until or unless they require technical support.
All of this addresses the "why" part of your question. As for the technical question, there is currently no "tenant admin super-read-permissions" role that you can use for the data you want to collect.
I scrolled through the documentation of KeyCloak and also set it on my machine to explore.
I also explored fine-grained permissions however I didn't get much detail in documentation around the n-level of nested hierarchies.
Here https://www.keycloak.org/docs/latest/server_admin/ this talks about limiting an admin user to particular client management, however, I want certain users, within the client, to be able to create accounts but with scopes and attributes limited to what's assigned to themselves.
For an example:
For a client(ERP>Transactions) we want to create an Org(our customer) Admin who in return will create teams and team admins. Team admins shall be able to invite their teammates in there.
Now I just want to know if only Keycloak can be used to make sure a user in one Org shouldn't be able to create a user in some other org, in the same way, a team admin shouldn't be able to onboard/invite a user in some other team.
Because if Keycloak in principle can't handle this, our team will start writing custom logic in our application code base for this.
I've made an app that utilizes Firestore. I am trying to find documentation on how to assign roles to my users. Ironically enough Google didn't help.
Time has come to set some security rules based on a users role. There will only be two roles; users and admin(s). Admins should be able read and write to everything but a user should only be able to read, write and delte its own content. Writing the rules for that is fine I suppose and well documented, but I can not seem to find any documentation on how to assign a role to a specific user. All my users are just regular users (I guess) including my own user. So adding the .isAdmin to a security check is kind of pointless.
Is there anyone out there that can point me in the right direction?
Im working on a "what I thought would be simple" application using zend framework. This is my 4th application with zf, but my first with a dynamic ACL. Application uses standard MVC setup with Model/Domain Layer consisting of a Service Layer to access my Models(popo) which are mapped through Mappers. For each Model I have a corresponding Service and Mapper. I would like to have my UserModel implement the Role interface and then all my model based services implement the Resource interface. Also I would like to have specified predefined privileges based on static roles, but also be able to change specified privileges for each user based on the user's role(s);
So for instance:
I role of 'vendor' that by default has access to the 'invoice' resource with 'create', 'edit' and 'view' privileges.
So my InvoiceService I would would be the 'invoice' resource with methods create, edit, view, and delete(but by default only role admin could delete an invoice.
For a specific user with role of vendor I would like to be able to grant delete privilege, or for another user with vendor role I might like to be able to deny edit privilege. This im thinking would have to be persisted in some way and dynamically loaded.
So to my actual question(s).
Am I going about this the wrong way?
Also how could a solution like this be implemented with Zend Navigation?
Any ideas pointers lessons feedback would be greatly appreciated.
Sorry if I have done a crap job with my explanation been up all night.
Yes, as David said you are on the right track. Zend_Navigation plays very nicely with Zend_Acl. You can define your navigation in an xml or ini file, assigning each page a resource and required privilege, and then inject the ACL and the navigation container into the navigation view helper. You can also set the current role for the navigation helper to whomever is currently logged in, which will show or hide navigation elements based on the ACL.
I will say that defining all those pages in a navigation container is a bit tedious and verbose, but not difficult.
As for defining your ACL, you can do something as simple as defining all your roles and resources in a single php file, or you can have a more flexible approach and store this information in a database and build the acl. You'd definitely want to cache the ACL with the latter approach.
I'm trying to switch my site from the asp.net membership sql provider to using facebook connect to do OAuth single signon. I'd like to keep using the role provider as it makes it pretty easy secure sections of my site by flagging the controller class or controller methods with the Authorize(Roles="...") attribute. The site isn't live yet so I'll be completely ditching the Asp.net membership provider if I can. (keeping the roles and profile provider)
I've got the facebook connect logging the user in and I can get his info. But how do I associate that with a role?
I'd like the system to automatically add a new user to the "SuperHero" role after he authenticates and authorizes my app.
Am I on track here? Is there a better way to handle roles when using OAuth2? I'd like to add other OAuth providers later.
An alternate approach would be to keep the asp membership, then when I user logs in through facebook connect, I could find his record and sign him in with aspmembership. But that seems sloppy.
Some sample code would be great and I'd think others would find it helpful too.
thx,
Dan
The easiest way to do this ime is to actually implement a FacebookMembershipProvider for yourself. That way it ties in to all the other providers naturally. The main downsides are a) a lot of code b/c Membership is a fat interface, and b) some cruft b/c it assumes you'll be doing passwords, etc, which obviously you don't need for OAuth.