Windows Azure PowerShell is a module that provides cmdlets to manage Azure through Windows PowerShell.
Here you can find an official documentation on how to install and configure Azure PowerShell. But in a nutshell, there are two simple steps.
Step 1:
Download and run Microsoft Web Platform installer, which will guide you through the Windows Azure PowerShell installation. The process is a bit lengthy and includes some heavy Microsoft components, such as IIS Express and SQL Server Express. Note that a system restart may (will?) be required during the installation, so prepare accordingly.
Step 2:
Open Azure PowerShell and configure it to use your Azure account, as explained in the documentation.
Two methods are available – via your Azure credentials (with session available for the next 12 hours) and certificate-based. The former did not work in my case, resulting in some strange error, so I had no choice but to go with certificates option. Surprisingly, the setup went extremely easy. First, download your settings file with Get-AzurePublishSettingsFile cmdlet. Second, import the resulting file with Import-AzurePublishSettingsFile cmdlet and delete the file from the local system.
This week I dedicated some time to check what Windows Azure is about. Here are some notes I gathered during those days. I have some background in VMware and AWS, so the notes are mostly around the differences between those and Windows Azure that I spotted.
The first thing to note is that single Management Console provides access to all Windows Azure functionality pieces. Here those pieces look like the parts of a whole. In AWS each service actually is a separate service (with some of those services being integrated), and the console clearly reflects that.
Virtual Machines and Virtual Networks Those are two basic concepts that are much the same between Azure and AWS, besides maybe some terminology differences:
Amazon AWS
Windows Azure
Instance
Virtual Machine
(Instance) Type
(VM) Size
Start, Stop, Terminate
Start, Shut Down, Delete
AMI (= Amazon Machine Image)
(VM) Images
VPC (= Virtual Private Cloud)
(Virtual) Network
My feeling is that similarly named type/size on Azure is much slower than its AWS counterpart, but I cannot prove that with some test results yet.
VM Images Just like AWS, Azure provides you large set of images to start your VM from. There is no marketplace for 3rd party images yet, but you can create your own images if you need to. Two major differences here are the need to go through all sysprep burden on your own and the fact that the original VM is deleted (sic!) after it was captured as an image. Yet, this may be not that bad to avoid some confusion, considering that original instance is mostly wiped after sysprep.
IP Addresses Unlike AWS, where internal IP address of an instance within VPC will remain constant for the instance lifetime (that is – until the termination), here both external and internal IP of the VM will not survive the shutdown and will be changed after you turn it on. A possible workaround is to shut down the VM from inside the guest OS and not from the Management Console. This way the VM is considered running by Azure and all VM resources, including IP addresses, are preserved. Note that in this state the VM continues to eat your budget! [ Update (May 2014): Here is a great article on the topic. Also, setting static IP address is now possible via PowerShell. ]
Cloud Service The concept of cloud service does not exist on AWS, and is not easy to create simple explanations of what it is. The explanation from Microsoft pretends to be complete, but is mostly confusing. There are some better explanations on the net, much more suitable for newbies – for example this one, which explains the concept by giving three examples of cloud services: 1) Small HTML site. 2) Complex 2-tier web application built on ASP.NET and SQL Server. 3) Virtual network with multi-server application cluster and local AD installation. Each VM lives inside some cloud service, even if it is a cloud service with single VM inside. Each cloud service has own permanent DNS name under “cloudapp.net” domain, short and fully resolvable on the internet, and single public IP address. The IP address will be released after all VMs in the cloud service go down, but the new IP will be associated with the same DNS name after the service will be up again. Each VM in the service will get own externally available ports (so-called “endpoints”), which are mapped to some private ports on the VM itself. Those port numbers do no change, making configuration of various connection managers (like mRemoteNG) static and easy to maintain. In addition, cloud service may be configured to act as a load-balancer for containing VMs, eliminating the need to maintain separate entity for that (like, say, ELB on AWS).
Name Resolution There are significant differences related to name resolution between Azure and AWS. The build-in DNS service is intended to provide name resolution for virtual machines that reside in the same cloud service only. That is, even if you have two virtual machines that are located on the same virtual network, but belong to different cloud services, you will need to use your own DNS server solution in order for them to communicate directly by hostname. I guess this is one of the reasons for Azure-provided DNS server not being able to perform reverse lookups. Pay attention that setting own DNS server in Azure is not so straightforward given that internal IP addresses may change over time. [ Update (May 2014): Things have changed. read about it here. ]
Active Directory Windows Azure Active Directory is not a Domain Controller. You can use it to sync on-premises AD with Windows Azure AD to easily enable SSO, but you can not join computers to Windows Azure AD. In addition, it appears that you cannot delete Windows Azure Active Directory that you don’t need anymore. Well, at least they don’t charge for it. But anyway, if you do need full Active Directory (with Domain Services) in Azure – recall that it requires own DNS server…
Storage Windows Azure Blob Storage is somehow similar to S3 in AWS – but only if you need programmatic access. There is no way to upload files there via Management Console, and I was unable to find third party utils or browser extensions that can do it for you without mandatory registration to their service (and providing them your Azure credentials). [ Update (May 2014): CloudBerry Explorer for Microsoft Azure Cloud Storage seems to do that job perfectly! ]
Security There is no AWS-like separate “security groups” in Azure. Instead, the same functionality is provided by endpoints that are configured directly on VM level (see my notes on cloud services above). The major drawback of this approach is lack of single place to maintain access rules. However, it makes some sense when you recall that each VM has own public port number for the same protocol.
After struggling some time with CAS, I finally ended up working with SimpleSAMLphp package. I can recommend it as really simple yet powerful software. The package contains ready-to-use SAML 2.0 IdP site and provides PHP API to integrate your application with SAML 2.0 Service Provider functionality. The handling of the actual authentication process is delegated to a rich set of authentication modules, and in case no build-in module fits your needs – you have all the power to implement your own module in hours.
[ Update (June 2014): Please take some time to check John’s comment below. ]
Last week I spent some time investigating SAML 2.0 support of Central Authentication Service 3.5.1 (latest version of CAS at the moment of writing). The results were disappointing.
CAS was developed by Yale University in early 2000’s and was donated to open source in 2004. It is primary used in the academic networks, but the use is now extended to the enterprise world. Initial versions of CAS were built around own custom interoperability protocol. Later it was extended to support more protocols – both standard (such as SAML 1.1, OAuth, OpenID) and custom (REST API).
The skeleton for SAML 2.0 support was implemented around 2003. The implementation was driven by the need to integrate CAS with Google Apps for Education even before SAML 2.0 was finalized as a standard in 2005. As you may guess, this implementation is not fully compatible with the approved standard. Unfortunately, it did not change a lot during those ten years. The relevant documentation page says “SAML 2.0”, yet mentions the fact that it is actually intended for Google Accounts in the big red warning at the top. The supporting code is more conscious and presents itself as “GoogleAccountsService”.
But even if you don’t really care about spec compatibility, SAML 2.0 implementation of CAS is extremely limited and is not fully secure.
First, CAS implementation does not support SAML 2.0 metadata. Besides the inconvenience of manual configuration on SP side, it has serious implications on the IdP itself. CAS will not maintain the list of trusted SPs – it will be glad to work with any SP, including malicious ones, and will not verify validity of signed authentication requests. Actually, the whole request content besides the request ID (which must be returned in the resulting assertion) and “AssertionConsumerServiceURL” attibute (see below) is simply ignored.
As another implication of missing metadata notion, CAS will not have the pre-configured return URL for each SP and will rely on “AssertionConsumerServiceURL” request attribute. This attribute is defined as optional in SAML 2.0 specification, and some SP implementations do not provide it. Obviously, CAS will fail (in the ugly way – with NullPointerException) if this attribute is missing and will not be able to continue the flow if it does not contain valid URL. And if all this is not enough, just think about invalidated redirects…
The content of the resulting response is also far from being perfect. It is built from a fixed template, with only few values replaced. Among hard-coded values are assertion issuer (sic!), authentication method and some dates. Even the computed values are mostly not configurable – for example, the assertion is always valid for 1 year. Authentication attributes that are required by some service providers are not supported also.
Bottom line:
If you are looking for enterprise-grade software to be your SAML 2.0 Identity Provider, CAS 3.5.1 is not for you.
Windows Azure PowerShell is a module that provides cmdlets to manage Azure through Windows PowerShell. 