IBM Security Verify

Hi guys, First of all thanks for your attention. I'm facing a problem when I try to implent EAI follow the intructions of security academy learning, the issue is when the script test_sso.pl post o check_user.pl it's not redirect to resource just show on the browser the user and headers. Any ideas?

It's the result when form login post to check_user.pl:
am-eai-user-id: jesse287 am-eai-xattrs: eai-orig-user eai-orig-user: jesse287 Server: Apache-Coyote/1.1 Content-Type: text/html;charset=utf-8 Content-Length: 1048 Date:.Thu, 20.Sept 2017 04:39:57.GMT Connection:.close

Thanks

------------------------------
Jessé Baeta
------------------------------

Hi Jessé,

If the HTTP response with headers is returned to the browser, this means that either:
  a) EAI functionality is not enabled for the protocol you are using (HTTP/HTTPS)
  b) The trigger-url didn't match the request for the page that returned the EAI headers.

In the cookbook you're referring to, the relevant configuration is on page 16 and 17.

Make sure that you have eai-auth = https in the [eai] stanza and make sure you're accessing the Reverse Proxy over HTTPS.
Make sure that you don't have a typo in the trigger; it must exactly match the path of the POST request to check_user.pl 

If you're still struggling, maybe paste us the [eai] and [eai-trigger-urls] stanzas in your system.
It would be helpful to see the relevant lines from the request.log of the Reverse Proxy too (and or browser trace showing requests made).

Jon.

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

Original Message:
Sent: Thu July 29, 2021 10:42 AM
From: Jessé Baeta
Subject: EAI Authentication - Post problems

Hi guys, First of all thanks for your attention. I'm facing a problem when I try to implent EAI follow the intructions of security academy learning, the issue is when the script test_sso.pl post o check_user.pl it's not redirect to resource just show on the browser the user and headers. Any ideas?

It's the result when form login post to check_user.pl:
am-eai-user-id: jesse287 am-eai-xattrs: eai-orig-user eai-orig-user: jesse287 Server: Apache-Coyote/1.1 Content-Type: text/html;charset=utf-8 Content-Length: 1048 Date:.Thu, 20.Sept 2017 04:39:57.GMT Connection:.close

Thanks

------------------------------
Jessé Baeta
------------------------------

Hi, first of all thanks and my apologies to delay.
Follow the answers:

A) yes using https.
B) I thing its correctly, but I send part of config below

Note: Its not clear to second script(check_user.pl) because its doesn't post to pkmslogin.form ?

Part of config Reverse Proxy:

[eai]

#----------------------

# EXTERNAL AUTHENTICATION INTERFACE

#----------------------



# Enable EAI authentication.

#

# One of <http, https, both, none>

eai-auth = https



# EAI HEADER NAMES



# If eai-auth is not 'none', and WebSEAL has received a trigger URL

# in a request, WebSEAL will examine the corresponding server response for

# the following headers. These are the headers that will contain authentication

# data used to authenticate the user.



# EAI PAC header names

eai-pac-header = am-eai-pac

eai-pac-svc-header = am-eai-pac-svc



# EAI USER ID header names

eai-user-id-header = am-eai-user-id

eai-auth-level-header = am-eai-auth-level

eai-xattrs-header = am-eai-xattrs



# The following configuration entry is used to determine whether

# to allow eai extended attribute names to contain special characters.

# When set to yes, each of the attribute names in the eai-xattrs-header list containing special characters

# must be URL encoded. The commas delimiting the attribute names must not be URL encoded.

# When set to no then the whole list MAY be URL encoded (including the commas).

# The default value, if no entry is specifed, is 'no'.

#encoded-eai-xattrs = no





# EAI external USER ID header names

# The eai-ext-user-id-header takes precedence over the eai-user-id-header.

# If the authentication data that is presented to WebSEAL includes both headers,

# WebSEAL will process it as an authentication for an external user.

eai-ext-user-id-header = am-eai-ext-user-id

eai-ext-user-groups-header = am-eai-ext-user-groups



# EAI COMMON header names

eai-redir-url-header = am-eai-redir-url



# Determines whether the redirect URL contained within the EAI response takes

# priority over all other EAI redirect options. If set to true the redirect

# URL contained in the EAI response will take priority.

eai-redir-url-priority = yes



# The name of the header which is used to 'flag' the authentication

# response with extra processing information. The supported flags

# (.i.e. header values) include:

# - stream: Used to indicate that the authentication response should

# be streamed back to the client.

# - append-cred-attrs:

# When an extended attribute name matches an existing

# credential attribute, its value will be appended as an

# additional value.

# - replace-cred-attrs:

# When an extended attribute name matches an existing

# credential attribute, its value will replace the

# credential attribute value.

#

# If neither append-cred-attrs nor replace-cred-attrs is

# specified then the eai-replace-cred-attributes

# value determines the extended attribute behaviour.

eai-flags-header = am-eai-flags



# The session identifier from a distributed session can also be supplied

# through the EAI interface. Upon receiving a header which contains the

# distributed session identifier, WebSEAL will retrieve the corresponding

# session and use this session for subsequent requests. This header

# provides the mechanism by which distributed sessions (aka DSC sessions)

# can be shared across multiple DNS domains.

eai-session-id-header = am-eai-session-id



# RETAIN EAI SESSION

# If an already-authenticated EAI client authenticates via an EAI a second

# time, the existing session and cache entry are completely replaced by

# default. If retain-eai-session = yes, then the existing session and

# cache entry will be retained, and the credential and relevant data will

# be updated in the existing cache entry.

retain-eai-session = yes



#

# The following entry determines, in the event of a subsequent EAI

# authentication, whether the new user identity must match the user

# identity from the previous authentication. In the situation where

# eai-verify-user-identity = yes, and the user identities do not

# match, an error will be presented to the user.

#

eai-verify-user-identity = no



# The following configuration entry is used to determine whether multiple

# extended attribute headers of the same name are added to the credential as

# a multi-valued attribute, or a single comma-delimited attribute.

eai-create-multi-valued-attributes = no



# The following configuration entry is used to determine whether

# extended attributes replace credential attributes of the same name

# or are appended as additional values.

eai-replace-cred-attributes = no



# EAI TRIGGER URLS

[eai-trigger-urls]

# If eai-auth is not 'none', then WebSEAL will examine the URLs of incoming

# requests to determine if they match one of the entries in this list.

# If they do, then WebSEAL will examine the corresponding server response to

# determine if it contains authentication data.

#

# NOTE: If eai-auth is not 'none', there must be at least one entry in this list

#

# The URL string patterns are case-sensitive wild card patterns.

#

# Format for regular WebSEAL junctions is:

# trigger = <URL pattern of EAI server response>

#

# Format for Virtual Host junctions is:

# trigger = HTTP[S]://virtual-host-name[:port]/<URL pattern of EAI server response>

#

# For Virtual Host junctions to match a trigger they must also have the same

# protocol (HTTP[S] = TCP/SSL) and have the same virtual-host-name & port as

# the trigger. The virtual-host-name match is case-insensitive.

#

# Regular WebSEAL junction triggers are not used by Virtual Host junctions.

# Virtual Host junction triggers are not used by regular WebSEAL junctions.



trigger = /mga/sps/auth*

trigger = /mga/sps/authservice/authentication*

trigger = /mga/sps/authsvc*

trigger = /mga/sps/apiauthsvc*

trigger = /eai/cgi-bin/check_user.pl







#local-response-redirect-uri = /jct/redirect/handler

#Add by Jesse S. Baeta - Middleware Team

local-response-redirect-uri = /eai/cgi-bin/test_sso.pl



[local-response-macros]

# URL-encoded macros to include in the query string for all management

# page requests.

#

# These will increase the length of the local response redirect URI. Certain

# user-agents, such as WAP browsers, may have URI length limitations, so

# add macros sparingly and cautiously. Note that any special characters will

# be URI-encoded, further increasing the length of the local response URI.

#

# Do not modify the macro strings or add new ones; all supported macros are

# listed below. Comment/uncomment desired macros for inclusion in the local

# response URI. See the WebSEAL Admin Guide for definitions of the content

# corresponding to each macro.

#

# The field names used in the query string can be customized by placing a

# colon and a custom name after the macro definition as demonstrated below.

# macro = USERNAME:customerId

#

# If no name or a blank name is provided after the colon, the default value

# will be used. The default value is the macro name. For the HTTPHDR macro,

# the default value is HTTPHDR_<name>, where name is the name of the HTTP

# header defined in that macro. For the CREDATTR macro, the default value

# is CREDATTR_<name>, where name is the name of the attributed defined in

# that macro.

#

# Note that at a minimum the TAM_OP macro must be included in any response.

# Even if the TAM_OP macro is not included or customized below, it will

# still be present in all response URIs.



macro = TAM_OP

macro = USERNAME

macro = METHOD

macro = AUTHNLEVEL

macro = ERROR_CODE

macro = ERROR_TEXT

#macro = URL

#macro = REFERER

#macro = HOSTNAME

#macro = FAILREASON

#macro = PROTOCOL

#macro = ERROR_URL

#macro = OLDSESSION

#macro = EXPIRE_SECS

#macro = HTTPHDR{<name>}

