Hi Leo,
Really appreciate your quick response!
In our environment, unfortunately we can't create multiple junctions for same backend, in this case, multiple junctions to same AAC runtime. I have been checking production webseal request logs, no /aac/sps/auth show up in the searches, would you think that's sufficient to prove authentication endpoint is not being called actively by any application?
As to handling the error response, if I understand correctly, the error html templates are under C/proper/errors on the AAC appliance, would it be worth trying to update them to redirect to a login page, and again not too sure about the impact doing that...
Thanks,
Tian
------------------------------
Tian Xia
------------------------------
Original Message:
Sent: Mon November 02, 2020 07:27 PM
From: Leo Farrell
Subject: AAC unauthenticated access policy - how to customize the error response
Hi Tian,
The best approach here is to help solve both questions is to use a separate junction for any federation which wishes to use unauthenticated access policy. That way you know the impact of changing the ACL is limited only to services using that junction. For the error returned from /sps/auth, it will also occur if an authenticated user browsers to that endpoint too, so there's not too much mitigation we can offer on that, as users shouldn't end up there through regular browsing with correct configuration.
The OAuth and federation configuration utilities support configuring a federation or API protection definition on a separate junction which helps facilitate this mode of operation.
This question does highlight the need for an update to that article, to re-iterate the need to configure separate junctions for different federations depending on what sort of access policy they are using. I will make this change.
I hope this helps with your concerns
Thank you
------------------------------
Leo Farrell
Original Message:
Sent: Fri October 30, 2020 06:14 PM
From: Tian Xia
Subject: AAC unauthenticated access policy - how to customize the error response
Hi, ISVA community,
Two questions here regarding "Unauthenticated access policy" pattern mentioned in Leo Farrell's blog post: Federated Single Sign On: Access Policy for 2FA with SAML and OIDC
First question is, when using this pattern in existing environment (with a few existing SAML federations,and access control policies for step-up authentication flows, but no existing access policy), what's the caveat in terms of not to break anything existing, since by default /sps/auth is protected on webseal.
Second question is:
When using this pattern and setting /aac/sps/auth to be public on webseal, "/aac" being the junction to point to AAC runtime, what is the proper way to customize the response in AAC when a request is sent to /aac/sps/auth unauthenticated? My understanding is that when calling /aac/sps/auth without a session (neither webseal session id nor AAC jsessionid), AAC will respond with "An error has occurred" HTML response like below:
--------------------------------------------------------------------------------
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
<title>Internal Protocol Error</title>
<link rel="stylesheet" type="text/css" href="/aac/sps/static/styles.css" />
</head>
<body>
<div class="header">
<div class="brandingLogo"><img src="/aac/sps/static/ibm-logo.png" /></div>
</div>
<div class="content">
<div class="contentHeader">
<h1 class="pageTitle error">An error has occurred</h1>
<div class="instructions"></div>
</div>
<div class="pageContent">
<div id="infoDiv">
<em>/sps/auth</em> <br />
<em>2020-10-30T20:30:42Z</em> <br />
</div>
<br />
<div id="detailDiv">
<h4>Error details</h4>
An error occurred fulfulling the current request to /sps/auth. <br />
This error was caused by an internal/unexpected error on the invoked protocol module leading to
the exception displayed below. <br />
Please validate configuration of the executing protocol and environment. <br />
This is not a problem with the SPS. <br />
</div>
<br />
<div id="stackDiv" >
<h4>Stack trace</h4>
<em></em>
<pre>
</pre>
</div>
</div>
</div>
</body>
</html>
--------------------------------------------------------------------------------
This will go back to user browser, which is not a user friendly response. This unauthenticated authentication endpoint call won't reach access policy, is there anywhere we can catch this and present proper response to user, e.g., redirect user to login, in case the authentication endpoint is called without session id?
Mostly what I am trying to get at is, since this pattern involves opening up an URI on AAC, so potentially it can be called by anyone, I want to make sure the implementation is covered from security perspective.
Thanks in advance, any help is much appreciated.
Tian
------------------------------
Tian Xia
------------------------------