AWS

Connect your Azure AD to AWS Single Sign-On (SSO)

In this blog post, I will provide a step-by-step guide for how to integrate your Azure AD with AWS Single Sign On (SSO). The integration will enable you to manage access to AWS accounts and applications centrally for single sign-on, and make use of automatic provisioning to reduce complexity when managing and using identities.

Organizations usually like to maintain a single identity across their range of applications and AWS cloud environments. Azure Active Directory (AD) is a common authentication method as Office 365 often is used among companies, and might be the hub of authentication as it often is integrated with other applications as well.

If you are using AWS Single Sign-On (SSO) you can leverage your existing identity infrastructure while enabling your users to access their AWS accounts and resources at one place. By connecting Azure AD with AWS SSO you can sign in to multiple AWS accounts and applications using your Azure AD identity with the possibility to enable automatic synchronization of Azure AD Users/Groups into AWS SSO.

This makes perfect sense and often improves your ability to further automate how you handle user-lifecycle and access to your AWS accounts as you might already have some identity manager connected to your HR system like Microsoft Identity Manager or Omada in place for example. You can also leverage your existing process for applying for access to different systems, ServiceNow or similar solution might already be connected to Azure AD in one way or another which then could be leveraged for applying for access to different AWS Accounts.
There are also other benefits such as levering your existing MFA solution if your organization has such a solution in place.

To the good stuff! I will in this blog-post demonstrate how you can connect your Azure AD to AWS SSO and take advantage of its capabilities.

Creating a new Azure Enterprise Application

Login to your Azure portal and open Azure Active Directory. Under the Manage section, click on Enterprise application.

Click New application and select a Non-gallery application, give your new application an appropriate name and click Add.

Once the Azure gods have created our new application, head into the Overview page and select Set up single sign-on and choose the SAML option.

Under section, SAML Signing Certificate click Download next to Federation Metadata XML.

Please keep this page open as we later need to upload the metadata XML file from AWS SSO.

Setup AWS SSO

Login to AWS management console and open AWS Single Sign-On, please ensure that you are in your preferred region. If you haven’t enabled AWS Single Sign-On already, you can enable it by clicking Enable AWS SSO as shown below.

Click Choose your identity source. You can also configure your custom User portal URL if you’d like but it is not required.

Select External identity provider. Upload the AD Federation Metadata XML file downloaded earlier inside the IdP SAML metadata section and download the AWS SAML metadata file.

In the Azure SAML page, click Upload metadata file and upload the AWS SSO SAML metadata file.

If you have configured a User portal URL earlier, you need to edit the Basic SAML Configuration section and match the Sign-on URL.

Setting up automatic provisioning

The connection between Azure AD and AWS SSO is now established, we can proceed to enable automatic provisioning to synchronise users/groups from Azure AD to AWS SSO.

Note that you can use Azure AD groups but not nested groups ie. groups that are into groups.

Head over to the Provisioning page and change the mode to Automatic. Please keep this page open as we will copy values from AWS SSO.

In the AWS SSO Settings page, click Enable automatic provisioning

Take note of both values given in the popup

In the Provisioning page in the Azure portal, expand the Admin Credentials section and insert the values from above. It is also recommended to add an email address for notification of failures.

SCIM endpoint > Tenant URL
Access token > Secret Token

Note that these tokens expire after 1 year and should be renewed for continuous connectivity.

Click Test Connection and it should result in a success message.

Expand the Mapping section and click Synchronize Azure Active Directory Users to customappsso

Which attributes you want to sync over depends on your setup, but default setups you can remove all attributes except:
userName
active
displayName
emails
name.givenName
name.familyName

You then create a new attribute mapping objectId with externalId.

Important to note is that you can modify the email attribute to use userPrincipalName over mail as not all users have Office365 licenses which leave that attribute null.

In the Provisioning page, you can now set the Status to On. It is recommended leaving Scope set to Sync only assigned users and groups.
Click Save, it should take about 5 minutes for it to start synchronizing.

Our AWS SSO and Azure AD connection is now fully set up, when you assign Azure Users/Groups to the enterprise app, they will then appear in AWS SSO Users/Groups within around 40 minutes.