#macro = CREDATTR{<name>}

#macro = SECONDARY_BASE



[enable-redirects]

# This stanza contains a list of authentication mechanisms

# for which automatic redirects are enabled.

# Valid choices are forms-auth, token-auth, basic-auth, cert-auth,

# oidc and ext-auth-interface

# Any or all of them may be enabled.



#Uncommented by Jesse S. Baeta - Middleware Team --> forms-auth and ext-auth-interface

redirect = forms-auth

redirect = ext-auth-interface


------------------------------
Jessé Baeta
------------------------------

Original Message:
Sent: Fri July 30, 2021 06:08 AM
From: Jon Harry
Subject: EAI Authentication - Post problems

Hi Jessé,

If the HTTP response with headers is returned to the browser, this means that either:
  a) EAI functionality is not enabled for the protocol you are using (HTTP/HTTPS)
  b) The trigger-url didn't match the request for the page that returned the EAI headers.

In the cookbook you're referring to, the relevant configuration is on page 16 and 17.

Make sure that you have eai-auth = https in the [eai] stanza and make sure you're accessing the Reverse Proxy over HTTPS.
Make sure that you don't have a typo in the trigger; it must exactly match the path of the POST request to check_user.pl 

If you're still struggling, maybe paste us the [eai] and [eai-trigger-urls] stanzas in your system.
It would be helpful to see the relevant lines from the request.log of the Reverse Proxy too (and or browser trace showing requests made).

Jon.

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

Original Message:
Sent: Thu July 29, 2021 10:42 AM
From: Jessé Baeta
Subject: EAI Authentication - Post problems

Hi guys, First of all thanks for your attention. I'm facing a problem when I try to implent EAI follow the intructions of security academy learning, the issue is when the script test_sso.pl post o check_user.pl it's not redirect to resource just show on the browser the user and headers. Any ideas?

It's the result when form login post to check_user.pl:
am-eai-user-id: jesse287 am-eai-xattrs: eai-orig-user eai-orig-user: jesse287 Server: Apache-Coyote/1.1 Content-Type: text/html;charset=utf-8 Content-Length: 1048 Date:.Thu, 20.Sept 2017 04:39:57.GMT Connection:.close

Thanks

------------------------------
Jessé Baeta
------------------------------

Hi Jessé,

Your configuration looks OK to me so I don't understand why the EAI is not working.

To answer your question about pkmslogin.form...
pkmslogin.form is only used specifically for form-based login.  It's not used for EAI.
With EAI, login is completed by the login application (your CGI scripts) returning an HTTP response with a set of HTTP headers that assert identity information to the Reverse Proxy.

Given that your EAI configuration looks correct, I can only guess now that the CGI scripts are not returning a correctly formatted HTTP response.  Maybe there's a blank line at the start so what should be headers is being interpreted as page content?

In your first append you said:
"It's the result when form login post to check_user.pl:
am-eai-user-id: jesse287 am-eai-xattrs: eai-orig-user eai-orig-user: jesse287 Server: Apache-Coyote/1.1 Content-Type: text/html;charset=utf-8 Content-Length: 1048 Date:.Thu, 20.Sept 2017 04:39:57.GMT Connection:.close"

Where did you capture that? 

Jon.

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

Original Message:
Sent: Tue August 03, 2021 07:08 AM
From: Jessé Baeta
Subject: EAI Authentication - Post problems

Hi, first of all thanks and my apologies to delay.
Follow the answers:

A) yes using https.
B) I thing its correctly, but I send part of config below

Note: Its not clear to second script(check_user.pl) because its doesn't post to pkmslogin.form ?

Part of config Reverse Proxy:

[eai]

#----------------------

# EXTERNAL AUTHENTICATION INTERFACE

#----------------------



# Enable EAI authentication.

#

# One of <http, https, both, none>

eai-auth = https



# EAI HEADER NAMES



# If eai-auth is not 'none', and WebSEAL has received a trigger URL

# in a request, WebSEAL will examine the corresponding server response for

# the following headers. These are the headers that will contain authentication

# data used to authenticate the user.



# EAI PAC header names

eai-pac-header = am-eai-pac

eai-pac-svc-header = am-eai-pac-svc



# EAI USER ID header names

eai-user-id-header = am-eai-user-id

eai-auth-level-header = am-eai-auth-level

eai-xattrs-header = am-eai-xattrs



# The following configuration entry is used to determine whether

# to allow eai extended attribute names to contain special characters.

# When set to yes, each of the attribute names in the eai-xattrs-header list containing special characters

# must be URL encoded. The commas delimiting the attribute names must not be URL encoded.

# When set to no then the whole list MAY be URL encoded (including the commas).

# The default value, if no entry is specifed, is 'no'.

#encoded-eai-xattrs = no





# EAI external USER ID header names

# The eai-ext-user-id-header takes precedence over the eai-user-id-header.

# If the authentication data that is presented to WebSEAL includes both headers,

# WebSEAL will process it as an authentication for an external user.

eai-ext-user-id-header = am-eai-ext-user-id

eai-ext-user-groups-header = am-eai-ext-user-groups



# EAI COMMON header names

eai-redir-url-header = am-eai-redir-url



# Determines whether the redirect URL contained within the EAI response takes

# priority over all other EAI redirect options. If set to true the redirect

# URL contained in the EAI response will take priority.

eai-redir-url-priority = yes



# The name of the header which is used to 'flag' the authentication

# response with extra processing information. The supported flags

# (.i.e. header values) include:

# - stream: Used to indicate that the authentication response should

# be streamed back to the client.

# - append-cred-attrs:

# When an extended attribute name matches an existing

# credential attribute, its value will be appended as an

# additional value.

# - replace-cred-attrs:

# When an extended attribute name matches an existing

# credential attribute, its value will replace the

# credential attribute value.

#

# If neither append-cred-attrs nor replace-cred-attrs is

# specified then the eai-replace-cred-attributes

# value determines the extended attribute behaviour.

eai-flags-header = am-eai-flags



# The session identifier from a distributed session can also be supplied

# through the EAI interface. Upon receiving a header which contains the

# distributed session identifier, WebSEAL will retrieve the corresponding

# session and use this session for subsequent requests. This header

# provides the mechanism by which distributed sessions (aka DSC sessions)

# can be shared across multiple DNS domains.

eai-session-id-header = am-eai-session-id



# RETAIN EAI SESSION

# If an already-authenticated EAI client authenticates via an EAI a second

# time, the existing session and cache entry are completely replaced by

# default. If retain-eai-session = yes, then the existing session and

# cache entry will be retained, and the credential and relevant data will

# be updated in the existing cache entry.

retain-eai-session = yes



#

# The following entry determines, in the event of a subsequent EAI

# authentication, whether the new user identity must match the user

# identity from the previous authentication. In the situation where

# eai-verify-user-identity = yes, and the user identities do not

# match, an error will be presented to the user.

#

eai-verify-user-identity = no



# The following configuration entry is used to determine whether multiple

# extended attribute headers of the same name are added to the credential as

# a multi-valued attribute, or a single comma-delimited attribute.

eai-create-multi-valued-attributes = no



# The following configuration entry is used to determine whether

# extended attributes replace credential attributes of the same name

# or are appended as additional values.

eai-replace-cred-attributes = no



# EAI TRIGGER URLS

[eai-trigger-urls]

# If eai-auth is not 'none', then WebSEAL will examine the URLs of incoming

# requests to determine if they match one of the entries in this list.

# If they do, then WebSEAL will examine the corresponding server response to

# determine if it contains authentication data.

#

# NOTE: If eai-auth is not 'none', there must be at least one entry in this list

#

# The URL string patterns are case-sensitive wild card patterns.

#

# Format for regular WebSEAL junctions is:

# trigger = <URL pattern of EAI server response>

#

# Format for Virtual Host junctions is:

# trigger = HTTP[S]://virtual-host-name[:port]/<URL pattern of EAI server response>

#

# For Virtual Host junctions to match a trigger they must also have the same

# protocol (HTTP[S] = TCP/SSL) and have the same virtual-host-name & port as

# the trigger. The virtual-host-name match is case-insensitive.

#

# Regular WebSEAL junction triggers are not used by Virtual Host junctions.

# Virtual Host junction triggers are not used by regular WebSEAL junctions.



trigger = /mga/sps/auth*

trigger = /mga/sps/authservice/authentication*

trigger = /mga/sps/authsvc*

trigger = /mga/sps/apiauthsvc*

trigger = /eai/cgi-bin/check_user.pl







#local-response-redirect-uri = /jct/redirect/handler

#Add by Jesse S. Baeta - Middleware Team

local-response-redirect-uri = /eai/cgi-bin/test_sso.pl



[local-response-macros]

# URL-encoded macros to include in the query string for all management

# page requests.

#

# These will increase the length of the local response redirect URI. Certain

# user-agents, such as WAP browsers, may have URI length limitations, so

# add macros sparingly and cautiously. Note that any special characters will

# be URI-encoded, further increasing the length of the local response URI.

#

# Do not modify the macro strings or add new ones; all supported macros are

# listed below. Comment/uncomment desired macros for inclusion in the local

# response URI. See the WebSEAL Admin Guide for definitions of the content

