Monday, May 18, 2015

Connected Identity: Benefits, Risks & Challenges - EIC 2015 Recording


Friday, May 15, 2015

Two Security Patches Issued Publicly for WSO2 Identity Server 5.0.0

Wolfgang Ettlinger (discovery, analysis, coordination) from the SEC Consult Vulnerability Lab contacted WSO2 security team on 19th March and reported following three vulnerabilities in WSO2 Identity Server 5.0.0.

1) Reflected cross-site scripting (XSS, IDENTITY-3280)

Some components of the WSO2 Identity Server are vulnerable to reflected cross-site scripting vulnerabilities. The effect of this attack is minimal because WSO2 Identity Server does not expose cookies to JavaScript.

2) Cross-site request forgery (CSRF, IDENTITY-3280)

On at least one web page, CSRF protection has not been implemented. An attacker on the internet could lure a victim, that is logged in on the Identity Server administration web interface, on a web page e.g. containing a manipulated tag. The attacker is then able to add arbitrary users to the Identity Server.

3) XML external entity injection (XXE, IDENTITY-3192)

An unauthenticated attacker can use the SAML authentication interface to inject arbitrary external XML entities. This allows an attacker to read arbitrary local files. Moreover, since the XML entity resolver allows remote URLs, this vulnerability may allow to bypass firewall rules and conduct further attacks on internal hosts. This vulnerability was found already before being reported by Wolfgang Ettlinger and all our customers were patched. But the corresponding patch was not issued publicly. Also this attack is not harmful as it sounds to be since in all our production deployments, WSO2 Identity Server is run as a less privileged process, which cannot be used to exploit or gain access to read arbitrary local files.

WSO2 security team treats all the vulnerabilities that are reported to security@wso2.com, top most important and we contacted the reporter immediately and started working on the fix. The fixes were done on the reported components immediately - but we wanted to make sure we build a generic solution where all the possible XSS and CSRF attacks are mitigated centrally.

Once that solution is implemented as a patch to the Identity Server 5.0.0 - we tested the complete product using OWASP Zed Attack Proxy and CSRFTester. After testing almost all the Identity Server functionality with the patch - we released it to all our customers two weeks prior to the public disclosure date. The patch for XXE was released few months back. Also I would like to confirm that none of the WSO2 customers were exploited/attacked using any of theses vulnerabilities.

On 13th May, parallel to the public disclosure, we released both the security patches publicly. You can download following patches from http://wso2.com/products/identity-server/.
  • WSO2-CARBON-PATCH-4.2.0-1194 
  • WSO2-CARBON-PATCH-4.2.0-1095 
WSO2 thanks Wolfgang Ettlinger (discovery, analysis, coordination) from the SEC Consult Vulnerability Lab for responsibly reporting the identified issues and working with us as we addressed them, at the same time we are disappointed with the over-exaggerated article published on threatpost. The article was not brought into the attention of WSO2 security team before its being published, although the WSO2 security team responded to the query by the reporter immediately over email. Anyway we are fully aware that such reports are unavoidable and not under our control.

WSO2 security team is dedicated to protect all its customers and the larger community around WSO2 from all sort of security vulnerabilities. We appreciate your collaboration and please report any of the security issues you discover related to WSO2 products to security@wso2.com. 

Tuesday, May 12, 2015

MQTT Security Fundamentals

Saturday, May 9, 2015

Identity Mediation Language (IML) - Requirements Specification

A recent research done by the analyst firm Quocirca confirms that many businesses now have more external users than internal ones: in Europe 58 percent transact directly with users from other businesses and/or consumers; for the UK alone the figure is 65 percent. If you look at the history, most enterprises grow today via acquisitions, mergers and partnerships. In U.S only, mergers and acquisitions volume totaled to $865.1 billion in the first nine months of 2013, according to Dealogic. That’s a 39% increase over the same period a year ago — and the highest nine-month total since 2008.

Gartner predicts by 2020, 60% of all digital identities interacting with enterprises will come from external identity providers.

I have written two blog posts in detail highlighting the need for an Identity Bus.
The objective of the Identity Mediation Language (IML) is to define a configuration language, that would run in an Identity Bus - to mediate and transform identity tokens between multiple service providers and identity providers in a protocol agnostic manner.

The objective of this blog post is to define the high-level requirements for the Identity Mediation Language. Your thoughts/suggestions are extremely valuable and highly appreciated to evolve this into a language where the global identity management industry will benefit.

1. Transform identity tokens from one protocol to another.

For example, the Identity Mediation Language should have the provision to the transform an incoming SAML request into an OpenID Connect request, and then the OpenID Connect response from the Identity Provider into a SAML response.

2.  The language should have the ability define a handler chain in inbound-authentication-request flow, outbound-authentication-request flow, outbound-authentication-response flow, inbound-authentication-response flow and any of the major channels identified as this specification evolves.


3. The language should define a common syntax and semantics, independent from any of the protocols.

Having a common a common syntax and semantics for the language, independent from any of the specific protocols will make it extensible. Support for specific protocols should be implemented as handlers. Each handler should be aware of how to translate the common syntax defined by the language to its own on syntax - and how to process them in a protocol specific manner.

Following is a sample configuration (which must evolve in the future). Language is not coupled to any implementations.  There can be global handlers for each protocol, but then again, should be able to override in each request flow if needed.


  "inbound-authentication-request" : 
              { "protocol": "saml", 
                 "handler" : "org.wso2.SAMLAuthReqRespHandler"
               },
  "outbound-authentication-request" :
              { "protocol": "oidc",
                 "handler" : "org.wso2.OIDCAuthReqRespHandler"
              }
}

