这是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
KbmMW 认证管理器说明(转载),布布扣,bubuko.com
原文地址：http://www.cnblogs.com/xalion/p/3709013.html
