[jira] [Commented] (KNOX-2020) Enhance hadoop-jwt cookie to interact with the AWS ecosystem

["Larry McCay (Jira)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/KNOX-2020?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16965456#comment-16965456 ] 

Larry McCay commented on KNOX-2020:
-----------------------------------

[~sharad-oss] - sorry for the delay for this response.

I want to thank you again for this contribution!

I have been trying to reconcile a couple things with this and I have some thoughts for a less obtrusive change across the ecosystem in order to pick up the credentials. These are not fully thought through yet and I've just started the DISCUSS thread on planning for 1.4.0 release.

One thing that has been bothering me is that changes across the ecosystem would be required that would be able to verify and crack open the JWT based cookie and extract the credentials to be used within a credential provider for SDK calls. This mostly limits it to backend use AFAICT. Perhaps this could be done within JS singlepage apps, I'm not sure. But it would require the propagation of this cookie beyond the Knox gateway to the backends in a lot of cases. This isn't necessarily something that we want or need to do otherwise.

I don't want to include a change in 1.4.0 that paves the way for consumers that essentially only provides a way to leak cloud credentials into browsers with no actual feature available yet.

To clarify, I am quite familiar with SAML and its usefulness. What I was speaking to in the current patch is that it is completely limited to our SAML provider and kind of violates separation of concerns by combining the acquisition of cloud credentials with only a browser based SAML integration.  The current pac4j provider is dependent on browsers/cookies for its redirect and callback state and will not likely change easily.

What I would like to do is target a 1.5.0 release for this and a larger cloud native release theme that incorporates end-to-end usecases for cloud storage and other cloud capabilities/services. This theme would need to be written up as a KIP in our wiki and the required work spelled out and tracked accordingly. A feature branch for building out the POC and end-to-end feature usecases would probably be a good idea.

One thought for a usecase would be a file browser UI within our admin UI or as a separate UI application. Starting from there and fleshing out what the consumer side would look like would go a long way. From a design perspective, we should also not preclude the ability to integrate with non-S3 cloud storage as well.

I think that what we should do here is move this out to 1.5.0 fix version and begin the discussion and KIP for fleshing out the vision.

Thoughts?

> Enhance hadoop-jwt cookie to interact with the AWS ecosystem
> ------------------------------------------------------------
>
>                 Key: KNOX-2020
>                 URL: https://issues.apache.org/jira/browse/KNOX-2020
>             Project: Apache Knox
>          Issue Type: New Feature
>          Components: KnoxSSO, Server
>            Reporter: Sharad K
>            Priority: Major
>         Attachments: AWS Federation in Knox.docx
>
>          Time Spent: 6h 50m
>  Remaining Estimate: 0h
>
> It's desirable to access AWS managed services while accessing resources using Apache Knox. AWS provides SAML for federation, and we could enhance the SAML login flow in Knox to interact with AWS, and enhance the hadoop-jwt cookie with AWS credentials. The cookie now gives the gateway to interact with other AWS services like S3, DDB, EC2 etc (as defined by the IDP admin in the AWS Role that gets injected in SAML assertion).



--
This message was sent by Atlassian Jira
(v8.3.4#803005)