IBM Security Verify

------------------------------
Narayan Verma
------------------------------

Hi team, any isights or recommendations on this?

Thanks!

------------------------------
Narayan Verma
------------------------------

Certificate authentication happens at the transport layer directly to WebSEAL. It does not make sense that it would ever use an AAC/Infomap authentication policy. It might use an Infomap to do identity mapping for the certificate, but that's all.

If you want certificate authentication as primary, followed by essentially step-up to Duo, then that is easy. Use a protected object policy on the junction (or any other WebSEAL object space resource that you want to protected) with authentication levels, like:

pdadmin> pop create level2poppdadmin> pop modify level2pop set ipauth anyothernw 2pdadmin> pop attach /WebSEAL/<your_server>/<your jct> level2pop

In your  [authentication-levels] stanza, something like:

[authentication-levels]level = unauthenticatedlevel = ssllevel = ext-auth-interface

To redirect to your Duo Infomap for step-up authentication:

[acnt-mgt]enable-local-response-redirect = yes[local-response-redirect]local-response-redirect-uri = [stepup] /mga/sps/authsvc/policy/duoPolicy

And in the AuthSvcCredential mapping rule (included in AAC), which runs at the successful completion of any AAC authentication policy, add:

if (policyID.equals("urn:ibm:security:authentication:asf:duoPolicy")) {   stsuu.getAttributeContainer().setAttribute(new Attribute("AUTHENTICATION_LEVEL", null, "2"));}

If its not that exact combination, its close. Experiment.

------------------------------
Shane Weeden
IBM

Original Message:
Sent: Tue January 09, 2024 02:28 PM
From: Narayan Verma
Subject: Adding an infomap mechanism to the default login policy

Hi team, any isights or recommendations on this?

Thanks!

------------------------------
Narayan Verma

Original Message:
Sent: Mon January 08, 2024 10:56 AM
From: Narayan Verma
Subject: Adding an infomap mechanism to the default login policy

------------------------------
Narayan Verma
------------------------------

Thanks Shane!

How do we achieve Duo authentication right after the user id/password authentication?  The current login screen - e.g. certlogin.html provides both userid/password authentication and certificate option.  What we want to do is to inject Duo right after the userid/password authentication if the user chooses that route.  If user goes for cert based authentication then Duo is not needed.  We want to do that as part of initial login not as part of step-up authentication.

Somewhat of a later concern, for step-up authentication for sensitive data applications is it possible to provide an option to the user of using (either Duo or Certificate) not just Duo-only or just Cert-only?

We are trying to treat Duo and cert as same level of authentications from strength perspective.  Our options for initial login are going to be either of a) Kerberos b) userid/password followed by Duo c) certificate.  For step-up they are going to be either of a) Duo b) certificate.  That's the desired end goal.  I am hoping it's not going to create any conflicts, lead to bad practices, or unsupportable configurations.

------------------------------
Narayan Verma

Original Message:
Sent: Wed January 10, 2024 01:36 AM
From: Shane Weeden
Subject: Adding an infomap mechanism to the default login policy

Certificate authentication happens at the transport layer directly to WebSEAL. It does not make sense that it would ever use an AAC/Infomap authentication policy. It might use an Infomap to do identity mapping for the certificate, but that's all.

If you want certificate authentication as primary, followed by essentially step-up to Duo, then that is easy. Use a protected object policy on the junction (or any other WebSEAL object space resource that you want to protected) with authentication levels, like:

pdadmin> pop create level2poppdadmin> pop modify level2pop set ipauth anyothernw 2pdadmin> pop attach /WebSEAL/<your_server>/<your jct> level2pop

In your  [authentication-levels] stanza, something like:

[authentication-levels]level = unauthenticatedlevel = ssllevel = ext-auth-interface

To redirect to your Duo Infomap for step-up authentication:

[acnt-mgt]enable-local-response-redirect = yes[local-response-redirect]local-response-redirect-uri = [stepup] /mga/sps/authsvc/policy/duoPolicy

And in the AuthSvcCredential mapping rule (included in AAC), which runs at the successful completion of any AAC authentication policy, add:

if (policyID.equals("urn:ibm:security:authentication:asf:duoPolicy")) {   stsuu.getAttributeContainer().setAttribute(new Attribute("AUTHENTICATION_LEVEL", null, "2"));}

If its not that exact combination, its close. Experiment.

------------------------------
Shane Weeden
IBM

Original Message:
Sent: Tue January 09, 2024 02:28 PM
From: Narayan Verma
Subject: Adding an infomap mechanism to the default login policy

Hi team, any isights or recommendations on this?

Thanks!

------------------------------
Narayan Verma

Original Message:
Sent: Mon January 08, 2024 10:56 AM
From: Narayan Verma
Subject: Adding an infomap mechanism to the default login policy

------------------------------
Narayan Verma
------------------------------

You do this exactly the same way I have described - use the building blocks I have provided to put your solution together. Step-up authentication is just a way of triggering another level of authentication (Duo, or certificate) after password authentication. So you'd start with something like:

[authentication-levels]level = unauthenticatedlevel = passwordlevel = ext-auth-interfacelevel = ext-ssl

In this case password=1, EAI=2 (this includes Duo), and certificates=3. You would still use level2pop to protect all resources that are of any value. Either level 2 or 3 satisifies this.

Then instead of just using local-response-redirect to redirect to Duo on step-up, take that out and allow WebSEAL to show the regular stepuplogin.html page. Modify WebSEAL to have:

[step-up]show-all-auth-prompts = yesstep-up-at-higher-level = yes

Code your "choices" of either Duo or certificates to be displayed to the user into stepuplogin.html with FORM actions pointing to each as appropriate.

------------------------------
Shane Weeden
IBM

Original Message:
Sent: Wed January 10, 2024 09:15 AM
From: Narayan Verma
Subject: Adding an infomap mechanism to the default login policy

Thanks Shane!

How do we achieve Duo authentication right after the user id/password authentication?  The current login screen - e.g. certlogin.html provides both userid/password authentication and certificate option.  What we want to do is to inject Duo right after the userid/password authentication if the user chooses that route.  If user goes for cert based authentication then Duo is not needed.  We want to do that as part of initial login not as part of step-up authentication.

Somewhat of a later concern, for step-up authentication for sensitive data applications is it possible to provide an option to the user of using (either Duo or Certificate) not just Duo-only or just Cert-only?

We are trying to treat Duo and cert as same level of authentications from strength perspective.  Our options for initial login are going to be either of a) Kerberos b) userid/password followed by Duo c) certificate.  For step-up they are going to be either of a) Duo b) certificate.  That's the desired end goal.  I am hoping it's not going to create any conflicts, lead to bad practices, or unsupportable configurations.

------------------------------
Narayan Verma

Original Message:
Sent: Wed January 10, 2024 01:36 AM
From: Shane Weeden
Subject: Adding an infomap mechanism to the default login policy

Certificate authentication happens at the transport layer directly to WebSEAL. It does not make sense that it would ever use an AAC/Infomap authentication policy. It might use an Infomap to do identity mapping for the certificate, but that's all.

If you want certificate authentication as primary, followed by essentially step-up to Duo, then that is easy. Use a protected object policy on the junction (or any other WebSEAL object space resource that you want to protected) with authentication levels, like:

pdadmin> pop create level2poppdadmin> pop modify level2pop set ipauth anyothernw 2pdadmin> pop attach /WebSEAL/<your_server>/<your jct> level2pop

In your  [authentication-levels] stanza, something like:

[authentication-levels]level = unauthenticatedlevel = ssllevel = ext-auth-interface

To redirect to your Duo Infomap for step-up authentication:

[acnt-mgt]enable-local-response-redirect = yes[local-response-redirect]local-response-redirect-uri = [stepup] /mga/sps/authsvc/policy/duoPolicy

And in the AuthSvcCredential mapping rule (included in AAC), which runs at the successful completion of any AAC authentication policy, add:

if (policyID.equals("urn:ibm:security:authentication:asf:duoPolicy")) {   stsuu.getAttributeContainer().setAttribute(new Attribute("AUTHENTICATION_LEVEL", null, "2"));}

If its not that exact combination, its close. Experiment.

------------------------------
Shane Weeden
IBM

Original Message:
Sent: Tue January 09, 2024 02:28 PM
From: Narayan Verma
Subject: Adding an infomap mechanism to the default login policy

Hi team, any isights or recommendations on this?

Thanks!

------------------------------
Narayan Verma

Original Message:
Sent: Mon January 08, 2024 10:56 AM
From: Narayan Verma
Subject: Adding an infomap mechanism to the default login policy

------------------------------
Narayan Verma
------------------------------

Thanks Shane, I got it to work with the following:

------------------------------
Narayan Verma

Original Message:
Sent: Wed January 10, 2024 07:40 PM
From: Shane Weeden
Subject: Adding an infomap mechanism to the default login policy

You do this exactly the same way I have described - use the building blocks I have provided to put your solution together. Step-up authentication is just a way of triggering another level of authentication (Duo, or certificate) after password authentication. So you'd start with something like:

[authentication-levels]level = unauthenticatedlevel = passwordlevel = ext-auth-interfacelevel = ext-ssl

In this case password=1, EAI=2 (this includes Duo), and certificates=3. You would still use level2pop to protect all resources that are of any value. Either level 2 or 3 satisifies this.

Then instead of just using local-response-redirect to redirect to Duo on step-up, take that out and allow WebSEAL to show the regular stepuplogin.html page. Modify WebSEAL to have:

[step-up]show-all-auth-prompts = yesstep-up-at-higher-level = yes

Code your "choices" of either Duo or certificates to be displayed to the user into stepuplogin.html with FORM actions pointing to each as appropriate.

------------------------------
Shane Weeden
IBM

Original Message:
Sent: Wed January 10, 2024 09:15 AM
From: Narayan Verma
Subject: Adding an infomap mechanism to the default login policy

Thanks Shane!

How do we achieve Duo authentication right after the user id/password authentication?  The current login screen - e.g. certlogin.html provides both userid/password authentication and certificate option.  What we want to do is to inject Duo right after the userid/password authentication if the user chooses that route.  If user goes for cert based authentication then Duo is not needed.  We want to do that as part of initial login not as part of step-up authentication.

Somewhat of a later concern, for step-up authentication for sensitive data applications is it possible to provide an option to the user of using (either Duo or Certificate) not just Duo-only or just Cert-only?

We are trying to treat Duo and cert as same level of authentications from strength perspective.  Our options for initial login are going to be either of a) Kerberos b) userid/password followed by Duo c) certificate.  For step-up they are going to be either of a) Duo b) certificate.  That's the desired end goal.  I am hoping it's not going to create any conflicts, lead to bad practices, or unsupportable configurations.

------------------------------
Narayan Verma

Original Message:
Sent: Wed January 10, 2024 01:36 AM
From: Shane Weeden
Subject: Adding an infomap mechanism to the default login policy

Certificate authentication happens at the transport layer directly to WebSEAL. It does not make sense that it would ever use an AAC/Infomap authentication policy. It might use an Infomap to do identity mapping for the certificate, but that's all.

If you want certificate authentication as primary, followed by essentially step-up to Duo, then that is easy. Use a protected object policy on the junction (or any other WebSEAL object space resource that you want to protected) with authentication levels, like:

pdadmin> pop create level2poppdadmin> pop modify level2pop set ipauth anyothernw 2pdadmin> pop attach /WebSEAL/<your_server>/<your jct> level2pop

In your  [authentication-levels] stanza, something like:

[authentication-levels]level = unauthenticatedlevel = ssllevel = ext-auth-interface

To redirect to your Duo Infomap for step-up authentication:

[acnt-mgt]enable-local-response-redirect = yes[local-response-redirect]local-response-redirect-uri = [stepup] /mga/sps/authsvc/policy/duoPolicy

And in the AuthSvcCredential mapping rule (included in AAC), which runs at the successful completion of any AAC authentication policy, add:

if (policyID.equals("urn:ibm:security:authentication:asf:duoPolicy")) {   stsuu.getAttributeContainer().setAttribute(new Attribute("AUTHENTICATION_LEVEL", null, "2"));}

If its not that exact combination, its close. Experiment.

------------------------------
Shane Weeden
IBM

Original Message:
Sent: Tue January 09, 2024 02:28 PM
From: Narayan Verma
Subject: Adding an infomap mechanism to the default login policy

Hi team, any isights or recommendations on this?

Thanks!

------------------------------
Narayan Verma

Original Message:
Sent: Mon January 08, 2024 10:56 AM
From: Narayan Verma
Subject: Adding an infomap mechanism to the default login policy

------------------------------
Narayan Verma
------------------------------

Read this: https://community.ibm.com/community/user/security/blogs/shane-weeden1/2020/03/18/protecting-entire-isam-webseal-site-with-multi-fac

It will resolve your issue with all-of-site protection with MFA.

Thanks Shane, I got it to work with the following:

------------------------------
Narayan Verma

Original Message:
Sent: Wed January 10, 2024 07:40 PM
From: Shane Weeden
Subject: Adding an infomap mechanism to the default login policy

You do this exactly the same way I have described - use the building blocks I have provided to put your solution together. Step-up authentication is just a way of triggering another level of authentication (Duo, or certificate) after password authentication. So you'd start with something like:

[authentication-levels]level = unauthenticatedlevel = passwordlevel = ext-auth-interfacelevel = ext-ssl

In this case password=1, EAI=2 (this includes Duo), and certificates=3. You would still use level2pop to protect all resources that are of any value. Either level 2 or 3 satisifies this.

Then instead of just using local-response-redirect to redirect to Duo on step-up, take that out and allow WebSEAL to show the regular stepuplogin.html page. Modify WebSEAL to have:

[step-up]show-all-auth-prompts = yesstep-up-at-higher-level = yes

Code your "choices" of either Duo or certificates to be displayed to the user into stepuplogin.html with FORM actions pointing to each as appropriate.

------------------------------
Shane Weeden
IBM

Original Message:
Sent: Wed January 10, 2024 09:15 AM
From: Narayan Verma
Subject: Adding an infomap mechanism to the default login policy

Thanks Shane!

How do we achieve Duo authentication right after the user id/password authentication?  The current login screen - e.g. certlogin.html provides both userid/password authentication and certificate option.  What we want to do is to inject Duo right after the userid/password authentication if the user chooses that route.  If user goes for cert based authentication then Duo is not needed.  We want to do that as part of initial login not as part of step-up authentication.

Somewhat of a later concern, for step-up authentication for sensitive data applications is it possible to provide an option to the user of using (either Duo or Certificate) not just Duo-only or just Cert-only?

We are trying to treat Duo and cert as same level of authentications from strength perspective.  Our options for initial login are going to be either of a) Kerberos b) userid/password followed by Duo c) certificate.  For step-up they are going to be either of a) Duo b) certificate.  That's the desired end goal.  I am hoping it's not going to create any conflicts, lead to bad practices, or unsupportable configurations.

------------------------------
Narayan Verma

Original Message:
Sent: Wed January 10, 2024 01:36 AM
From: Shane Weeden
Subject: Adding an infomap mechanism to the default login policy

Certificate authentication happens at the transport layer directly to WebSEAL. It does not make sense that it would ever use an AAC/Infomap authentication policy. It might use an Infomap to do identity mapping for the certificate, but that's all.

If you want certificate authentication as primary, followed by essentially step-up to Duo, then that is easy. Use a protected object policy on the junction (or any other WebSEAL object space resource that you want to protected) with authentication levels, like:

pdadmin> pop create level2poppdadmin> pop modify level2pop set ipauth anyothernw 2pdadmin> pop attach /WebSEAL/<your_server>/<your jct> level2pop

In your  [authentication-levels] stanza, something like:

[authentication-levels]level = unauthenticatedlevel = ssllevel = ext-auth-interface

To redirect to your Duo Infomap for step-up authentication:

