Noise

Search
Skip to content
  • Home
  • About

Simplify Login with Application Load Balancer Built-in Authentication

2018-05-30 Randall Hunt

Post Syndicated from Randall Hunt original https://aws.amazon.com/blogs/aws/built-in-authentication-in-alb/

Today I’m excited to announce built-in authentication support in Application Load Balancers (ALB). ALB can now securely authenticate users as they access applications, letting developers eliminate the code they have to write to support authentication and offload the responsibility of authentication from the backend. The team built a great live example where you can try out the authentication functionality.

Identity-based security is a crucial component of modern applications and as customers continue to move mission critical applications into the cloud, developers are asked to write the same authentication code again and again. Enterprises want to use their on-premises identities with their cloud applications. Web developers want to use federated identities from social networks to allow their users to sign-in. ALB’s new authentication action provides authentication through social Identity Providers (IdP) like Google, Facebook, and Amazon through Amazon Cognito. It also natively integrates with any OpenID Connect protocol compliant IdP, providing secure authentication and a single sign-on experience across your applications.

Trending
Европейските произведения в каталозите на доставчиците на аудиовизуални медийни услуги по заявка

How Does ALB Authentication Work?

Authentication is a complicated topic and our readers may have differing levels of expertise with it. I want to cover a few key concepts to make sure we’re all on the same page. If you’re already an authentication expert and you just want to see how ALB authentication works feel free to skip to the next section!

  • Authentication verifies identity.
  • Authorization verifies permissions, the things an identity is allowed to do.
  • OpenID Connect (OIDC) is a simple identity, or authentication, layer built on top on top of the OAuth 2.0 protocol. The OIDC specification document is pretty well written and worth a casual read.
  • Identity Providers (IdPs) manage identity information and provide authentication services. ALB supports any OIDC compliant IdP and you can use a service like Amazon Cognito or Auth0 to aggregate different identities from various IdPs like Active Directory, LDAP, Google, Facebook, Amazon, or others deployed in AWS or on premises.

When we get away from the terminology for a bit, all of this boils down to figuring out who a user is and what they’re allowed to do. Doing this securely and efficiently is hard. Traditionally, enterprises have used a protocol called SAML with their IdPs, to provide a single sign-on (SSO) experience for their internal users. SAML is XML heavy and modern applications have started using OIDC with JSON mechanism to share claims. Developers can use SAML in ALB with Amazon Cognito’s SAML support. Web app or mobile developers typically use federated identities via social IdPs like Facebook, Amazon, or Google which, conveniently, are also supported by Amazon Cognito.

ALB Authentication works by defining an authentication action in a listener rule. The ALB’s authentication action will check if a session cookie exists on incoming requests, then check that it’s valid. If the session cookie is set and valid then the ALB will route the request to the target group with X-AMZN-OIDC-* headers set. The headers contain identity information in JSON Web Token (JWT) format, that a backend can use to identify a user. If the session cookie is not set or invalid then ALB will follow the OIDC protocol and issue an HTTP 302 redirect to the identity provider. The protocol is a lot to unpack and is covered more thoroughly in the documentation for those curious.

ALB Authentication Walkthrough

I have a simple Python flask app in an Amazon ECS cluster running in some AWS Fargate containers. The containers are in a target group routed to by an ALB. I want to make sure users of my application are logged in before accessing the authenticated portions of my application. First, I’ll navigate to the ALB in the console and edit the rules.

I want to make sure all access to /account* endpoints is authenticated so I’ll add new rule with a condition to match those endpoints.

Now, I’ll add a new rule and create an Authenticate action in that rule.

I’ll have ALB create a new Amazon Cognito user pool for me by providing some configuration details.


After creating the Amazon Cognito pool, I can make some additional configuration in the advanced settings.

I can change the default cookie name, adjust the timeout, adjust the scope, and choose the action for unauthenticated requests.

I can pick Deny to serve a 401 for all unauthenticated requests or I can pick Allow which will pass through to the application if unauthenticated. This is useful for Single Page Apps (SPAs). For now, I’ll choose Authenticate, which will prompt the IdP, in this case Amazon Cognito, to authenticate the user and reload the existing page.

 

Now I’ll add a forwarding action for my target group and save the rule.

Over on the Facebook side I just need to add my Amazon Cognito User Pool Domain to the whitelisted OAuth redirect URLs.

I would follow similar steps for other authentication providers.

Now, when I navigate to an authenticated page my Fargate containers receive the originating request with the X-Amzn-Oidc-* headers set by ALB. Using the information in those headers (claims-data, identity, access-token) my application can implement authorization.

All of this was possible without having to write a single line of code to deal with each of the IdPs. However, it’s still important for the implementing applications to verify the signature on the JWT header to ensure the request hasn’t been tampered with.

