Android Authenticator

Last modified by Ecaterina Moraru (Valica) on 2018/07/12 16:27



This page presents the design, architecture and general technical/implementation details of the Android Authenticator project.

The idea of this project is 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's easy to communicate and collaborate with each other. And the authenticator can also be used to provide credentials for other android apps.

There're mainly the following key tasks, such as

 - restful/solr http connector
 - authenticator service
 - synchronization service
 - large capacity performance
 - security issues


First introduce the design and implementation of the synchronization and authenticator


Server->Client Sync

There are two choices, including synchronizing all users or synchronizing the users of selected groups. We use the same method for these two cases.

Add Update

Each time while periodecally calling the synchronization method SyncAdapter.onPerformSync, we get data from server that has been modified since the last modified time. The data that we get must be updated or add to the local contact2 database. Also only these data need to be updated.


What data should be deleted for the local database?  Because the server does not return data that needs to be deleted, or maybe I do not know how to query the deleted objects?  Therefor now I just get all the user IDs(HashSet<ids>), traverse every user of the local database, find the users that are not contained in the HashSet, and these data need to be deleted, and then delete them.


For synchronizing all users:

1) Get all users as List<SearchResult> searchResults

2) Add Update: SearchResults include the last modified time. So according to the time, we can filter what data should be updated or added. Then call the function ContactManager.UpdateContacts to update local db.

3) Delete: searchResults already have user ids, so we can get the IDs(HashMap<id,Ojbect>), then traverse the local database to find what data should be deleted.

For synchronizing users of selected groups:

1) Get all selected group ids from local sharepreference xml,  as List<String> groupIds

2) Get the users' simple information(ObjectSummary) of each group one by one. The ObjectSummary only has the user's id without the last modified time.

3) Add Update: According to the user ids, we get the last modified time for each user, if before the given last sync time, continue; if after, we update user (but we need first get the detailed information of the user.).

4) Delete: at seconde step, we get ObjectSummarys which include all the user ids. So with these ids, we can find the data that should be deleted.

Code Detail

 1 XWiki.getUserList.  get all users that have been modified after lastmodifiedtime from server.
 2 ContactManager.UpdateContacts. (add update delete the local database)
     2.1 add users if lookupRawContact return false;
     2.2 update users if lookupRawContact return true;
     2.3 delete users
           2.3.1  XWikiHttp.getAllUserMap from server as A.
           2.3.2  getAllContactsIdMap from local database as B.
           2.3.3 delete the user [B-A] that is in B but not in A.

Client->Server Sync

For this part, As we will first update the server while editing the contact, Therefore, unnecessary synchronization mechanism is not required. If the server's response is that the editor has no permission, we return; if has been updated in the server, we will update the local database at the same time.

 1 check if input values if valid
 2 Request to update contact in server
    2.1 If having no permission, give up.
    2.2 If having permission, update local database
 3 NOTE: Update server first, if the response is ok, then update local database.


1. How to grant the permission for third party apps when they calling getAuthToken? (Here, AuthToken is equal to Cookie.JessionId)

Basically, only 3 useful interfaces, like AddNewAccount, getAuthToken, invalideAuthToken, are available for other third party android apps. The most widely used is getAuthToken. How should we grant permission for third-party apps? And when we grant? If adding XWiki account from one app, then we can trust this app and grant the getAuthToken permission. But if not, we should check the permission for every getAuthToken request of third-party apps.  So the checking logic code should be in the function getAuthToken. But XWikiAuthenticator.getAuthToken will never be called if AcountManager has cached the authtoken corresponding to AuthTokenType. Therefore for first granting permission for third-party apps, the app should not pass the same authTokenType when calling getAuthToken function. Or the authToken value will be directly returned by AcountManager according to the same AuthTokenType and the method getAuthToken will never be called.  So different apps should use the different AuthTokenType param to call the function getAuthToken so that the <AuthTokenType, AuthToken> will not be cached before granting permission for this app. AuthTokenType=FULL_ACCESS+PackageName. So in XWikiAuthenticator.getAuthToken function, if we check that the third-party app has not been granted, we startActivity(GrantPermissionAcvivity) to grant permission for this package by checking the user's input password.
 And in addition the packageName can't be forged because we can use the options.getInt(AccountManager.KEY_CALLER_UID) to verify the pakageName.

2. How to maintain authToken consistency for different third-party apps with different AuthTokenType?

