… but of course, only when it comes to IT… We will certainly continue to pay due interest and respect to the archeologically noteworthy menhirs or monoliths from ancient times, not to forget Obelix whom we can hardly imagine without his menhir. For IT, on the other hand, the time has come to do without monolithic applications where user/rights management was included within the business application. In the wake of cloud computing and SaaS, this link between application servers and identity infrastructures has been cut, to be closed again with methodologies such as federated security.
Common monoliths – directory services
Certainly you still remember the 2000ies with their Y2K issues. Within this first decade of the 21st century, Microsoft, vendor of the de-facto standard Windows Domain System, launched Active Directory as a state-of-the-art and powerful LDAP directory. This technology was quickly adopted by many applications, creating an ecosystem where single sign-on became the standard for Windows applications.
Federated security for IT
The 2000ies are over, and our world has experienced profound and dramatic changes. As opposed to Asterix and Obelix, who fought successfully against the changes going on in their world, IT must be flexible and responsive to such changes. Software-as-a-service applications find their way into business environments. Applications are provisioned by managed service providers, and temporary business allies collaborate within one service. IT is challenged to grant application access to end users without allowing the application to query the user database, for instance, Active Directory, directly. Server-to-server communications are highly unsuitable for such scenario and also much too restrictive on applications. Therefore, federated security is used for software-as-a service, web and, increasingly, for on-premise or native applications. In simple terms, only the client (web browser) needs access to the authorization mechanism and the actual application when this method is used. Both must be trusted applications, which is defined in common protocols such as SAML2 or oAuth2.
Obelix the gold-seeker – about tokens & claims
Both the SAML2 and the oAuth2 protocol are essentially based on the exchange of security tokens between both systems; i.e., the browser as client requests an authorization token at the server that handles the log-in. This token normally has a digital signature by the private key of the authorization system; information within the token is not encrypted, but this is not really necessary. The primary goal is to ensure that authorization information about a user comes from a trusted source and is not changed on its way to the application. TLS/SSL-based encryption is evolving into a standard. The application can validate the signed token with the public key of the authorization system. For this purpose, Matrix42 MyWorkspace uses an end-to-end asymmetric encryption methodology, based on X509 certificates.
If a security token can be created and validated by an authorization system, information on a user’s rights to use an application can be stored within this token; these “claims” define which rights and roles a user is granted in the target application. The oAuth2 protocol uses the JWT token format, which is described in more detail in the this article.
Resisting changes, in a positive sense
Federated security is an approach that ensures security by protecting information against changes, rather than encrypting this information, which means that while authorizations are not encrypted, but can be viewed by all involved parties, their origin and consistency are protected by a digital signature – one of the next blog articles will examine the most popular protocols, SAML2p and oAuth2, from a technical perspective.
While IT monoliths can be replaced, Obelix, on the other hand, shall be allowed to keep his monolithic menhir as a powerful “supporting argument” to defend and protect his world.
