By: Thu Nguyen
Read Time: 10 min
Interested in learning how to use Single sign-on in LogDNA? Single sign-on (SSO) is an authentication model designed to let users access different applications, services, and resources using a single set of credentials. Instead of having multiple user accounts for different applications, users are assigned a single centralized account that is used to authenticate with each application. This makes it more convenient for users to authenticate, while also making it easier for IT administrators to manage multiple accounts.
LogDNA supports SSO using the OAuth and SAML protocols. In this guide, we’ll explain how these protocols work in LogDNA, and walk you through the process of setting them up.
Strictly speaking, OAuth isn’t a true authentication protocol. It was originally intended for authorization—that is, allowing users to grant applications access to specific account details or resources. For example, LogDNA’s GitHub integration uses OAuth to access specific GitHub APIs, such as push and pull events. The result is that LogDNA can perform only a limited subset of actions—for example, we can’t change your profile information or delete a repository—but we never see your GitHub password in the process.
Since OAuth permissions are tied to a specific account, providers like Google and Heroku have also started to use OAuth for authentication as well as authorization. The benefit is that these platforms are already in place. In the case of LogDNA, logging in via your Heroku account is as simple as clicking a button, providing your username and password to Heroku, and clicking another button to grant LogDNA access to certain details in your Heroku account. It’s simple, seamless, and requires practically no setup.
Security Assertion Markup Language (SAML) is a protocol for authenticating users through a central authentication service. Unlike OAuth, SAML was designed for both authentication and authorization. It can not only verify a user’s identity, but it can also grant or restrict access to certain resources.
A SAML interaction involves three parties:
When a user attempts to log into the SP, the SP verifies their identity with the IdP. The IdP responds to the SP with an assertion that verifies the user, the IdP, and whether the user should be given access to the SP. The user will need to log in to the IdP if they haven’t already, but as with OAuth, the SP never sees the user’s credentials.
Because it supports both authentication and authorization, SAML is the more popular choice among large teams and enterprises. However, it’s more complicated to set up, since you must configure each SP to connect to your IdP. SSO providers such as OneLogin, Okta, Bitium, and AuthDigital make this process easier by integrating with many different SPs, and many SPs (including LogDNA) provide interfaces that streamline the setup process.
When using OAuth in LogDNA, most of the hard work is already done for you. You just need to select your OAuth provider from the sign-in page, log in to your provider account, and grant LogDNA access.
Using Okta to sign up for LogDNA with a GitHub account.
After you have authorized LogDNA, you will be signed into LogDNA using your OAuth provider account. Note that if you already created a LogDNA account using the sign up page, this process will create a completely separate account.
To make sure other members of your team can join your organization using OAuth, open the LogDNA web app and navigate to Settings > Team > Settings. Make sure “Other OAuth Sign-In” is checked, otherwise members will need to sign in using an account created through LogDNA.
Enable “Other OAuth Sign-In” to allow other team members to sign in using OAuth.
Setting up SAML in LogDNA is a more involved process. Before you begin, you will need to sign in to a LogDNA account that was created using either the sign up page or by signing in via OAuth. You can continue to sign into this account after enabling SAML, but we recommend limiting this account to administrative actions and signing in over SAML instead.
Once you are signed into LogDNA, contact us so we can enable SAML for your organization.
The process of your IdP will vary depending on who your SSO provider is. As an example, we’ll use Okta.
Start by signing into your local LogDNA account and navigate to Settings > Team >Settings. Scroll down to the SAML Configuration section. Here you will find your single sign-on URL (also known as the Assertion Consumer Service, or ACS). Keep this window open, since you will need this when configuring Okta.
In a separate window, sign in to your Okta account and select Applications > Add Application > Create New App. Select Web in the Platform drop-down and SAML 2.0 as the sign on method. On the next screen, enter a name for the app (e.g. “LogDNA”) and click Next. The Configure SAML screen is where you will add your single sign-on URL from LogDNA.
In addition, you will need to add an Audience URI (or SP Entity ID). This is simply logdna-saml/<your LogDNA account ID>. You can find your account ID in your browser’s URL bar immediately after the LogDNA domain. For example, when viewing the Manage Team screen, the URL bar will show https://app.logdna.com/<accountID>/manage/team.
Copy these URLs to the appropriate fields in your Okta window. In addition, change the Name ID format to EmailAddress and the application username to Email. Your screen will look like the following:
Click Next to continue to the Feedback screen. Select “I’m an Okta customer adding an internal app” and click Finish. Okta will redirect you to the application detail screen. Click the Sign On tab and click the link to download the Identity Provider metadata. Save this XML file to your workstation, since you will need to upload it to LogDNA to finish the integration process.
Return to the LogDNA web app and upload the XML file that you downloaded from Okta. LogDNA will automatically configure itself to use Okta for authentication. Click Save Config to save your settings, and that’s it! You can now sign into LogDNA using your Okta account.
If you want to allow other members of your team to log in using SSO, scroll to the Discoverability section of the SAML configuration screen and toggle the Join feature. You can restrict logins to your SSO account by unchecking Local Sign-In and Other OAuth Sign-in. This prevents users from signing in using an account created through LogDNA or from an OAuth provider like GitHub.
Logging is probably not the first item to come to mind when most of us think about DevSecOps, a term that refers to the integration...
Isn't all logging pretty much the same? Logs appear by default, like magic, without any further intervention by teams other than simply starting a system…...
This was originally posted on The New Stack. Once upon a time, log management was relatively straightforward. The volume, types, and structures of logs were...