There are 5 parts of setting up an authorization manager:
A) Defining what the resources are (often services or service functions, but can be anything you want to protect).
B) Defining who the actors (typically users) are.
C) Defining which roles you want actors to be able to participate as towards the application server.
D) Defining authorizations for actors or roles on resources.
E) Optionally defining constraint on authorizations and/or logins.
Normally, the only one who really knows which resources exists, is the developer of the application server as a
resource typically is very
application server type specific (service name, function name, virtual
function/external file name or something like that).
Resources would usually always be defined in the application server, and never be picked up from a database, unless its resources that refers
external files/resources not known by the application server at compile
Similarly with roles. What basic role types are relevant for a particular application server is normally known at compile time. Hence they would typically also be defined by the developer, early on.
Actors can be defined at compile time, but thats not the typical use scenario, except for internal actors that cant be used for login from outside (see next paragraph for an example). Most often you want to maintain an external database/configuration file where the actor, which his password and default role is stored.
Authorizations for a resource is typically defined on a role, but _CAN_ also be linked directly to an actor, although I want to discourage that scenario, unless you define the actor at compile time, in which case the actor is typically used for some internal special security stuff, that are not to be messed with by an human administrator. An example is a special actor that do not allow login as the actor, but that do allow for internal execution of one service from another service.
Authorizations most often makes sense to define at compile time. There could perhaps be imagined scenarios where a role should have more or less authorizations towards resources depending on time of day or other constraints, but that is why the constraint definition exists (ie.. only allow being an administrator from 9:00-17:00, outside this timespan, disallow administrator login etc). If you want to have multiple levels of administrators (one with time limits and one super admin role without time limits) define two roles, and limit login with constraints on one of them.
So what you want to define in an external database/configuration file, typically boils down to real human actors with passwords and the default role they have when logging in. The remaining bits are usually known at compile time or at least as a one time configuration when the server starts up.
The login process, that validates given credentials with defined authorizations, is a crucial part of the authorization manager.
Thus one way or the other, you will want to call the Login method of the authorization manager. It can happen by explicitly calling the Login method in a service function which is not protected by the authorization manager (or else you would probably not be allowed to execute that function in the first place), or you can let the application server automatically determine when a login is needed.
The later is the easiest way. For that to happen, you must set the TkbmmWAuthorizationManager.Options to include the mwaoAutoLogin flag.
With that setting, if a client tries to call a server service, and the client is not providing a TkbmMWClientIdentitity.Token (its empty), the authorization manager will attempt a login with the username and password provided in the TkbmMWClientIdentity, and an empty role name.
If the login succeeds, a new server generated token will be returned to the client, which should be used in subsequent requests for the duration of the login.
The Login call itself, first tries to lookup an actor and if a role name was given (which is not the case when using mwaoAutoLogin) the role.
Since the actor is not known by the authorization manager at this point in time (a TkbmMWAuthorizationActor has not been predefined), the login will fail, unless you put some code in the OnLogin event handler.
The eventhandler will be called with the provided username (AActorName) and password (APassphrase).
You will also get a reference to whatever TkbmMWAuthorizationActor that the authorization manager have found for your. It will be nil, if the user with that username has not logged in since last application server startup.
Now its your responsibility to lookup that username/password for example in a database, determine what (predefined) role the person should have and return those values in the AActor and ARole arguments of the event.
Lets say you lookup the username/pwd in the database and fails to find a person matching, you would simply return AActor:=nil and ARole:=nil, and optionally set AMessage to some text that explains the reason for the failure to login.
If you do find the username/pwd in your database, you first lookup which role the user should have. Eg:
Then, if the provided AActor was nil, you MUST define the actor on the TkbmMWAuthorizationManager by calling AddActor with the username/password and the looked up role and return that actor. Eg:
Next step after the login, is the authorization manager authenticates the actual request the client is making.
That usually happens automatically according to your predefined authorizations/constraints.
You _can_ also hook into this, by the OnAuthorize event. Usually you will at most disallow an otherwise given authorization, this way, by setting AAuthorization:=nil if you do not allow the actor to access that particular resource, even though your authorization rules has allowed it.
You can logout a user by calling AuthMgr.Logout, or let the logout garbage collection handle it. I.e. if a user has been inactive for too long, it can be auto logged out (DefaultMaxIdleTime property on the authmgr given in secs - default 1 hour).