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.
Related
Planning on creating a Google Assistant Application that allows our customers to access business data. The problem I am having is understanding how a given user would link his account to his "instance" of our multi-tenant solution. I think the deeper problem is know which Tenant URL to associate with a particular account. I know I can implement the Accounting linking using Oauth, I have just yet to see how this could work with a single Assistant App accessing multiple tenants depending upon account.
You can get additional info from the user, by asking him, and save that in your context, and then you can request for a sign in. this way, during the sign in process, you can use the context to sign in the user into the proper tenant
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.
I have read about LDAP on wikipedia and I kind of understand what it is. However what I did not get what why so many organizations are using LDAP authentication server over having a simple table with userid and hashed password.
LDAP server surely brings more complexity to the infrastructure. What gains justify this added complexity?
LDAP is complex, but it brings a lot more to the table than just centralized authentication. For example, many email clients can be hooked in to do LDAP searches to find other users - i.e. look up an employee by name, find their email address and phone number right from your email client.
Also, it is extensible - you can define your own types of objects and store them in the directory, so it can be used to store even data that the original implementers did not have in mind when designing it.
For example, OpenSolaris (and therefore I presume Solaris) machines can grab significant amounts of their own configuration over LDAP.
While setting up LDAP is not for the faint of heart and it makes little sense for the home user / small smattering of machines, the aggregate savings over thousands or tens of thousands of computers can make it worth it if administered properly.
Using a simple table seems like a good start until you need to use that same username and password in other locations. When your other systems (email, code, server login, bug tracking/ticket systems, etc.) start getting into the mix and you need to maintain all of them the table approach will be unmanageable fast because you would have to write an adapter for all of them to connect to your table for auth. Using ldap which is a standard and used by many projects will make it easier for you to maintain
Table with name and hash does not define an authentication scheme, it just defines a storage for the credentials. Authentication involves a protocol for the user to proove it's identity, like Kerberos or HTTP Digest. Organizations that deploy ldap don't, t deploy it for auth per se, they use Kerberos for that. Ldap is used for things like user organisatinal structure management (OU) or asset inventory. Once you deployed Kerberos for authentication and autheization it makes sense to use LDAP as your organization structure store, since most kern implementation will create an ldap anyway, eg. NT domain controllers.
At an application level..
In a Windows domain environment it can make sense to use LDAP as a means to use existing Active Directory information instead of duplicating all of your authentication.
Our company, Company A, may soon be partnering with Company B under some sort of licensing agreement. If it goes through, it will be necessary for users of Company B's web service to have access to Company A's web service. In other words, any user with an account for Company B's service should automatically have an account with Company A, but without having to create a new account...their's should be a shared account.
I'm not an expert in this matter (obviously) but I think this scenario would call for something along the lines of OpenID, but just between our two web sites. How would we go about sharing authentication is this way? I'm not familiar with the verbiage of the subject, which makes it difficult to google for guidance. Would this be a single-sign on?
Thanks.
You're really describing federation here, of which OpenId is one example (albeit one that's not suitable in this case). With federated identity Company A allows Company B to authenticate their users. This authentication process results in a token from Company B containing information (claims) about the user which is sent to Company A and used for authorisation.
Federation is not single sign-on, that tends to describe the situation where Company A runs lots of services and an authentication service as well - and logging into the authentication service allows a user to access all of the resources without having to re-authenticate.
Without knowing what the architectures involved are it's hard to recommend an approach. The standard way to transport claims is in a SAML token. In a Microsoft environment you can use the Windows Identity Framework to write web services which understand SAML, and ADFS "Geneva" to issue SAML tokens from an Active Directory. There are similar solutions for other identity stores, such as IBM's Higgins.
I don't think OpenID is really an answer here. It matters very much how users of B's web service currently authenticate to these web services. I assume that they use username/password pairs, and assume that you want them to continue doing so even for A's web services.
If so, the next question is how the password gets transmitted and validated. I assume that B currently uses "Basic Authentication" (you need to confirm this with B). If so, authentication is straight-forward in principle: In an A web service, also use basic auth, which causes users to send their passwords to A, IN PLAIN TEXT. Use https to encrypt the passwords on the wire.
Then, having a copy of the password, validate them with B, e.g. by having A's service sending a request to some dedicated service at B which just confirms the password as correct.
The downside of this setup is that users have to reveal their passwords to A; by means of the licensing agreement, you need to establish trust that A won't abuse these password (i.e. that they will not store them, and not use them to incarnate a user outside of the agreed processes).
You have two problems, I think.
Allow Company A machines to authenticate Company B users (and vice versa?)
Provide resources on Company A machines for Company B users.
Single sign on, or any authentication solution like OpenID, solves the first part (and may be sufficient for static content); you still will need to actually create accounts or otherwise allocate resources on Company A machines for these now authenticated users.
For example, StackOverflow uses OpenID to authenticate users. This means that StackOverflow can leave the part of figuring out who you are to other services, such as Google or Facebook etc. However, StackOverflow still needs to create a local account for you, to track your reputation, send you updates to your questions, and other things.
For just the authentication part, here are a couple of options:
If Company A already support OpenID, then Company B could just be an OpenID provider. You would still also want to add some code to Company A's website to ensure that a user logging in with OpenID is authorized, i.e., from Company B.
If Company A and B both use LDAP (e.g. Microsoft Active Directory) to handle authentication for internally, then you can probably add a forwarder to have Company A query Company B's LDAP servers to authenticate users (subject to appropriate firewall tunneling).
Or you can do it more statically, by having Company B provide a list of users, and having Company A pre-create accounts for all of those users ahead of time. This is the simplest but doesn't handle change of personnel from Company B very effectively, unless you set up an additional synchronization process. Here you would probably generate passwords (e.g., lastname+employeeID or random strings) for each account and have Company B distribute them to its users.
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