Authentication

Security is a very large topic for Service Layer implementers, and the scope is too broad for a short article like this one. So I’ll just discuss the most obvious aspect of it – user authentication.

If the Service Layer is to have great value, it needs to provide a homogeneous authentication approach. A typical goal would be to have authorization decisions somehow externalized so that the Service Layer could handle that automatically in the context of the universal authentication scheme.

Unfortunately, what we normally see is a much more difficult situation. Legacy systems were built over a long period of time by people who did not know each other, who did not share common goals, who did not understand enterprise architecture, and to whom security was a last-minute add-on. As a result, the various authentication schemes that back-end systems implement are eclectic and thus hard to mold into a seamless whole, which is the goal of the service layer.

Examples of legacy authentication approaches that we found included standard mainframe RACF or ACF, single-system userid/password repository and even one that used a “trusted IP”. Trusted IP means that if your IP address is in their table, you can just come on in.

Approaches to getting authorized access to the enterprise system can be divided into two types: transitive and user-specific. In the transitive approach, the portal itself is an authorized user of the enterprise system which implicitly delegates authorization chores to it carte blanche. A typical implementation is to create a user with full access rights and let the portal authenticate as that user. Then it’s up to the portal to prevent unauthorized access. Obviously, this is a weak approach and should only be considered when the cost of a compromise is low and the cost of user-specific authentication is high, or if a user-specific approach is simply not feasible.

A user-specific approach can be implemented in several different ways, depending on what the target system requires. Two that we tried are the Replay Technique and the Secondary Table Technique. Neither one of these is very satisfying, either. In the Replay Technique, the portal steals the session token that is generated by the authentication server (in this instance Netegrity SiteMinder). It passes the token as a parameter in the request to the Service Layer and it eventually filters down to the Requester Adaptor which replays it in the request to the enterprise system. This works only if the token decay is long enough and if the target is defended by the same system component that generated the token in the first place.

1

• Next

Home
Webinars
Blogs
Subscriptions
White Paper
Analyst Corner

Goals

Enabling Business Agility and Reuse
Improving Business Processes
Leveraging Information and Intelligence
Governing the Infrastructure
Leveraging the Connected Web
Securing Enterprise Applications
Supporting Industry Solutions

About Us
Editorial Calendar
Feedback
FAQ
Advertise With Us
Site Map
Privacy Policy
Unsubscribe