A precursor: I've worked now in two enviroments with conflicting principals on this. I am outlining the competing ideas and would like to know which is 'correct' given the scenario described.
Scenario: Multiple applications exist on our intranet. We are implementing OpenSSO with LDAP as our authentication control and user directory. The issue comes to play is, with the LDAP authentication we know a user is allowed on the intranet but to which applications is questionable.
We intend to use LDAP to control what applications each user can access i.e. helpdesk, consultant review, report generator, survey creator etc.
The question arises in that, within each application are a significant amount of roles, and the fact that people may have multiple roles.
What is the best way to address this second area? Shoudl ALL roles be in the ldap or just the application allowances with each app database containing the more granular roles?
One approach is to use LDAP to maintain relatively high-level role information, but keep the very detailed application-specific information internal to each application.
For example, an individual might be members of LDAP groups (roles) like "employee", "help desk associate", "help desk supervisor", etc., and then the individual applications would map the high-level roles into the application-specific functions. A particular high-level role might imply access to multiple applications, and different roles would have different levels of access.
For example, a "help desk associate" might be able to create tickets, but maybe only a supervisor can delete them or run reports.
This is one of those areas where there's no one right answer. Centralizing everything in LDAP gives you better ability to report/audit individuals' access, at the cost of complicating your central LDAP schema with a lot of application-specific data. Also, depending on what existing/commercial applications you're trying to integrate, the applications may not support pulling all their fine-grained access information from LDAP.
Related
I tried to understand RBAC in order to determine if it is a good solution for our problem.
Let say that the context is a bank. Among the several actors, we have account managers and clients.
I think I have understand RBAC for the account manager. If we imagine Account Managers can create, modify, view and remove accounts, then:
Account Manager is a role,
create, modify, view, remove are the operations,
accounts are objects
create account is one of the permissions associated to the role Account Manager
But my problem is about clients ... They can consult only their accounts.
My problem is: How can we specified this particular account in RBAC? Is it at least possible or must I choose another way of manage access control? And which of them?
As mentionned, Attribute based access control may be the good solution. And XACML could be used in an application with complex policies.
Here is a very understandable documentation about ABAC in Spring Security
I am working on a multi-tenant cloud application and considering using E-mail addresses/passwords for general login credentials. However, I may have the same user (same E-mail address) associated with multiple tenants based on the planned sales model for this application. For example, multiple departments in the same company might be separate tenants, or separate companies must be separate tenants. In either case the same user (with same E-mail address) might be a user of these different tenants.
What are possible design strategies for handling such situation?
One approach I am considering is separating creation and update of the user E-mail credentials from the tenants. In this approach a tenant could invite a user (by sending an E-mail) and the user can use the same login credentials for access to all tenants, merely switching between tenants as desired.
What I have typically seen in current web applications is that the user has to have separate E-mail addresses for each tenants, which seems a burden for the user.
Thanks.
Assuming your question is about the technical design (and not the user experience), this is a pretty straight forward solution. Create the users independently from the tenants, and allow for a many to many relationship that represents the "has access to" phrase.
Depending on your chosen backend, there are different manifestations of the design pattern:
RDBMS: Create a user table, tenant table and a user_has_access_to relationship table
Directory Server (LDAP): Place the users into a single OU within the directory, and create the tenants as group objects. The users could then have the memberOf attribute set for each tenant they are able to access.
The LDAP option above has the limitation of overloading the group entity. If you are comfortable enough with LDAP schema definitions, you could just as easily create a tenant object and add a hasAccessToTenant attribute to your user object. Taking this approach would allow you to use groups to represent actual user groups (as the object type was intended to be used).
A more advanced design option would include the creation of a "has access to" relationship between tenants. Adding this, along with the user to tenant relationship, would open up more advanced relationship modeling. For example: a tenant with departments or divisions, allowing users with permission to the top level tenant to automatically "have access to" the divisions.
Using the same credential across namespaces in multi-tenant applications is technically possible. For example, when a user logs in, the application can check across the namespaces and determine which all namespaces he belongs to. There is a possibility, the user may have different levels of authorizations against these namespaces. This is also implementable.
The real problem is the experience the application can offer to such users. They will require a special landing page which will allow them to chose between the namespaces. The chosen namespace should be made quasi-permanent during the session, that is, until the user logs out. ( I am trying to implement this in a new application on GAE/Python27 )
Other possibilities are restricting the user to a single namespace and asking the user to use different credentials against each namespace, which seems to be the prevailing practice.
I am working on a system architecture for a fund/pension manager. We are providing two ASP.NET MVC web applications; one to allow members of the pension fund to login and check their balances, manage their investment, etc and another to allow employers to make contributions to the fund on the employees (members) behalf. There are also internal applications delivered via the intranet.
We have been considering using Active Directory for storing, authentication/authorisation of not just the internal users (who are already using AD for logging into the domain and resource authorisation) but for the member and employer user accounts. The member and employer user accounts would be located in a different hierarchy (maybe even a different AD instance?) to the internal users.
However I am wondering if this is the best use-case for AD... given AD is such an 'internal' resource, should it be used to hold auth details for 'external' users (the alternative being a USERS table in a database)?
The benefits are: AD is designed and optimised for holding this sort of data, ASP.NET apps integrate with AD authorisation easily, there possibly are existing tools for working with the data (password resets, etc).
What are the risks?
I would recommend against a hybrid of internal and external users. Speaking from experience it opens a lot of security headaches. It might be better to create separate authentication systems, one that uses AD directly against the internal domain and another that uses an ADAM directory designed simply to hold external users. (i.e. - internal users should be authenticated using NTLM with the AD to ensure a kerberos encrypted login, while forms would be usable for the ADAM instance).
AD is very easy to integrate though, and if direct integration is undesirable due to the networking lumps, you can always attempt an LDAP:// to achieve the same authentication results.
I think your biggest risk is that AD would not scale to the amount of users you might have from an Internet app. I would use the Membership provider, unless you are trying to achieve SSO with internal and external accounts.
I've been reading about Azure's Access Control Service and claims-based authorization in general for a while now, and for whatever reason, I still don't see the rationale behind moving from role/permission-based authorization to a claims-based model. The models seem similar to me (and they probably are), except that the list of what the client can and can't do comes from a third party and is wrapped up in some sort of token, instead of from some sort of database that the server has to query. What's the advantage of getting a third party (the token issuer) involved?
I fully understand the advantages of outsourcing authentication to a third party. It allows apps to not have to create new users all the time, worry about storing passwords, etc. when they can just push that off to some other service that already has the infrastructure set up. It's essentially the DRY principle for authentication.
However, in my mind, that same logic doesn't work for authorization. Each app has its own resources it has to protect, and therefore its own rules for authorizing users to perform certain actions. The infrastructure seems simple enough that each app could create it on its own (a table mapping users to roles, and possibly another mapping roles to permissions), and even if you wanted to outsource it, it seems that the claims-based model is doing something more complicated than that.
The only partial explanation I've seen comes from Building a Claims-Based Security Model in WCF, and it gives two main advantages to claims-based auth: more flexibility, and someone to "vouch" that the information in a claim is correct. When would you need either of those?
Claims-based authorization seems to be gaining popularity, so I assume there must be some good rationale for it; I just haven't figured out what that is yet. Can someone please provide a concrete example of a situation where claims-based auth works better than role-based, and why it works better in that case?
(EDIT: I missed a third benefit listed in the article: supporting single sign-on/federation. But doesn't authentication deal with that on its own without getting authorization involved?)
I guess the main promise of a benefit from federated security / claims-based system would be one fewer area you have to deal with different systems.
Imagine a site where you have local users authenticating with Windows credentials, a bunch of internet users using username/password, others using certificates, and maybe another group of users with biometric authentication.
In today's system, you have to set up and deal with all different kinds of authentication schemes and their different ways of doing things. That can get pretty messy.
The promise of a federated security solution would be to handle all those chores for you - the STS (security token server) would handle all different kinds of authentication systems for you, and present to you a uniform and trusted set of claims about a caller - no matter from where and on which path he's arriving at your site.
Of course, just examining and reacting to a single set of claims rather than having to understand four, five, ten different and disparate authentication systems looks like a really compelling promise to me!
The purpose of claims based authorization is to allow fine grained access control based on Boolean expressions that evaluate characteristics of the accessing entity and the resource. This reduces or eliminates the need to provision groups. As with federated identity, claims also provide a vehicle for an Identity provider to manage their users wile allowing a resource provider to gate users access to assets.
Note: Claims can be used within a single enterprise and provide the following benefits:
1) Access grants and revocations do not require provisioning or de-provisioning
2) Thus changes are instantaneous
3) Resource owners can define the scope and requirements for access rather than having admins create groups manage group memberships - this moves the access control decisions into the hands of the folks best suited to make such decisions (the data owner)
4) This results in fewer groups being required and fewer member in the groups
5) There can be issues creating a single group to accommodate a large community having access (for
example all full time employees can read a HR policy) - Claims avoids this problem
6) Audit is more informative - the reason a grant or deny took place is clearly visible
7) Claims support dynamic attributes, such as 2-factor authentication, time of day, or network restrictions
There are a lot more reasons, but those ones come to mind. There will shortly be a video at www.cionsystems.com that showcases this (disclaimer - I work there and recorded the video - I still need to post it) Also, for reference, claims aware apps and platforms include SharePoint 2010 on, Windows 2012 (file shares), Azure, many SaaS services (Facebook and Salesforce)
Also, with claims you can blend information from multiple sources (say Facebook and your local AD) etc. - which is increasingly important
Not sure if the rules allow this, but feel free to ping me with your questions or comments. I'll happily edit the post to make any corrections or add pertinent info.
Claims can come from AD, databases tables, SAML, OAuth, algorithms, XACML or any other trusted provider. Harnessing claims requires a bit of kit - with apps and platforms evolving rapidly in this space.
All the Best,
Paul
Claims-based access control also helps build up attribute-based access control and policy-based access control. If you standardize on a set of pre-agreed claims that can be assigned to users based on their other attributes (e.g. a US manager can have claim U_M; a European manager can have claim E_M).
In an attribute-based and policy-based environment, it's possible to achieve fine-grained authorization (also known as fine-grained entitlements) using XACML.
In this case, you can have authorization that depends on who the user is (claims) but also what they want to do (resource information) and under which circumstances (context).
CBAC with XACML will let you express rules like:
managers can edit notes they created themselves or notes that their
direct reports created.
Role based security is a limited security model
Authorization is:
Based on role membership only
Claims based security is much more flexible and expressive
Authorisation can be:
Based on role membership
Based on Age
Based on Geographic Location
Based on an account balance
Based on a size
Based on pre-defined securtiy levels
Based on any combination of the above
Does anyone have any tips as we develop an application that will require each user to be assigned a permission level. The permission level will determine what functionality is available to the user.
Any advice?
How would you (do you) employ such functionality in your application?
First you need to figure out what functionality you want to cover by your permission system, and in what detail:
Access to tables (List, CRUD)
Functions/Modules
Access on record level (=ACL)
Positive (grant) or Negative (revoke) semantics
What is the "admin" role allowed to do
If you want to restrict access to tables, you can easily set up an additional table containing all the table names, and grant select-list/select-record/insert/update/delete access to the roles/groups, as sketched by JV.
If you want to grant access to functions or modules, have a table of modules and grant execute to roles/groups.
Both functionality is equivalent to grants in SQL.
Access restriction on record level is much more complicated, as you need to model access rights on the status of a record (e.g. "public", "private", "released" in CMS apps), or have explicit permissions on each record.
If you want to implement a permission scheme equivalent to NTFS, you calculate the permission per record based on the group the user is assigned to, and have user-specific permissions that may override the group permissions, and revokes overriding grants.
My applications typically work on table+function / group level, which may be good enough, depending on your requirements.
This is the partial ER diagram for identity module in Turbogears, Python. It implements what you are looking forward to. Users are associated with groups and groups have associated permissions.
The two ways restricted feature availability can be implemented are:
(I prefer)In your controllers check the group to which the user belongs to and moderate your response to the View according to that. Thus View is just a renderer - no business logic.
The View gets the user details like groups and permissions and it decides what to display and what not to (MVC violated).
Read more about MVC (and Turbogears may be).
alt text http://jaivikram.verma.googlepages.com/temp.jpeg
It depends a lot of the language you use and the architecture of your application (web service ? client software ?).
For a server toy project, I though about assigning a minimum permission level to each command, and check it directly when a command network packet is received, triggering a permission error when the user hasn't a high enough level. I might not be suitable for another architecture.
It may be a bit of a dead end to pursue the concept of 'levels'. It may suit your current application, however a data model that consists of a mapping of roles to privileges is more general and suits most purposes.
Assign roles to users. A user may have more than one role, and their role(s) define the privileges they have. The concept is similar to groups, however 'role' is usually easily mapped directly to business logic (think of roles such as 'administrator', 'user', 'clerk', 'account manager', 'regional manager', etc). Privileges also map fairly directly to functions and data objects. You may also be able to map to implementations that use underlying platform access control (e.g. Java privileges).
In the controller code, you check (via their roles) that the user holds the required privilege to perform a function. It is also good practice to modify your views to hide functions that the user does not have the privileges to perform.
In your design you can visualise / document the access control system as a matrix (roles to privileges).