Project

General

Profile

Feature #8484

Make SmartProxyAuth concern more useful to plugins

Added by Stephen Benjamin over 5 years ago. Updated almost 2 years ago.

Status:
Closed
Priority:
Normal
Category:
Authentication
Target version:
Difficulty:
Triaged:
Bugzilla link:
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

Related to Foreman - Bug #8949: Setting rename migration for {restrict_registered, require_ssl}_puppetmaster is actually a noopClosed2015-01-14
Related to Foreman - Bug #8922: authorized_smart_proxy_features should not fail if not implementedClosed2015-01-13
Related to Foreman - Bug #11921: Features in controller authentication are not loaded correctly if you modify them from pluginsClosed2015-09-22

Associated revisions

Revision 53da2694 (diff)
Added by Stephen Benjamin over 5 years ago

fixes #8484 - use new smart proxy features-based auth

Revision c3b33536 (diff)
Added by Stephen Benjamin over 5 years ago

fixes #8484 - make SmartProxyAuth concern more useful to plugins

Revision 1fb1a0b3 (diff)
Added by Stephen Benjamin over 5 years ago

refs #8484 - use new smart proxy filters

Revision 1e274611
Added by Stephen Benjamin over 5 years ago

Merge pull request #21 from stbenjam/8484

refs #8484 - use new smart proxy filters

Revision 2ea959fb
Added by Marek Hulán over 5 years ago

Merge pull request #7 from stbenjam/8484

fixes #8484 - use new smart proxy features-based auth

History

#1 Updated by Marek Hulán over 5 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.

#2 Updated by The Foreman Bot over 5 years ago

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

#3 Updated by Stephen Benjamin over 5 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.

#4 Updated by Marek Hulán over 5 years ago

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

#5 Updated by Dominic Cleal over 5 years ago

  • Legacy Backlogs Release (now unused) set to 28

#6 Updated by Anonymous over 5 years ago

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

#7 Updated by Dominic Cleal over 5 years ago

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

#8 Updated by Dominic Cleal over 5 years ago

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

#10 Updated by Marek Hulán over 4 years ago

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

Also available in: Atom PDF