Hello,

   We are creating an external authentication module to be used by ISAM as authentication flow. The module will act as an EAI and will return the eai http headers. However the authentication page is a SPA and we are struggling after authentication to expose a basic html page with the eai headers in the response. Issue is populating the eai  http headers without exposing to the browser the parameters populating the eai values. I'm really just looking at ideas on how building a SPA page for ISAM using eai headers. I found a note from Philip Nye suggesting :

• SPAs can be configured to act as an ISAM EAI – External Authentication Interface, just like any other web application. The special trick is that EAI headers should be added to the final REST request in the authentication flow. That same REST API URL  should be configured as the trigger URL.

 I will be keen to have more details or simple example to do the above. 

Many thanks!

------------------------------
Gilles Mahout
Pirean
Fareham
------------------------------

Hi Gilles,

I don't think you can really have the SPA (client-side code) act as an "authentication application".  The client is effectively untrusted so you can't have it asserting identity into your security system.

I assume that the SPA will be calling REST services at some backend application to validate gathered authentication data.  This (trusted) backend service - sitting on an ISAM junction - will need to respond with the EAI headers to complete the authentication.

@Philip Nye can comment but I suspect that his note was really saying that the EAI headers should be added to the final REST *response* in the authentication flow. That same REST API URL  should be configured as the trigger URL.

Jon.

P.S. I think your signature is out of date.  I don't think you're in Fareham any more ;-)

​​​

------------------------------
Jon Harry
Consulting IT Security Specialist
IBM
------------------------------

@Jon Harry you're correct, this is indeed the correct interpretation...

I will attempt to update that blog to read correctly. But yes, it would NOT be a good idea to have the browser tell ISAM/ISVA who you are, so naturally this is not supported.
​

------------------------------
Philip Nye
IBM
Gold Coast
------------------------------

Original Message:
Sent: Mon February 22, 2021 11:45 AM
From: Jon Harry
Subject: EAI using SPA

Hi Gilles,

I don't think you can really have the SPA (client-side code) act as an "authentication application".  The client is effectively untrusted so you can't have it asserting identity into your security system.

I assume that the SPA will be calling REST services at some backend application to validate gathered authentication data.  This (trusted) backend service - sitting on an ISAM junction - will need to respond with the EAI headers to complete the authentication.

@Philip Nye can comment but I suspect that his note was really saying that the EAI headers should be added to the final REST *response* in the authentication flow. That same REST API URL  should be configured as the trigger URL.

Jon.

P.S. I think your signature is out of date.  I don't think you're in Fareham any more ;-)

​​​

------------------------------
Jon Harry
Consulting IT Security Specialist
IBM
------------------------------

Thank you both for your replies - I'm sorry my question was not clear enough or confusing. The SPA is protected by ISAM and we do eventually communicate the eai headers to isam via backend servers - those headers are not seen by the browser. We are just struggling to populate those headers in a safe way during the authentication flow. I will communicate your comment  regarding REST response to the developer.

------------------------------
Gilles Mahout
Pirean
Fareham
------------------------------

Original Message:
Sent: Tue February 23, 2021 08:44 PM
From: Philip Nye
Subject: EAI using SPA

@Jon Harry you're correct, this is indeed the correct interpretation...

I will attempt to update that blog to read correctly. But yes, it would NOT be a good idea to have the browser tell ISAM/ISVA who you are, so naturally this is not supported.
​

------------------------------
Philip Nye
IBM
Gold Coast
------------------------------


Original Message:
Sent: Mon February 22, 2021 11:45 AM
From: Jon Harry
Subject: EAI using SPA

Hi Gilles,

I don't think you can really have the SPA (client-side code) act as an "authentication application".  The client is effectively untrusted so you can't have it asserting identity into your security system.

I assume that the SPA will be calling REST services at some backend application to validate gathered authentication data.  This (trusted) backend service - sitting on an ISAM junction - will need to respond with the EAI headers to complete the authentication.

@Philip Nye can comment but I suspect that his note was really saying that the EAI headers should be added to the final REST *response* in the authentication flow. That same REST API URL  should be configured as the trigger URL.

Jon.

P.S. I think your signature is out of date.  I don't think you're in Fareham any more ;-)

​​​

------------------------------
Jon Harry
Consulting IT Security Specialist
IBM