Last week I spent a good while on writing a new security realm for KDE’s Jenkins setups. The result of my tireless java brewing is that the Jenkins installation of KDE neon now uses KDE’s Phabricator setup to authenticate users and manage permissions via OAuth.
We should hopefully see this roll out to the KDE CI Jenkins as well in the near future.
Since the documentation seems a bit scarce I am going to throw together some thoughts on how to implement OAuth security realms. For a primer on general plugin development I suggest having a look at the Jenkins Plugin Tutorial.
Jenkins security is split into two parts. The SecruityRealm controlling authentication of users and the AuthorizationStrategy controlling permissions of the users. These two are plugin description points for the respective functionality in Jenkins’ security.
The important thing to remember is that you can implement one without the other. For example the KDE OAuth plugin only implements a SecurityRealm as we currently have no need for our own AuthorizationStrategy. The Role Strategy plugin on the other hand implements only an AuthorizationStrategy.
To successfully implement a SecurityRealm you will need your realm class which is going to extend SecurityRealm and implement a UserDetailsService (this will actually only be used internally to, among other things, log in a user for API transactions). The SecurityRealm will use an AuthenticationToken to actually manage a session and a UserDetails instance to represent a user entity.
You can find some boilerplate code to outline a primitive realm we could use for OAuth2 in this git repository. Which would get a call-sequence similar to this one upon login request:
- getLoginUrl (redirects to commenceLogin)
- doCommenceLogin (redirects to request URI on oauth host)
- doFinishLogin (gets redirected to by oauth host once authorized; requests access token)
After doFinishLogin the user should be authenticated and logged in. As you will probably notice there is talk of MyAuthToken and MyUser. Sample code for those is also available in the git repository.
They are both not terribly complicated, for the most part they are simply plain old data objects representing a session and a user. It is probably worth mentioning that a GrantedAuthority is approximately equal to the concept of a group membership, so much so that if you add more GrantedAuthorityImpls Jenkins will handle them as groups listed on the user profile and for use in AuthorizationStrategies.
MyAuthToken auth = new MyAuthToken(accessToken); SecurityContextHolder.getContext().setAuthentication(auth); SecurityListener.fireAuthenticated(auth.getUser());
And that’s all you need for your SecurityRealm. For the most part your realm will simply create a token “somehow” and then set it as active on the SecurityContextHolder. Once that is done you have an authenticated session at your hand.
For some more inspiration hop on over to my actual plugin’s git repository.
💺 Blog 