# corresponding to each macro.

#

# The field names used in the query string can be customized by placing a

# colon and a custom name after the macro definition as demonstrated below.

# macro = USERNAME:customerId

#

# If no name or a blank name is provided after the colon, the default value

# will be used. The default value is the macro name. For the HTTPHDR macro,

# the default value is HTTPHDR_<name>, where name is the name of the HTTP

# header defined in that macro. For the CREDATTR macro, the default value

# is CREDATTR_<name>, where name is the name of the attributed defined in

# that macro.

#

# Note that at a minimum the TAM_OP macro must be included in any response.

# Even if the TAM_OP macro is not included or customized below, it will

# still be present in all response URIs.



macro = TAM_OP

macro = USERNAME

macro = METHOD

macro = AUTHNLEVEL

macro = ERROR_CODE

macro = ERROR_TEXT

#macro = URL

#macro = REFERER

#macro = HOSTNAME

#macro = FAILREASON

#macro = PROTOCOL

#macro = ERROR_URL

#macro = OLDSESSION

#macro = EXPIRE_SECS

#macro = HTTPHDR{<name>}

#macro = CREDATTR{<name>}

#macro = SECONDARY_BASE



[enable-redirects]

# This stanza contains a list of authentication mechanisms

# for which automatic redirects are enabled.

# Valid choices are forms-auth, token-auth, basic-auth, cert-auth,

# oidc and ext-auth-interface

# Any or all of them may be enabled.



#Uncommented by Jesse S. Baeta - Middleware Team --> forms-auth and ext-auth-interface

redirect = forms-auth

redirect = ext-auth-interface


------------------------------
Jessé Baeta

Original Message:
Sent: Fri July 30, 2021 06:08 AM
From: Jon Harry
Subject: EAI Authentication - Post problems

Hi Jessé,

If the HTTP response with headers is returned to the browser, this means that either:
  a) EAI functionality is not enabled for the protocol you are using (HTTP/HTTPS)
  b) The trigger-url didn't match the request for the page that returned the EAI headers.

In the cookbook you're referring to, the relevant configuration is on page 16 and 17.

Make sure that you have eai-auth = https in the [eai] stanza and make sure you're accessing the Reverse Proxy over HTTPS.
Make sure that you don't have a typo in the trigger; it must exactly match the path of the POST request to check_user.pl 

If you're still struggling, maybe paste us the [eai] and [eai-trigger-urls] stanzas in your system.
It would be helpful to see the relevant lines from the request.log of the Reverse Proxy too (and or browser trace showing requests made).

Jon.

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

Original Message:
Sent: Thu July 29, 2021 10:42 AM
From: Jessé Baeta
Subject: EAI Authentication - Post problems

Hi guys, First of all thanks for your attention. I'm facing a problem when I try to implent EAI follow the intructions of security academy learning, the issue is when the script test_sso.pl post o check_user.pl it's not redirect to resource just show on the browser the user and headers. Any ideas?

It's the result when form login post to check_user.pl:
am-eai-user-id: jesse287 am-eai-xattrs: eai-orig-user eai-orig-user: jesse287 Server: Apache-Coyote/1.1 Content-Type: text/html;charset=utf-8 Content-Length: 1048 Date:.Thu, 20.Sept 2017 04:39:57.GMT Connection:.close

Thanks

------------------------------
Jessé Baeta
------------------------------

Hi, John thanks again for your attention, I see this result on the browser.

Follow content script check_user.pl

#!/usr/bin/perl -w



### to debug

$|=1;

print "Content-type: text/html\n\n";

use CGI::Carp('fatalsToBrowser');

###



use CGI;

$last_login_failed = 0;

$error_txt = "";

# open file

open OF, ">>/tmp/test_ck.out";



$qstring = $ENV{QUERY_STRING};

print OF "\n QUERY_STRING: $qstring";

print OF "\n";





# dump args

@arg_list = split('&',$qstring);

print OF "ARGS: $#arg_list \n";

for ($i=0; $i<=$#arg_list; $i++) {

print OF "\n $i: $arg_list[$i]";

($tmp1,$tmp2) = split('=',$arg_list[$i]);

if ($tmp1 eq 'ERROR_CODE' && $tmp2 ne "0x00000000") {

$last_login_failed = 1;

}

if ($last_login_failed && $tmp1 eq 'ERROR_TEXT') {

$error_txt = $tmp2;

}

}



print OF "START STDIN: \n";

my @key;

while (<STDIN>) {

@key = split(/&/, $_);

print OF " Key/Value pair for Username is $key[0] \n";

print OF " probably blank line ==>> $_ \n";

}



print OF "END STDIN: \n";

my @username = split(/=/, $key[0]);

print OF " (ext) User name after second split, hopefully not blank, $username[1] \n";

close OF;



# generate login header



# Pass identity in this header for users external to Access Manager

#print "am-eai-ext-user-id: $username[1]\n";



# Pass this header if user is present in Access Manager registry

print "am-eai-user-id: $username[1]\n";



print "am-eai-xattrs: eai-orig-user\n";

print "eai-orig-user: $username[1]\n";



print "Server: Apache-Coyote/1.1\n";

print "Content-Type: text/html;charset=utf-8\n";

print "Content-Length: 1048\n";

print "Date:.Thu, 20.Sept 2017 04:39:57.GMT\n";

print "Connection:.close\n";

print "\n";


------------------------------
Jessé Baeta
------------------------------

Original Message:
Sent: Tue August 03, 2021 11:14 AM
From: Jon Harry
Subject: EAI Authentication - Post problems

Hi Jessé,

Your configuration looks OK to me so I don't understand why the EAI is not working.

To answer your question about pkmslogin.form...
pkmslogin.form is only used specifically for form-based login.  It's not used for EAI.
With EAI, login is completed by the login application (your CGI scripts) returning an HTTP response with a set of HTTP headers that assert identity information to the Reverse Proxy.

Given that your EAI configuration looks correct, I can only guess now that the CGI scripts are not returning a correctly formatted HTTP response.  Maybe there's a blank line at the start so what should be headers is being interpreted as page content?

In your first append you said:
"It's the result when form login post to check_user.pl:
am-eai-user-id: jesse287 am-eai-xattrs: eai-orig-user eai-orig-user: jesse287 Server: Apache-Coyote/1.1 Content-Type: text/html;charset=utf-8 Content-Length: 1048 Date:.Thu, 20.Sept 2017 04:39:57.GMT Connection:.close"

Where did you capture that? 

Jon.

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

Original Message:
Sent: Tue August 03, 2021 07:08 AM
From: Jessé Baeta
Subject: EAI Authentication - Post problems

Hi, first of all thanks and my apologies to delay.
Follow the answers:

A) yes using https.
B) I thing its correctly, but I send part of config below

Note: Its not clear to second script(check_user.pl) because its doesn't post to pkmslogin.form ?

Part of config Reverse Proxy:

[eai]

#----------------------

# EXTERNAL AUTHENTICATION INTERFACE

#----------------------



# Enable EAI authentication.

#

# One of <http, https, both, none>

eai-auth = https



# EAI HEADER NAMES



# If eai-auth is not 'none', and WebSEAL has received a trigger URL

# in a request, WebSEAL will examine the corresponding server response for

# the following headers. These are the headers that will contain authentication

# data used to authenticate the user.



# EAI PAC header names

eai-pac-header = am-eai-pac

eai-pac-svc-header = am-eai-pac-svc



# EAI USER ID header names

eai-user-id-header = am-eai-user-id

eai-auth-level-header = am-eai-auth-level

eai-xattrs-header = am-eai-xattrs



# The following configuration entry is used to determine whether

# to allow eai extended attribute names to contain special characters.

# When set to yes, each of the attribute names in the eai-xattrs-header list containing special characters

# must be URL encoded. The commas delimiting the attribute names must not be URL encoded.

# When set to no then the whole list MAY be URL encoded (including the commas).

# The default value, if no entry is specifed, is 'no'.

#encoded-eai-xattrs = no





# EAI external USER ID header names

# The eai-ext-user-id-header takes precedence over the eai-user-id-header.

# If the authentication data that is presented to WebSEAL includes both headers,

# WebSEAL will process it as an authentication for an external user.

eai-ext-user-id-header = am-eai-ext-user-id

eai-ext-user-groups-header = am-eai-ext-user-groups



# EAI COMMON header names

eai-redir-url-header = am-eai-redir-url



# Determines whether the redirect URL contained within the EAI response takes

# priority over all other EAI redirect options. If set to true the redirect

# URL contained in the EAI response will take priority.

eai-redir-url-priority = yes



# The name of the header which is used to 'flag' the authentication

# response with extra processing information. The supported flags

# (.i.e. header values) include:

# - stream: Used to indicate that the authentication response should

# be streamed back to the client.

# - append-cred-attrs:

# When an extended attribute name matches an existing

# credential attribute, its value will be appended as an

# additional value.

# - replace-cred-attrs:

# When an extended attribute name matches an existing

# credential attribute, its value will replace the

# credential attribute value.

#

# If neither append-cred-attrs nor replace-cred-attrs is

# specified then the eai-replace-cred-attributes

# value determines the extended attribute behaviour.