[acnt-mgt]enable-local-response-redirect = yes[local-response-redirect]local-response-redirect-uri = [stepup] /mga/sps/authsvc/policy/duoPolicy

And in the AuthSvcCredential mapping rule (included in AAC), which runs at the successful completion of any AAC authentication policy, add:

if (policyID.equals("urn:ibm:security:authentication:asf:duoPolicy")) {   stsuu.getAttributeContainer().setAttribute(new Attribute("AUTHENTICATION_LEVEL", null, "2"));}

If its not that exact combination, its close. Experiment.

------------------------------
Shane Weeden
IBM

Original Message:
Sent: Tue January 09, 2024 02:28 PM
From: Narayan Verma
Subject: Adding an infomap mechanism to the default login policy

Hi team, any isights or recommendations on this?

Thanks!

------------------------------
Narayan Verma

Original Message:
Sent: Mon January 08, 2024 10:56 AM
From: Narayan Verma
Subject: Adding an infomap mechanism to the default login policy

------------------------------
Narayan Verma
------------------------------

Thank you Shane!  One thing I observed is that it's also trying to step-up the users authenticated using Kerberos.  Seems like those users get the AUTHENTICATION_LEVEL = 0 as seen in IVCREDS.  Can Kerberos be treated as if it's equivalent to (UID/PWD + Duo) or Certificate?

Thanks!

Read this: https://community.ibm.com/community/user/security/blogs/shane-weeden1/2020/03/18/protecting-entire-isam-webseal-site-with-multi-fac

It will resolve your issue with all-of-site protection with MFA.

Thanks Shane, I got it to work with the following:

------------------------------
Narayan Verma

Original Message:
Sent: Wed January 10, 2024 07:40 PM
From: Shane Weeden
Subject: Adding an infomap mechanism to the default login policy

You do this exactly the same way I have described - use the building blocks I have provided to put your solution together. Step-up authentication is just a way of triggering another level of authentication (Duo, or certificate) after password authentication. So you'd start with something like:

[authentication-levels]level = unauthenticatedlevel = passwordlevel = ext-auth-interfacelevel = ext-ssl

In this case password=1, EAI=2 (this includes Duo), and certificates=3. You would still use level2pop to protect all resources that are of any value. Either level 2 or 3 satisifies this.

Then instead of just using local-response-redirect to redirect to Duo on step-up, take that out and allow WebSEAL to show the regular stepuplogin.html page. Modify WebSEAL to have:

[step-up]show-all-auth-prompts = yesstep-up-at-higher-level = yes

Code your "choices" of either Duo or certificates to be displayed to the user into stepuplogin.html with FORM actions pointing to each as appropriate.

------------------------------
Shane Weeden
IBM

Original Message:
Sent: Wed January 10, 2024 09:15 AM
From: Narayan Verma
Subject: Adding an infomap mechanism to the default login policy

Thanks Shane!

How do we achieve Duo authentication right after the user id/password authentication?  The current login screen - e.g. certlogin.html provides both userid/password authentication and certificate option.  What we want to do is to inject Duo right after the userid/password authentication if the user chooses that route.  If user goes for cert based authentication then Duo is not needed.  We want to do that as part of initial login not as part of step-up authentication.

Somewhat of a later concern, for step-up authentication for sensitive data applications is it possible to provide an option to the user of using (either Duo or Certificate) not just Duo-only or just Cert-only?

We are trying to treat Duo and cert as same level of authentications from strength perspective.  Our options for initial login are going to be either of a) Kerberos b) userid/password followed by Duo c) certificate.  For step-up they are going to be either of a) Duo b) certificate.  That's the desired end goal.  I am hoping it's not going to create any conflicts, lead to bad practices, or unsupportable configurations.

------------------------------
Narayan Verma

Original Message:
Sent: Wed January 10, 2024 01:36 AM
From: Shane Weeden
Subject: Adding an infomap mechanism to the default login policy

Certificate authentication happens at the transport layer directly to WebSEAL. It does not make sense that it would ever use an AAC/Infomap authentication policy. It might use an Infomap to do identity mapping for the certificate, but that's all.

If you want certificate authentication as primary, followed by essentially step-up to Duo, then that is easy. Use a protected object policy on the junction (or any other WebSEAL object space resource that you want to protected) with authentication levels, like:

pdadmin> pop create level2poppdadmin> pop modify level2pop set ipauth anyothernw 2pdadmin> pop attach /WebSEAL/<your_server>/<your jct> level2pop

In your  [authentication-levels] stanza, something like:

[authentication-levels]level = unauthenticatedlevel = ssllevel = ext-auth-interface

To redirect to your Duo Infomap for step-up authentication:

[acnt-mgt]enable-local-response-redirect = yes[local-response-redirect]local-response-redirect-uri = [stepup] /mga/sps/authsvc/policy/duoPolicy

And in the AuthSvcCredential mapping rule (included in AAC), which runs at the successful completion of any AAC authentication policy, add:

if (policyID.equals("urn:ibm:security:authentication:asf:duoPolicy")) {   stsuu.getAttributeContainer().setAttribute(new Attribute("AUTHENTICATION_LEVEL", null, "2"));}

If its not that exact combination, its close. Experiment.

------------------------------
Shane Weeden
IBM

Original Message:
Sent: Tue January 09, 2024 02:28 PM
From: Narayan Verma
Subject: Adding an infomap mechanism to the default login policy

Hi team, any isights or recommendations on this?

Thanks!

------------------------------
Narayan Verma

Original Message:
Sent: Mon January 08, 2024 10:56 AM
From: Narayan Verma
Subject: Adding an infomap mechanism to the default login policy

------------------------------
Narayan Verma
------------------------------

That would be easy enough to do. There are probably a few ways. The one that comes to mind most readily and is most flexible is as follows.

1. Go back to using local-response-redirect for stepup login, sending the local-response-redirect for step-up to an Infomap based authentication policy.
2. Code the Infomap to see what is already in the users credentials - you'll be able to tell if they've already done Kerberos by looking at another stsuu attribute the the credential like AZN_CRED_AUTH_METHOD or similar.
3. If the user was already authenticated kerberos, just succeed the stepup immediately in the Infomap, raising their authentication level.
4. Otherwise send back a page template from Infomap which looks more or less like the exisiting WebSEAL stepuplogin.html and everything else there works as it currently does.

------------------------------
Shane Weeden
IBM

Original Message:
Sent: Thu January 11, 2024 04:37 PM
From: Narayan Verma
Subject: Adding an infomap mechanism to the default login policy

Thank you Shane!  One thing I observed is that it's also trying to step-up the users authenticated using Kerberos.  Seems like those users get the AUTHENTICATION_LEVEL = 0 as seen in IVCREDS.  Can Kerberos be treated as if it's equivalent to (UID/PWD + Duo) or Certificate?

Thanks!

------------------------------
Narayan Verma

Original Message:
Sent: Thu January 11, 2024 04:26 PM
From: Shane Weeden
Subject: Adding an infomap mechanism to the default login policy

Read this: https://community.ibm.com/community/user/security/blogs/shane-weeden1/2020/03/18/protecting-entire-isam-webseal-site-with-multi-fac

It will resolve your issue with all-of-site protection with MFA.

------------------------------
Shane Weeden
IBM

Original Message:
Sent: Thu January 11, 2024 12:32 PM
From: Narayan Verma
Subject: Adding an infomap mechanism to the default login policy

Thanks Shane, I got it to work with the following:

------------------------------
Narayan Verma

Original Message:
Sent: Wed January 10, 2024 07:40 PM
From: Shane Weeden
Subject: Adding an infomap mechanism to the default login policy

You do this exactly the same way I have described - use the building blocks I have provided to put your solution together. Step-up authentication is just a way of triggering another level of authentication (Duo, or certificate) after password authentication. So you'd start with something like:

[authentication-levels]level = unauthenticatedlevel = passwordlevel = ext-auth-interfacelevel = ext-ssl

In this case password=1, EAI=2 (this includes Duo), and certificates=3. You would still use level2pop to protect all resources that are of any value. Either level 2 or 3 satisifies this.

Then instead of just using local-response-redirect to redirect to Duo on step-up, take that out and allow WebSEAL to show the regular stepuplogin.html page. Modify WebSEAL to have:

[step-up]show-all-auth-prompts = yesstep-up-at-higher-level = yes

Code your "choices" of either Duo or certificates to be displayed to the user into stepuplogin.html with FORM actions pointing to each as appropriate.

------------------------------
Shane Weeden
IBM

Original Message:
Sent: Wed January 10, 2024 09:15 AM
From: Narayan Verma
Subject: Adding an infomap mechanism to the default login policy

Thanks Shane!

How do we achieve Duo authentication right after the user id/password authentication?  The current login screen - e.g. certlogin.html provides both userid/password authentication and certificate option.  What we want to do is to inject Duo right after the userid/password authentication if the user chooses that route.  If user goes for cert based authentication then Duo is not needed.  We want to do that as part of initial login not as part of step-up authentication.

Somewhat of a later concern, for step-up authentication for sensitive data applications is it possible to provide an option to the user of using (either Duo or Certificate) not just Duo-only or just Cert-only?

We are trying to treat Duo and cert as same level of authentications from strength perspective.  Our options for initial login are going to be either of a) Kerberos b) userid/password followed by Duo c) certificate.  For step-up they are going to be either of a) Duo b) certificate.  That's the desired end goal.  I am hoping it's not going to create any conflicts, lead to bad practices, or unsupportable configurations.

------------------------------
Narayan Verma

Original Message:
Sent: Wed January 10, 2024 01:36 AM
From: Shane Weeden
Subject: Adding an infomap mechanism to the default login policy

Certificate authentication happens at the transport layer directly to WebSEAL. It does not make sense that it would ever use an AAC/Infomap authentication policy. It might use an Infomap to do identity mapping for the certificate, but that's all.

If you want certificate authentication as primary, followed by essentially step-up to Duo, then that is easy. Use a protected object policy on the junction (or any other WebSEAL object space resource that you want to protected) with authentication levels, like:

pdadmin> pop create level2poppdadmin> pop modify level2pop set ipauth anyothernw 2pdadmin> pop attach /WebSEAL/<your_server>/<your jct> level2pop

In your  [authentication-levels] stanza, something like:

[authentication-levels]level = unauthenticatedlevel = ssllevel = ext-auth-interface

To redirect to your Duo Infomap for step-up authentication:

[acnt-mgt]enable-local-response-redirect = yes[local-response-redirect]local-response-redirect-uri = [stepup] /mga/sps/authsvc/policy/duoPolicy

And in the AuthSvcCredential mapping rule (included in AAC), which runs at the successful completion of any AAC authentication policy, add:

if (policyID.equals("urn:ibm:security:authentication:asf:duoPolicy")) {   stsuu.getAttributeContainer().setAttribute(new Attribute("AUTHENTICATION_LEVEL", null, "2"));}

If its not that exact combination, its close. Experiment.

------------------------------
Shane Weeden
IBM

Original Message:
Sent: Tue January 09, 2024 02:28 PM
From: Narayan Verma
Subject: Adding an infomap mechanism to the default login policy

Hi team, any isights or recommendations on this?

Thanks!

------------------------------
Narayan Verma

Original Message:
Sent: Mon January 08, 2024 10:56 AM
From: Narayan Verma
Subject: Adding an infomap mechanism to the default login policy

------------------------------
Narayan Verma
------------------------------

I am trying to test the new policy at /mga/sps/authsvc/policy/kbooster after doing a kerberos authentication directly and getting the following error:

"stsuu" is not defined.

The code snippet in my mapping rule is as below:

Getting similar error (stsuu is not defined) when the policy is being invoked in the step-up flow:  /mga/sps/authsvc/policy/kbooster?TAM_OP=stepup

My other question is if I copy the content from stepuplogin.html for this new template in booster when Kerberos is not present how do I supply the values for macros that are already present like %LANGUAGE%, %PKMSPUBLIC%, %MSG{0x3898370b}%, %MSG{0x3898370e}% etc.  I believe somehow the mapping rule needs to make it available to the template, they don't seem to be globally available for all templates.  A workaround could be hard coding the values so stsuu not being available in the mapping rule is the bigger problem.

Thanks!

------------------------------
Narayan Verma

Original Message:
Sent: Thu January 11, 2024 05:14 PM
From: Shane Weeden
Subject: Adding an infomap mechanism to the default login policy

That would be easy enough to do. There are probably a few ways. The one that comes to mind most readily and is most flexible is as follows.

1. Go back to using local-response-redirect for stepup login, sending the local-response-redirect for step-up to an Infomap based authentication policy.
2. Code the Infomap to see what is already in the users credentials - you'll be able to tell if they've already done Kerberos by looking at another stsuu attribute the the credential like AZN_CRED_AUTH_METHOD or similar.
3. If the user was already authenticated kerberos, just succeed the stepup immediately in the Infomap, raising their authentication level.
4. Otherwise send back a page template from Infomap which looks more or less like the exisiting WebSEAL stepuplogin.html and everything else there works as it currently does.

------------------------------
Shane Weeden
IBM

Original Message:
Sent: Thu January 11, 2024 04:37 PM
From: Narayan Verma
Subject: Adding an infomap mechanism to the default login policy

Thank you Shane!  One thing I observed is that it's also trying to step-up the users authenticated using Kerberos.  Seems like those users get the AUTHENTICATION_LEVEL = 0 as seen in IVCREDS.  Can Kerberos be treated as if it's equivalent to (UID/PWD + Duo) or Certificate?

Thanks!

------------------------------
Narayan Verma

Original Message:
Sent: Thu January 11, 2024 04:26 PM
From: Shane Weeden
Subject: Adding an infomap mechanism to the default login policy

Read this: https://community.ibm.com/community/user/security/blogs/shane-weeden1/2020/03/18/protecting-entire-isam-webseal-site-with-multi-fac

It will resolve your issue with all-of-site protection with MFA.

------------------------------
Shane Weeden
IBM

Original Message:
Sent: Thu January 11, 2024 12:32 PM
From: Narayan Verma
Subject: Adding an infomap mechanism to the default login policy

Thanks Shane, I got it to work with the following:

------------------------------
Narayan Verma

Original Message:
Sent: Wed January 10, 2024 07:40 PM
From: Shane Weeden
Subject: Adding an infomap mechanism to the default login policy

You do this exactly the same way I have described - use the building blocks I have provided to put your solution together. Step-up authentication is just a way of triggering another level of authentication (Duo, or certificate) after password authentication. So you'd start with something like:

[authentication-levels]level = unauthenticatedlevel = passwordlevel = ext-auth-interfacelevel = ext-ssl

In this case password=1, EAI=2 (this includes Duo), and certificates=3. You would still use level2pop to protect all resources that are of any value. Either level 2 or 3 satisifies this.

Then instead of just using local-response-redirect to redirect to Duo on step-up, take that out and allow WebSEAL to show the regular stepuplogin.html page. Modify WebSEAL to have:

[step-up]show-all-auth-prompts = yesstep-up-at-higher-level = yes

Code your "choices" of either Duo or certificates to be displayed to the user into stepuplogin.html with FORM actions pointing to each as appropriate.

------------------------------
Shane Weeden
IBM

Original Message:
Sent: Wed January 10, 2024 09:15 AM
From: Narayan Verma
Subject: Adding an infomap mechanism to the default login policy

Thanks Shane!

How do we achieve Duo authentication right after the user id/password authentication?  The current login screen - e.g. certlogin.html provides both userid/password authentication and certificate option.  What we want to do is to inject Duo right after the userid/password authentication if the user chooses that route.  If user goes for cert based authentication then Duo is not needed.  We want to do that as part of initial login not as part of step-up authentication.

Somewhat of a later concern, for step-up authentication for sensitive data applications is it possible to provide an option to the user of using (either Duo or Certificate) not just Duo-only or just Cert-only?

