There has to be a means by which a user logs into DataHub.
User Story
The user comes to datahub.aecmaster.com and sees this login page but without the password field. The background image is randomly picked from 10 different images related to construction.
Request Type A/B
Type A: This request creates something entirely new.
This request will add a new screen, which allows users to log in passwordless or with SSO (Google and Apple).
Is This Really Necessary?
A login screen is necessary, and making it passwordless seems to be the best way to future-proof the login approach. Adding SSO covers the drawback of sometimes issues arising with receiving the magic link.
Motivation
The user does not currently have any way to log in to DataHub and we don't have any way to protect the views from unauthorized use.
Named Concepts
passwordless means that the user can log in with a magic link without ever having a password.
SSO means single-sign-on (e.g. sign-in with Google)
Examples, Risks & Assumptions
Explain concretely what will manifest as a result of this RFW.
The ability for users to log in without a password.
Explain how is it different from what is already manifesting i.e. what we already have?
We don't have any way for users to log in.
Explain what users/brands will experience as a result of this RFW. How will they feel as a result of it? How will they benefit as a result of it?
Scenario A:
The user will come to the login screen. The user will then insert either their email address or phone number. They will then receive the magic link. The user clicks the link on their device. If the link is valid, the user then is allowed to come in.
Scenario B:
The user will come to the login screen. The user will click the SSO button of their choice. They will then go through the prompts of that SSO. If the sign-in is valid, the user then is allowed to come in.
If applicable, provide sample messages for any new messages the system will display as a result of this RFW.
This is available in the Figma mocks.
Define what is out of scope in this request.
The ability to create/delete/update user accounts.
What are the data protection, privacy, and security assumptions made for this request (for example, should this be GDPR, compliant, etc)
The system has to be a GDPR complaint.
Explain how this user story will be supported (i.e. customer support - if the user story fails technically, how will the user be supported).
There is no support function provided at this point.
Explain how this user story impacts revenue or billing (if applicable).
NA
State any additional risks identified as a result of this user story.
Not following GDPR
Not following security best practices
Overcomplicating the actual build of this request
Success Metrics
The user is able to log in.
Conceptual Design
The user is provided with two different ways to log in:
magic link
SSO
Drawbacks
If the provider for the magic link has a problem, the user can't come in. This is why we provided SSO as a backup.
Alternatives
The alternative is to make either a password login or use just SSO.
Table of Contents
Housekeeping
ALL BELOW FIELDS ARE REQUIRED
The Problem
There has to be a means by which a user logs into DataHub.
User Story
The user comes to datahub.aecmaster.com and sees this login page but without the password field. The background image is randomly picked from 10 different images related to construction.
Request Type A/B
Type A: This request creates something entirely new.
Owner
mikkokotila
Summary
This request will add a new screen, which allows users to log in passwordless or with SSO (Google and Apple).
Is This Really Necessary?
A login screen is necessary, and making it passwordless seems to be the best way to future-proof the login approach. Adding SSO covers the drawback of sometimes issues arising with receiving the magic link.
Motivation
The user does not currently have any way to log in to DataHub and we don't have any way to protect the views from unauthorized use.
Named Concepts
passwordless means that the user can log in with a magic link without ever having a password.
SSO means single-sign-on (e.g. sign-in with Google)
Examples, Risks & Assumptions
The ability for users to log in without a password.
We don't have any way for users to log in.
Scenario A:
The user will come to the login screen. The user will then insert either their email address or phone number. They will then receive the magic link. The user clicks the link on their device. If the link is valid, the user then is allowed to come in.
Scenario B:
The user will come to the login screen. The user will click the SSO button of their choice. They will then go through the prompts of that SSO. If the sign-in is valid, the user then is allowed to come in.
This is available in the Figma mocks.
The ability to create/delete/update user accounts.
The system has to be a GDPR complaint.
There is no support function provided at this point.
NA
Success Metrics
The user is able to log in.
Conceptual Design
The user is provided with two different ways to log in:
Drawbacks
If the provider for the magic link has a problem, the user can't come in. This is why we provided SSO as a backup.
Alternatives
The alternative is to make either a password login or use just SSO.
New Data
Product release date
NA