eai-flags-header = am-eai-flags



# The session identifier from a distributed session can also be supplied

# through the EAI interface. Upon receiving a header which contains the

# distributed session identifier, WebSEAL will retrieve the corresponding

# session and use this session for subsequent requests. This header

# provides the mechanism by which distributed sessions (aka DSC sessions)

# can be shared across multiple DNS domains.

eai-session-id-header = am-eai-session-id



# RETAIN EAI SESSION

# If an already-authenticated EAI client authenticates via an EAI a second

# time, the existing session and cache entry are completely replaced by

# default. If retain-eai-session = yes, then the existing session and

# cache entry will be retained, and the credential and relevant data will

# be updated in the existing cache entry.

retain-eai-session = yes



#

# The following entry determines, in the event of a subsequent EAI

# authentication, whether the new user identity must match the user

# identity from the previous authentication. In the situation where

# eai-verify-user-identity = yes, and the user identities do not

# match, an error will be presented to the user.

#

eai-verify-user-identity = no



# The following configuration entry is used to determine whether multiple

# extended attribute headers of the same name are added to the credential as

# a multi-valued attribute, or a single comma-delimited attribute.

eai-create-multi-valued-attributes = no



# The following configuration entry is used to determine whether

# extended attributes replace credential attributes of the same name

# or are appended as additional values.

eai-replace-cred-attributes = no



# EAI TRIGGER URLS

[eai-trigger-urls]

# If eai-auth is not 'none', then WebSEAL will examine the URLs of incoming

# requests to determine if they match one of the entries in this list.

# If they do, then WebSEAL will examine the corresponding server response to

# determine if it contains authentication data.

#

# NOTE: If eai-auth is not 'none', there must be at least one entry in this list

#

# The URL string patterns are case-sensitive wild card patterns.

#

# Format for regular WebSEAL junctions is:

# trigger = <URL pattern of EAI server response>

#

# Format for Virtual Host junctions is:

# trigger = HTTP[S]://virtual-host-name[:port]/<URL pattern of EAI server response>

#

# For Virtual Host junctions to match a trigger they must also have the same

# protocol (HTTP[S] = TCP/SSL) and have the same virtual-host-name & port as

# the trigger. The virtual-host-name match is case-insensitive.

#

# Regular WebSEAL junction triggers are not used by Virtual Host junctions.

# Virtual Host junction triggers are not used by regular WebSEAL junctions.



trigger = /mga/sps/auth*

trigger = /mga/sps/authservice/authentication*

trigger = /mga/sps/authsvc*

trigger = /mga/sps/apiauthsvc*

trigger = /eai/cgi-bin/check_user.pl







#local-response-redirect-uri = /jct/redirect/handler

#Add by Jesse S. Baeta - Middleware Team

local-response-redirect-uri = /eai/cgi-bin/test_sso.pl



[local-response-macros]

# URL-encoded macros to include in the query string for all management

# page requests.

#

# These will increase the length of the local response redirect URI. Certain

# user-agents, such as WAP browsers, may have URI length limitations, so

# add macros sparingly and cautiously. Note that any special characters will

# be URI-encoded, further increasing the length of the local response URI.

#

# Do not modify the macro strings or add new ones; all supported macros are

# listed below. Comment/uncomment desired macros for inclusion in the local

# response URI. See the WebSEAL Admin Guide for definitions of the content

# corresponding to each macro.

#

# The field names used in the query string can be customized by placing a

# colon and a custom name after the macro definition as demonstrated below.

# macro = USERNAME:customerId

#

# If no name or a blank name is provided after the colon, the default value

# will be used. The default value is the macro name. For the HTTPHDR macro,

# the default value is HTTPHDR_<name>, where name is the name of the HTTP

# header defined in that macro. For the CREDATTR macro, the default value

# is CREDATTR_<name>, where name is the name of the attributed defined in

# that macro.

#

# Note that at a minimum the TAM_OP macro must be included in any response.

# Even if the TAM_OP macro is not included or customized below, it will

# still be present in all response URIs.



macro = TAM_OP

macro = USERNAME

macro = METHOD

macro = AUTHNLEVEL

macro = ERROR_CODE

macro = ERROR_TEXT

#macro = URL

#macro = REFERER

#macro = HOSTNAME

#macro = FAILREASON

#macro = PROTOCOL

#macro = ERROR_URL

#macro = OLDSESSION

#macro = EXPIRE_SECS

#macro = HTTPHDR{<name>}

#macro = CREDATTR{<name>}

#macro = SECONDARY_BASE



[enable-redirects]

# This stanza contains a list of authentication mechanisms

# for which automatic redirects are enabled.

# Valid choices are forms-auth, token-auth, basic-auth, cert-auth,

# oidc and ext-auth-interface

# Any or all of them may be enabled.



#Uncommented by Jesse S. Baeta - Middleware Team --> forms-auth and ext-auth-interface

redirect = forms-auth

redirect = ext-auth-interface


------------------------------
Jessé Baeta

Original Message:
Sent: Fri July 30, 2021 06:08 AM
From: Jon Harry
Subject: EAI Authentication - Post problems

Hi Jessé,

If the HTTP response with headers is returned to the browser, this means that either:
  a) EAI functionality is not enabled for the protocol you are using (HTTP/HTTPS)
  b) The trigger-url didn't match the request for the page that returned the EAI headers.

In the cookbook you're referring to, the relevant configuration is on page 16 and 17.

Make sure that you have eai-auth = https in the [eai] stanza and make sure you're accessing the Reverse Proxy over HTTPS.
Make sure that you don't have a typo in the trigger; it must exactly match the path of the POST request to check_user.pl 

If you're still struggling, maybe paste us the [eai] and [eai-trigger-urls] stanzas in your system.
It would be helpful to see the relevant lines from the request.log of the Reverse Proxy too (and or browser trace showing requests made).

Jon.

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

Original Message:
Sent: Thu July 29, 2021 10:42 AM
From: Jessé Baeta
Subject: EAI Authentication - Post problems

Hi guys, First of all thanks for your attention. I'm facing a problem when I try to implent EAI follow the intructions of security academy learning, the issue is when the script test_sso.pl post o check_user.pl it's not redirect to resource just show on the browser the user and headers. Any ideas?

It's the result when form login post to check_user.pl:
am-eai-user-id: jesse287 am-eai-xattrs: eai-orig-user eai-orig-user: jesse287 Server: Apache-Coyote/1.1 Content-Type: text/html;charset=utf-8 Content-Length: 1048 Date:.Thu, 20.Sept 2017 04:39:57.GMT Connection:.close

Thanks

------------------------------
Jessé Baeta
------------------------------

Jessé,

Did you resolve this issue?  I looked at it again and I noticed that the output of the script sends the line:

Content-type: text/html

and then a blank line.   This is going to make the browser consider all following text as content and not headers.
I notice that the output sends another content-type line later - so I would just remove this line:

#print "Content-type: text/html\n\n";

and try again.

Jon.

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

Original Message:
Sent: Tue August 03, 2021 01:22 PM
From: Jessé Baeta
Subject: EAI Authentication - Post problems

Hi, John thanks again for your attention, I see this result on the browser.

Follow content script check_user.pl

#!/usr/bin/perl -w



### to debug

$|=1;

print "Content-type: text/html\n\n";

use CGI::Carp('fatalsToBrowser');

###



use CGI;

$last_login_failed = 0;

$error_txt = "";

# open file

open OF, ">>/tmp/test_ck.out";



$qstring = $ENV{QUERY_STRING};

print OF "\n QUERY_STRING: $qstring";

print OF "\n";





# dump args

@arg_list = split('&',$qstring);

print OF "ARGS: $#arg_list \n";

for ($i=0; $i<=$#arg_list; $i++) {

print OF "\n $i: $arg_list[$i]";

($tmp1,$tmp2) = split('=',$arg_list[$i]);

if ($tmp1 eq 'ERROR_CODE' && $tmp2 ne "0x00000000") {

$last_login_failed = 1;

}

if ($last_login_failed && $tmp1 eq 'ERROR_TEXT') {

$error_txt = $tmp2;

}

}



print OF "START STDIN: \n";

my @key;

while (<STDIN>) {

@key = split(/&/, $_);

print OF " Key/Value pair for Username is $key[0] \n";

print OF " probably blank line ==>> $_ \n";

}



print OF "END STDIN: \n";

my @username = split(/=/, $key[0]);

print OF " (ext) User name after second split, hopefully not blank, $username[1] \n";

close OF;



# generate login header



# Pass identity in this header for users external to Access Manager

#print "am-eai-ext-user-id: $username[1]\n";



# Pass this header if user is present in Access Manager registry

print "am-eai-user-id: $username[1]\n";



print "am-eai-xattrs: eai-orig-user\n";

print "eai-orig-user: $username[1]\n";



print "Server: Apache-Coyote/1.1\n";

print "Content-Type: text/html;charset=utf-8\n";

print "Content-Length: 1048\n";

print "Date:.Thu, 20.Sept 2017 04:39:57.GMT\n";

print "Connection:.close\n";

print "\n";


------------------------------
Jessé Baeta

Original Message:
Sent: Tue August 03, 2021 11:14 AM
From: Jon Harry
Subject: EAI Authentication - Post problems