We are trying to treat Duo and cert as same level of authentications from strength perspective.  Our options for initial login are going to be either of a) Kerberos b) userid/password followed by Duo c) certificate.  For step-up they are going to be either of a) Duo b) certificate.  That's the desired end goal.  I am hoping it's not going to create any conflicts, lead to bad practices, or unsupportable configurations.

------------------------------
Narayan Verma

Original Message:
Sent: Wed January 10, 2024 01:36 AM
From: Shane Weeden
Subject: Adding an infomap mechanism to the default login policy

Certificate authentication happens at the transport layer directly to WebSEAL. It does not make sense that it would ever use an AAC/Infomap authentication policy. It might use an Infomap to do identity mapping for the certificate, but that's all.

If you want certificate authentication as primary, followed by essentially step-up to Duo, then that is easy. Use a protected object policy on the junction (or any other WebSEAL object space resource that you want to protected) with authentication levels, like:

pdadmin> pop create level2poppdadmin> pop modify level2pop set ipauth anyothernw 2pdadmin> pop attach /WebSEAL/<your_server>/<your jct> level2pop

In your  [authentication-levels] stanza, something like:

[authentication-levels]level = unauthenticatedlevel = ssllevel = ext-auth-interface

To redirect to your Duo Infomap for step-up authentication:

[acnt-mgt]enable-local-response-redirect = yes[local-response-redirect]local-response-redirect-uri = [stepup] /mga/sps/authsvc/policy/duoPolicy

And in the AuthSvcCredential mapping rule (included in AAC), which runs at the successful completion of any AAC authentication policy, add:

if (policyID.equals("urn:ibm:security:authentication:asf:duoPolicy")) {   stsuu.getAttributeContainer().setAttribute(new Attribute("AUTHENTICATION_LEVEL", null, "2"));}

If its not that exact combination, its close. Experiment.

------------------------------
Shane Weeden
IBM

Original Message:
Sent: Tue January 09, 2024 02:28 PM
From: Narayan Verma
Subject: Adding an infomap mechanism to the default login policy

Hi team, any isights or recommendations on this?

Thanks!

------------------------------
Narayan Verma

Original Message:
Sent: Mon January 08, 2024 10:56 AM
From: Narayan Verma
Subject: Adding an infomap mechanism to the default login policy

------------------------------
Narayan Verma
------------------------------

No it's not and never has been. There are alternative APIs for accessing credential attributes in an Infomap. Google up examples or look through my blog articles. There's plenty of existing information available. 

I am trying to test the new policy at /mga/sps/authsvc/policy/kbooster after doing a kerberos authentication directly and getting the following error:

"stsuu" is not defined.

The code snippet in my mapping rule is as below:

Getting similar error (stsuu is not defined) when the policy is being invoked in the step-up flow:  /mga/sps/authsvc/policy/kbooster?TAM_OP=stepup

My other question is if I copy the content from stepuplogin.html for this new template in booster when Kerberos is not present how do I supply the values for macros that are already present like %LANGUAGE%, %PKMSPUBLIC%, %MSG{0x3898370b}%, %MSG{0x3898370e}% etc.  I believe somehow the mapping rule needs to make it available to the template, they don't seem to be globally available for all templates.  A workaround could be hard coding the values so stsuu not being available in the mapping rule is the bigger problem.

Thanks!

------------------------------
Narayan Verma

Original Message:
Sent: Thu January 11, 2024 05:14 PM
From: Shane Weeden
Subject: Adding an infomap mechanism to the default login policy

That would be easy enough to do. There are probably a few ways. The one that comes to mind most readily and is most flexible is as follows.

1. Go back to using local-response-redirect for stepup login, sending the local-response-redirect for step-up to an Infomap based authentication policy.
2. Code the Infomap to see what is already in the users credentials - you'll be able to tell if they've already done Kerberos by looking at another stsuu attribute the the credential like AZN_CRED_AUTH_METHOD or similar.
3. If the user was already authenticated kerberos, just succeed the stepup immediately in the Infomap, raising their authentication level.
4. Otherwise send back a page template from Infomap which looks more or less like the exisiting WebSEAL stepuplogin.html and everything else there works as it currently does.

------------------------------
Shane Weeden
IBM

Original Message:
Sent: Thu January 11, 2024 04:37 PM
From: Narayan Verma
Subject: Adding an infomap mechanism to the default login policy

Thank you Shane!  One thing I observed is that it's also trying to step-up the users authenticated using Kerberos.  Seems like those users get the AUTHENTICATION_LEVEL = 0 as seen in IVCREDS.  Can Kerberos be treated as if it's equivalent to (UID/PWD + Duo) or Certificate?

Thanks!

------------------------------
Narayan Verma

Original Message:
Sent: Thu January 11, 2024 04:26 PM
From: Shane Weeden
Subject: Adding an infomap mechanism to the default login policy

Read this: https://community.ibm.com/community/user/security/blogs/shane-weeden1/2020/03/18/protecting-entire-isam-webseal-site-with-multi-fac

It will resolve your issue with all-of-site protection with MFA.

------------------------------
Shane Weeden
IBM

Original Message:
Sent: Thu January 11, 2024 12:32 PM
From: Narayan Verma
Subject: Adding an infomap mechanism to the default login policy

Thanks Shane, I got it to work with the following:

------------------------------
Narayan Verma

Original Message:
Sent: Wed January 10, 2024 07:40 PM
From: Shane Weeden
Subject: Adding an infomap mechanism to the default login policy

You do this exactly the same way I have described - use the building blocks I have provided to put your solution together. Step-up authentication is just a way of triggering another level of authentication (Duo, or certificate) after password authentication. So you'd start with something like:

[authentication-levels]level = unauthenticatedlevel = passwordlevel = ext-auth-interfacelevel = ext-ssl

In this case password=1, EAI=2 (this includes Duo), and certificates=3. You would still use level2pop to protect all resources that are of any value. Either level 2 or 3 satisifies this.

Then instead of just using local-response-redirect to redirect to Duo on step-up, take that out and allow WebSEAL to show the regular stepuplogin.html page. Modify WebSEAL to have:

[step-up]show-all-auth-prompts = yesstep-up-at-higher-level = yes

Code your "choices" of either Duo or certificates to be displayed to the user into stepuplogin.html with FORM actions pointing to each as appropriate.

------------------------------
Shane Weeden
IBM

Original Message:
Sent: Wed January 10, 2024 09:15 AM
From: Narayan Verma
Subject: Adding an infomap mechanism to the default login policy

Thanks Shane!

How do we achieve Duo authentication right after the user id/password authentication?  The current login screen - e.g. certlogin.html provides both userid/password authentication and certificate option.  What we want to do is to inject Duo right after the userid/password authentication if the user chooses that route.  If user goes for cert based authentication then Duo is not needed.  We want to do that as part of initial login not as part of step-up authentication.

Somewhat of a later concern, for step-up authentication for sensitive data applications is it possible to provide an option to the user of using (either Duo or Certificate) not just Duo-only or just Cert-only?

We are trying to treat Duo and cert as same level of authentications from strength perspective.  Our options for initial login are going to be either of a) Kerberos b) userid/password followed by Duo c) certificate.  For step-up they are going to be either of a) Duo b) certificate.  That's the desired end goal.  I am hoping it's not going to create any conflicts, lead to bad practices, or unsupportable configurations.

------------------------------
Narayan Verma

Original Message:
Sent: Wed January 10, 2024 01:36 AM
From: Shane Weeden
Subject: Adding an infomap mechanism to the default login policy

Certificate authentication happens at the transport layer directly to WebSEAL. It does not make sense that it would ever use an AAC/Infomap authentication policy. It might use an Infomap to do identity mapping for the certificate, but that's all.

If you want certificate authentication as primary, followed by essentially step-up to Duo, then that is easy. Use a protected object policy on the junction (or any other WebSEAL object space resource that you want to protected) with authentication levels, like:

pdadmin> pop create level2poppdadmin> pop modify level2pop set ipauth anyothernw 2pdadmin> pop attach /WebSEAL/<your_server>/<your jct> level2pop

In your  [authentication-levels] stanza, something like:

[authentication-levels]level = unauthenticatedlevel = ssllevel = ext-auth-interface

To redirect to your Duo Infomap for step-up authentication:

[acnt-mgt]enable-local-response-redirect = yes[local-response-redirect]local-response-redirect-uri = [stepup] /mga/sps/authsvc/policy/duoPolicy

And in the AuthSvcCredential mapping rule (included in AAC), which runs at the successful completion of any AAC authentication policy, add:

if (policyID.equals("urn:ibm:security:authentication:asf:duoPolicy")) {   stsuu.getAttributeContainer().setAttribute(new Attribute("AUTHENTICATION_LEVEL", null, "2"));}

If its not that exact combination, its close. Experiment.

------------------------------
Shane Weeden
IBM

Original Message:
Sent: Tue January 09, 2024 02:28 PM
From: Narayan Verma
Subject: Adding an infomap mechanism to the default login policy

Hi team, any isights or recommendations on this?

Thanks!

------------------------------
Narayan Verma

Original Message:
Sent: Mon January 08, 2024 10:56 AM
From: Narayan Verma
Subject: Adding an infomap mechanism to the default login policy

------------------------------
Narayan Verma
------------------------------

Thanks Shane, I tried the below and it worked:

No it's not and never has been. There are alternative APIs for accessing credential attributes in an Infomap. Google up examples or look through my blog articles. There's plenty of existing information available. 

I am trying to test the new policy at /mga/sps/authsvc/policy/kbooster after doing a kerberos authentication directly and getting the following error:

"stsuu" is not defined.

The code snippet in my mapping rule is as below:

Getting similar error (stsuu is not defined) when the policy is being invoked in the step-up flow:  /mga/sps/authsvc/policy/kbooster?TAM_OP=stepup

My other question is if I copy the content from stepuplogin.html for this new template in booster when Kerberos is not present how do I supply the values for macros that are already present like %LANGUAGE%, %PKMSPUBLIC%, %MSG{0x3898370b}%, %MSG{0x3898370e}% etc.  I believe somehow the mapping rule needs to make it available to the template, they don't seem to be globally available for all templates.  A workaround could be hard coding the values so stsuu not being available in the mapping rule is the bigger problem.

Thanks!

------------------------------
Narayan Verma

Original Message:
Sent: Thu January 11, 2024 05:14 PM
From: Shane Weeden
Subject: Adding an infomap mechanism to the default login policy

That would be easy enough to do. There are probably a few ways. The one that comes to mind most readily and is most flexible is as follows.

1. Go back to using local-response-redirect for stepup login, sending the local-response-redirect for step-up to an Infomap based authentication policy.
2. Code the Infomap to see what is already in the users credentials - you'll be able to tell if they've already done Kerberos by looking at another stsuu attribute the the credential like AZN_CRED_AUTH_METHOD or similar.
3. If the user was already authenticated kerberos, just succeed the stepup immediately in the Infomap, raising their authentication level.
4. Otherwise send back a page template from Infomap which looks more or less like the exisiting WebSEAL stepuplogin.html and everything else there works as it currently does.

------------------------------
Shane Weeden
IBM

Original Message:
Sent: Thu January 11, 2024 04:37 PM
From: Narayan Verma
Subject: Adding an infomap mechanism to the default login policy

Thank you Shane!  One thing I observed is that it's also trying to step-up the users authenticated using Kerberos.  Seems like those users get the AUTHENTICATION_LEVEL = 0 as seen in IVCREDS.  Can Kerberos be treated as if it's equivalent to (UID/PWD + Duo) or Certificate?

Thanks!

------------------------------
Narayan Verma

Original Message:
Sent: Thu January 11, 2024 04:26 PM
From: Shane Weeden
Subject: Adding an infomap mechanism to the default login policy

Read this: https://community.ibm.com/community/user/security/blogs/shane-weeden1/2020/03/18/protecting-entire-isam-webseal-site-with-multi-fac

It will resolve your issue with all-of-site protection with MFA.

------------------------------
Shane Weeden
IBM

Original Message:
Sent: Thu January 11, 2024 12:32 PM
From: Narayan Verma
Subject: Adding an infomap mechanism to the default login policy

Thanks Shane, I got it to work with the following:

------------------------------
Narayan Verma

Original Message:
Sent: Wed January 10, 2024 07:40 PM
From: Shane Weeden
Subject: Adding an infomap mechanism to the default login policy

You do this exactly the same way I have described - use the building blocks I have provided to put your solution together. Step-up authentication is just a way of triggering another level of authentication (Duo, or certificate) after password authentication. So you'd start with something like:

[authentication-levels]level = unauthenticatedlevel = passwordlevel = ext-auth-interfacelevel = ext-ssl

In this case password=1, EAI=2 (this includes Duo), and certificates=3. You would still use level2pop to protect all resources that are of any value. Either level 2 or 3 satisifies this.

Then instead of just using local-response-redirect to redirect to Duo on step-up, take that out and allow WebSEAL to show the regular stepuplogin.html page. Modify WebSEAL to have:

[step-up]show-all-auth-prompts = yesstep-up-at-higher-level = yes

Code your "choices" of either Duo or certificates to be displayed to the user into stepuplogin.html with FORM actions pointing to each as appropriate.

------------------------------
Shane Weeden
IBM

Original Message:
Sent: Wed January 10, 2024 09:15 AM
From: Narayan Verma
Subject: Adding an infomap mechanism to the default login policy

Thanks Shane!

How do we achieve Duo authentication right after the user id/password authentication?  The current login screen - e.g. certlogin.html provides both userid/password authentication and certificate option.  What we want to do is to inject Duo right after the userid/password authentication if the user chooses that route.  If user goes for cert based authentication then Duo is not needed.  We want to do that as part of initial login not as part of step-up authentication.

Somewhat of a later concern, for step-up authentication for sensitive data applications is it possible to provide an option to the user of using (either Duo or Certificate) not just Duo-only or just Cert-only?

We are trying to treat Duo and cert as same level of authentications from strength perspective.  Our options for initial login are going to be either of a) Kerberos b) userid/password followed by Duo c) certificate.  For step-up they are going to be either of a) Duo b) certificate.  That's the desired end goal.  I am hoping it's not going to create any conflicts, lead to bad practices, or unsupportable configurations.

------------------------------
Narayan Verma

Original Message:
Sent: Wed January 10, 2024 01:36 AM
From: Shane Weeden
Subject: Adding an infomap mechanism to the default login policy

Certificate authentication happens at the transport layer directly to WebSEAL. It does not make sense that it would ever use an AAC/Infomap authentication policy. It might use an Infomap to do identity mapping for the certificate, but that's all.

If you want certificate authentication as primary, followed by essentially step-up to Duo, then that is easy. Use a protected object policy on the junction (or any other WebSEAL object space resource that you want to protected) with authentication levels, like:

pdadmin> pop create level2poppdadmin> pop modify level2pop set ipauth anyothernw 2pdadmin> pop attach /WebSEAL/<your_server>/<your jct> level2pop

In your  [authentication-levels] stanza, something like:

[authentication-levels]level = unauthenticatedlevel = ssllevel = ext-auth-interface

To redirect to your Duo Infomap for step-up authentication:

[acnt-mgt]enable-local-response-redirect = yes[local-response-redirect]local-response-redirect-uri = [stepup] /mga/sps/authsvc/policy/duoPolicy

And in the AuthSvcCredential mapping rule (included in AAC), which runs at the successful completion of any AAC authentication policy, add:

if (policyID.equals("urn:ibm:security:authentication:asf:duoPolicy")) {   stsuu.getAttributeContainer().setAttribute(new Attribute("AUTHENTICATION_LEVEL", null, "2"));}

If its not that exact combination, its close. Experiment.

------------------------------
Shane Weeden
IBM

