Authentication in Apache Lenya

Transcription

1 Authentication in Apache Lenya Using LDAP The user authentication mechanism in Apache Lenya is carried out by specifi c components using certain policy fi les. This process is, in itself, complex to understand and inclusion of LDAP authentication makes it more complex. Lenya does not have provision of user creation on LDAP, instead it provides mapping of Lenya user with the existing users on the LDAP. This mapping of user is one-to-one and would be cumbersome if the number of existing LDAP user is large. This problem can be solved through a small standalone program which would interface LDAP server to Lenya and would copy the users to latter in single execution. 1

2 About the Author Shishir Saxena Shishir Saxena is an associate of Open Source and Linux Practice and has more than fi ve years experience in J2EE related technologies. His expertise includes web tier architecture and java/xml based open source content management system. He is presently involved with development of open source content management system related initiatives and offerings. Shishir has obtained his engineering degree in computer science and is a java certifi ed programmer. 1

3 Table of Contents 1. Introduction 3 2. Description 3 3. Authentication through LDAP 5 4. Conclusion 6 2

4 Introduction Most of the organisations would require a proper authentication mechanism to be in place for authorising the privileged users to access the respective resources in the system. LDAP authentication is one of the popular mechanisms for the same. It is a standard application supported by various companies like Microsoft, Lotus Notes, Netscape and so forth. In Apache Lenya, the user can be authenticated based on the Access Controller component using specifi c user policy fi le. These users are defi ned in the context of Apache Lenya and are referred through their respective user case policy fi le. This process of authentication is complex to understand and the complexity increases when a LDAP user needs to be authenticated to access Lenya publications. Though the authentication for this user happens at LDAP server, Lenya needs to be aware of the profi le of this user and the role to which this user is associated within Lenya context. Hence, the user creation process regarding LDAP users can be cumbersome, if a large number of existing LDAP users is required to be provided access. Lenya supported LDAP authentication was tested with OpenLDAP and MS Active Directory servers. Authentication means password checking is done through LDAP, so that the user does not need a Lenyaspecifi c password. Note that only authentication is done through LDAP and the Lenya administrator still has to inform Lenya which LDAP users to allow and also inform to assign Lenya roles to these users. LDAP setup is handled in Lenya confi guration fi les, adding users and assigning them roles are handled within the Lenya Admin GUI. The LDAP implementation in Lenya is based on the factor that you have an existing LDAP directory containing users and passwords, but you do not want to (or are not allowed to) add anything particular to Lenya within this LDAP directory, such as Lenya roles. Consequently, the Lenya-specifi c user information is not stored in LDAP but instead it is stored with the same mechanism as non-ldap users. Here Lenya delegates authorization (the checking of the user s password in LDAP), which means that the user does not require an additional Lenya password. In the fi le ldap.properties, set security-protocol to the value ssl and set key-store to the name of your keystore fi le. Add the LDAP server certifi cate fi le to the local keystore using this command: Keytool -import -keystore.keystore -file <ca_cert_file> -alias <yourdomain.com> This white paper initially provides an overview of the process involved in normal CMS and LDAP user authentication and hence the solution to solve the problem posed during manual creation of large number of LDAP users to access Lenya. Description User Authentication how it happens in Lenya The user authentication and authorization is carried out by a Lenya component known as Access Controller. The access controller would generally combine an authenticator, authorizer, a policy manager and an accreditable manager. The Authenticator is responsible for identifying a user. There are various types of authenticators that can be used but generally User Authenticator is implied, which identifi es and verifi es a user through the password. There is another authenticator known as Anonymous Authenticator that is being used for authenticating users called as anonymous. This authenticator can be further customised on the publication requirements. The Authorizer is used for determining the access for the user to invoke a certain request. This access can be based on the user profile as well as on the group profi le to which the user belongs. A policy associates a role to a user or a group. This means that a user or a group would be able to 3

5 perform certain specifi c task such as edit, review or administer. Hence, for a request, the Policy Manager determines the policy to be followed by the user. The Accreditable Manager is again a combination of User Manager, Group Manager and Role Manager. While the Group Manager and the Role Manager manage the groups and the roles respectively, the User Manager associates the user with its respective profi le maintained in a fi le. The User Manager also determines the type of the user, whether the user is a normal CMS user or whether the user is a LDAP user. All these components should be put together to understand the authentication process being followed for a request. Figure 1 User Authentication When there is a request for a URL and if the user is logging for the fi rst time or the session has expired, the login screen is produced to take the username and the password as input else the user name is retrieved from the current context. For the fi rst case, the Authenticator would authenticate and the User Manager would use respective fi les to provide the credentials to authenticate the user. If the user already exists in the context, the authentication part is skipped. The User Manager would provide the group information for the user in the context; hence, the Authorizer would associate if the user or his respective group has access to the respective URL. The association information would be retrieved through the policy fi le provided by Policy Manager for the respective request. If the users are not authorised for the request then they would be provided with the login page else they would be provided with the requested page as the response. 4

