Realization of the System for Access Management and Identity Federation with Use of Service Mojeid and the Product Dirx Access

MASARYKOVA UNIVERZITA FAKULTA}w¡¢£¤¥¦§¨ INFORMATIKY !"#$%&'()+,-./012345

Realization of the system for access management and identity federation with use of service mojeID and the product DirX Access.

DIPLOMA THESIS

Jakub Šebök

Brno, Autumn 2014 Declaration

Hereby I declare, that this paper is my original authorial work, which I have worked out by my own. All sources, references and literature used or excerpted during elaboration of this work are properly cited and listed in complete reference to the due source.

Jakub Šebök

Advisor: RNDr. JUDr. Vladimír Šmíd, CSc.

ii Acknowledgement

I would like to thank ﬁrstly to my technical consultant Filip Höfer for his guidance. Secondly I thank to Mr. Šmíd for his advice about methodology and formal formatting of the thesis. And lastly I would like to thank all who survived by my side and cheered me up espe- cially during last months before the deadline. These are namely my mom, my girlfriend, Anton Gierlti, Matej Chrenko, Buddha and Bill Cosby. Thank you all again for enormous support.

iii Abstract

The aim of this thesis is implementation of a client program on the side of DirX Access which cooperates with the Czech identity provider mojeID. This cooperation consists of authenticating users by third party authority such that their credentials can be used for further processing in access management mechanism of DirX Access.

iv Keywords security, SSO, OpenID, policies, RBAC, identity, mojeID, access management, authentication, authorization

v Contents

1 Introduction ...... 3 2 Internet Security and Terminology ...... 5 2.1 Identity ...... 5 2.2 Identity Provider and Relying Party ...... 6 2.3 Claims vs. Credentials ...... 7 2.4 Identity and Access Management ...... 7 2.4.1 Discretionary Access Control (DAC)...... 8 2.4.2 Attribute-Based Access Control (ABAC).....8 2.4.3 Role-Based Access Control (RBAC)...... 8 2.5 Policies ...... 10 2.6 Authentication Patterns ...... 13 2.6.1 Single Sign-on (SSO)...... 14 2.6.2 One Time Password (OTP) Authentication... 14 2.7 OpenID 2.0 Protocol ...... 14 2.8 Federation and Federation Endpoint (FEP) ...... 15 3 Systems ...... 17 3.1 mojeID ...... 17 3.1.1 OpenID Mechanism...... 18 3.1.2 Yadis...... 19 3.2 DirX Access ...... 20 3.2.1 Principle of Working...... 22 3.2.2 Cooperation with Third Parties...... 24 3.3 Concept of Cooperation ...... 24 4 Integration ...... 26 4.1 Technologies ...... 26 4.2 Model ...... 27 4.3 Questions ...... 29 4.3.1 Question 2...... 29 4.3.2 Question 3...... 29 4.3.3 Question 4...... 30 4.4 Project Scope ...... 30 4.4.1 The Client...... 32 4.4.2 Initial Request Handling...... 32 4.4.3 Callback Request Handling...... 33 4.4.4 Error Handling...... 34

1 4.4.5 Contexts...... 35 4.4.6 User Proﬁle...... 35 4.4.7 Web Application...... 35 5 Conclusion ...... 37 5.1 Further Steps ...... 37 A Program Testing Manual ...... 41 A.1 Deploying Application ...... 41 A.2 Running Application Without Deployment ...... 41

2 1 Introduction

Security is a word that shapes today’s image of IT sphere. It is simply because information is the gold of the new era and has sometimes higher price than anything materialistic. Protection thus became the main issue discussed and considered while designing any new piece of software. Many ways of protecting information were created throughout the years of existence of network communication. They differ from example to another but lot of them follow same principles of Internet communication. Basic principles of security can be derived from the methods used long ago computers. Information delicacy was also concern when messages were sent between emperors or others whose secret was not supposed to be revealed. One can imagine those security measures from the real life experience. Key locks, city walls and gates, guards and many many more were used as forms of keeping unpriv- ileged people away from protected content. So if we look at the principle behind this methods we will see there is always person trying to pass through the guarding system to the protected resource. In order to achieve this they need at ﬁrst to prove who they are by possession of the key or by persuading guards, what we call an authentication process. Secondly, as a result of successful authentication, they are granted access to the protected content e.g. entrance to the inner city or to the locked chamber, what we call an authorization. Authentication and authorization are two areas that covers functionality of the basic security measures also today. The question of authentication in computer society is handled with respect to the machines and humans acting in message exchange processes. Each com- puting unit has its own production number and MAC address by which it can be recognized among other machines as well as among other Internet-connected appliances. Authorization in the other way is focused on people with an aim to assign privileges to someone rather than to something. If we go back to our example we would be talking about giving permission to person having the key rather than giving them to that particular key. However in reality, anybody having the key can hypothetically open matching key lock, but this is not intended way to think about this example because we also do

3 1. INTRODUCTION not give the key from our house to any stranger. The subject of this thesis stands on mentioned security basics and aims to increase authentication side of product DirX Access with the help of service mojeID enhancing this very area of Internet security. In chapter two we will discuss terminology and describe in details mechanism of relevant security protocols. In chapter three we take a look at both systems that are intended to cooperate. That will emerge in chapter four describing how the integration was done. And ﬁnally in chapter ﬁve we will come to the conclusion found out from the results of previous chapter.

4 2 Internet Security and Terminology

Internet grew over the last four decades and so the amount of web services working at this layer. Almost each service desires to know by whom it is used and terms such as identity, identity provider or service provider became a part of our everyday life. Even if we do not say them or write them. We spoke earlier about distinguishing humans and machines when it comes to authentication. Word identity is in this context vague and can represent both. For cases like this we should specify the frame in which we will lead our words to be clear and understandable. We will start with an elementary deﬁni- tions and follow with more complex ones.

2.1 Identity

Specification of a word as such is never easy and that is valid not only for linguists. When word occurs in different contexts it may gain distinct meanings and it is often upon the people who adopt this word to provide an exact characteristics of it so it can be properly set into the context. There have been debates about the content of the identity and how it should be described in technological sense. According to Rannenberg[1] the word identity cannot be conceptual- ized and put into the boxes. Online community refined identity as a set of attributes deterministic for recognition of any subject described by them. Moreover he does not talk strictly about identity. He claims that identity derived from human’s profile and refers to so called "profiling" process defined by M. Hildebrandt: "Profiling is the process of ’discovering’ patterns in data in databases that can be used to identify or represent a human or nonhuman subject (individual or group) and/or the application of profiles (set of correlated data) to individuate and represent an individual subject or to identify a subject as a member of a group (which can be an existing community or a ’discovered’ category)."[2] To sum it up, we will perceive identity in an IT context as a deterministic set of attributes defining an online entity substituting real person, group, organization or unit having sense to exist by itself.

5 2. INTERNET SECURITYAND TERMINOLOGY 2.2 Identity Provider and Relying Party

Identity on Internet serves people as a virtual representation of themselves. Users can use their identity tokens to identify (authenticate) themselves for services. In the past, common practice for identity providing used by services was to have their own databases containing personal information about previously registered users. As a result, users had as many identities as services that they used. This did not only lead to redundancy of information piling up but also to the increased number of credentials necessary for claiming one’s identity. Problems with forgetting user names and passwords became more and more common and IT society needed to think about the solution to this problem. As presumed a solution finding tendency headed towards reducing redundancy by centralizing identities on one place. Identity provider is an authority storing identities of others with a right to claim who they are on their behalf[3]. Plenty of identity providers now exist across the internet who gather data about users and give them an easy reusable tool for their governance. Some of them developed from social networks or great companies which already had a bunch of identities stored in their databases and wanted to provide option for their users to use already filled-in credentials to be verified in their brother systems or on other places (e.g. Google and Facebook). Another part was founded just with a business plan targeted on identity providing as an enhanced remote security measure. The second half of story that makes identity providers work is an assumption that services which needs user’s verification exists and such web services want to cooperate with an identity providers. By relying party we mean a service provider which is in a relationship with an identity provider such that this identity provider gives an information about user to the service provider that relies on it. Simply, relying party is any service provider which relies on external authentication of users. Within this context we may run into words "trusted authentication". The term trusted authentication was introduced exactly with an evolution of remote authentication process. "Trusted" because we trust third party acting as an authority to donate us with a valid data.

6 2. INTERNET SECURITYAND TERMINOLOGY

It is wise to trust only authorities having a certiﬁcate. Such authorities able to claim about themselves that they are reliable, must be entitled for this activity by governmental organ which consequently takes responsibility for its credibility.

2.3 Claims vs. Credentials

In the context of identity providers and relying parties we often use terms claims/attributes and credentials. It may come confusing when we are talking about them in a way describing user’s data. Never- theless they shouldn’t be confused. Claims or attributes are individual data describing the current user. Each of them forms a piece of identity. Claim or attribute can be for example first name, last name or date of birth. But it can be also non-personal information bounded to the processed identity within identity provider context such as validity flag, seconds until authentication sustains or authentication request scope. To obtain claims and user’s attributes, users have to present their credentials which somehow unlock access to this data. Credentials widely used on Internet are log-in nick name in combination with password, but it can be as well user’s certificate or something else. To sum it up, every data that are used along authentication process are marked as user’s credentials. They are confidential and never given to a third party because they act as a private key[4].

2.4 Identity and Access Management

Identity and Access Management (IAM) is a security discipline that handles management of individual principals, their authentication an authorization in order to dismantle repetitive tasks, decrease cost and increase security of processes within business boundaries[5]. Identity management has an eye on the handling large numbers of identities. It tries to solve tasks such as clustering, distribution, provisioning or performing elementary operations on top of stored identities. By access management we usually understand management of a set of access rights. That encapsulates organizing them by certain

7 2. INTERNET SECURITYAND TERMINOLOGY pattern, assigning and forbidding rights for entities. Methods of access management have been invented according to an instance which is in their focus from the triple: subject, right, resource. For the purpose of this thesis only relevant ones, that are implemented in DirX Access, will be introduced.

2.4.1 Discretionary Access Control (DAC) Word "Discretionary" in DAC determines an aim of the method by telling that rights assignment can be discretionary in a sense that rights can be assigned to users or groups which can discretionary pass the rights (even indirectly) to other entities. In opposing to DAC there is often talk about MAC - Mandatory Access Control which stands behind an opposite approach. In MAC rights can be assigned only to the subjects that are permitted to have them and there is no possibility for it to pass it forward. Both approaches can be implemented together as well as each on its own. By implementing them aside we get a system where DAC refers to one category of access controls and MAC imposes a restric- tive policy upon the DAC with another set of controls[6].

2.4.2 Attribute-Based Access Control (ABAC) ABAC is a mechanism of granting right through the attributes grouped into the policies while these attributes can be voluntarily oriented (user attributes, resource attributes, environment attributes etc.)[6].

2.4.3 Role-Based Access Control (RBAC) The most important control schema for our purposes is the RBAC.It is natural to humans to assign people some privileges, position or role. Role-centered approach was as a solution founded to mirror an hierarchy of any organization and copy the needs and setup of the real world[7]. In RBAC system, access rights are assigned to the roles rather than single users. Such tactic can ensure endurance and stability when number of system’s assets is increasing over the time. The set of right is declared for one role working as a group aggregating users on the

8 2. INTERNET SECURITYAND TERMINOLOGY

Figure 2.1: RBAC model in DirX Access same level of hierarchy. New employees are commonly sorted into already existing roles when they are hired and so they easily obtain whole set of privileges and restrictions that are targeted for them. In the Figure 2.1 we see that in RBAC user is a separate entity that does not take place in whole machinery of access control. All is centered around the role that is a root subject. Role is then equipped with the authorization policies which are further speciﬁed by partial elements. Of course in the end a user is the one who is in the center of at- tention and he may be incorporated into the role either by the or- ganizational group he belongs to or by his own account. This ﬁgure

