I am drawing a use case diagram for an Online Bill Payment and I am confused about the authentification step. Is it better to create separate use cases for a new user and for a registered user like I've tried below
or should I create just a login use case and then extend the register, for example like this:
or should I create an authentification use case and extend login, logout and register?
A use case shows added value brought to its actor. There is no added value for Login. So Login is no use case at all. It is a constraint you apply to other use cases. It can be attached to (real) use cases like { actor must be logged in}.
I can recommend Bittner/Spence as an excellent source on how to deal with use cases.
There are several approaches depending on expected system behavior and your writing style.
Use two different actors, authorised and non-authorised user. Write subfunction level login use case for non-authorised user. Let authorised user only to be an actor in user goal use cases like Check balance.
In all user goal level use cases write precondition that user is authorised. Write subfunction level login use case.
In all user goal level use cases write precondition that user session is valid. Write subfunction level use case where system checks session and enforces login use case when needed.
Login, logout and registration (also session expiration) scenarios are not connected in the way you asking. You can, for example, tag them as AAA or put in AAA chapter/folder. There is no need to mix them in one scenario.
Related
I am currently developing a strategy for Dialogflow on https://passportjs.org.
From what I've learnt, Dialogflow doesn't authenticate users. So I'm thinking about making a strategy (for passportjs) that identify users from every plateform differently (analyse the originalRequest differently for each plateform).
For example, the Telegram originalRequest has this field:
originalRequest.data.message.from.id
The Telegram says this field is a:
"Unique identifier for this user or bot"
So I think it is safe to use it for authentication and identify every intent of my users fulfilled by my webhook.
I was wondering about the actions-on-google authentication and I found the field originalRequest.data.user.userId.
The documentation says:
"Users can reset this identifier, so don't store important user data keyed off this identifier, because once it's reset, that information is no longer accessible by the user."
So the only reason to not trust the userId is because it can be reset? At the end of the documentation it says:
User ID lifetime - User IDs are reset automatically after 30 days of inactivity or if users unlink their accounts on the device.
And:
"If a registered user's voice isn't recognized by the device or no registered voice exists, then a different ID is used that is unique for just that conversation."
How to differentiate users from one other? Can some IDs be recycled?
The best way to differentiate users from each other is to use the userId field, as you've determined. On the AoG platform, the userId is meant to be used somewhat like a web cookie can be used - if you see it again, you are assured that this is the same user that used it last time. But if you see a new one, you have to assume that you've never seen this user before, even if it means they deleted the cookie.
To be clear - most of the time, the UserId will remain the same and you can expect returning users to have the same ID. This won't be true in only three cases:
They have reset the ID for this Action. So they have deliberately chosen to start over.
They didn't use the Action for 30 days, in which case it makes sense to treat them as a brand new user anyway in most cases.
They were not recognized as a normal user of this device, so they are treated anonymously. (This is the equivalent of the clunky "Do not remember me on this machine" setting you see on websites, which forces a session cookie rather than a persistent cookie.)
The phrasing is poor in the documentation - I think it is meant to remind developers that the user is ultimately in charge of their privacy. And Google both forces you to do the same and adopt policies that do so.
IDs will not be recycled. In fact, they won't even be re-used between different Actions, even for the same Assistant account.
Summary: If you see the same UserId, you can trust it is the same user you saw before. If you see a new one, assume they are a new user.
If you want a more robust way to identify users, you might consider using Account Linking which puts you in control of the identifying token. But that has significant additional overhead.
Be careful when using other authentication methods - Google limits how you're allowed to use them as part of an Action, and expressly forbids them in some cases. See the General Policies for details.
Login is use case, right? But I am confused about Invalid login credential: Is it a use case or a system operation?
No, "login" is not a use case. Here is why: Is it necessary to include the login for every usecase?
Login is a common precondition to real use cases.
Second step: Think about the outcomes that bring a benefit.
If a valid login is a use case, then invalid login is a use case. You need to be able to notify your user that a login has failed.
Typically it is an alternative flow in the login use case.
If in your situation this alternate flow turns out to be long and complicated - you can promote it to a separate use case extending login use case.
Which is suggested way to implement _customRoleRepository in the following examples?
Following code is executed in the application service.
var user = _userRepository.GetById(1);
var customRole = _customRoleRepository.GetById(user.CustomRoleId);
or
var user = _userRepository.GetById(1);
var customRole = _customRoleRepository.GetForUser(user);
Given the two options I would probably go for the first one, which keeps consistency of accessing by an ID.
If possible, it might be preferable to load the custom role when you load the user to avoid another round trip to the database, especially if this is a common operation. This could be implemented as a read model.
This is presuming you have modelled your aggregates correctly... :)
Hate to say it but in a DDD environment, my answer would be neither.
In your first example, the role repository can be ignorant of the user domain which is good but it means the application needs to know that to get the role it needs to pull an id out of the user and then query another repository. In other words, the application is acting as a mapper between user and role.
In the second example, the roles repository now needs to know about the user domain. Not great but on the other hand the application no longer needs to know about roleId. So that is good. Classic sort of trade off between the two approaches.
But in both cases the application still needs two repositories to get it's information. What happens when more relations are needed? The number of repositories can quickly grow and things become a mess.
In Domain Driven Design you should try to think in terms of aggregate roots(AR) and domain contexts. For your example context, the user is an AR and the role becomes a child. So you might have:
var user = _userFinder.GetById(1);
var customRole = user.CustomRole;
That hides most of the implementation details from you application and allows you to focus on what your domain entities actually need to do.
Both are equally valid, depending on your needs. GetForUser would be good if you want to ensure the calling code has a valid User aggregate before you try and retrieve the roles - while it does couple the customRoleRepository to knowledge of the User aggregate, if you want to require the calling code to have a valid User aggregate, then that coupling has a purpose.
GetByUserId is more consistent with GetById and has less coupling, so if in your context it doesn't matter to call GetByUserId even if the client doesn't have a valid User aggregate, then that's fine too.
If you are loading ById, I've also found using typed identity valueobjects can be quite helpful in providing an extra level of type safety - some conversation about the pros and cons here https://stackoverflow.com/a/5377460/6720449 and here https://groups.google.com/forum/#!topic/dddcqrs/WQ9zRtW3Gbg
I'm working on a project based on Jhipster that requires the use of an additional field (organization) to uniquely identify a user during authentication. So we can have two rows in the JHI_USER table with the same login and password but different organizations and this should represent two separate users.
I searched in code but I can't figure out how to implement this.
Sorry for previous answer, I really don`t understand you last time.
In this case you can use OPERATIONS(OR ANOTHER ROLE) and you can check if user has two roles like ["ROLE_USER", "OPERATION_ORGANIZATION_1"] then do something, but if user has ["ROLE_USER", "OPERATION_ORGANIZATION_1"] then another action.
You must add concept "operation". I wrote about it here:
Jhipster - roles and operation
It`s different, that what you want, but it's specific exit from your situation.
I am doing sequence diagrams, but I have some issues in the design of these diagrams. So I was doing the diagram for Account Creation as follows:
So, first the user goes to the registration page and then enters his information. I also wanted to show what would happen if the information entered by the user in the registration page are incorrect: I added the verify input arrow from the registration page to the database.
I am not sure who should verify that the input is correct, is it correct to say it's the database that checks if the entered data are valid?
Moreover, is it correct to add the dashed arrow from the database to the registration page or should I go directly to the if condition?
What would you advice me to change?
1) ..who should verify..input...database..?
You can delegate the responsibility for data validation to whichever actor with whatever name. Database is good candidate, and many SQL databases have some kind of integrity constraint checking mechanism built-in
If configured, such database will validate data and reject them at the moment of insert/update attempt. So in your case if a SQL database would handle it the way they usually do, the VerificationResult would be returned from AddNewUser() message, not sooner
However, for real-life application the good candidates according to Open Web Application Security Project (OWASP) → Data Validation would be:
..Integrity checks must be included wherever data passes from a trusted to a less trusted boundary, such as from the application to the user's browser in a hidden field, or to a third party payment gateway, such as a transaction ID used internally upon return..
..Validation must be performed on every tier..
2) ..dashed arrow from the database to the registration page..directly to the if..?
I would extend the execution (activation) down as shown below, but it does not mean that your way is not correct
See also: uml-diagrams.org: UML Sequence Diagrams Examples
3) ..advice..to change?
I would review the use of synchronous/asynchronous messages. It seems that you use one type of arrow for everything