JSON Web Tokens (JWT)  can be an option.
It will provide claims required for authorization without needing
verification with issuer.
Auth0.com has more info on this method.
JWT can be use to propagate identity along the flow so that it can be  used
later by processors

On Mon, Oct 5, 2015, 7:41 PM Rick Braddy <rbra...@softnas.com> wrote:

> SSO is another important consideration.
>
> Spring Security looks like a winner. Very impressive list of support.
>
>
> > On Oct 5, 2015, at 9:34 PM, larry mccay <lmc...@apache.org> wrote:
> >
> > The wiki page seems to describe continuing to use Spring Security.
> > I believe this to be a wise choice.
> >
> > I would encourage you to try and expose the capabilities of that
> framework
> > as much as possible rather than providing support for a constrained set
> of
> > providers.
> >
> > SSO integrations are becoming important for a number of ecosystem
> projects
> > and UIs for instance.
> > The ability to add a custom authentication provider will be important for
> > such usecases.
> >
> >> On Mon, Oct 5, 2015 at 10:10 PM, Tony Kurc <trk...@gmail.com> wrote:
> >>
> >> I'd like to see Duo Web two-factor
> https://www.duosecurity.com/docs/duoweb
> >>
> >>> On Mon, Oct 5, 2015 at 10:00 PM, Rick Braddy <rbra...@softnas.com>
> wrote:
> >>>
> >>> 1) Basic password authentication with Recaptcha after N failed logins
> >>> (encrypted password storage)
> >>>
> >>> 2) 2-factor Google Auth option to supplement password logins
> >>>
> >>> 3) Active Directory / Kerberos auth (with 2-factor option as well)
> >>>
> >>>> On Oct 5, 2015, at 8:56 PM, Joe Witt <joe.w...@gmail.com> wrote:
> >>>>
> >>>> Thanks Rick.  If you were to say which of that you'd want 'first' and
> >>>> then which you can see coming later please advise.
> >>>>
> >>>> All: Please do just that - let us know which you need 'now' and which
> >>>> you can wait on.
> >>>>
> >>>> Thanks
> >>>> Joe
> >>>>
> >>>>> On Mon, Oct 5, 2015 at 9:53 PM, Rick Braddy <rbra...@softnas.com>
> >>> wrote:
> >>>>> Matt,
> >>>>>
> >>>>> Here you go:
> >>>>>
> >>>>> -  2-factor Google Authenticator to supplement password auth (e.g. to
> >>> strengthen password with mobile phone onetime ID or other support
> strong
> >>> auth options)
> >>>>>
> >>>>> - Recaptcha required after N failed password login attempts to block
> >>> brute force attacks (e.g. 5 failed logins, then captcha required)
> >>>>>
> >>>>> - Password strength policies
> >>>>>
> >>>>> - PAM support provides pluggable authentication options, at least for
> >>> Linux (better than locally stored passwords)
> >>>>>
> >>>>> - Active Directory Kerberos integration (Windows native and Linux)
> >>>>>
> >>>>> If passwords to be stored locally, must be encrypted.
> >>>>>
> >>>>> Hope that helps.
> >>>>>
> >>>>> Rick
> >>>>>
> >>>>>> On Oct 5, 2015, at 8:34 PM, Matt Gilman <matt.c.gil...@gmail.com>
> >>> wrote:
> >>>>>>
> >>>>>> All,
> >>>>>>
> >>>>>> I've started working on providing additional authentication
> >> mechanisms
> >>> for
> >>>>>> the NiFi user interface. Currently, only two way SSL using client
> >>>>>> certificates is supported to authenticate users. I would like to
> >>> inquire
> >>>>>> about which other mechanisms the community would like to see
> >>> implemented.
> >>>>>>
> >>>>>> We have created a feature proposal discussing some of the options
> >> [1].
> >>> At a
> >>>>>> high level, in additional to PKI, we are looking at
> >>>>>>
> >>>>>> - Username/password
> >>>>>> -- stored in a local configuration file (ie authorized-users.xml)
> >>>>>> -- stored in a configurable LDAP
> >>>>>> -- stored in a configurable database
> >>>>>> - Kerberos
> >>>>>> - OpenId Connect
> >>>>>>
> >>>>>> What other options are important and should be added to the list?
> >>> Thanks!
> >>>>>>
> >>>>>> Matt
> >>>>>>
> >>>>>> [1]
> >>
> https://cwiki.apache.org/confluence/display/NIFI/Pluggable+Authentication
> >>
>

Reply via email to