<html><head></head><body><p>With the release of version 6.4.0, Elasticsearch is able to run in a FIPS 140-2 environment. This means Elasticsearch 6.4.0+ can be run in FIPS 140-2 mode&#xA0;when properly configured within an approved environment. Additionally, a Platinum <a href="/subscriptions">subscription</a> is required to&#xA0;enable&#xA0;this feature.
</p><h2>What exactly is FIPS 140-2 ?</h2><p><a href="https://csrc.nist.gov/csrc/media/publications/fips/140/2/final/documents/fips1402.pdf">FIPS 140-2</a> is a U.S. Government computer security standard authored by the National Institute of Standards and Technology (NIST). FIPS stands for &quot;Federal Information Processing Standard&quot;, 140 is the Publication number, and 2 refers to the fact that this is the second version of this Standard. It governs security requirements that must be satisfied by hardware and software cryptographic components:
</p><blockquote>The security requirements cover areas related to the secure design and implementation of a cryptographic module. These areas include cryptographic module specification; cryptographic module ports and interfaces; roles, services, and authentication; finite state model; physical security; operational environment; cryptographic key management; electromagnetic interference/electromagnetic compatibility (EMI/EMC); self-tests; design assurance; and mitigation of other attacks.
</blockquote><p>Yes, it&#x2019;s complicated, but the stated goal was to create a minimum level of cryptography for data the government considered sensitive, but unclassified. There are four levels within FIPS 140-2, with each level&#xA0;increasing requirements on the components, like tamper-evident physical security mechanisms or access to important settings within the component. Not all levels are applicable for all component types. Typically software can only achieve level 1 certification, for example, because you can not physically access it directly: you need to interact with hardware.
</p><h2>Why should you care?</h2><p>Cryptographic components help ensure that stored data (&#x201C;data at rest&#x201D; and &#x201C;data in use&#x201D;) and data moving between systems (&#x201C;data in transit&#x201D;) is not viewed or changed by unauthorized people. By encrypting data with a cryptographic function &#x2012; locking it &#x2012;, the data cannot be read without the right key to unlock it. One can go a step further and &#x201C;<a href="https://en.wikipedia.org/wiki/Digital_signature">sign</a>&#x201D; data with a cryptographic key so if someone attempted to alter the data, the recipient could detect the tampering. &#xA0;
</p><p>That&#x2019;s the idea, anyway. Cryptographic strategies have a <a href="https://en.wikipedia.org/wiki/Enigma_machine#Breaking_Enigma">history</a> <a href="https://web.archive.org/web/20000302000206/http://www.dvd-copy.com/news/cryptanalysis_of_contents_scrambling_system.htm">of</a> <a href="https://eprint.iacr.org/2005/067.pdf">being</a> <a href="https://security.googleblog.com/2017/02/announcing-first-sha1-collision.html">beaten</a>. It&#x2019;s because of this history that the U.S. government wrote FIPS 140: so government systems with sensitive data could protect that data with &#x201C;good&#x201D; cryptography. More and more, governmental organizations are requiring that systems comply with FIPS 140-2, motivating us to add Elasticsearch to the list of compliant systems.
</p><p>Good cryptography is desirable outside of the government too. Finance, healthcare, and legal companies, among others, want to protect their data...hopefully even when they&#x2019;re not required to by law. That&#x2019;s why this was done by NIST, since one of its roles is setting standards (like <a href="https://www.nist.gov/programs-projects/nist-mise-en-pratique-new-kilogram-definition">redefining the kilogram</a>) for public and private concerns.
</p><p>Adherence to FIPS 140-2 benefits everyone responsible for ensuring the confidentiality and integrity of very sensitive data, as well as those of us who entrust our sensitive data to others.
</p><h2>Elasticsearch and FIPS 140-2</h2><p>How does FIPS 140-2 apply to Elasticsearch? Elasticsearch is not, nor does it contain, a software or hardware cryptographic module. Consequently, it cannot be &quot;FIPS 140-2 Validated&quot; or &quot;FIPS 140-2 Approved&quot;. It can, however, be compliant with the FIPS 140-2 standard. What that means is that starting with version 6.4.0, Elasticsearch can be run in a Java Virtual Machine where cryptography is provided by a FIPS 140-2 approved or validated cryptographic module. Elasticsearch uses cryptography provided by the aforementioned validated cryptographic modules in various aspects, whether it&apos;s<a href="/guide/en/elasticsearch/reference/6.4/security-settings.html#hashing-settings"> salting and hashing your users&apos; passwords</a>,<a href="/guide/en/elasticsearch/reference/6.4/secure-settings.html"> securing your settings on disk</a> or<a href="/guide/en/elastic-stack-overview/6.4/encrypting-communications.html"> encrypting the communications between your browser and Elasticsearch and between your Elasticsearch nodes</a>.
</p><p>In order to satisfy the requirements of FIPS 140-2:
</p><ul>
	<li>Only FIPS Approved or NIST recommended cryptographic algorithms are used.	</li>
	<li>The implementation of these algorithms is not internal to Elasticsearch, but delegated to Java Cryptography Architecture (JCA) and/or Java Cryptography Extension (JCE) providers that, as software cryptographic modules, can be FIPS 140-2 validated and approved. </li>
</ul><h2>Running Elasticsearch in a FIPS 140-2 JVM</h2><p>FIPS 140-2 is complicated enough, so we&apos;ve made it very simple to configure Elasticsearch to support it. First, you need to enable &quot;fips_mode&quot; by setting <code>xpack.security.fips_mode.enabled</code> to true in elasticsearch.yml.
</p><pre class="prettyprint">xpack.security.fips_mode.enabled: true
</pre><p>Among other things, this will offer a warning if any of your configuration would result in compliance issues if, for instance, you select to use an encryption algorithm that is not FIPS Approved / NIST recommended.
</p><p>In previous releases, Elasticsearch only supported the bcrypt algorithm with configurable work factors for password hashing. While bcrypt is a highly adopted and well regarded choice, it&apos;s not FIPS 140-2 approved, and as such, cannot be used in a FIPS 140-2 JVM. To overcome this hurdle, and be as future proof as possible, the PBKDF2 key derivation function with a configurable computational cost (up to 1000000 HMAC-SHA512 iterations) is available for use. bcrypt remains the default option, but can be changed via the <code>xpack.security.authc.password_hashing.algorithm</code> configuration option to something FIPS 140-2 compliant, such as pbkdf2_10000.
</p><pre class="prettyprint">xpack.security.authc.password_hashing.algorithm: pbkdf2_10000
</pre><p>See&#xA0;<a href="/guide/en/elasticsearch/reference/6.4/security-settings.html#hashing-settings">the Elasticsearch hash algorithm documentation</a> for all available values.
</p><p>The default TLS configuration of Elasticsearch is compliant with FIPS 140-2, as only TLSv1.2, TLSv1.1 and TLSv1 are<a href="/guide/en/elasticsearch/reference/6.4/security-settings.html#ssl-tls-settings"> supported</a> and all the enabled cipher suites can be used in a FIPS 140-2 JVM.
</p><h2>A Parting Note</h2><p>We know that FIPS 140-2 support isn&#x2019;t something everyone needs, but it&#x2019;s one of the ways Elastic is showing its dedication to building security into the product. We plan to continue to expand our support for FIPS 140-2 across additional Elastic products. If you need more information about FIPS 140-2, other federal compliance standards, or want to contact us, please see our website for <a href="/federal/compliance">US Government Certifications and Accreditations</a>.
</p></body></html>

fips_banner.jpg

fips_thumb.jpg

Configuring Elasticsearch in a FIPS 140-2 Environment

<h2>So what exactly is SAML and why are we excited?</h2><h3>Introduction</h3><p>This post aims to offer a proper introduction to SAML Authentication and give an overview of how the Elastic Stack is using SAML to enable you to secure your clusters and users. For complete and detailed instructions on how to configure your cluster for SAML Authentication, consult our <a href="/guide/en/cloud/current/ec-securing-clusters-SAML.html">Elastic Cloud</a>, <a href="/guide/en/cloud-enterprise/2.0/ece-securing-clusters-SAML.html">Elastic Cloud Enterprise</a> and <a href="/guide/en/elastic-stack-overview/6.5/saml-guide.html">Elasticsearch</a> SAML Configuration guides.
</p><h3>SAML demystified</h3><p>SAML, which stands for <em>Security Assertion Markup Language</em>, is an is an XML-based standard from OASIS that deals with exchanging authentication and authorization data between parties. It consists of a number of profiles describing different use cases for the standard, but the one that is most prominently used is SAML 2.0 Web Browser Single Sign On (SSO)&nbsp;Profile which describes cross (security) domain web SSO.
</p><p>There are three actors involved in a SAML authentication flow. The SAML Identity Provider (IdP) is a SAML authority that bears the burden of authenticating users against an identity repository and retrieving information about these users from the same or other identity repositories. It consequently passes on this information to a SAML Service Provider using SAML messages. A SAML Service Provider (SP) is most commonly a component of, or a middleware in a web application. It triggers the authentication request to a SAML Identity Provider and, after successful user authentication, consumes the SAML message that the Identity Provider sent in order to retrieve details about the authentication event and the authenticated user themselves. It finally uses this information in order to create a session in the context of the web application in which it is being used.
</p><p>The last of the three actors, is the user agent, the browser that the user utilizes in order to access the application, and thus, the Service Provider and the Identity Provider. All communication in SAML 2.0 Web Browser SSO Profile is front-channel communication and is handled explicitly by the browser. The Identity Provider doesn’t need to be able to communicate directly with the Service Provider in any way.
</p><p>The interactions between these three main actors in a SAML 2.0 Web Browser SSO authentication flow, are illustrated in the following diagram. The legend below describes the steps involved in more detail and offers further insights to the process.
</p><p><img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/blt88a9e8d6527678dc/5c58447c122247d10be8ed1d/blog-saml.png" data-sys-asset-uid="blt88a9e8d6527678dc" alt="blog-saml.png">
</p><ol>
	<li>
	The authentication flow usually starts with the user clicking on a login button or accessing a part of the web application that is secured. Since the web application is configured for authentication with SAML, it creates a SAML message known as a SAML Authentication Request. As the name conveys, this message is a request to an Identity Provider to authenticate this user. 
	</li>
	<li>
	The Authentication Request message is compressed and Base64 encoded and the user’s browser is redirected to the Identity Provider with that message as an HTTP GET parameter. 
	</li>
	<li>
	Upon receiving the Authentication Request, the Identity Provider verifies that it comes from a Service Provider it trusts, and prompts the user to authenticate, most commonly using a login form. 
	</li>
	<li>
	The user authenticates with the Identity Provider using their existing credentials and if successful, the Identity Provider proceeds to create a SAML Response message that contains a SAML Assertion. In essence, by constructing the SAML Assertion, the Identity Provider asserts that this user has authenticated successfully and they are known to have certain characteristics that are released in the form of SAML Attributes and their values. 
	</li>
	<li>
	The Identity Provider, then, instructs the user’s browser to make an HTTP POST request to the URL where the Service Provider expects SAML Response messages, called the Assertion Consumer Service URL, with the SAML Response Base64 and URL encoded in the body of the request. 
	</li>
	<li>
	Finally, the Service Provider receives the SAML Response to the SAML Authentication Request it had originally created and after verifying its authenticity and integrity, “consumes” it in order to retrieve the fact that the user has been successfully authenticated and the information about that user’s identity in the form of attributes. It then passes this information to the web application for it to create a session for the user.
	</li>
</ol><p>A couple of questions could be on your mind by now: “How does the Identity Provider verify that the Authentication Request comes from a Service Provider it trusts?” or “How can the Service Provider verify the authenticity and integrity of the SAML responses it receives from the Identity Provider?”
</p><p>Well, before any messages can be exchanged between an Identity Provider and a Service Provider, one needs to know the configuration details and capabilities of the other. This configuration and the capabilities are encoded in an XML document, that is the SAML Metadata of the SAML entity. The metadata document contains a lot of information, but the most important parts are:
</p><ul>
	<li>
	A unique ID of the SAML entity, called <em>EntityID</em>
	</li>
	<li>
	A public key that other SAML entities can use in order to encrypt messages sent to this Entity
	</li>
	<li>
	A public key that corresponds to the private key that this entity uses to digitally sign messages sent to other entities.
	</li>
	<li>
	URLs to which other entities can send SAML messages and the bindings (connection details and protocol specifics) it supports.
	</li>
	<li>
	Information about the Organization operating this entity and the technical and support contact details.
	</li>
</ul><p>Once the entities have mutually exchanged metadata in a secure manner, XML Digital Signatures, XML encryption and public key cryptography are used in order to safeguard the integrity, authenticity and the confidentiality of the SAML messages. For instance, an Identity Provider uses the private key that corresponds to the public key it has published in its metadata, in order to digitally sign the SAML Response it sends to a Service Provider. The Service Provider can then use that public key in the published metadata in order to verify the signature and thus the authenticity and the integrity of the response.
</p><h3>Why use SAML? </h3><p>Apart from being one of the most requested features, why are we <em>excited</em> to offer you support for SAML Authentication? Or even better, why is this one of the most requested features? SSO solutions offer a range of benefits both for the organizations and their users. From the perspective of organizations, it helps with minimizing risk and assists compliance efforts as user credentials and user information needs to be stored and maintained in only one place. It is thus easier for the organization to protect and secure this user data, as well as to grant requests for data portability and requests to erase data in the context of GDPR . Furthemore, it enhances the user experience as the users need to enter their credentials and enter their details less often. It also helps to reduce password fatigue - the fewer password a user needs to remember, the better the chances are that they will use longer, more complex ones. SAML has been widely deployed and tested in many industries, and remains one of the most popular standards for implementing Web SSO solutions.
</p><h2>OK, I’m sold. Show me how this works with the Elastic Stack!</h2><h3>SAML and the Elastic Stack</h3><p>In terms of SAML 2.0 nomenclature, the Elastic Stack as a whole is a SAML 2.0 compliant Service Provider, that implements the Web Browser SSO and Single Logout profiles. The two major components of the Elastic Stack that contribute to the SAML related functionality are Kibana and Elasticsearch. Kibana, as the user facing component, interacts with the user’s browser and receives all the SAML messages that the Identity Provider sends to the Elastic Stack Service Provider. Elasticsearch implements most of the functionality a SAML Service Provider needs. It holds all SAML related configuration in the form of an authentication realm and it also generates all SAML messages required and passes them to Kibana to be relayed to the user’s browser. It finally consumes all SAML Responses that Kibana relays to it, verifies them, extracts the necessary authentication information and creates the internal authentication tokens based on that.
</p><h3>Configuring SAML in 9 lines of configuration</h3><p>SAML 2.0 offers a lot of options for the implementers of the standard, and as such, our configuration has a <a href="/guide/en/elastic-stack-overview/6.5/saml-realm.html">decent number</a> of options that can be set and knobs that can adjusted. Having said that, significant effort has been put into offering a <a href="/guide/en/elastic-stack-overview/6.5/saml-guide.html">comprehensive guide</a> on how to set up Elastic Stack for SAML, and into setting as many sane defaults as possible so that the minimum configuration needed for enabling SAML is, well, minimal.
</p><p>The following configuration example represents a minimal functional configuration, but depending on the SAML Identity Provider used and its configuration, as well as your security requirements, you might want to read through our SAML Guide and configure things such as <a href="/guide/en/elastic-stack-overview/6.5/saml-guide-authentication.html#saml-attribute-mapping">group attribute mappings</a> and <a href="/guide/en/elastic-stack-overview/6.5/saml-role-mapping.html">role mappings for authorization</a>.<br>
</p><p>Assuming that your Identity Provider is up and running, there are only two prerequisites: <a href="/guide/en/elastic-stack-overview/6.5/ssl-tls.html">TLS</a> for the http layer and the <a href="/guide/en/elasticsearch/reference/6.5/security-settings.html#token-service-settings">Token Service</a> needs to be enabled in Elasticsearch.
</p><p>With that out of the way, SAML can be configured with the following 9 lines in your <code>elasticsearch.yml</code> file
</p><pre class="prettyprint">xpack.security.authc.realms.saml1:
   type: saml
   order: 0
   idp.metadata.path: saml/idp-external.xml
   idp.entity_id: "https://idp.myorg.com/"
   sp.entity_id:  "https://kibana.myorg.com/"
   sp.acs: "https://kibana.myorg.com/api/security/v1/saml"
   sp.logout: "https://kibana.myorg.com/logout"
   attributes.principal: "nameid:persistent"
</pre><p>This configuration creates a SAML authentication realm with name <code>saml1</code> with the following configuration properties
</p><ul>
	<li>
	<code>idp.metadata.path</code> &nbsp;is the the file path or the https URL where your Identity Provider metadata is available. 
	</li>
	<li>
	<code>idp.entity_id</code> is the SAML EntityID of your Identity Provider. This can be read from the configuration page of the Identity Provider, or its SAML metadata.
	</li>
	<li>
	<code>sp.entity_id</code> is the SAML EntityID of our Service Provider. This can be any URI but it’s good practice to set it to the URL where Kibana is accepting connections. 
	</li>
	<li>
	<code>sp.acs</code> is the Assertion Consumer Service URL where Kibana is listening for incoming SAML messages. This should be the <code>/api/security/v1/saml</code> endpoint of your Kibana server.
	</li>
	<li>
	<code>sp.logout</code> is the SingleLogout endpoint where the Service Provider is listening for incoming SAML LogoutResponse and LogoutRequest messages. This should be the <code>/logout</code> endpoint of your Kibana server.
	</li>
	<li>
	<code>attributes.principal</code> defines which SAML attribute is going to be mapped to the principal (username) of the authenticated user in Kibana, in this case we use the special <code>nameid:persistent</code> which will map the NameID with <code>urn:oasis:names:tc:SAML:2.0:nameid-format:persistent</code> format from the Subject of the SAML Assertion.
	</li>
</ul><p>If your Identity Provider can consume SAML metadata, then it can be easily created with the provided <a href="/guide/en/elasticsearch/reference/6.5/saml-metadata.html">saml-metadata</a> tool that is provided with X-Pack. Otherwise, the only pieces of configuration that your IdP would require are the Service Provider EntityID and the Assertion Consumer Service URL.
</p><p>Configuring Kibana is even simpler, as only two settings need to be set:
</p><pre class="prettyprint">xpack.security.authProviders: [saml]
server.xsrf.whitelist: [/api/security/v1/saml]
</pre><code>basic</code> can be added in the list of <code>authProviders</code> if we want to allow users to also login via the native realm, which might come in handy for administrative access and as a fallback authentication mechanism, in case the Identity Provider is unresponsive. Cross site request forgery protection needs to be disabled for the Assertion Consumer Service URL since the SAML response will come as a valid and legitimate cross site request ! Not to worry though, Elasticsearch will validate the request content before consuming it.<p>That’s it! Restarting Elasticsearch and Kibana, SAML authentication will be enabled and navigating to Kibana will start the authentication flow we described above. Who said SAML was difficult?
</p><p><img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/blt9b1fdcf18bad9b6e/5c30742161a626fb0b63018e/SAML-demo.gif" data-sys-asset-uid="blt9b1fdcf18bad9b6e" alt="SAML-demo.gif">
</p><p><br>
</p><p><a href="/start">Try it out with the latest version of the Elastic Stack</a>.
</p>

SAML Authentication and the Elastic Stack

Start free trial

Blog Footer CTA

Sign up for Elastic Cloud free trial

Ioannis Kakavas

<p>Надсилаючи цю форму ви погоджуєтеся з <a href="/legal/terms-of-use">Умовами надання послуг Elastic</a>. Ваші особисті дані будуть опрацьовані відповідно з <a href="/legal/privacy-statement">Положеннями про конфіденційність Elastic</a>.</p>

Newsletter GDPR Text - Ukrainian

<p>By submitting you acknowledge that you've read and agree to our <a href="/legal/elastic-cloud-account-terms" target="_self">Terms of Service</a>, and you agree to receive the <a href="/legal/privacy-statement#how-we-use-the-information" target="_self">selected communications</a> at the contact details you provided above. See <a href="/legal/privacy-statement/" target="_self">Elastic’s Privacy Statement</a> for more details or to opt-out at any time.</p>

Communication Preferences - ONLY for /communication-preferences

<p>By submitting you agree to <a href="/agreements/global/cloud-services-monthly" rel="nofollow">Elastic Cloud Terms of Service</a>. Your personal data will be processed in accordance with <a href="/legal/privacy-statement">Elastic's Privacy Statement</a>.</p>

Cloud Trial GDPR Text

Intentionally Blank

<p>By submitting you acknowledge that you've read and agree to our <a href="/legal/serverless-preview-terms" target="_blank">Terms of Service</a>, and that Elastic may <a href="/legal/privacy-statement#how-we-use-the-information" target="_blank">contact you</a> about our related products and services, using the details you provide above. See <a href="/legal/privacy-statement/" target="_blank">Elastic’s Privacy Statement</a> for more details or to opt-out at any time.</p>

Serverless GDPR Text

<p>提交即表示您確認已詳閱並同意我們的<a href="/legal/elastic-cloud-account-terms" target="_blank">服務條款</a>，且同意 Elastic 使用您在上方提供的個人資料<a href="/legal/privacy-statement#how-we-use-the-information" target="_blank">與您聯絡</a>，為您提供相關產品和服務的資訊。如需詳細說明或隨時想停止收到產品和服務資訊，請參閱 <a href="/legal/privacy-statement/" target="_blank">Elastic 的隱私聲明</a>。</p>

Newsletter GDPR Text - TW

<p>By submitting you acknowledge that you've read and agree to our <a href="/legal/elastic-cloud-account-terms" target="_blank">Terms of Service</a>, and that Elastic may <a href="/legal/privacy-statement#how-we-use-the-information" target="_blank">contact you</a> about our related products and services, using the details you provide above. See <a href="/legal/privacy-statement/" target="_blank">Elastic’s Privacy Statement</a> for more details or to opt-out at any time.</p><p>By submitting this form, I agree to Elastic sharing my contact information with Google Cloud. I also agree to Elastic giving my information to the vendor for the purpose of shipping my food package.</p>

GDPR Text + Google Cloud

<p>Inviando la registrazione (1) esprimi il consenso ai <a href="/legal/terms-of-use">termini e condizioni di Elastic</a> e <a href="/legal/privacy-statement">all’informativa sulla privacy</a>, nonché (2) a ricevere saltuarie e-mail.</p>

Newsletter GDPR Text - Italian

<p>By submitting you acknowledge that you've read and agree to our <a href="/legal/terms-of-use" target="_blank">Terms of Service</a>, and that Elastic may <a href="/legal/privacy-statement#how-we-use-the-information" target="_blank">contact you</a> about our related products and services, using the details you provide above. See <a href="/legal/privacy-statement/" target="_blank">Elastic’s Privacy Statement</a> for more details or to opt-out at any time.</p>

Newsletter GDPR Text

Load more

Overview

Can't make it? Register and we'll send you the recording. You'll also receive an email with related content

Can't make it? Register and we'll send you the recording. You'll also receive an email with related content.

You'll also receive an email with related content.

You'll also receive an email with related content

Speakers

Close

See more insights

The content on this page is not available in the selected language. As Elastic grows globally, we continue to support content in multiple languages.

Author

Articles by Ioannis Kakavas

Configuring Elasticsearch in a FIPS 140-2 Environment

SAML Authentication and the Elastic Stack

Follow us

About us

Join us

Partners

Trust & Security

Investor relations

Excellence Awards