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