Feature Exploration

[lahirujayathilake]

Hey everyone!

I've been exploring some new feature ideas for Custos, and I believe the following could be useful for extending its capabilities. These are still at the idea stage, and I’d love to hear your thoughts on how they can be improved, expanded upon, or even if they aren’t worth pursuing. Feedback from this group will really help shape where we take things!

Here are a few ideas:

1. Application Concept

1. Organizing redirect URLs, callback URLs, application properties (e.g., authorization grant flow, application logo), and attaching groups or scopes under a unified "Application" entity. This will streamline configuration for developers and reduce redundancy
2. Multiple environments for a single application. For example, developers could define different configurations for dev, staging, and production environments within a single application, rather than setting up separate tenants or applications for each environment. This allows for more straightforward management of app lifecycles

2. Authorization and Access Control
This section explores how Custos handles access control, going beyond simple role assignments to include a combination of user attributes, context, and policies to determine what a user can access at any given time. These configurations, defined by an admin through the Custos portal, offer more flexibility in managing access while ensuring security and compliance across various applications and environments

1. Attribute-Based Access Control (ABAC)
   Dynamically grant or deny access based on user attributes like their email domain, department, or organizational role. This allows for more context-driven security policies
   1. Example: Users with an email domain matching "university.edu" are automatically added to a research group with specific permissions to access scientific data

2. Policy-Based Access Control (PBAC)
   This allows for custom policies where application owners or admins can set conditions based on both user attributes and external factors. Policies can be activated or deactivated as needed
   1. Example: If a user signs in from an unfamiliar IP address, the system could require additional verification or restrict access to sensitive resources

3. Groups with defined policies
   Allow admins to create groups that are tied to specific policies or access rights. These policies can be toggled based on the organization's needs.
   1. A PEARC_WORKSHOP group can have access to AWS compute resources during an event. The policy can be disabled after the event and re-enabled when needed again

3. Anomaly Detection
Proactive detection of unusual activity can strengthen Custos' security layer. Here are a few possible features:

1. Detect high-volume access or modification requests
   1. Example: Flagging situations where projects are being deleted unusually often, or resources are shared with a high number of users who have no previous interactions
2. Identify sudden logins from unexpected locations (geolocation anomalies)
3. Behavioral analytics to detect deviations from normal activity patterns
   1. Example: Insider threats: Identify if users who normally access routine files suddenly start interacting with files outside their typical scope, potentially indicating malicious intent
4. High request rates from a single IP, indicating potential brute force attacks or DDoS attempts
5. DDoS Attack Detection: Automatically flagging and responding to sudden spikes in traffic or request volume