The main endpoint is the PdpController. It is protected by the security configuration in WebSecurityConfig.

There are two AuthenticationProviders in the PDP application:

1. A Shibboleth PreAuthenticatedAuthenticationProvider implementation which protects all the /internal/** endpoints.
2. A BasicAuthenticationFilter which protects all the /protected/** endpoints.

The Shibboleth filter inspects the request headers for pre-populated Shibboleth values. The task of building a Shibboleth federated user based on the request headers is handled by the FederatedUserBuilder.

Only federated logged in users are therefore allowed access to the /internal/** endpoints. The /internal/**endpoints are used by the internal PDP JavaScript GUI. It is highly recommended to limit access to the PDP Admin GUI using a PDP policy.

There are two trusted clients that use the username/password /protected/** endpoints:

1. EngineBlock for the policy decision endpoint
2. Dashboard server for the maintenance of institutional policies.

The trusted Dashboard server sends custom request headers to PDP API calls indicating who is logged in. The PDP application uses these custom headers to populate an institutional admin.

Whenever policies are returned, created or updated the PDPController asks the PolicyIdpAccessEnforcer to check if the action is allowed. Therefore institutional admins in Dashboard can only see their own policies.

The internal PDP admin GUI has no restrictions in the accessibility of policies, because the /internal/** endpoints pre-populates an user that is not limited by the PolicyIdpAccessEnforcer.

The external API for trusted applications - e.g. Dashboard server - restricts access to policies based on the Identity Provider and the possible associated Service Provider(s) of the logged-in user with Dashboard and the corresponding Service and Identity Provider(s) of the policy that is accessed.

See this image for an overview of the logic applied in determining policy accessibility.