[
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)
