Below are frequently asked questions about Okta and GitLab's implementation of it. If you have an additional question that is not listed here, please add it to our Okta FAQ doc and we'll improve this list.
The activation workflow is triggered by the creation of account within Bamboo HR.
Okta supports the following Web Browsers: Internet Explorer, Firefox, Safari and Chrome. Okta also works through Mobile Apps on iOS and Android.
Plugins are applications that can easily be installed and are used as a part of a web browser.
GitLab is using Secure Web Authentication (SWA) for many of its apps, and the Okta plugin is necessary to work with these applications. For applications that support SAML, the Plugin is not necessary. GitLab recommends all users install the browser plugin as required.
The security image is a cookie that is set when you log in. If the cookies in your browser have been cleared, you may not see the security image until the next time you log in.
Yes, the Okta plugin is very safe to install.
To create a new tab, click on the '+' sign next to the last tab. You will be asked to enter a new tab name (for example, "Personal"). Enter the new name of the tab and click save to create it.
You can have up to five tabs.
To delete a tab, you will need to move all applications out of that tab into another one. Once the tab has been emptied you will see a Delete Tab option. Select that option and your tab will be deleted.
You should make application request via the GitLab Okta access request form. If the app is not yet in the Okta Application Network, it’s easy to add. Select the ‘Add an App’ button, create a ‘Bookmark,’ input the login URL and finally, check the box that reads ‘Request App ‐ Ask Okta IT to add this app’.
To change the order of your apps, click and hold on an app icon, then drag and drop the app to the location you would like it to be displayed.
To move an app from one tab to another, click and hold on the app icon, then drag and drop your app to the new tab.
Apps you've installed can be removed by hovering over the app and selecting the gear icon. In the app setting screen, you'll see the option to delete it. Apps issued by the GitLab Okta administrator cannot be removed, but there is a way to move the app out of sight. The best way to do so is to create a new tab to store unused and unwanted applications.
A bookmark is a way to save the URL login of an app not currently available to you. When you create a new bookmark, your Okta dashboard will display an app icon to that app URL login. This bookmark will only store the URL, not your username and password.
To add a bookmark, go to the "+Add Apps" button on the top right of your dashboard to open a search menu. Search for your app. If no app is found, Okta will display the option to create a bookmark. Enter the URL of the app and the name of the bookmark you would like displayed. Click ‘Add’ button to create your bookmark. Click on "Home” at the top of your dashboard to see your new bookmark.
At the top of your dashboard, you can find apps in the "Launch App" search bar. If you can't remember which tab your app is on, go to the Launch App search, type in the name of your app and select the name to open it when it appears.
No, Okta only acts as an integrator to the various apps. The information that the user stores inside of the app, is not accessible by Okta. The usernames and passwords (user credentials) are encrypted using both an industry-standard encrypted AES and a randomly generated symmetric key.
SWA - A SWA integration provides single sign-on for apps that don't support proprietary federated sign-on methods; it works with any web-based app. If your SWA app integration is successful, the following happens when end-users click the app chiclet:
SAML - A SAML (Security Assertion Markup Language) integration provides Federated Authentication standards that allow end users one-click access to the app. SAML is an XML-based standard for exchanging authentication and authorization data between an identity provider (IdP) such as Okta, and a service provider (SP). If your Application supports SAML, then this is a better Authentication Protocol over SWA. When SAML is enabled Okta will be the Authentication provider for the application, also, this Authentication Protocol will give you more control over your users Authentication behavior. Okta can authenticate to Cloud Applications using SAML Assertions, a “passwordless” assertion method that is authorised based on a trust decision from Okta based on its authentication policy. This reduces the exposure for credential leakage and eases auditability.
There is an example of this in the Application configuration Video linked on the Okta page. In short, click on the Add Apps button, search for the App you want to request, and click the request button. As a best practice, link in the Access Request issue created so that the Application owner understands the requirements of the request!
Yes, we can add App Notes to each of the Apps, and will work through them to add intuitive labels. For an example, we have already enabled this on BambooHR and a few others. To configure Apps and improve your user experience, please see the Dashboard Tips video on the Okta main page.
There are plenty of Applications that need conversion to SAML. BambooHR/Greenhouse/Sisense/Slack are examples. The next stage of the Okta project is to work with the application owners of these Apps to convert them. SAML/SSO is tricky though, in that most applications are either/or with using username/ password or SSO, so changing these applications to SAML now would have the effect of locking out everyone who isn’t using Okta from those applications!
At GitLab, your GitLab email address is your username. If you've forgotten your password, use the 'Forgot password' link at the bottom of the sign‐in page to generate a new one.
Okta supports strong passwords through the use of password complexity rules and length, consistent with our password policy. Please follow GitLab’s Password Policy guidelines to determine the rules.
Your user credentials are encrypted using both an industry-standard encrypted AES and a randomly generated symmetric key. This key-store, containing your symmetric encryption keys, is then encrypted with a master key that is held only in memory and only accessible to the Okta app. At startup, the app is provided a master passphrase allowing it to access, decrypt, and store the master key in memory. A technical operations administrator at your company inputs the master passphrase. Only a select number of administrators know this master passphrase. As a result, attackers can only decrypt the data if they have the master key, private key, as well as the user's app context.
With Okta you can access your applications through a single, unified dashboard. Access to these applications is delivered through single sign-on (SSO) technology via either Security Assertion Markup Language (SAML) or Okta’s Secure Web Authentication (SWA) technology.
With SWA, you may need to enter your username and password upon the first use of that application. If an app requires you to make a password change, you should do so within the Okta dashboard. With SAML, Okta automatically passes on access via a token, so you don’t need to manually make a change when the app requires an update.
To change your password for a specific application, hover your mouse over the app's icon. Click the gear to go to settings, which should open a menu that gives you the option to change your password for that specific application.
If you are not able to update the username and password, contact GitLab Okta support or the ITOps team. Can I be confident my password is safe? Yes, nobody (including GitLab administrators or IT support) have access or visibility into your password data.
Okta uses strong encryption to secure data and uses strong (256-bit AES) encryption for username and password credentials. This information is stored and maintained by Okta.
Okta has two controlled re-authentication parameters – Factor Lifetime and Session Lifetime.
Factor Lifetime: Setting a factor lifetime is a way for end users to sign out for the amount of time noted in the Factor Lifetime and not have to authenticate again with MFA at the next sign in. End users must check a box to confirm that the setting should be applied. We have configured this to be 15 minutes. If you are logging on with a machine that isn't your usual device, make sure you don't check this button!
Session Lifetime: The maximum idle time before an authentication prompt is triggered. We have configured this to be 16 hrs. This is the more significant factor to note in relation to authentication, and should mean that if you log into the Okta dashboard using MFA, you should not be prompted for any additional authentication during your working day unless a specific application requires you to re-auth. For most people, this creates a straightforward daily process where they log into Okta once at the start of their day, and can keep their browser open to access applications for the rest of the day.
If you are having issues with excessive authentication requests, please log an issue and we will investigate.
The GitLab administrator can see your username, but he or she does not have access to your password or any other credentials or devices you use to authenticate.
Yes, Okta has been configured such that - it adheres to the GitLab password policy and restrictions.
For many applications, that’s correct. The goal will be to focus on Logins in 1Password and migrate as many of them (particularly shared passwords!) to Okta. There are other things like Secure Notes that don’t translate, so we won’t be completely getting rid of 1Password for a while.
Yes, once you’ve put the credentials in Okta, you may delete it from 1password.
Yes, this is fine. Our end state will be to use Okta for most/all applications, but in the meantime existing authentication methods are fine. Once we have broader user adoption of Okta, we’ll be taking on migration of some of these apps to use Okta instead of Google OAuth, where this makes the most sense.
At this time there is nothing stopping someone from using personal credentials. See the video created about configuring Apps for more details.
MFA is strictly enforced on Okta. This acts as a gateway to the services it manages. So those services, in effect require MFA via Okta login.
Okta has some capacity to do that. There can be some device-level controls, but won’t be on Day 1 of rollout. On Day 1 we’ll have IP-based controls based on threat intelligence feeds.
Okta does not log you out of your applications even though you might be logged out of your Okta session.
Okta is built on an “Always On” architecture. However, if their services were to go down, you would not be able to log in to your GitLab Okta platform and access your applications via Single Sign‐On. However, some applications might still be accessible through a direct link. When Okta is down, basically GitLab will be down. Any mitigation strategy would enlarge our security surface area.
When Okta is down we are down. Any mitigation strategy would enlarge our security surface area. Okta is built on an “Always On” architecture. However, if their services were to go down, you would not be able to log in to your GitLab Okta platform and access your applications via Single Sign‐On. However, some applications might still be accessible through a direct link.
In the case of an Okta emergency, contact GitLab Okta administrators (IT Ops) for assistance. Alternatively, there is a #it-help channel on Slack.
No, this does not exist within Okta. But this should be something security automation team can help with. There are some automated security notifications already enabled for things like MFA or password changes, as well as connections from new and unrecognised devices. GitLab is able to perform reporting on these based on built-in reporting.
Automating access requests is one such thing. This is not going to be magically solved. Manager approval is not possible with Okta as yet. We are working towards other ways and means to achieve this.
There is capacity to do this, but further research is needed to understand the application use case for this. At this stage, requirement for VPN is not enabled.
We do not remove GitLab accounts currently for off-boarding, currently we remove users from GitLab groups. When offboarding happens, your Okta account and related accounts are Deactivated or Suspended.