Understanding predefined Worklight authentication realms and security tests
AntonAleksandrov 270005D80F Comment (1) Visits (28427)
Worklight platform provides a variety of different predefined authentication realms and security tests available out-of-the-box. Let’s try to understand how those are working.
This blog assumes that you’re already familiar with concepts of Authenticators, Login Modules, Authentication realms and Security tests. In case not – it is highly recommended to read the Authentication Concepts tutorial at IBM Worklight Getting Started first (htt
All client-server security mechanisms in Worklight are based on a concept of authentication realms and challenge handlers. In most cases the purpose of authentication realm is to get some kind of identity. It can be either user identity (user authentication realm), device identity (device authentication realm) or application identity (application authenticity realm). In addition authentication realm can be used for a non-identity related functionality, e.g. remote disable.
Worklight platform predefined authentication realms
Worklight platform comes with a set of predefined authentication realms.
Worklight platform supports three types of security tests – webSecurityTest, mobileSecurityTest, customSecurityTest. The difference between them is in the predefined authentication realms each of those security tests has. Basically speaking webSecurityTest and mobileSecurityTest are shortcuts – a simplified way to create a security tests targeted for web and mobile environments.
The examples on Figure 1 demonstrate what webSecurityTest and mobileSecurityTest actually are. The security test on a left side is exactly the same as the right side one.
As you can see defining a custom security test contains a lot of boiler plate configuration. Therefore in case your security configuration is close to default security settings you might want to use webSecurityTest and mobileSecurityTest. That said - lets examine how default security tests can be altered and configured. For example by adding a user realm which will be responsible for providing user identity used by the security test.
Security configuration on Figure #2 is one step closer to the real life scenario security configuration. Still, developer will never need to manually define a security configuration like that because this is a default security configuration provided by a Worklight platform. In other words – in case you have not defined any security test protection for your applications, the ones on Figure #2 will be silently used.
In a real life scenario developer would usually need to add his own authentication realms. In case developer creates his own authentication realm named MyUserAuthRealm to authenticate users, the security configuration would be similar to the one shown on a Figure #3:
As you can see, the structure of the security tests has remained unchanged, however it is no longer using the default wl_a
The most complex scenario might be when developer, in addition to previous change, would like to enable both application authentication (authenticity) realm and automatic device provisioning realm. In this case configuration might look similar to Figure #4.
It is important to note that there were no changes in webSecurityTest and its customSecurityTest analogy, as both auto-provisioning and authenticity are irrelevant for web environments. Secondarily, note that cust
Types of protected resources and their default security configuration
There are four types of resources that can be protected using Worklight authentication framework.
In addition to the settings described above Worklight platform provides additional predefined security test – wl_unprotected. Setting securityTest value to wl_unprotected means that the resource will not be protected by any of Worklight platform security mechanisms. This security test cannot be used to protect application environments and event sources as they both require user and device identities. Usually this security test is used to protect adapter procedures that should be publicly accessible without any authentication requirements.