Original Message:
Sent: Tue January 09, 2024 02:28 PM
From: Narayan Verma
Subject: Adding an infomap mechanism to the default login policy

Hi team, any isights or recommendations on this?

Thanks!

------------------------------
Narayan Verma

Original Message:
Sent: Mon January 08, 2024 10:56 AM
From: Narayan Verma
Subject: Adding an infomap mechanism to the default login policy

------------------------------
Narayan Verma
------------------------------

Sounds good. 

------------------------------
Shane Weeden
IBM

Original Message:
Sent: Sat January 13, 2024 10:31 AM
From: Narayan Verma
Subject: Adding an infomap mechanism to the default login policy

Thanks Shane, I tried the below and it worked:

------------------------------
Narayan Verma

Original Message:
Sent: Sat January 13, 2024 03:26 AM
From: Shane Weeden
Subject: Adding an infomap mechanism to the default login policy

No it's not and never has been. There are alternative APIs for accessing credential attributes in an Infomap. Google up examples or look through my blog articles. There's plenty of existing information available. 

------------------------------
Shane Weeden
IBM

Original Message:
Sent: Fri January 12, 2024 11:45 AM
From: Narayan Verma
Subject: Adding an infomap mechanism to the default login policy

I am trying to test the new policy at /mga/sps/authsvc/policy/kbooster after doing a kerberos authentication directly and getting the following error:

"stsuu" is not defined.

The code snippet in my mapping rule is as below:

Getting similar error (stsuu is not defined) when the policy is being invoked in the step-up flow:  /mga/sps/authsvc/policy/kbooster?TAM_OP=stepup

My other question is if I copy the content from stepuplogin.html for this new template in booster when Kerberos is not present how do I supply the values for macros that are already present like %LANGUAGE%, %PKMSPUBLIC%, %MSG{0x3898370b}%, %MSG{0x3898370e}% etc.  I believe somehow the mapping rule needs to make it available to the template, they don't seem to be globally available for all templates.  A workaround could be hard coding the values so stsuu not being available in the mapping rule is the bigger problem.

Thanks!

------------------------------
Narayan Verma

Original Message:
Sent: Thu January 11, 2024 05:14 PM
From: Shane Weeden
Subject: Adding an infomap mechanism to the default login policy

That would be easy enough to do. There are probably a few ways. The one that comes to mind most readily and is most flexible is as follows.

1. Go back to using local-response-redirect for stepup login, sending the local-response-redirect for step-up to an Infomap based authentication policy.
2. Code the Infomap to see what is already in the users credentials - you'll be able to tell if they've already done Kerberos by looking at another stsuu attribute the the credential like AZN_CRED_AUTH_METHOD or similar.
3. If the user was already authenticated kerberos, just succeed the stepup immediately in the Infomap, raising their authentication level.
4. Otherwise send back a page template from Infomap which looks more or less like the exisiting WebSEAL stepuplogin.html and everything else there works as it currently does.

------------------------------
Shane Weeden
IBM

Original Message:
Sent: Thu January 11, 2024 04:37 PM
From: Narayan Verma
Subject: Adding an infomap mechanism to the default login policy

Thank you Shane!  One thing I observed is that it's also trying to step-up the users authenticated using Kerberos.  Seems like those users get the AUTHENTICATION_LEVEL = 0 as seen in IVCREDS.  Can Kerberos be treated as if it's equivalent to (UID/PWD + Duo) or Certificate?

Thanks!

------------------------------
Narayan Verma

Original Message:
Sent: Thu January 11, 2024 04:26 PM
From: Shane Weeden
Subject: Adding an infomap mechanism to the default login policy

Read this: https://community.ibm.com/community/user/security/blogs/shane-weeden1/2020/03/18/protecting-entire-isam-webseal-site-with-multi-fac

It will resolve your issue with all-of-site protection with MFA.

------------------------------
Shane Weeden
IBM

Original Message:
Sent: Thu January 11, 2024 12:32 PM
From: Narayan Verma
Subject: Adding an infomap mechanism to the default login policy

Thanks Shane, I got it to work with the following:

------------------------------
Narayan Verma

Original Message:
Sent: Wed January 10, 2024 07:40 PM
From: Shane Weeden
Subject: Adding an infomap mechanism to the default login policy

You do this exactly the same way I have described - use the building blocks I have provided to put your solution together. Step-up authentication is just a way of triggering another level of authentication (Duo, or certificate) after password authentication. So you'd start with something like:

[authentication-levels]level = unauthenticatedlevel = passwordlevel = ext-auth-interfacelevel = ext-ssl

In this case password=1, EAI=2 (this includes Duo), and certificates=3. You would still use level2pop to protect all resources that are of any value. Either level 2 or 3 satisifies this.

Then instead of just using local-response-redirect to redirect to Duo on step-up, take that out and allow WebSEAL to show the regular stepuplogin.html page. Modify WebSEAL to have:

[step-up]show-all-auth-prompts = yesstep-up-at-higher-level = yes

Code your "choices" of either Duo or certificates to be displayed to the user into stepuplogin.html with FORM actions pointing to each as appropriate.

------------------------------
Shane Weeden
IBM

Original Message:
Sent: Wed January 10, 2024 09:15 AM
From: Narayan Verma
Subject: Adding an infomap mechanism to the default login policy

Thanks Shane!

How do we achieve Duo authentication right after the user id/password authentication?  The current login screen - e.g. certlogin.html provides both userid/password authentication and certificate option.  What we want to do is to inject Duo right after the userid/password authentication if the user chooses that route.  If user goes for cert based authentication then Duo is not needed.  We want to do that as part of initial login not as part of step-up authentication.

Somewhat of a later concern, for step-up authentication for sensitive data applications is it possible to provide an option to the user of using (either Duo or Certificate) not just Duo-only or just Cert-only?

We are trying to treat Duo and cert as same level of authentications from strength perspective.  Our options for initial login are going to be either of a) Kerberos b) userid/password followed by Duo c) certificate.  For step-up they are going to be either of a) Duo b) certificate.  That's the desired end goal.  I am hoping it's not going to create any conflicts, lead to bad practices, or unsupportable configurations.

------------------------------
Narayan Verma

Original Message:
Sent: Wed January 10, 2024 01:36 AM
From: Shane Weeden
Subject: Adding an infomap mechanism to the default login policy

Certificate authentication happens at the transport layer directly to WebSEAL. It does not make sense that it would ever use an AAC/Infomap authentication policy. It might use an Infomap to do identity mapping for the certificate, but that's all.

If you want certificate authentication as primary, followed by essentially step-up to Duo, then that is easy. Use a protected object policy on the junction (or any other WebSEAL object space resource that you want to protected) with authentication levels, like:

pdadmin> pop create level2poppdadmin> pop modify level2pop set ipauth anyothernw 2pdadmin> pop attach /WebSEAL/<your_server>/<your jct> level2pop

In your  [authentication-levels] stanza, something like:

[authentication-levels]level = unauthenticatedlevel = ssllevel = ext-auth-interface

To redirect to your Duo Infomap for step-up authentication:

[acnt-mgt]enable-local-response-redirect = yes[local-response-redirect]local-response-redirect-uri = [stepup] /mga/sps/authsvc/policy/duoPolicy

And in the AuthSvcCredential mapping rule (included in AAC), which runs at the successful completion of any AAC authentication policy, add:

if (policyID.equals("urn:ibm:security:authentication:asf:duoPolicy")) {   stsuu.getAttributeContainer().setAttribute(new Attribute("AUTHENTICATION_LEVEL", null, "2"));}

If its not that exact combination, its close. Experiment.

------------------------------
Shane Weeden
IBM

Original Message:
Sent: Tue January 09, 2024 02:28 PM
From: Narayan Verma
Subject: Adding an infomap mechanism to the default login policy

Hi team, any isights or recommendations on this?

Thanks!

------------------------------
Narayan Verma

Original Message:
Sent: Mon January 08, 2024 10:56 AM
From: Narayan Verma
Subject: Adding an infomap mechanism to the default login policy

------------------------------
Narayan Verma
------------------------------

------------------------------
Narayan Verma

Original Message:
Sent: Sat January 13, 2024 03:44 PM
From: Shane Weeden
Subject: Adding an infomap mechanism to the default login policy

Sounds good. 

------------------------------
Shane Weeden
IBM

Original Message:
Sent: Sat January 13, 2024 10:31 AM
From: Narayan Verma
Subject: Adding an infomap mechanism to the default login policy

Thanks Shane, I tried the below and it worked:

------------------------------
Narayan Verma

Original Message:
Sent: Sat January 13, 2024 03:26 AM
From: Shane Weeden
Subject: Adding an infomap mechanism to the default login policy

No it's not and never has been. There are alternative APIs for accessing credential attributes in an Infomap. Google up examples or look through my blog articles. There's plenty of existing information available. 

------------------------------
Shane Weeden
IBM

Original Message:
Sent: Fri January 12, 2024 11:45 AM
From: Narayan Verma
Subject: Adding an infomap mechanism to the default login policy

I am trying to test the new policy at /mga/sps/authsvc/policy/kbooster after doing a kerberos authentication directly and getting the following error:

"stsuu" is not defined.

The code snippet in my mapping rule is as below:

Getting similar error (stsuu is not defined) when the policy is being invoked in the step-up flow:  /mga/sps/authsvc/policy/kbooster?TAM_OP=stepup

My other question is if I copy the content from stepuplogin.html for this new template in booster when Kerberos is not present how do I supply the values for macros that are already present like %LANGUAGE%, %PKMSPUBLIC%, %MSG{0x3898370b}%, %MSG{0x3898370e}% etc.  I believe somehow the mapping rule needs to make it available to the template, they don't seem to be globally available for all templates.  A workaround could be hard coding the values so stsuu not being available in the mapping rule is the bigger problem.

Thanks!

------------------------------
Narayan Verma

Original Message:
Sent: Thu January 11, 2024 05:14 PM
From: Shane Weeden
Subject: Adding an infomap mechanism to the default login policy

That would be easy enough to do. There are probably a few ways. The one that comes to mind most readily and is most flexible is as follows.

1. Go back to using local-response-redirect for stepup login, sending the local-response-redirect for step-up to an Infomap based authentication policy.
2. Code the Infomap to see what is already in the users credentials - you'll be able to tell if they've already done Kerberos by looking at another stsuu attribute the the credential like AZN_CRED_AUTH_METHOD or similar.
3. If the user was already authenticated kerberos, just succeed the stepup immediately in the Infomap, raising their authentication level.
4. Otherwise send back a page template from Infomap which looks more or less like the exisiting WebSEAL stepuplogin.html and everything else there works as it currently does.

------------------------------
Shane Weeden
IBM

Original Message:
Sent: Thu January 11, 2024 04:37 PM
From: Narayan Verma
Subject: Adding an infomap mechanism to the default login policy

Thank you Shane!  One thing I observed is that it's also trying to step-up the users authenticated using Kerberos.  Seems like those users get the AUTHENTICATION_LEVEL = 0 as seen in IVCREDS.  Can Kerberos be treated as if it's equivalent to (UID/PWD + Duo) or Certificate?

Thanks!

------------------------------
Narayan Verma

Original Message:
Sent: Thu January 11, 2024 04:26 PM
From: Shane Weeden
Subject: Adding an infomap mechanism to the default login policy

Read this: https://community.ibm.com/community/user/security/blogs/shane-weeden1/2020/03/18/protecting-entire-isam-webseal-site-with-multi-fac

It will resolve your issue with all-of-site protection with MFA.

------------------------------
Shane Weeden
IBM

Original Message:
Sent: Thu January 11, 2024 12:32 PM
From: Narayan Verma
Subject: Adding an infomap mechanism to the default login policy

Thanks Shane, I got it to work with the following:

------------------------------
Narayan Verma

Original Message:
Sent: Wed January 10, 2024 07:40 PM
From: Shane Weeden
Subject: Adding an infomap mechanism to the default login policy

You do this exactly the same way I have described - use the building blocks I have provided to put your solution together. Step-up authentication is just a way of triggering another level of authentication (Duo, or certificate) after password authentication. So you'd start with something like:

[authentication-levels]level = unauthenticatedlevel = passwordlevel = ext-auth-interfacelevel = ext-ssl

In this case password=1, EAI=2 (this includes Duo), and certificates=3. You would still use level2pop to protect all resources that are of any value. Either level 2 or 3 satisifies this.

Then instead of just using local-response-redirect to redirect to Duo on step-up, take that out and allow WebSEAL to show the regular stepuplogin.html page. Modify WebSEAL to have:

[step-up]show-all-auth-prompts = yesstep-up-at-higher-level = yes

Code your "choices" of either Duo or certificates to be displayed to the user into stepuplogin.html with FORM actions pointing to each as appropriate.

------------------------------
Shane Weeden
IBM

Original Message:
Sent: Wed January 10, 2024 09:15 AM
From: Narayan Verma
Subject: Adding an infomap mechanism to the default login policy

Thanks Shane!

How do we achieve Duo authentication right after the user id/password authentication?  The current login screen - e.g. certlogin.html provides both userid/password authentication and certificate option.  What we want to do is to inject Duo right after the userid/password authentication if the user chooses that route.  If user goes for cert based authentication then Duo is not needed.  We want to do that as part of initial login not as part of step-up authentication.

Somewhat of a later concern, for step-up authentication for sensitive data applications is it possible to provide an option to the user of using (either Duo or Certificate) not just Duo-only or just Cert-only?

We are trying to treat Duo and cert as same level of authentications from strength perspective.  Our options for initial login are going to be either of a) Kerberos b) userid/password followed by Duo c) certificate.  For step-up they are going to be either of a) Duo b) certificate.  That's the desired end goal.  I am hoping it's not going to create any conflicts, lead to bad practices, or unsupportable configurations.

------------------------------
Narayan Verma

Original Message:
Sent: Wed January 10, 2024 01:36 AM
From: Shane Weeden
Subject: Adding an infomap mechanism to the default login policy

Certificate authentication happens at the transport layer directly to WebSEAL. It does not make sense that it would ever use an AAC/Infomap authentication policy. It might use an Infomap to do identity mapping for the certificate, but that's all.

If you want certificate authentication as primary, followed by essentially step-up to Duo, then that is easy. Use a protected object policy on the junction (or any other WebSEAL object space resource that you want to protected) with authentication levels, like:

pdadmin> pop create level2poppdadmin> pop modify level2pop set ipauth anyothernw 2pdadmin> pop attach /WebSEAL/<your_server>/<your jct> level2pop

In your  [authentication-levels] stanza, something like:

[authentication-levels]level = unauthenticatedlevel = ssllevel = ext-auth-interface

To redirect to your Duo Infomap for step-up authentication:

[acnt-mgt]enable-local-response-redirect = yes[local-response-redirect]local-response-redirect-uri = [stepup] /mga/sps/authsvc/policy/duoPolicy

And in the AuthSvcCredential mapping rule (included in AAC), which runs at the successful completion of any AAC authentication policy, add:

if (policyID.equals("urn:ibm:security:authentication:asf:duoPolicy")) {   stsuu.getAttributeContainer().setAttribute(new Attribute("AUTHENTICATION_LEVEL", null, "2"));}

If its not that exact combination, its close. Experiment.

------------------------------
Shane Weeden
IBM

Original Message:
Sent: Tue January 09, 2024 02:28 PM
From: Narayan Verma
Subject: Adding an infomap mechanism to the default login policy

Hi team, any isights or recommendations on this?

Thanks!

------------------------------
Narayan Verma

Original Message:
Sent: Mon January 08, 2024 10:56 AM
From: Narayan Verma
Subject: Adding an infomap mechanism to the default login policy

------------------------------
Narayan Verma
------------------------------

Can't you do something simple like detect this  error code in client side JavaScript and show the regular u/p prompt in that case?

------------------------------
Narayan Verma

