Identity Management and Access Control are anchors for virtually all critical processes, collaboration and transactions. To that end, it was no accident that Access Control was one of the very first cloud services we delivered within Windows Azure. In the years since, customers have often reminded us that in addition to being highly reliable and easy to use, identity management should be delivered by a cloud directory available for use by any business, large or small, around the world.
Built with the customer insights gained over the years from Windows Server Active Directory (the identity management system that 95% of enterprises to manage identities in their on-premise computing environments) Windows Azure Active Directory is built for business and built for the cloud.
To help make identity management in the cloud accessible and available to every business and organization in the world, we are announcing today that two key features of Windows Azure Active Directory are available at no charge.
With these changes Microsoft is making it easier than any other vendor to get started with identity management in the cloud. Try out Windows Azure Active Directory today and experience how easy it is to create an identity for your organization.
For more technical details on Active Directory, check out Alex’s Simon’s posts Enhancements to Windows Azure Active Directory Preview and Windows Azure now supports federation with Windows Server Active Directory.
I look forward to your thoughts and questions below.
Windows Azure Business Planning
For many deployers of infrastructure as a service one very topical infrastructure management framework is OpenStack. Typically deployments of OpenStack are rather complicated and when the number of nodes running OpenStack is large then configuration management toolkits are essential. Such toolkits include the likes of Chef and Puppet. Recently folks over at the ICCLab at Zurich University for Applied Sciences have made changes and issued a github pull request against PuppetLabs puppet OpenStack installer (a set of modules and manifests). With this contribution any organisation with a substantial OpenStack deployment, whose configuration is managed by puppet, can easily offer a standardised, interoperable (as demonstrated by FedCloud) interface. The work leverages the existing OpenStack OCCI implementation that is contributed by FI-ware. Further details on how to use the manifest can be found here.
An interesting article (by @cloudpundit) from Gartner: Don’t Let OpenStack Hype Distort Your Selection of a Cloud Management Platform in 2012. The recommendations are not specific for OpenStack. The following table form the exact same article gives a nice impression of Garnter’s recommendations:
The second recommendation is probably most interesting: ‘Use a 3rd party cloud API library […]’ – Why not even go for an Open Community Standard Driven Cloud API? OCCI for OpenStack is the answer and an implementation deployed on the EGI FedCloud.
At the EGI Technical Forum in Prague, the FedCloud task force presented their progress on bringing various standards together in order to compose a federated cloud within Europe. The presentation ended with an impressive live demonstration of that very work.
During the presentation eight different sites participated offering a set of standardised interfaces. Upon those sites cloud resources were allocated on very different infrastructure management frameworks but unified through the OCCI API. In one part of the demonstration 5 virtual machines were provisioned simultaneously, using OCCI, in Cyprus, Germany (2), Sweden and the Czech Republic. This was followed by a similar demonstration of provisioning storage and accessing that storage using CDMI through the same cloud resource providers.
In the European Grid Initiative Inspired Newsletter for September the recent activities of the EGI FedCloud initiative are summarised. OCCI is playing a key role for the goal of the Task Force to deliver a blueprint defining how federated virtualised environments can be implemented. A workable test bed has been set up by members of EGI as the implementation and deployment of a blueprint for cloud interoperability. Other standards at play also include OVF and CDMI.
The results of the EGI FedCloud inititative will be presented during the EGI Technical Forum taking place from 17.9.-21.9.2012 in Prague.
There is unanimous acceptance of all the best practices, team is together and every one wants to do this right. “Let us deliver a great one this time!”
In the face of time pressures to deliver, all these wishes fall by the wayside. At the end of the very same project, the same team, will ignore all of this and finally deliver the functionality with no clue as to the extent they actually met any of these goals.
I have always asked myself, why is it this way?
It is important these discussions are converted to rules in some form so that you can validate them. I have done this also a lot of time. But are these enforced every time code is created or changed? And this has always been the missing one partially or completely. Rules without enforcement is toothless. Don’t you agree?
One of the principles we are following at cloudmunch is just that!
As Kim Cameron, distinguished engineer on the Active Directory team, described on his blog today, we think that identity management as a service has the potential to profoundly alter the landscape of identity. In this post, I want to share how Microsoft is reimagining the Active Directory service to operate in this new world.
Identity management solutions like Active Directory, a feature of the Windows Server operating system, have been in use for a long time. Active Directory is most often used by midsize and large organizations where the substantial effort and cost necessary to build and keep an identity management system running have brought many benefits, including:
Organizations have built on these capabilities to create a range of solutions. One of the most important uses of Active Directory, often deployed in conjunction with identity products from other software vendors, is to provide a solid foundation to manage access to information, helping ensure that only approved users can access sensitive information. Similarly, Active Directory is often used as a basis to enable secure collaboration between people within the organization and, with Active Directory Federation Services or similar offerings, between organizations.
But for many smaller organizations, building and maintaining an identity management system and the associated application integration has been too hard and too costly to consider. Even organizations that have successfully deployed identity management solutions are looking for ways to make identity management easier and to broaden its reach.
Here in part 1 of a two-part posting, we will look at how the use of cloud architectures and cloud economies of scale is enabling us to offer Active Directory as a turnkey service at a cost that puts this powerful collection of capabilities within reach of essentially everyone—even small organizations without an IT staff. We see this as very important. It opens the door to “democratizing” identity management so it becomes a foundational capability that every organization and every software developer can count on—no matter what platform or technology base they are building from.
In part 2, we will look at how offering Active Directory in the cloud as turnkey services provides an opportunity to reimagine the way that directories can be used to enable the social enterprise—and how it enables developers to easily create applications that connect the directory to other software-as-a-service (SaaS) applications, cloud platforms, an organization’s customers, and social networks.
In evolving a powerful and widely deployed solution like Active Directory, we have to be very careful that we don’t create new issues while we’re addressing these new opportunities. In this overview, we provide some background on how we are reimagining Active Directory and highlight some of the key ideas driving this work.
We have taken Active Directory, a widely deployed, enterprise-grade identity management solution, and made it operate in the cloud as a multitenant service with Internet scale, high availability, and integrated disaster recovery. Since we first talked about it in November 2011, Windows Azure Active Directory has shown itself to be a robust identity and access management service for both Microsoft Office 365 and Windows Azure–based applications.
In the interim, we have been working to enhance Windows Azure Active Directory by adding new, Internet-focused connectivity, mobility, and collaboration capabilities that offer value to applications running anywhere and on any platform. This includes applications running on mobile devices like iPhone, cloud platforms like Amazon Web Services, and technologies like Java.
The easiest way to think about Windows Azure Active Directory is that Microsoft is enabling an organization’s Active Directory to operate in the cloud. Just like the Active Directory feature in the Windows Server operating system that operates within your organization, the Active Directory service that is available through Windows Azure is your organization’s Active Directory. Because it is your organization’s directory, you decide who your users are, what information you keep in your directory, who can use the information and manage it, and what applications are allowed to access that information. And if you already have on-premises Active Directory, this isn’t an additional, separate copy of your directory that you have to manage independently; it is the same directory you already own that has been extended to the cloud.
Meanwhile, it is Microsoft’s responsibility to keep Active Directory running in the cloud with high scale, high availability, and integrated disaster recovery, while fully respecting your requirements for the privacy and security of your information.
Sounds straightforward, right? In practice, it really is easy to use Windows Azure Active Directory. To illustrate this, let us take a look at how a directory gets created and used when an organization signs up for Microsoft Office 365.
Today Microsoft Office 365, Microsoft Dynamics CRM, Windows Intune software and services, and many third-party applications created by enterprises, established software vendors, and enterprise-focused startups are working with Windows Azure Active Directory. Here we focus on Office 365 and look at how Windows Azure Active Directory helps enable Office 365.
Each time a new organization signs up for Office 365, Microsoft automatically create a new Windows Azure Active Directory that is associated with the Office 365 account. No action is required on the part of the individual signing up.
With an Active Directory in place, the owner of the Office 365 account is able to easily add users to the directory. The figure below shows how I would add a new user to my personal Office 365 account.
The owner of the account is also able to manage passwords for the users, determine what roles they are in and which applications they can access, and so on. An example of this type of setting is shown in the figure below.
Now note several interesting aspects of the experience that the owner has when signing up for Office 365:
The ease of use; great common experiences like SSO; shared context between applications, including information about the people in an organization, their relationships, and roles; and efficient, highly available operations makes Windows Azure Active Directory a great foundation for many applications and services.
As the example above shows, for new organizations, it is very easy to get started with Windows Azure Active Directory. But what if an organization is already using Active Directory for on-premises identity management? To support this, Microsoft makes it easy to “connect” Windows Azure Active Directory with an existing directory. At the technical level, organizations can enable identity federation and directory synchronization between an existing Active Directory deployment and Windows Azure Active Directory.
When an organization does this, its Active Directory is, in a sense, stretching over both an on-premises and a cloud deployment. The ability for Active Directory to operate across both on-premises and cloud deployments in a hybrid mode enables an organization to easily take advantage of new cloud-based platforms and SaaS applications, while all of its existing identity management processes and application integration can continue unaffected.
In addition, being able to operate in this hybrid mode is critical for some organizations because of business or regulatory requirements that mandate that certain critical information, such as passwords, be maintained in on-premises servers.
To make Active Directory available as a service, you might think all we had to do was take a copy of the Windows Server Active Directory software and run it in the cloud—that is, use Windows Azure to create a new virtual machine for each customer and then run Active Directory on this virtual machine. But that kind of approach wouldn’t give us the efficient operations or high availability that we are able to provide with Windows Azure Active Directory.
To make the Active Directory service operate at extremely high scale and with very high availability (including the ability to do incremental servicing) and provide integrated disaster recovery, we made significant changes to the internal architecture of Active Directory and moved from a server-based system to a scale-out, cloud-based system. For example, instead of having an individual server operate as the Active Directory store and issue credentials, we split these capabilities into independent roles. We made issuing tokens a scale-out role in Windows Azure, and we partitioned the Active Directory store to operate across many servers and between data centers.
Beyond these architectural changes, it was also clear that we needed to reimagine how Active Directory would operate in the cloud. In talking with many developers, customers, and partners, we heard that they wanted us to enhance the ability for Active Directory to “connect”—to the new Internet-based identities from Google, Facebook, and other social networks; to new SaaS applications; and to other cloud platforms.
All this work involved efforts by many people and teams across Microsoft. To get everything operating at Internet scale has been a substantial undertaking, which has taken several years.
We have made good progress. Today we have hundreds of thousands of paying organizations using Windows Azure Active Directory as part of applications such as Office 365, Windows Intune, and many third-party applications. For example, organizations using Office 365 and the underlying Windows Azure Active Directory include Hickory Farms and Patagonia. Similarly organizations are building custom applications using Windows Azure Active Directory; for example, easyJet in Europe is using Windows Azure Active Directory Access Control and the Windows Azure Service Bus to enable flight check-in and other tasks for airport gate agents.
In this first post, we focused on how we are reimagining Active Directory as a cloud service. We discussed how the application of cloud architecture and economics is making it possible to bring the power of organizational identity management to organizations of any size and IT sophistication, with great ease of use, low cost, and high availability.
Hopefully this post conveyed that Active Directory as a service is here now and that it is very easy for organizations to obtain and use. Many applications are already integrating with Windows Azure Active Directory, including SaaS applications such as Office 365 and many custom applications built on Windows Azure and other platforms.
For IT professionals and users within organizations, these integrations provide many benefits, including common experiences like SSO; shared context between applications, including information about the people in an organization, their relationships, and roles; consistent management; the ability to seamlessly extend existing directory deployments and identity management processes to the cloud; and efficient, highly available operations.
In my next post, I will cover what this reimagined Active Directory can mean for developers and how moving to the cloud is enabling Microsoft and software developers to work together to reimagine the role of Active Directory. We will focus on how we are making it easier for developers to integrate with Windows Azure Active Directory and look at how Windows Azure Active Directory can be used as a platform to enable the social enterprise.
In particular, we will look at enhancements to Windows Azure Active Directory and the programming model that enable developers to more easily create applications that work with consumer-oriented identities, integrate with social networks, and incorporate information in the directory into new application experiences. And we will talk about how developers can use Windows Azure Active Directory to support new scenarios that go well beyond the “behind the firewall” role that identity management has historically played. We are excited to work with developers and help them build these next-generation experiences and capabilities for organizations and users.
– John Shewchuk, Microsoft Technical Fellow
The post Reimagining Active Directory for the Social Enterprise (Part 1) appeared first on Platform as a Service Magazine.
Developers like you deploy code to hundreds of thousands of apps every month on the Heroku platform. Some of these are production apps which serve hundreds of millions or even billions of requests per month. Uptime of the platform is critical for such apps.
We want to achieve the sustained reliability that these apps require. But when there are incidents that impact uptime, we want to maximize our transparency and accountability to you and all developers on the platform.
Today, we’re launching a completely redesigned status.heroku.com, which provides real-time status of the platform, the ability to sign up for email or SMS notification of incidents, and recent uptime history in both visual and numeric formats.
Let’s zoom in on each of these points.
Incident monitoring: The circles at the top show green (all systems go), yellow (intermittent errors or partial impact), or red (major outage of specified component). The boxes below describe the incident in detail and show how long it’s been happening. This page uses Pusher to refresh the page automatically as we post updates, without requiring you to continually reload to track progress of an in-progress incident.
Proactive Alerts: Click “Subscribe to Notifications” in the upper right corner to receive notifications on platform incidents in a variety of formats: email, SMS, Twitter, or RSS.
Uptime numbers for the last month: At the top, you’ll see uptime numbers for the previous month. This provides an at-a-glance answer to the question of “How stable has Heroku been lately?” Our numbers here haven’t been as good as we’d like in the last few months, but by posting them publicly here we intend to create the transparency and accountability that will help drive us to improve. After all, you make what you measure.
Timeline: Most status sites, including the previous implementation of the Heroku status site, list incidents in a blog-like format. For the new Heroku status site, we took the opportunity to try something more innovative, and the result was the timeline view. Incidents are displayed on a vertical timeline. When the platform is performing normally, the timeline is green. When an incident occurs, a red or yellow bar sized to the duration of the incident is plotted against the timeline. By scrolling down the timeline, you can get a feel for the duration and frequency of recent incidents, without needing to scrutinize each one individually.
Production vs Development: There are two circles for status, two uptime numbers, and two timelines. Why the separation? Heroku’s operational efforts always prioritize continuity of service for existing production applications over service for development/prototype/hobby apps, or the ability to take development actions (such as deploying new code) against production apps. If you can’t push code to your app for ten minutes, it’s an annoyance. If your production app stops serving traffic to your users for ten minutes, that’s a much bigger problem. Today, production apps are defined as any app running two or more dynos with a production-grade database.
API: Like other parts of the Heroku platform, the new status site has its own API. Use this to create a custom monitoring tool, your own front-end, or whatever you like.
Documentation can be found in the Dev Center.
This new status site is more than just eye candy: we’ve provided transparency and demonstrated our accountability for the uptime of the Heroku platform. It’s our goal to earn a long-term track record of reliability, one that is deserving of the critical production apps which many of you have entrusted us with.
We’d like to extend a big thank-you to the approximately 350 people who helped us beta test the new status site. If you’d like to help us test future beta releases of Heroku products, sign up for our private beta list.
I’m very excited to announce one of the projects that I’ve been spending a lot of time on lately — BuildHive! It started as my Christmas/New Year break hack project, but since then it has grown into a real project inside CloudBees.
BuildHive is a free service that lets you set up Jenkins-based continuous integration build/test jobs for your GitHub repositories with just a few mouse clicks. It is freely available for anyone to use.
The top page shows recent builds that have happened on BuildHive. If you keep the page open for a while, you’ll see new cards appear from the left for new builds in semi-real time:
Let’s click the big red “Add your Git repositories” button to set up CI jobs for your repositories. It’ll first ask you to approve GitHub OAuth integration, so you need to click “Allow” to let us see your repositories and install hooks:
Once logged in, you’ll see the screen to select repositories from GitHub. It will show all your personal repositories as well as repositories from any organizations that you belong to. If you have too many repositories, use the filter text box to narrow down the candidates.
All you have to do to set up a CI job is to click “Enable”. We’ll sniff your repository to guess the initial build configuration. The auto sniffing of the repository contents is extensible, but the initial set is geared toward Java projects (like Ant, Maven, Gradle), but also covers some Ruby projects as well.
In any case, auto-sniffing can only do so much. You can tweak the setting via the configuration screen (for example, to update where the notification e-mails are sent):
When you enable a repository, we auto-install necessary hooks for you, so that it’ll build your project every time someone pushes to your repository. In addition to that, we’ll speculatively build incoming pull requests to your repository (by building the result of the merge between the incoming commit and the current tip of the branch for which the pull request is sent), and report the status as a comment to the pull request:
So you can use that as one of the inputs to determine if you are going to merge a pull request or not.
Behind the scene, many of the features in BuildHive rely on our value-add plugins for Jenkins Enterprise by CloudBees, which are available for customers to use on their own Jenkins instances. For example, we use the Templates plugin to model various project types and for auto-sniffing. We use the Validated Merge plugin to speculatively build pull requests. So, while it isn’t as easy as it could be, our customers can set up a similar environment in their own Jenkins instance, or they can re-use those pieces to create similar but different workflows.
And needless to say, there are many other open-source plugins at play, too — it really shows off the power of extensibility in Jenkins.
For almost as long as we can remember, full text search has been one of the top feature requests for Google App Engine. Since our talk at Google I/O last year, we’ve been hard at work getting search ready for our developers, and today we’re happy to announce that we are making it available as an Experimental feature.
The Search API, like many other features of Google App Engine, allows you to take advantage of parts of Google’s infrastructure to add full text search to your application. This release includes a host of features including searching specific fields and ranges as well as more advanced features like scoring and snippeting. Whether you want to index products and search price ranges or just match keywords over articles and comments, the Search API is ready for you to test drive.
To help you start integrating search into your application, we’ve created a sample application and walkthrough and documented our known issues. We are extending a limited free quota for testing during our Experimental period.
As always, we’re grateful to all of our trusted testers for their patience and feedback in preparation for this launch, and we look forward to your feedback on the groups. Happy searching (and finding)!
– Posted by the Google App Engine Full Text Search Team