Zuul - Api Gateway Authentication

后端 未结 2 1215
清歌不尽
清歌不尽 2021-01-30 10:41

I want to introduce Zuul through Spring Cloud as an API Gateway in front of a few services.

I have some design doubts around Authentication. The Authentication would be

2条回答
  •  孤独总比滥情好
    2021-01-30 11:32

    • the Gateway would sit in front of many services

    What is the concern here ?

    • some services may expose endpoints which do not require authentication

    Spring Security has a permitAll()access rule

    • some services may expose endpoints which need a Session Id and some with a token", an arbitrary opaque value (for example downloading a file if you know a "hard to guess" url) In the API Gateway/Spring Security you can configure all the endpoints with their specific authentication requirements.

    Your Zuul proxy can have sessions. If you are using Spring Security OAuth 2.0 you can use ResourceServerSecurityConfigurer#stateless(false) and activate sessions with HttpSecurity#sessionManagement().sessionCreationPolicy(...) to create sessions everytime you receive a valid access token. A JSESSIONID Cookie will be placed in the HTTP Response.

    • how do you enforce the actual Service Teams to provide the required settings per downstream service?

    I'm not sure I understand the question here, don't you want to enforce security constraints at the API Gateway (zuul proxy) level ? or are you trying to have "security double checks" both on the proxy AND target application ?

    • how do you allow frequent Authentication settings changes in the Gateway (as per service needs) without having to stop the entire Gateway?

    Zuul allows you to add ZuulRoutes dynamically at runtime, if you use it as a standalone library that is. Wrapped in Spring Security, whose context is initialized once at startup time... I doubt you can easily alter the security config at runtime.

    EDIT following precisions by the OP in the comments : If your teams should be responsible for their security rules, having a centralized gateway is a contradiction by design.

    My interpretation of the microservice philosophy is that each application is standalone, and in charge of its full functional scope, and security / access control is part of it. You can easily verify tokens at the application level (by either making a call to the authorization server or using JWTs), with each application defining which scope is required for each resource. Spring Cloud already has an OAuth 2.0 starter, or you could easily create one if you use "plain" Spring Boot.

    That way you can deploy individual apps wherever you want (public cloud or on premise servers), without having to rely on upstream components for security or synchronize your gateway configuration deployments with other teams.

    The API Gateway thing is an easy temptation, but don't overlook the risks and constraints :

    • You won't be able to secure internal calls
    • You will have to rely on upstream network components, and take your applications' input for granted
    • Advanced access control rules may become a headache : how do you get the user's individual permissions, etc
    • You will have to synchronize configuration changes with other teams

提交回复
热议问题