Identity
In consequence of the growing openness of IT-infrastructure (Internet, SaaS, public services, remote access, Web 2.0), security based on fortresses (isolated environments) is becoming less adequate. Secondly there is an awareness that security incidents are not only caused from outside these isolated environments, but also from inside such an environment. These aspects together with the introduction of compliancy regulations (be able to quickly proof who did what and when, on penalty of legal sanctions) a trend is recognized toward identity management based security mechanisms. These mechanisms are based on the idea that all components in an IT-environment (people, devices, software) that can act more or less autonomous have an identity. Access to resources is controlled at the resource-level and is based on the identity credentials of the user of that resource.
Service Access
This pattern describes an identity based solution for protecting services against undesired use. Without protection every arbitrary service can call any other arbitrary service. This raises risks with regard to intended and unintended violations of the system. Also with regard to compliancy regulations (knowing who did what and when) such a situation is undesirable. These risks are present even in a fire-wall secured environment.
Arbitrary Service Access
Controlled Service AccessThe solution described in this pattern assumes the availability of a security infrastructure based on identity management.
When a service is called by a caller (service access) the identity credentials of the caller are added to the message. The called service can only be accessed via a proxy (security proxy). This proxy will validate the access rights of the caller based on the credentials passed in the message and the defined access policies before passing the message to the called service. In case of a synchronous communication implementation the identity credentials of the called services are added to the reply to allow the caller to validate the integrity of the reply.
This model supports authentication and authorization of service calls:
- Identity Credentials: proof that a service is who it claims to be (authentication)
- Policies: managing what service may be called by whom (authorization)
Secured Service AccessBy establishing trust relations with external companies, secured service access can be offered to external or federated parties without the need to maintain the external identities; only the (e.g. role based) policies have to be maintained (relying on the adequate role allocation by the trusted party).
Identity Credentials Propagation Trail
The service-access and security-proxy combinations can be chained together. This allows for complex access policies based on a complete chain of identity credentials. For example:
- If D is called by C and C was called by A: access allowed
- If D is called by C and C was called by B: access denied
Credentials Propagation TrailAnti-pattern: security-agent nested in the service
There are products available that offer comparable solutions where a security agent is built into the service in stead of using an external security proxy. Such a solution may be qualified as an anti-pattern. Mixing up security components with the service components decreases flexibility and increases vendor lock-ins. An infrastructure based on embedded agents leads to a load of extra efforts to change the services when you want to choose another vendor in future; proxies can easily be replaced without any effect on the services.
Anti-patternIdentity Credentials in Business Events
Beside passing identity credentials to services (SOA), identity credentials can also be added to published business events (EDA). This allows for the consumer of the message to validate the identity of the source of the message. A trail of identity credentials may be added to the published messages in a process flow to allow for determination of the process flow route, based on the identities of the services in the flow. The figure below illustrates the pattern of identity credentials in a business event.
Identity Credentials contained in a Business Event
Posts
2 comments:
Interesting article but why not XACML? Combining SAML and XACML you would achieve a standards-based Security Infrastructure rather than having to invent it on your own. A SOA architecture that wants to achieve anything on a maturity level beyond a pure "Silo" in terms of the Open Group Service Integration Maturity Model (OSIMM) would indeed benefit from a standardized Security Infrastructure. And higher maturity levels cannot be achieved without it. But once you enter this path, I'd say standards compliance is key. So why not pass let an XACML Policy Enforcement Point (PEP) pass the attributes contained in your SAML ticket to an XACML based Policy Decision Point (PDP) to determine whether access should be granted or not? Cf this Axiomatics article on this.
Hey Thanks a lot for sharing such a nice and interesting article.Really a very nice and detailed review on "How to implement identity based Service Access Control in SOA".
I’ve trying to fix it all day, and your post helped me out a lot.Thanks a lot for sharing it.
By the way for more information on Professional Training and Certification for Security Courses check this link: http://www.eccouncil.org/certification.aspx
Post a Comment