Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Rest spec and documentation #54664

Merged
merged 8 commits into from
Apr 16, 2020
Merged

Conversation

jkakavas
Copy link
Member

@jkakavas jkakavas commented Apr 2, 2020

This change adds the spec for the new REST APIs that we
introduce for the IDP and documentation for each of the APIs. The
documentation pages are intentionally not included in the API
reference so as to minimize unnecessary exposure.

supersedes: #53858

This change adds the spec for the new REST APIs that we
introduce for the IDP and documentation for each of the APIs. The
documentation pages are intentionally not included in the API
reference so as to minimize unnecessary exposure.

supersedes: elastic#53858
@jkakavas jkakavas added >docs General docs changes :Security/Security Security issues without another label labels Apr 2, 2020
@jkakavas jkakavas requested review from lloydmeta and tvernum April 2, 2020 16:28
@elasticmachine
Copy link
Collaborator

Pinging @elastic/es-security (:Security/Security)

@elasticmachine
Copy link
Collaborator

Pinging @elastic/es-docs (>docs)

@jkakavas
Copy link
Member Author

jkakavas commented Apr 3, 2020

@elasticmachine test this please

This API generates a SAML Response message that should be sent to a Service Provider as part of an
IDP initiated or SP initiated SAML Single Sign On. This API expects the caller to present
credentials for the user that the SAML Response will be created for as "Secondary Authentication"
using the `es-secondary-authorization` HTTP Request header.
Copy link
Contributor

@tvernum tvernum Apr 8, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

FYI, @lcawl is working on some generic docs for secondary authentication, which we can link to when they're ready.

(Required, string) A name to identify this service provider. Used only for informational purposes

`entity_id`::
(Required, string) The SAML entity Id of the service provider.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This isn't required.
If it is not set, it will be populated from the URL parameter.
If it is set, it must match the URL parameter.

if (document.entityId == null) {
document.setEntityId(entityId);
} else if (entityId != null) {
if (entityId.equals(document.entityId) == false) {
throw new ElasticsearchParseException(
"Entity id [{}] inside request body and entity id [{}] from parameter do not match", document.entityId, entityId);
}
}

@jkakavas jkakavas requested a review from tvernum April 8, 2020 13:06
@jkakavas
Copy link
Member Author

ping @tvernum

@Mpdreamz
Copy link
Member

cc @elastic/es-clients heads up, new API's incoming 😄

@jkakavas
Copy link
Member Author

jkakavas commented Apr 15, 2020

@Mpdreamz / @elastic/es-clients this is intentionally kept separate from the rest spec as we don't want our clients to support this cloud internal functionality.

@Mpdreamz
Copy link
Member

Cool, the need private API;s for this has been discussed previously: #38413 (comment) but voted against.

I do think we need a private: true marker in the future but will chase this outside of this PR and circle back to this.

@@ -46,7 +46,8 @@ The following parameters can be specified in the body of a POST or PUT request:
(Required, string) A name to identify this service provider. Used only for informational purposes

`entity_id`::
(Required, string) The SAML entity Id of the service provider.
(Optional, string) The SAML entity Id of the service provider. If not set, it will be populated with the value from the URL parameter.
If set, it musth match the value that is passed in the URL parameter.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
If set, it musth match the value that is passed in the URL parameter.
If set, it must match the value that is passed in the URL parameter.

@@ -19,6 +19,9 @@
}
}
]
},
"params": {
"acs": { ... }
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

My use of ... was just a placeholder - I think this should be populated with something meaningful.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Meh , I did a two step process of 1) all the suggestions make sense and later 2) lets merge these and forgot to take care of this . Will adjust

Copy link
Contributor

@russcam russcam left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggestion to mark the stability of the specs as private. This signals to the language clients that these are internal APIs and not to be exposed. Current stability values supported are:

"enum": ["stable", "beta", "experimental", "private"]

EDIT

Removed the suggestions. Appears "private" is now not a stability value in specs

@Mpdreamz
Copy link
Member

@russcam there is no private option:
https://github.com/elastic/elasticsearch/blob/master/test/framework/src/main/java/org/elasticsearch/test/rest/yaml/restspec/ClientYamlSuiteRestApi.java#L47

See also previous discussion: #38413 (comment)

As mentioned in my comment will discuss and fix this outside this PR then circle back to it. We'll need to update the json schema in the meantime.

@russcam
Copy link
Contributor

russcam commented Apr 16, 2020

Ok @Mpdreamz. I would like to be involved in this discussion when it happens

@codebrain
Copy link
Contributor

codebrain commented Apr 16, 2020

I think an is_private: true flag is more favourable to introducing the private "stability" option, on the basis that a developer can still use the experimental > beta > stable pathway and keep the is_private flag intact.

@jkakavas
Copy link
Member Author

Can I kindly ask that we continue the flag related discussion in another medium/thread/issue so that it won't get lost in the comments of this PR ?

@jkakavas
Copy link
Member Author

@elasticmachine update branch

@jkakavas jkakavas requested a review from tvernum April 16, 2020 11:08
Copy link
Contributor

@tvernum tvernum left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@jkakavas jkakavas merged commit dfb3355 into elastic:master Apr 16, 2020
jkakavas added a commit to jkakavas/elasticsearch that referenced this pull request Apr 16, 2020
This change adds the spec for the new REST APIs that we
introduce for the IDP and documentation for each of the APIs. The
documentation pages are intentionally not included in the API
reference so as to minimize unnecessary exposure.

supersedes: elastic#53858
jkakavas added a commit to jkakavas/elasticsearch that referenced this pull request Apr 16, 2020
This change adds the spec for the new REST APIs that we
introduce for the IDP and documentation for each of the APIs. The
documentation pages are intentionally not included in the API
reference so as to minimize unnecessary exposure.

supersedes: elastic#53858
jkakavas added a commit that referenced this pull request Apr 16, 2020
This change adds the spec for the new REST APIs that we
introduce for the IDP and documentation for each of the APIs. The
documentation pages are intentionally not included in the API
reference so as to minimize unnecessary exposure.

supersedes: #53858
jkakavas added a commit that referenced this pull request Apr 16, 2020
This change adds the spec for the new REST APIs that we
introduce for the IDP and documentation for each of the APIs. The
documentation pages are intentionally not included in the API
reference so as to minimize unnecessary exposure.

supersedes: #53858
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
>docs General docs changes :Security/Security Security issues without another label
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants