Include user's privileges actions in IdP plugin _has_privileges request

[s-nel]

Currently the identity provider (IdP) plugin pulls and caches a given application's privileges' actions in ApplicationActionsResolver which are used to construct a _has_privileges request and each that matches the service provider's template will be returned as roles in the SAML response. The problem with this approach is that it misses actions defined in roles that may not be present in the predefined application privileges. For example given this role:

{
    "application": [
        {
            "application": "elastic-cloud",
            "privileges": ["sso:custom"],
            "resources": "*"
        }
    ]
}

and service provider that matches sso:(.*). Unless sso:custom is returned in GET /_security/privilege/elastic-cloud, custom role will not be present in the SAML response.

This PR pulls user privileges from the GET /_security/user/_privileges response and includes all actions with the matching application in the _has_privileges request alongside the cached actions.

[elasticsearchmachine]

Pinging @elastic/es-security (Team:Security)

[elasticsearchmachine]

Hi @s-nel, I've created a changelog YAML for you.

[jakelandis]

code itself LGTM

however, not sure I understand the functional side or why this change is needed.

Unless sso:custom is returned in GET /_security/privilege/elastic-cloud, custom role will not be present in the SAML response.

Why would sso:custom NOT be returned by GET /_security/privilege/elastic-cloud ?

that it misses actions defined in roles that may not be present in the predefined application privileges

Isn't that a good thing ? The input to get the application privs is the application name and why would we want to get all the of the them in the role ? (I see the code filters the role results by application name, so no worries about the code, just trying to understand why this change is needed)

[jakelandis]

Also tangential to this change ... I noticed that we are doing all of this work on the transport thread. The new action call is all local, so it probably doesn't add much overhead but long term we probably want to fork earlier here to get off the transport thread to allow for more concurrent throughput. As-is we we are not getting much benefit from NIO or the overhead of the creating all of these listeners. (we could probably also do some of this work in parallel too)

[s-nel]

Why would sso:custom NOT be returned by GET /_security/privilege/elastic-cloud ?

GET /_security/privilege/elastic-cloud only returns predefined named privilege -> actions mappings. Since sso:custom is an action that only exists in the role it's not returned.

The background is that we want to give users the ability to specify a role that they will get during SSO. This could be any custom role that they've configured and we don't know it in advance. Our approach to support this is to add the action to the user's role. For example

{
    "custom-sso-role": {
        "cluster": [],
        "indices": [],
        "applications": [
            {
                "application": "elastic-cloud",
                "privileges": [
                    "deployment-viewer",
                    "deployment:sso-custom" // <-- this privilege should allow the user to SSO with role `custom`
                ],
                "resources": [...]
            }
        ]
    }
}

Also tangential to this change ... I noticed that we are doing all of this work on the transport thread. The new action call is all local, so it probably doesn't add much overhead but long term we probably want to fork earlier here to get off the transport thread to allow for more concurrent throughput. As-is we we are not getting much benefit from NIO or the overhead of the creating all of these listeners. (we could probably also do some of this work in parallel too)

Are you suggesting that I make the change in this PR?

[jakelandis]

Caught up with @s-nel in slack...thanks for the additional context !

Why would sso:custom NOT be returned by GET /_security/privilege/elastic-cloud ?

I see now that the idea is the privilege (sso:custom) will not be registered with the application (elastic-cloud). If it was registered it then this PR would not be needed but we could also introduce a possible issue with the cache and introduce a performance issue since we run all registered privileges through a has_privileges check. Since the number of custom privileges are essentially unbounded we need a way to ensure we don't blow up the cache or performance. The change here allows us not register the privilege with the application and instead read the privilege from the role directly. This mitigates the issue since we will not greatly expand the number of privileges for the application and we can grab this new information from the user's role (in the security cluster) directly. It does slightly muddy the water w.r.t. application level privs since for this specific workflow you can you use privs for an application without declaring those privs for the application ...but in the context of the end goal this makes sense. The end result is that we will have pre-defined privileges registered with the application and purely custom roles (represented as privileges that are then are reflected in the SAML assertion used for role mapping) that live only in the role (in the security cluster).

Are you suggesting that I make the change in this PR?

No .. sorry that was not clear. Just something I noticed while reviewing this PR... that change would be way outside the scope of this change.

[jakelandis]

LGTM