Date: Thu, 28 Mar 2024 17:24:44 +0000 (UTC) Message-ID: <408025499.6704.1711646684349@ip-10-10-7-29.ec2.internal> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_6703_1470144940.1711646684347" ------=_Part_6703_1470144940.1711646684347 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html
See also: Writing Registry Plugins
Some additional conventions are required when writing an Authenticator P= lugin.
FooAuthenticato=
r
.FooAuthenticator
, a=
nd a corresponding Controller. (These are in addition to the other models a=
nd controllers required for Plugins.)
AuthenticatorBackend
, which =
defines some standard interfaces and provides some behind the scenes common=
functionality.$multiple
that=
is true is the Authenticator supports multiple valu=
es, or false otherwise.SAuthController
=
("Standard Authenticator" Controller), which provides some common functiona=
lity.co_foo_authenticators
table will be c=
reated. There is no add
operation or view required. =
The skeletal row will point to the parent Authenticator Model.foo_authenticator/foo_authenticators/edit/=
#
. This will be called immediately after the Authenticator Backend i=
s first instantiated.$enableSSR =3D=
true
in the model.Authenticator
has a hasOne
(ie: 1 to 1) relationship with FooAuthenticator
.cm_foo_authenticators
should include a=
foreign key to cm_authenticators:id
.
cm_foo_authentic=
ators:id
.Model/AuthenticatorBackend.php
. More details are in the next s=
ection.PasswordAuthentic=
ator
Plugin, this Model is Password
and is defined=
in Password.php
. The Plugin must also implement a corres=
ponding Controller, Controller/FoosController.php
. This C=
ontroller should extend SAMController.php
("Standard Auth=
enticator Model" Controller).
actsAs Provisioner
. =
SAMController will handle triggering provisioning under appropriate circums=
tances.=
co_person_id
foreign key) will automatically be made available to Pr=
ovisioner plugins.There are two supported approaches for implementing an Authenticator Plu= gin. Plugins that only need to provide a form, storing the results in the d= atabase, can use the Simple method. Plugins with more complicated requireme= nts, such as redirecting the user to an external service, must instead use = the Complex method.
Foo
or Password
in the above examples; Foo<=
/code> will be used going forward) in schema.xml
as =
usual, and create the Model file (Foo.ctp
) as usual.
View/Foos
direct=
ory:
info.ctp -> ../../../../View/Authenticators/info.ctp
manage.ctp -> ../../../../View/Standard/edit.ctp
fields.inc
file in the same directory that c=
ontains the form elements you need for your Plugin. (See other Authenticato=
r plugins in the AvailablePlugins
directory for examples.=
) The plugin configuration will be available in $vv_authenticator.
Model/FooAuthenticator.php
as described abo=
ve. Specifically, you must
current()
so that it returns the current rec=
ord(s) based on the parameters passed via the function signature. The resul=
ts from this function will be passed to your fields.inc
V=
iew via the $vv_current
variable.
AuthenticatorBackend
that should work for most s=
imple models. This function will also be used to provide data to Provisione=
r Plugins.manage()
so that it implements whatever backend l=
ogic your plugin requires, including data validation and the actual saving =
to the database. You should also create a history record indicating that th=
e Authenticator was updated, as part of this call.lock()
and Authentica=
torStatus
records, or else locked data may be provided to Provisio=
li>
reset()
call.index
view. If you follow the typical ad=
d/delete/edit pattern used by other controllers, the parent SAMController w=
ill take care of much of the busy work for you, and you can simply provide =
a fields.inc
with the typical contents (and symlinks to t=
he Standard views).reset()
is not automatically supported. You can eithe=
r use the standard delete
action to remove an Authenticat=
or, or add your own custom action to the index view (with the usual support=
ing MVC requirements to implement it).status()
call. If your P=
lugin supports multiple Authenticators per instantiation, the result should=
aggregate status across all Authenticators attached to the Backend.FoosController.php
should use $this->calcula=
teParentPermissions()
to calculate permissions for the required acti=
ons in isAuthorized()
.In the Complex method, the plugin is expected to override the controller=
's manage()
action (and reset()
if appropriate) i=
nstead of overriding the model's functions as described above. In other wor=
ds, if you override SAMController::manage()
, you do not need t=
o worry about overriding AuthenticatorBackend::manage()
or
As of Registry v4.0.0 it may be necessary to override current() to provide information to Provisioner Plugins, unless the default=
implementation in
AuthenticatorBackend
is sufficient.
Your controller's manage
and (if appropriate) reset=
code> actions must manually call provisioning at the appropriate point in y=
our plugin's logic. As of Registry v3.3.0, Authenticators may be established during enro=
llment. Authenticator plugins should not trigger provisi=
oning during enrollment.
As of Registry v4.0.0, the plugin must also trigger notification when th=
e Authenticator is updated. The easiest way to do this is with Authen=
ticatorBackend::notify()
, which will handle all the necessary steps.=
When you are finished, your controller should return control to Registry=
by calling $this->performRedirect()
.
... // Finished updating our Authenticator's state in the database if(!isset($this->request->params['named']['copetitionid'])) { // Don't provision or notify if we're in an enrollment $this->Authenticator->provision($coPersonId); $this->Authenticator->notify($coPersonId); } // All done $this->performRedirect();
Use $this->calculateParentPermissions()
to cal=
culate permissions for the required actions in isAuthorized().
As of Registry v3.3.0, Authenticator plugins may expose APIs.