where to store the user credentials in an enterprise application(EAI)?

Question

Background/Context

We are developing a Event Notification Service. The application at a high level looks like below:

Our developene scope involves widget and the ENS.

"ENS" acts as a central point of collection for certain types of events that are of interest to users. Any user who wants to know when these types of events occur registers with ENS, which identifies events in order and matches notifications with subscriptions.

The user who wants to subscibe should be a valid user of the intergrated application(db, sap system etc)

The sequence of events:

Now my question is:

What is the best pracitces in storing the Users db, sap etc credentials.

EDIT How often should the user be authenticated? Should be everytime the messages are delivered?(As @duffymo mentioned, if I use this strategy, it will affect the source system)

Additional Info: ENS are the web-services.

ENS polls the SAP(and other applications) and this is where the problem is becoming more complex. In SAP there is data-level authorization. So not all users are allowed to see all the events/data.

If the SAP has PUSHed the data, along with the User info who has authorized to see, then no issues at all.

Case 1: Scheduler is initiated by the ENS

1. User subscribes to a subscription. At the time of subscription, user is checked for his authorization in the SAP system. If OK, then he will be allowed for Subscription.
2. The scheduler runs at the scheduled time.
3. The scheduler identifies the users who are subscribed.
4. The scheduler uses the stored credentials of the users(stroed in ENS) to POLL if the event occured.
5. Notify users if there are changes.

Disadvs here:

• User credentials are stored somewhere external - Security team might not accept it
• Reduntant hits if more than one user is subscribed for the same piece of information

Case 2: Scheduler is intitated by the WIDGET. User creds will be stored in the users local machine only. Diadv:

• If the subscription is daily, and if the user system/widget is not up. The user might miss the notifications that happened on say, weekends.
• Reduntant hits to the server if more than one user is subscribed for the same piece of information.

Answer 1

Usually it's the application that's given credentials to the database, SAP, etc. Individual users would have credentials stored in an LDAP or database; authentication and authorization would be handled as a cross-cutting concern by the application, EAI server, or an appliance like SiteMinder.

Incoming requests would be intercepted and checked for authorization tokens. If the token doesn't appear, check for authentication and authorization. If allowed, create the authorization token and cache it.

This is the usual scenario for web applications. For an event notification situation like yours it's more complicated. You'll have to check for authorization when the user subscribes. You should notify them right away if the user is unauthorized, because you don't want to have to check credentials every time you publish. There will have to be an association between a user, a subscribed event, and the authorization credential.

I see just one problem.

You may broadcast events to an unauthorized user if they subscribe to an event, find out they are authorized, receive the first broadcast, and then become unauthorized for some reason. This suggests that you'll have to check credentials each and every time you broadcast to subscribers. This could become onerous and slow your app down.

Have a look at standards like SAML to see if it can help you.

The caching issue hinges on the comparison between the time between events and between authorization changes. If the time between events is long compared to authorization changes you have to check each time, because you have no way to know if the authorization has been rescinded since the last event.

Answer 2

The way I've seen this pattern implemented most often is that the authorization occurs at the subscription rather than at the back end. The topic hierarchy mirrors the security model of the back-end application. If the back-end has functions for inquiring on Produce, Deli and Grocery, there exist topic nodes with the same classifications. Users who are authorized in the back end system for Grocery are also authorized to the Grocery topic. The authorizations in the back-end system can be periodically exported (frequently this is nightly) and converted to authorization settings on the pub/sub broker. In one implementation I worked on the back-end system would publish authorization changes to the pub/sub broker on a secure administrative topic so that subscriber authorizations would be kept up to date in near-real time.

The notion of passing credentials back to the source system sounds secure at first glance but on deeper inspection has some problems. First, how do you plan to scale this? I have never seen a successful event notification system that did not get heavily reused. Each back-end system will have different requirements for authentication, usually different credentials, different validity and caching requirements, etc. Building the system to flow credentials back to a couple of back-end applications is one thing. Doing it for 10 or 20 is a nightmare.

Assuming that you addressed the problems above, you now have cached user credentials for half the back end enterprise systems in one place. If that one central system is compromised, so are all the back-end systems it talks to. That central system just became the most critical security focal point in the enterprise. Serious security-fu needed to address this problem is costly.

Yes, it is a pain in the butt to make the topic tree and authorizations of the pub/sub broker mirror the security model of the back-end applications. But in the end it is a lot easier (and less costly) than designing a central broker service secure enough to store all the credentials and also capable of validating them across several back-end systems without bogging down the broker or the source systems that publish to it.