6 Authentication through LDAP We have already seen that the User Manager determines whether a user should be authenticated through fi le authentication or through LDAP authentication. If the user is required to be authenticated through LDAP, Authenticator would use the LDAP properties to connect to the respective LDAP server. The properties file would contain the respective credentials for the LDAP server, though Lenya requires some basic information to always be present in the fi le. This information includes the provider URL (both IP and port number), the base domain name and security authentication mechanism (anonymous, simple or MD5). There are certain fi elds that are mandatory to be present in the fi le but can remain unfi lled. This includes the directory manager name along with the password (it can remain unfi lled for anonymous binding), user branch (can remain unfi lled if the user needs to be searched in all the sub-trees) and the security protocol (can remain unfi lled if secured authentication is not required). This property fi le is not only used during user authentication but also during user creation. In the next section, we would see how LDAP users are being created in Lenya and what its problems are. LDAP User Creation the Problem and the Solution The users for a publication are created through the administrator interface provided by Lenya. The same interface is also used for creating various groups and for associating the users to these groups. There are two types of users that can be created through the interface, one is normal user whose password is maintained in their respective user profi le fi le and the other type of user is LDAP user. The LDAP user creation does not imply that Lenya would be able to create a new user in LDAP server. Instead, the application would be mapping this new Lenya user name to the user name already existing in LDAP server. Thus, for creating such a user, the username fi eld needs to be pre-determined from the LDAP server. Lenya would be using the LDAP properties fi le to connect to the LDAP server and search the respective fi eld. The Lenya user name LDAP user name mapping would be stored in the user profi le fi le that would hence be used by User Manager for authentication. Thus, to create a user who already exists with LDAP, a Lenya user is required to be mapped and placed in the user profi le. Consider a scenario where the number of existing LDAP user is large and all of these users are required to be associated with certain group. It would be a cumbersome process if these users are created through the interface. Also, connecting to LDAP server each time for a single user creation would further delay the process. This problem can be solved by writing a standalone program that would connect to the LDAP server once (using the same property fi le) and copy all the respective users from the server to specifi c Lenya placeholder already known by User manager. This program would be associating the users to a specifi c group as well and would maintain the profi le of these users as desired by Lenya. If a specifi c user branch is mentioned in the LDAP properties fi le then the program would pick only those users that belong to that user branch. This program can either be scheduled or can be user initiated depending on the design policy. 5

7 Conclusion We have seen the process being followed by Lenya for user authentication and the various components being involved for the same. We have also seen the difference between authentication of a LDAP user and a normal user. We have tried to understand the problem being posed for large number of user creations that would be authenticated at LDAP server and hence, the solution that can cater this problem. Similarly depending on the requirement, the other issues related with user creation and authentication can be determined and accordingly, either the existing components can be customised or an additional tool can be created. 6

8 About Open Source & Linux Practice From understanding business pain areas, recommending and implementing solutions to providing support, the OSL practice at TCS helps enterprises to overcome the challenges moving to Open Source, achieve tangible results and optimize the Total Cost of Ownership (TCO). The OSL practice offers secure and scalable solutions, built around Linux & Open Source, that cover Application Development, Reengineering, Migration, Product Porting, Application Consolidation and Kernel Programming. About Tata Consultancy Services Tata Consultancy Services (TCS) is among the leading global information technology consulting, services and business process outsourcing organizations. Pioneer of the fl exible global delivery model for IT services that enables organizations to operate more effi ciently and produce more value, TCS focuses on delivering technology led business solutions to its international customers across varied industries. For more information contact Rakhi Gupta Tata Consultancy Services Ltd. Akruti Business Port Road No 13, MIDC Andheri (East) Mumbai , India Phone: Fax: Website : All content / information present here is the exclusive property of Tata Consultancy Services Limited (TCS). The content / information contained here is correct at the time of publishing. No material from here may be copied, modifi ed, reproduced, republished, uploaded, transmitted, posted or distributed in any form without prior written permission from TCS. Unauthorized use of the content / information appearing here may violate copyright, trademark and other applicable laws, and could result in criminal or civil penalties. Copyright Tata Consultancy Services Limited 7