Do I need a user story to talk about three predefined users in a security system?

Oscar,

If I understand your question, you are creating a story for logging into a security system with three separate user types.

There are a number of authorization and permission differences between the roles once they enter the application (else, why differentiate?), but to your request, we'll just focus on the "login" part:

1) Are there different login requirements between the three roles?

2) Are there different expected results based on each role logging in (ex: different landing page, field view, etc)?

3) Are the user types (operator, technical, administrator) "static" values, or are User Id's associated with these roles? If static, what prevents an unauthorized user from simply typing in one of the user types? If there is a security structure for associating UserId's to one of these three Users, then where is that process?

4) What do you want the system to do if a different user type tries to log in?

5) Is there password validation involved with the login? Similar to previous question - what do you want the system to do if an invalid password is entered?

Timothy,

I answer your questions bellow:

1) Are there different login requirements between the three roles?

I'm not sure if I have understood your question but these three users (or logins) will have different roles on the system. All of them will have also different passwords.

2) Are there different expected results based on each role logging in (ex: different landing page, field view, etc)?

No. They are allowed to do different things.

3) Are the user types (operator, technical, administrator) "static" values, or are User Id's associated with these roles? If static, what prevents an unauthorized user from simply typing in one of the user types? If there is a security structure for associating UserId's to one of these three Users, then where is that process?

User types operator, technical, administrator are User Id's associated with these roles.
The password prevents unauthorized user.
These three user have permissions with their functionality that is processed when the user is going to execute one action.

4) What do you want the system to do if a different user type tries to log in?

User administrator can create new users on the system. When unauthorized user tries to login he/she will get a message saying wrong name and/or password.

5) Is there password validation involved with the login? Similar to previous question - what do you want the system to do if an invalid password is entered?

Yes, there is a password for all the user.
A message like the previous one.

> As a user, I want to log on to the application, to work with it.
> Acceptance criteria.
>
> 1. Can log with any of these users: operator, technical and administrator.

That's a technical requirement, not a user story. It is predicated on technical assumptions: there will be a logging-on mechanism; there will be certain pre-configured roles; the solution will take the form of an application.

A user story should express how value is obtained by that user as they go about their business. The fewer assumptions that are made about how the solution will be implemented the better. For example, it's unlikely that an end user would "want" to log on. It's more likely that an end user would just want the system to work, and be smart enough to know who he or she is. Then again security might be a key administrator concern, and it might be important to express stories about (say) logging on and verification and validation from that perspective. The stories need to make clear what value is provided to each kind of user.

But I haven't defined any user story about those predefined users. Do I need one about them?

I agree to Ian, best case you don't need a separate user story for this. It might be one of your acceptance criteria like:
"Logging in is possible with the following roles/users: operator, technical and administrator"

Good advise is to involve the team in a grooming meeting: Maybe a separate story might make sense depending on your sprint length, the availiabilty of the team etc. Anyway start with a user story draft/proposal, this will be a good start for a discussion.