I have a scenario that I will need to support multiple applications in a federation, but the login mechanisms are multiple, like IBM Verify, Facebook, Fido2, Forms, and many more.
What is the best approach to implement this?

------------------------------
Joao Goncalves
Pyxis, Lda.
Sintra
+351 91 721 4994
------------------------------

Hi Joao,

If I assume an architecture that is a single Verify Access deployment (so one AAC/Fed runtime) and multiple federations supported via one (or a small number) of Reverse Proxy clusters, this implies that at some point in the flow you will need to identify the federation partner for which access is being requested and then trigger an appropriate authentication flow.

In Verify Access, authentication associated with federation could be triggered in two ways:
 1. ACL on some federation endpoint (likely /sps/auth) requiring login
 2. An "Access Policy" associated with a federation requires authentication

For authentication triggered via ACL, it is possible (via Point of Contact configuration) to specify additional query parameters to be added to the authentication trigger URL.  This could include the entity ID of the partner.  These query string parameters can be read, in client-side JavaScript on login.html page, to decide whether a redirect to an alternative login flow is needed.  In this case, logic is executed on browser.

Taking the idea above one step further, you could re-direct from login.html to an AAC authentication policy and pass on the query string attributes in that call.  That authentication policy could then determine the correct authentication required and use either branching - or trigger social sign-on.  In this case, logic is executed in the AAC Authentication Policy.

For authentication triggered by Access Policy, you have direct access to federation context in the Access Policy JavaScript.  This JavaScript can trigger a redirect to either a suitable AAC authentication policy or trigger social login etc.  In this case the logic is in the Access Policy.

To use Access Policy to manage "first factor" authentication for federation, you have to add unauthenticated ACL to the /sps/auth endpoint so that it doesn't trigger initial authentication before the Access Policy is triggered.

It's worth noting that Access Policy is only triggered within federation flows so you would probably also need some mechanism to handle the case where authentication is required for access to local resources (if that is also a use case).

Of course, it's hard to provide definitive advice but I hope this provides some ideas. 

Jon.

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

Original Message:
Sent: Thu January 07, 2021 04:00 PM
From: Joao Goncalves
Subject: Multiple Logins methodology support on a federation

I have a scenario that I will need to support multiple applications in a federation, but the login mechanisms are multiple, like IBM Verify, Facebook, Fido2, Forms, and many more.
What is the best approach to implement this?

------------------------------
Joao Goncalves
Pyxis, Lda.
Sintra
+351 91 721 4994
------------------------------

Thanks for your thoughts.
Let me ask if something like this may work.
1 reverse proxy with multiple Junctions.
Each junction will support SAML, OIDC, OAuth, Federated Protocols as needed.
There will be 1 unique Access Policy that will be shared by all federations. This Access Policy will be able to redirect to suitable authorization mechanism. For example, if the user logs in through a browser we can use Username/Password + email OTP to connect, or google if he chooses. If the user logs in through a Mobile App which prompts for credentials he may choose email + QRCode using a 2FA.
If Google is chosen, we will use OIDC Fed protected junction to validate the user. If it is some other choice may we will SAML Fed protected junction, and so on.

The next question comes when I get any of the possible authentication mechanisms and different ID Tokens SAML, JWT claims, and more, I will need to map the users to the backend Application users, and generate a common JWT, to access the backend application.

Can I use a "bearer" protocol to accept Google JWT, to generate the new JWT to the backend application?

------------------------------
Joao Goncalves
Pyxis, Lda.
Sintra
+351 91 721 4994
------------------------------

Original Message:
Sent: Fri January 08, 2021 04:53 AM
From: Jon Harry
Subject: Multiple Logins methodology support on a federation

Hi Joao,

If I assume an architecture that is a single Verify Access deployment (so one AAC/Fed runtime) and multiple federations supported via one (or a small number) of Reverse Proxy clusters, this implies that at some point in the flow you will need to identify the federation partner for which access is being requested and then trigger an appropriate authentication flow.

In Verify Access, authentication associated with federation could be triggered in two ways:
 1. ACL on some federation endpoint (likely /sps/auth) requiring login
 2. An "Access Policy" associated with a federation requires authentication

For authentication triggered via ACL, it is possible (via Point of Contact configuration) to specify additional query parameters to be added to the authentication trigger URL.  This could include the entity ID of the partner.  These query string parameters can be read, in client-side JavaScript on login.html page, to decide whether a redirect to an alternative login flow is needed.  In this case, logic is executed on browser.

Taking the idea above one step further, you could re-direct from login.html to an AAC authentication policy and pass on the query string attributes in that call.  That authentication policy could then determine the correct authentication required and use either branching - or trigger social sign-on.  In this case, logic is executed in the AAC Authentication Policy.

For authentication triggered by Access Policy, you have direct access to federation context in the Access Policy JavaScript.  This JavaScript can trigger a redirect to either a suitable AAC authentication policy or trigger social login etc.  In this case the logic is in the Access Policy.

To use Access Policy to manage "first factor" authentication for federation, you have to add unauthenticated ACL to the /sps/auth endpoint so that it doesn't trigger initial authentication before the Access Policy is triggered.

It's worth noting that Access Policy is only triggered within federation flows so you would probably also need some mechanism to handle the case where authentication is required for access to local resources (if that is also a use case).

Of course, it's hard to provide definitive advice but I hope this provides some ideas. 

Jon.

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

Original Message:
Sent: Thu January 07, 2021 04:00 PM
From: Joao Goncalves
Subject: Multiple Logins methodology support on a federation

I have a scenario that I will need to support multiple applications in a federation, but the login mechanisms are multiple, like IBM Verify, Facebook, Fido2, Forms, and many more.
What is the best approach to implement this?

------------------------------
Joao Goncalves
Pyxis, Lda.
Sintra
+351 91 721 4994
------------------------------