Hi Jessé,

Your configuration looks OK to me so I don't understand why the EAI is not working.

To answer your question about pkmslogin.form...
pkmslogin.form is only used specifically for form-based login.  It's not used for EAI.
With EAI, login is completed by the login application (your CGI scripts) returning an HTTP response with a set of HTTP headers that assert identity information to the Reverse Proxy.

Given that your EAI configuration looks correct, I can only guess now that the CGI scripts are not returning a correctly formatted HTTP response.  Maybe there's a blank line at the start so what should be headers is being interpreted as page content?

In your first append you said:
"It's the result when form login post to check_user.pl:
am-eai-user-id: jesse287 am-eai-xattrs: eai-orig-user eai-orig-user: jesse287 Server: Apache-Coyote/1.1 Content-Type: text/html;charset=utf-8 Content-Length: 1048 Date:.Thu, 20.Sept 2017 04:39:57.GMT Connection:.close"

Where did you capture that? 

Jon.

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

Original Message:
Sent: Tue August 03, 2021 07:08 AM
From: Jessé Baeta
Subject: EAI Authentication - Post problems

Hi, first of all thanks and my apologies to delay.
Follow the answers:

A) yes using https.
B) I thing its correctly, but I send part of config below

Note: Its not clear to second script(check_user.pl) because its doesn't post to pkmslogin.form ?

Part of config Reverse Proxy:

[eai]

#----------------------

# EXTERNAL AUTHENTICATION INTERFACE

#----------------------



# Enable EAI authentication.

#

# One of <http, https, both, none>

eai-auth = https



# EAI HEADER NAMES



# If eai-auth is not 'none', and WebSEAL has received a trigger URL

# in a request, WebSEAL will examine the corresponding server response for

# the following headers. These are the headers that will contain authentication

# data used to authenticate the user.



# EAI PAC header names

eai-pac-header = am-eai-pac

eai-pac-svc-header = am-eai-pac-svc



# EAI USER ID header names

eai-user-id-header = am-eai-user-id

eai-auth-level-header = am-eai-auth-level

eai-xattrs-header = am-eai-xattrs



# The following configuration entry is used to determine whether

# to allow eai extended attribute names to contain special characters.

# When set to yes, each of the attribute names in the eai-xattrs-header list containing special characters

# must be URL encoded. The commas delimiting the attribute names must not be URL encoded.

# When set to no then the whole list MAY be URL encoded (including the commas).

# The default value, if no entry is specifed, is 'no'.

#encoded-eai-xattrs = no





# EAI external USER ID header names

# The eai-ext-user-id-header takes precedence over the eai-user-id-header.

# If the authentication data that is presented to WebSEAL includes both headers,

# WebSEAL will process it as an authentication for an external user.

eai-ext-user-id-header = am-eai-ext-user-id

eai-ext-user-groups-header = am-eai-ext-user-groups



# EAI COMMON header names

eai-redir-url-header = am-eai-redir-url



# Determines whether the redirect URL contained within the EAI response takes

# priority over all other EAI redirect options. If set to true the redirect

# URL contained in the EAI response will take priority.

eai-redir-url-priority = yes



# The name of the header which is used to 'flag' the authentication

# response with extra processing information. The supported flags

# (.i.e. header values) include:

# - stream: Used to indicate that the authentication response should

# be streamed back to the client.

# - append-cred-attrs:

# When an extended attribute name matches an existing

# credential attribute, its value will be appended as an

# additional value.

# - replace-cred-attrs:

# When an extended attribute name matches an existing

# credential attribute, its value will replace the

# credential attribute value.

#

# If neither append-cred-attrs nor replace-cred-attrs is

# specified then the eai-replace-cred-attributes

# value determines the extended attribute behaviour.

eai-flags-header = am-eai-flags



# The session identifier from a distributed session can also be supplied

# through the EAI interface. Upon receiving a header which contains the

# distributed session identifier, WebSEAL will retrieve the corresponding

# session and use this session for subsequent requests. This header

# provides the mechanism by which distributed sessions (aka DSC sessions)

# can be shared across multiple DNS domains.

eai-session-id-header = am-eai-session-id



# RETAIN EAI SESSION

# If an already-authenticated EAI client authenticates via an EAI a second

# time, the existing session and cache entry are completely replaced by

# default. If retain-eai-session = yes, then the existing session and

# cache entry will be retained, and the credential and relevant data will

# be updated in the existing cache entry.

retain-eai-session = yes



#

# The following entry determines, in the event of a subsequent EAI

# authentication, whether the new user identity must match the user

# identity from the previous authentication. In the situation where

# eai-verify-user-identity = yes, and the user identities do not

# match, an error will be presented to the user.

#

eai-verify-user-identity = no



# The following configuration entry is used to determine whether multiple

# extended attribute headers of the same name are added to the credential as

# a multi-valued attribute, or a single comma-delimited attribute.

eai-create-multi-valued-attributes = no



# The following configuration entry is used to determine whether

# extended attributes replace credential attributes of the same name

# or are appended as additional values.

eai-replace-cred-attributes = no



# EAI TRIGGER URLS

[eai-trigger-urls]

# If eai-auth is not 'none', then WebSEAL will examine the URLs of incoming

# requests to determine if they match one of the entries in this list.

# If they do, then WebSEAL will examine the corresponding server response to

# determine if it contains authentication data.

#

# NOTE: If eai-auth is not 'none', there must be at least one entry in this list

#

# The URL string patterns are case-sensitive wild card patterns.

#

# Format for regular WebSEAL junctions is:

# trigger = <URL pattern of EAI server response>

#

# Format for Virtual Host junctions is:

# trigger = HTTP[S]://virtual-host-name[:port]/<URL pattern of EAI server response>

#

# For Virtual Host junctions to match a trigger they must also have the same

# protocol (HTTP[S] = TCP/SSL) and have the same virtual-host-name & port as

# the trigger. The virtual-host-name match is case-insensitive.

#

# Regular WebSEAL junction triggers are not used by Virtual Host junctions.

# Virtual Host junction triggers are not used by regular WebSEAL junctions.



trigger = /mga/sps/auth*

trigger = /mga/sps/authservice/authentication*

trigger = /mga/sps/authsvc*

trigger = /mga/sps/apiauthsvc*

trigger = /eai/cgi-bin/check_user.pl







#local-response-redirect-uri = /jct/redirect/handler

#Add by Jesse S. Baeta - Middleware Team

local-response-redirect-uri = /eai/cgi-bin/test_sso.pl



[local-response-macros]

# URL-encoded macros to include in the query string for all management

# page requests.

#

# These will increase the length of the local response redirect URI. Certain

# user-agents, such as WAP browsers, may have URI length limitations, so

# add macros sparingly and cautiously. Note that any special characters will

# be URI-encoded, further increasing the length of the local response URI.

#

# Do not modify the macro strings or add new ones; all supported macros are

# listed below. Comment/uncomment desired macros for inclusion in the local

# response URI. See the WebSEAL Admin Guide for definitions of the content

# corresponding to each macro.

#

# The field names used in the query string can be customized by placing a

# colon and a custom name after the macro definition as demonstrated below.

# macro = USERNAME:customerId

#

# If no name or a blank name is provided after the colon, the default value

# will be used. The default value is the macro name. For the HTTPHDR macro,

# the default value is HTTPHDR_<name>, where name is the name of the HTTP

# header defined in that macro. For the CREDATTR macro, the default value

# is CREDATTR_<name>, where name is the name of the attributed defined in

# that macro.

#

# Note that at a minimum the TAM_OP macro must be included in any response.

# Even if the TAM_OP macro is not included or customized below, it will

# still be present in all response URIs.



macro = TAM_OP

macro = USERNAME

macro = METHOD

macro = AUTHNLEVEL

macro = ERROR_CODE

macro = ERROR_TEXT

#macro = URL

#macro = REFERER

#macro = HOSTNAME

#macro = FAILREASON

#macro = PROTOCOL

#macro = ERROR_URL

#macro = OLDSESSION

#macro = EXPIRE_SECS

#macro = HTTPHDR{<name>}

#macro = CREDATTR{<name>}

#macro = SECONDARY_BASE



[enable-redirects]

# This stanza contains a list of authentication mechanisms

# for which automatic redirects are enabled.

# Valid choices are forms-auth, token-auth, basic-auth, cert-auth,

# oidc and ext-auth-interface

# Any or all of them may be enabled.



#Uncommented by Jesse S. Baeta - Middleware Team --> forms-auth and ext-auth-interface

redirect = forms-auth

redirect = ext-auth-interface


------------------------------
Jessé Baeta

Original Message:
Sent: Fri July 30, 2021 06:08 AM
From: Jon Harry
Subject: EAI Authentication - Post problems

Hi Jessé,

If the HTTP response with headers is returned to the browser, this means that either:
  a) EAI functionality is not enabled for the protocol you are using (HTTP/HTTPS)
  b) The trigger-url didn't match the request for the page that returned the EAI headers.

In the cookbook you're referring to, the relevant configuration is on page 16 and 17.

