brianalloyd
commented
3 years ago Thanks @johnhashva can you define "T&C"?
Closed johnhashva closed 2 years ago
brianalloyd
commented
3 years ago Thanks @johnhashva can you define "T&C"?
johnhashva
commented
3 years ago Yes @brianalloyd --- Terms & Conditions. Confirming with the VA person who identified this issue that I understand the use case (hard to replicate -- for me at least). Stay tuned.
brianalloyd
commented
3 years ago Awesome, thanks @johnhashva I've got this one on the docket for Grooming this week, thanks for confirming details in support.
brianalloyd
commented
3 years ago @ncksllvn update with some details, can you review and let us know what questions remain on this ticket. TY.
ncksllvn
commented
3 years ago Bumping estimate to 3. I'll see if I can replicate this locally.
Need to do more research before I can say with any confidence, but I am wondering if this could be related to that issue we had earlier this year (or was it last?) with the MHV eauth domain and the SSOe work.
johnhashva
commented
3 years ago @ncksllvn and @brianalloyd take a look at this Slack thread -- seems like it is related to this one
https://dsva.slack.com/archives/G01EN8VSX0A/p1615499324196300
johnhashva
commented
3 years ago @ncksllvn & @brianalloyd since that ^^^ is a closed channel (for the moment) here are looong, but hopefully helpful thread details.
Emily Mann Yesterday at 4:48 PM
My summary of the MHV coordinator call discussion about MHV sign-in issues (cc: @John Rahaghi @Cory Trimm) Problem: MHV coordinators are responding to issues when Veterans using sign-in partners and can sign-in, but then cannot use certain features in their MHV account. Coordinators have diagnosed this problem by viewing how Veterans last signed-in to their account, and found this was happening with DS Logon and ID.me secure partners. From the discussion, it sounded like Veterans were using the secure sign-in options on the MHV sign-in page, as opposed to this being an SSOe outbound failure (VA.gov > MHV). Coordinators are using DS Logon and ID.me to help Veterans upgrade to a premium MHV account. After that, they instruct Veterans to only sign in using the dark blue button, which is the non-SSOe option on MHV.
Charles Worthington 16 hours ago does this also impact people who sign in on VA.gov with DSL, IDme or MHV and then go to MHV via outbound
Leanna Miller 16 hours ago @Patrick Saxton @alastair
Emily Mann 16 hours ago It was unclear from this one conversation @charles, but outbound issues have been reported elsewhere
Chris Johnston 16 hours ago Rambling for a second. These "identity partners" were implemented over two years ago, and I would be shocked and dismayed if, all this time, it never actually worked. Further, the way they work is through a somewhat cludge-y but still functional session token that retains the session across different apps (MHV, VA.gov, VAOS). "True SSOe" is implemented for ~30% of users on VA.gov right now leaving the other 70% still subject to the above-described session cookie. Barry Egbert from Bylight confirmed for me last week that it is still in place. So this whole conversation just does not compute. (edited)
Aryeh Jacobsohn 15 hours ago Let's zoom out a sec. Here is what we know (I'll rely on @Cory Trimm to issue corrections): ~32% of SAML SSO logins initiated on VA.gov do not result in an established session Because of :point_up: , we only route 30% of users through the SAML flow (the rest get cookie) This results in a substantial number of users who auth on VA.gov, go to MHV and... need to auth again (think major browsers all disabling 3rd party cookies, etc.; the cookie gets less useful over time) Certain user flows in MHV (ex., the one which prompts the 10% of MHV users who have Advanced accounts to upgrade to Premium) do not appear unless there is a valid SAML SSO session (so, often, they're not occurring) To end users and support personnel alike, this behavior scans as "broken" because it's unpredictable at the level of an individual end user. To them, they might as well flip a coin and get one experience or the other. Our explanations about percentages of people for whom this or that is true and whether or not it's expected — Greek to them, and rightly so. MHV coordinators routinely advise end users to sign in using the non-SSO option on MHV, and are convinced this causes less trouble for end users / resolves access issues MHV team intends to make the non-SSO option on MHV more prominent to cut down on complaints from coordinators and end users until SSO issues are resolved Here is what we have heard but have not confirmed: It's possible users also experience analogous issues after signing into MHV directly using the partner flow (this is the first I've heard that, which means we should look into it, but it might turn out to be false — or to have been true some time in the past). Here is what we are doing: The IAM team has been working for a few months on adding or modifying a cookie (not clear to me which) to collect enough info on our fairly complicated authentication stack to be able to trace a user through the stack and, hopefully, assess the root cause of user issues for SSO sessions initiated on VA.gov. Cory is prodding this along. Carnetta is helping us aggregate suspected-affected-broken functionality in MHV. So that we can try to reproduce issues. Here is what we need: This cookie work is important. We need not to distract IAM team and / or we need to find a way to strengthen them so that we can do this root cause analysis. We will need production MHV accounts in various states (or to have them created) so that we can try to reproduce problems. I don't see being able to do this without heavy realtime collab w/MHV engineers. Spitballing here: We may need access to the help desk ticketing system and / or to influence the help desk team to create a specific tag for issues we suspect are related to SSO. I have no idea how realistic this is or how long it would take but it's what I would have done immediately as a private sector PM to start gathering intel and measuring problem occurrence. And frankly we need to clone ourselves. The sheer number of threads that go this deep is multiplying faster than we are. I know I have more limited working memory and multitasking ability than most, but we are biting off a lot. (edited)
brianalloyd
commented
3 years ago @johnhashva looking to set up a quick roundtable to review this ticket and discuss how we move forward. Would like to set something up next week if possible so we can screen share and determine what is happening and how to resolve.
johnhashva
commented
3 years ago Thanks @brianalloyd ... having missed today's session and convo on this very complicated one, let's catch-up as its unclear to me what role PW plays in the solve. You may be right == a workshop may be necessary to untangle all the complexity -- and determine if/where collaboration across teams is needed.
brianalloyd
commented
2 years ago Received a follow-on email concerning this issue as resolved. Closing ticket in support.
What happened?
When a user reads and acknowledges the VA.gov T&C's, they should not be presented with the MyHealthevet (MHV) T&C's -- but right now, they are.
Details:
The code in MHV is not displaying the MHV T&Cs if the VA.gov T&Cs are signed and that parameter is sent. It is suspected that the parameter is not sent if users are presented to sign the MHV T&Cs.
Worth noting: On 2/25, the VA.gov identity team (@CoryTrimmUSDS ) tested this user flow and found that a brand new user who started on va.gov and was redirected to MHV was presented with MHV’s T&C b/c they had not already signed them. (e.g. working as expected)
Specs:
Steps to Reproduce
URL:
Test User (if applicable):
Desired behavior
Describe in detail what was supposed to happen; reference existing Github issue that contains a solution if possible
Acceptance Criteria
How to configure this issue
Ongoing Maintenance)product support,analytics-insights,operations,triage,tools-improvements)backend,frontend,devops,design,research,product,ia,qa,analytics,contact center,research,accessibility,content)Bug