Creation and assignments of AWS SSO Permission Sets

Using Permission Sets, we can assign permissions to synchronized Groups and Users, these permission sets will later create IAM roles in accounts which they are assigned.
You can create new Permission Sets based on AWS Identity and Access Management (IAM) managed policies or create your own custom policies.

To create a new Permission Set in the AWS Management console you can follow the below steps:

  1. Go to the AWS SSO management portal, in the navigation pane, choose AWS accounts and then the AWS organization tab.
  2. In AWS account, choose the account that you want to create a permission set for, and then choose Assign users.
  3. In Display name, choose the user name that you want to create the permission set for, and then choose Next: Permission sets.
  4. In Select permission sets, choose Create new permission set.
  5. In Create new permission set, choose Use an existing job function policy or Create a custom permission set depending on your needs, click Next Details, and then select a job function or create a custom policy or managed policy.
  6. You can then complete the guide and click Create.

You should then see the message “We have successfully configured your AWS account. Your users can access this AWS account with the permissions you assigned”.

If you are more comfortable with the AWS CLI you can use create-permission-set and create-account-assignment in the same way if you would like to.

The most preferred way is however to use Infrastructure as Code and keep this in version control to manage and deploy this.
If you want to use CloudFormation you can use the below template as a base to get started.
https://github.com/pozeus/aws-sso-management/blob/main/template.yml

But be careful on how you deploy these AWS SSO Permission Sets and assignments since it needs to be executed in the Master account. You should always follow the least privilege principle and should therefore carefully plan on which approach you use to deploy these Permission Sets and assignments.
If you want to automate assignments and creation of Permission Sets further, I suggest you go with an event-based approach and assign Permission Sets using Lambdas.

Summary

In this blog-post I showed how you can connect Azure AD to AWS Single Sign-On (SSO), you can now manage access to AWS accounts and applications centrally for single sign-on, and make use of automatic provisioning to reduce complexity when managing and using identities.
Azure AD can now act as a single source of truth for managing users, and users no longer need to manage additional identities and passwords to access their AWS accounts and applications.
Sign in is accomplished using the familiar Azure AD experience, and users will be able to choose the accounts and roles to assume in the AWS SSO portal.

You now also have the possibility to use your existing automation process on how you apply for access, grant and revoke access to systems.

If you have any questions or just want to get in contact with me or any of my colleagues, I’m reachable on any of the following channels.

Email: christoffer.pozeus@tiqqe.com

LinkedIn: Christoffer Pozeus

andreas vallberg serverless integration

Serverless Integration

The integration landscape is changing and you are paying too much!

Serverless integration is our offering where we replace your traditional on-prem enterprise integration software with auto-scalable, fully managed, pay-for-what-you-use connectivity between your software applications on-premise and in the clouds.

Why serverless integration?

Enterprises has struggled with integration, where projects were setting up integration dependencies as part of the project and when the project closed down after delivery the integration dependencies were left in limbo with nobody to management.

Enter the era of integration software, where we established integration competence centers and purchased specialized software that was trying to make the integrations easier, deliveries faster and integrations manageable.

With 15 years in using enterprise integration software, We can see with a bit of hindsight that the promise of integration software has failed to deliver to us:

  • Visibility of the cost now cause integration to be a problem, instead of being spread out among the projects
  • Feature based selling of integration platforms often leave customers with a lot more features than they will make use of
  • Centralization leads to more structure, yes, but the structure comes at the cost of red-tape and more lead time for implementing solutions

So the solution to this was the Self service API’s – already touted by Jeff Bezos back in 2002 in his now-famous Mandate which sternly forced everyone into an API-first approach. Suddenly teams can consume other teams data and do integrations without talking to the intermediary.

Even though it is almost 20 years ago, we still see corporations trying to adopt this way of thinking, while also trying to save the Enterprise Integration Center.

A battle of many fronts

We see the Integration Competence Center concept being attacked on many fronts:

  • The software application owners and teams are building their own dependencies directly using API driven approach
  • Infrastructure is moving to the cloud, leaving no Servers to manage, cluster and consider
  • The different building blocks (i.e. features) of the old integration platform are becoming increasingly available from the existing cloud vendors rendering your integration software platform obsolete
  • Infrastructure is becoming code, Security Operations is becoming code.
    Why should the integrations reside in proprietary formats deep inside custom software which only a few selected people have access and knowledge how to manage