Original Message:
Sent: Sat January 13, 2024 03:44 PM
From: Shane Weeden
Subject: Adding an infomap mechanism to the default login policy

Sounds good. 

------------------------------
Shane Weeden
IBM

Original Message:
Sent: Sat January 13, 2024 10:31 AM
From: Narayan Verma
Subject: Adding an infomap mechanism to the default login policy

Thanks Shane, I tried the below and it worked:

------------------------------
Narayan Verma

Original Message:
Sent: Sat January 13, 2024 03:26 AM
From: Shane Weeden
Subject: Adding an infomap mechanism to the default login policy

No it's not and never has been. There are alternative APIs for accessing credential attributes in an Infomap. Google up examples or look through my blog articles. There's plenty of existing information available. 

------------------------------
Shane Weeden
IBM

Original Message:
Sent: Fri January 12, 2024 11:45 AM
From: Narayan Verma
Subject: Adding an infomap mechanism to the default login policy

I am trying to test the new policy at /mga/sps/authsvc/policy/kbooster after doing a kerberos authentication directly and getting the following error:

"stsuu" is not defined.

The code snippet in my mapping rule is as below:

Getting similar error (stsuu is not defined) when the policy is being invoked in the step-up flow:  /mga/sps/authsvc/policy/kbooster?TAM_OP=stepup

My other question is if I copy the content from stepuplogin.html for this new template in booster when Kerberos is not present how do I supply the values for macros that are already present like %LANGUAGE%, %PKMSPUBLIC%, %MSG{0x3898370b}%, %MSG{0x3898370e}% etc.  I believe somehow the mapping rule needs to make it available to the template, they don't seem to be globally available for all templates.  A workaround could be hard coding the values so stsuu not being available in the mapping rule is the bigger problem.

Thanks!

------------------------------
Narayan Verma

Original Message:
Sent: Thu January 11, 2024 05:14 PM
From: Shane Weeden
Subject: Adding an infomap mechanism to the default login policy

That would be easy enough to do. There are probably a few ways. The one that comes to mind most readily and is most flexible is as follows.

1. Go back to using local-response-redirect for stepup login, sending the local-response-redirect for step-up to an Infomap based authentication policy.
2. Code the Infomap to see what is already in the users credentials - you'll be able to tell if they've already done Kerberos by looking at another stsuu attribute the the credential like AZN_CRED_AUTH_METHOD or similar.
3. If the user was already authenticated kerberos, just succeed the stepup immediately in the Infomap, raising their authentication level.
4. Otherwise send back a page template from Infomap which looks more or less like the exisiting WebSEAL stepuplogin.html and everything else there works as it currently does.

------------------------------
Shane Weeden
IBM

Original Message:
Sent: Thu January 11, 2024 04:37 PM
From: Narayan Verma
Subject: Adding an infomap mechanism to the default login policy

Thank you Shane!  One thing I observed is that it's also trying to step-up the users authenticated using Kerberos.  Seems like those users get the AUTHENTICATION_LEVEL = 0 as seen in IVCREDS.  Can Kerberos be treated as if it's equivalent to (UID/PWD + Duo) or Certificate?

Thanks!

------------------------------
Narayan Verma

Original Message:
Sent: Thu January 11, 2024 04:26 PM
From: Shane Weeden
Subject: Adding an infomap mechanism to the default login policy

Read this: https://community.ibm.com/community/user/security/blogs/shane-weeden1/2020/03/18/protecting-entire-isam-webseal-site-with-multi-fac

It will resolve your issue with all-of-site protection with MFA.

------------------------------
Shane Weeden
IBM

Original Message:
Sent: Thu January 11, 2024 12:32 PM
From: Narayan Verma
Subject: Adding an infomap mechanism to the default login policy

Thanks Shane, I got it to work with the following:

------------------------------
Narayan Verma

Original Message:
Sent: Wed January 10, 2024 07:40 PM
From: Shane Weeden
Subject: Adding an infomap mechanism to the default login policy

You do this exactly the same way I have described - use the building blocks I have provided to put your solution together. Step-up authentication is just a way of triggering another level of authentication (Duo, or certificate) after password authentication. So you'd start with something like:

[authentication-levels]level = unauthenticatedlevel = passwordlevel = ext-auth-interfacelevel = ext-ssl

In this case password=1, EAI=2 (this includes Duo), and certificates=3. You would still use level2pop to protect all resources that are of any value. Either level 2 or 3 satisifies this.

Then instead of just using local-response-redirect to redirect to Duo on step-up, take that out and allow WebSEAL to show the regular stepuplogin.html page. Modify WebSEAL to have:

[step-up]show-all-auth-prompts = yesstep-up-at-higher-level = yes

Code your "choices" of either Duo or certificates to be displayed to the user into stepuplogin.html with FORM actions pointing to each as appropriate.

------------------------------
Shane Weeden
IBM

Original Message:
Sent: Wed January 10, 2024 09:15 AM
From: Narayan Verma
Subject: Adding an infomap mechanism to the default login policy

Thanks Shane!

How do we achieve Duo authentication right after the user id/password authentication?  The current login screen - e.g. certlogin.html provides both userid/password authentication and certificate option.  What we want to do is to inject Duo right after the userid/password authentication if the user chooses that route.  If user goes for cert based authentication then Duo is not needed.  We want to do that as part of initial login not as part of step-up authentication.

Somewhat of a later concern, for step-up authentication for sensitive data applications is it possible to provide an option to the user of using (either Duo or Certificate) not just Duo-only or just Cert-only?

We are trying to treat Duo and cert as same level of authentications from strength perspective.  Our options for initial login are going to be either of a) Kerberos b) userid/password followed by Duo c) certificate.  For step-up they are going to be either of a) Duo b) certificate.  That's the desired end goal.  I am hoping it's not going to create any conflicts, lead to bad practices, or unsupportable configurations.

------------------------------
Narayan Verma

Original Message:
Sent: Wed January 10, 2024 01:36 AM
From: Shane Weeden
Subject: Adding an infomap mechanism to the default login policy

Certificate authentication happens at the transport layer directly to WebSEAL. It does not make sense that it would ever use an AAC/Infomap authentication policy. It might use an Infomap to do identity mapping for the certificate, but that's all.

If you want certificate authentication as primary, followed by essentially step-up to Duo, then that is easy. Use a protected object policy on the junction (or any other WebSEAL object space resource that you want to protected) with authentication levels, like:

pdadmin> pop create level2poppdadmin> pop modify level2pop set ipauth anyothernw 2pdadmin> pop attach /WebSEAL/<your_server>/<your jct> level2pop

In your  [authentication-levels] stanza, something like:

[authentication-levels]level = unauthenticatedlevel = ssllevel = ext-auth-interface

To redirect to your Duo Infomap for step-up authentication:

[acnt-mgt]enable-local-response-redirect = yes[local-response-redirect]local-response-redirect-uri = [stepup] /mga/sps/authsvc/policy/duoPolicy

And in the AuthSvcCredential mapping rule (included in AAC), which runs at the successful completion of any AAC authentication policy, add:

if (policyID.equals("urn:ibm:security:authentication:asf:duoPolicy")) {   stsuu.getAttributeContainer().setAttribute(new Attribute("AUTHENTICATION_LEVEL", null, "2"));}

If its not that exact combination, its close. Experiment.

------------------------------
Shane Weeden
IBM

Original Message:
Sent: Tue January 09, 2024 02:28 PM
From: Narayan Verma
Subject: Adding an infomap mechanism to the default login policy

Hi team, any isights or recommendations on this?

Thanks!

------------------------------
Narayan Verma

Original Message:
Sent: Mon January 08, 2024 10:56 AM
From: Narayan Verma
Subject: Adding an infomap mechanism to the default login policy

------------------------------
Narayan Verma
------------------------------

Thanks Shane, which template would I modify for detecting this error state on the browser?

Also, by showing the regular userid/password you mean redirecting the user's browser to a policy that contains the password mechanism (I am assuming I'll immediately follow it up with a Duo mechanism)?  If so, how can we add the cert based auth option to the setup?  Can I simply include the below form as is?

Can't you do something simple like detect this  error code in client side JavaScript and show the regular u/p prompt in that case?

------------------------------
Narayan Verma

Original Message:
Sent: Sat January 13, 2024 03:44 PM
From: Shane Weeden
Subject: Adding an infomap mechanism to the default login policy

Sounds good. 

------------------------------
Shane Weeden
IBM

Original Message:
Sent: Sat January 13, 2024 10:31 AM
From: Narayan Verma
Subject: Adding an infomap mechanism to the default login policy

Thanks Shane, I tried the below and it worked:

------------------------------
Narayan Verma

Original Message:
Sent: Sat January 13, 2024 03:26 AM
From: Shane Weeden
Subject: Adding an infomap mechanism to the default login policy

No it's not and never has been. There are alternative APIs for accessing credential attributes in an Infomap. Google up examples or look through my blog articles. There's plenty of existing information available. 

------------------------------
Shane Weeden
IBM

Original Message:
Sent: Fri January 12, 2024 11:45 AM
From: Narayan Verma
Subject: Adding an infomap mechanism to the default login policy

I am trying to test the new policy at /mga/sps/authsvc/policy/kbooster after doing a kerberos authentication directly and getting the following error:

"stsuu" is not defined.

The code snippet in my mapping rule is as below:

Getting similar error (stsuu is not defined) when the policy is being invoked in the step-up flow:  /mga/sps/authsvc/policy/kbooster?TAM_OP=stepup

My other question is if I copy the content from stepuplogin.html for this new template in booster when Kerberos is not present how do I supply the values for macros that are already present like %LANGUAGE%, %PKMSPUBLIC%, %MSG{0x3898370b}%, %MSG{0x3898370e}% etc.  I believe somehow the mapping rule needs to make it available to the template, they don't seem to be globally available for all templates.  A workaround could be hard coding the values so stsuu not being available in the mapping rule is the bigger problem.

Thanks!

------------------------------
Narayan Verma

Original Message:
Sent: Thu January 11, 2024 05:14 PM
From: Shane Weeden
Subject: Adding an infomap mechanism to the default login policy

That would be easy enough to do. There are probably a few ways. The one that comes to mind most readily and is most flexible is as follows.

1. Go back to using local-response-redirect for stepup login, sending the local-response-redirect for step-up to an Infomap based authentication policy.
2. Code the Infomap to see what is already in the users credentials - you'll be able to tell if they've already done Kerberos by looking at another stsuu attribute the the credential like AZN_CRED_AUTH_METHOD or similar.
3. If the user was already authenticated kerberos, just succeed the stepup immediately in the Infomap, raising their authentication level.
4. Otherwise send back a page template from Infomap which looks more or less like the exisiting WebSEAL stepuplogin.html and everything else there works as it currently does.

------------------------------
Shane Weeden
IBM

Original Message:
Sent: Thu January 11, 2024 04:37 PM
From: Narayan Verma
Subject: Adding an infomap mechanism to the default login policy

Thank you Shane!  One thing I observed is that it's also trying to step-up the users authenticated using Kerberos.  Seems like those users get the AUTHENTICATION_LEVEL = 0 as seen in IVCREDS.  Can Kerberos be treated as if it's equivalent to (UID/PWD + Duo) or Certificate?

Thanks!

------------------------------
Narayan Verma

Original Message:
Sent: Thu January 11, 2024 04:26 PM
From: Shane Weeden
Subject: Adding an infomap mechanism to the default login policy

Read this: https://community.ibm.com/community/user/security/blogs/shane-weeden1/2020/03/18/protecting-entire-isam-webseal-site-with-multi-fac

It will resolve your issue with all-of-site protection with MFA.

------------------------------
Shane Weeden
IBM

Original Message:
Sent: Thu January 11, 2024 12:32 PM
From: Narayan Verma
Subject: Adding an infomap mechanism to the default login policy

Thanks Shane, I got it to work with the following:

------------------------------
Narayan Verma

Original Message:
Sent: Wed January 10, 2024 07:40 PM
From: Shane Weeden
Subject: Adding an infomap mechanism to the default login policy

You do this exactly the same way I have described - use the building blocks I have provided to put your solution together. Step-up authentication is just a way of triggering another level of authentication (Duo, or certificate) after password authentication. So you'd start with something like:

[authentication-levels]level = unauthenticatedlevel = passwordlevel = ext-auth-interfacelevel = ext-ssl

In this case password=1, EAI=2 (this includes Duo), and certificates=3. You would still use level2pop to protect all resources that are of any value. Either level 2 or 3 satisifies this.

Then instead of just using local-response-redirect to redirect to Duo on step-up, take that out and allow WebSEAL to show the regular stepuplogin.html page. Modify WebSEAL to have:

[step-up]show-all-auth-prompts = yesstep-up-at-higher-level = yes

Code your "choices" of either Duo or certificates to be displayed to the user into stepuplogin.html with FORM actions pointing to each as appropriate.

------------------------------
Shane Weeden
IBM

Original Message:
Sent: Wed January 10, 2024 09:15 AM
From: Narayan Verma
Subject: Adding an infomap mechanism to the default login policy

Thanks Shane!

How do we achieve Duo authentication right after the user id/password authentication?  The current login screen - e.g. certlogin.html provides both userid/password authentication and certificate option.  What we want to do is to inject Duo right after the userid/password authentication if the user chooses that route.  If user goes for cert based authentication then Duo is not needed.  We want to do that as part of initial login not as part of step-up authentication.

Somewhat of a later concern, for step-up authentication for sensitive data applications is it possible to provide an option to the user of using (either Duo or Certificate) not just Duo-only or just Cert-only?

We are trying to treat Duo and cert as same level of authentications from strength perspective.  Our options for initial login are going to be either of a) Kerberos b) userid/password followed by Duo c) certificate.  For step-up they are going to be either of a) Duo b) certificate.  That's the desired end goal.  I am hoping it's not going to create any conflicts, lead to bad practices, or unsupportable configurations.

------------------------------
Narayan Verma

Original Message:
Sent: Wed January 10, 2024 01:36 AM
From: Shane Weeden
Subject: Adding an infomap mechanism to the default login policy

Certificate authentication happens at the transport layer directly to WebSEAL. It does not make sense that it would ever use an AAC/Infomap authentication policy. It might use an Infomap to do identity mapping for the certificate, but that's all.

If you want certificate authentication as primary, followed by essentially step-up to Duo, then that is easy. Use a protected object policy on the junction (or any other WebSEAL object space resource that you want to protected) with authentication levels, like:

pdadmin> pop create level2poppdadmin> pop modify level2pop set ipauth anyothernw 2pdadmin> pop attach /WebSEAL/<your_server>/<your jct> level2pop

In your  [authentication-levels] stanza, something like:

[authentication-levels]level = unauthenticatedlevel = ssllevel = ext-auth-interface

To redirect to your Duo Infomap for step-up authentication:

[acnt-mgt]enable-local-response-redirect = yes[local-response-redirect]local-response-redirect-uri = [stepup] /mga/sps/authsvc/policy/duoPolicy

And in the AuthSvcCredential mapping rule (included in AAC), which runs at the successful completion of any AAC authentication policy, add:

if (policyID.equals("urn:ibm:security:authentication:asf:duoPolicy")) {   stsuu.getAttributeContainer().setAttribute(new Attribute("AUTHENTICATION_LEVEL", null, "2"));}

If its not that exact combination, its close. Experiment.

------------------------------
Shane Weeden
IBM

Original Message:
Sent: Tue January 09, 2024 02:28 PM
From: Narayan Verma
Subject: Adding an infomap mechanism to the default login policy

Hi team, any isights or recommendations on this?

Thanks!

------------------------------
Narayan Verma

Original Message:
Sent: Mon January 08, 2024 10:56 AM
From: Narayan Verma
Subject: Adding an infomap mechanism to the default login policy

------------------------------
Narayan Verma
------------------------------

