WSO2Con 2011: Security in Practice (Security Patterns with WSO2 Products) - Prabath Siriwardena
By WSO2Con 2011
- 15 Dec, 2011
One of the most critical components in a security design is authentication to verify the user, but it also carries some of the greatest weaknesses, said Prabath, who remarked, “Even though username/password authentication has been a failure from the Ali Baba era, still we are using it.”
The problem is that users often keep one password for the many accounts they have, which is not recommended and definitely not secure. However, Prabath suggested that the future of authentication could shift to a recognition-based system, completely eliminating the username/password model.
By employing a single identity provider for authentication, Prabath explained, dependent systems can communicate and verify a user through that particular provider. This single sign-on system creates one master user account for various systems and eliminates the risk created from multiple usernames and passwords. Three standards allow for single sign-on authentication: OpenID, SAML2 and Kerberos.
OpenID facilitates decentralized single sign-on, so users do not need to maintain different passwords for different service providers. It only requires logging into the OpenID provider, and the other dependent systems trust this OpenID provider for the authentication decision it provides. Use of certificate-based or token-based authentication gives providers the option to eliminate the use of passwords.
SAML2 is similar to OpenID, but one major difference is that SAML2 supports both single sign-on and single sign-out, meaning users seamlessly log into all other dependent systems and logout from one system. The other big difference is that the SAML2 service provider is tightly coupled to the SAML2 ID provider. The SAML2 protocol requires security design teams to know they want to implement or facilitate SAML2 logins for applications beforehand, whereas OpenID does not.
Kerberos is another standard that facilitates single sign-on. With Kerberos, users log into a specific machine or terminal, and no additional authentication is required for services or Web applications that rely on Kerberos-based authentication.
Federation is another key component to a good security design because enterprises must open up their services to partners, but do so in a secure way, Prabath explained. He also noted that the username/password model doesn’t work, since those users are not in the enterprise user store. To simply and appropriately authenticate outside users, enterprises can implement protocols such as SAML2, OpenID, Security Token Service (STS) and InfoCards, which all allow for federation.
Prabath provided an example about how token-based authentication works. A consumer application in domain A wants to access a resource in domain B. Domain B does not know how to authenticate the consumer application; however the consumer application can go to the STS running in its own domain. The STS authenticates this user and provides a token, which the consumer application can then give to the domain B resource as verification. The resource will accept the request if the particular token is issued from a trusted STS.
“In other words, anybody from domain A can access a resource in domain B with a token from a trusted security token service, and that is how federation works, Prabath said. “It is enabled by WS-Federation and WS-Trust,” he added.
Identity delegation essentially means that administrator-specified accounts can impersonate users. This too is an important factor when designing a security model. Services, such as Twitter and Facebook often ask for usernames and passwords to access information from other accounts, but there is no real guarantee that the login information is safe. The OAuth protocol supports identity delegation, enabling data retrieval without login information.
Authorization policies, which verify what actions a user can take, are another crucial component to a good security design, Prabath said. There are two types of control to manage authorization: role-based access control and attribute-based access control.
With role-based access control, user permissions are attached to a particular role or title allowing access to resources. If a user moves from one role to another, he will not carry permissions, but rather inherits permissions associated with his active position in the company, Prabath explained. Attribute-based access control gives access to resources based on specific descriptors of a user account, such as a user’s age.
“The defacto standard for authorization is XACML,” Prabath said. “XACML is based on XML, the policy language and allows application developers to externalize authorization logic. With XACML, you can define fine-grained policies.” WSO2 has two XACML policy wizards as part of WSO2 Identity Server, Prabath added, “We have a simple wizard for those who are less familiar with XACML and an advanced wizard.”
To learn more about security design best practices and how WSO2 supports different security standards, view Prabath’s full presentation here.