Using login.gov for scorecard authentication to the scorecard #876
Replies: 1 comment
-
I spent some time looking into login.gov today and I suspect there's a simpler approach than shadow accounts. My understanding is that login.gov is a service that handles user authentication for us. (It can also store a bunch of PII that we don't need, like SSNs) Once a user logs in with them, login.gov would give us (or Kirk's app) an email address or unique identifier to ID the user and some sort of authentication token. Once we've received confirmation that the user is authenticated, Kirk's app would then be able to create a session for them and it'd be up to us (and/or Kirk's app) to determine what the user would be authorized to do and how long they'd remain logged in. It's not clear to me how authorization is handled yet as that would involve a database that'd need to be persisted. It'd probably be good to talk with Kirk & Shannon on how this would work and who would be responsible for which parts. To keep it simple, we could require authentication solely for the scorecard app. Un-authenticated users would be able to use the rest of MATS without logging in. An aside - It's occasionally been mentioned that we have users who aren't US nationals - is being able to grant them access to MATS/the scorecard a requirement? If so, will we be able to accommodate someone from, for example, the UK's MET office or the Taiwanese Weather Bureau with login.gov? |
Beta Was this translation helpful? Give feedback.
-
As I understand it so far, Kirk has set up a mechanism where a user can authenticate to his/her login.gov through Kirk's application and that application will route the user through to the scorecard embedding the username in the header - something like that. I wonder, if I get a user in the header I could always create a local account with a temp password (probably just the user email) and save it so that the next time the user wouldn't need to authenticate with login.gov. No PI involved, we are just creating an account automatically with a temp password. The local account would be subject to loss unless we persist it. We could persist it, although it would have to be to a mounted directory or a database. If the same mechanism is applied to all the apps (even the legacy ones) - and it would be because it is in common code - we would probably have to find multiple ways to persist the local accounts.
The discussion is about the whole technique. Does it make sense at all to have fake local accounts for the sake of convenience? If we require login.gov then we are possibly requiring it for all of MATS and METexpress and that might be onerous. I suppose we could enforce it selectively. These are the questions.
Beta Was this translation helpful? Give feedback.
All reactions