Make sure that you have eai-auth = https in the [eai] stanza and make sure you're accessing the Reverse Proxy over HTTPS.
Make sure that you don't have a typo in the trigger; it must exactly match the path of the POST request to check_user.pl 

If you're still struggling, maybe paste us the [eai] and [eai-trigger-urls] stanzas in your system.
It would be helpful to see the relevant lines from the request.log of the Reverse Proxy too (and or browser trace showing requests made).

Jon.

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

Original Message:
Sent: Thu July 29, 2021 10:42 AM
From: Jessé Baeta
Subject: EAI Authentication - Post problems

Hi guys, First of all thanks for your attention. I'm facing a problem when I try to implent EAI follow the intructions of security academy learning, the issue is when the script test_sso.pl post o check_user.pl it's not redirect to resource just show on the browser the user and headers. Any ideas?

It's the result when form login post to check_user.pl:
am-eai-user-id: jesse287 am-eai-xattrs: eai-orig-user eai-orig-user: jesse287 Server: Apache-Coyote/1.1 Content-Type: text/html;charset=utf-8 Content-Length: 1048 Date:.Thu, 20.Sept 2017 04:39:57.GMT Connection:.close

Thanks

------------------------------
Jessé Baeta
------------------------------

Original Message:
Sent: 9/2/2021 1:30:00 PM
From: Jon Harry
Subject: RE: EAI Authentication - Post problems

Jessé,

Did you resolve this issue?  I looked at it again and I noticed that the output of the script sends the line:

Content-type: text/html

and then a blank line.   This is going to make the browser consider all following text as content and not headers.
I notice that the output sends another content-type line later - so I would just remove this line:

#print "Content-type: text/html\n\n";

and try again.

Jon.

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

Original Message:
Sent: Tue August 03, 2021 01:22 PM
From: Jessé Baeta
Subject: EAI Authentication - Post problems

Hi, John thanks again for your attention, I see this result on the browser.

Follow content script check_user.pl

#!/usr/bin/perl -w



### to debug

$|=1;

print "Content-type: text/html\n\n";

use CGI::Carp('fatalsToBrowser');

###



use CGI;

$last_login_failed = 0;

$error_txt = "";

# open file

open OF, ">>/tmp/test_ck.out";



$qstring = $ENV{QUERY_STRING};

print OF "\n QUERY_STRING: $qstring";

print OF "\n";





# dump args

@arg_list = split('&',$qstring);

print OF "ARGS: $#arg_list \n";

for ($i=0; $i<=$#arg_list; $i++) {

print OF "\n $i: $arg_list[$i]";

($tmp1,$tmp2) = split('=',$arg_list[$i]);

if ($tmp1 eq 'ERROR_CODE' && $tmp2 ne "0x00000000") {

$last_login_failed = 1;

}

if ($last_login_failed && $tmp1 eq 'ERROR_TEXT') {

$error_txt = $tmp2;

}

}



print OF "START STDIN: \n";

my @key;

while (<STDIN>) {

@key = split(/&/, $_);

print OF " Key/Value pair for Username is $key[0] \n";

print OF " probably blank line ==>> $_ \n";

}



print OF "END STDIN: \n";

my @username = split(/=/, $key[0]);

print OF " (ext) User name after second split, hopefully not blank, $username[1] \n";

close OF;



# generate login header



# Pass identity in this header for users external to Access Manager

#print "am-eai-ext-user-id: $username[1]\n";



# Pass this header if user is present in Access Manager registry

print "am-eai-user-id: $username[1]\n";



print "am-eai-xattrs: eai-orig-user\n";

print "eai-orig-user: $username[1]\n";



print "Server: Apache-Coyote/1.1\n";

print "Content-Type: text/html;charset=utf-8\n";

print "Content-Length: 1048\n";

print "Date:.Thu, 20.Sept 2017 04:39:57.GMT\n";

print "Connection:.close\n";

print "\n";


------------------------------
Jessé Baeta

Original Message:
Sent: Tue August 03, 2021 11:14 AM
From: Jon Harry
Subject: EAI Authentication - Post problems

Hi Jessé,

Your configuration looks OK to me so I don't understand why the EAI is not working.

To answer your question about pkmslogin.form...
pkmslogin.form is only used specifically for form-based login.  It's not used for EAI.
With EAI, login is completed by the login application (your CGI scripts) returning an HTTP response with a set of HTTP headers that assert identity information to the Reverse Proxy.

Given that your EAI configuration looks correct, I can only guess now that the CGI scripts are not returning a correctly formatted HTTP response.  Maybe there's a blank line at the start so what should be headers is being interpreted as page content?

In your first append you said:
"It's the result when form login post to check_user.pl:
am-eai-user-id: jesse287 am-eai-xattrs: eai-orig-user eai-orig-user: jesse287 Server: Apache-Coyote/1.1 Content-Type: text/html;charset=utf-8 Content-Length: 1048 Date:.Thu, 20.Sept 2017 04:39:57.GMT Connection:.close"

Where did you capture that? 

Jon.

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

Original Message:
Sent: Tue August 03, 2021 07:08 AM
From: Jessé Baeta
Subject: EAI Authentication - Post problems

Hi, first of all thanks and my apologies to delay.
Follow the answers:

A) yes using https.
B) I thing its correctly, but I send part of config below

Note: Its not clear to second script(check_user.pl) because its doesn't post to pkmslogin.form ?

Part of config Reverse Proxy:

[eai]

#----------------------

# EXTERNAL AUTHENTICATION INTERFACE

#----------------------



# Enable EAI authentication.

#

# One of <http, https, both, none>

eai-auth = https



# EAI HEADER NAMES



# If eai-auth is not 'none', and WebSEAL has received a trigger URL

# in a request, WebSEAL will examine the corresponding server response for

# the following headers. These are the headers that will contain authentication

# data used to authenticate the user.



# EAI PAC header names

eai-pac-header = am-eai-pac

eai-pac-svc-header = am-eai-pac-svc



# EAI USER ID header names

eai-user-id-header = am-eai-user-id

eai-auth-level-header = am-eai-auth-level

eai-xattrs-header = am-eai-xattrs



# The following configuration entry is used to determine whether

# to allow eai extended attribute names to contain special characters.

# When set to yes, each of the attribute names in the eai-xattrs-header list containing special characters

# must be URL encoded. The commas delimiting the attribute names must not be URL encoded.

# When set to no then the whole list MAY be URL encoded (including the commas).

# The default value, if no entry is specifed, is 'no'.

#encoded-eai-xattrs = no





# EAI external USER ID header names

# The eai-ext-user-id-header takes precedence over the eai-user-id-header.

# If the authentication data that is presented to WebSEAL includes both headers,

# WebSEAL will process it as an authentication for an external user.

eai-ext-user-id-header = am-eai-ext-user-id

eai-ext-user-groups-header = am-eai-ext-user-groups



# EAI COMMON header names

eai-redir-url-header = am-eai-redir-url



# Determines whether the redirect URL contained within the EAI response takes

# priority over all other EAI redirect options. If set to true the redirect

# URL contained in the EAI response will take priority.

eai-redir-url-priority = yes



# The name of the header which is used to 'flag' the authentication

# response with extra processing information. The supported flags

# (.i.e. header values) include:

# - stream: Used to indicate that the authentication response should

# be streamed back to the client.

# - append-cred-attrs:

# When an extended attribute name matches an existing

# credential attribute, its value will be appended as an

# additional value.

# - replace-cred-attrs:

# When an extended attribute name matches an existing

# credential attribute, its value will replace the

# credential attribute value.

#

# If neither append-cred-attrs nor replace-cred-attrs is

# specified then the eai-replace-cred-attributes

# value determines the extended attribute behaviour.

eai-flags-header = am-eai-flags



# The session identifier from a distributed session can also be supplied

# through the EAI interface. Upon receiving a header which contains the

# distributed session identifier, WebSEAL will retrieve the corresponding

# session and use this session for subsequent requests. This header

# provides the mechanism by which distributed sessions (aka DSC sessions)

# can be shared across multiple DNS domains.

eai-session-id-header = am-eai-session-id



# RETAIN EAI SESSION

# If an already-authenticated EAI client authenticates via an EAI a second

# time, the existing session and cache entry are completely replaced by

# default. If retain-eai-session = yes, then the existing session and

# cache entry will be retained, and the credential and relevant data will

# be updated in the existing cache entry.

retain-eai-session = yes



#

# The following entry determines, in the event of a subsequent EAI

# authentication, whether the new user identity must match the user

# identity from the previous authentication. In the situation where

# eai-verify-user-identity = yes, and the user identities do not

# match, an error will be presented to the user.

#

eai-verify-user-identity = no



# The following configuration entry is used to determine whether multiple

# extended attribute headers of the same name are added to the credential as

# a multi-valued attribute, or a single comma-delimited attribute.

eai-create-multi-valued-attributes = no



# The following configuration entry is used to determine whether

# extended attributes replace credential attributes of the same name

# or are appended as additional values.

eai-replace-cred-attributes = no



# EAI TRIGGER URLS

[eai-trigger-urls]

# If eai-auth is not 'none', then WebSEAL will examine the URLs of incoming

# requests to determine if they match one of the entries in this list.

# If they do, then WebSEAL will examine the corresponding server response to

