Project

General

Profile

Actions

Feature #8484

closed

Make SmartProxyAuth concern more useful to plugins

Added by Stephen Benjamin over 9 years ago. Updated about 6 years ago.

Status:
Closed
Priority:
Normal
Category:
Authentication
Target version:
Difficulty:
Triaged:
Fixed in Releases:
Found in Releases:

Description

Instead of being only handling the Puppet case, change the concern to authenticate arbitrary Smart Proxies / Features


Related issues 4 (0 open4 closed)

Related to Foreman - Bug #8949: Setting rename migration for {restrict_registered, require_ssl}_puppetmaster is actually a noopClosedStephen Benjamin01/14/2015Actions
Related to Foreman - Bug #8922: authorized_smart_proxy_features should not fail if not implementedClosedDaniel Lobato Garcia01/13/2015Actions
Related to ABRT - Bug #8646: Foreman will refuse reports from proxies that are not Puppet/Chef proxiesClosedMartin Milata12/10/2014Actions
Related to Foreman - Bug #11921: Features in controller authentication are not loaded correctly if you modify them from pluginsClosedMarek Hulán09/22/2015Actions
Actions #1

Updated by Marek Hulán over 9 years ago

I was thinking about this few days ago. I think Feature model should define whether we should trust that SmartProxy for authentication. Other plugins adds their own features to SmartProxy so they could just create it with (e.g.) authentication flag set to true.

Actions #2

Updated by The Foreman Bot over 9 years ago

  • Status changed from New to Ready For Testing
  • Pull request https://github.com/theforeman/foreman/pull/1975 added
  • Pull request deleted ()
Actions #3

Updated by Stephen Benjamin over 9 years ago

@Marek - That could work also. The end goal for me was just to get rid of all the alias_method_chains and hacking I have on this Concern in foreman_salt.

The way I have it in the PR, each controller specifies which features are allowed to access it. This does have the advantage that a Salt-only Smart Proxy won't have access to say for example, an endpoint for the ABRT or OpenScap plugins.

FactImporters (and hopefully soon ReportImporters) are special in that the plugin's implementation would supply authorized features.

Actions #4

Updated by Marek Hulán over 9 years ago

Yeah, nice one! I'm looking forward to test it with chef plugin.

Actions #5

Updated by Dominic Cleal over 9 years ago

  • Translation missing: en.field_release set to 28
Actions #6

Updated by Anonymous over 9 years ago

  • Status changed from Ready For Testing to Closed
  • % Done changed from 0 to 100
Actions #7

Updated by Dominic Cleal over 9 years ago

  • Related to Bug #8949: Setting rename migration for {restrict_registered, require_ssl}_puppetmaster is actually a noop added
Actions #8

Updated by Dominic Cleal over 9 years ago

  • Related to Bug #8922: authorized_smart_proxy_features should not fail if not implemented added
Actions #9

Updated by Stephen Benjamin over 9 years ago

  • Related to Bug #8646: Foreman will refuse reports from proxies that are not Puppet/Chef proxies added
Actions #10

Updated by Marek Hulán almost 9 years ago

  • Related to Bug #11921: Features in controller authentication are not loaded correctly if you modify them from plugins added
Actions

Also available in: Atom PDF