Feature #8484: Make SmartProxyAuth concern more useful to plugins - Foreman

Custom queries

3.11.5 release DONE
3.11.5 release TODO
3.12.2 release DONE
3.12.2 release TODO
3.13.1 release DONE
3.13.1 release TODO
All bugs by votes
All issues closed in the last 3 weeks
Easy and Trivial Issues
Easy Issues (only)
Foreman - new open issues in last 10 days
Good first issues - Foreman core
high prio open bugs
Host registration [open]
Mine
My issues closed in the last 3 weeks
old bugs
Open with target version set (aka blockers)
registration
taken-none
Team Atlas untriaged bugs
templates
Trivial Issues
Untriaged and opened in the past two weeks

Actions

Copy link

Feature #8484

closed

Make SmartProxyAuth concern more useful to plugins

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

Status:

Closed

Priority:

Normal

Assignee:

Stephen Benjamin

Category:

Authentication

Target version:

1.8.0

Difficulty:

Triaged:

Bugzilla link:

Pull request:

https://github.com/theforeman/foreman/pull/1975

Fixed in Releases:

Found in Releases:

Red Hat JIRA:

Description

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

Related issues 4 (0 open — 4 closed)

Related to Foreman - Bug #8949: Setting rename migration for {restrict_registered, require_ssl}_puppetmaster is actually a noop	Closed	Stephen Benjamin	01/14/2015	Actions
Related to Foreman - Bug #8922: authorized_smart_proxy_features should not fail if not implemented	Closed	Daniel Lobato Garcia	01/13/2015	Actions
Related to ABRT - Bug #8646: Foreman will refuse reports from proxies that are not Puppet/Chef proxies	Closed	Martin Milata	12/10/2014	Actions
Related to Foreman - Bug #11921: Features in controller authentication are not loaded correctly if you modify them from plugins	Closed	Marek Hulán	09/22/2015	Actions

Issue # Delay: days Cancel

History
Notes
Property changes
Associated revisions

Actions

Copy link

Updated by Marek Hulán about 10 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

Copy link

Updated by The Foreman Bot about 10 years ago

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

Actions

Copy link

Updated by Stephen Benjamin about 10 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

Copy link