Given there is a requirement from a 3rd party application where LDAP integration is required for authentication, authorization and assignment of users/roles with lookup to directory services or user repository...
When the application environment is Microsoft Server 2012 with WAS to support the application and the server can only access security principals through a web service...
Is there a way to provide LDAP or AD LDS to integrate with the web service or even to sync the local repository with the system of record?
This will probably provide many routes for discussion, but let's assume the application for now can only best subscribe to a LDAP instance for this and AD is not being provided directly to the environment where the application exists AND AD isn't even the system of record - that is exposed from a web service.
This is fundamentally the definition of a meta directory or Virtual directory.
That is, rather than directly contact the directory service for usage, instead there is an abstraction layer, often caching, perhaps uniting data (on the fly per request, or in advance as changes occur).
There are any number of vendors that provide such services in products.
Related
If you were to build an enterprise SaaS app today, what would be the preferred protocol/endpoint to obtain the list of users, emails and groups from an Azure AD deployment?
Historically this was done via LDAP connection to an Active Directory Domain Controller, and I see that Azure offers an LDAPS service (Azure AD DS).
ADFS, which is quite widespread, is just a SAML-compatible IdP, but it doesn't seem to provide an API for listing the directory of users.
The Microsoft Graph API seems to be able to provide at least some of this information, but it seems to be fairly new and very widespread. There's also something called SCIM that appears to have broader support, but it doesn't seem to be super popular on enterprise cloud apps either.
My research has shown that the apparent right answer for this problem is to implement SCIM 2.0 APIs on the product.
The main annoyance of the approach is that SCIM 2.0 is a protocol that is triggered by the directory provider (i.e. a SaaS app will receive an API call from Azure AD when a user needs to be created or updated, instead of the SaaS app contacting a directory endpoint to fetch the information when it is needed).
This creates a few annoyances such as potential race conditions when updating user information in the middle of application processes, or the fact that updates to the directory can't be triggered at convenient times (such as nightly, for example). Debugging/testing is also more problematic.
Hie Please explain which to use when, OpenDS OpenDJ OpenAM. Thanks.
OpenDJ is an open source project building LDAP and REST base Directory Services. OpenDJ is continuing in open source the development of OpenDS, a project that was started by Sun Microsystems, but abandoned by Oracle.
OpenAM is an open source Authentication, Authorization, Web Single Sign On, Federation solution that is flexible, extensible and highly scalable. For its configuration management, OpenAM embeds OpenDJ. For its user stores, it relies on LDAP directory servers, and is very well integrated with OpenDJ.
[Disclosure: I am product manager at ForgeRock, the company that supports and commercializes OpenDJ and OpenAM]
OpenAM is entirely different from that of OpenDJ or OpenDS. Let me clear all your doubts:
OpenAM is an open source access management and federation server platform, backed by ForgeRock. It was sponsored by ForgeRock until 2016.Now it is supported by Open Identity Platform Community.
What exactly OpenAM is ?
OpenAM provides a service called access management, which manages
access to resources, such as a web page, an application, or web
service, available over the network. Once it is set up, OpenAM
provides an infrastructure for managing users, roles, and access to
resources.
It centralizes access control by handling both authentication
(Confirming the identity) and authorization (Determining whether
to grant access to someone who has authenticated).
When you dive deep inside this beautiful service you will find,You can secure your resources and customize it through Open Access Policy and can implement social authentication, Multi-Factor Authentication ,Account Lockout, Single Sign-On etc. and can define Authorization policies in no time .
Moving on to OpenDJ ..
OpenDJ is a directory server which implements a wide range of
“Lightweight Directory Access Protocol” (LDAP) and also have
support for “Directory Service Markup Language” (DSML). OpenDJ is
written in Java language.
It was an internal project started by Sun Microsystems, which is now maintained by ForgeRock.
Let me help you with those big terms like LDAP and Directory :
Lightweight Directory Access Protocol (also known as LDAP) is an application protocol.
This protocol is used specifically for querying data as well as modifying said data.This is performed by using directory services –that is, a software system that stores, organises, and provides access to the information that is in a directory.
Conclusion:
OpenAM regulates who can access what resource ,when and under what condition while OpenDJ is the high-performance,Highly-available and
secure store for identities managed by the organization.
.
I am new to windows azure development.
I am developing an application for hosting online tests.
This application needs to have multiple authentication options like Windows live ID, Facebook etc.
It also needs to have default form based authentication fed by the database in back end (simple User name and Password match).
Based on the authentication mechanism different permissions will be available to the user.
Can anyone please suggest how i should proceed on this?
Thanks
Do you really need forms authentication, or do you just need an application specific store where people can use a credential specific to your app?
I'd suggest researching Windows Azure Active Directory and Windows Azure Access Control Services together. You may create either an AD tenant for your application store and use it as an Identity Provider for ACS or you could host your own Secure Token Service and Identity Provider which uses your backend database as the user store also registered with ACS. This means that all of your authentication goes through the same process and allows for you to have your own user store, plus the social Identity Provider capability.
The key here is that you want try to avoid having forms authentication AND Social, but rather a mechanism where multiple Identity Providers can be used, including one of your own.
As Gaurav stated there are a ton of resources out there for this:
Understand the difference between WAAD and ACS.
Provisioning an Azure AD Tenant as a Identity Provider in ACS
Windows Azure Identity
There are also many blogs and MSDN documents talking about how to set these up.
If you start with the default "ASP.net MVC4 Web Application" template in Visual Studio you get a web application mini-sample with an AccountController that supports local and 'social' accounts out of the box. See documentation here. It is based on DotNetOpenAuth (a fantastic lib with terrible documentation) and a Microsoft implementation of an special MembershipProvider which lives in WebMatrix.WebData.
Regarding the Azure Access Control Service 2.0: I have no idea what the status of this service is but it looks to me as if MS itself tries to discourage developers form using this service since it was to deeply hidden somewhere under Windows Azure Active Directory in the documentation.
I am creating a website and my company feels accessing active directory from internet can be a security threat. I would like the users to be able to log in using Active Directory Credential. Is there a secure way to do that?
I think that Active Directory Federation Services might be what you're looking for. Specifically the "Web Single Sign On" functionality.
Since you've tagged with question with "insecure-connection" I feel I must add that you should not, under any circumstances let user account data flow in to or out from your company's firewall un-encrypted.
Active Directory Federation Services (ADFS) is based on the emerging, industry-supported Web Services Architecture, which is defined in WS-* specifications. ADFS helps you use single sign-on (SS0) to authenticate users to multiple, related Web applications over the life of a single online session. ADFS accomplishes this by securely sharing digital identity and entitlement rights across security and enterprise boundaries.
http://technet.microsoft.com/en-us/library/cc736690%28v=WS.10%29.aspx
We have an application that uses Active Directory for its Authentication. This includes Kerberos multi-hop delegation which the application requires. It consists of a WinForms client, connecting to a set of Web Services via WCF 4.0, hosted under IIS 7.5.
Normally, this all gets installed on our Customers own hardware and integrates with their AD. But we have recently set the Web Services running on private cloud (accessible via IPSec VPN) with its own AD implementation, and where we can set-up a one-way Active Directory Trust between our AD and the customers AD then all is well, and the application works as designed.
However, we have a few customers who are running their AD on Small Business Server, and therefore it is not possible to set-up the trust.
Given the following constraints...
A major re-write of the application to not use AD/Kerberos is not a viable option.
Forcing the Customer to move off SBS to a full Windows Server AD is not a viable option.
... I am looking at ways to solve this problem that require the minimum changes to the core Application as possible.
I can see 3 options that seem immediately obvious:
Active Directory Certificate Services - Clients use a certificate issued from our AD which is linked to an AD account in our domain. But unsure of whether this would allow the Kerberos Delegation.
Active Directory Federation Services - This sounds like it also could do the job, but we have never used it before.
Active Directory Lightweight DS - If the customer was to install this and somehow link it to their AD and we set-up the trust to the LDS instance, could that work? Again, we have never used AD LDS before.
Does anybody have any experience of this situation or something similar?
Does anyone have any recommendations as to which of the 3 routes to look down first?
Does anyone have any other alternatives?
The certificate will work for authentication and delegation. You should also look at protocol transition. This will enable you to do something like a forms based auth on your site and have it transition to Kerberos on the backend.
AD LDS won't do much here. ADFS is going to require alot of rework in your app as well.