Check on UK plans to implement authentication/ authorisation for Data-rights Holders

Science Independent Data Access Centers
#1

Dear DM (possibly one for SQuaRE team),

Here in LSST:UK, we have sketched out a design for authentication of data-rights holders to access LSST DR products on the UK IDAC. We have three (or four), high-level steps:

  • Step 1 – ideally in time for DP1, but in any case as soon as practical, we plan to implement DMTN-253 as written with our instance of Gafaelfawr as client and the US DAC as the IDP.
  • Then, Step 2 will be to introduce a proxy (probably Keycloak) between our RSP and the US DAC (with the data_rights claim being passed through) in order to allow users to log in using a different IDP or local account (obviously in this case the data_rights claim does not get set, so such users would have no access to data releases, but could still log in to, e.g., view non-rubin data or start a nublado session to access Lasair);
  • Step 3, we’d like to enable account linking so that a user with both types of login doesn’t need two separate accounts
  • Step 4, we’d like to extend the data_rights mechanism to cover non-rubin data (this would require additional work on our part, perhaps running a custom TAP service for such data so it’s more of a long-term ambition than a concrete plan).

We don’t anticipate any problems with the first two steps - does this seem correct?

The main problem that we foresee at Step 3 is ensuring that the data_rights claim gets updated in a reasonable timeframe when it changes (e.g., due to a new data release or a grace period expiring) regardless of which IDP is in use. Any thoughts on how we could handle this?

#2

Hello George,

Let’s work this back a bit to make sure you are saying what I think you should be saying.

As DMTN-253 explains, you can use delegated authentication from data.lsst.cloud by using an OpenID Connect client to connect to data.lsst.cloud’s gafaelfawr, which is an OIDC server. You can use your deployment of gafaelfawr as an OIDC client to connect to data.lsst.cloud’s gafaelfawr OIDC server BUT this is insufficient for a working system; additionally you need an LDAP server holding account metadata. This may or may not be what you mean in Step 2? But to clarify for other readers, we do not provide an LDAP server, you need to instantiate one, populate it and manage it yourselves.

In other words, Step 1 will not work unless you have done Steps 2 and 3 first.

Since my user information is in one LDAP server for data.lsst.cloud users (specifically the one provided to me by CoManage) and your user information is in whatever LDAP server you have set up to back your keycloak that you reference in Step 2, the only way to achieve Step 3, is for you to capture the information we return as part of the web authflow (as described here Science Platform authentication for IDAC users ) and store it in your local LDAP. This information should be sufficient for you to be able to link the two identities. This does mean that you can, theoretically, make it so that the user is not aware they have a UKDAC account through some process like:

  • You direct a user to some sort of signup page on your system
  • Your signup page directs the user to auth to data.lsst.cloud (per DMTN-253)
  • You capture that information, create an account for that user on your LDAP, and associate it with their data.lsst.cloud account
  • The user can now auth to the UK IDAC with their data.lsst.cloud identity

To be clear, you have to write the code to do the above.

I don’t understand exactly what you mean in Step 4. But perhaps since it is a downstream plan we can tackle this later.

As for your last point: we return you the data rights claim every time the user logs on (in your scenario). You actually control the user’s session duration (since despite what the user thinks they see, again, to be clear, they are using an account on your system / gafaelfawr). So you could set the session expiry to be at whatever cadence you want to re-check the data rights. As to whether there are policy issues with the built-in latency to such an implementation, I cannot tell you. For practical reasons, I doubt that any loss of data rights for a well-behaved user will be applied instantly, even in my system.

Hope that helps.

1 Like
#3

Hi Frossie,

Thanks for the response. The question here is an attempt to summarise the design that I presented at an IDAC coordination group meeting in April and to check whether DM anticipate any problems with it. I will try to clarify by breaking it down into two parts (perhaps it should really have been two separate posts to begin with).

Part 1. We are trying to understand what is involved in implementing delegated authentication and authorisation as described in DMTN-253, using Gafaelfawr as the client on the IDAC side. DMTN-253 gives a good explanation of how this works from the server side; is there anything that describes how to set up Gafaelfawr as the client in such a setup? (I have looked at the user documentation, but that is obviously not targetted at a specific scenario and is thus lacking in detail.

As you say, a local LDAP server is required in this setup for user metadata, which would presumably need to be populated by some out of band process. I would imagine that in theory the metadata and group information could actually be synthesised in this case in a similar manner to which it is already done for GitHub, but clearly this is not implemented.

In this scenario the main issue that I am still slightly unclear about is how the client Gafaelfawr makes authorisation decisions. As DMTN-253 says, the client (Gafaelfawr in this case) must check the content of the data_rights claim in order to establish that the user does indeed have data rights. However, it is not obvious to me how this is configured, nor how it interacts with the group mappings derived from LDAP.

Is there anyone with an existing implementation of this setup that we could learn from perhaps?

Part 2. This was not so much about what we can implement right away, as a roadmap for where we want to go and checking that there are no obvious showstoppers, either from a policy or technical point of view.

Step 2 introduces an OIDC proxy in between the client and server. Using an OIDC proxy for authentication in this way is fairly standard and I don’t anticipate any serious problems. There is a question about how to handle authorisation and the data_rights claim though. As I described in the IDAC coordination group presentation, there appear to me to be two options: either simply to pass the data_rights claim through and let the client handle it as though the proxy wasn’t there, or to intercept and interpret it at the proxy and use the information to update the local LDAP server appropriately. This is the part that I prototyped and concluded that both are feasible from the point of view of the proxy, although obviously the pass-through scenario is simpler to implement.

I think I agree that the detailed issues with steps 3 and 4 can be left for later since these are very much longer term plans.

Thanks again for your help!