|
| 1 | +[role="xpack"] |
| 2 | +[[idp-saml-init]] |
| 3 | +=== Generate a SAML authentication response message |
| 4 | +++++ |
| 5 | +<titleabbrev>Generate SAML response</titleabbrev> |
| 6 | +++++ |
| 7 | +Generates a SAML Response message to be sent to a Service Provider |
| 8 | + |
| 9 | +[[idp-saml-init-request]] |
| 10 | +==== {api-request-title} |
| 11 | + |
| 12 | +`POST /_idp/saml/init` |
| 13 | + |
| 14 | +[[idp-saml-init-prereqs]] |
| 15 | +==== {api-prereq-title} |
| 16 | + |
| 17 | +* To use this API, you must have a role that grants the `cluster:admin/idp/saml/init` privilege. |
| 18 | + |
| 19 | +[[idp-saml-init-desc]] |
| 20 | +==== {api-description-title} |
| 21 | + |
| 22 | +This API generates a SAML Response message that should be sent to a Service Provider as part of an |
| 23 | +IDP initiated or SP initiated SAML Single Sign On. This API expects the caller to present |
| 24 | +credentials for the user that the SAML Response will be created for as "Secondary Authentication" |
| 25 | +using the `es-secondary-authorization` HTTP Request header. |
| 26 | + |
| 27 | +The SAML response is returned as a String that contains an XML document. The caller of the API is responsible to instruct |
| 28 | +the end user's browser to make an HTTP Post request to the Service Provider with the SAML response |
| 29 | +Base64 encoded. |
| 30 | + |
| 31 | +[[idp-saml-init-body]] |
| 32 | +==== {api-request-body-title} |
| 33 | + |
| 34 | +The following parameters can be specified in the body of a POST request: |
| 35 | + |
| 36 | +`entity_id`:: |
| 37 | +(Required, string) The SAML entity Id of the service provider that will be the recipient of the SAML Response. |
| 38 | + |
| 39 | +`acs`:: |
| 40 | +(Required, string) The assertion consumer service URL of the service provider that will be the recipient of the SAML Response. |
| 41 | + |
| 42 | +`authn_state`:: |
| 43 | +(Optional, object) The JSON structure that <<idp-saml-validate>> returns. This should only be |
| 44 | +provided when calling this API as part of an SP initiated Single Sign On. |
| 45 | + |
| 46 | + |
| 47 | +[[idp-saml-init-example]] |
| 48 | +==== {api-examples-title} |
| 49 | + |
| 50 | +The following example generates a SAML Response for an IDP initiated SAML Single Sign On to the Service Provider with entity Id |
| 51 | +`https://sp1.kibana.org` and an assertion consumer service URL that is `https://sp1.kibana.org/saml/acs` |
| 52 | + |
| 53 | +[source, sh] |
| 54 | +-------------------------------------------------------------------- |
| 55 | +curl -u idp_admin:idp_admin_pwd <1> \ |
| 56 | + -H 'Content-Type: application/json' \ |
| 57 | +-H 'es-secondary-authorization: ApiKey dVhmUDBuQUJERWhZWEZaQVg5S0k6WUJubmZwNEtRZ1d4cGRxdXBzZmFDUQ==' <2> \ |
| 58 | +localhost:9200/_idp/saml/init -d '{"entity_id":"https://sp1.kibana.org","acs":"https://sp1.kibana.org/saml/acs"}' |
| 59 | +-------------------------------------------------------------------- |
| 60 | +// NOTCONSOLE |
| 61 | +<1> The credentials of the user that has the necessary privileges to call this API |
| 62 | +<2> The credentials of the end user for which the SAML Response will be generated. These can be in the form of a Basic authentication |
| 63 | +header, an {es} access token, or an API key. |
| 64 | + |
| 65 | + |
| 66 | +The following example generates a SAML Response for an SP initiated SAML Single Sign On to the Service Provider with entity Id |
| 67 | +`https://sp1.kibana.org` that would have originally sent an authentication request and which has been validated with the |
| 68 | +use of <<idp-saml-validate>> |
| 69 | + |
| 70 | +[source, sh] |
| 71 | +-------------------------------------------------------------------- |
| 72 | +curl -u idp_admin:idp_admin_pwd <1> -H 'Content-Type: application/json' \ |
| 73 | +-H 'es-secondary-authorization: ApiKey dVhmUDBuQUJERWhZWEZaQVg5S0k6WUJubmZwNEtRZ1d4cGRxdXBzZmFDUQ==' <2>\ |
| 74 | +localhost:9200/_idp/saml/init -d '{"entity_id":"https://sp1.kibana.org","acs":"https://sp1.kibana.org/saml/acs", |
| 75 | +"authn_state":{"authn_request_id":"_3243243243fdwfsd34r2f32f23","nameid_format":"urn:oasis:names:tc:SAML:2.0:nameid-format:transient"}<3>}' |
| 76 | +-------------------------------------------------------------------- |
| 77 | +// NOTCONSOLE |
| 78 | +<1> The credentials of the user that has the necessary privileges to call this API |
| 79 | +<2> The credentials of the end user for which the SAML Response will be generated. These can be in the form of a Basic authentication |
| 80 | +header, an elasticsearch access token, or an API key. |
| 81 | +<3> The `authn_state` JSON structure as it was returned by <<idp-saml-validate>> |
| 82 | + |
| 83 | + |
| 84 | +A successful call returns the SAML Response as an XML String, the URL to post this SAML Response to, and information about the Service |
| 85 | +Provider that should receive this SAML Response. |
| 86 | + |
| 87 | +[source, console-result] |
| 88 | +-------------------------------------------------------------------- |
| 89 | +{ |
| 90 | + "post_url" : "https://sp1.kibana.org/saml/acs", |
| 91 | + "saml_response" : "<?xml version="1.0" encoding="UTF-8"?><saml2p:Response xmlns:saml2p="urn:oasis:names:tc:SAML:2.0:protocol" xmlns:xsd="http://www.w3.org/2001/XMLSchema" Destination="https://sp.some.org/api/security/v1/saml" ID="_845fbfc9f3254162ce1e161c91b07d85311d65cd" IssueInstant="2020-03-19T15:45:00.158Z" ...removed for brevity ... </saml2p:Response>", |
| 92 | + "saml_status" : "urn:oasis:names:tc:SAML:2.0:status:Success", |
| 93 | + "error" : null, |
| 94 | + "service_provider" : { |
| 95 | + "entity_id" : "https://sp1.kibana.org" |
| 96 | + } |
| 97 | +} |
| 98 | +-------------------------------------------------------------------- |
| 99 | +// TESTRESPONSE[skip:Do not enable identity provider for the docs cluster, at least not yet] |
| 100 | + |
| 101 | +A failed call, in the case of an SP initiated SSO returns a SAML Response as an XML String with its status set to the appropriate error |
| 102 | +code indicating that the authentication request failed and the reason for that failure. A `saml_status` of |
| 103 | +`urn:oasis:names:tc:SAML:2.0:status:Requester` indicates that the error is on the side of the SP or the user, while a `saml_status` of |
| 104 | +`urn:oasis:names:tc:SAML:2.0:status:Responder` indicates that something went wrong in the IDP side. The `error` field contains a short |
| 105 | +human friendly interpretation of the error that is outside the SAML standard and is meant to be communicated to the user, especially |
| 106 | +if the user is not redirected back the SP with the `saml_response` |
| 107 | + |
| 108 | +[source, console-result] |
| 109 | +-------------------------------------------------------------------- |
| 110 | +{ |
| 111 | + "post_url" : "https://sp1.kibana.org/saml/acs", |
| 112 | + "saml_response" : "?xml version="1.0" encoding="UTF-8"?><saml2p:Response xmlns:saml2p="urn:oasis:names:tc:SAML:2.0:protocol" xmlns:xsd="http://www.w3.org/2001/XMLSchema" Destination="https://sp1.kibana.org/api/saml/acs" ID="_845fbfc9f3254162ce1e161c91b07d85311d65cd" IssueInstant="2020-03-19T15:45:00.158Z" Version="2.0"><saml2:Issuer xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion">https://idp.cloud.elastic.co</saml2:Issuer><ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">...removed for brevity...</ds:Signature><saml2p:Status><saml2p:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Requester"><samlp:StatusCode xmlns:saml2p="urn:oasis:names:tc:SAML:2.0:protocol" Value="urn:oasis:names:tc:SAML:2.0:status:InvalidNameIDPolicy"/></saml2p:StatusCode></saml2p:Status></saml2p:Response>", |
| 113 | + "saml_status" : "urn:oasis:names:tc:SAML:2.0:status:Requester", |
| 114 | + "error" : "User [user1] is not permitted to access service [https://sp1.kibana.org]", |
| 115 | + "service_provider" : { |
| 116 | + "entity_id" : "https://sp1.kibana.org" |
| 117 | + } |
| 118 | +} |
| 119 | +-------------------------------------------------------------------- |
| 120 | +// TESTRESPONSE[skip:Do not enable identity provider for the docs cluster, at least not yet] |
| 121 | + |
| 122 | +A failed call, in the case of an IDP initiated SSO returns an error with the appropriate HTTP Status code. i.e. if the value of the |
| 123 | +`es-secondary-authorization` is wrong, the IDP will respond with `403` |
0 commit comments