I already described how to find which page you need before. Sounds like you have some experimenting to do. 

------------------------------
Shane Weeden
IBM

Original Message:
Sent: Wed January 17, 2024 12:26 PM
From: Narayan Verma
Subject: Adding an infomap mechanism to the default login policy

Thanks Shane, which template would I modify for detecting this error state on the browser?

Also, by showing the regular userid/password you mean redirecting the user's browser to a policy that contains the password mechanism (I am assuming I'll immediately follow it up with a Duo mechanism)?  If so, how can we add the cert based auth option to the setup?  Can I simply include the below form as is?

------------------------------
Narayan Verma

Original Message:
Sent: Wed January 17, 2024 12:11 PM
From: Shane Weeden
Subject: Adding an infomap mechanism to the default login policy

Can't you do something simple like detect this  error code in client side JavaScript and show the regular u/p prompt in that case?

------------------------------
Shane Weeden
IBM

Original Message:
Sent: Wed January 17, 2024 10:47 AM
From: Narayan Verma
Subject: Adding an infomap mechanism to the default login policy

------------------------------
Narayan Verma

Original Message:
Sent: Sat January 13, 2024 03:44 PM
From: Shane Weeden
Subject: Adding an infomap mechanism to the default login policy

Sounds good. 

------------------------------
Shane Weeden
IBM

Original Message:
Sent: Sat January 13, 2024 10:31 AM
From: Narayan Verma
Subject: Adding an infomap mechanism to the default login policy

Thanks Shane, I tried the below and it worked:

------------------------------
Narayan Verma

Original Message:
Sent: Sat January 13, 2024 03:26 AM
From: Shane Weeden
Subject: Adding an infomap mechanism to the default login policy

No it's not and never has been. There are alternative APIs for accessing credential attributes in an Infomap. Google up examples or look through my blog articles. There's plenty of existing information available. 

------------------------------
Shane Weeden
IBM

Original Message:
Sent: Fri January 12, 2024 11:45 AM
From: Narayan Verma
Subject: Adding an infomap mechanism to the default login policy

I am trying to test the new policy at /mga/sps/authsvc/policy/kbooster after doing a kerberos authentication directly and getting the following error:

"stsuu" is not defined.

The code snippet in my mapping rule is as below:

Getting similar error (stsuu is not defined) when the policy is being invoked in the step-up flow:  /mga/sps/authsvc/policy/kbooster?TAM_OP=stepup

My other question is if I copy the content from stepuplogin.html for this new template in booster when Kerberos is not present how do I supply the values for macros that are already present like %LANGUAGE%, %PKMSPUBLIC%, %MSG{0x3898370b}%, %MSG{0x3898370e}% etc.  I believe somehow the mapping rule needs to make it available to the template, they don't seem to be globally available for all templates.  A workaround could be hard coding the values so stsuu not being available in the mapping rule is the bigger problem.

Thanks!

------------------------------
Narayan Verma

Original Message:
Sent: Thu January 11, 2024 05:14 PM
From: Shane Weeden
Subject: Adding an infomap mechanism to the default login policy

That would be easy enough to do. There are probably a few ways. The one that comes to mind most readily and is most flexible is as follows.

1. Go back to using local-response-redirect for stepup login, sending the local-response-redirect for step-up to an Infomap based authentication policy.
2. Code the Infomap to see what is already in the users credentials - you'll be able to tell if they've already done Kerberos by looking at another stsuu attribute the the credential like AZN_CRED_AUTH_METHOD or similar.
3. If the user was already authenticated kerberos, just succeed the stepup immediately in the Infomap, raising their authentication level.
4. Otherwise send back a page template from Infomap which looks more or less like the exisiting WebSEAL stepuplogin.html and everything else there works as it currently does.

------------------------------
Shane Weeden
IBM

Original Message:
Sent: Thu January 11, 2024 04:37 PM
From: Narayan Verma
Subject: Adding an infomap mechanism to the default login policy

Thank you Shane!  One thing I observed is that it's also trying to step-up the users authenticated using Kerberos.  Seems like those users get the AUTHENTICATION_LEVEL = 0 as seen in IVCREDS.  Can Kerberos be treated as if it's equivalent to (UID/PWD + Duo) or Certificate?

Thanks!

------------------------------
Narayan Verma

Original Message:
Sent: Thu January 11, 2024 04:26 PM
From: Shane Weeden
Subject: Adding an infomap mechanism to the default login policy

Read this: https://community.ibm.com/community/user/security/blogs/shane-weeden1/2020/03/18/protecting-entire-isam-webseal-site-with-multi-fac

It will resolve your issue with all-of-site protection with MFA.

------------------------------
Shane Weeden
IBM

Original Message:
Sent: Thu January 11, 2024 12:32 PM
From: Narayan Verma
Subject: Adding an infomap mechanism to the default login policy

Thanks Shane, I got it to work with the following:

------------------------------
Narayan Verma

Original Message:
Sent: Wed January 10, 2024 07:40 PM
From: Shane Weeden
Subject: Adding an infomap mechanism to the default login policy

You do this exactly the same way I have described - use the building blocks I have provided to put your solution together. Step-up authentication is just a way of triggering another level of authentication (Duo, or certificate) after password authentication. So you'd start with something like:

[authentication-levels]level = unauthenticatedlevel = passwordlevel = ext-auth-interfacelevel = ext-ssl

In this case password=1, EAI=2 (this includes Duo), and certificates=3. You would still use level2pop to protect all resources that are of any value. Either level 2 or 3 satisifies this.

Then instead of just using local-response-redirect to redirect to Duo on step-up, take that out and allow WebSEAL to show the regular stepuplogin.html page. Modify WebSEAL to have:

[step-up]show-all-auth-prompts = yesstep-up-at-higher-level = yes

Code your "choices" of either Duo or certificates to be displayed to the user into stepuplogin.html with FORM actions pointing to each as appropriate.

------------------------------
Shane Weeden
IBM

Original Message:
Sent: Wed January 10, 2024 09:15 AM
From: Narayan Verma
Subject: Adding an infomap mechanism to the default login policy

Thanks Shane!

How do we achieve Duo authentication right after the user id/password authentication?  The current login screen - e.g. certlogin.html provides both userid/password authentication and certificate option.  What we want to do is to inject Duo right after the userid/password authentication if the user chooses that route.  If user goes for cert based authentication then Duo is not needed.  We want to do that as part of initial login not as part of step-up authentication.

Somewhat of a later concern, for step-up authentication for sensitive data applications is it possible to provide an option to the user of using (either Duo or Certificate) not just Duo-only or just Cert-only?

We are trying to treat Duo and cert as same level of authentications from strength perspective.  Our options for initial login are going to be either of a) Kerberos b) userid/password followed by Duo c) certificate.  For step-up they are going to be either of a) Duo b) certificate.  That's the desired end goal.  I am hoping it's not going to create any conflicts, lead to bad practices, or unsupportable configurations.

------------------------------
Narayan Verma

Original Message:
Sent: Wed January 10, 2024 01:36 AM
From: Shane Weeden
Subject: Adding an infomap mechanism to the default login policy

Certificate authentication happens at the transport layer directly to WebSEAL. It does not make sense that it would ever use an AAC/Infomap authentication policy. It might use an Infomap to do identity mapping for the certificate, but that's all.

If you want certificate authentication as primary, followed by essentially step-up to Duo, then that is easy. Use a protected object policy on the junction (or any other WebSEAL object space resource that you want to protected) with authentication levels, like:

pdadmin> pop create level2poppdadmin> pop modify level2pop set ipauth anyothernw 2pdadmin> pop attach /WebSEAL/<your_server>/<your jct> level2pop

In your  [authentication-levels] stanza, something like:

[authentication-levels]level = unauthenticatedlevel = ssllevel = ext-auth-interface

To redirect to your Duo Infomap for step-up authentication:

[acnt-mgt]enable-local-response-redirect = yes[local-response-redirect]local-response-redirect-uri = [stepup] /mga/sps/authsvc/policy/duoPolicy

And in the AuthSvcCredential mapping rule (included in AAC), which runs at the successful completion of any AAC authentication policy, add:

if (policyID.equals("urn:ibm:security:authentication:asf:duoPolicy")) {   stsuu.getAttributeContainer().setAttribute(new Attribute("AUTHENTICATION_LEVEL", null, "2"));}

If its not that exact combination, its close. Experiment.

------------------------------
Shane Weeden
IBM

Original Message:
Sent: Tue January 09, 2024 02:28 PM
From: Narayan Verma
Subject: Adding an infomap mechanism to the default login policy

Hi team, any isights or recommendations on this?

Thanks!

------------------------------
Narayan Verma

Original Message:
Sent: Mon January 08, 2024 10:56 AM
From: Narayan Verma
Subject: Adding an infomap mechanism to the default login policy

------------------------------
Narayan Verma
------------------------------

Thanks Shane!  Figured out it was the rp1 Junction --> Management Root --> errors --> C --> default.htm.

Was able to get the browser redirected to https://www.iamlab.ibm.com:4000/mga/sps/authsvc/policy/branchtesting

branchtesting is a is policy which is giving two branches/choices to the user... one branch has pre-built password mechanism immediately followed by Duo universal prompt mechanism (default option).  When I add the form for cert based authentication into the second branch it seems like it keeps asking for certificate at 

------------------------------
Narayan Verma

Original Message:
Sent: Wed January 17, 2024 01:10 PM
From: Shane Weeden
Subject: Adding an infomap mechanism to the default login policy

I already described how to find which page you need before. Sounds like you have some experimenting to do. 

------------------------------
Shane Weeden
IBM

Original Message:
Sent: Wed January 17, 2024 12:26 PM
From: Narayan Verma
Subject: Adding an infomap mechanism to the default login policy

Thanks Shane, which template would I modify for detecting this error state on the browser?

Also, by showing the regular userid/password you mean redirecting the user's browser to a policy that contains the password mechanism (I am assuming I'll immediately follow it up with a Duo mechanism)?  If so, how can we add the cert based auth option to the setup?  Can I simply include the below form as is?

------------------------------
Narayan Verma

Original Message:
Sent: Wed January 17, 2024 12:11 PM
From: Shane Weeden
Subject: Adding an infomap mechanism to the default login policy

Can't you do something simple like detect this  error code in client side JavaScript and show the regular u/p prompt in that case?

------------------------------
Shane Weeden
IBM

Original Message:
Sent: Wed January 17, 2024 10:47 AM
From: Narayan Verma
Subject: Adding an infomap mechanism to the default login policy

------------------------------
Narayan Verma

Original Message:
Sent: Sat January 13, 2024 03:44 PM
From: Shane Weeden
Subject: Adding an infomap mechanism to the default login policy

Sounds good. 

------------------------------
Shane Weeden
IBM

Original Message:
Sent: Sat January 13, 2024 10:31 AM
From: Narayan Verma
Subject: Adding an infomap mechanism to the default login policy

Thanks Shane, I tried the below and it worked:

------------------------------
Narayan Verma

Original Message:
Sent: Sat January 13, 2024 03:26 AM
From: Shane Weeden
Subject: Adding an infomap mechanism to the default login policy

No it's not and never has been. There are alternative APIs for accessing credential attributes in an Infomap. Google up examples or look through my blog articles. There's plenty of existing information available. 

------------------------------
Shane Weeden
IBM

Original Message:
Sent: Fri January 12, 2024 11:45 AM
From: Narayan Verma
Subject: Adding an infomap mechanism to the default login policy

I am trying to test the new policy at /mga/sps/authsvc/policy/kbooster after doing a kerberos authentication directly and getting the following error:

"stsuu" is not defined.

The code snippet in my mapping rule is as below:

Getting similar error (stsuu is not defined) when the policy is being invoked in the step-up flow:  /mga/sps/authsvc/policy/kbooster?TAM_OP=stepup

My other question is if I copy the content from stepuplogin.html for this new template in booster when Kerberos is not present how do I supply the values for macros that are already present like %LANGUAGE%, %PKMSPUBLIC%, %MSG{0x3898370b}%, %MSG{0x3898370e}% etc.  I believe somehow the mapping rule needs to make it available to the template, they don't seem to be globally available for all templates.  A workaround could be hard coding the values so stsuu not being available in the mapping rule is the bigger problem.

Thanks!

------------------------------
Narayan Verma

Original Message:
Sent: Thu January 11, 2024 05:14 PM
From: Shane Weeden
Subject: Adding an infomap mechanism to the default login policy

That would be easy enough to do. There are probably a few ways. The one that comes to mind most readily and is most flexible is as follows.

1. Go back to using local-response-redirect for stepup login, sending the local-response-redirect for step-up to an Infomap based authentication policy.
2. Code the Infomap to see what is already in the users credentials - you'll be able to tell if they've already done Kerberos by looking at another stsuu attribute the the credential like AZN_CRED_AUTH_METHOD or similar.
3. If the user was already authenticated kerberos, just succeed the stepup immediately in the Infomap, raising their authentication level.
4. Otherwise send back a page template from Infomap which looks more or less like the exisiting WebSEAL stepuplogin.html and everything else there works as it currently does.

------------------------------
Shane Weeden
IBM

Original Message:
Sent: Thu January 11, 2024 04:37 PM
From: Narayan Verma
Subject: Adding an infomap mechanism to the default login policy

Thank you Shane!  One thing I observed is that it's also trying to step-up the users authenticated using Kerberos.  Seems like those users get the AUTHENTICATION_LEVEL = 0 as seen in IVCREDS.  Can Kerberos be treated as if it's equivalent to (UID/PWD + Duo) or Certificate?

Thanks!

------------------------------
Narayan Verma

Original Message:
Sent: Thu January 11, 2024 04:26 PM
From: Shane Weeden
Subject: Adding an infomap mechanism to the default login policy

Read this: https://community.ibm.com/community/user/security/blogs/shane-weeden1/2020/03/18/protecting-entire-isam-webseal-site-with-multi-fac

It will resolve your issue with all-of-site protection with MFA.

------------------------------
Shane Weeden
IBM

Original Message:
Sent: Thu January 11, 2024 12:32 PM
From: Narayan Verma
Subject: Adding an infomap mechanism to the default login policy

Thanks Shane, I got it to work with the following:

------------------------------
Narayan Verma

Original Message:
Sent: Wed January 10, 2024 07:40 PM
From: Shane Weeden
Subject: Adding an infomap mechanism to the default login policy

You do this exactly the same way I have described - use the building blocks I have provided to put your solution together. Step-up authentication is just a way of triggering another level of authentication (Duo, or certificate) after password authentication. So you'd start with something like:

[authentication-levels]level = unauthenticatedlevel = passwordlevel = ext-auth-interfacelevel = ext-ssl

In this case password=1, EAI=2 (this includes Duo), and certificates=3. You would still use level2pop to protect all resources that are of any value. Either level 2 or 3 satisifies this.

Then instead of just using local-response-redirect to redirect to Duo on step-up, take that out and allow WebSEAL to show the regular stepuplogin.html page. Modify WebSEAL to have:

[step-up]show-all-auth-prompts = yesstep-up-at-higher-level = yes

Code your "choices" of either Duo or certificates to be displayed to the user into stepuplogin.html with FORM actions pointing to each as appropriate.

------------------------------
Shane Weeden
IBM

Original Message:
Sent: Wed January 10, 2024 09:15 AM
From: Narayan Verma
Subject: Adding an infomap mechanism to the default login policy

Thanks Shane!

How do we achieve Duo authentication right after the user id/password authentication?  The current login screen - e.g. certlogin.html provides both userid/password authentication and certificate option.  What we want to do is to inject Duo right after the userid/password authentication if the user chooses that route.  If user goes for cert based authentication then Duo is not needed.  We want to do that as part of initial login not as part of step-up authentication.