# determine if it contains authentication data.

#

# NOTE: If eai-auth is not 'none', there must be at least one entry in this list

#

# The URL string patterns are case-sensitive wild card patterns.

#

# Format for regular WebSEAL junctions is:

# trigger = <URL pattern of EAI server response>

#

# Format for Virtual Host junctions is:

# trigger = HTTP[S]://virtual-host-name[:port]/<URL pattern of EAI server response>

#

# For Virtual Host junctions to match a trigger they must also have the same

# protocol (HTTP[S] = TCP/SSL) and have the same virtual-host-name & port as

# the trigger. The virtual-host-name match is case-insensitive.

#

# Regular WebSEAL junction triggers are not used by Virtual Host junctions.

# Virtual Host junction triggers are not used by regular WebSEAL junctions.



trigger = /mga/sps/auth*

trigger = /mga/sps/authservice/authentication*

trigger = /mga/sps/authsvc*

trigger = /mga/sps/apiauthsvc*

trigger = /eai/cgi-bin/check_user.pl







#local-response-redirect-uri = /jct/redirect/handler

#Add by Jesse S. Baeta - Middleware Team

local-response-redirect-uri = /eai/cgi-bin/test_sso.pl



[local-response-macros]

# URL-encoded macros to include in the query string for all management

# page requests.

#

# These will increase the length of the local response redirect URI. Certain

# user-agents, such as WAP browsers, may have URI length limitations, so

# add macros sparingly and cautiously. Note that any special characters will

# be URI-encoded, further increasing the length of the local response URI.

#

# Do not modify the macro strings or add new ones; all supported macros are

# listed below. Comment/uncomment desired macros for inclusion in the local

# response URI. See the WebSEAL Admin Guide for definitions of the content

# corresponding to each macro.

#

# The field names used in the query string can be customized by placing a

# colon and a custom name after the macro definition as demonstrated below.

# macro = USERNAME:customerId

#

# If no name or a blank name is provided after the colon, the default value

# will be used. The default value is the macro name. For the HTTPHDR macro,

# the default value is HTTPHDR_<name>, where name is the name of the HTTP

# header defined in that macro. For the CREDATTR macro, the default value

# is CREDATTR_<name>, where name is the name of the attributed defined in

# that macro.

#

# Note that at a minimum the TAM_OP macro must be included in any response.

# Even if the TAM_OP macro is not included or customized below, it will

# still be present in all response URIs.



macro = TAM_OP

macro = USERNAME

macro = METHOD

macro = AUTHNLEVEL

macro = ERROR_CODE

macro = ERROR_TEXT

#macro = URL

#macro = REFERER

#macro = HOSTNAME

#macro = FAILREASON

#macro = PROTOCOL

#macro = ERROR_URL

#macro = OLDSESSION

#macro = EXPIRE_SECS

#macro = HTTPHDR{<name>}

#macro = CREDATTR{<name>}

#macro = SECONDARY_BASE



[enable-redirects]

# This stanza contains a list of authentication mechanisms

# for which automatic redirects are enabled.

# Valid choices are forms-auth, token-auth, basic-auth, cert-auth,

# oidc and ext-auth-interface

# Any or all of them may be enabled.



#Uncommented by Jesse S. Baeta - Middleware Team --> forms-auth and ext-auth-interface

redirect = forms-auth

redirect = ext-auth-interface


------------------------------
Jessé Baeta

Original Message:
Sent: Fri July 30, 2021 06:08 AM
From: Jon Harry
Subject: EAI Authentication - Post problems

Hi Jessé,

If the HTTP response with headers is returned to the browser, this means that either:
  a) EAI functionality is not enabled for the protocol you are using (HTTP/HTTPS)
  b) The trigger-url didn't match the request for the page that returned the EAI headers.

In the cookbook you're referring to, the relevant configuration is on page 16 and 17.

Make sure that you have eai-auth = https in the [eai] stanza and make sure you're accessing the Reverse Proxy over HTTPS.
Make sure that you don't have a typo in the trigger; it must exactly match the path of the POST request to check_user.pl 

If you're still struggling, maybe paste us the [eai] and [eai-trigger-urls] stanzas in your system.
It would be helpful to see the relevant lines from the request.log of the Reverse Proxy too (and or browser trace showing requests made).

Jon.

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

Original Message:
Sent: Thu July 29, 2021 10:42 AM
From: Jessé Baeta
Subject: EAI Authentication - Post problems

Hi guys, First of all thanks for your attention. I'm facing a problem when I try to implent EAI follow the intructions of security academy learning, the issue is when the script test_sso.pl post o check_user.pl it's not redirect to resource just show on the browser the user and headers. Any ideas?

It's the result when form login post to check_user.pl:
am-eai-user-id: jesse287 am-eai-xattrs: eai-orig-user eai-orig-user: jesse287 Server: Apache-Coyote/1.1 Content-Type: text/html;charset=utf-8 Content-Length: 1048 Date:.Thu, 20.Sept 2017 04:39:57.GMT Connection:.close

Thanks

------------------------------
Jessé Baeta
------------------------------

Hi,
I'm sorry to delay,  this issue was solved the problem it was:

### to debug

$|=1;

print "Content-type: text/html\n\n";

use CGI::Carp('fatalsToBrowser');

###

I just removed from script and now work's fine.

Thanks a lot.

------------------------------
Jessé Baeta
------------------------------

Original Message:
Sent: Thu September 02, 2021 01:29 PM
From: Jon Harry
Subject: EAI Authentication - Post problems

Jessé,

Did you resolve this issue?  I looked at it again and I noticed that the output of the script sends the line:

Content-type: text/html

and then a blank line.   This is going to make the browser consider all following text as content and not headers.
I notice that the output sends another content-type line later - so I would just remove this line:

#print "Content-type: text/html\n\n";

and try again.

Jon.

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

Original Message:
Sent: Tue August 03, 2021 01:22 PM
From: Jessé Baeta
Subject: EAI Authentication - Post problems

Hi, John thanks again for your attention, I see this result on the browser.

Follow content script check_user.pl

#!/usr/bin/perl -w



### to debug

$|=1;

print "Content-type: text/html\n\n";

use CGI::Carp('fatalsToBrowser');

###



use CGI;

$last_login_failed = 0;

$error_txt = "";

# open file

open OF, ">>/tmp/test_ck.out";



$qstring = $ENV{QUERY_STRING};

print OF "\n QUERY_STRING: $qstring";

print OF "\n";





# dump args

@arg_list = split('&',$qstring);

print OF "ARGS: $#arg_list \n";

for ($i=0; $i<=$#arg_list; $i++) {

print OF "\n $i: $arg_list[$i]";

($tmp1,$tmp2) = split('=',$arg_list[$i]);

if ($tmp1 eq 'ERROR_CODE' && $tmp2 ne "0x00000000") {

$last_login_failed = 1;

}

if ($last_login_failed && $tmp1 eq 'ERROR_TEXT') {

$error_txt = $tmp2;

}

}



print OF "START STDIN: \n";

my @key;

while (<STDIN>) {

@key = split(/&/, $_);

print OF " Key/Value pair for Username is $key[0] \n";

print OF " probably blank line ==>> $_ \n";

}



print OF "END STDIN: \n";

my @username = split(/=/, $key[0]);

print OF " (ext) User name after second split, hopefully not blank, $username[1] \n";

close OF;



# generate login header



# Pass identity in this header for users external to Access Manager

#print "am-eai-ext-user-id: $username[1]\n";



# Pass this header if user is present in Access Manager registry

print "am-eai-user-id: $username[1]\n";



print "am-eai-xattrs: eai-orig-user\n";

print "eai-orig-user: $username[1]\n";



print "Server: Apache-Coyote/1.1\n";

print "Content-Type: text/html;charset=utf-8\n";

print "Content-Length: 1048\n";

print "Date:.Thu, 20.Sept 2017 04:39:57.GMT\n";

print "Connection:.close\n";

print "\n";


------------------------------
Jessé Baeta

Original Message:
Sent: Tue August 03, 2021 11:14 AM
From: Jon Harry
Subject: EAI Authentication - Post problems

Hi Jessé,

Your configuration looks OK to me so I don't understand why the EAI is not working.

To answer your question about pkmslogin.form...
pkmslogin.form is only used specifically for form-based login.  It's not used for EAI.
With EAI, login is completed by the login application (your CGI scripts) returning an HTTP response with a set of HTTP headers that assert identity information to the Reverse Proxy.

Given that your EAI configuration looks correct, I can only guess now that the CGI scripts are not returning a correctly formatted HTTP response.  Maybe there's a blank line at the start so what should be headers is being interpreted as page content?

In your first append you said:
"It's the result when form login post to check_user.pl:
am-eai-user-id: jesse287 am-eai-xattrs: eai-orig-user eai-orig-user: jesse287 Server: Apache-Coyote/1.1 Content-Type: text/html;charset=utf-8 Content-Length: 1048 Date:.Thu, 20.Sept 2017 04:39:57.GMT Connection:.close"

Where did you capture that? 

Jon.

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

Original Message:
Sent: Tue August 03, 2021 07:08 AM
From: Jessé Baeta
Subject: EAI Authentication - Post problems