4. The language should have the provision to define a common request/response path as well as override it per service provider.

5. The language should have the provision to identify the service provider by a unique name or by any other associate attributes. These attributes can be read from incoming transport headers or from the Identity Token itself. If read from the ID token, the way to identify that attribute must be protocol agnostic. For example, if the incoming ID token is a SAML token, then - if we need to identify the issuer from  an attribute in the SAML token, the language should define it as an XPATH, with out using  any SAML specific semantics.

6. The language should have the provision to define, whether an incoming request is just a pass-through.

7. The language should have the provision to define, which transport headers should be passed-through to outbound-authentication-request path.

8. The language should have the provision to define, which transport headers needs to be added to the outbound-authentication-request path.

9. The language should have the provision to log all the requests and responses. Should be able to configure logging per service providers. Log handler should be configurable, per service provider. Due to PCI compliance requirements we may not be able to log the complete message, all the time.

10. The language should have provision to retrieve attributes and attribute metadata, required by a given service provider, via an attribute handler. Also - it should have the provision to define attribute requirements inline.

11. The language should have provision to define, authentication requirements per service providers. The authentication can be using one more - local authenticators, federated authenticators or federated authenticators. The local authenticators will authenticate the end user, using a local credential store. The federated authenticators will talk to an external identity provider to authenticate users. The request path authenticators will authenticate users from the credentials attached to request itself.

12. The language should have the provision to define, multiple-option and multiple-steps authentication, per service provider. In multiple-option scenario, the relationship between in authenticators is an OR. That means, user needs to authenticate only using a single authenticator. With multiple-steps, the relationship between steps is an AND. User must authenticate in successfully in each step.

13. The language should have the provision to define, multiple-option and multiple-steps authentication, per user. The user can be identified by the username or by any other attribute of the user. For example, if user belongs to the 'admin' role, then he must authenticate with multi-factor authentication.

14. The language should have the provision to define, multiple-option and multiple-steps authentication, per user, per service provider. The user can be identified by the username or by any other attribute of the user. For example, if user belongs to the 'admin' role and if he accesses a high-privileged application then he must authenticate with multi-factor authentication, if the same person accesses the user profile dashboard, then multi-factor authentication is not required.

15. The language should not define any authenticators by itself.

16. The language should have the provision to define, authenticator sequences independently and then associate them to an authentication request path, just by a reference. Also should have the ability to define them inline.

17. The language should support defining requirements for adaptive authentication. A service provider may have a concrete authenticator sequence attached to it. At the same time, the language should have the provision to dynamically pick authenticator sequences in a context aware manner.

18. The language should have the provision to define, per service provider, authorization policies. Authorization policy may define the criteria under which an end-user can access the given service provider. Only if its satisfied by the authenticated user, the identity provider should send back the authentication response.

19. The language should have the provision to define how to transform a claim set obtained from an identity provider to a claim dialect specific to a give service provider. This can be a simple one to one claim transformation, for example http://claims.idp1.org/firstName --> http://claims.sp1.org/firstName, or a complex claim transformation like, http://claims.idp1.org/firstName + http://claims.idp1.org/lastName --> http://claims.sp1.org/fullName. The language should have the provision to do this claim transformation from inboudAuthenticationRequest flow to outboundAuthenticationRequest/localAuthenticationRequest flow and from outboundAuthenticationResponse/localAuthenticationResponse flow to inboundAuthenticationResponse flow.

20.  The language should have the provision to authenticate service providers, irrespective of the protocol used in the inboundAuthenticationRequest.

21. The language should have the provision to accept, authentication requests, provisioning requests,  authorization requests, attribute requests and any other types of requests from the service provider. The language should not be just limited to above four types of requests and must have the provision to extend.

22.  The language should define a way to retrieve identity provider and service provider metadata.

23. The language should have the provision to define rule-based user provisioning per service provider, per identity provider or per user - and per attributes associated with any of the above entities. For example, if the user is provisioned to the system via foo service provider and if his role is sales-team, provision the user to salesforce. Another example could be, provision everyone authenticated against the Facebook identity provider to a internal user store.

24. The language should have the provision to indicate to a policy decision point (for access controlling), from which service provider the access controlling request is initiated from and also with the other related metadata.

25. The language should have the provision to the specify just-in-time provisioning requirements per service provider, per identity provider or per user - and and per attributes associated with any of the above entities.

26. The language should have the provision to specify, per service provider - the user
store and the attribute store for local authentication and to retrieve user attributes locally.

27. The language should have the provision to specify an algorithm and a handler for force authentication for users already logged into the identity provider. There can be a case where user is already authenticated to the system with a single factor - when the same user tries to log into a service provider which needs two-factor authentication, then the algorithm handler should decide whether to force user authentication - and if so at which level. There can be an algorithm handler defined at the global level and also per service provider request flow.

28. The language should have the provision to specify a home-realm-discovery handler, per service provider. This handler should know how to read the request to find out relevant attributes that can be used to identify the authentication options for that particular request.

29. The language should have the provision to define attribute requirements for out-bound provisioning requests.

30. The language should have the provision to define claim transformations prior to just-in-time provisioning or out-bound provisioning.

31. The language must have the provision to define how to authenticate to external endpoints. The language should not be coupled into any specific authentication protocol.