Somewhat of a later concern, for step-up authentication for sensitive data applications is it possible to provide an option to the user of using (either Duo or Certificate) not just Duo-only or just Cert-only?

We are trying to treat Duo and cert as same level of authentications from strength perspective.  Our options for initial login are going to be either of a) Kerberos b) userid/password followed by Duo c) certificate.  For step-up they are going to be either of a) Duo b) certificate.  That's the desired end goal.  I am hoping it's not going to create any conflicts, lead to bad practices, or unsupportable configurations.

------------------------------
Narayan Verma

Original Message:
Sent: Wed January 10, 2024 01:36 AM
From: Shane Weeden
Subject: Adding an infomap mechanism to the default login policy

Certificate authentication happens at the transport layer directly to WebSEAL. It does not make sense that it would ever use an AAC/Infomap authentication policy. It might use an Infomap to do identity mapping for the certificate, but that's all.

If you want certificate authentication as primary, followed by essentially step-up to Duo, then that is easy. Use a protected object policy on the junction (or any other WebSEAL object space resource that you want to protected) with authentication levels, like:

pdadmin> pop create level2poppdadmin> pop modify level2pop set ipauth anyothernw 2pdadmin> pop attach /WebSEAL/<your_server>/<your jct> level2pop

In your  [authentication-levels] stanza, something like:

[authentication-levels]level = unauthenticatedlevel = ssllevel = ext-auth-interface

To redirect to your Duo Infomap for step-up authentication:

[acnt-mgt]enable-local-response-redirect = yes[local-response-redirect]local-response-redirect-uri = [stepup] /mga/sps/authsvc/policy/duoPolicy

And in the AuthSvcCredential mapping rule (included in AAC), which runs at the successful completion of any AAC authentication policy, add:

if (policyID.equals("urn:ibm:security:authentication:asf:duoPolicy")) {   stsuu.getAttributeContainer().setAttribute(new Attribute("AUTHENTICATION_LEVEL", null, "2"));}

If its not that exact combination, its close. Experiment.

------------------------------
Shane Weeden
IBM

Original Message:
Sent: Tue January 09, 2024 02:28 PM
From: Narayan Verma
Subject: Adding an infomap mechanism to the default login policy

Hi team, any isights or recommendations on this?

Thanks!

------------------------------
Narayan Verma

Original Message:
Sent: Mon January 08, 2024 10:56 AM
From: Narayan Verma
Subject: Adding an infomap mechanism to the default login policy

------------------------------
Narayan Verma
------------------------------

I wouldn't redirect to AAC at all. When the error is detected why not just have that error page render almost identical contents to what you have in certlogin.html today?

Thanks Shane!  Figured out it was the rp1 Junction --> Management Root --> errors --> C --> default.htm.

Was able to get the browser redirected to https://www.iamlab.ibm.com:4000/mga/sps/authsvc/policy/branchtesting

branchtesting is a is policy which is giving two branches/choices to the user... one branch has pre-built password mechanism immediately followed by Duo universal prompt mechanism (default option).  When I add the form for cert based authentication into the second branch it seems like it keeps asking for certificate at 

------------------------------
Narayan Verma

Original Message:
Sent: Wed January 17, 2024 01:10 PM
From: Shane Weeden
Subject: Adding an infomap mechanism to the default login policy

I already described how to find which page you need before. Sounds like you have some experimenting to do. 

------------------------------
Shane Weeden
IBM

Original Message:
Sent: Wed January 17, 2024 12:26 PM
From: Narayan Verma
Subject: Adding an infomap mechanism to the default login policy

Thanks Shane, which template would I modify for detecting this error state on the browser?

Also, by showing the regular userid/password you mean redirecting the user's browser to a policy that contains the password mechanism (I am assuming I'll immediately follow it up with a Duo mechanism)?  If so, how can we add the cert based auth option to the setup?  Can I simply include the below form as is?

------------------------------
Narayan Verma

Original Message:
Sent: Wed January 17, 2024 12:11 PM
From: Shane Weeden
Subject: Adding an infomap mechanism to the default login policy

Can't you do something simple like detect this  error code in client side JavaScript and show the regular u/p prompt in that case?

------------------------------
Shane Weeden
IBM

Original Message:
Sent: Wed January 17, 2024 10:47 AM
From: Narayan Verma
Subject: Adding an infomap mechanism to the default login policy

------------------------------
Narayan Verma

Original Message:
Sent: Sat January 13, 2024 03:44 PM
From: Shane Weeden
Subject: Adding an infomap mechanism to the default login policy

Sounds good. 

------------------------------
Shane Weeden
IBM

Original Message:
Sent: Sat January 13, 2024 10:31 AM
From: Narayan Verma
Subject: Adding an infomap mechanism to the default login policy

Thanks Shane, I tried the below and it worked:

------------------------------
Narayan Verma

Original Message:
Sent: Sat January 13, 2024 03:26 AM
From: Shane Weeden
Subject: Adding an infomap mechanism to the default login policy

No it's not and never has been. There are alternative APIs for accessing credential attributes in an Infomap. Google up examples or look through my blog articles. There's plenty of existing information available. 

------------------------------
Shane Weeden
IBM

Original Message:
Sent: Fri January 12, 2024 11:45 AM
From: Narayan Verma
Subject: Adding an infomap mechanism to the default login policy

I am trying to test the new policy at /mga/sps/authsvc/policy/kbooster after doing a kerberos authentication directly and getting the following error:

"stsuu" is not defined.

The code snippet in my mapping rule is as below:

Getting similar error (stsuu is not defined) when the policy is being invoked in the step-up flow:  /mga/sps/authsvc/policy/kbooster?TAM_OP=stepup

My other question is if I copy the content from stepuplogin.html for this new template in booster when Kerberos is not present how do I supply the values for macros that are already present like %LANGUAGE%, %PKMSPUBLIC%, %MSG{0x3898370b}%, %MSG{0x3898370e}% etc.  I believe somehow the mapping rule needs to make it available to the template, they don't seem to be globally available for all templates.  A workaround could be hard coding the values so stsuu not being available in the mapping rule is the bigger problem.

Thanks!

------------------------------
Narayan Verma

Original Message:
Sent: Thu January 11, 2024 05:14 PM
From: Shane Weeden
Subject: Adding an infomap mechanism to the default login policy

That would be easy enough to do. There are probably a few ways. The one that comes to mind most readily and is most flexible is as follows.

1. Go back to using local-response-redirect for stepup login, sending the local-response-redirect for step-up to an Infomap based authentication policy.
2. Code the Infomap to see what is already in the users credentials - you'll be able to tell if they've already done Kerberos by looking at another stsuu attribute the the credential like AZN_CRED_AUTH_METHOD or similar.
3. If the user was already authenticated kerberos, just succeed the stepup immediately in the Infomap, raising their authentication level.
4. Otherwise send back a page template from Infomap which looks more or less like the exisiting WebSEAL stepuplogin.html and everything else there works as it currently does.

------------------------------
Shane Weeden
IBM

Original Message:
Sent: Thu January 11, 2024 04:37 PM
From: Narayan Verma
Subject: Adding an infomap mechanism to the default login policy

Thank you Shane!  One thing I observed is that it's also trying to step-up the users authenticated using Kerberos.  Seems like those users get the AUTHENTICATION_LEVEL = 0 as seen in IVCREDS.  Can Kerberos be treated as if it's equivalent to (UID/PWD + Duo) or Certificate?

Thanks!

------------------------------
Narayan Verma

Original Message:
Sent: Thu January 11, 2024 04:26 PM
From: Shane Weeden
Subject: Adding an infomap mechanism to the default login policy

Read this: https://community.ibm.com/community/user/security/blogs/shane-weeden1/2020/03/18/protecting-entire-isam-webseal-site-with-multi-fac

It will resolve your issue with all-of-site protection with MFA.

------------------------------
Shane Weeden
IBM

Original Message:
Sent: Thu January 11, 2024 12:32 PM
From: Narayan Verma
Subject: Adding an infomap mechanism to the default login policy

Thanks Shane, I got it to work with the following:

------------------------------
Narayan Verma

Original Message:
Sent: Wed January 10, 2024 07:40 PM
From: Shane Weeden
Subject: Adding an infomap mechanism to the default login policy

You do this exactly the same way I have described - use the building blocks I have provided to put your solution together. Step-up authentication is just a way of triggering another level of authentication (Duo, or certificate) after password authentication. So you'd start with something like:

[authentication-levels]level = unauthenticatedlevel = passwordlevel = ext-auth-interfacelevel = ext-ssl

In this case password=1, EAI=2 (this includes Duo), and certificates=3. You would still use level2pop to protect all resources that are of any value. Either level 2 or 3 satisifies this.

Then instead of just using local-response-redirect to redirect to Duo on step-up, take that out and allow WebSEAL to show the regular stepuplogin.html page. Modify WebSEAL to have:

[step-up]show-all-auth-prompts = yesstep-up-at-higher-level = yes

Code your "choices" of either Duo or certificates to be displayed to the user into stepuplogin.html with FORM actions pointing to each as appropriate.

------------------------------
Shane Weeden
IBM

Original Message:
Sent: Wed January 10, 2024 09:15 AM
From: Narayan Verma
Subject: Adding an infomap mechanism to the default login policy

Thanks Shane!

How do we achieve Duo authentication right after the user id/password authentication?  The current login screen - e.g. certlogin.html provides both userid/password authentication and certificate option.  What we want to do is to inject Duo right after the userid/password authentication if the user chooses that route.  If user goes for cert based authentication then Duo is not needed.  We want to do that as part of initial login not as part of step-up authentication.

Somewhat of a later concern, for step-up authentication for sensitive data applications is it possible to provide an option to the user of using (either Duo or Certificate) not just Duo-only or just Cert-only?

We are trying to treat Duo and cert as same level of authentications from strength perspective.  Our options for initial login are going to be either of a) Kerberos b) userid/password followed by Duo c) certificate.  For step-up they are going to be either of a) Duo b) certificate.  That's the desired end goal.  I am hoping it's not going to create any conflicts, lead to bad practices, or unsupportable configurations.

------------------------------
Narayan Verma

Original Message:
Sent: Wed January 10, 2024 01:36 AM
From: Shane Weeden
Subject: Adding an infomap mechanism to the default login policy

Certificate authentication happens at the transport layer directly to WebSEAL. It does not make sense that it would ever use an AAC/Infomap authentication policy. It might use an Infomap to do identity mapping for the certificate, but that's all.

If you want certificate authentication as primary, followed by essentially step-up to Duo, then that is easy. Use a protected object policy on the junction (or any other WebSEAL object space resource that you want to protected) with authentication levels, like:

pdadmin> pop create level2poppdadmin> pop modify level2pop set ipauth anyothernw 2pdadmin> pop attach /WebSEAL/<your_server>/<your jct> level2pop

In your  [authentication-levels] stanza, something like:

[authentication-levels]level = unauthenticatedlevel = ssllevel = ext-auth-interface

To redirect to your Duo Infomap for step-up authentication:

[acnt-mgt]enable-local-response-redirect = yes[local-response-redirect]local-response-redirect-uri = [stepup] /mga/sps/authsvc/policy/duoPolicy

And in the AuthSvcCredential mapping rule (included in AAC), which runs at the successful completion of any AAC authentication policy, add:

if (policyID.equals("urn:ibm:security:authentication:asf:duoPolicy")) {   stsuu.getAttributeContainer().setAttribute(new Attribute("AUTHENTICATION_LEVEL", null, "2"));}

If its not that exact combination, its close. Experiment.

------------------------------
Shane Weeden
IBM

Original Message:
Sent: Tue January 09, 2024 02:28 PM
From: Narayan Verma
Subject: Adding an infomap mechanism to the default login policy

Hi team, any isights or recommendations on this?

Thanks!

------------------------------
Narayan Verma

Original Message:
Sent: Mon January 08, 2024 10:56 AM
From: Narayan Verma
Subject: Adding an infomap mechanism to the default login policy

------------------------------
Narayan Verma
------------------------------

How do I keep default.html page intact for other use cases and change it only for the kerberos error code?

Are the macro values that are in certlogin.html going to be available in default.html as well?

I wouldn't redirect to AAC at all. When the error is detected why not just have that error page render almost identical contents to what you have in certlogin.html today?

Thanks Shane!  Figured out it was the rp1 Junction --> Management Root --> errors --> C --> default.htm.

Was able to get the browser redirected to https://www.iamlab.ibm.com:4000/mga/sps/authsvc/policy/branchtesting

branchtesting is a is policy which is giving two branches/choices to the user... one branch has pre-built password mechanism immediately followed by Duo universal prompt mechanism (default option).  When I add the form for cert based authentication into the second branch it seems like it keeps asking for certificate at 

------------------------------
Narayan Verma

Original Message:
Sent: Wed January 17, 2024 01:10 PM
From: Shane Weeden
Subject: Adding an infomap mechanism to the default login policy

I already described how to find which page you need before. Sounds like you have some experimenting to do. 

------------------------------
Shane Weeden
IBM

Original Message:
Sent: Wed January 17, 2024 12:26 PM
From: Narayan Verma
Subject: Adding an infomap mechanism to the default login policy

Thanks Shane, which template would I modify for detecting this error state on the browser?

Also, by showing the regular userid/password you mean redirecting the user's browser to a policy that contains the password mechanism (I am assuming I'll immediately follow it up with a Duo mechanism)?  If so, how can we add the cert based auth option to the setup?  Can I simply include the below form as is?

------------------------------
Narayan Verma

Original Message:
Sent: Wed January 17, 2024 12:11 PM
From: Shane Weeden
Subject: Adding an infomap mechanism to the default login policy

Can't you do something simple like detect this  error code in client side JavaScript and show the regular u/p prompt in that case?

------------------------------
Shane Weeden
IBM

Original Message:
Sent: Wed January 17, 2024 10:47 AM
From: Narayan Verma
Subject: Adding an infomap mechanism to the default login policy

------------------------------
Narayan Verma

Original Message:
Sent: Sat January 13, 2024 03:44 PM
From: Shane Weeden
Subject: Adding an infomap mechanism to the default login policy

Sounds good. 

------------------------------
Shane Weeden
IBM

Original Message:
Sent: Sat January 13, 2024 10:31 AM
From: Narayan Verma
Subject: Adding an infomap mechanism to the default login policy

Thanks Shane, I tried the below and it worked:

------------------------------
Narayan Verma

Original Message:
Sent: Sat January 13, 2024 03:26 AM
From: Shane Weeden
Subject: Adding an infomap mechanism to the default login policy

No it's not and never has been. There are alternative APIs for accessing credential attributes in an Infomap. Google up examples or look through my blog articles. There's plenty of existing information available. 

------------------------------
Shane Weeden
IBM

Original Message:
Sent: Fri January 12, 2024 11:45 AM
From: Narayan Verma
Subject: Adding an infomap mechanism to the default login policy

I am trying to test the new policy at /mga/sps/authsvc/policy/kbooster after doing a kerberos authentication directly and getting the following error:

"stsuu" is not defined.

The code snippet in my mapping rule is as below:

Getting similar error (stsuu is not defined) when the policy is being invoked in the step-up flow:  /mga/sps/authsvc/policy/kbooster?TAM_OP=stepup

My other question is if I copy the content from stepuplogin.html for this new template in booster when Kerberos is not present how do I supply the values for macros that are already present like %LANGUAGE%, %PKMSPUBLIC%, %MSG{0x3898370b}%, %MSG{0x3898370e}% etc.  I believe somehow the mapping rule needs to make it available to the template, they don't seem to be globally available for all templates.  A workaround could be hard coding the values so stsuu not being available in the mapping rule is the bigger problem.

Thanks!

------------------------------
Narayan Verma

Original Message:
Sent: Thu January 11, 2024 05:14 PM
From: Shane Weeden
Subject: Adding an infomap mechanism to the default login policy