Additional Resources

Of course everything we’ve seen today is also available in the the API and AWS Command Line Interface (CLI). You can find additional information on the feature in the documentation. This feature is provided at no additional charge.

Be sure to check out the live example as well.

With authentication built-in to ALB, developers can focus on building their applications instead of rebuilding authentication for every application, all the while maintaining the scale, availability, and reliability of ALB. I think this feature is a pretty big deal and I can’t wait to see what customers build with it. Let us know what you think of this feature in the comments or on twitter!

– Randall

ACEActive DirectoryADADIAIALAAllalsamazonAmazon CognitoAmazon ECSappApplication Load BalancersapplicationsappsartATIauthauthenticationauthorizationAvailabilityAWSAWS FargateblebookCCASCaseciciaclicloudCloud applicationsclustercodecognitoconsolecontainerContainersCuritydatadeadetdeveloperDevelopersdocumentDocumentationdomaindowndpebookebuildecECSedeffElastic Load BalancingENSEnterpriseetFacebookfargatefirformFunGogoogleGREHATheaderhttpICEIDEIdentityIdPIPirsississueISTEjsonJWTLEDMakemanamobilemovmovenatureNECNetworkNetworking & Content Delivery*OauthOIDCon-premisesOpenID ConnectOSSOtherOUsPAPermissionsPPLpspythonRratratereliabilityrequestResourceresourcesROVRTIrunningS.SAMSAMLScalesecuritySecurity, Identity & ComplianceSESsign-inSingle sign-onsocialSSOStarstssupporttargetteateamtedThethingsTICtimeTodayTokentortwitterUIunUSUsefulwarwebWeb appWorkxml

Post navigation

Previous PostMonitoring your Amazon SNS message filtering activity with Amazon CloudWatchNext PostMore stable update cleanup

The collective thoughts of the interwebz

Contributors

  • /dev/ttyS0
  • Armed and Dangerous
  • arp242.net
  • AWS Architecture Blog
  • AWS Big Data Blog
  • AWS Compute Blog
  • AWS DevOps Blog
  • AWS Managed Services by Anchor
  • AWS Messaging & Targeting Blog
  • AWS News Blog
  • AWS Security Blog
  • Backblaze Blog | Cloud Storage & Cloud Backup
  • BeardedTinker
  • Bivol.bg
  • Bozho's tech blog
  • Bradley M. Kuhn's Blog ( bkuhn )
  • Crosstalk Solutions
  • Curious Droid
  • Darknet
  • Delian’s Tech blog
  • Devil’s Advocate Security
  • digiblurDIY
  • Engineering – The GitHub Blog
  • Errata Security
  • Explosm.net
  • fuzzy notepad
  • Geographics
  • Grab Tech
  • Grigor Gatchev – A Weblog
  • Home Assistant
  • IBM 360 Model 20 Rescue and Restoration
  • IEEE Spectrum Recent Content full text
  • Joel on Software
  • Kendov.com
  • LastWeekTonight
  • laur.ie's blog
  • lcamtuf’s blog
  • Let's Encrypt – Free SSL/TLS Certificates
  • LGR
  • LWN.net
  • Matt Granger
  • Matthew Garrett
  • Monty says
  • Netflix TechBlog – Medium
  • NTPsec Project Blog
  • Oglaf! — Comics. Often dirty.
  • Pid Eins
  • Prometheus Blog
  • Rapid7 Blog
  • Raspberry Pi Blog – Raspberry Pi
  • Schneier on Security
  • Show Notes
  • Sprites mods
  • Talks at Google
  • Techmoan
  • Technology Connextras
  • The Atlantic
  • The Cloudflare Blog
  • The Codeless Code
  • The History Guy: History Deserves to Be Remembered
  • The Hook Up
  • turnoff.us – geek comic site
  • xkcd.com
  • Yahoo Engineering
  • Yate – Software Defined Mobile Networks
  • Zabbix Blog
  • БЛОГодаря
  • Блогът на Делян Делчев
  • Блогът на Юруков
  • Дневникът на Георги
  • Дни
  • Йовко Ламбрев
  • Како Сийке, не съм от тях!
  • Кътчето на Селин
  • Медийно право
  • Неосъзнато
  • татко Крокодил
  • Тоест

Tags

AD AI All app art ATI AWS BEC ble C CAS ci code Curity data ec ed et Go HAT ICE IP irs iss Make mit NES OSS Other R rat rest ROV RTI S. security sts support ted tor UI un US win Work
Proudly powered by Ants

By continuing to use the site, you agree to the use of cookies. more information

The cookie settings on this website are set to "allow cookies" to give you the best browsing experience possible. If you continue to use this website without changing your cookie settings or you click "Accept" below then you are consenting to this.

Close