I'm not sure, but I think you may be confusing story roles with authorization roles. The user story should not tell you how to implement something. The following user story is an example of user voice form using a role:
As a manager, I need to be able to add a new Foo Report to my Bar so
that I can analyze all Foos and look for issues.
In my experience, the intention here is not to prescribe how to implement authorization, but instead to provide the developer with an idea of the type of person that is using this feature. You may also use a persona, such as "Bob", instead of the role to capture demographics and information about the type of user using the Foo Report. This gives you the context in how the feature will be used.
This should not mean that an authorization role of "Manager" should be created. You can implement your security however you like, so long as a user that is like "Bob the manager" can be given access to report on the Foos in their Bar.
Since my teams work with a lot of security roles on their projects, we use personas instead to avoid the possibility of confusion within the team.
(BTW: My apologies if this is not what you meant, perhaps you are using user roles in a way that I am not familiar with)