Yesterday I got a call from a Microsoft representative asking if we supply "hosted solutions", presumably as part of the big Windows Azure push. As soon as I got off that call, our marketing director came into my office and said the majority of our customers are demanding Active Directory integration in the next version. Then it occurred to me: how does one use Active Directory in a "hosted solution" if the application does not live on the customer's network?
As a more general question about Active Directory integration, what kind of functional changes does that usually imply for an app? Does it mean a user is signed into the app just by authenticating to Active Directory or does it mean the app gets its list of users from Active Directory or does the creation of new users or groups in the app create new users or groups in Active Directory?
Am I just caught in the crossfire of a war of buzzwords?
You're not. Active Directory can be run across the public Internet, though this complicates the security and setup of the network rather considerably.
Generally, authenticating an app against Active Directory means that your membership provider (for example) would call into Active Directory to do the authentication and, after that, the user is simply logged in; you don't keep active credentials, etc, in your own database. However I would consider it smart to cache that information as well, and be prepared to authenticate against that cache in addition to the directory, in case the domain controller is unavailable for authentication (an especially large risk if you're running the directory across the Internet).
You can use Active Directory Federated Services to enable authentication using AD over the internet between two organizations. See: http://technet.microsoft.com/en-us/library/cc786469.aspx
I've never used it only read about it. Hope it helps.
The accepted answer explains the role of Active Directory and I agree that caching basic user information may be useful in many instances.
Active Directory can be expanded outside of a corporate network, to the internet and connected web services. As another user mentioned, this is achieved through ADFS (Active Directory Federation Services) which allows "trusted" connections to be set up between separate authentication services. There were a number of scenarios explained as part of the "Office 365 Jump Start" webinars:
http://technet.microsoft.com/en-us/edge/office-365-jump-start-04-microsoft-office-365-identity-and-access-solutions
After viewing these, I immediately thought that a "hosted" AD and ADFS service would be useful, where a customer doesn't want to maintain the AD servers internally (Microsoft don't recommend running less than 5 seperate servers if you're doing this!) Recently, Microsoft have also launched their Azure cloud platform. One of the services they provide is labelled "Identity" which you can see here:
http://www.windowsazure.com/en-us/services/identity/
This is Microsoft's own solution to hosted AD services. In fact, they even mention using their "Identity" hosted service as a solution for SSO (Single Sign-On) for Office 356 and even Google web apps.
I am still learning about AD and Microsoft's cloud offerings, but I hope this points you in the right direction.
There's an article here: http://www.developerfusion.com/article/121561/integrating-active-directory-into-azure/ which describes in-depth how to integrate Active Directory with Azure - hope that helps.
Active Directory can be run across the public internet but you will experience lag times which may cause your app to time out or crash depending on your bandwidth. In the past, I have setup accounts with another company called ultradns.com who specializes in these types of scenarios. hope that helps.
You'd be best off going with a true hosting framework if you would like any support from MS.
I'm sure you'd like some links so:
HMC (Hosted Messaging and Collaboration)
The ONLY true blog I know about on the framework is from Kip Ng
The ASP.NET forums are a good resource for questions on the Framework as well.
An example of the work that goes into configuring AD for Exchange multitenancy is here, though it is based on an older version of the framework a lot of the same principles apply.
Also, try searching on the keyword multitenancy for some articles.
Related
I have a standalone web application (not an add-in) and I would like to access Project Server PWA oData from this web application without using the PWA username/password combination.
I can do this for SharePoint oData by registering my web app in Azure AD and configuring the application to require "Read" permissions from "Office 365 SharePoint Online"
If you are interested to do this for SharePoint data, see this article for details: https://www.itunity.com/article/integrating-angularjs-aad-office-365sharepoint-part-1-622
My problem is that I want to do the same for a Project Server, but can't see any relevant Project Online permission in Azure AD.
Has any one ever accessed Project Online using Azure AD tokens?
My 10 Minutes of Internet Research™ leads me to believe this isn't available but that it was a planned feature at one point. [see here]
Without knowing much (anything) about Project Server, this seems like a situation I've dealt with on AWS at work. We have a bunch of endpoints that are secured using IAM (AWS) credentials and we can't leave those creds lying around in our app (because that would be silly). Our solution is to generate access URLs server-side and hand them out, these typically will have a time limit and be restricted to a very specific action.
A quick search for Azure's equivalent to IAM tells me that you might be able to do something similar though I'm unsure it exists for Project Server.
That failing, you could always set up an intermediary micro-service that acts as proxy and has the username/password combo. We do stuff like this all the time with Lambda (AWS's serverless functions).
I've created a website within the company that utilizes our active directory server to authenticate. I am concerned about security surrounding setting up relying parties with "localhost" domains.
I've pretty much followed this guide on setup. You'll notice about halfway down the page, there is a step to set up the development environment, localhost:44336 as a relying party.
I am concerned that someone could easily get the location of our federation metadata document, and simply roll their own project utilizing the same port and get access to our active directory. Is this a valid concern, or am I worrying over nothing? What would be a better alternative to having to use localhost in this configuration?
Yes it's safe. The metadata document only describes information about endpoints and about the token that active directory is issuing. It doesn't inherently have anything sensitive about it.
The actual authentication is still going to be handled by AD and unless the curious user already has a way to successfully authenticate against your AD then it's rather useless for him to hookup into that document.
Could they potentially create an app that uses your authentication protocol? Sure, but what would be the point if nobody can actually authenticate against it. Allowing this sort of behavior to happen is one of the points of ADFS.
We store user email addresses, phones, physical addresses and other info in our corporate Windows Active Directory. Active Directory users need to access this information from all kind e-mail clients, such as Mozilla Thunderbird, Outlook, iOS Contacts, MacOS X, Android addressbook, etc. both from corporate network and outside if it, from Internet. We do not use Microsoft Exchange server.
I have found that this could be done via LDAP and CardDAV (through in-house app installed).
Which one to be better approach for accessing contacts in all kinds of email and mobile clients LDAP or CardDAV?
Think about this way - Active Directory is Microsoft's own implementation of LDAP, in addition to being their version of a database driven directory server. I wouldn't use anything else.
Also, Active Directory primarily supports LDAP based user authorization, so if you're going to be serving applications or individual requests outside of your local network and domain (especially from the various sources you named), this is a feature you'll need to consider for security purposes.
I'm not quite sure what your tech stack looks like, but many languages support LDAP based querying and authorization. I've cut my teeth in C# working with the System.DirectoryServices.Protocols namespace, and I've come to appreciate the adaptability and performance.
And, here is great link on the Protocols and Interfaces to Active Directory.
We are looking to use an Active Directory server to restrict access to certain URLs in our Spring application on a Weblogic server and I have no idea where to start. The problem should be quite simple as I understand it, we have a simple app which has a number of URLs:
<root>/page1.do
<root>/page2.do
<root>/page3.do
etc.
And an Active Directory servers which lists the users in two groups, such as "Admin" and "User". We would like it so that based on the login information provided (no SSO required), anyone in "Admin" can access all pages, anyone in "User" can only access page2.do and page3.do.
I have absolutely no idea where to start and Google isn't being very forthcoming. I would have hoped that this is an easy task (add AD server to weblogic, set up a config file). Anyone have any experience with this and links to good places to get started or a summary of what we will need to do to get it working in this fashion?
Cheers
You should be able to easily use your AD as an Authentication Provider in your Weblogic server(s). Here is some documentation to get started on how to do the configuration:
http://download.oracle.com/docs/cd/E12840_01/wls/docs103/secmanage/atn.html#wp1198953
After that, you can configure security roles and security policies in order to control access to your server's resources. Again, some docs to get started: http://download.oracle.com/docs/cd/E13222_01/wls/docs81/secintro/concepts.html#1083616
If you prefer a good book to start with, here goes my suggestion: http://onjava.com/pub/a/onjava/excerpt/weblogic_chap17/index.html. Although somewhat old, this chapter covers pretty much everything you need to know.
I am developing a web based intranet for my company. I just want to know is it a good thing for users to login the application using the active directory login details or shall i create a login together with the application db.
If there is anything better that this please suggest. This is my first application development so need help from experienced people.
Generally it's a good idea to try and minimize the number of accounts people need to have.
So I'd definately try and use their active directory login.
Also if desireable, you can automatically log people into your application using various single sign on methods. (Either integrated into IIS, or other.).
This makes for a very usable application, as people always forget login details, and hate to login again to other systems.
Only use Active directory for your intranet, if you infrastructure supports it.
You question is phrased as if you think the user to type there password in again to login to the intranet site - they should not do this! have windows pass on the credentials automatically. This is pretty much built in to dotnet/iis/etc.
Also AD will add group management a privledges so you can restrict areas of you intranet to members of certain groups.
And you support team already have the tools to manage all this.
PS you can enable FireFox to auto log on via NTLM and it is one of the most requested features for Chrome too so don't let browser issues put you off
There are several pros using Active Directory authentication in the intranet.
Thoses are the main ones:
You want to to keep authentication stores number as low as possible
Using Active Directory, users who have their desktop in the domain (as they should) will be able to use Integrated Windows Authentication. They will be able to log in without having to type their password.
An Active Directory authentication mechanism probably exists for your language
More information:
http://msdn.microsoft.com/en-us/library/ms998358.aspx
If you create a separate login system, then your users have to remember 2 different logins. Why bother, when their "real" login is right at hand?
Less code for you to write and better integration into the wider system. And, who doesn't want FEWER passwords to remember.
Definitely go for the Active Directory option, or use Active Directory as an LDAP server if whatever language you're using doesn't directly support AD. Active Directory actually makes a pretty good LDAP server.
If there is anything better that this please suggest.
OpenID?...