[
https://issues.apache.org/jira/browse/AMBARI-23253?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Levas updated AMBARI-23253:
----------------------------------
Description:
Today enabling SSO requires visiting each component that supports SSO and
adding configuration entries to each. This task is to enable a single entry
point via the Ambari CLI to configure SSO for each service that supports it.
Changes to the ambari-server setup-sso CLI are needed allow configuration of
all SSO-capable services using that single CLI. This facility can be used to
enable, disable, and reconfigure SSO integration.
*Proposed implementation:*
Services are to declare they support SSO integration by indicating in the
service's \{{metainfo.xml}} file as follows:
{code}
<sso>
<supported>true</supported>
<enabledConfiguration>config-type/sso.enabled.property</enabledConfiguration>
</sso>
{code}
The stack/service advisor will be used to retrieve the recommended
configurations needed by a service to set up SSO integration. A special stack
advisor action will be added to ensure only SSO-related recommendations are
returned upon request. The new action name is
"{{recommend-configurations-for-sso}}". Ambari (or common) SSO information will
be provided to the stack advisor via the input data under the label
"sso-configuration". This information may be used by the stack advisor when
creating recommendations.
Ambari will store details on which services should be enabled for SSO so it
_knows_ how to behave when SSO integration is enabled and new services are
added. This data will be stored within Ambari's configuration data under the
category of {{sso-configuration}}. The list of services to have SSO integration
turned on will be stored in the property named {{ambari.sso.enabled_services}}.
The value will be a comma-delimited list of service names, or "{{*}}" to
indicate all services that support SSO integration.
The Ambari REST API entry point for installed services
({{/api/v1/clusters/:CLUSTER_NAME/services/:SERVICE_NAME}}) is to be enhance by
adding the following properties:
* *\{{sso_integration_supported}}* - Indicates whether the service supports SSO
integration or not
* *\{{sso_integration_enabled}}* - Indicates whether the service is configured
for SSO integration or not
* *\{{sso_integration_desired}}* - Indicates whether the service is chosen for
SSO integration or not
The Ambari REST API entry point for stack services
({{/api/v1/stacks/:STACK_NAME/versions/:VERSION/services/:SERVICE_NAME}}) is to
be enhance by adding the following properties:
* *\{{sso_integration_supported}}* - Indicates whether the service supports SSO
integration or not
When producing a list of installed services that support SSO integration in the
CLI, the Ambari REST API is to be used to query for the relevant service names.
Once the user selects the set of services to enable SSO for (or all), the
Ambari REST API is to be used to set the value of the Ambari configuration
\{{sso-configuration/sso_enabled_services}}. Upon setting this, logic is
triggered in the backend to query the stack advisor for SSO-related
configuration recommendations which will be automatically applied. This will
potentially yield new configuration versions and require services to be
manually restarted.
When adding new services, the
\{{sso-configuration/ambari.sso.enabled_services}} value is to be checked to
see if the new service is on the list of services to have SSO integration
enabled. If so, and the service has a SSO descriptor, its configuration will be
updated as needed before the service is started.
In a Blueprint scenario, it is expected that the user first sets up Ambari for
SSO integration using the {{ambari-server setup-sso}} CLI. The Blueprint is
expected to set the relevant properties needed to enable SSO integration per
service. However, if SSO details were set up, the stack advisor may recommend
relevant changes which may be applied depending on the Blueprint settings.
was:
Today enabling SSO requires visiting each component that supports SSO and
adding configuration entries to each. This task is to enable a single entry
point via the Ambari CLI to configure SSO for each service that supports it.
Changes to the ambari-server setup-sso CLI are needed allow configuration of
all SSO-capable services using that single CLI. This facility can be used to
enable, disable, and reconfigure SSO integration.
*Proposed implementation:*
Services are to declare they support SSO integration by indicating in the
service's \{{metainfo.xml}} file as follows:
{code}
<sso>
<supported>true</supported>
<enabledConfiguration>config-type/sso.enabled.property</enabledConfiguration>
</sso>
{code}
The stack/service advisor will be used to retrieve the recommended
configurations needed by a service to set up SSO integration. A special stack
advisor action will be added to ensure only SSO-related recommendations are
returned upon request. The new action name is
"\{{recommend-configurations-for-sso}}". Ambari (or common) SSO information
will be provided to the stack advisor via the input data under the label
"sso-configuration". This information may be used by the stack advisor when
creating recommendations.
Ambari will store details on which services should be enabled for SSO so it
_knows_ how to behave when SSO integration is enabled and new services are
added. This data will be stored within Ambari's configuration data under the
category of \{{sso-configuration}}. The list of services to have SSO
integration turned on will be stored in the property named
\{{sso_enabled_services}}. The value will be a comma-delimited list of service
names, or "\{{*}}" to indicate all services that support SSO integration.
The Ambari REST API entry point for installed services
(\{{/api/v1/clusters/:CLUSTER_NAME/services/:SERVICE_NAME}}) is to be enhance
by adding the following properties:
* *\{{sso_integration_supported}}* - Indicates whether the service supports SSO
integration or not
* *\{{sso_integration_enabled}}* - Indicates whether the service is configured
for SSO integration or not
* *\{{sso_integration_desired}}* - Indicates whether the service is chosen for
SSO integration or not
The Ambari REST API entry point for stack services
(\{{/api/v1/stacks/:STACK_NAME/versions/:VERSION/services/:SERVICE_NAME}}) is
to be enhance by adding the following properties:
* *\{{sso_integration_supported}}* - Indicates whether the service supports SSO
integration or not
When producing a list of installed services that support SSO integration in the
CLI, the Ambari REST API is to be used to query for the relevant service names.
Once the user selects the set of services to enable SSO for (or all), the
Ambari REST API is to be used to set the value of the Ambari configuration
\{{sso-configuration/sso_enabled_services}}. Upon setting this, logic is
triggered in the backend to query the stack advisor for SSO-related
configuration recommendations which will be automatically applied. This will
potentially yield new configuration versions and require services to be
manually restarted.
When adding new services, the \{{sso-configuration/sso_enabled_services}} value
is to be checked to see if the new service is on the list of services to have
SSO integration enabled. If so, and the service has a SSO descriptor, its
configuration will be updated as needed before the service is started.
In a Blueprint scenario, it is expected that the user first sets up Ambari for
SSO integration using the \{{ambari-server setup-sso}} CLI. The Blueprint is
expected to set the relevant properties needed to enable SSO integration per
service. However, if SSO details were set up, the stack advisor may recommend
relevant changes which may be applied depending on the Blueprint settings.
> Allow Ambari Server to Setup SSO for the entire stack using the CLI
> -------------------------------------------------------------------
>
> Key: AMBARI-23253
> URL: https://issues.apache.org/jira/browse/AMBARI-23253
> Project: Ambari
> Issue Type: Epic
> Components: ambari-server
> Affects Versions: 2.7.0
> Reporter: Robert Levas
> Assignee: Robert Levas
> Priority: Major
> Labels: SSO, sso
> Fix For: 2.7.0
>
>
> Today enabling SSO requires visiting each component that supports SSO and
> adding configuration entries to each. This task is to enable a single entry
> point via the Ambari CLI to configure SSO for each service that supports it.
> Changes to the ambari-server setup-sso CLI are needed allow configuration of
> all SSO-capable services using that single CLI. This facility can be used to
> enable, disable, and reconfigure SSO integration.
> *Proposed implementation:*
> Services are to declare they support SSO integration by indicating in the
> service's \{{metainfo.xml}} file as follows:
> {code}
> <sso>
> <supported>true</supported>
> <enabledConfiguration>config-type/sso.enabled.property</enabledConfiguration>
> </sso>
> {code}
> The stack/service advisor will be used to retrieve the recommended
> configurations needed by a service to set up SSO integration. A special stack
> advisor action will be added to ensure only SSO-related recommendations are
> returned upon request. The new action name is
> "{{recommend-configurations-for-sso}}". Ambari (or common) SSO information
> will be provided to the stack advisor via the input data under the label
> "sso-configuration". This information may be used by the stack advisor when
> creating recommendations.
> Ambari will store details on which services should be enabled for SSO so it
> _knows_ how to behave when SSO integration is enabled and new services are
> added. This data will be stored within Ambari's configuration data under the
> category of {{sso-configuration}}. The list of services to have SSO
> integration turned on will be stored in the property named
> {{ambari.sso.enabled_services}}. The value will be a comma-delimited list of
> service names, or "{{*}}" to indicate all services that support SSO
> integration.
> The Ambari REST API entry point for installed services
> ({{/api/v1/clusters/:CLUSTER_NAME/services/:SERVICE_NAME}}) is to be enhance
> by adding the following properties:
> * *\{{sso_integration_supported}}* - Indicates whether the service supports
> SSO integration or not
> * *\{{sso_integration_enabled}}* - Indicates whether the service is
> configured for SSO integration or not
> * *\{{sso_integration_desired}}* - Indicates whether the service is chosen
> for SSO integration or not
> The Ambari REST API entry point for stack services
> ({{/api/v1/stacks/:STACK_NAME/versions/:VERSION/services/:SERVICE_NAME}}) is
> to be enhance by adding the following properties:
> * *\{{sso_integration_supported}}* - Indicates whether the service supports
> SSO integration or not
> When producing a list of installed services that support SSO integration in
> the CLI, the Ambari REST API is to be used to query for the relevant service
> names. Once the user selects the set of services to enable SSO for (or all),
> the Ambari REST API is to be used to set the value of the Ambari
> configuration \{{sso-configuration/sso_enabled_services}}. Upon setting this,
> logic is triggered in the backend to query the stack advisor for SSO-related
> configuration recommendations which will be automatically applied. This will
> potentially yield new configuration versions and require services to be
> manually restarted.
> When adding new services, the
> \{{sso-configuration/ambari.sso.enabled_services}} value is to be checked to
> see if the new service is on the list of services to have SSO integration
> enabled. If so, and the service has a SSO descriptor, its configuration will
> be updated as needed before the service is started.
> In a Blueprint scenario, it is expected that the user first sets up Ambari
> for SSO integration using the {{ambari-server setup-sso}} CLI. The Blueprint
> is expected to set the relevant properties needed to enable SSO integration
> per service. However, if SSO details were set up, the stack advisor may
> recommend relevant changes which may be applied depending on the Blueprint
> settings.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
