[
https://issues.apache.org/jira/browse/NIFIREG-45?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16260795#comment-16260795
]
ASF GitHub Bot commented on NIFIREG-45:
---------------------------------------
Github user kevdoran commented on the issue:
https://github.com/apache/nifi-registry/pull/37
Good catch! I added a null check that makes the LdapIdentityProvider
implementation handle this gracefully. The next PR (#41) makes this even a bit
more robust by adding a null check in the /access/token/identity-provider as
well.
Thanks for the feedback, let me know if you see anything else to change
prior to merging in. There are a couple deprecated classes (exception types)
that I plan to address in a follow up PR as there were already a ton of classes
touched here and I didn't want to introduce the noise of a bunch of classes
with one-line changes to exception types in this PR.
> 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)
