Cyral Data Access Portal
Enterprise database access, without passwords.
The Data Access Portal was a centralized interface for Cyral’s enterprise customers to browse, search, and connect to their database infrastructure. Instead of managing individual passwords across hundreds of databases, users authenticated once through their existing identity provider and received a token-based connection string, granting access without credentials ever being stored or shared.
Overview
What enterprise database access looks like
An enterprise runs hundreds of databases, spread across Postgres, Oracle, MongoDB, Snowflake, Redshift and S3, and each type authenticates its own way. The people reaching them vary just as much: database administrators, analysts, outside contractors, applications, and scheduled jobs. Access is granted, changed and revoked constantly, and no two repository types handle any of it the same way.
Problem
Providing visibility into database access
Users were managing passwords across hundreds of databases. Most databases have no native single sign-on, so companies either share accounts and passwords, or issue individual accounts per database. The first leaves no way to attribute a query to the person who ran it. The second demands that companies have a tight handle on issuing accounts to their users.
Solution
Designing for a range of users and repositories
The Data Access Portal gave users a centralized place to easily browse the repositories they could access, and quickly connect to any of them without a password. Authentication ran through the identity provider the company already used, and the portal generated a short-lived token instead of credentials.
A customer might have anywhere between a dozen and a thousand repositories. Indexing through such a wide range of results was non-negotiable. I prioritized optimizing the search and filtering experience so that users could locate and connect to their chosen repositories as quickly and easily as possible.
At Cyral, users were classified into two main groups: data administrators and data consumers. The issue was that data consumer behaviors ranged drastically; this user group consisted of analysts, business users working through Looker or Tableau, and outside contractors. The web interface was a decision about who was expected to use it: most of Cyral’s users spent their day in Looker or a spreadsheet, not a terminal. However, that didn’t close the feature off to users who preferred a terminal. I designed the interface to account for these power users by providing connection commands for psql, DBeaver, PgAdmin, Postico, SQL Developer or Toad, with the token already in it.
PGPASSWORD=***************** PGSSLMODE=require psql -h sidecar-east.demo.hhiu.us -p 5432 -U "nancy.drew@hhiu.us:analyst" example_dbMany repositories don’t connect the same way. A Postgres database takes a connection string; an S3 bucket takes AWS IAM credentials, has no database account to map an identity onto, and carries an entirely different set of clients. The list entries had to keep their shape, while the connection panels inside them had to adapt depending on the repository type.
Iteration
How can I improve this feature?
Opportunities for improvement became apparent once the feature was in the hands of real users. I had to be resourceful in how I gathered feedback: working around the constraints of building at a startup sometimes meant limited bandwidth and resources to dive deeper post feature release. I sourced feedback from support requests on Slack as well as direct feedback from support developers to shape how improvements could be made to the portal.
1. Avoid cognitive overload
Users had trouble parsing the details of a repository or an account, because related values were scattered across the layout. I rebuilt the view around grouping and disclosure: connection details became one block and access restrictions another, and each account folded into an accordion that opens one at a time.
2. Optimizing search and filter
I updated the search functionality to be more performant. Backend engineering optimizations allowed for responsive queries, so results could appear as users typed in the search input. Filtering expanded from repository name alone to repository type, database account, and user, which enabled users to further fine tune their queries. I added loading states as visual feedback to convey when user queries were acknowledged but took longer to load.
Reflection
What I learned
The challenge in designing this feature was how to handle variety: two kinds of user who worked in different tools and a repository list that accommodated a multitude of types. Two things I took from that challenge:
Isolating who you design for
The portal served drastically varying user types all within one screen. Every decision had to hold for all of them, and that’s where most of the complexity came from. The more useful question would’ve been whether they all belonged on the same screen.
The research channel usually already exists
Support developers triaged incoming issues, so they already knew which complaints recurred and which were one-offs. I found discussions with these devs to be insightful in pinpointing where users struggled.
Adoption was strong enough that the portal expanded to cover S3 buckets within the same quarter, and the patterns I established in it were picked up in other areas of the product.