[
https://issues.apache.org/jira/browse/AIRAVATA-3319?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17476426#comment-17476426
]
Marcus Christie edited comment on AIRAVATA-3319 at 1/14/22, 9:10 PM:
---------------------------------------------------------------------
Eroma found something interesting. Logging in through ORCID results in the
email address not coming through. So that alone is great for testing. But more
interesting is that Keycloak takes the user to the following screen:
!Screen Shot 2022-01-10 at 4.52.42 PM.png|width=500!
The user has to provide an email address at this point to move forward.
I think this solves the mystery of how someone logs in through CILogon and ends
up with a username of {{http://cilogon...}} but also ends up with a seemingly
valid email address.
This makes me think that we can not implicitly trust the email address that we
get from the CILogon authentication flow. Perhaps we never really should have
implicitly trusted it, but definitely if Keycloak is allowing users to manually
input the email address, we really need to verify it first.
was (Author: marcuschristie):
Eroma found something interesting. Logging in through ORCID results in the
email address not coming through. So that alone is great for testing. But more
interesting is that Keycloak takes the user to the following screen:
!Screen Shot 2022-01-10 at 4.52.42 PM.png|thumbnail!
The user has to provide an email address at this point to move forward.
I think this solves the mystery of how someone logs in through CILogon and ends
up with a username of {{http://cilogon...}} but also ends up with a seemingly
valid email address.
This makes me think that we can not implicitly trust the email address that we
get from the CILogon authentication flow. Perhaps we never really should have
implicitly trusted it, but definitely if Keycloak is allowing users to manually
input the email address, we really need to verify it first.
> Handle missing name and email attributes from CILogon
> -----------------------------------------------------
>
> Key: AIRAVATA-3319
> URL: https://issues.apache.org/jira/browse/AIRAVATA-3319
> Project: Airavata
> Issue Type: New Feature
> Components: Django Portal
> Reporter: Marcus Christie
> Assignee: Marcus Christie
> Priority: Major
> Attachments: Screen Shot 2022-01-10 at 4.52.42 PM.png,
> Screenshot_2020-09-02 Keycloak Admin Console(1).png, Screenshot_2020-09-02
> Keycloak Admin Console.png
>
>
> {quote}
> tl;dr: CILogon will no longer require Identity Providers (IdPs) to assert
> email addresses and names for new users of OAuth2/OIDC (OpenID Connect)
> clients.
> {quote}
> [https://groups.google.com/a/cilogon.org/forum/#!topic/outages/kksaYVrW1Io]
> This issue to design a user authentication flow that handles missing
> attributes and prompts the user to supply them as necessary.
> h2. Questions
> - [x] Will we always get a {{preferred_username}} attribute? Question for
> CILogon team
> -- CILogon will always return a {{sub}} claim and this is the main
> identifier. CILogon doesn't appear to return a {{preferred_username}} claim.
> Keycloak uses {{email}} for {{preferred_username}}, if available, and {{sub}}
> if not.
> - [x] what will Keycloak do if any of these attributes are missing?
> -- in general it seems to leave out attributes that are missing but I haven't
> been able to find a test case with email or name attributes missing
> - [ ] can we setup a test setup where CILogon doesn't return
> email/firstName/lastName?
> -- Haven't found one yet. GitHub doesn't return given_name/family_name but it
> does return "name" and Keycloak parse this into firstName/lastName. See
> comments for details.
> h2. TODO
> - [x] extends User model to hold additional attributes?
> -- Use OneToOneField to associate additional attributes with built-in User
> model:
> https://docs.djangoproject.com/en/3.1/topics/auth/customizing/#extending-the-existing-user-model
> -- Store Keycloak 'sub', maybe also 'cilogon-sub' and 'eppn'. Maybe just
> store all of the userinfo fields as key-value pairs in a separate table
> - [x] user profile editor user interface (AIRAVATA-3455)
> - [ ] middleware to redirect to user profile editor when profile is
> incomplete (AIRAVATA-3468)
> - [ ] flag user profile as incomplete so that API calls, especially
> initializeUserProfile, are blocked (AIRAVATA-3468)
> - [ ] add an Admin view for updating a user's username
> h3. Maybe
> - [ ] check if username is IdP's 'sub' claim and, if CILogon, default to
> 'eppn' instead
> - [ ] verify email address of CILogon users as well?
> h2. Design
> h3. Scenario #1: User doesn't have first name and/or last name attributes
> - callback handles user authentication
> - fetch userinfo and check for missing attributes
> - note that first and/or last name are missing
> - -disable user in Keycloak- don't want to do this, otherwise user won't be
> able to log in
> - (?) Question: log the user in with a flag that profile is not complete? Or
> don't log the user in and put the user information somewhere in the session?
> -- I think, log the user in but set a session flag that the profile is not
> complete. in workspace/signals.py and in the UI use this to prevent API calls
> and to prevent the user from seeing UIs that they can't yet interact with.
> - redirect user to web form with profile information filled in
> -- email
> -- email again
> -- first name (if available)
> -- last name (if available)
> - user submits form
> - validate form
> - if form is valid and all required information is supplied, then ...
> -- update the user record in Keycloak
> -- enable the user
> h3. Scenario #2: User doesn't have email attribute
> Similar flow to above except
> - send the user an email verification link if the profile is complete and the
> email address has been supplied
> -- more generally, if the user updates their profile information and the
> email changes, need to re-verify the email address
> - when the email verification link is clicked, re-check the the profile is
> complete
> - if profile is complete, update the user record and enable the user
> - otherwise kick the user to the profile form and require the missing profile
> attributes
> - also, if the email is missing, Keycloak will set the username to the
> CILogon 'sub' claim (for example, "http://cilogon.org/serverA/users/12345";).
> So need to enable username editing at the realm level and require the user to
> pick a username.
> -- further, we can use a protocol mapper to provide the CILogon 'sub' claim
> in the userinfo as 'cilogon-sub' so we can check if Keycloak has set the
> username to the CILogon 'sub'
> -- if we have 'eppn' we can default the username to 'eppn'. Question though,
> if 'email' isn't provided, what will 'eppn' be?
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
