1602-Azure AD – “legacy” MS AD
Main questions to answer
Two basic questions to answer:
- How do custom applications integrate with Azure Active Directory (“AAD”)?
- How can AAD be used for AuthN / AuthZ outside the Azure cloud? Eg Office 365 / Win10 integration flows.
- AAD and AD become a single logical entity. On-premise AD driven from cloud-based AAD.
- Strategic AuthN protocols are:
- OpenID Connect (MS extension of OpenID)
- WS-Federation / SAML are *not* strategic. Neither is Windows Identity Foundation.
- Apps (public or corporate) must be registered to AAD. After that federation is easy.
- ADAL is MS multi-platform open-source SDK to do AuthN, also Xamarin, Apache Cordova
- Win10 will have new AuthN flows integrated at OS level: “WebAccountManager” API
- Major MS paradigm shift / change in fundamental architectural direction.
MS AAD developer’s Guide
Documentation describing how to integrate with AAD.
Azure Active Directory Graph API: Use the Azure Active Directory Graph API to programmatically access Azure Active Directory through REST API endpoints. Note that AAD Graph API is also accessible through Microsoft Graph, a unified API that enables access to multiple Microsoft cloud service APIs through a single REST API endpoint, and with a single access token.
SAML 2.0 protocol reference: The SAML 2.0 protocol enables applications to provide a single sign-on experience to their users.
OAuth 2.0 protocol reference: You can use the OAuth 2.0 protocol to authorize access to web applications and web APIs in your Azure Active Directory tenant.
OpenID Connect 1.0 protocol reference: The OpenID Connect 1.0 protocol extends OAuth 2.0 for use as an authentication protocol.
WS-Federation 1.2 protocol reference: The WS-Federation 1.2 protocol is specified in the Web Services Federation Version 1.2 Specification.
Supported token and claim types: You can use this guide to understand and evaluate the claims in the SAML 2.0 and JSON Web Tokens (JWT) tokens.
But according to later video presentations, strategic protocols are OAuth and OpenID Connect.
Video Presentation: Product orientation / direction IDaaS
Stuart Kwan Principal Pgm Mgr
Legacy “As Is” AD vs AAD IDaaS
AD == “Active Directory”
AAD == “Azure Active Directory”
Functional improvements, advantages of moving to cloud AAD:
- Federation → Customers / users off-premises get access. But need user context as well.
- Take IAM to the cloud for signup/signin/provisioning/directory services.
- Make federation easier: Programmatically establish relationship with customer /user. Then 1-click federation onboarding.
- Self-service pwd reset, self-service group mgmt. (premium version)
- done in the cloud.Then reflect changes back into “on-premises”.
- ➔Cloud AD + on-prem AD become one global AD.
- Less on-prem software, let MS manage the complexity of AD plumbing. MS vision.
Benefits of AAD integration
- SSO to Office 365
- MS App Gallery / App store presence
- One-click federated access.
Security Monitoring by MS, alerts (premium) generated when:
- Brute force detection, including slo-mo attacks
- Sign-in from anonymizer netwk eg TOR
- Unlikely travel e.g. NA, then APAC signins one after each other
- Multiple failed requests from 1 IP to multi-tenants
- Sign-in from known infected devices
Corporate cloud apps can be “single-tenant” i.e. for our company only.
MS is still architecting / building AAD. Eg
- 1-click currently permissions not very granular e.g. “read directory” permissions gives full AD RO access.
- Will be releasing more granular access permissioning so that an ordinary user can accept an app, not necessarily an AAD admin.
AD admin in organization that accepted the app can see:
- App access stats
- Configure AuthN for this app (e.g. require MFA if not on-premises)
- MFA sign-in is handled by AAD transparently to the application.
- More device-specific context eg. “no jailbroken phones”
MS has middleware libraries in major languages to do “heavy lifting” client-side e.g. verify token signing, refresh tokens.
AAD designed to handle AuthN in various places for “modern” apps architectures to preserve user’s identity across the full pipeline. Eg. Mobile app → docusign web app –> corporate Sharepoint →sign document → return document to Sharepoint
Strategic protocols / API support
Strategic protocols are:
- OAuth 2.0 and OpenID Connect (MS-enhanced version of OpenID).
- AAD also supports SAML, WS-Federation but not strategic
No LDAP support in AAD.
Rather MS Graph REST API with JSON or XML response. ODATA V3.0 and soon V4.0 compatible.
Both client-side and server-side libraries to do these authentication flows
Server side support a bit thin.
- Reduce exposure of keys to DevOPs.
- Access to keys monitored / audited.
- Bring your own keys. PAAS mentality
- App has identity + certificate. Private key thrown away.
- App requests token to key vault from AAD
- Application retrieves storage secrets from AD
IDaaS for Applications
- Add B2C for customer-facing applications.
Free level and consumption pricing
- Integration between AAD account and MS account
- 1-signon regardless of whether consumer identity or workplace identity used.
- New app registration portal outside of Azure to work with either MS account or AAD.
- Office 365 APIs will be unified across the consumer / business accounts. → unified calendar etc
- SSO of Desktop to AAD / MS consumer for Windows 10, Azure, Android. Based on ADAL API.
- SSO to native applications using Web account API, consumer applications, corporate applications.
- Device identity passed along → Health state of device through broker application. Extension of MFA today.
Video presentation: Developing Native applications
Basically mobile orientation iOS / Android, but also Win
- Can write app with ADAL at any level – individual stack or multi-stack
- Xamarin → dot Net
OAuth-A or OAuth-T only used in mobile applications.
Multi-refresh resource token (AAD-only extension)
- Same refresh token can ask for completely new set of resources also authorized for the user
- MS “embrace and extend”
Win 10 specifics
- WebAccountManager Integrated protocol mgmt into OS
- low level API at OS level.
- Sits on top of Identity Provider plugins
- Identity Provider Plugin integrated into API with integrated UX for gathering credentials, selection of user identity.
AAD one identity provider (if I understood correctly)
Universal App API runs across all devices
- Must be registered in AAD
- Has to declare resources that will use.
Could also use Win7-style app on Win10. In this case would use ADAL
Available on many platforms eg .Net, Java, IOS, Android, NodeJS. Python coming.
Open Source https://github.com/AzureAD includes community contributions
Consistent primitives, native programming models.
- Works across Windows Server and AAD
- Cache, auto refresh
- Multi-user support
- Token persistence, refresh handled automatically
- Abstracts away protocol considerations, e.g. different instances of AAD (→isolated instance in China)
ADAL.NET for Desktop
- Windows integrated AuthN
- Direct use of username / pwd
Persistent cache / sandbox:
- Token kept for 90 days in Windows Store apps.
- On Desktop, token kept in memory.
Run same C# code across various eg Mac, Android
Apache Cordova Plugin for ADAL
- Same app across multiple environments.
Video presentation: Developing Web applications with AAD
Web app architectures
- Web server – browser client
- Web API
- Web app / API calls backend Web API
Basic building blocks
To secure round-trip web apps:
- ASP.Net OWIN Security components (not bolted to IIS)
- OpenID Connect
- Legacy: Win Identity Foundation in .Net 4.5
- Will be supported but not strategic
Need to register the app.
- AAD will *not* give tokens to unknown apps. Needs ID, certificate to check token signing, etc
MS extension of OpenID (“OpenID Connect”) is complex:
Tokens are tied into specific web sites.
- OAuth code sent along OpenID pipeline after initial AuthN.
- Can be exchanged for OAuth tokens at backend Web API.
Protecting own API with AAD
- Eg. Facebook protects Facebook Graph API
- Token placed in header
Single Page Apps and AAD
- Possibly multiple-domain backends
- ADAL JS obtains a token (with own token cache) *each* time backend is called.
- No refresh token
- Iframe used to renew access token with showing UI to user.
(Fairly kludgy patch)