{"data":{"id":"SP-004","slug":"soa-publication-and-location","joomla_id":189,"title":"SOA Publication and Location Pattern","description":"Security architecture for protecting service registries and discovery mechanisms in service-oriented architectures. Addresses access control, change management, and certification of services published to UDDI, WSDL, and modern API registries.","url":"https://www.opensecurityarchitecture.org/patterns/sp-004","metadata":{"release":"26.02","classification":"Application & Operations","status":"published","type":"pattern","datePublished":"2008-01-22","dateModified":"2026-02-06","authors":["Aurelius","Vitruvius"],"reviewers":[]},"diagram":{"svg":"/images/patterns/08_02_13_Pattern_004_SOA_Registration_and_location.svg","png":"/images/OSA_images/patterns/08_02_13_Pattern_004_SOA_Registration_and_location.png"},"content":{"description":"Service registries are the phone book of a service-oriented architecture. They publish service endpoints, interface contracts (WSDL, OpenAPI), and metadata that consumers rely on to discover and bind to services at runtime. If an attacker can modify a registry entry, they can redirect traffic to a malicious endpoint, inject a compromised service into a composite workflow, or exfiltrate data by impersonating a legitimate service provider. Protecting the publication and location infrastructure is therefore foundational to SOA integrity.\n\nThe pattern applies wherever services are registered for discovery -- whether in a traditional UDDI registry, an enterprise service bus catalogue, a modern API gateway, or a Kubernetes service mesh. In each case, the core problem is the same: who is allowed to publish a service definition, who is allowed to discover and consume it, and how do you ensure that what was published has not been tampered with. The pattern draws a trust boundary around the registry itself and the publication lifecycle.\n\nAccess control is the first layer. Not every developer or system account should be able to publish or modify service entries. Publication rights must be restricted to authorised roles, typically service owners or release managers, with separation of duties between those who develop a service and those who approve its publication. Discovery access may also need restriction: internal-only services should not be visible to external consumers, and sensitive service metadata (security policies, endpoint credentials) must be protected even from authorised consumers who do not need that level of detail.\n\nChange control is the second layer. Service interface changes -- adding a new operation, modifying a schema, deprecating a version -- must follow a controlled change management process. Uncontrolled changes to a service contract can break downstream consumers, introduce security vulnerabilities, or violate compliance requirements. Configuration management ensures that every change to a registry entry is tracked, reviewed, and reversible.\n\nCertification and assessment provide the third layer. Before a service is published to a production registry, it should be assessed against security standards: input validation, authentication requirements, authorisation model, error handling, and logging. This security certification step prevents vulnerable or non-compliant services from being discoverable and consumable by other systems in the architecture.","keyControlAreas":["Registry Access Control (AC-01, AC-03, AC-05): Access to the service registry must be governed by formal policy (AC-01) that defines who can publish, modify, and discover service entries. Access enforcement (AC-03) ensures that only authorised accounts can write to the registry, with role-based controls distinguishing between service publishers, administrators, and consumers. Separation of duties (AC-05) prevents the same individual from both developing a service and approving its publication to the production registry. In practice, implement RBAC on the registry platform itself, restrict administrative access to a small group, and enforce approval workflows for any new or modified service publication.","Audit and Accountability (AU-01): Every interaction with the service registry must be logged -- publications, modifications, deletions, and discovery queries. Audit policy and procedures (AU-01) should define what events are captured, how long logs are retained, and who reviews them. Registry audit trails are essential for forensic investigation when a service entry is tampered with or when an unauthorised service appears. Modern API gateway platforms provide built-in audit logging; for legacy UDDI registries, ensure that platform-level logging is enabled and forwarded to a central SIEM.","Security Assessment and Certification (CA-01, CA-04): Before a service is published to a production registry, it must undergo security assessment (CA-01) against defined criteria. Security certification (CA-04) formalises this gate: a service that has not passed security testing -- covering input validation, authentication, authorisation, error handling, and transport security -- should not be registerable in production. This prevents vulnerable services from becoming discoverable and consumable. Automate where possible using security scanning in CI/CD pipelines, with the registry publication step gated on a passing security assessment.","Configuration and Change Management (CM-01, CM-03): Service registry entries are configuration items that must be managed under formal change control. Configuration management policy (CM-01) should cover the registry as critical infrastructure. Change control (CM-03) requires that modifications to service definitions -- new versions, schema changes, endpoint updates, deprecations -- follow a documented process with impact analysis, approval, and rollback capability. This is especially important for service contracts that other systems depend on: an uncontrolled breaking change can cascade failures across composite services.","Lifecycle and Engineering Principles (SA-03, SA-08): Services in the registry have a lifecycle -- development, testing, staging, production, deprecation, retirement. Life cycle support (SA-03) ensures that security is addressed at each stage and that deprecated services are removed from the registry in a timely manner to reduce attack surface. Security engineering principles (SA-08) should be applied to the registry architecture itself: defence in depth, least privilege, fail-secure defaults, and separation of production and non-production registries. Do not expose development or test service entries in production discovery; maintain separate registry instances or namespaces per environment."],"assumptions":"The service registry is a shared, network-accessible component that multiple systems rely on for service discovery. Service interfaces (WSDL, OpenAPI specs) represent implicit contracts between providers and consumers; modifying them has downstream impact. The organisation uses some form of centralised or federated service catalogue, whether a traditional UDDI registry, API gateway, service mesh, or equivalent. Certificate-based or token-based authentication is available for machine-to-machine registry access.","typicalChallenges":"Enforcing service contracts remains difficult because there are few mature standards for automated contract validation and policy enforcement. While tooling exists for API gateway policy enforcement and contract testing, many organisations still rely on manual review processes that do not scale as the number of services grows. Legacy SOA registries (UDDI) often lack fine-grained access control, making it hard to restrict publication rights without custom development. In microservices architectures, service discovery is often automated through service meshes (Istio, Consul), which introduces new attack surfaces around the mesh control plane. Maintaining consistency between registry entries and actual deployed service configurations is an ongoing operational challenge, particularly when deployments are automated but registry updates are not.","indications":"Use this pattern whenever your architecture includes a service registry, API catalogue, or service mesh that mediates discovery between service providers and consumers. It is particularly important when you can distinguish between trusted and untrusted callers -- for example, internal services versus partner-facing APIs. Apply it when services are composed dynamically at runtime based on registry lookups, as a compromised registry entry in this context enables man-in-the-middle attacks at the application layer. Also applicable when regulatory or compliance requirements mandate traceability of service publication and change history.","contraIndications":"If all potential service consumers are equally trusted and operate within a single, tightly controlled environment with no external exposure, the overhead of full registry protection may not be justified. Very small deployments with a handful of static services and no dynamic discovery may not benefit from the full pattern, though basic access control on service definitions is still recommended. This pattern does not address end-to-end message security between services -- for that, see the SOA Internal Service Usage pattern (SP-005).","threatResistance":"This pattern addresses threats from rogue employees who could publish a malicious service to intercept or manipulate transactions, rogue developers who could modify a service endpoint to redirect traffic, and rogue suppliers who could register an unauthorised service impersonating a legitimate provider. It mitigates unauthorised service publication, registry tampering, and service impersonation attacks. The combination of access control, separation of duties, change management, and security certification creates multiple barriers that an attacker must overcome to successfully compromise the service discovery infrastructure. It does not protect against threats at the transport or message layer, which are addressed by complementary patterns."},"examples":{"API gateway and management platforms":["Kong Gateway with RBAC-controlled service registration and plugin-based policy enforcement","Apigee API Management with developer portal access controls and API product lifecycle management","AWS API Gateway with IAM-based publication controls and stage-based deployment","Azure API Management with publisher portal role separation and API versioning"],"Service mesh and discovery":["Kubernetes service discovery with RBAC-controlled service and ingress definitions","Istio service mesh with AuthorizationPolicy controlling service-to-service visibility","HashiCorp Consul with ACL-protected service registration and intention-based access control","Netflix Eureka with secured registration endpoints and self-preservation mode"],"Legacy SOA registries":["IBM WebSphere Service Registry with role-based governance policies","Oracle Service Registry (formerly BEA AquaLogic) with UDDI access control","WSO2 API Manager with lifecycle state management and approval workflows"],"Contract testing and validation":["Pact contract testing framework for consumer-driven contract verification","Spectral OpenAPI linting for automated API security rule checking before publication","Postman API governance with schema validation and security policy checks"],"Developing Areas":["API gateways have evolved from simple traffic proxies into full security enforcement points, but the convergence of gateway, service mesh, and API management functionality is creating architectural confusion. Organisations struggle to determine where to enforce authentication, rate limiting, and authorisation when Kong, Istio, and Apigee all offer overlapping capabilities. No industry consensus exists on the optimal layering, leading to either duplicated enforcement (performance overhead) or gaps where each layer assumes the other handles security.","Service mesh security -- particularly mTLS enforcement and fine-grained authorisation policies between services -- is maturing rapidly but operational complexity remains high. Istio, Linkerd, and Consul Connect each take different approaches to certificate lifecycle management, policy definition, and sidecar proxy architecture. Organisations adopting service meshes report 6-12 month learning curves before security policies are consistently enforced, and debugging authentication failures in mesh environments requires specialist skills that are in short supply.","API-first design principles are pushing service discovery complexity into new territory. As organisations expose hundreds of internal APIs through developer portals, the challenge of maintaining accurate, security-classified API catalogues becomes a governance problem rather than a technical one. Emerging API governance platforms attempt to auto-discover APIs from traffic analysis and code repositories, but accuracy rates for security classification remain below 70%, requiring significant manual curation to prevent sensitive internal APIs from being exposed through self-service portals."]},"references":[{"title":"NIST SP 800-95: Guide to Secure Web Services","url":"https://csrc.nist.gov/publications/detail/sp/800-95/final","note":"Comprehensive NIST guidance on securing web services including registry protection, service discovery, and UDDI security considerations."},{"title":"OWASP API Security Top 10","url":"https://owasp.org/API-Security/","note":"OWASP project cataloguing the most critical API security risks, directly relevant to service publication and discovery attack surfaces."},{"title":"NIST SP 800-53 Rev 5: Security and Privacy Controls (AC, CM, CA families)","url":"https://csrc.nist.gov/publications/detail/sp/800-53/rev-5/final","note":"Authoritative source for the access control, configuration management, and security assessment controls referenced in this pattern."},{"title":"Kubernetes RBAC Documentation","url":"https://kubernetes.io/docs/reference/access-authn-authz/rbac/","note":"Practical guide to implementing role-based access control for service registration and discovery in Kubernetes environments."},{"title":"Istio Security: Authorization Policy","url":"https://istio.io/latest/docs/concepts/security/","note":"Service mesh security model including service identity, authentication, and authorisation for modern microservices discovery."}],"relatedPatterns":["SP-002","SP-005","SP-008","SP-011","SP-016"],"relatedPatternNames":["Server Module","SOA Internal Service Usage","Public Web Server","Cloud Computing","DMZ Module"],"threats":[{"id":"T-SR-001","name":"Unauthorised Service Publication","mitigatedBy":["AC-01","AC-03","AC-05"]},{"id":"T-SR-002","name":"Registry Entry Tampering","mitigatedBy":["AC-03","CM-03","AU-01"]},{"id":"T-SR-003","name":"Service Impersonation via Endpoint Redirection","mitigatedBy":["CA-04","CM-03","AC-03"]},{"id":"T-SR-004","name":"Rogue Developer Publishing Malicious Service","mitigatedBy":["AC-05","CA-04","CM-03"]},{"id":"T-SR-005","name":"Rogue Supplier Injecting Unauthorised Service","mitigatedBy":["CA-01","CA-04","AC-01","AC-03"]},{"id":"T-SR-006","name":"Discovery of Sensitive Service Metadata by Unauthorised Consumer","mitigatedBy":["AC-03","AC-01"]},{"id":"T-SR-007","name":"Uncontrolled Service Contract Change Causing Cascading Failures","mitigatedBy":["CM-01","CM-03","SA-03"]},{"id":"T-SR-008","name":"Stale or Deprecated Service Exploited After End of Life","mitigatedBy":["SA-03","CM-03","SA-08"]}],"controls":[{"id":"AC-01","name":"Policy and Procedures","family":"AC","emphasis":"important"},{"id":"AC-03","name":"Access Enforcement","family":"AC","emphasis":"critical"},{"id":"AC-05","name":"Separation of Duties","family":"AC","emphasis":"critical"},{"id":"AU-01","name":"Policy and Procedures","family":"AU","emphasis":"important"},{"id":"CA-01","name":"Policy and Procedures","family":"CA","emphasis":"important"},{"id":"CA-04","name":"Security Certification","family":"CA","emphasis":"critical"},{"id":"CM-01","name":"Policy and Procedures","family":"CM","emphasis":"important"},{"id":"CM-03","name":"Configuration Change Control","family":"CM","emphasis":"critical"},{"id":"SA-03","name":"System Development Life Cycle","family":"SA","emphasis":"important"},{"id":"SA-08","name":"Security and Privacy Engineering Principles","family":"SA","emphasis":"standard"}],"controlFamilySummary":{"AC":3,"AU":1,"CA":2,"CM":2,"SA":2}}}