That would be easy enough to do. There are probably a few ways. The one that comes to mind most readily and is most flexible is as follows.

1. Go back to using local-response-redirect for stepup login, sending the local-response-redirect for step-up to an Infomap based authentication policy.
2. Code the Infomap to see what is already in the users credentials - you'll be able to tell if they've already done Kerberos by looking at another stsuu attribute the the credential like AZN_CRED_AUTH_METHOD or similar.
3. If the user was already authenticated kerberos, just succeed the stepup immediately in the Infomap, raising their authentication level.
4. Otherwise send back a page template from Infomap which looks more or less like the exisiting WebSEAL stepuplogin.html and everything else there works as it currently does.

------------------------------
Shane Weeden
IBM

Original Message:
Sent: Thu January 11, 2024 04:37 PM
From: Narayan Verma
Subject: Adding an infomap mechanism to the default login policy

Thank you Shane!  One thing I observed is that it's also trying to step-up the users authenticated using Kerberos.  Seems like those users get the AUTHENTICATION_LEVEL = 0 as seen in IVCREDS.  Can Kerberos be treated as if it's equivalent to (UID/PWD + Duo) or Certificate?

Thanks!

------------------------------
Narayan Verma

Original Message:
Sent: Thu January 11, 2024 04:26 PM
From: Shane Weeden
Subject: Adding an infomap mechanism to the default login policy

Read this: https://community.ibm.com/community/user/security/blogs/shane-weeden1/2020/03/18/protecting-entire-isam-webseal-site-with-multi-fac

It will resolve your issue with all-of-site protection with MFA.

------------------------------
Shane Weeden
IBM

Original Message:
Sent: Thu January 11, 2024 12:32 PM
From: Narayan Verma
Subject: Adding an infomap mechanism to the default login policy

Thanks Shane, I got it to work with the following:

------------------------------
Narayan Verma

Original Message:
Sent: Wed January 10, 2024 07:40 PM
From: Shane Weeden
Subject: Adding an infomap mechanism to the default login policy

You do this exactly the same way I have described - use the building blocks I have provided to put your solution together. Step-up authentication is just a way of triggering another level of authentication (Duo, or certificate) after password authentication. So you'd start with something like:

[authentication-levels]level = unauthenticatedlevel = passwordlevel = ext-auth-interfacelevel = ext-ssl

In this case password=1, EAI=2 (this includes Duo), and certificates=3. You would still use level2pop to protect all resources that are of any value. Either level 2 or 3 satisifies this.

Then instead of just using local-response-redirect to redirect to Duo on step-up, take that out and allow WebSEAL to show the regular stepuplogin.html page. Modify WebSEAL to have:

[step-up]show-all-auth-prompts = yesstep-up-at-higher-level = yes

Code your "choices" of either Duo or certificates to be displayed to the user into stepuplogin.html with FORM actions pointing to each as appropriate.

------------------------------
Shane Weeden
IBM

Original Message:
Sent: Wed January 10, 2024 09:15 AM
From: Narayan Verma
Subject: Adding an infomap mechanism to the default login policy

Thanks Shane!

How do we achieve Duo authentication right after the user id/password authentication?  The current login screen - e.g. certlogin.html provides both userid/password authentication and certificate option.  What we want to do is to inject Duo right after the userid/password authentication if the user chooses that route.  If user goes for cert based authentication then Duo is not needed.  We want to do that as part of initial login not as part of step-up authentication.

Somewhat of a later concern, for step-up authentication for sensitive data applications is it possible to provide an option to the user of using (either Duo or Certificate) not just Duo-only or just Cert-only?

We are trying to treat Duo and cert as same level of authentications from strength perspective.  Our options for initial login are going to be either of a) Kerberos b) userid/password followed by Duo c) certificate.  For step-up they are going to be either of a) Duo b) certificate.  That's the desired end goal.  I am hoping it's not going to create any conflicts, lead to bad practices, or unsupportable configurations.

------------------------------
Narayan Verma

Original Message:
Sent: Wed January 10, 2024 01:36 AM
From: Shane Weeden
Subject: Adding an infomap mechanism to the default login policy

Certificate authentication happens at the transport layer directly to WebSEAL. It does not make sense that it would ever use an AAC/Infomap authentication policy. It might use an Infomap to do identity mapping for the certificate, but that's all.

If you want certificate authentication as primary, followed by essentially step-up to Duo, then that is easy. Use a protected object policy on the junction (or any other WebSEAL object space resource that you want to protected) with authentication levels, like:

pdadmin> pop create level2poppdadmin> pop modify level2pop set ipauth anyothernw 2pdadmin> pop attach /WebSEAL/<your_server>/<your jct> level2pop

In your  [authentication-levels] stanza, something like:

[authentication-levels]level = unauthenticatedlevel = ssllevel = ext-auth-interface

To redirect to your Duo Infomap for step-up authentication:

[acnt-mgt]enable-local-response-redirect = yes[local-response-redirect]local-response-redirect-uri = [stepup] /mga/sps/authsvc/policy/duoPolicy

And in the AuthSvcCredential mapping rule (included in AAC), which runs at the successful completion of any AAC authentication policy, add:

if (policyID.equals("urn:ibm:security:authentication:asf:duoPolicy")) {   stsuu.getAttributeContainer().setAttribute(new Attribute("AUTHENTICATION_LEVEL", null, "2"));}

If its not that exact combination, its close. Experiment.

------------------------------
Shane Weeden
IBM

Original Message:
Sent: Tue January 09, 2024 02:28 PM
From: Narayan Verma
Subject: Adding an infomap mechanism to the default login policy

Hi team, any isights or recommendations on this?

Thanks!

------------------------------
Narayan Verma

Original Message:
Sent: Mon January 08, 2024 10:56 AM
From: Narayan Verma
Subject: Adding an infomap mechanism to the default login policy

------------------------------
Narayan Verma
------------------------------

Put the forms in a hidden div and use JavaScript. Hard code "the other macros" values where needed. 

------------------------------
Shane Weeden
IBM

Original Message:
Sent: Wed January 17, 2024 05:30 PM
From: Narayan Verma
Subject: Adding an infomap mechanism to the default login policy

How do I keep default.html page intact for other use cases and change it only for the kerberos error code?

Are the macro values that are in certlogin.html going to be available in default.html as well?

------------------------------
Narayan Verma

Original Message:
Sent: Wed January 17, 2024 04:49 PM
From: Shane Weeden
Subject: Adding an infomap mechanism to the default login policy

I wouldn't redirect to AAC at all. When the error is detected why not just have that error page render almost identical contents to what you have in certlogin.html today?

------------------------------
Shane Weeden
IBM

Original Message:
Sent: Wed January 17, 2024 04:43 PM
From: Narayan Verma
Subject: Adding an infomap mechanism to the default login policy

Thanks Shane!  Figured out it was the rp1 Junction --> Management Root --> errors --> C --> default.htm.

Was able to get the browser redirected to https://www.iamlab.ibm.com:4000/mga/sps/authsvc/policy/branchtesting

branchtesting is a is policy which is giving two branches/choices to the user... one branch has pre-built password mechanism immediately followed by Duo universal prompt mechanism (default option).  When I add the form for cert based authentication into the second branch it seems like it keeps asking for certificate at 

------------------------------
Narayan Verma

Original Message:
Sent: Wed January 17, 2024 01:10 PM
From: Shane Weeden
Subject: Adding an infomap mechanism to the default login policy

I already described how to find which page you need before. Sounds like you have some experimenting to do. 

------------------------------
Shane Weeden
IBM

Original Message:
Sent: Wed January 17, 2024 12:26 PM
From: Narayan Verma
Subject: Adding an infomap mechanism to the default login policy

Thanks Shane, which template would I modify for detecting this error state on the browser?

Also, by showing the regular userid/password you mean redirecting the user's browser to a policy that contains the password mechanism (I am assuming I'll immediately follow it up with a Duo mechanism)?  If so, how can we add the cert based auth option to the setup?  Can I simply include the below form as is?

------------------------------
Narayan Verma

Original Message:
Sent: Wed January 17, 2024 12:11 PM
From: Shane Weeden
Subject: Adding an infomap mechanism to the default login policy

Can't you do something simple like detect this  error code in client side JavaScript and show the regular u/p prompt in that case?

------------------------------
Shane Weeden
IBM

Original Message:
Sent: Wed January 17, 2024 10:47 AM
From: Narayan Verma
Subject: Adding an infomap mechanism to the default login policy

------------------------------
Narayan Verma

Original Message:
Sent: Sat January 13, 2024 03:44 PM
From: Shane Weeden
Subject: Adding an infomap mechanism to the default login policy

Sounds good. 

------------------------------
Shane Weeden
IBM

Original Message:
Sent: Sat January 13, 2024 10:31 AM
From: Narayan Verma
Subject: Adding an infomap mechanism to the default login policy

Thanks Shane, I tried the below and it worked:

------------------------------
Narayan Verma

Original Message:
Sent: Sat January 13, 2024 03:26 AM
From: Shane Weeden
Subject: Adding an infomap mechanism to the default login policy

No it's not and never has been. There are alternative APIs for accessing credential attributes in an Infomap. Google up examples or look through my blog articles. There's plenty of existing information available. 

------------------------------
Shane Weeden
IBM

Original Message:
Sent: Fri January 12, 2024 11:45 AM
From: Narayan Verma
Subject: Adding an infomap mechanism to the default login policy

I am trying to test the new policy at /mga/sps/authsvc/policy/kbooster after doing a kerberos authentication directly and getting the following error:

"stsuu" is not defined.

The code snippet in my mapping rule is as below:

Getting similar error (stsuu is not defined) when the policy is being invoked in the step-up flow:  /mga/sps/authsvc/policy/kbooster?TAM_OP=stepup

My other question is if I copy the content from stepuplogin.html for this new template in booster when Kerberos is not present how do I supply the values for macros that are already present like %LANGUAGE%, %PKMSPUBLIC%, %MSG{0x3898370b}%, %MSG{0x3898370e}% etc.  I believe somehow the mapping rule needs to make it available to the template, they don't seem to be globally available for all templates.  A workaround could be hard coding the values so stsuu not being available in the mapping rule is the bigger problem.

Thanks!

------------------------------
Narayan Verma

Original Message:
Sent: Thu January 11, 2024 05:14 PM
From: Shane Weeden
Subject: Adding an infomap mechanism to the default login policy

That would be easy enough to do. There are probably a few ways. The one that comes to mind most readily and is most flexible is as follows.

1. Go back to using local-response-redirect for stepup login, sending the local-response-redirect for step-up to an Infomap based authentication policy.
2. Code the Infomap to see what is already in the users credentials - you'll be able to tell if they've already done Kerberos by looking at another stsuu attribute the the credential like AZN_CRED_AUTH_METHOD or similar.
3. If the user was already authenticated kerberos, just succeed the stepup immediately in the Infomap, raising their authentication level.
4. Otherwise send back a page template from Infomap which looks more or less like the exisiting WebSEAL stepuplogin.html and everything else there works as it currently does.

------------------------------
Shane Weeden
IBM

Original Message:
Sent: Thu January 11, 2024 04:37 PM
From: Narayan Verma
Subject: Adding an infomap mechanism to the default login policy

Thank you Shane!  One thing I observed is that it's also trying to step-up the users authenticated using Kerberos.  Seems like those users get the AUTHENTICATION_LEVEL = 0 as seen in IVCREDS.  Can Kerberos be treated as if it's equivalent to (UID/PWD + Duo) or Certificate?

Thanks!

------------------------------
Narayan Verma

Original Message:
Sent: Thu January 11, 2024 04:26 PM
From: Shane Weeden
Subject: Adding an infomap mechanism to the default login policy

Read this: https://community.ibm.com/community/user/security/blogs/shane-weeden1/2020/03/18/protecting-entire-isam-webseal-site-with-multi-fac

It will resolve your issue with all-of-site protection with MFA.

------------------------------
Shane Weeden
IBM

Original Message:
Sent: Thu January 11, 2024 12:32 PM
From: Narayan Verma
Subject: Adding an infomap mechanism to the default login policy

Thanks Shane, I got it to work with the following:

------------------------------
Narayan Verma

Original Message:
Sent: Wed January 10, 2024 07:40 PM
From: Shane Weeden
Subject: Adding an infomap mechanism to the default login policy

You do this exactly the same way I have described - use the building blocks I have provided to put your solution together. Step-up authentication is just a way of triggering another level of authentication (Duo, or certificate) after password authentication. So you'd start with something like:

[authentication-levels]level = unauthenticatedlevel = passwordlevel = ext-auth-interfacelevel = ext-ssl

In this case password=1, EAI=2 (this includes Duo), and certificates=3. You would still use level2pop to protect all resources that are of any value. Either level 2 or 3 satisifies this.

Then instead of just using local-response-redirect to redirect to Duo on step-up, take that out and allow WebSEAL to show the regular stepuplogin.html page. Modify WebSEAL to have:

[step-up]show-all-auth-prompts = yesstep-up-at-higher-level = yes

Code your "choices" of either Duo or certificates to be displayed to the user into stepuplogin.html with FORM actions pointing to each as appropriate.

------------------------------
Shane Weeden
IBM

Original Message:
Sent: Wed January 10, 2024 09:15 AM
From: Narayan Verma
Subject: Adding an infomap mechanism to the default login policy

Thanks Shane!

How do we achieve Duo authentication right after the user id/password authentication?  The current login screen - e.g. certlogin.html provides both userid/password authentication and certificate option.  What we want to do is to inject Duo right after the userid/password authentication if the user chooses that route.  If user goes for cert based authentication then Duo is not needed.  We want to do that as part of initial login not as part of step-up authentication.

Somewhat of a later concern, for step-up authentication for sensitive data applications is it possible to provide an option to the user of using (either Duo or Certificate) not just Duo-only or just Cert-only?

We are trying to treat Duo and cert as same level of authentications from strength perspective.  Our options for initial login are going to be either of a) Kerberos b) userid/password followed by Duo c) certificate.  For step-up they are going to be either of a) Duo b) certificate.  That's the desired end goal.  I am hoping it's not going to create any conflicts, lead to bad practices, or unsupportable configurations.

------------------------------
Narayan Verma

Original Message:
Sent: Wed January 10, 2024 01:36 AM
From: Shane Weeden
Subject: Adding an infomap mechanism to the default login policy

Certificate authentication happens at the transport layer directly to WebSEAL. It does not make sense that it would ever use an AAC/Infomap authentication policy. It might use an Infomap to do identity mapping for the certificate, but that's all.

If you want certificate authentication as primary, followed by essentially step-up to Duo, then that is easy. Use a protected object policy on the junction (or any other WebSEAL object space resource that you want to protected) with authentication levels, like:

pdadmin> pop create level2poppdadmin> pop modify level2pop set ipauth anyothernw 2pdadmin> pop attach /WebSEAL/<your_server>/<your jct> level2pop

In your  [authentication-levels] stanza, something like:

[authentication-levels]level = unauthenticatedlevel = ssllevel = ext-auth-interface

To redirect to your Duo Infomap for step-up authentication:

[acnt-mgt]enable-local-response-redirect = yes[local-response-redirect]local-response-redirect-uri = [stepup] /mga/sps/authsvc/policy/duoPolicy

And in the AuthSvcCredential mapping rule (included in AAC), which runs at the successful completion of any AAC authentication policy, add:

if (policyID.equals("urn:ibm:security:authentication:asf:duoPolicy")) {   stsuu.getAttributeContainer().setAttribute(new Attribute("AUTHENTICATION_LEVEL", null, "2"));}

If its not that exact combination, its close. Experiment.

------------------------------
Shane Weeden
IBM

Original Message:
Sent: Tue January 09, 2024 02:28 PM
From: Narayan Verma
Subject: Adding an infomap mechanism to the default login policy