DEV Community

Arseny Zinchenko
Arseny Zinchenko

Posted on • Originally published at rtfm.co.ua on

Jenkins: SAML Authentication with Okta and users groups

SAMLSecure Assertion Markup Language used for federated authentication when some service which we need to get access to (a Service Provider), asks another service (an Identity Provider) to perform a user’s authentication.

Check the documentation here>>>.

  • Service Provider ( SP ): is a system where need to authenticate, in our case this will be Jenkins
  • Identity Provider ( IdP ): is a system where users are stored and which will perform exactly authentication steps, in our case this will be Okta

Their communication and steps during authentication can be displayed in the next scheme:

Here:

  • SAML Request: or authentication request, created by an SP to request a user’s authentication
  • SAML Response: will be created by an IdP and contains data about an already authenticated user and may include some additional information like user’s groups and so on

Also, keep in mind that SAML-authentication can be two types:

  • A Service Provider Initiated (SP-initiated): a service, Jenkins in this case, performs initialization to an IdP provider when a user tries to log in to the Jenkins instance
  • An Identity Provider Initiated (IdP-initiated): and vise versa – when Okta’s user will click on a button to log in to the Jenkins – IdP will initialize a request to the Jenkins (SP) to authenticate this user

In this post mostly will speak about Service Provider Initiated, but still, Identity Provider Initiated will work as well.

Also, keep in mind that an SP and an IdP will never talk directly to each other – a user’s browser will act like a “proxy” between them.

A Service Provider role

An IdP generates a SAML response for an SP and then SP has to check if this response was received from a valid IdP and then parse this response to get necessary data – a user’s name, groups, and other attributes.

To do so an SP need to obtain the next information from an IdP:

  • an IdP’s public certificate
  • ACS Endpoint (Assertion Consumer Service URL) or just “SP login URL” – an endpoint URL passed by an SP to an IdP to receive SAML replies
  • IdP Login URL – an IdP’s endpoint where SP will send its SAML requests

Jenkins SAML for Okta

The main goal in the SAML integration to the Jenkins is:

  • store users in Okta
  • Okta’s users are grouped to groups
  • Jenkins will use a Role-Based Strategy plugin which will have access roles assigned to various groups

In Okta Jenkins SAML can be configured in two ways:

  1. by using a native Okta’s application – less work for configuration, but has no ability to pass user’s groups to Jenkins, will be covered in the Okta Community Created Jenkins SAML application part of this post
  2. or by creating an own SAML-based application in Okta which will have a custom attribute with user group field will be reviewed in the Okta and own application for Jenkins SAML part of this post

With the first way you’ll be unable to use the Role-Based Strategy plugin but still can use a Matrix-based security or Matrix Authorization Strategy plugins:

The Role-Based plugin configuration will be described in the following parts and now in the post will see how to configure Okta and SAML for Jenkins in both ways mentioned above.

Okta native Jenkins SAML application

Okta configuration

Go to the Okta > Add app, find an Jenkins SAML plugin:

Set a Jenkins’ URL:

Switch to the Sign On tab:

Click on the View Setup Instructions – Okta already has all data generated here to be used by our SP (Jenkins):

Go to the Assignment tab and add the Jenkins SAML app to desired Okta’s users:

Navigate to your Jenkins.

SAML configuration in Jenkins

Install the SAML plugin:

Go to the Configure Global Security, switch your authentication realm from the Jenkins’ own user database to the SAML:

Go back to Okta and the metadata page, copy the IdP Metadata content:

Paste to the Jenkins’ SAML settings:

Return to your Okta, copy link to the Identity Provider metadata:

Set it in Jenkins to the IdP Metadata URL field:

Display Name Attribute and Group Attribute leave as is.

Check it now: open your Jenkins URL – you must be redirected to Okta:

Log in, all done here.

Okta and own application for Jenkins SAML

Now let’s add a new application in Okta which will be able to pass a user’s group to Jenkins, for example – a DevOps group:

Okta configuration

Crateate a new application:

Set its name, icon:

Next, in the Single sign on URL и Audience URI (SP Entity ID) set ACS Endpointhttp://dev.ci.example.com/securityRealm/finishLogin:

To pass user groups from Okta to Jenkins add a new field in the GROUP ATTRIBUTE STATEMENTS (OPTIONAL):

  • Name: Group
  • Name format: Basic
  • FilterMatches regex and value as .* to apply to all Okta’s groups

On the next page set I’m an Okta customer adding an internal app, and Finish.

Do not forget about Assignments.

Now, in the same way, as we did previously, click on the View Setup Instructions, copy IdP_ metadata_ and update Configure Global Security settings in Jenkins.

Copy a link to the Identity Provider metadata:

SAML configuration in Jenkins

Set this link to the IDP Metadata URL filed in Jenkins:

In Jenkins change the Group Attribute’_s value from the _http://schemas.xmlsoap.org/claims/Group to just “Group”:

Actually, that’s all folks.

Jenkins Role-based Security

Going forward a bit (will add another post about Role-based plugin configuration) – an example of Role-based Security and groups in Jenkins.

A user in Okta and its groups:

Roles in Jenkins:

And a group DevOps with a test assigned:

Done.

Useful links

Similar posts

Top comments (1)

Collapse
 
daljitsinz profile image
DaljitSinz

Expected The Icon in front of DevOps group name in last screen short and not able to get the access as followed the whole steps