Hi Tom - Sorry for the delayed response.
I'm not entirely sure that I am understanding completely your description for an upstream application. Let me describe the usecases that we target for typical middleware applications consuming REST APIs through Apache Knox and we can start from there. Often, applications that consume Hadoop REST APIs through Knox authenticate the user themselves and merely want to assert the user's identity to Knox rather than have Knox challenge the application with some sort of authentication like a SPNEGO negotiate or Basic auth. One of the ways to do this is to leverage the Header-based Preauthenticated SSO provider in Knox [1]. This allows the application to propagate the user's identity and optionally groups via HTTP Headers. Knox will then pull the identity and groups out of the headers and impersonate that identity when interacting with the Hadoop services. The Hadoop services may be kerberized or not and the client - in this case, the middleware application is shielded from this burden. There is an important caveat to using this mechanism: There must not be any way to get directly to Knox other than through or from a trusted entity. Otherwise, an actor could impersonate anyone using this mechanism. It is strongly encourage to use 2-way SSL between applications that should be trusted by Knox and the Knox Gateway [2]. Hope this is helpful. If your usecase differs from what I describe here then please describe how and we can take it from there. thanks, --larry [1] - http://knox.apache.org/books/knox-0-9-0/user-guide.html#Preauthenticated+SSO+Provider [2] - http://knox.apache.org/books/knox-0-9-0/user-guide.html#Mutual+Authentication+with+SSL On Fri, Jun 17, 2016 at 10:16 AM, Ellis, Tom (Financial Markets IT) < [email protected]> wrote: > Hi, > > > > We have an upstream application that wishes to access Hadoop REST > endpoints behind Knox on behalf of Users – i.e. that the User is passed > down through the upstream application, through Knox, and into the Hadoop > REST endpoint. > > > > Am I right in thinking that so long as the upstream application correctly > performs SPNEGO itself and uses the obtained subject, and that Knox is > configured with the default identity assertion provider then this subject > will also be passed down to the Hadoop REST endpoints? > > > > Would anyone be able to elaborate a bit more on the internals of how that > works, or point me in the direction of the implementation classes so I can > follow through the code? > > > > Otherwise, if the above is not correct is what I’m trying to achieve > possible and how can we accomplish it? > > > > *Cheers,* > > > > *Tom Ellis* > Consultant Developer – Excelian > > Data Lake | Financial Markets IT > *LLOYDS BANK COMMERCIAL BANKING* > ------------------------------ > > > *E: *[email protected] > Website: www.lloydsbankcommercial.com > , , , > Reduce printing. Lloyds Banking Group is helping to build the low carbon > economy. > Corporate Responsibility Report: www.lloydsbankinggroup-cr.com/downloads > > > > Lloyds Banking Group plc. Registered Office: The Mound, Edinburgh EH1 1YZ. > Registered in Scotland no. SC95000. Telephone: 0131 225 4555. Lloyds Bank > plc. Registered Office: 25 Gresham Street, London EC2V 7HN. Registered in > England and Wales no. 2065. Telephone 0207626 1500. Bank of Scotland plc. > Registered Office: The Mound, Edinburgh EH1 1YZ. Registered in Scotland no. > SC327000. Telephone: 03457 801 801. Cheltenham & Gloucester plc. Registered > Office: Barnett Way, Gloucester GL4 3RL. Registered in England and Wales > 2299428. Telephone: 0345 603 1637 > > Lloyds Bank plc, Bank of Scotland plc are authorised by the Prudential > Regulation Authority and regulated by the Financial Conduct Authority and > Prudential Regulation Authority. > > Cheltenham & Gloucester plc is authorised and regulated by the Financial > Conduct Authority. > > Halifax is a division of Bank of Scotland plc. Cheltenham & Gloucester > Savings is a division of Lloyds Bank plc. > > HBOS plc. Registered Office: The Mound, Edinburgh EH1 1YZ. Registered in > Scotland no. SC218813. > > This e-mail (including any attachments) is private and confidential and > may contain privileged material. If you have received this e-mail in error, > please notify the sender and delete it (including any attachments) > immediately. You must not copy, distribute, disclose or use any of the > information in it or any attachments. Telephone calls may be monitored or > recorded. >
