KbmMW 认证管理器说明(转载)

这是kbmmw 作者关于认证管理器的说明，我懒得翻译了，自己看吧。

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

to
external files/resources not known by the application server at compile
time.

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:

ARole:=authmanager.GetRole(somerolename);

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:

AActor:=authmanager.AddActor(AActorName,APassPhrase,somerolename);

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).

best regards

Kim Madsen

C4D