[
https://issues.apache.org/jira/browse/KNOX-2020?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16947984#comment-16947984
]
Sharad K edited comment on KNOX-2020 at 10/9/19 8:43 PM:
---------------------------------------------------------
# As I explained this may not be an out of feature box but paves way for future
applications that want to interact with AWS ecosystem (or any cloud provider
that supports SAML federation).
# SAML is a stronger authentication protocol than other protocols that accept
user credentials with the service provider. Right now the major use cases are
with a browser (or so called SAML passive profile). I'd not like to add an API
that accepts credentials, and then does cloud federation. It goes against the
best practices that SAML, OAuth, OIDC etc try to achieve (distinction between
SP and IDP etc). As I understand the SAML active profile is not very well
adopted, but it could be a possibility in future to add via which a non browser
application could present it's SAML token to Knox, and it gives back a
decorated hadoop-jwt cookie (much like what kinit does with kerberos). Another
benefit is that it's seamless to the end user (has to do nothing special than
what he used to) like a data scientist working with a notebook like Jupyter.
His Spark jobs run as the right user via Livy.
# That's true and as I said this contribution paves way for a secure mechanism
to federate into AWS, or any other cloud provider that supports SAML. Once in
cookie we have the notebooks or REST ful services like Livy, or HS2 that can
benefit from it. In credentials file the CLI apps can benefit from it.
I am open to your suggestions [~lmccay] .
was (Author: sharad-oss):
# As I explained this may not be an out of feature box but paves way for future
applications that want to interact with AWS ecosystem (or any cloud provider
that supports SAML federation).
# SAML is a stronger authentication protocol than other protocols that accept
user credentials with the service provider. Right now the major use cases are
with a browser (or so called passive profile). I'd not like to add an API that
accepts credentials, and then does cloud federation. It goes against the best
practices that SAML, OAuth, OIDC etc try to achieve (distinction between SP and
IDP etc). As I understand the SAML active profile is not very well adopted, but
it could be a possibility in future to add via which a non browser application
could present it's SAML token to Knox, and it gives back a decorated hadoop-jwt
cookie (much like what kinit does with kerberos). Another benefit is that it's
seamless to the end user (has to do nothing special than what he used to) like
a data scientist working with a notebook like Jupyter. His Spark jobs run as
the right user via Livy.
# That's true and as I said this contribution paves way for a secure mechanism
to federate into AWS, or any other cloud provider that supports SAML. Once in
cookie we have the notebooks or REST ful services like Livy, or HS2 that can
benefit from it. In credentials file the CLI apps can benefit from it.
I am open to your suggestions [~lmccay] .
> 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 40m
> 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)
