[JIRA] (IDP-1858) Consulting re integrating with third party IdP via saml proxy

[jerry shipman (Jira)]

jerry shipman ( https://shibboleth.atlassian.net/secure/ViewProfile.jspa?accountId=557058%3Ad78b2fc3-13f9-40cd-985b-e3a8a88e3cb4 ) *created* an issue

Identity Provider ( https://shibboleth.atlassian.net/browse/IDP?atlOrigin=eyJpIjoiZDQyNzg2ZmM5YzNlNDdmNzlmNDRjYjcyMDkxMWM2ZGYiLCJwIjoiaiJ9 ) / Improvement ( https://shibboleth.atlassian.net/browse/IDP-1858?atlOrigin=eyJpIjoiZDQyNzg2ZmM5YzNlNDdmNzlmNDRjYjcyMDkxMWM2ZGYiLCJwIjoiaiJ9 ) IDP-1858 ( https://shibboleth.atlassian.net/browse/IDP-1858?atlOrigin=eyJpIjoiZDQyNzg2ZmM5YzNlNDdmNzlmNDRjYjcyMDkxMWM2ZGYiLCJwIjoiaiJ9 ) Consulting re integrating with third party IdP via saml proxy ( https://shibboleth.atlassian.net/browse/IDP-1858?atlOrigin=eyJpIjoiZDQyNzg2ZmM5YzNlNDdmNzlmNDRjYjcyMDkxMWM2ZGYiLCJwIjoiaiJ9 )

Issue Type: Improvement Assignee: Scott Cantor ( https://shibboleth.atlassian.net/secure/ViewProfile.jspa?accountId=557058%3A5b78efc9-1379-42cc-a3f6-56c6ea3a0007 ) Attachments: Cornell-Shibboleth-Proposal.pdf Components: Authentication Created: 26/Aug/21 9:44 AM Priority: Trivial Reporter: jerry shipman ( https://shibboleth.atlassian.net/secure/ViewProfile.jspa?accountId=557058%3Ad78b2fc3-13f9-40cd-985b-e3a8a88e3cb4 )

Hello,

We are exploring the possibility of using a passwordless third-party Identity Provider to authenticate some of our user base and are hoping to get advice from you on how to best accomplish that.

Our goals are, in order of importance:

1. Decide which users are eligible to use the third-party service and only send those users through the authentication proxy.

We only want to attempt proxy authentication if a user is eligible and enrolled with the vendor's service (due to timeouts with how the vendor's authentication system works if a user is not enrolled). We antipate making this conditional decision based on attributes in our directory and the vendor's directory then choose the authentication flow based on the result of this conditional decision.

For example: alumni must always use our IdP with MFA because they are not eligible to proxy; IT staff must always use proxy authentication; faculty have the option to opt-in to the passwordless proxy or use traditional MFA. If they pick passwordless and they've already enrolled (based on directory attributes) we send them to the vendor, otherwise we send them to the enrollment page.

Can you advise us on a feasible way to accomplish this goal?

A key dependency to making eligibility decisions and knowing enrollment status is first having a username. We thought about prompting for the username and storing this value in a cookie to avoid asking them again every session. Once we have the username we can make the necessary queries. Based on their eligibility, we thought about presenting a choice to the user of whether to attempt login via the vendor or an existing MFA authentication flow (see attached flow chart).

We would prefer to reduce prompting the user for information. The most concise UI might be something like the username and password field, but then under that an extra button to "go passwordless", which would discard the password and go to the SAML proxy. But we weren't sure if we could mix the password/MFA flow and the SAML proxy flow like this, so we thought we would need to break it out into sequential prompts.

We are aware that the SAML proxy module exists, as does the external module that allows us to write customized code. I suppose we are looking for a better understanding of how these modules can interact together to choose the authentication flow based on some conditional logic.

2. Make a decision on our IdP about whether to allow a user session access to an application (SP) based on a SAML attribute provided by the third-party vendor. (We understand this more of an authorization check, but it would be great to enforce something like this centrally rather than on hundreds of distributed applications.)

The idea here is to utilize a capability that the vendor provides, which is to determine the confidence of a device's security posture (they use an agent installed on the device to collect telemetry or "risk signals" and map them against an admin-defined policy engine). Upon successful user authentication, the vendor would return a Authentication Assurance Level (AAL) value as a SAML attribute in the assertion representing the confidence level based on the policy we define.

For example, if a user successfully authenticates and has an AAL of 1, we would admit that user to applications that require AAL 1 but deny them access to applications that require AAL 2 or higher (we would store that association in a database somewhere). And if a user doesn't have an AAL attribute at all, we know that they didn't use this third-party service which we consider more robust than MFA alone because there is some knowledge of the device's security too.

It's sort of like network access control being applied at the identity authentication layer, a stripped down version of Zero Trust without requiring all SSO applications to be reconfigured and forced through an access gateway.

Is it possible to make access decisions based on a SAML attribute and, if so, how could we incorporate that into the authentication flow? What if it's an already established SSO session?

We realize this can be a complicated topic and we are open to a brief call about it if you are. Many thanks in advance for your help (and for reading this far)!

( https://shibboleth.atlassian.net/browse/IDP-1858#add-comment?atlOrigin=eyJpIjoiZDQyNzg2ZmM5YzNlNDdmNzlmNDRjYjcyMDkxMWM2ZGYiLCJwIjoiaiJ9 ) Add Comment ( https://shibboleth.atlassian.net/browse/IDP-1858#add-comment?atlOrigin=eyJpIjoiZDQyNzg2ZmM5YzNlNDdmNzlmNDRjYjcyMDkxMWM2ZGYiLCJwIjoiaiJ9 )

Get Jira notifications on your phone! Download the Jira Cloud app for Android ( https://play.google.com/store/apps/details?id=com.atlassian.android.jira.core&referrer=utm_source%3DNotificationLink%26utm_medium%3DEmail ) or iOS ( https://itunes.apple.com/app/apple-store/id1006972087?pt=696495&ct=EmailNotificationLink&mt=8 ) This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100175- sha1:eff898f )
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/commits/attachments/20210826/ebba36fd/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: jira-generated-image-static-comment-icon-98072d3e-d445-4370-8ced-85a3b85bb016
Type: image/png
Size: 1084 bytes
Desc: not available
URL: <http://shibboleth.net/pipermail/commits/attachments/20210826/ebba36fd/attachment-0004.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: jira-generated-image-avatar-a0a31228-fd40-441a-9475-eccc3727724a
Type: image/png
Size: 457 bytes
Desc: not available
URL: <http://shibboleth.net/pipermail/commits/attachments/20210826/ebba36fd/attachment-0005.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: jira-generated-image-static-trivial-f2dbb190-1b6d-424f-8811-4aee1747aa21
Type: image/png
Size: 563 bytes
Desc: not available
URL: <http://shibboleth.net/pipermail/commits/attachments/20210826/ebba36fd/attachment-0006.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: jira-generated-image-static-footer-desktop-logo-d297d9a4-2994-4d37-aedc-9fcadbbe9cf7
Type: image/png
Size: 10805 bytes
Desc: not available
URL: <http://shibboleth.net/pipermail/commits/attachments/20210826/ebba36fd/attachment-0007.png>