9 2. INTERNET SECURITYAND TERMINOLOGY represents just permission hierarchy and subordination of elements in policy tree. Authorization policy consist of rules saying an action can1 be performed on a resource under circumstances in which the conditions attached to this rule are valid. Action is a regular access type or activity specified be the CRUD2 system and condition can be any condition supported by the specific implementation (e.g. time range condition, condition bounded to IP address or resource ownership condition). As you can notice, authentication policy stands aside even though it takes part in the access management. The reason is an authentication policy is regularly not concerned by single accounts or roles. In most cases we want to build and authentication bubble around whole bundle of resources with same authentication duties for ev- erybody. If we nevertheless want to force certain group of users to authenticate themselves by other means, we can configure this directly as an attribute of given policy. Another thing in diagram worth commenting are cardinalities. In each case cardinality is set bilaterally to 0..n relation. Sometimes it is not quite correct from the logical view on dependency of each two entities. However, schema represents implementation of RBAC principle in DirX Access where each element can stand on its own and if its presence is required it is substituted by default value to follow "what is not permitted is denied" principle.

2.5 Policies

So far we introduced techniques of access control and how to deal with rights in large system. Policy is a term that stands as an abut- ment stone for every single control mechanism. In general, by policy we understand a set of rules where rules do not have to be connected logically, by their semantics or by their reference to some subject. Pol-

1. In theory RBAC contains two kinds of rules: permit and deny rules. In our implementation settings follow principle: what is not permitted by a rule is denied by default. So we do not have differentiation among rules and can freely say "action can be performed" instead of "action can or cannot be performed". 2. Create Read Update Delete

10 2. INTERNET SECURITYAND TERMINOLOGY icy can be perceived as a set of rules that we are planning to use as a unit for additional processing. To describe authorization policies and their application in an environment of computer application we use among others descriptive XML-based language developed by OASIS called XACML which stands for eXtensible Access Control Markup Language. XACML is also a standard containing model for promoting an inﬂuence of policies. It acts as a guide for the architecture design patterns when we decide to build such program.

Figure 2.2: XACML policy evaluation model[8]

As we can see in the Figure 2.2 policy propagation model is not so trivial to understand at the ﬁrst sight. Let us take a look on the unknown abbreviations in the model for now: • PAP - Policy Administration Point is a place that starts the whole

11 2. INTERNET SECURITYAND TERMINOLOGY

policy evaluating process. It may be a host system with an application or a server where comes a request for resolving policy.

• PDP - Policy Decision Point combines results from other system parts to compose a ﬁnal decision about acceptance or denial of requested access.

• PEP - Policy Enforcement Point is a controller which processes access requests into XACML request pointed to the PDP and translates a response provided by system to create obligations controlling the access.

• PIP - Policy Information Point is some kind of a postman who delivers system attributes for evaluation process taking part in PDP.

Process:

1. The PAP speciﬁes the policy and sets rule for its evaluation es- sential for the PDP to work correctly. This step should be rather marked as zero step as it does not trigger the process. Its work is to set up a background environment for a process to be able to run.

2. Impulse that starts policy evaluation is access request obtained from the outer interface of the program.

3. A request is served to the PEP that builds from it an XACML request in speciﬁc context.

4. This request is dedicated for the PDP to create a decision about its justiﬁcation and is asked in a form of request notiﬁcation.

5. PDP needs for proper reasoning attributes of environment in which it is currently running and thus forms a attribute queries.

6. Attribute retrieval is now delegated to the PIP to which is sent one attribute query at the time.

12 2. INTERNET SECURITYAND TERMINOLOGY

7. PIP then tries to gather all requested data from system environment containing resources or subjects acting in an application. Those are in picture shown as subject attributes, resource attributes and environment attributes.

8. When PIP collects what is requested by PDP, it sends an attribute collection to context handler.

9. Attribute collection is optionally broadened by the resource itself.

10. Context handler adds a notion of current context to the attributes and redirects them to the PDP.

11. Now the PDP is capable of performing an authorization decision and ﬁnalize the initial request by conﬁrming or refusing it and sends an information in response context.

12. Response is as other messages redirected by context handler to the PEP which parse the XACML and recognize the decision.

13. Finaly a set of obligations is sent to the obligation service responsible of end-to-end propagation of generated response.

This is the process of policy evaluation used also by the DirX Access system. It is a necessary step on a path of protecting one’s belongings on the Internet. Even though it may seem a little more complex, it is perfectly reasonable and justiﬁed when we get to work with it.

2.6 Authentication Patterns

We have seen on example of access management (authorization process) that the topic covered here is not trivial and has to be parsed to smaller problems in order to grab it correctly. Theme of authentication is not different and techniques were created to make whole process more efﬁcient.

13 2. INTERNET SECURITYAND TERMINOLOGY

2.6.1 Single Sign-on (SSO) When speaking about identities and authentication we should stop here to mention a principle used within companies to help them communicate in more secure way. Principle we are talking about is called Single Sign-On and as its name suggests its aim is to bring implementation of authenticating process in a way that a client will have to do it only once within the same domain. This principle is designed to reduce the overhead which would be caused by the need of authorization and previous authentication for any sub resource in a domain. It is usually implemented by token that is even stored centrally on an LDAP server or in the session which is howbeit valid just within the current domain and cannot be passed to other federated resources[9]. In contrary Single Sign-off exists with an aim on opposite functionality, so that the termination of all signed on sessions is imposed.

2.6.2 One Time Password (OTP) Authentication OTP refers to another principle connected with an authentication process. One Time Password tactic is used to provide more secure way of proving self identity. Based on an algorithm built frequently from the time function, password generator is provided for client to use it with combination to his usual credentials. It is called a two- factor authentication, when a user is requested for what he knows as well as for something that he owns. Such password is however valid only for current session and cannot be reused, but this can be seen as a price paid for increased security which is often more desirable.

2.7 OpenID 2.0 Protocol

So far we spoke about authentication and now it is time to cover another part of it. Authentication on the network is a fragile topic and should be taken to hands with care. To prevent unwanted errors web community often comes up with standards, recommendations and protocols which can and should be reused. As many other ser-

