Architecture#

Rather than requiring every application to integrate with every campus and every campus to trust every application bilaterally, CORTEX places a single Federation Gateway (proxy) between them. Each participant trusts only the proxy, and the gateway brokers identity, discovery, and authorization on their behalf.

_images/architecture.svg

Federation Gateway (Proxy)#

The Federation Gateway (Proxy) is the hub of the platform. It presents itself as a Service Provider (SP) to campus Identity Providers (IdPs) and as an Identity Provider (IdP) to protected applications, serving as a bridge between them. Every login flows through it.

Campuses and application owners each maintain exactly one trust relationship with the proxy.

Campus Identity Providers#

Tip

CORTEX does not manage campus credentials or replace campus Identity Providers (IdPs).

Campus Identity Providers (IdPs) authenticate researchers using the credentials they already hold at their home institutions, such as research organizations, universities, and other participating institutions. When a user signs in to an application integrated with CORTEX, their campus IdP asserts their campus identity to the proxy.

Discovery Service#

Because a Virtual Organization (VO) spans many institutions, the proxy must first determine which campus a user belongs to during the authentication process. The Discovery Service performs this home realm discovery function by allowing users to select their home institution so that the proxy can forward the authentication request to the correct campus IdP.

Collaboration Management Platform (Registry)#

Registry is the system of record for the Virtual Organization. It stores VO registration data, including who has enrolled in the collaboration, the groups and roles they belong to, and the lifecycle state of their membership.

The Registry answers the question of who belongs to the collaboration. This is distinct from who a person is at their home institution. A researcher may be authenticated by their campus yet authorized only after they appear as an active member in the Registry. Membership managed in the Registry provides the identity and authorization data that the gateway ultimately releases to Service Providers (SPs).

Attribute Authority (LDAP)#

The Attribute Authority, backed by an LDAP directory, supplies the VO identity and authorization attributes for a user at login time, including collaboration scoped identifiers, group memberships, and entitlements. It is the read optimized source that the gateway queries during the authentication process and reflects the membership curated in the Registry.

Consolidating these attributes in a single authority ensures that every protected application receives the same current view of a user’s standing within the collaboration rather than each application maintaining its own copy.

Protected Applications (Service Providers)#

Protected applications are the resources that the collaboration shares. They are the Service Providers (SPs) that researchers ultimately want to access. They delegate authentication and authorization entirely to the Federation Gateway.

An application never sees campus credentials and does not implement VO membership logic. Instead, it receives the VO identity and authorization attributes released by the gateway and enforces access based solely on those attributes. This allows new applications to join the collaboration without integrating individually with every campus.