Page History

...

• We have to ascertain the impact of changing the auth handler on the UI endpoints on the REST APIs that may be on the same endpoint
• Cookie domains may not need to be the same across all UIs using this approach
• In order to do a more complicated/secure token between knoxsso and the UI - we will need to verify signature using a common key. This will likely require the use of the KeyProvider API or CredentialProvider API. This will also require either:
  • a central KMS provider that will allow contrained access to the same key materials by knoxsso and the UI auth handler
  • separate keystores that will need the key provisioned independently and to stay in sync
• Normalizing on JWT as the token that is consumed by the UI auth handler will require some JWT parsing and verification code to be available in hadoop. Not sure if it can be put into hadoop auth module or whether it needs to go into common/security.
• This same architecture can be used with other implementations on the knoxsso side in place of the SAML/Shibboleth integration. We will have to make this configurable. The first filter will also capture the original url and the last will always redirect back to the original url. The processing that goes on in between can be pluggable to accommodate various integrations with SSO providers, simple hosted mechanisms (FORM, HTTP Basic), etc.

Other Considerations

• Introduce new SSO cookie as first class citizen rather than hadoop auth cookie
• Create new filter for new cookie instead of a new handler
• Refactor existing AuthenticationFilter into a delegating filter rather than returning 403
  • add check to see if the user is established already
  • continue the filter chain
  • add new filter that checks for established user and in it's absence looks for new cookie
  • does the redirect
  • verifies the signature based on PKI public key of the configured knoxsso endpoint
  • add new filter that terminates the chain, returning 403 if the user has not been established at the end
• New knoxsso cookie is better security due to PKI rather than a shared secret across the cluster that can/must be acquired by each server
• Shouldn't get much push back due to Alejandro leaving cloudera
• Can always fall back to the hadoop auth cookies under pressure and revisit it later
• Add groups to the knoxsso token
• We may be able to get away with using existing hadoop auth cookie with a strengthened signer based on PKI

hide footbox
autonumber

participant "Browser" as cli
participant "WebUI\n(eg NN UI)" as ui
participant "Knox\nTS/SSO" as sso
participant "SAML\nIdP" as idp
 
activate cli
cli -> ui: page.GET()
  activate ui
  cli <-- ui: redirect(IDP.login)
  deactivate ui
cli -> idp: login.GET()
  activate idp
  cli <-- idp: form
  deactivate idp
cli -> idp: form.POST(username,password)
  activate idp
  cli <-- idp: redirect(SSO.translate):saml-bearer-token
  deactivate idp
cli -> sso: translate.GET(saml-bearer-token)
  activate sso
  cli <-- sso: redirect(WebUI.page):jwt-bearer-token-cookie
  deactivate sso
cli -> ui: page.GET(jwt-bearer-token-cookie)
  activate ui
  cli <- ui: response
  deactivate ui
deactivate cli

...