Hi,
on Friday, I've successfully did a POC on combining OpenXPKI with
Request Tracker (RT), a widely used tracking system (see
http://bestpractical.com/rt/). This would be really useful for people
who have a lot of certificate requests and lots of E-Mail communication
related to them.
Martin and I just had a quick brainstorming session how to abstract this
kind of thing a "notification" layer. Our idea is the following:
Within the workflow activities, CTX('api')->notify() is called, for
example when a CSR is created with CTX('api')->notify('csr_created').
The server then looks at its config file. In the PKI realm definition,
it finds zero or more notifiers, for example like this:
<notification>
<notifier>I18N_OPENXPKI_DEPLOYMENT_TEST_NOTIFIER_RT</notifier>
</notification>
The notifiers are defined in notification.xml, which might look similar
to the following:
<notification_backend type="RT" id="default">
<url>...</url>
<username>...</username>
<password>...</password>
</notification_backend>
<notification_backend type="email" id="default">
<from>...</from>
<comment>[EMAIL PROTECTED]</comment>
</notification_backend>
<notifications id="default">
<notification id="csr_created">
<action type="open" requestor="[% creator %]"/>
<action type="comment">
<template file="/path/to/filename" lang="de_DE"/> <!-- TT -->
</action>
<action type="communication">
<template file="/path/to/other_file" lang="de_DE"/>
<!-- like e-mail: key: value pairs, separated by \n, body starts at
\n\n, comments using # -->
</action>
<action type="set_value" field="workflow_id" value="[% workflow_id %]">
<action type="set_value" field="priority" value="9"/>
</notification>
<notification id="...">
</notification>
...
</notifications>
<notifier id="I18N_OPENXPKI_DEPLOYMENT_TEST_NOTIFIER_RT">
<notification_backend type="RT" super="default">
<queue>...</queue>
</notification_backend>
<notifications super="default">
<!-- already has some notification from parent has it -->
<!-- additional notification -->
<notification id="certificate_issued"/>
<action type="communication">
<template file="/path/to/file" lang="en_EN"/>
</action>
<action type="close"/>
</notification>
</notifications>
</notifier>
So a notifier both has a notification_backend, which could for example
be RT, a simple e-mail class, or a driver for a different ticketing
system. It also has a list of possible notifications with corresponding
actions. If a notification is requested using CTX('api')->notify(), the
actions are executed (for example, a new ticket is opened, a comment is
attached to the ticket, communication is sent out to the user, etc.).
Most of these will use variable data, which can be input into the system
using Template::Toolkit (with the possibility to use all context
variables, similar to the code I recently checked in for smartcard
personalization). Templates may have a header consisting of key/value pairs,
which can be typical e-mail headers such as To, CC, etc., but may also
consist of custom fields that are then communicated to the backend
(RT for example allows for custom fields, which can be used to
create a link to the CSR, certificate identifier, etc.)
In systems where certain actions do not have a valid meaning (such as
opening a ticket in an e-mail-only system), they may just have an empty
implementation.
As usual, XML inheritance is used to inherit from some sane default.
Please let us know what you think about this structure. Is it flexible
enough for the future? Are we missing something? Any ideas for better
names?
Regards,
Alex
--
Dipl.-Math. Alexander Klink | IT-Security Engineer
[EMAIL PROTECTED] | working @ urn:oid:1.3.6.1.4.1.11417
-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier.
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
OpenXPKI-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/openxpki-devel
