Skip to content

RCBJ Blog

Integration, Middleware, Identity, and APIs

  • Contact Information
  • Privacy Policy
  • Quick Reference
    • Computer Measurements
  • RCBJ.NET – About Us
  • rcbj.net Conventions
  • Relevant Links

Identity Protocols, Hosted Login UIs, and Custom Login UIs

July 13, 2020 rcbj-admin Uncategorized

Image: Ankor Wat / Ramiro Ramirez

There are many ways to implement user authentication in a modern application (mobile, desktop, tablet, web, etc). I have previously explored Authentication, Federation, and SSO; that post introduces several key concepts that are assumed here. At the intersection of user experience, authentication, supportability, and general security is the question of how is the user authenticated? There are many ways of doing this; from an end-user perspective, there may not be a noticeable difference between the approaches. From an overall identity capability perspective, the approach matters. We aren’t just talking about the difference between using a username and password validated against LDAP versus using a client certificate, but also which architectural component is performing that step. Back in the day, just about every application had its own custom login workflow (series of screens to authenticate the user). As recently as a couple of years ago, I was working with IT organizations that still did things this way.

For several years now, I’ve been recommending clients use the hosted login workflows (UIs) that are available in their Identity Providers (or, at least, a customized workflow that is hosted on the identity provider) because this:

  • Facilitates abstracting user credentials away from the applications.
  • This centralizes the login experience across the organization.
  • Provides a choke point for enforcing certain authentication characteristics like Multi Factor Authentication (MFA) or mandatory password change.
  • Together with a common set of authentication libraries for the various platforms in play, can implement a reliable signout mechanism.
  • Provides a mechanism that can facilitate a global signout (logout) capability.
  • Allows for global changes to the login workflow with minimal hassle.
  • Facilitates SSO via a common IdP session cookie and spec-defined identity protocols.
  • The authentication service can appropriately implement.

The first one is especially important from a security standpoint. Some industry literature provides a more nuanced approach to this and says this is really only important if the IdP and application development teams belong to different organizations (or maybe different lines of business). Every identity solution I’ve designed/implemented over the past six years abstracted the user’s credentials away from the application by using a hosted login workflow — only the IdP saw the credentials. Designing your application authentication mechanism from the ground up to work in this manner is more secure than a situation where individual applications can see user credentials.

What are the downsides of doing this?

  • App developers no longer have direct control over this aspect of the user experience. I’ve encountered a couple of developers who really disliked this.
  • The ability to customize the login workflow hosted by the IdP may be limited. Identity As a Service (IDaaS) solutions especially tend to be limited to what can be done. Sometimes only the color scheme and a company logo can be customized, maybe you can’t run custom Javascript, maybe the ability the ability customize the login forms is limited.
  • The use of the standards-based identity protocols that are common today tend to involve multiple HTTP Redirects (maybe six or more). This can create delays in the app on slow network connections that wouldn’t otherwise be there.
  • For native mobile apps (or desktop apps), an external browser has to be launched in order to interact with the hosted UI. In some circles, this is viewed as an extreme negative.
  • In recent versions of iOS, launching that external browser from the app requires the user to consent each time. This further erodes the user experience.
  • To bring control back to the application native mobile app, typically requires registering a protocol or URL for the application with the device OS. This creates a new attack surface that must be addressed. See PKCE and here.

When Single Sign On first became important for the user experience, the most common way of implementing it was through server-integration with the User Store (LDAP, Active Directory, SQL database). Each individual organization was almost universally responsible for collecting user credentials. Then, those credentials would be validated against the needed User Store. The OpenID Connect, SAML2, WS-Federation, and other identity protocols imply that an IdP-hosted login workflow should be used, but none of these protocols specifically state how the login mechanism should work.

For example, the OIDC spec states:

3.1.2.3. Authorization Server Authenticates End-User
If the request is valid, the Authorization Server attempts to Authenticate the End-User or determines whether the End-User is Authenticated, depending upon the request parameter values used. The methods used by the Authorization Server to Authenticate the End-User (e.g. username and password, session cookies, etc.) are beyond the scope of this specification. An Authentication user interface MAY be displayed by the Authorization Server, depending upon the request parameter values used and the authentication methods used.

The OAuth2 (RFC6749) states:

3.1. Authorization Endpoint
The authorization endpoint is used to interact with the resource
owner and obtain an authorization grant. The authorization server
MUST first verify the identity of the resource owner. The way in
which the authorization server authenticates the resource owner
(e.g., username and password login, session cookies) is beyond the
scope of this specification.

The SAML 2.0 spec states:

The <AuthnRequest> and <Response> exchange supports a variety of usage scenarios and is therefore typically profiled for use in a specific context in which this optionality is constrained and specific kinds of input and output are required or prohibited. The following processing rules apply as invariant behavior across any profile of this protocol exchange. All other processing rules associated with the underlying request and response messages MUST also be observed.

The WS-Federation spec states (look at the last sentence):

In the Web approach, there is a common pattern used when communicating with an IP/STS. In the first step, the requestor accesses the resource; the requestor is then redirected to an IP/STS if no token or cookie is supplied on the request.  The requestor may MAY be redirected to a local IP/STS operated by the resource provider.  If it has not cached data indicating that the requestor has already been authenticated, a second redirection to the requestor's IP/STS will be performed.  This redirection process MAY require prompting the user to determine the requestor’s home realm. The IP/STS in the requestor’s home realm generates a security token for use by the federated party.  This token MAY be consumed directly by the resource, or it MAY be exchanged at the resource’s IP/STS for a token consumable by the resource.  In some cases the requestor’s IP/STS has the requisite information cached to be able to issue a token, in other cases it must prompt the user. Note that the resource’s IP/STS can be omitted if the resource is willing to consume the requestor’s token directly.

The figure below illustrates an example flow where there is no resource IP/STS. As depicted, all communication occurs with the standard HTTP GET and POST methods, using redirects (steps 2à3 and 5à6) to automate the communication. Note that when returning non-URL content a POST is REQUIRED (e.g. in step 6) if a result reference is not used. In step 2 the resource MAY act as its own IP/STS so communication with an additional service isn't required. Note that step 3 depicts the resource redirecting directly to the requestor’s IP/STS. As previously discussed, this could redirect to an IP/STS for the resource (or any number of chained IP/STS services). It might also redirect to a home realm discovery service.

It should be noted that in step 4, the authentication protocol employed MAY be implementation-dependent.

So, we have four different identity protocol specifications and four different statements to the effect of “how the user is authenticated is beyond the scope of this spec”. This is useful for each of these specs because it means that each can be employed in a wide variety of use cases and authentication scenarios (username + password, MFA, OTP, secureId, client certificates, digital signatures, FIDO2 WebAuthN, session cookies, etc.).

So, by extension, none of these specs explicitly requires the IdP to use a hosted login workflow. In fact, the OAuth2 spec defines an Authorization Grant that supports using an application-hosted login workflow, but only with a username and password; though, use of this grant is generally discouraged today. So, we are left with the list of pros and cons where this post started.

If you insist on having the login workflow (authentication service) built into your application, then you must address how to securely integrate that workflow into your identity provider. This will likely involve implementing some type of custom interface/module on the IdP. Regardless of the details, it involves custom coding that amounts to a custom security solution. I wish you luck. I would strongly encourage your organization to do a professional penetration test and security audit of this application/system before it goes live in production, especially if it is facing the public internet.

For the reasons listed the beginning of this post, I always recommend using an IdP-hosted login workflow. That being said, even if you do this, but fail to follow best practices throughout the rest of your Identity and Access Management (IAM) infrastructure, little has been accomplished — that for another post. But, please do NOT store clear text user passwords in LDAP, AD, or a database.

