GSoC

Last modified by Michael Hamann on 2023/06/16

21 posts

[Blog.RajatGSoCExperience] is not a blog post!

[Blog.GSoC 2021 With XWiki For XWiki-AWS Integration.WebHome] is not a blog post!

Aug 20 2021

My Journey with XWiki - GSoC'21 and Beyond

1_l7N4CZhyIBiILSNpQRmCoA.png

Since the Google Summer of Code 2021 comes to an end, I got to say the experience that I got from this program is indeed amazing. During these 10 weeks, I got to learn a lot of skills and it indeed helped me become a better Software Engineering student. All the credit goes to the very welcoming XWiki community and the wonderful bunch of experienced mentors that we have, here.

About me

My name is Mohammad Humayun Khan. I am currently a 5th-semester Computer Engineering student from ZHCET, AMU, India. I am working on the project "Add WebAuthn support to XWiki" as a GSoC 2021 student here, at XWiki. 

Add WebAuthn support to XWiki

The aim of the project is to add Web Authentication (or WebAuthn) support to XWiki open source software which will allow the users of XWiki to authenticate themselves without having to type their password every time they try logging in (removing passwords from the picture, itself). Through this project, we want to go a long way in minimizing some untoward incidents like ‘phishing’, ‘stolen credentials’ and ‘replay attacks', etc. The fact that a password is a shared secret makes it vulnerable. Public-key authentication doesn’t have that weakness, and the WebAuthn API enables servers to register and authenticate users using public-key cryptography instead of a password. 

Description

The way we implement this is, we take in the 'username' of an already existing standard XWiki user and then we have the following options:

  • Register WebAuthn credentials for this user. These credentials will be saved as custom xobjects in the XWiki user profile.
  • Authenticate the user: The xobjects saved in the XWiki user profile of a standard XWiki user will be used to authenticate the user.
  • Delete credentials: All the xobjects that have WebAuthn credentials for a particular user will be deleted.

We will also have an option to Skip WebAuthn if we are not on a supported browser. This is a fallback to default login form.

Work summary

Community Bonding Period

(May 17, 2021 - June 7, 2021)

The community bonding period started with a video chat between me and my mentors, it was indeed a good session where the mentors told me about the existing practices and the workflow that I should follow while working on the project. After that, I started polishing the skills that were required of me to work on the project (mostly Java and Maven). I looked into some existing authenticators that were already present and used, and I also looked into XWiki's APIs (JavaDoc) in order to better understand their code. I also tried solving existing issues in the main XWiki repo: https://github.com/xwiki/xwiki-platform  and in OIDC: https://github.com/xwiki-contrib/oidc in order to learn more about the authentication framework and tools that are being used in XWiki.

First Phase

(June 7, 2021 - July 16, 2021)

