What are the requirements for enterprise event security?
In a SOA, to be effective, we need to share both data and events. Events, as I have discussed before, are the messages that applications send to the common infrastructure to inform subscribers that well-understood business events have occurred. This includes things like "a sale was made" and "a product was shipped." It may also include things like "an employee has ceased working for the company."
The last example above, an employee quits or is fired, is interesting. From the employee's standpoint, it may be a private event. If they were fired, it may be quite embarrassing, not something they want broadcast. On the other hand, from the viewpoint of the company, it could be of very high importance that the applications in IT be immediately notified of the employee's dismissal, so that all permissions can be revoked, and workflow processes involving that person can be redirected to another person or team to accomplish.
Revocation of credentials: we've got Active Directory. That one is fairly straight forward for a Microsoft-based IT team.
Changing workflow: most folks screw this up. I've seen my share of workflows. It is rare, to say the least, to find a workflow system where the business told IT to prepare for the day when their employees would be fired. Mature systems usually add the event handling somewhere... sometimes it is entirely manual, occasionally requiring a data support analyst to write a SQL Query to reassign tasks from one person to another. That's a mess.
So clearly, we need to share the firing of an employee as a broadcast event in the IT infrastructure. The question is this: do we secure it?
The ramifications of placing security models in an EAI space are oddly different than similar situations in an application. If an app knows that Joe can access Contoso's sales record but Mary cannot, then Mary doesn't see it. Pretty simple. However, the app knows. We, as developers, can still build in referential integrity around the fact that the sale was made. By extension, if an event occurs in another system, this system may need to know about it, even if NONE of the users of this system need to be informed about it.
It may sound striking, but when you look at it, it makes sense. Applications have their own identitiy, and their own security. They are full actors in the system. An app can see an event. In fact, I would say that all apps that support the enterprise security model should be allowed to subscribe to ANY event.
Of course, I said the key words: apps that support the enterprise security model. What does that mean? That means that there is a way for an event to either carry security in the event message or in the subscription process, so that the apps that subscribe to the event respect the right of the enterprise to control who, among the human population, can see the event. It's a little like saying that the app has signed the corporate NDA and will respect the wishes of the company to keep some data secure, even from its own users.
In other words, it is OK to allow our apps to see things that we, as human users, cannot see. Certainly, the support analysts will need the right to investigate exceptions and find data errors. Other than exception handling and auditing, it is entirely reasonable to restrict events to be viewed by the app, but none of the users of the app.
So, how do we correctly share and manage event security? That is the question I'd like to answer.
If you know of a good answer, please drop me a link. I'm investigating two avenues:
- Including the security policy in the event message itself, and/or
- Including the security policy in the subscription, so that the subscriber has a consistent policy to follow for all events.
If you know of a good answer to this question, please share it.