14 2. INTERNET SECURITYAND TERMINOLOGY vices, identity providing is also described by many protocols such as OAuth3, OpenID or SAML4[10]. OpenID protocol is an open standard and protocol created origi- nally in 2005 by Brad Fitzpatrick and later by the non-proﬁt OpenId Foundation that allows users to prove their identity without having to additionally register and create new accounts on every new service provider page they visit. This begun as a proposal for the solution of loosing and forgetting passwords. The cause for this was established as quantity of information needed to be memorized by one person. So target for ﬁnding solution was straight forwardly set to reduce the number of credentials owned by individual. To make this work, there would need to be a centralized identity store which could be reachable by any service asking for user’s authentication. The idea was quite simple in both theory and use so it became rapidly popular and lot of identity providers arisen using this known standard pattern. Some of the majors are AOL, Blogger, Flicker, Word- Press or Yahoo! who use this technology until now. By the time protocol evolved, needs of organizations grew up and some of them developed their own protocols such as Facebook or Google. The reason why we speak about OpenID could have been clear from the similarity of names mojeID and OpenID. It is not a coinci- dence and indeed system mojeID uses protocol OpenID on its background. With one goal ahead of itself it became a suitable mechanism to maintain users authentication process. OAuth on the other hand works as more robust tool allowing to pile up functionality above the authentication that was not desired for purpose of mojeID.

2.8 Federation and Federation Endpoint (FEP)

Authentication itself is a challenge but when one problem is con- quered another arises. Authentication within one service, one com-

3. Open Authentication protocol developed by Facebook to be able to both authenticate and authorize their users for certain action. It is working on principle of passing the authentication token. 4. Security Assertion Markup Language, created by OASIS is an XML-based, open-standard data format for exchanging authentication and authorization data between parties. 15 2. INTERNET SECURITYAND TERMINOLOGY

pany, one system is handled and described and federations of organizations starts to crave for similar solutions supporting their alliance. Federation in IT terms can be seen as cooperation of services and even web services that are becoming more popular in last decades. We will speak here about federated services communicating with each other whereas each of them is part of different organization’s structure. Information technology uses also term federated identity that covers what was already mentioned in section dedicated to identities. In general it is associated to the identity seen as a token which can be passed across sites in an SSO manner. A FEP is a place in a product which is dedicated to handling the inter-service communication between two or more companies. This point usually implements a bor- der of a product working as a pre-processor which passes the data inside the system after they are successfully processed to acceptable format. Depending on a functionality we ask for, we implement more endpoints to logically separate duty among them and prevent security issues that may rise up later. For example we use here authentication and authorization FEPs as separate units letting each of them ﬁll its role in a non-robust way.

16 3 Systems

This chapter describes systems that stand as objects of integration in this work. It presents their nature and with use of deﬁned terminology outlines their relation as identity and service provider. Basics of their functionality are described for the purpose of solution design.

3.1 mojeID

Service mojeID is an identity provider concentrating on the coun- try markets of Czech Republic and Slovakia. It belongs to the group CZ.NIC1 which acts as an authority taking care of ".cz" domain. Pur- pose of mojeID was similar to other identity providers which is main- taining a central repository for identities in order to make flow of users over Czech and Slovak sites more fluent, efficient and comfort- able. Responsibilities of mojeID could be divided into two parts depending on a client to whom is provided service. On one side it is oriented towards the users as a provider which takes care and guards their belongings. On the other side, to follow up its mission, it needs to support redistribution of itself to partner projects and is also oriented towards service providers. As an identity provider, mojeID commits itself to safely store the data about users and provide their identity token to third parties whilst not revealing these data. It is solemnly a user’s will to hand over some of the data if it is requested by the service provider. The second part is built on top of the fact that mojeID creates possibility for other corporate subjects to use its API. The only condition for this to work is that other party needs to have a contract with mo- jeID that gives it a right to authenticate users with the mojeID identifier. When a deal between identity provider and the service provider is sealed, service provider becomes a relying party. After that it may

1. The group was founded in 1998 by corporate subjects taking care of root .cz domain. It is also part of EURid looking after .eu domain and its purpose is to provide a registry for the lower level domain names. Details can be found on pages of CZ.NIC: http://www.nic.cz/.

17 3. SYSTEMS start to fully co-function with the mojeID, considered as trusted partner and it can obtain any user’s data with standard request. The service is not free at full range and this is due to the protection from service misuse. In the free variant provider can authenticate a user, but receives just a result of veriﬁcation process on the side of mojeID. All other attributes are opt-in, meaning that user can let them be used if he intends to do so and thus it is not a will of provider. Therefore contract is a guarantee that communication ﬂows between two business partners and that data are not handed over to some untrustworthy site.

3.1.1 OpenID Mechanism

As we putted down earlier, mojeID works above OpenID 2.0 protocol and so its functionality is straightly derived from it. Because OpenID is an originator which implements these principles we will speak in its name. OpenID 2.0 protocol model has three actors: User, OpenID provider (OP) and Relying Party (RP). All of them communicate together in order to claim user’s identity. In the Figure 3.1 we can see the steps of authenticating user with OpenID 2.0. Before actual authentication begins there is a possibility of a zero step which is establishing association between OP and RP. It is not mandatory but when association is present, verification of multiple users goes much faster as there is no need to do again Diffie-Hellman’s exchange of a key for setting up a trusted zone. The first step is obviously input from a user who wants to access some resource at RP side. RP can either ask user to fill his OpenID identifier and verify this at step two or send user to the defined endpoint of OP and make him do everything on an OP side in step three. After OP is done with the authentication in step four, response with results of authentication is sent through the user back to the RP in step five. As there is a chance that data coming through the user could be compro- mised, RP verifies this response with the OP in step six. If data were not modified RP is free to work with obtained attributes in a similar way as if the user would put it in its registration service himself.

18 3. SYSTEMS

Figure 3.1: mojeID mechanism

3.1.2 Yadis Yet another distributed identity system is a communication protocol for discovery of web services such as OpenID or OAuth connected to Yadis ID where it is intended to discover digital identities. A Yadis ID can either be a traditional URL or a newer XRI i-name, where the i-name2 must resolve to a URL. Furthermore, Yadis speciﬁes how to use the Yadis URL to retrieve a service descriptor called Yadis Resource Descriptor. This descriptor follows the XRDS3 format and connects several services, like authentication or authorization to the Yadis URL. Each service description

