Customer is requesting the addition of resource like "Service Accounts" are done in OpenShift, but to handle 3scale data.

• There is no way to get to an Token without any human interaction relying on the API-Manager GUI.
• This means we cannot fully automate the setup of the Instance. ( e.g. get service tokens for apicast )
• Besides of exposing the system’s seed token - which is not a good idea- we need the ability to request a token on a rest based protocol

This will be useful to CI/CD automation, and should be able to create administrative accounts, without need of manual intervention to get the token of the created account.

as A consequece the following shoud be implemented:
Proposed title of this feature request
--> create 3Scale-Service-Account

What is the nature and description of the request?
--> Currently there is no  operation to create users and continue to work with those in an automated manner.
Due to demands coming along with Infrastructure as code there is the need to fully automate the Administration of 3scale.
Therefore a facility like a technical, administrative user is needed.
A user can be created with an automated rest call -- however the token for this User has to be retrieved in a manual way by personally logging in.This is quite important as authorizing each request is done inside 3Scale and cannot be delegated to an global LDAP-Instance.

Why does the customer need this? (List the business requirements here)->
--> Use 3scale in combination with an Infrastructure-as-code policy.if each and anything becomes 
this is to some degree complementing:
https://issues.redhat.com/browse/THREESCALE-8280
How would the customer like to achieve this? (List the functional requirements here)
3Scale-API:
as ADMIN/ with SystemSeed: UserID =Create technical user user with restcall   serciveaccount-Create-uerser
Change Role to Admin( User ID )Token = serviceAccount_token-create ( UserID ) ( readOnce/immutable )-- new token invlidates old one.

or with a manifest/Operator:
create user having a secretRef this is the name of the secret where the token is stored in. ( like in onenshift. )

For each functional requirement listed, specify how Red Hat and the customer can test to confirm the requirement is successfully implemented.

--> Create servveAccountcreate readOnlytoken for apimanagmentapi
use this in selfmaganed ApiCast

create providerAccounts and users(pl) with this ServiceAccounl-token and check if those are created appropriately.