You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@knox.apache.org by "Larry McCay (JIRA)" <ji...@apache.org> on 2016/12/20 20:35:58 UTC
[jira] [Comment Edited] (KNOX-749) Simple Admin UI
[ https://issues.apache.org/jira/browse/KNOX-749?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15765183#comment-15765183 ]
Larry McCay edited comment on KNOX-749 at 12/20/16 8:35 PM:
------------------------------------------------------------
Some thoughts on topology descriptors the this manager UI....
We should not introduce any requirements on the existing admin.xml topology that may break existing consumers that do not currently require webapp security protections - such as Apache Ranger.
The UI and the admin API are being used together require now and require protection against CSRF and XFS attacks. Our WebAppSec provider allows us to configure this protection in the topology. However, if we co-locate the admin-ui application and the KNOX service in the same topology then both of those protection will be required for both the UI page requests as well as the API calls.
A page request for the admin UI should not be required to send a HTTP Header for CSRF and since the API is the only way to POST or PUT changes the CSRF protection only needs to be on the API. Likewise, the API itself doesn't need protection against clickjacking - only the UI does.
Unfortunately, we don't have the ability to override the providers within a given application or service element at this time. Therefore, I think we should consider adding two new topologies for the admin UI scenerio:
# manager.xml which contains the admin-ui application
# manager-api.xml which contains the admin API service KNOXSSO
{no format}
manager.xml
<topology>
<gateway>
<provider>
<role>webappsec</role>
<name>WebAppSec</name>
<enabled>true</enabled>
<param><name>xframe.options.enabled</name><value>true</value></param>
</provider>
<provider>
<role>federation</role>
<name>SSOCookieProvider</name>
<enabled>true</enabled>
<param>
<name>sso.authentication.provider.url</name>
<value>https://www.local.com:8443/gateway/knoxsso/api/v1/websso</value>
</param>
</provider>
</gateway>
<application>
<role>admin-ui</role>
</application>
</topology>
{noformat}
<noformat>
manager-api.xml
<topology>
<gateway>
<provider>
<role>webappsec</role>
<name>WebAppSec</name>
<enabled>true</enabled>
<param><name>csrf.enabled</name><value>true</value></param>
</provider>
<provider>
<role>federation</role>
<name>SSOCookieProvider</name>
<enabled>true</enabled>
<param>
<name>sso.authentication.provider.url</name>
<value>https://www.local.com:8443/gateway/knoxsso/api/v1/websso</value>
</param>
</provider>
</gateway>
<service>
<role>KNOX</role>
</service>
</topology>
{noformat}
Thoughts?
was (Author: lmccay):
Some thoughts on topology descriptors the this manager UI....
We should not introduce any requirements on the existing admin.xml topology that may break existing consumers that do not currently require webapp security protections - such as Apache Ranger.
The UI and the admin API are being used together require now and require protection against CSRF and XFS attacks. Our WebAppSec provider allows us to configure this protection in the topology. However, if we co-locate the admin-ui application and the KNOX service in the same topology then both of those protection will be required for both the UI page requests as well as the API calls.
A page request for the admin UI should not be required to send a HTTP Header for CSRF and since the API is the only way to POST or PUT changes the CSRF protection only needs to be on the API. Likewise, the API itself doesn't need protection against clickjacking - only the UI does.
Unfortunately, we don't have the ability to override the providers within a given application or service element at this time. Therefore, I think we should consider adding two new topologies for the admin UI scenerio:
1. manager.xml which contains the admin-ui application
2. manager-api.xml which contains the admin API service KNOXSSO
{no format}
manager.xml
<topology>
<gateway>
<provider>
<role>webappsec</role>
<name>WebAppSec</name>
<enabled>true</enabled>
<param><name>xframe.options.enabled</name><value>true</value></param>
</provider>
<provider>
<role>federation</role>
<name>SSOCookieProvider</name>
<enabled>true</enabled>
<param>
<name>sso.authentication.provider.url</name>
<value>https://www.local.com:8443/gateway/knoxsso/api/v1/websso</value>
</param>
</provider>
</gateway>
<application>
<role>admin-ui</role>
</application>
</topology>
{noformat}
<noformat>
manager-api.xml
<topology>
<gateway>
<provider>
<role>webappsec</role>
<name>WebAppSec</name>
<enabled>true</enabled>
<param><name>csrf.enabled</name><value>true</value></param>
</provider>
<provider>
<role>federation</role>
<name>SSOCookieProvider</name>
<enabled>true</enabled>
<param>
<name>sso.authentication.provider.url</name>
<value>https://www.local.com:8443/gateway/knoxsso/api/v1/websso</value>
</param>
</provider>
</gateway>
<service>
<role>KNOX</role>
</service>
</topology>
{noformat}
Thoughts?
> Simple Admin UI
> ---------------
>
> Key: KNOX-749
> URL: https://issues.apache.org/jira/browse/KNOX-749
> Project: Apache Knox
> Issue Type: Bug
> Components: Server
> Reporter: Larry McCay
> Assignee: Sumit Gupta
> Fix For: 0.11.0
>
> Attachments: knox-admin-ui-001.patch
>
>
> We need to a simple UI for management/admin insights based on the Knox Admin API.
> We can start with a read-only iteration and extend it in a future release.
> [~zacblanco] has expressed interest in this effort on the dev list and possibly other JIRAs.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)