2. i-name is a standard deﬁned by OASIS with intention to bring more human readable format to the human names resolving 3. eXtensible Resource Descriptor Sequence is an XML format representing discovery of web resource

19 3. SYSTEMS

can have further parameters.[11] An XRDS document must be present in a scope of web application to help determine the resource location. Likewise, location of XRDS document must be included in an HTTP header under meta tag with value X-XRDS-Location. The example of XRDS document can look like this:

1 2 5 6 7 8 http://specs.openid.net/auth/2.0/return_to 9 10http://www.myopenid.com/return 11 12 13

Figure 3.2: XRDS sample document

3.2 DirX Access

DirX Access is a product of company Atos that comes up with a family of DirX products[12]. The target of this product portfolio is to provide a secure way to store data about the company infrastructure with an emphasis on users - employees who are needed to be veri- ﬁed before accessing company’s resources. Four products are distin- guished from this family as shown in the Figure 3.3. DirX Directory is a base for other ones and its focus is on ad- ministering LDAP4 directory that is capable of holding information about the organization’s hierarchical structure.

4. Lightweight Directory Access Protocol is a protocol describing maintenance of distributed directories over Internet Protocol (IP). It originated from X.500 series

20 3. SYSTEMS

Figure 3.3: Family of DirX products[13]

DirX Identity works above the Directory and cares about users as individuals with single unique identity. It is a robust and highly functional system which concern is turning around identity management from all angles, working with the idea of multiple storage facilities and identity replication to support federation systems. DirX Access in simple terms works as an inter-mediator between Identity and Directory. It plays part of security layer bringing in security features such as centralized authentication, authorization or Single Sign-On 2.6.1.In addition it is a user-centric identity management tool which puts users in control of the use and management of their personal identity information for internet transactions. It also helps to centrally and consistently enforce security policies for web services in a SOA5 envitonments.[15] On top of this family sits DirX Audit which gathers reports pro- duced by all other products and process them into presentable format. The technical cooperation of all products can be seen in the Fig-

of recommendations about directories formed by the International Communica- tion Union (ITU) which are commonly known as RFC (Request For Comment) documents.[14] 5. Service Oriented Architecture

21 3. SYSTEMS ure 3.4. As the base for all of them sits on the bottom of the pyramid DirX Directory handling storage-related issues. Right connected to it is DirX Identity providing synchronization, replication and more services guarding that identities information are in consistent state. On top of those two is DirX Access which role is to protect incoming and outgoing transitions inside one or among multiple systems. Last but not leas on the side of everything lies DirX Audit listening to events occurring on each line and informing user about statistics created out of these data.

Figure 3.4: DirX product family cooperation scheme.

3.2.1 Principle of Working

When we set DirX Access into the scope of other DirX family we mentioned its role and responsibility. That was however put very brieﬂy and not sufﬁciently for reader to imagine whole concept.

22 3. SYSTEMS

Figure 3.5: DirX Access Authentication/SSO Subsystem[16]

From more technical point of view, DirX Access stands on the server side of web application or service. From here it protects content of the application by enforcing evaluation of policies designed to protect specific resources. The area of protection depends from the purpose of client. DirX Access is capable of protecting common server platforms as well as web services themselves by injecting plugins holding its functionality. PEP is a basic configuration element grouping settings and functions describing policies. It is also the first point that is triggered when user tries to reach a resource as we can see in Figure 3.5. Configuration consist of large variety of parameters from setting descriptive elements for PEP through the Internet security related settings (SSL[17], Cookies, Cache, Session) to the handling of occurring events. We can indeed consider it heart or rather brain of DirX Access. This was a bit more detailed introduction to DirX Access. It is a vast product and it would take us few tens of pages more to cover it thoroughly so we will mention only some of the relevant areas to help us imagine how DirX Access cooperates with third parties.

23 3. SYSTEMS

3.2.2 Cooperation with Third Parties One of the main intentions of DirX Access is to create a federated environment with the possibilities of SSO 2.6.1 to keep users away from redundant needs of repetitive authentication. For this purpose DirX Access implements FEPs 2.8. FEPs can be also conﬁgured in exhaus- tive way to ﬁt the majority of customers. They are designated to con- nect partner companies with use of standard protocols for federation such as SAML, STS 6 and OAuth. We can see that such federation is based on passing identities from one service provider to another and this is exactly what we require from our new program.

3.3 Concept of Cooperation

Goal of this thesis was to implement a solution integrating OpenID provider mojeID and product DirX Access in a way such that DirX Access can make a use of mojeID services to extend its functionality and provide new means of authentication for external users. Interaction of two systems strange to each other requires analysis of their workﬂow to enable us to ﬁnd an interception where we could create a communication bridge transferring data between them. Ser- vice mojeID works primarily as an external authentication provider and accordingly it has several demo implementations present for its users who want to take advantage of its services and provides an API for this purpose. As an OpenID provider it strongly relies on the architecture and libraries of OpenID 2.0 protocol which means that also an API follows structure of standardized library that can be potentially reused with other implementations. The more interesting area of integration is situated on the side of DirX Access. The questions occurring here were:

1. Where to create a client application accepting requests for accessing resources and providing a trustful response offering client to authenticate himself to be recognized as a user of the system?

6. "Security Token Service is the service component that builds, signs, and issues security tokens according to the WS-Trust and WS-Federation protocols."[18]

24 3. SYSTEMS

2. How to process data obtained from a third party application to correlate external entity with a potentially present account in the system?

3. How to cope with a situation when authenticated user does not have an account in the system?

4. Can we make use of RBAC principle for enabling us to resolve authorization questions of new entities?

From the systems analysis in the chapters 3.1 and 3.2 we conclude that the most suitable place for realization of referenced bridge is to create a new FEP guarding resources from the middle of DirX Access and conﬁgure the authentication methods to perform an authentication with an external provider. To follow these steps we will need to come up with a brand new FEP working with and also supporting fundamentals of OpenID 2.0 protocol. One question is solved, but let us take the other ones to the following sections to explain it deeper. It will require technical terms and understanding of previous chapters to see the outcome.

25 4 Integration

In this chapter we will depict the implementation details from the more technical point of view. We create an overview about the project appearance and introduce the context under which is whole system working. Implementation brought some ups and downs that will be mentioned and elaborated on if necessary. However for the complete list of ﬁles and manuals to the program see the enclosed appendixA.

4.1 Technologies

One of many concerns when developing a piece of software is a mat- ter of technologies used for its creation process. We should consider existing technologies present in both products as well as functionality that the ﬁnal implementation should bring. With the aim on these characteristics we found out that Java language in its EE form will be the most suitable instrument. On the one hand because DirX Access is implemented in it and on the other hand because OpenID protocol is also well supported by Java libraries such as openid4java library. Additional tools used together with Java during implementation were:

• Maven for dependencies management and up-keeping third party libraries

• Jetty for purposes of server simulation and testing demo application

• Ant for building of project in complex environment

• OSGI as a framework for bundle management

Mentioned here are the most remarkable ones. There were of course present other technologies, but these few made a visible inﬂuence to the project’s appearance. We will discuss all others later.

26 4. INTEGRATION 4.2 Model

Model in the Figure 4.1 is an image representation of theoretical analysis.

Figure 4.1: Cooperation model

It is somehow an extended representation of OpenID model 3.1 we still have three main actors exchanging data and steps from the previous model are preserved. Model 4.1 is moreover decomposing Re- lying Party actor to show the inner mechanism of cooperation amid singular parts. The whole RP is packed in one container named DirX Access. That is a representation of our system having resources R1 upto Rn exposed to outer network. They are governed by single policy enforcement point which is in charge of calling FEP when necessary. All other parts of the system are pictured leftmost by cog wheel communicating with local and global repositories. Dashed lines in the diagram represents states or facts that describes certain behaviour. It is supposed that user has an account at OP side and it is supposed as well that all parts of the system cooperate together correctly.

27 4. INTEGRATION

The process:

0. The beginning step is same as in the OpenID model and that is creating of an alliance or an association if you want, between OP and RP.

1. Client initialize the process by pointing his browser to the resource belonging to the realm of DirX Access.

2. PEP recognizes his attempt and ﬁnds out what protection is bounded to the current resource. In the sunny day scenario authentication method selection would be voluntary, but in current state of system everything is strictly conﬁgured. Therefore we suppose that resource accessed by the user is being protected by the trusted authentication method requiring third party identity validation. PEP is in such case forwarding request to the FEP in charge of used method.

3. FEP got a command that it should process an incoming request and as in openID model it informs OP about authentication request to be followed.

4. Then it sends the request indirectly through the user’s browser to make him attend the authentication.

5. When user completes his authentication attempt, response is sent again through the client browser back to the returning URL which was deﬁned by FEP. This might be resource containing handling processor or address of such service. For sim- plicity let us assume that response is heading back to the arms of FEP.

6. It will take care of the response and sends ﬁndings back to the PEP.

7. PEP reads the conclusion and informs end-user by granting him access or refusing his request. Anterior to this is whole set of resolving access rights if authentication endded successfully. This is caught on the image 2.2.

28 4. INTEGRATION 4.3 Questions

Let us get back to the questions posed in the ﬁrst section of this chapter. We may now be able to contemplate about them and answer the problems with regards to the model and technologies.

4.3.1 Question 2 How to process data obtained from a third party application to correlate external entity with a potentially present account in the system?

Third party application here equals to the mojeID based on OpenID 2.0 protocol. Data passed over by this protocol are organized into the claims which are indeed claiming user’s identity by delivering private data. Nevertheless, only on piece of information is guaranteed to be delivered together with the validity flag and that is user’s identifier. Unexpectedly, nobody can promise that this parameter of one’s account will be coincident on both sides. Therefore we have to ask user to grant us an access to his other data such as first and last name or his email address. These attributes will help us to correlate his identity to the account in DirX Access where user’s full name is saved as well. In order to be sure to obtain this data we have to mark them as required in a request addressed to the mojeID.

4.3.2 Question 3 How to cope with a situation when authenticated user does not have an account in the system?

Additionally to the question of connecting user’s accounts (identities) we need to count with a situation when this task will not be accomplished. Such exception may occur from two main reasons:

1. User has account at DirX Access side but information com- ming from veriﬁcation request was not recognized and paired correctly. In this case it would be wise to either redirect user to another authentication method or handle him as a one who

29 4. INTEGRATION

does not have an account. As it is difficult to find out if the first situation happened we will follow the second path.

2. User’s data are not in any of existing accounts in DirX Access. Now, why should a non-member of companies infrastructure be able to access any of its resources? There exists for sure reasons that are not known to us yet, so let us ask another question. Can we create general role for external users and assign them here, granting them in every case the basic set of rights? When a special case occurs such as external user tries to con- nect to our system it is on place to treat this individually and rather equip him with temporary account than handle it some- where at the edge of application. Finally this should be done by the system administrator and not by the program.

In conclusion to this dispute we came to an agreement that this will be not concern of implementation covered by this thesis.

4.3.3 Question 4 Can we make use of RBAC principle for enabling us to resolve authorization questions of new entities?

From previously decided we assume that we will not assign any role to the authenticated user directly and this part remains on the PEPs of DirX Access server. However we certainly make use of RBAC principle when it comes to authorization because it will be applied when access request will be generated immediately after authentication step.

4.4 Project Scope

The project itself is an autonomous block that can be placed into the DirX Access installation as a plugin with certain conﬁguration. It is a .jar package with additional part containing source ﬁles for the web application. Its directory structure can be seen in the Figure 4.2 As you can see, project is called "OpenId2Fep". This has two reasons.

30 4. INTEGRATION

Figure 4.2: Directory structure of the project

OpenID is in the name because for potential reuse in the production it is not important which OpenID 2.0 provider will we support because they all on top of the same protocol an so the mechanism of cooperation with them will be quite similar. If the project would be adjusted so it can go to the production, it will be extended in such way that it would provide a switchable and conﬁgurable context describing provider that will be in use for authentication purposes present in that context. Secondly, the word "Fep" represents a functionality template re- ferring to a certain paradigm telling us what can we expect from the given component. That is, the project will work as a point on the edge of system communicating with foreign organizations to propa- gate either authorization or authentication functions. The folder is afterwards divided into few predeﬁned blocks as- suring us the right cooperation with all external components such as Maven or Ant. Important here are three parts:

