Design Concept/Mockup [WIP]: User Access Reporting

[bdellasc]

What is “User Access Reporting”?

[Includes info from our product manager (PM), Amy Farley and user feedback]

We initially named this an “audit view” based on the following real-world scenario:
Some of our users are under increasing pressure to provide information about their Access and Sudo Policies for their regulatory and security audit programs. They need the ability to show the Access and Privilege granted to users across their environment.

Currently, when they need to report on user access for audits, they have to dig around in the Web UI to piece the information together themselves. They expressed interest in a “consolidated view” of a user’s access and some of the feedback suggested we have a way to download the information as a file that they can hand over in these audit situations.

We decided to make this design concept one of the first attempts at “WebUI UX task flows effort” because it was a smaller subset of functionality with specific customer requests that were more narrowly scoped. After some discussion, we are considering naming this feature “User Access Reporting” to better speak to the narrow scope of the feature. Past similar efforts (e.g. "Centralized logging") ran into scope/feasibility challenges and were ultimately deprioritized. There is a section (including a link to the detailed history) just before the mockups that summarizes what happened.

Why this scope?

We decided to take this narrowly scoped approach (only user access reporting) because of the following reasons:

• Lighter implementation lift:
  It could theoretically be a much lighter lift and effort to implement a very narrow focus as opposed to taking on a wider swath of functionality. To that point: it sounds like the centralized logging effort (See “Background for Centralized Logging” section below) ballooned very quickly and was ultimately deprioritized because of the scale of the issues that surfaced with such a wide-reaching feature.
• Incremental change:
  It would show incremental thought/progress in a tangible way that we are working toward solutions to help with our users’ needs. Users appreciate when there is progress that they can see/use, even if it may not be all-encompassing. We have to start somewhere, so let’s start small and see where it leads us.
• Inspiring conversations with our users:
  New functionality concepts and suggestions can bring about “you know what else would be useful?” suggestions with users. Giving users mock-ups/concepts to react to almost always inspire great conversation and uncover aspects we may not have considered. Even if the concept doesn’t exactly align with all of their expectations, it encourages further discussion and exporation. We always present these conceptual reviews with the following caveats:
  • conceptual in nature
  • will likely have more iteration
  • no promises of guaranteed implementation
• Looking beyond this concept:
  We’d continue building on whatever we start with. Yes, we might need to rework some of this specific user interface (UI) designs as more functionality is added, but that’s expected with an iterative approach. Trying to keep the designs moving forward and evolving based on need/feedback and feasibility will always help guide us.
• Speaking of feasibility:
  We are aware that there are gaps in backend capability, but will plan to address those as we can. The UX design for the task workflow will come first, along with research vetting of the proposed concept experience. These mockups are just the first step in creating and vetting these new workflows.

Background for Centralized Logging

[per Alex Bokovoy]

https://www.freeipa.org/page/Centralized_Logging was an attempt to investigate how we can collect the logging information in RHEL IdM environment. The group working on this quickly got to a multitude of issues including:

• storage of that information
• correlating it across multiple systems
• trusting the content of that information and so on.

Visualizing it in RHEL IdM web UI was not even under a consideration due to performance issues related to live-time processing of that data.

Concept mockups for User Access Reporting

Note: This design is in the conceptual phase. Although the mockups look like finished code, they are not. This is the first attempt/test at sharing design concepts and we will definitely be re-evaluating how we post content like this.
When commenting, please reference the flow/mockup # (x/x). If responding to a question, please also add the question before your response.

Flow 1: Search with "All" filter applied (concept)

Flow 1 (1/3): Search with "All" filter applied (concept)

Flow 1 (2/3): Search with "All" filter applied (concept)

Open Questions:

• Flow 1 (2/3) - A1: Specifically for this user access reporting area, are there any other types we should offer as filters?
  Flow 1 (2/3) - A2: 
Can we distinguish between Active/Preserved/Stage Users as a filter or are they all just considered “User login” ?
  Flow 1 (2/3) - A3: For the “All” (unfiltered) version of the table, columns might differ from the individual-type tables?

Flow 1 (3/3): Search with "All" filter applied (concept)

Open Questions:

• Question E1: Would mouseover to show rules overflow tooltip be feasible?

Flow 2: Search with the "Active user" filter applied (concept)

Flow 2 (1/2): Search with the "Active user" filter applied (concept)

Open Questions:

• A1: Are there any other useful columns of data applicable to all types that should appear in the “All” table?

Flow 2 (2/2): Search with the "Active user" filter applied (concept)

Flow 3: Bulk select for export (concept)

Flow 3 (1/3): Bulk select for export (concept)

Open Questions:

• B1: New infrastructure, API calls needed to batch process reports?
• B2: 
Could there be performance issues with export, especially if it’s a large number reports?
• B3: Would the reports be 1:1 per user or consolidated into one report?

Flow 3 (2/3): Bulk select for export (concept)

