On this page
ABB Smart Access
Summary
Smart Access is the product-neutral architecture building block for context-aware access control for users and services. It states what DC 3.0 needs from this capability before a concrete SBB, product, or operating model is selected.
Capabilities
- Provides context-aware access control for users and services.
- Defines the functional, technical, security, and quality expectations that SBBs must satisfy.
- Keeps service ownership, interfaces, and consumption boundaries visible before product selection.
- Enables traceability from architecture intent to implementation, operational evidence, and consuming services.
Constraints
- The resulting SBB must fit the end user productivity ownership model and document the support, lifecycle, and service-management boundary.
- Security, privacy, logging, evidence, and compliance controls must be explicit enough to assess BIO2-aligned implementation where applicable.
- Access decisions must be explainable, auditable, and aligned with Zero Trust and least-privilege principles.
- SBBs must not bypass federation or central entitlement governance.
Service Description
This ABB offers a smart-access service that applies identity, context, device posture, and policy signals before access is granted to DC 3.0 services. It is consumed by solution architects, platform teams, and service owners as the capability contract for selecting and shaping SBBs.
The service description remains implementation-neutral: product selection, hosting pattern, detailed runbooks, and service levels belong in the mapped SBB and related ADRs.
Roadmaps
- Baseline: confirm scope, service ownership, constraints, and acceptance criteria for Smart Access.
- MVP: validate the mapped SBB implementation and record the selected support and lifecycle model.
- Next: add measurable service levels, evidence requirements, and roadmap dependencies once the SBB is selected.
Landing Zones
- Private cloud landing zone in ODC-Amsterdam, following the RWS ICT Strategy 2025-2030 private-cloud direction.
- Government cloud or external cloud landing zones only when the SBB documents the required control set, connectivity model, and data classification fit.
Interfaces
- OIDC, OAuth2, SAML, proxy, and policy decision interfaces.
- Identity governance, device posture, and logging integrations.
- Application and platform access enforcement points.
Dependencies
- Depends on federated-authentication for a supporting capability or integration boundary.
- Depends on identity-governance-and-administration for a supporting capability or integration boundary.
- Depends on security-operations-center for a supporting capability or integration boundary.
- Implemented by keycloak as currently mapped SBB traceability.
- Consuming ABB and SBB dependencies must be recorded as links when solution design identifies concrete upstream or downstream use.
EIRA Alignment
- EIRA reference: European Interoperability Reference Architecture (EIRA).
- EIRA definition mapping (PURI):
- Identity Management
- Access Management
- Implemented mapping in this vault:
- Active realizations: keycloak.
- Cross-reference register: EIRA Alignment Index.
Available SBB's
- keycloak - Keycloak is a candidate solution building block for the translated DC 3.0 ABB model. It remains candidate until the responsible architects confirm service ownership, support model, and acceptance criteria.