• Java source code in src folder.

31 4. INTEGRATION

• Output folder concentrating ﬁnal plugin with classes.

• Web application source code in webapps folder.

• Conﬁguration ﬁles in project root.

Between configuration files it is worth noticing bnd.bnd responsible for OSGI bundle configuration, build.xml responsible for building of project with Ant and pom.xml configuring dependencies han- deled by Maven component. All other present XML files are just an external additional configuration files for Maven that would cause bad readability of plugin declarations.

4.4.1 The Client Source code in the src folder represents an implementation of the project back-end core. Application is designed as a traditional server - client application communicating over network where server is mo- jeID and client is our application. The client consists of Java servlet handling all incoming communication called ClientServlet. Actions that are needed to be processed to handle all situations are divided into three parts covered by so called handlers. These are:

• Initial Request Handler

• Callback Request Handler

• Handler covering error handling

4.4.2 Initial Request Handling The very first step invoking whole authentication process is started by accessing protected resource. In a case that user is not already authenticated, such action will trigger InitialRequestHandler that takes care of the situation by offering user authentication by mo- jeID where he may insert his identifier under which he is registered at this provider. Identifier has different shape from provider to provider and it depends on single implementation how it will be represented. MojeID

32 4. INTEGRATION

represents a principal entity with an identifier in a form: https://[identifier.]mojeid.cz/[hash]. The hash part is generated by mojeID and so it does not serve at the initiation step as important field. The focus is set on the URL that occurs before and serves as an potential endpoint. If user identifier is supplied in this first step, request is redirected to common endpoint https://mojeid.cz/endpoint with a pre-filled identifier.

Figure 4.3: Welcome screen of mojeID endpoint after redirection with (not) ﬁlled identiﬁer

User has usually three options to authenticate at mojeID site: password, certificate, password + OTP 2.6.2. However this will not affect the final affect of claims on our integration as we correlate only simple fields such as first, last name or email with the data in the DirX repository. Before redirecting user to authentication page of mojeID, Initial Request Handler stores users identifier to UserProfile object which is held in a session for later retrieval, comparison or extension. It can be accessed by the hash code generated based on the prime numbers combined with a hash code representation of a session object.

4.4.3 Callback Request Handling When user passes authentication challenge of mojeID he is redirected back to the return address 3.2 which is in our program address of

33 4. INTEGRATION

ClientServlet which can decide to process callback response. By doing so it transfers responsibility to the CallbackRequestHandler. Signature of request containing user’s claims is compared with the one from association and if everything ended up legitimately identity’s attributes are processed and inserted into the cookie serving DirX Access as referral point from which is built UserCredentials CallbackHandler doing authentication on the Access side by comparison of correlating ﬁelds.

Figure 4.4: Response of mojeID after successful authentication

In the Figure 4.4 are shown required and optional attributes requested by DirX Access. Here is the user’s choice if he provides them or not. Error appearing above the response is telling that server is not cer- tiﬁed and request is coming from mistrusted site. This is due to the environment of development which allow us to only deploy testing application with a self-signed certiﬁcate.

4.4.4 Error Handling Whole process of authentication is risky and errors may occur because network failure as well as because data incorrectness or incon- sistency during the communications. All of those should be taken care of respectfully to their importance and impact. Outer mechanism for treating exceptions and errors might seem to be homogeneous as it mostly consists of displaying the same fail-

34 4. INTEGRATION

ure page for every mistake, however inner handling process runs distinctly and interrupts whole process when credentials are insuf- ﬁcient or passes default values on when misstep is not serious e.g. when user forgets to insert his identiﬁer. Error handling is directed from the main RequestHandler acting as parent for separate specialized handlers. It might be wise to separate also this part if the project will tend to expand. This was not necessary in consideration of a size of this project.

4.4.5 Contexts Each of the ones above stores data in its own Conﬁguration context that is being created when an instance of particular FEP class is pro- duced. Context is an entity keeping relevant data aside while sup- plying methods exchanging knowledge with DirX Access PEPs. Be- sides of that, additional contexts are present to help FEP communicate with the DXA server. FEP Request Context stores a data about the current ongoing request and behaves like a local repository having methods simplify- ing for example passing and getting parameters.

4.4.6 User Proﬁle Project contains a java object representation of user’s temporary pro- ﬁle as well. Temporary, because it is similarly as contexts relevant only during data exchange. It is some kind of a holder for claims obtained from mojeID and hash code value representing user in the session.

4.4.7 Web Application A folder containing web application sources is mainly supposed to provide a demo application for testing purposes which is also used to demonstrate functionality of whole system. The application is build with classic JavaEE technologies. Web pages are written as HTML or JSP pages contacting implemented servlet. Whole application may be run on a Jetty Server which is included by Maven plugin. By default, application runs on the port :80 under

35 4. INTEGRATION non secure HTTP protocol, but configuration is possible by modify- ing the XML files with a "jetty" prefix in the name. For more details about this seeA.

36 5 Conclusion

Goal of thesis was to realize a system for access management and identity federation working on top of federation between DirX Ac- cess and service mojeID. By analysing the problem from side of mo- jeID as well as from side of DirX Access we came to the solution to implement a new FEP which will stand for director of inter-service communication. Development of FEP was based on the technologies supported by both products and program was lead to the successful working state. With the implemented solution user is able to log in to DirX Access through the mojeID service which will on background correlate accounts in both systems in order to let DirX Access work with logged user. With respect to a growing market and the effort to orientate towards customer’s needs, thesis tends to bring proﬁt to the product by extending its portfolio of provided services and enables it to spread to the still unexploited Czech and Slovak market. New elements were implemented under supervision of software architect working for the DirX Access team. They correspond to the principles used with implementation of similar features and are written in reusable and extensible manner. Discussion over this topic was held to already discover potential directions to which a product development may lean. All in all, software development is liable to the customer’s intentions and is scheduled respectfully. Implemented solution was thus not yet integrated into the production version of DirX Access.

5.1 Further Steps