Hi, first of all thanks and my apologies to delay.
Follow the answers:

A) yes using https.
B) I thing its correctly, but I send part of config below

Note: Its not clear to second script(check_user.pl) because its doesn't post to pkmslogin.form ?

Part of config Reverse Proxy:

[eai]

#----------------------

# EXTERNAL AUTHENTICATION INTERFACE

#----------------------



# Enable EAI authentication.

#

# One of <http, https, both, none>

eai-auth = https



# EAI HEADER NAMES



# If eai-auth is not 'none', and WebSEAL has received a trigger URL

# in a request, WebSEAL will examine the corresponding server response for

# the following headers. These are the headers that will contain authentication

# data used to authenticate the user.



# EAI PAC header names

eai-pac-header = am-eai-pac

eai-pac-svc-header = am-eai-pac-svc



# EAI USER ID header names

eai-user-id-header = am-eai-user-id

eai-auth-level-header = am-eai-auth-level

eai-xattrs-header = am-eai-xattrs



# The following configuration entry is used to determine whether

# to allow eai extended attribute names to contain special characters.

# When set to yes, each of the attribute names in the eai-xattrs-header list containing special characters

# must be URL encoded. The commas delimiting the attribute names must not be URL encoded.

# When set to no then the whole list MAY be URL encoded (including the commas).

# The default value, if no entry is specifed, is 'no'.

#encoded-eai-xattrs = no





# EAI external USER ID header names

# The eai-ext-user-id-header takes precedence over the eai-user-id-header.

# If the authentication data that is presented to WebSEAL includes both headers,

# WebSEAL will process it as an authentication for an external user.

eai-ext-user-id-header = am-eai-ext-user-id

eai-ext-user-groups-header = am-eai-ext-user-groups



# EAI COMMON header names

eai-redir-url-header = am-eai-redir-url



# Determines whether the redirect URL contained within the EAI response takes

# priority over all other EAI redirect options. If set to true the redirect

# URL contained in the EAI response will take priority.

eai-redir-url-priority = yes



# The name of the header which is used to 'flag' the authentication

# response with extra processing information. The supported flags

# (.i.e. header values) include:

# - stream: Used to indicate that the authentication response should

# be streamed back to the client.

# - append-cred-attrs:

# When an extended attribute name matches an existing

# credential attribute, its value will be appended as an

# additional value.

# - replace-cred-attrs:

# When an extended attribute name matches an existing

# credential attribute, its value will replace the

# credential attribute value.

#

# If neither append-cred-attrs nor replace-cred-attrs is

# specified then the eai-replace-cred-attributes

# value determines the extended attribute behaviour.

eai-flags-header = am-eai-flags



# The session identifier from a distributed session can also be supplied

# through the EAI interface. Upon receiving a header which contains the

# distributed session identifier, WebSEAL will retrieve the corresponding

# session and use this session for subsequent requests. This header

# provides the mechanism by which distributed sessions (aka DSC sessions)

# can be shared across multiple DNS domains.

eai-session-id-header = am-eai-session-id



# RETAIN EAI SESSION

# If an already-authenticated EAI client authenticates via an EAI a second

# time, the existing session and cache entry are completely replaced by

# default. If retain-eai-session = yes, then the existing session and

# cache entry will be retained, and the credential and relevant data will

# be updated in the existing cache entry.

retain-eai-session = yes



#

# The following entry determines, in the event of a subsequent EAI

# authentication, whether the new user identity must match the user

# identity from the previous authentication. In the situation where

# eai-verify-user-identity = yes, and the user identities do not

# match, an error will be presented to the user.

#

eai-verify-user-identity = no



# The following configuration entry is used to determine whether multiple

# extended attribute headers of the same name are added to the credential as

# a multi-valued attribute, or a single comma-delimited attribute.

eai-create-multi-valued-attributes = no



# The following configuration entry is used to determine whether

# extended attributes replace credential attributes of the same name

# or are appended as additional values.

eai-replace-cred-attributes = no



# EAI TRIGGER URLS

[eai-trigger-urls]

# If eai-auth is not 'none', then WebSEAL will examine the URLs of incoming

# requests to determine if they match one of the entries in this list.

# If they do, then WebSEAL will examine the corresponding server response to

# determine if it contains authentication data.

#

# NOTE: If eai-auth is not 'none', there must be at least one entry in this list

#

# The URL string patterns are case-sensitive wild card patterns.

#

# Format for regular WebSEAL junctions is:

# trigger = <URL pattern of EAI server response>

#

# Format for Virtual Host junctions is:

# trigger = HTTP[S]://virtual-host-name[:port]/<URL pattern of EAI server response>

#

# For Virtual Host junctions to match a trigger they must also have the same

# protocol (HTTP[S] = TCP/SSL) and have the same virtual-host-name & port as

# the trigger. The virtual-host-name match is case-insensitive.

#

# Regular WebSEAL junction triggers are not used by Virtual Host junctions.

# Virtual Host junction triggers are not used by regular WebSEAL junctions.



trigger = /mga/sps/auth*

trigger = /mga/sps/authservice/authentication*

trigger = /mga/sps/authsvc*

trigger = /mga/sps/apiauthsvc*

trigger = /eai/cgi-bin/check_user.pl







#local-response-redirect-uri = /jct/redirect/handler

#Add by Jesse S. Baeta - Middleware Team

local-response-redirect-uri = /eai/cgi-bin/test_sso.pl



[local-response-macros]

# URL-encoded macros to include in the query string for all management

# page requests.

#

# These will increase the length of the local response redirect URI. Certain

# user-agents, such as WAP browsers, may have URI length limitations, so

# add macros sparingly and cautiously. Note that any special characters will

# be URI-encoded, further increasing the length of the local response URI.

#

# Do not modify the macro strings or add new ones; all supported macros are

# listed below. Comment/uncomment desired macros for inclusion in the local

# response URI. See the WebSEAL Admin Guide for definitions of the content

# corresponding to each macro.

#

# The field names used in the query string can be customized by placing a

# colon and a custom name after the macro definition as demonstrated below.

# macro = USERNAME:customerId

#

# If no name or a blank name is provided after the colon, the default value

# will be used. The default value is the macro name. For the HTTPHDR macro,

# the default value is HTTPHDR_<name>, where name is the name of the HTTP

# header defined in that macro. For the CREDATTR macro, the default value

# is CREDATTR_<name>, where name is the name of the attributed defined in

# that macro.

#

# Note that at a minimum the TAM_OP macro must be included in any response.

# Even if the TAM_OP macro is not included or customized below, it will

# still be present in all response URIs.



macro = TAM_OP

macro = USERNAME

macro = METHOD

macro = AUTHNLEVEL

macro = ERROR_CODE

macro = ERROR_TEXT

#macro = URL

#macro = REFERER

#macro = HOSTNAME

#macro = FAILREASON

#macro = PROTOCOL

#macro = ERROR_URL

#macro = OLDSESSION

#macro = EXPIRE_SECS

#macro = HTTPHDR{<name>}

#macro = CREDATTR{<name>}

#macro = SECONDARY_BASE



[enable-redirects]

# This stanza contains a list of authentication mechanisms

# for which automatic redirects are enabled.

# Valid choices are forms-auth, token-auth, basic-auth, cert-auth,

# oidc and ext-auth-interface

# Any or all of them may be enabled.



#Uncommented by Jesse S. Baeta - Middleware Team --> forms-auth and ext-auth-interface

redirect = forms-auth

redirect = ext-auth-interface


------------------------------
Jessé Baeta

Original Message:
Sent: Fri July 30, 2021 06:08 AM
From: Jon Harry
Subject: EAI Authentication - Post problems

Hi Jessé,

If the HTTP response with headers is returned to the browser, this means that either:
  a) EAI functionality is not enabled for the protocol you are using (HTTP/HTTPS)
  b) The trigger-url didn't match the request for the page that returned the EAI headers.

In the cookbook you're referring to, the relevant configuration is on page 16 and 17.

Make sure that you have eai-auth = https in the [eai] stanza and make sure you're accessing the Reverse Proxy over HTTPS.
Make sure that you don't have a typo in the trigger; it must exactly match the path of the POST request to check_user.pl 

If you're still struggling, maybe paste us the [eai] and [eai-trigger-urls] stanzas in your system.
It would be helpful to see the relevant lines from the request.log of the Reverse Proxy too (and or browser trace showing requests made).

Jon.

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

Original Message:
Sent: Thu July 29, 2021 10:42 AM
From: Jessé Baeta
Subject: EAI Authentication - Post problems

Hi guys, First of all thanks for your attention. I'm facing a problem when I try to implent EAI follow the intructions of security academy learning, the issue is when the script test_sso.pl post o check_user.pl it's not redirect to resource just show on the browser the user and headers. Any ideas?

It's the result when form login post to check_user.pl:
am-eai-user-id: jesse287 am-eai-xattrs: eai-orig-user eai-orig-user: jesse287 Server: Apache-Coyote/1.1 Content-Type: text/html;charset=utf-8 Content-Length: 1048 Date:.Thu, 20.Sept 2017 04:39:57.GMT Connection:.close

Thanks

------------------------------
Jessé Baeta
------------------------------