Flow 3 (3/3): Bulk select for export (concept)

Flow 4: Export notification (concept)

Flow 4 - OptA: Toast export notification (concept)

Open Questions:

• A1: Would we have the capability to process the request in the background, then notify upon completion?
• A2: 
Would these files be: stored somewhere for download OR would files download upon completion?

Flow 4 - OptB: Inline export notification (concept)

Open Questions:

• A1: Would we have the capability to process the request in the background, then notify upon completion?
• A2: 
Would these files be: stored somewhere for download OR would files download upon completion?

Flow 5 - OptA: User login details via drill-ins (concept)

Flow 5 - OptA (1/3): User login details via drill-ins (concept)

Flow 5 - OptA (2/3): User login details via drill-ins (concept)

• A1: Is this list too redundant or is it useful to see rules all rolled up into one list?
• D2: 
Is the host group relevent here?
• I3: Any additional content that would be needed for a useful audit report?

Flow 5 - OptA (3/3): User login details via drill-ins (concept)

Open Questions:

• B1: Is it a 1:many relationship (1 rule with many line items)? OR 1:1 relationship (1 rule with 1 line item)? OR both?
• F2: 
Is this valid/actual situation we’d have? No comparable rule/line item?
• G3: Question Automate release process with semantic release #3: Should anything be actionable from this screen? Offering “Export” here felt a little odd, since we’rte drilled in on details of a specific applied rule

Flow 5 - OptB: User login details via table row expansion (concept)

Flow 5 - OptB (1/3): User login details via table row expansion (concept)

Flow 5 - OptB (2/3): User login details via table row expansion (concept)

Open Questions:

• B1: Is it helpful for the user to see which rule(s) the applied rule “won” over?
• B2: 
Question Add vagrant and cypress for integration tests #2:
Would we ever have more than one conflicting rule we’d need to show?

Flow 5 - OptB (3/3): User login details via table row expansion (concept)

Open Questions:

• B1: Is it helpful for the user to see which rule(s) the applied rule “won” over?
• B2: 
Question Add vagrant and cypress for integration tests #2:
Would we ever have more than one conflicting rule we’d need to show?
  

[bdellasc]

This design is in the conceptual phase. Although the mockups look like finished code, they are not. This is the first attempt/test at sharing design concepts and will definitely be re-evaluating how we post content like this. When commenting, please reference the flow/mockup # (x/x). If responding to a question, please also add the question. Thanks!

Open questions rollup:

Flow 1: Search with "All" filter applied (concept)

• (1/3)
  • none to start
• (2/3)
  • A1: Specifically for this user access reporting area, are there any other types we should offer as filters?
  • A2: 
Can we distinguish between Active/Preserved/Stage Users as a filter or are they all just considered “User login” ?
  • A3: For the “All” (unfiltered) version of the table, columns might differ from the individual-type tables?
• (3/3)
  • Would mouseover to show rules overflow tooltip be feasible?

Flow 2: Search with the "Active user" filter applied (concept)

• (1/2)
  • Are there any other useful columns of data applicable to all types that should appear in the “All” table?
• (2/2)
  • none to start

Flow 3: Bulk select for export (concept)

• (1/3)
  • B1: New infrastructure, API calls needed to batch process reports?
  • B2: 
Could there be performance issues with export, especially if it’s a large number reports?
  • B3: Would the reports be 1:1 per user or consolidated into one report?
• (2/3)
  • none to start
• (3/3)
  • none to start

Flow 4: Export notification (concept)

• OptA
  • A1: Would we have the capability to process the request in the background, then notify upon completion?
  • A2: 
Would these files be: stored somewhere for download OR would files download upon completion?
• OptB
  • A1: Would we have the capability to process the request in the background, then notify upon completion?
  • A2: 
Would these files be: stored somewhere for download OR would files download upon completion?

Flow 5: User login details via drill-ins (concept)

• OptA (1/3)
  • none to start
• OptA (2/3)
  • A1: Is this list too redundant or is it useful to see rules all rolled up into one list?
  • D2: 
Is the host group relevent here?
  • I3: Any additional content that would be needed for a useful audit report?
• OptA (3/3)
  • B1: Is it a 1:many relationship (1 rule with many line items)? OR 1:1 relationship (1 rule with 1 line item)? OR both?
  • F2: 
Is this valid/actual situation we’d have? No comparable rule/line item?
  • G3: Should anything be actionable from this screen? Offering “Export” here felt a little odd, since we’rte drilled in on details of a specific applied rule
• OptB (1/3)
  • none to start
• OptB (2/3)
  • B1: Is it helpful for the user to see which rule(s) the applied rule “won” over?
  • B2: 
Would we ever have more than one conflicting rule we’d need to show?
• OptB (3/3)
  • B1: Is it helpful for the user to see which rule(s) the applied rule “won” over?
  • B2: 
Would we ever have more than one conflicting rule we’d need to show?