The question of each project is where to go next from the current point. Questions as such should be answered to outline a path for evolution if there is some ahead. As the goal of the thesis was ﬁrmly set, there were not many options to extend a system such that it would fall into the same context. Therefore we suggest few areas which can be taken into consideration if someone intends to build on top of this. One of them can be generalization of OpenID FEP in a sense that

37 5. CONCLUSION will allow DirX Access to support any OpenID 2.0 provider inde- pendent of its origin. OpenID 2.0 is a protocol and standard which is reused across the Internet in a very similar way and the differences among OPs are minor. Problem of different implementations and configurations may occur at each single provider side e.g. with user’s identifier definition. In such case we suggest to at least broaden the list of supported providers. There is off course always more to be improved, but we mentioned everything that we are aware of. Every little detail concerning implementation is noted in the code documentation and should be read carefully.

38 Bibliography

[1] RANNENBERG, Kai, Denis ROYER a André S DEUKER. The future of identity in the Information Science: challenges and opportu- nities. Dordrecht: Springer, c2009, xvi, 508 s.

[2] Hildebrandt, M. and Gurtwith, S. (eds.). Proﬁling the Euro- pean Citizen. Cross-Disciplinary Perspective. Dordrecht: Springer, c2008.

[3] MATYÁŠ, Vašek. The future of identity in the information society: 4th IFIP WG 9.2, 9.6/11.6, 11.7/ FIDIS International Summer School Brno, Czech Republic, September 1-7, 2008 : revised selected papers. Berlin: Springer, 2009, x, 281 s.

[4] REESE, Terry and Kyle BANERJEE. textitBuilding digital libraries: a how-to-do-it manual (R). New York: Neal-Schuman Publishers, c2008, xv, 277 p.

[5] GARIBYAN, Masha, Simon MCLEISH a John PASCHOUD. Ac- cess and identity management for libraries: controlling access to online information. 1st pub. London: Facet Publishing, 2014, xx, 248 p.

[6] HÖFER, Filip. Platform-Based Authorization Technologies: Tradi- tional and modern authorization technologies with focus on the Win- dows platform. Saarbrücken: LAP LAMBERT Academic Publish- ing GmbH & Co. KB, c2010, i, 88 p.

[7] National Institute of Standards and Technology. ROLE BASED ACESS CONTROL (RBAC) AND ROLE BASED SECURITY. [online]. [cit. 2014]. Available at: .

[8] MOSES, Tim. eXtensible Access Control Markup Language (XACML) Version 2.0 : OASIS Standard, 1 Feb 2005. [online]. c OASIS Open 2004-2005 [cit. 2014]. Available at: .

39 5. CONCLUSION

[9] SHERIFF, D. Paul, PDSA, Inc. Single Sign-On Enterprise Security for Web Applications. [online]. [cit. 2014]. Avail- able at: .

[10] Wikipedia Foundation, Inc.: OpenID. [online]. [cit. 2014]. Avail- able at: .

[11] MILLER, Joaquin. Yadis Speciﬁvation: Version 1.0, 18 March 2006. [online]. [cit 2014]. Available at: .

[12] KUPPINGER, Cole. KuppingerCole VENDOR REPORT: Atos DirX. [online]. [cit. 2014]. Available at: .

[13] Atos SE. Training DirX Access v8.4: Product Overview. Munich: Atos SE, c2014, i, 39 p.

[14] ARKILLS, Brian. LDAP directories explained: an introduction and analysis. Boston: Addison-Wesley, c2003, xxiv, 405 s.

[15] Atos SE. DirX Access: truested collaboration. [online]. [cit. 2014]. Available at: .

[16] Atos SE. DirX Access V8.4: Web Access Management and Identity Federation. [online]. [cit. 2014]. Available at: .

[17] RESCORLA, Eric. SSL and TLS: designing and building secure systems. Boston: Addison-Wesley, c2001, xxv, 499 p.

[18] Microsoft Developer Network: Security token service. [online]. [cit. 2014]. Available at: .

40 A Program Testing Manual

The program is contained in the OpenId2Fep project. Its output after compiling is a standard java library with extension .jar that serves as a plugin for the DirX Access installation. Files attached to this thesis contain already built project. If you want to modify the project, rebuild it with Ant or other building tool to be able to continue in the manual.

A.1 Deploying Application

Steps to reproduce:

1. Go to the folder output\plugins and locate ﬁle dirx.access.applications.web.federation.openid2.client-8.4.0.jar.

2. Copy this ﬁle within your DirX Access installation to the Atos\DirX Access\WebApplications\plugins folder together with dependent libraries from the lib folder.

3. Copy the content of webapps folder to your instalation in the newly created folder named "openid2-client" under directory Atos\DirX Access\WebApplications\instances\"your-instance" \webapps.

4. Now restart the DirX Access WebApplication server where your web application instance is running.

5. Access the project servlet on URL "your-web-application-url"/openid2-client/openidclient

A.2 Running Application Without Deployment

Application can be run as a standalone plugin without need to in- tegrate it inside DirX Access installation. Unfortunately, we might need to have or substitute some libraries. To run an application on local Java server simply open command line tool, go to the project’s root folder and type command mvn jetty:run. Command will start a

41 A.PROGRAM TESTING MANUAL local Jetty server with an application reachable at the URL localhost/openid2- client/openidclient. Beware! Application is running by default on the port:80. If this port is taken by other application or you want to change it, you have to go to ﬁle jetty-http.xml and change the following line:

1 2 3

Figure 1.1: Port settings in jetty-http.xml

If you want to run it on HTTPS protocol, set your desired port similarly in the file jetty-https.xml and configure your keystore in the file jetty-ssl.xml Also make sure that any files you modified are included in the pom.xml file read by maven on the lines:

42 A.PROGRAM TESTING MANUAL

1 2org.eclipse.jetty 3 4 jetty−maven−plugin 5 6 7 9.2.5.v20141112 8 9 10 11.\webapps 12 13 14 15.\webapps\WEB −INF\web.xml 16 17 18 19 jetty.xml,jetty−http.xml 20 21 22

Figure 1.2: Conﬁguration of Jetty plugin for Maven in pom.xml