I started coding in the first phase on June 14 since I was involved in the end-semester examinations at my university. One of the first tasks involved setting up the maven project for this authenticator. After that, I tried to create a basic authenticator which extended XWikiAuthServiceImpl (the authenticator's only public API which is exposed is recommended to extend it). 

I looked into the library, that is supposed to be used for this project: https://github.com/yubico/java-webauthn-server and did detailed research into the JavaDoc in order to get to know about the integration points that it provides. After that, I started adding the data transfer objects that were intrinsically the request objects that were supposed to be given as arguments to the WebAuthn API JS calls: navigator.credentials.create() and navigator.credentials.get(). Also, I added the basic structure for the module and added more utility classes till the end of the first phase and planned on building on the same.

Final Phase

(July 16, 2021 - August 16, 2021)

In the start, I added the events that were to be sent while authenticating the users as well as after adding xobjects to the XWiki user profile, I prepared local cache storage which essentially extended the CredentialRepository: https://developers.yubico.com/java-webauthn-server/JavaDoc/webauthn-server-core/1.7.0/com/yubico/webauthn/CredentialRepository.html interface (one of the integration points for the library) and wrote functions which were supposed to manipulate the database lookups by the library. 

The main problem that started to occur was during instantiating the https://developers.yubico.com/java-webauthn-server/JavaDoc/webauthn-server-core/1.7.0/com/yubico/webauthn/RelyingParty.html class which was an entry point into the library. The problem was that this library didn't have anything to do with HTTP requests/responses and only relied upon an embedded server/framework that can send the WebAuthn JS API calls by taking request objects as their parameter, what it did the best was to perform the validation logic after receiving the response from the client. The construction of instances using builders gave me a nightmarish deal as well as I did get a lot of errors while building using maven (the funny part was that, the IDE didn't give any sort of errors as such then). I then commented those classes to at least perform a clean build. In general, in both the registration as well as authentication part of WebAuthn, the whole thing of serializing these requests objects to JSON and then passing it to .create/.get JS calls and then receiving the response from the client, and deserializing it to save in a custom Java object was indeed the most challenging part to me.

During the end of this period, I created the velocity template that will be shown to users when they set it as an authenticator. But I was not able to make it perform the registration and authentication operations due to the limitations of the library. Implementing WebAuthn obviously requires a library that can take care of the requests/responses and the complex server-side cryptographic operations, that are actually the core part of it. 

Future plans

I intend to continue working on this project after GSoC as it is my 5th-semester college project as well. The end goal is to provide a cool authenticator to the XWiki open source project which would be future-proof as well as compliant to one of the most sought-after security protocols that are currently being implemented to enhance security in various platforms.

I will try to study the library again, and see/plan with Thomas (authenticators expert at XWiki) about what can we do on the XWiki side to send these requests to the WebAuthn JS API calls and thereafter take care of the serialization and deserialization as well as manipulating the database lookups. If it will not be possible to implement the WebAuthn operations using this library, then I will switch to the https://github.com/webauthn4j/webauthn4j library which is the only other library that supports the WebAuthn based server-side operations in Java. Hoping to make it work!

I will also try to find ways in which I can help the XWiki open source project since I still have 2 years left to graduate and plenty of room for improvements and learnings. I will stay connected with the amazing XWiki community and will try to help newcomers and will also inform if I'll come across an interesting idea to work here, on a project as well.

Lastly

And most importantly, I would like to thank my mentors: Thomas Mortagne and Fawad Ali for taking their time out to help me in resolving my issues and queries whenever I needed them. I seriously could not have wished for any better mentors while working on my first-ever real-world open-source project, they were indeed wonderful.

Also, a big thanks to Eduard (Enygma), Vincent, Simon, Sachin, Manuel, Marius, Clément, and everyone else in the Mentors team for their help throughout the program. Congratulations to the co-GSoC student Sanchita for the work that she has done on her project, it is quite appreciable.

Working as a student here at XWiki has been a fun and enriching experience for me during which I learned a lot of things: debugging, testing, doing a release, communicating in a team, best practices related to software development, etc just to name a few and I am quite indebted to XWiki, for the same.

Forum post: https://forum.xwiki.org/t/add-webauthn-support-to-xwiki-gsoc21-project/8812

Design page: https://design.xwiki.org/xwiki/bin/view/Proposal/AddWebAuthnsupporttoXWiki

XWiki Dev project page: https://dev.xwiki.org/xwiki/bin/view/GoogleSummerOfCode/AddWebAuthnsupport2021

XWiki extensions project page: https://extensions.xwiki.org/xwiki/bin/view/Extension/WebAuthn 

Aug 26 2019

My GSOC19 Experience

Hello there! My name is Divyansh Jain. I am a student at Mahatma Jyoti Rao Phoole University. I have been selected as an Android developer for the XWiki organization and I've finished working on their XWiki Android Authenticator application in GSOC19. ...

My GSOC journey with XWiki

Mentors:

I want to thank my mentors Shubham Jain, Neha Gupta and XWiki organisation for giving me such an opportunity and helping me out throughout my journey of GSOC. I also want to also thank Vincent Massol for helping me out in one of my dependent project.

A little bit about me

My name is Ashish Sharma, I am 23 and I am a final year student from Bharati Vidyapeeth's College of Engineering, India. I have participated in GSoC'19 program as a student in XWiki and worked on "Helm chart for XWiki".

What did I expect from GSoC 2019

This was my first Google Summer of Code and the concept to contribute for 3 months in an open-source organisation was exciting for me. I got an opportunity to work remotely on a project. I was curious to explore how an open-source organisation work. Anyway, I have expected new experience in remote internship, open source project contributing, Google Summer of Code participating and international only remote communication.

In this post I want to describe what I have finished and what is not completed yet and why.

Description

This project focoused on creating a helm chart that would deploy xwiki on Kubernetes by using helm templating. The deployment should be configurable to be scalacble, highly available and roboust.

You can find the project code at

https://github.com/xwiki-contrib/xwiki-helm and

The issue tracker can be found

https://jira.xwiki.org/projects/HELM/issues

How to use the result of my work

git clone https://github.com/xwiki-contrib/xwiki-helm
cd xwiki-helm-chart
helm dependency update
helm --debug upgrade -i --force xwiki -f ./values.yaml .

Read about prerequite

Milestones

Milestones 1:

Creating a basic helm chart

  • Understanding xwiki's docker structure.
  • Understanding and taking the decision for using the correct resource to host xwiki.
  • So I started up using the StatefulSet, clusterIP service and ingress.
  • Added values files which help in making the chart dynamically configurable.
  • Then we neded to support multiple databases and was in a need of a solution that don't require to deploy database externally, so a good standard for adding dependency for other services like database were needed.
  • So we decided to add database as a helm dependency, that helped us to templatise the databases in our application which makes deploying databases easier, we don't need to deploy the chart seprately.
  • So we added support for database mysql and postgress through dependency and also given option for user to deploy it's own external database.

Milestestone 2:

Adding support for ISTIO and other features

  • Till now we have a chart that would deploy our standalone application, now we need
  • Added support for ISTIO
  • Till now the helm were taking values from values file, we needed a way to manage our envoirnment variable that we pass to our container, and we also need to secure the sensetive variables like db password. For that I used Kubernetes resources configMaops and Secrets. These help us save and manage our variable securely and properly.
  • XWiki-helm also needed an optional feature to havdle Pod disruption, if the users have a heavy dependency on xwiki. This features make the xwiki chart user configure the minimum number of pods that should be running while pods are been destroyed due to any reason.
  • A need for shared file storage were needed, secially when serviec provider like GKE does not provide ReadWriteMany option, so to run xwiki on cluster we need different database solution like Rook, I had researched about it and also written a blog on how to set up Rook on GKE for shared file system

Milestone 3:

Adding support for clustering,HA and Unit testing

  • While moving towards HA and clustering we got to know that XWiki need shared file storage for clustering which was not available in StatefulSet, so we made a desicion to migrate to Deployment.
  • We needed to add test-cases so I added unit-testing.
  • Clustering was required to take xwiki on HA. For that we need docker to enable option to configure clustering, so first I made changes in docker project and provided option to configure JGroups.
  • Then I needed to provide the option in helm. For that I had to face another challenge to how to pass configuration files needed by JGroup from my helm chart to the container. For that I took the file in ConfigMaps and mounted the file to the xwiki pods. Also provided option to enable and disable JGroups.
  • While enabling clustering we need to know which pods are avialable to accept request and which are dead so that we can route traffic accordingly, for that I needed to configure liveliness and readiness probes, so that kubernetes always get updated with the state of the container and if the container crashes it could restart the pod.
  • XWiki uses solr and the docker it embededs solr internally, but as suggested by XWiki for performance improvement solr should be externalised, so I tried to add it as a dependency but failed due to an immature helm chart of solr, and how the xwiki configures solr, it was not possible with the current solr chart state. So for now I have exposed the basic parameter and the user has to manually setup solr and pass the url of the solr.

Jun 26 2019

Reasons to choose Kotlin

Hello there! My name is Divyansh Jain. I am a student of Mahatma Jyoti Rao Phoole University. I have been selected as the Android developer for the XWiki organization and I am working on their XWiki Android Authenticator application in GSOC19.

XWiki android Authenticator aims to integrate a wiki instance in Android accounts, mainly including the synchronization of contacts and the XWiki authenticator. By synchronizing contacts of your company on your phone, it becomes easier to communicate and collaborate with each other.

Ever since the start of my work on the XWiki Android Authenticator app, I have been constantly learning new things. In the first week, I migrated most of the XWiki Android Application code from Java to Kotlin. And on this page, I would like to share my understanding of Kotlin that I have gained so far.
 

Getting started with Kotlin

Kotlin is officially supported by Google for mobile development on Android. It was released in Android Studio 3.0 on October 2017. At first, I was a bit afraid to switch to Kotlin since I feared that the code might crash and not run properly, but as I read the documentation, I started understanding the nuances of the language which made the switch from Java to Kotlin an easier process. I started realizing the advantages of Kotlin over Java. Some of them being:

Java Interoperability

I started with migrating the whole XWiki Android Authenticator app code from Java to Kotlin. I was replacing one Java file at a time, and while migrating I saw that Kotlin worked with Java smoothly. Though it required some direct imports, there were no errors in running the app on the device.

Changed variable declaration

In Java, we declare string for instance, String str = "Hello";.

In Kotlin, we declare string for instance, val str = "Hello" or val str: String = "Hello". Here val declares a read-only property or local variable whereas var declares a mutable property or local variable.

The final keyword is default in class

In Kotlin final is a default. E.g.

             
class Button {
   fun click() = print("Click")
}

class displayToast : Button() {  // Error
   override fun click() = print("Toast Displayed") // Error
}

In the above example, class displayToast can’t inherit Button class because it is final. Moreover, it can’t override click(), because it is final in Button.

open class Button {
   open fun click() = print("Click")
   fun doubleClick() = print("Double Click")
}

class displayToast () : Button {           // Inheritance is now possible
   override fun click() = print("Toast Displayed") // Now it works
   override fun displayToast () = print("Toast Displayed") // Error
}

In order to inherit and override, we put “open” keyword that allows inheritance and overriding.

Fun keyword for defining functions

Now in Kotlin, there is a new way to define functions. E.g.

fun displayToast() { } //with no arguments inside functions

fun addDigitis (a: int, b: int) : String { }  //with arguments inside function

It is same as the Java parameterized method or empty method.

The when expression

The "switch-case" is replaced with the much more readable and flexible "when" expression: E.g.

int x = 3
when (x) {
   1 -> print("x is 1")
   2 -> print("x is 2")
   3, 4 -> print("x is 3 or 4")
   in 5..10 -> print("x is 5, 6, 7, 8, 9, or 10")
   else -> print("x is out of range")
}

It works without the argument too.

Static keywords

For declaring static methods & variables, you can put them above the class name, then you can use them by importing directly in other classes.

Null Safety

One of the biggest flaws in Java is the way it handles “null,” leading to the dreaded NulPointerException (NPE). Kotlin resolves this by distinguishing between non-null types and nullable types. Types are non-null by default, and can be made nullable by adding a safe call ‘?’. E.g.

var a: String = "abc"
a = null                // compile error

var b: String? = "xyz"
b = null                // no problem

Conclusion

So after seeing, reading and migrating the code from Java to Kotlin, in my honest opinion, I do not see any reason to not choose Kotlin over Java. For instance, we need to write less code as compared to Java, we don't have to face the dreaded ‘NPE’ error anymore, interoperability with existing Java files, smart casts while declaring variables and many more. We've given the fair amount of our time to Java, but it's time to let it go and welcome our new friend Kotlin.

Happy Reading.

Aug 23 2018

Google Summer of Code 2018 Wrap-Up

This is the eleventh year XWiki has participated in the Google Summer of Code program. XWiki had 12 mentors involved at various levels and 3 successful projects implemented. ...

Aug 13 2018

My GSOC adventure with XWiki and Dokuwiki

The project focused on improving the existing DokuWiki importer that imports instances of DokuWiki to XWiki by using some intermediate common events based on Filter Stream Framework. In the previous Dokuwiki importer module already supported basic functionalities. Improvements like support for handling unserializing of files with no metadata, lists, image-link, interwiki-link, macro support and other syntax-parser bug resolution. ...

Aug 08 2018

My GSoC 2018

Aleksei Ovsiannikov summary of experience in participating in GSoC 2018 and open source projects contributing. ...

Get Connected