The way out

This is the challenge we at TIQQE has seen, and that is why we are providing integration-as-a-service in our unique way. Knowing that a big part of the integration work is in the details of the specifications and the major part of the integrations within an organization is very similar we have a different approach.

We provide fully managed integrations and we do this using software implemented in standard languages, on a well-known cloud platform using serverless patterns.

This means the integrations are built securely, with auto scaling from the start. It means we are using standard development tools and standard programming languages that already millions of developers know.

Governance is still key!

Our value add is not mainly focusing on the implementation of the integrations, but rather the management of the integrations and standardization of monitoring and handling them.

The freedom of building high-order value add systems as integrations, and the standardization comes as a support in terms of operational excellence, security, reliability, performance efficiency and cost optimization (Yes – those are the 5 pillars of well-architected framework from AWS).

Many of our customers have felt their integrations to be a black-box experience and they feel a lack of understanding of what they have and how it works. We are handling this by providing our Harbor solution, where you as a customer get full transparency to the documentation, the integrations and their health.

Business Impact

  • You will save money
  • No license costs
  • No hardware costs
  • No patching costs
  • No lock-in
  • Pay for what you use
  • Adapt to change

Please feel free to reach out to Jacob Welsh and let us speak about how we can help lower your costs, increase your business agility and provide insights into your integration landscape.We will set you free from all major integration platforms such as Microsoft Biztalk, Teis, WebMethod and many others.

COVID-19

Watch our Biztalk Replace webinar

In March, we launched a series of ideas of how companies who are suffering from the Covid-19 pandemic can quickly reduce cost and increase liquidity. If you missed the webinar around our second idea, reducing cost by replacing you Biztalk platform, you can watch it today.

Many companies are under tremendous financial pressure due to the COVID-19 virus. In early March, we sat down to figure out what we can do to help and came up with 4 ways of how we can reduce cost and increase liquidity in the short term for a company.

You can read a summary of the cost saving series here. The summary include links to all 4 ideas to give you a deeper insight of each idea. Every idea also include a financial business case which have two purposes:

  • Translate technology into tangible financials to motivate your CFO to support the idea.
  • Provide a business case template to reflect your specific prerequisites.

Biztalk Replace

Every organization needs to connect data between applications and databases to support their business processes. There are a lot of ways of solving the integration need but many companies have bought an integration platform from one or more of the major product vendors in the market such as Microsoft Biztalk, Tibco, Mulesoft, IBM Websphere etc. If you’re one of them, we have good news for you and your CFO.

According to Radar Group, who made a survey of 200 Swedish companies a few years back, integration is a hidden cost bomb. On average, companies spend 140 000 SEK in maintenance cost per year and per integration. On average, a company with 300 employees have 50 integrations if you’re in the retail or in the distribution sector, 70 integrations if you’re in the manufacturing sector according to the survey. The cost of integration is substantial.

You should reconsider your next Biztalk upgrade project

You can read the full blog post here

You can watch the webinar here

Webinar

Join our Biztalk replace webinar

Your integration platform is a cost bomb according to Radar Group so if your company are looking for quick savings due to the COVID-19 crisis, we can help you save 50-60% and provide an ROI in less than a year.

Many companies are under financial pressure during the ongoing pandemic and are looking for ways to reduce cost in the short term.

Your integration platform is a cost bomb according to a study by Radar Group. This webinar will present how you can replace your existing integration platform with a modern cloud solution from TIQQE and cheer up your CFO with substantial savings.

Join our webinar the 5th of May, 08:30-09:15, to learn more.

Please enroll here

You can also read our blog post including a financial example of a company with 100 integrations.

  • 2MSEK in savings the first year
  • 8MSEK in savings the following years
  • 34MSEK in accumulated savings in 5 years (49%)
  • Return on investment, less than a year

If you’re planning an upgrade from Biztalk 2016 to 2020, you will have an even greater business case.

Welcome!