Identity as an access attempt subject identifies itself and initiates authentication flow. Before the authentication decision is made, a target system needs to meet basic requirement namely it has to support the same authentication protocol. Several factors will determine whether an authentication framework will suit end-user, medical institutions, organisation or enterprise needs. Multi-factor authentication model empowers authenticity and can be an enhancement to the most common username and password exchange. Something you know is the Type 1 authentication factor specifying anything that identity owner knows and what can be verified like password, passphrase, mother’s maiden name, ATM PIN, and so on. Something you have constitutes the Type 2 factor allowing authentication authority to verify whether the person owns physical object during authentication flow. This can be any electrical device like a one-time token generator, memory stick, smart card, and so on. Finally, the last Type 3 factor, the
includes all types of biometrics like fingerprints, hand geometry, retina and iris patterns, body movement, voice prints etc. [99]. On top of these three basic authentication factors, there is an additional identity specific factor somewhere you are, which, in a cloud environment, can be simply verified, and additional claims are often transparent to the authentication initiator.
Authentication system usability is often achieved with a single sign-on (SSO) model where the subject, here identity once authenticated is allowed to pass other trusted systems authentication challenges without being prompted. The bottleneck of SSO is that when implemented without well-defined authenticator policies and with lack of multi- factor authentication can expose even highly secure systems. If identity is compromised, all SSO-enabled systems will accept subject authentication claims as legitimate without further verification [99]. Recently Microsoft warned about new Zero-Day vulnerability allowing an attacker to take control over active end-user session through crafted MS Office document using built-in Object Linking and Embedding (OLE) functionality. Such compromised session in SSO enabled environment maintains unsecured access to all interconnected systems.
Cloud-based data sharing model to perform any activities as an access attempt subjects or simply as a passive accessed object should support several authentication technologies and methods including multi-factor authentication and SSO. Only by re-authentication or progressive identity authentication using different factors the data can be effectively protected and hosted in a shared cloud space.
In a cloud computing era any closed trusted environments can provide the best possible security in terms of information confidentiality and integrity, however, such environments fail to deliver high availability. Therefore, these solutions will have difficulties to sustain. New global identity and data sharing models require authentication that will bring data securely into the shared cloud space, where global organisations and institutions such as medical, financial, educational, government frameworks aiming to protect shared data require a reliable and efficient authentication method. Furthermore, cloud computing seeks for authentication protocols that are easy to integrate with existing internal infrastructures. Kerberos is one of the most popular authentication protocols, which successfully secured large infrastructures. However, since it was challenged with cloud-based authentication, it never adapted to new open cloud space [100] without the use of new protocols like Secure Assertion Markup Language (SAML) or WS-Security.
2.8.1 Kerberos
Kerberos is the most popular authentication protocol implemented by some of the largest world organisations and institutions. Many medical institutions use Kerberos as a standalone authentication technology or adapted it as a part of Microsoft Active Directory Domain Services (MS AD DS) product suite. Because of Kerberos architecture, it is often used for single sign-on solutions within relatively closed security boundaries. Any non- kerberized and not joined environment has to maintain its identity repository and authentication, and authorisation systems. Let assume a medical doctor or a general practitioner (GP) have an account in Kerberos federated institutions environment (see Figure 8) and is coming to use X-Ray medical facility where GP does not have any credentials, therefore due to Kerberos constrains the GP is not able to use the facility with currently owned federated account [100].
Figure 8. A trusted subsystem – no Kerberos token exchange possible (source Bertocci, 2011)
In terms of cloud-ready technologies, the Kerberos relies on private-key cryptography where all involved sides have to protect a shared private-key [99]. Even though technically cloud service can be integrated with existing internal Kerberos based authentication systems, in a real-life scenario, for a cloud-based service provider, it becomes difficult to obtain approval from customer’s information security officer for firewall policy amendments. To operate Kerberos requires additional network ports to be open (TCP/UDP 88), what should include Microsoft Active Directory Domain Services (MS AD DS) LDAP ports (TCP 389, 636), as having these two technologies together customer can receive comprehensive access control service.
2.8.2 SAML
Looking at other modern authentication protocols SAML is one of the promising cloud- friendly standards offering very high cross-platform compatibility. SAML was successfully used for global single sign-on (SSO) solutions and was implemented in several products offering federated identity functions [100]. It is interoperable with various legacy authentication and authorisation systems, and it communicates at a high HTTP protocol layer. Therefore, it does not require any modifications to egress firewall access policies at the customer side. SAML will leverage TCP ports 80 and 443, which by default are open in most of the networks passing in the World Wide Web (WWW) contents. It defines a protocol and token XML structure schema including the use of simple object access protocol (SOAP) wrapper to exchange standardised messages between involved authentication flow parties [101].
SAML assertion consists of several features, and in the most generic simplification, it contains information about the issuer of the token and most often it is expressed using Distinguished Name format from X509. It has the subject information of all assertion statements including subject confirmation for relying party (RP) to verify the assertion relationship between the sender and the subject. Additionally, the assertion is a constraint with conditions that are part of the assertion. These constraints validate the time frame when assertion can be evaluated as well as define a recipient or an audience of the assertion (e.g. RP). SAML assertion also includes an attribute statement related to the subject, which in WS-Federation are equivalents of claims [100]. Authentication
statement informs parties about initial authentication of the subject. Assertion also
includes information about authorisation against the object for which access was claimed and this part is called an authorisation statement. It indicates whether a subject can access an object (resource) the way it is specified in the request. Finally, a digital signature verifies the integrity of the token contents, so RP is assured of the authenticity of the assertion. Advice is optional information related to the authorisation itself.