#5030 [RFE] Add a way to store and manage URLs/resources for applications
Closed: wontfix 5 years ago by rcritten. Opened 8 years ago by dpal.

There was a deployment that wanted to use IPA with SSSD and apache modules to replace the functionality of the RSA Authorization Manager. RSA Authorization Manager effectively acts as a central server that defines which users and groups can access which URLs.

The solution we proposed was to map URL in mod_authnz_pam to a service and then use standard HBAC in IPA. However it might be beneficial to have an apache module that can be more dynamic.
It would take user and URL or resourceID and ask SSSD over D-BUS whether user can be granted access to a resource. SSSD would fetch information from IPA and cache it similarly to HBAC rules.

The rules would look like HBAC but instead it will have:
- User, Group, All
- Application identifier
- Resource type identifier (URL or may be Role)
- Attribute with the resource list

This model will allow to provide a centrally managed role based access control for applications as well as manage URLs.

By doing that we can reduce the burden for developers to do their own access control. It becomes similar to PicketLink but can be used for non Java based applications.


There are several places that need this function:

  1. ACLs for a messaging broker such as QPID
  2. IRC channels.
  3. database tables

IN All three cases, the resource can be described by a URL

protocol:hostname:resourcename

Querying can be filtered by the resource protocol; Apache only needs HTTP, QPID only need amqp:

I am also interested in this for access control/identity management/group/role definition for ampq and elasticsearch.

Metadata Update from @dpal:
- Issue assigned to lhellebr
- Issue set to the milestone: Ticket Backlog

7 years ago

Thank you taking time to submit this request for FreeIPA. Unfortunately this bug was not given priority and the team lacks the capacity to work on it at this time.

Given that we are unable to fulfil this request I am closing the issue as wontfix. To request re-consideration of this decision please reopen this issue and provide additional technical details about its importance to you.

Metadata Update from @rcritten:
- Issue close_status updated to: wontfix
- Issue status updated to: Closed (was: Open)

5 years ago

Login to comment on this ticket.

Metadata