We often build and deploy web applications specifically for users internal to our organisation. Azure Static Web Appsis proving to be an excellent replacement for Azure App Servicein these scenarios.
At a high-level the service provides you with a great set of features (outlined in the Azure release notes)
- Globally distributed content for production apps
- Tailored CI/CD workflows from code to cloud
- Auto-provisioned preview environments
- Custom domain configuration and free SSL certificates
- Built-in access to a variety of authentication providers
- Route-based authorization
- Custom routing
- Integration with serverless APIs powered by Azure Functions
- A custom Visual Studio Code developer extension
- A feature-rich CLI for local development
The desired experience?
The experience I wanted to achieve was that if one of our internal users browsed to any of our internal apps, they would be able to use SSO across them provided they were a member of the AAD group needed to access the app (or just a member of our tenant for organisation-wide apps) - no login button, just a seamless logged-in user experience.
It turns out this was super easy to get right! Follow below!
Authentication options
Azure Static Web Apps makes authentication easy to enable across the three pre-configured identity providers
- Azure Active Directory (AAD)
- Github or
These options allow users to login using a login button linking to the desired provider.
Initially I tried to use the pre-configured AAD provider, and when trying to log in using my company account I was presented with this approval dialogue
Meaning if I was able to get an admin to grant the permission, all users from our tenant would be able to log in to all Azure Static Web Apps, regardless of who had deployed them making this a non-starter for me.
Fortunately we already deploy our static web apps using the Standard plan for $9/per app/month, giving us the ability to use custom authenticationand use SSO with our organisations AAD tenant, internal app registrations and restrict access to groups / users in our tenants directory.
Getting it done!
To achieve the desired experience there are a number of components required
- the static web app (the website)
- an Azure App Registration for your app in your tenant
- an Azure resource group for your project (I’m working on the assumption you already have a subscription, if not read here)
- an Azure Static Web App for the web app
- an Azure Key Vault to safely store the secrets for your app
I will be showing you how to create, configure and deploy these using GitHub Actions, Bicep(for creating the Azure resources) and some once off scripts.
Info
All code is available on GitHub over here
Note
It is a good idea to wire up your Key Vault to a Log Analytics workspace or similar to track audit events when in production.
Initial setup and deployment
First we are going to scaffold our web app, define our infrastructure and deploy to Azure without any auth in place. Once done, we will move onto the configuration of the app with auth.
Scaffold the web app
For the purposes of this post, I needed a simple static web app and used the SvelteKitskeleton project with the static adapter.
|
|
You need to update the default svelte.config.js
to use the static adapter, see an example here.
Define the Azure Infrastructure
Resource Group
First, create an Azure resource group. For this tutorial I’m creating it manually from my terminal and Azure CLI
|
|
Resources
We will be deploying a Static Web App as well as a Key Vault using Bicep. I’ve split out the Bicep files to make them easier to work with as follows (filenames link to the code on GitHub)
main.bicep
- the main template that is deployed which makes use of the other templatesget-kv-secrets-refs.bicep
- a helper to build up the Key Vault secret referenceskey-vault.bicep
- defines the Key Vault resources and the role assignments neededstatic-sites.bicep
- defines the Static Web App resources needed
In the main.bicep
there are the following highlights to make note of
- Configuring the static web app
- to have app settings that are Key Vault references (
AAD_CLIENT_ID
,AAD_CLIENT_SECRET
) - to use the
Standard
sku
- to have app settings that are Key Vault references (
|
|
- And configuring the key vault to allow the static web app permissions to read from it
|
|
Deploy using GitHub
Deployment credentials
For a GitHub Action to be able to deploy to your resource group you need to have some form of deployment credentials. You can read about the options available here. I’ll be using the Service Principalapproach with Azure CLI.
|
|
You will get a JSON output from this that you can then save as a GitHub secret with the name AZURE_CREDENTIALS
.
Note
- Replace
{subscription-id}
with the ID of your subscription - Replace
{resource-group-name}
with the name of your resource group - I’ve made the service principal have Owner access to the resource group (so that I can assign roles).
Workflow token
Azure Static Web Apps needs access to your workflow when deploying. For this we’ll set up a WORKFLOW_TOKEN
secret using a GitHub personal access token with the workflow scope. Follow the instructions hereto create the token.
Github Action Workflow
With the above secrets in place, we can now create a workflow (mines in .github/workflows/deploy.yaml
) which
- specifies some environment variables for names, tags and locations
- checks out the repo
- logs into Azure using
${{ secrets.AZURE_CREDENTIALS }}
- deploys to the resource group using the
azure/CLI@v1
action - gets the API from the deployed static web app (so that we can deploy code to it)
- deploys the webapp using the
Azure/static-web-apps-deploy@v1
action
See the full workflow below.
|
|
Finalising auth
At this stage you should have a GitHub workflow successfully deploying a Static Web App and a Key Vault to you resource group. You should also be able to browse to your web app using the generated URL (navigate into the Static Web App from the portal, and you will see your URL on the overview tab. e.g. https://gray-wave-03fb32a03.1.azurestaticapps.net).
Note
Your app won’t ask you to authenticate just yet!
To enable auth our next steps will be to
- create an AAD app registration
- add it’s client ID and secret as secrets in your key vault
- configure the static web app to auto log you in if you aren’t already or your token has expired
AAD App Registration
An AAD app registration allows us to bind our application to a desired set of authentication flows and restrictions. Think of it as giving your application an identity inside AAD. Mark Foppen wrote a lovely articlethat may help demystify this a bit.
In this tutorial I’ll just be using Azure CLIto create one:
|
|
Note
Ensure you set the --reply-urls
to be the generated URL of your app with the /.auth/login/aad/callback
suffix. This allows AAD to call your app once the auth flow has completed.
Once created, we need to create an application secret for the application. For this tutorial you can do this via the portal following the instructions here.
Copy the value of the secret as well as the Application (client) ID
of the AAD app (found under the Overview section of the app).
Setup Key Vault Secrets
Once again, I’ve used the portal for this tutorial. You can follow the guide heresetting two secrets in your vault
aadClientId
- this should be set to the Application (client) ID of your app registrationaadClientSecret
- this should be set to the value of the application secret created above
Configuring the Static Web App
Configuration for Azure Static Web Apps is defined in the staticwebapp.config.json
file, which controls, among other things, authentication and authorisation.
I’ve put mine in the root of the webapp folderand set it to do the following to enable the auto-login SSO magic
enable custom
auth
with Azure Active Directory Version 2using the app settings references from earlier (AAD_CLIENT_ID
,AAD_CLIENT_SECRET
)1 2 3 4 5 6 7 8 91011
"auth": { "identityProviders": { "azureActiveDirectory": { "registration": { "openIdIssuer": "https://login.microsoftonline.com/4af290c8-08df-440d-93db-cbac02bd9b19/v2.0", "clientIdSettingName": "AAD_CLIENT_ID", "clientSecretSettingName": "AAD_CLIENT_SECRET" } } }},
a
navigationFallback
routetoindex.html
123
"navigationFallback": { "rewrite": "index.html"},
specific rules for the apps
routes
creates a
/login
route redirecting to AAD allowing anonymous access12345
{ "route": "/login", "rewrite": "/.auth/login/aad", "allowedRoles": ["anonymous", "authenticated"]},
blocks all providers except AAD
12345678
{ "route": "/.auth/login/github", "statusCode": 404},{ "route": "/.auth/login/twitter", "statusCode": 404},
(Video) Understanding single sign-on (SSO) with Azure AD and Microsoft Teamscreates a
/logout
route redirecting to AAD allowing anonymous access12345
{ "route": "/logout", "redirect": "/.auth/logout", "allowedRoles": ["anonymous", "authenticated"]},
enforces auth for all other routes (
/*
)1234
{ "route": "/*", "allowedRoles": ["authenticated"]}
sets up a response override that if an unauthenticated user hits a page, they should be redirected to the
/login
route123456
"responseOverrides": { "401": { "redirect": "/login", "statusCode": 302 }}
The combination of all of the above means that anyone accessing the site that isn’t logged in will be routed to the /login
route which will ensure that the AAD auth flow is completed!
Finishing up!
Commit all your outstanding changes, push to GitHub and watch your action deploy… once done, access your web app in the browser, and it should redirect you to login
Initially you will need to provide admin consent for your AD app registration to read the logged-in user details
If all has gone well you should see the default page after login completes
And that’s it! Hope you enjoyed this tutorial and that it helps you setup SSO for your Static Web Apps!
Info
A reminder that all code is available on GitHub over here
Featured image background by Hello I’m Nikon Unsplash
FAQs
What is the difference between Azure SSO and AD? ›
With password-based SSO, users sign in to the application with a username and password the first time they access it. After the first sign-on, Azure AD provides the username and password to the application.
Does Azure AD support single sign-on? ›With Azure AD, users can conveniently access all their apps with SSO from any location, on any device, from a centralized and branded portal for a simplified user experience and better productivity.
How does Active Directory work with SSO? ›In AD Mode, to get the user credentials, the SSO Agent makes a NetWkstaUserEnum call to the client computer over TCP port 445. The SSO Agent then uses the information it gets to authenticate the user for SSO. The SSO Agent uses only the first answer it gets from the computer.
How to implement single sign-on using Azure Active Directory? ›- Go to the Azure portal and sign in using one of the roles listed in the prerequisites.
- Browse to Azure Active Directory > Enterprise applications. ...
- In the Manage section of the left menu, select Single sign-on to open the Single sign-on pane for editing.
With SSO, a user logs in once, and gains access to all systems without being prompted to log in again at each of them. Active Directory (AD) is a directory service that provides a central location for network administration and security.
Is Active Directory a part of SSO? ›AD and SSO are very different; one is an on-prem directory service — the authoritative source of identities, the other a cloud-based, web app identity extension point solution that federates the identities from a core directory to web applications.
What is the benefit of single sign on Azure AD? ›Azure AD's SSO feature enables users to login to multiple applications via a single pane, which includes both SaaS and on-premises applications. The SSO feature makes it easier for administrators to add new users and services without needing to set up credentials or security groups for each application or service.
What Azure license is needed for SSO? ›Ensure the application is covered by the following licensing requirements: Azure AD licensing - SSO for pre-integrated enterprise applications is free. However, the number of objects in your directory and the features you wish to deploy may require more licenses.
What is the difference between SSO and federated SSO? ›The key difference between SSO and FIM is while SSO is designed to authenticate a single credential across various systems within one organization, federated identity management systems offer single access to a number of applications across various enterprises.
How do I know if SSO is working? ›Ensure that the Seamless SSO feature is still Enabled on your tenant. You can check the status by going to the Azure Active Directory > Azure AD Connect pane in the Azure portal. Click through to see all the AD forests that have been enabled for Seamless SSO.
How does SSO work for multiple domains? ›
About multi-domain support for SSO
To enable multi-domain support, all virtual servers must be on a single BIG-IP system and share the same access profile. All virtual servers must include all of the profiles that the access profile requires (for example, VDI, rewrite, server SSL, connectivity, and so on).
- In the SAC Admin Portal, create or edit a web application for which to configure SSO. ...
- Under Single Sign-On, select an authentication type: ...
- Save. ...
- (If using JWT Token) Enable user groups in JWT authentication:
Single sign-on systems require a one-time authentication from the user. Once logged in, the user can access other web applications and services without re-authenticating themselves. Meanwhile, same sign-on requires the user to repeat the login process each time with the same authentication credentials.
What is the difference between API and SSO? ›SSO vs API summary
SSO streamlines your user experience when accessing other applications. It's a set of Single Sign-On credentials associated with each user. API is all about data automation. It keeps your data in sync and automates pulling data out of a system to generate reports.
- Schema master.
- Domain naming master.
- RID master.
- PDC emulator.
- Infrastructure master.
Because the SSO Client installer for Windows is an MSI file, you can use an Active Directory Group Policy to automatically install it when users log on to your domain from a Windows computer.
What is the difference between SAML and OAuth in Azure Active Directory? ›SAML is an Extensible markup language. On the other hand OAuth is the authorization protocol. It gives users the access to specific resources with a service provider or SP. It is based on JavaScript object Notation.
What is the difference between Azure SSO and LDAP? ›What is the difference between SSO and LDAP? SSO is a convenient authentication method that allows users to access multiple applications and systems using just one login. LDAP is the protocol or communication process that will enable users to access a network resource through a directory service.
Does SSO require LDAP? ›Furthermore, SSO is a large-scale system for granting access to systems, and LDAP is a component of the SSO system. SSO allows businesses to have centralized control over who has access to their systems and what level of access each person has.
Does Azure SSO use LDAP? ›To communicate with your Azure Active Directory Domain Services (Azure AD DS) managed domain, the Lightweight Directory Access Protocol (LDAP) is used. By default, the LDAP traffic isn't encrypted, which is a security concern for many environments.
What are 3 benefits of single sign on? ›
- Reduces Help Desk costs. SSO saves users from having to memorize a long list of passwords. ...
- Improves customer satisfaction. ...
- Boosts productivity. ...
- Improves compliance and security capabilities. ...
- Facilitates B2B collaboration.
Security and compliance benefits of SSO
SSO reduces the number of attack surfaces because users only log in once each day and only use one set of credentials. Reducing login to one set of credentials improves enterprise security. When employees have to use separate passwords for each app, they usually don't.
Advantages | Disadvantages |
---|---|
Streamlines user access to their applications | Using a single password increases the chances of password vulnerability |
Reduces the load of memorising several passwords | When SSO fails, access to all related systems is lost |
By default, a maximum of 50,000 Azure AD resources can be created in a single tenant by users of the Azure Active Directory Free edition. If you have at least one verified domain, the default Azure AD service quota for your organization is extended to 300,000 Azure AD resources.
Does Azure SSO require MFA? ›Yes. Azure AD Multi-Factor Authentication is required at sign-in.
Does SSO require MFA? ›MFA and SSO are not mutually exclusive. As a matter of fact, you can combine these two technologies to provide your users with high security while ensuring a good user experience. MFA can add an extra layer of protection to the SSO logins of your users.
What is the difference between SSO and non SSO? ›While SSO enables users to log in with a single, secure password, non-SSO means that a user is required to log into each individual account that they are using each time they want to access it.
What is the difference between authentication and SSO? ›Authentication: process of an entity (the Principal) proving its identity to another entity (the System). Single Sign On (SSO): characteristic of an authentication mechanism that relates to the user's identity being used to provide access across multiple Service Providers.
Does SSO expire? ›Information and explanation about SSO password expiry. Your Single Sign-on password will expire in two circumstances: Automatically after a year.
Can I bypass SSO? ›If SSO-only Authentication is enabled, it can ONLY be bypassed by a user with full-admin access logging in directly to TDAdmin.
Is SSO authentication or authorization? ›
Single sign-on (SSO) is an authentication method that enables users to securely authenticate with multiple applications and websites by using just one set of credentials.
Can you have two SSO accounts? ›Yes, you can define multiple SSO configurations for accounts in your organization. You can define a default security policy that will be applicable to all admins/agents logging into any account that is part of the organization.
Can I use one SSL for multiple domains? ›The simple answer is a resounding Yes! You absolutely can use one SSL certificate for multiple domains — or one SSL certificate for multiple subdomains in addition to domains.
Can you have more than one SSO? ›You can mix the default login form with multiple SSO methods. If one SSO authentication method is configured, your users will be redirected to that method for authentication. Once you enable more than one authentication method, users will see a login page with different login options.
What type of SSO is Azure AD? ›Azure Active Directory Seamless single sign-on (Azure AD Seamless SSO) automatically signs users in when they are on their corporate devices connected to your corporate network. When enabled, users don't need to type in their passwords to sign in to Azure AD, and usually, even type in their usernames.
Where is SSO token stored? ›SSO stores a combination of (Guid, Token, Expiry) on the server, where Guid is a random guid and Expiry is something like 30 seconds.
What are SSO protocols? ›Single Sign-On (SSO) is a protocol used to authenticate and authorize users to multiple applications using a single set of credentials. SSO is very convenient for users because they don't need to memorize multiple passwords and don't need to perform multiple login operations.
Does SSO work across browsers? ›SSO is based on a session, and sessions are stored in cookies. Browsers don't share cookies, so you cannot do SSO between them.
How do I create my own SSO? ›- Go to Admin Console > Enterprise Settings, and then click the User Settings tab.
- In the Configure Single Sign-On (SSO) for All Users section, click Configure.
- Select your Identity Provider (IdP). ...
- Upload your IdP's SSO metadata file. ...
- Click Submit.
Federated Identity (FID) refers to where the user stores their credentials. Alternatively, FID can be viewed as a way to connect Identity Management systems together. In FID, a user's credentials are always stored with the "home" organization (the "identity provider").
How do I know if SSO is enabled in Azure? ›
- Sign in to the Azure portal with the Hybrid Identity Administrator account credentials for your tenant.
- In the left menu, select Azure Active Directory.
- Select Azure AD Connect.
- Verify that Seamless single sign-on is set to Enabled.
With Azure AD, users can conveniently access all their apps with SSO from any location, on any device, from a centralized and branded portal for a simplified user experience and better productivity.
Does SSO use an API? ›miniOrange allows you to authenticate your users via API authentication provider into multiple applications. This way, you can achieve Single Sign-On (SSO) into your applications where the users will need to authenticate themselves via your API Server only once and they can access all the configured applications.
What does Azure SSO do? ›Single sign-on with Azure AD
Enabling SSO with Azure Active Directory (Azure AD) means users can sign-in once to access their Microsoft apps and other cloud, SaaS, and on-premises apps with the same credential.
- OAuth/OpenID Connect—select the OIDC option based on OAuth 2.0 for applications that support this option. ...
- SAML—this is the best option for applications that don't support OIDC/OAuth. ...
- Password-based SSO—this option is suited to applications with HTML sign-in pages.
Integration: LDAP will usually be more recognizable to users across different applications. For example, using an SSO system will allow a user to access multiple platforms with web portals. LDAP, however, might be a key technology that syncs email contacts in an email client.
What are 3 benefits of SSO? ›Some of the key benefits of SSO authentication for IT administrators and other IT team members include user adherence to password rules, user password reset call reduction, and administrative ability to track and control application access.
What is the key benefit of SSO? ›Benefits of SSO
Single sign-on (SSO) in the enterprise refers to the ability for employees to log in just one time with one set of credentials to get access to all corporate apps, websites, and data for which they have permission. SSO solves key problems for the business by providing: Greater security and compliance.
Single Sign-On or SSO is an authentication process that allows consumers to log in to multiple independent applications with a single set of credentials. With SSO, users can access a suite of applications via one single login, irrespective of the platform, technology, or domain used.
What are the two basic user types in Azure Active Directory? ›Azure AD only accepts two values for the UserType attribute: Member and Guest.
What protocol does Azure SSO use? ›
Azure AD supports many standardized protocols for authentication and authorization, such as SAML 2.0, OpenID Connect, OAuth 2.0, and WS-Federation. Azure AD also supports password vaulting and automated sign-in capabilities for apps that only support forms-based authentication.