Image: Ankor Wat / Ramiro Ramirez

Authenticationhosted login uiidentity protocolslogin workflowSso

Post navigation

Previous Post:Differences Between Azure Active Directory and Red Hat SSO v7.1

Recent Posts

  • Identity Protocols, Hosted Login UIs, and Custom Login UIs
  • Differences Between Azure Active Directory and Red Hat SSO v7.1
  • OAuth2 Resource Owner Password Credential Grant with 3Scale and Red Hat SSO
  • OAuth2 Implicit Grant with 3Scale and Red Hat SSO
  • OAuth2 Configuration in 3Scale API Management (and APICast) with Red Hat SSO

Recent Comments

    Archives

    • July 2020
    • December 2017
    • November 2017
    • October 2017
    • September 2017
    • July 2017
    • June 2017
    • May 2017
    • April 2017
    • March 2017
    • February 2017
    • January 2017
    • December 2016
    • October 2016
    • August 2016
    • May 2016
    • April 2016
    • March 2016
    • February 2016
    • December 2012
    • November 2012
    • October 2012
    • September 2012
    • July 2012
    • June 2012
    • May 2012
    • April 2012
    • March 2012
    • February 2012
    • January 2012
    • December 2011
    • October 2011
    • June 2011
    • April 2011
    • September 2010
    • July 2010
    • October 2009
    • August 2009
    • June 2009
    • May 2009
    • April 2009
    • February 2009
    • January 2009
    • December 2008
    • November 2008
    • October 2008
    • September 2008
    • August 2008
    • March 2008
    • December 2007
    • October 2007
    • February 2007
    • January 2007
    • November 2006
    • September 2006
    • August 2006

    Categories

    • architecture
    • Browser
    • cryptography
    • datapower
    • development
    • diagnostics
    • ha
    • IBM JDK
    • internet
    • J2EE
    • java
    • JBoss
    • JBoss World
    • JEE
    • jvm
    • JVM Internals
    • ldap
    • networking
    • Performance
    • Recommended Reading
    • Security
    • Servlet
    • Servlet
    • soa
    • soa appliance
    • SOAP
    • Speaking
    • Sun JDK
    • Uncategorized
    • VPN
    • web
    • web service
    • Weblogic
    • websphere
    • xml
    • xpath
    • xslt

    Meta

    • Log in
    • Entries RSS
    • Comments RSS
    • WordPress.org

    About Us

    Contact Information

    This website uses cookies to improve your experience. We'll assume you're ok with this, but you can opt-out if you wish. Cookie settings ACCEPT
    Privacy & Cookies Policy

    Privacy Overview

    This website uses cookies to improve your experience while you navigate through the website. Out of these cookies, the cookies that are categorized as necessary are stored on your browser as they are essential for the working of basic functionalities of the website. We also use third-party cookies that help us analyze and understand how you use this website. These cookies will be stored in your browser only with your consent. You also have the option to opt-out of these cookies. But opting out of some of these cookies may have an effect on your browsing experience.
    Necessary
    Always Enabled

    Necessary cookies are absolutely essential for the website to function properly. This category only includes cookies that ensures basic functionalities and security features of the website. These cookies do not store any personal information.

    Non Necessary

    Any cookies that may not be particularly necessary for the website to function and is used specifically to collect user personal data via analytics, ads, other embedded contents are termed as non-necessary cookies. It is mandatory to procure user consent prior to running these cookies on your website.

    Advertisement

    Advertisement cookies are used to provide visitors with relevant ads and marketing campaigns. These cookies track visitors across websites and collect information to provide customized ads.

    Analytics

    Analytical cookies are used to understand how visitors interact with the website. These cookies help provide information on metrics the number of visitors, bounce rate, traffic source, etc.

    Performance

    Performance cookies are used to understand and analyze the key performance indexes of the website which helps in delivering a better user experience for the visitors.

    Save & Accept