When will appear inconsistent? There are mainly two key cases, the authToken is expired or the third-party app calls the invalideAuthToken function. Now, I use the following solution to these problems.
 1) When the authToken is expired, xwiki authenticator app will login again and refresh all the cached authToken for every AuthTokenType.
2) When the third-party app calls the invalidAuthToken function, then corresponding cache will be clear and getAuthToken will be called, then XWikiHttp.login will be called to get a new token and refresh all the cached authToken for every AuthTokenType.
3) So if any one finds the authToken has been expired, then login and refresh all the cached authToken to maintain consistency.  In addition, I suggest that if the third-party app find the authToken is expired after a period of time, then first call getAuthToken again. If the token is different, then maybe authenticator has already update the token. If the token is the same, just call invalidAuthToken and getAuthToken again.


1. ask for Permission Granting.  If permission granted, store in preference.
2. after passing 1 step,  peekAuthToken to get an cached token for different AuthTokenType(FULL_ACESS+PackageName).  If get a token that is not null, return.
3. if step 2 fails,  ask XWiki-server for a new token. If failed return network error.

Main classes and functions


Note: for third-party apps, there are mainly the following apis:

 1. getAuthToken
 2. invalideAuthToken
    Generally, only when we find the authToken getting from getAuthToken function was expired, we will invalide the token and let go to authenticator.getAuthToken
 3. addNewContact
 4. confirmCredentials

Rest Api and Solr Query about users and groups

*Sign In




curl -u user:passwd http://localhost:8080/xwiki/bin/login/XWiki/XWikiLogin -v

curl -X GET -H "Content-type: application/x-www-form-urlencoded" -H "Authorization: Basic dXNlcjpwYXNzd2Q=" http://localhost:8080/xwiki/bin/login/XWiki/XWikiLogin -v

curl -X GET -H "Content-type: application/x-www-form-urlencoded" -H " Cookie: JSESSIONID=v2ozvkq8meij34sblzcss1j;Path=/xwiki" http://localhost:8080/xwiki/bin/login/XWiki/XWikiLogin -v

*Sign Up  

curl -u username:passwd –X POST –H "Content-type: application/x-www-form-urlencoded" –d "form_token=" –d "parent=xwiki:Main.UserDirectory" –d "register_first_name=" –d "register_last_name" –d "xwikiname" –d "register_password" –d "register2_password" –d "register_email" –d "captcha_answer" –d "template=XWiki.XWikiUserTemplate" –d "xredirect=/xwiki/bin/view/Main/UserDirectory"  -v

return all 200ok, so I use jsoup to analyze the returned html. If it contains the login button, I think it’s successful for this registeration.

* Get All Users:

default number<=10

* Get User Information(DONE)
 for example XWiki.LudovicDubost

* Get user’s Avatar

For example:

Get avatar image name (ludo3.jpg):

Get the image attachment:

*Get User’s last modified time:





* Get Groups(DONE)

* Get User From Group(DONE)
 for example XWikiAdminGroup:

* Edit Contact
 curl -u username:passwd -X PUT -H "Content-type: application/x-www-form-urlencoded" -H "Accept: application/xml" -d "className=XWiki.XWikiUsers" -d "property#company=iie" http://localhost:8080/xwiki/rest/wikis/xwiki/spaces/XWiki/pages/username/objects/XWiki.XWikiUsers/0
 curl -u username:passwd -X PUT -H "Content-type: application/x-www-form-urlencoded" -d "className=XWiki.XWikiUsers" -d "property#company=iiedacas" http://localhost:8080/xwiki/rest/wikis/xwiki/spaces/XWiki/pages/username/objects/XWiki.XWikiUsers/0

* Edit Test Object
 $ curl -u Admin:admin
        -X POST -H "Content-type: application/x-www-form-urlencoded"
        -H "Accept: application/xml"
        -d "className=XWiki.TestClass"
        -d "property#test=Whatever you want"

* Create a new page
 create page
 curl -u Admin:admin -X PUT --data-binary "@newpage.xml" -H "Content-Type: application/xml" http://localhost:8080/xwiki/rest/wikis/xwiki/spaces/Main/pages/NewPage
 <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
 <page xmlns="">
     <title>Hello world</title>
     <content>This is a new page</content>

* Delete
  curl -v -u Admin:admin
        -X DELETE http://localhost:8080/xwiki/rest/wikis/xwiki/spaces/Main/pages/WebHome



Get Connected