Identity Server

Security is a key aspect of any successful enterprise SOA solution which allows channels for internal and external parties to access business assets. Security measures should also enable other vital aspects of the solution such as

• Flexibility - By catering to new security requirements which arise with changing business policies
• Interoperability - By facilitating secure communication with heterogeneous systems which talk over different security protocols.

The recent security breaches of major corporations and government agencies once again highlight the importance of implementing an effective security model within an SOA deployment to protect company data, employees, partners and customers. Going beyond authentication, authorization and auditing, security in practice relies heavily on battle-tested security patterns to combat thousands of cyber criminals worldwide seeking to exploit the any security hole in the system. In his WSO2Con 2011 session, Prabath discussed the patterns, best practices and threats associated with SOA security models. He also explored how standards, such as WS-Security, SAML, XACML, WS-Trust, WS-SecureConversation and WS-SecurityPolicy have come to define the ‘best-fit’ security model to an SOA deployment based on Web services. Additionally, he looked at how OpenID, OAuth, and Simple Cloud Identity Management (SCIM) have evolved to provide a ‘best-fit’ security model for Internet identity management. Here are highlights from his talk.

Prabath joined WSO2 in November 2007 and is currently a Software Architect and Senior Manager. He is an Apache Axis2 PMC member and has more than 7 years industry experience. Prior to joining WSO2, Prabath worked at Virtusa (NASDAQ: VRTU) for 3+ years. He has presented at numerous conferences including OSCON, ApacheCon, Apache Asia Roadshow, WSO2Con 2010, and WSO2 SOA Workshops. He has been involved in developing the OASIS Identity Metasystem Interoperability Version 1.0 specification.

This is a step by step guide on how to configure an ASP.NET client with the WSO2 Identity Server Passive STS. We'll be using a simple ASP.NET client and will be configuring everything from scratch. You need to have a recent version of WSO2 Identity Server (V3.2.3 or later).

We learned lot of theory about XACML policies in Part 1. In this section we will define a sample XACML policy using the concepts we learned in Part 1. In addition to that, this article describes how you can test and validate policies using “WSO2 Identity Server”.

Dealing with XML is sometimes very tedious. In the last section of this article, we will discuss how you can use XACML “simple UI ” to define XACML policies.

Carbon products are already connected to an internal LDAP user store by default. We also can configure them to be connected to external user stores such as Apache Directory Server, Active Directory Server in ReadOnly or Read/Write. It is also possible to connect to an external user store using secured LDAP. This tutorial will take you through the steps of how to configure the latter. For this tutorial, we are going to use WSO2 Governance Registry and Apache Directory Server to demonstrate the scenario.

XACML is the widely used authorization mechanisms for web services. XACML provides fine grained authorization. In which one can define authorization based on very finer details. This finer information is stated in the policy as attributes. XACML also defines set of functions, which can be used in authorization logic evaluation. Due to detailed behavior, some believe XACML policies are esoteric and complicated. In this article I will elaborate XACML policies and will give you an idea as how XACML policy evaluation is taking place.

Although XACML can create certain bottlenecks, it cannot be taken completely out of the picture. It is still a good choice for access control and the use of the WSO2 Identity Server can help augment the benefits it provides.

Today enterprise solutions adopt products and services from multiple cloud providers in order to accomplish various business requirements. This means that it is no longer sufficient to maintain user identities only in corporate LDAP. In most cases, SaaS providers also need dedicated user accounts created for the cloud service users, which raises the need of identity provisioning mechanisms to be in place.