You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@nifi.apache.org by "Kevin Doran (JIRA)" <ji...@apache.org> on 2017/11/14 18:01:00 UTC

[jira] [Updated] (NIFIREG-45) Refactor NiFi Registry LoginIdentityProvider

     [ https://issues.apache.org/jira/browse/NIFIREG-45?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kevin Doran updated NIFIREG-45:
-------------------------------
    Attachment: IdentityProviderDesign.png

Attached to this JIRA ticket is a design for how to bridge an implementation of IdentityProvider, which has no dependency on Spring Security to the Spring Security framework. The NiFi Registry Framework implements IdentityFilter and IdentityAuthenticationProvider, which implement Spring Interfaces and have an IdentityProvider dependency injected.

> Refactor NiFi Registry LoginIdentityProvider
> --------------------------------------------
>
>                 Key: NIFIREG-45
>                 URL: https://issues.apache.org/jira/browse/NIFIREG-45
>             Project: NiFi Registry
>          Issue Type: Improvement
>            Reporter: Kevin Doran
>            Assignee: Kevin Doran
>         Attachments: IdentityProviderDesign.png
>
>
> The initial implementation of identity provider implementation for NiFi Registry was based on the current (at the time) implementation on NiFi that used a LoginIdentityProvider Interface that authenticated a LoginCredentials object holding a username/password. This was for legacy reasons that were NiFi-specific relating to avoiding inclusion of servlet jars in the dependency for the identity provider api module.
> This is not a constraint for Registry (or NiFi any more apparently), so this ticket is to refactor this interface to be more general by authenticating a ServletRequest object, which would open implementations up to supporting more ways of the client passing in the identity claim (eg, cookie value).



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)