3

Zuulリバースプロキシユーティリティを使用してSpring Cloud(Angel.SR6)アプリケーションを設定しています。内部サービスポートを隠すためです。私のzuul(エッジ)サービスは8765ポートに公開されており、私の組織サービスは8083ポートにあります。セキュリティなしでアプリケーションにアクセスするとすべてがスムーズに進みます。http://localhost:8765/organization/organizationsはすべての組織でJSONを返します。ZuulリバースプロキシとKeycloakサーバ

しかし、認証目的でKeycloak SSO(OAuth2)サーバーを統合したいと考えています。 Spring Security adapterを組織サービスに追加し、http://localhost:8080/authで認証するように設定しました。 zuulがプロキシではなくリダイレ​​クトを実行する点を除いて、すべてうまくいっています。したがって、認証が成功すると、の代わりにhttp://localhost:8083/organizationsにリダイレクトされます。

enter image description here

keycloakアダプタは、それがトークンを検証するために、認証サーバーにリダイレクトを行い、そこからhttp://localhost:8083/sso/loginにおけるトークンの検証エンドポイントを作成しているためです。ここに私のブラウザの要求があります。認可サーバーがそれを確認すると、/organizationパスのリダイレクトが組織サービスに送信されるため、ロードされる最後のURLはhttp://localhost:8083/organizationsです。しかし、最初に要求されたURLを代わりにロードしたいと思います。

どの選択肢がありますか?

+0

私が言うことの一つは、zuulはそれ自身でリダイレクトを行わず、応答を転送するだけなので、下流のサービスがリダイレクトを送信すると、zuulはそれをブラウザに転送します。 – spencergibb

+0

@spencergibb、私は知っています。実際、問題はSSOサーバーにリダイレクトするログインエンドポイントが設定されたダウンストリームサービスにあります。 SSOサーバは、 '/ auth/realm/master?redirectUri = http:// localhost:8083/sso/login'のように、URLパラメータをurlパラメータとしてリダイレクトします。したがって、リダイレクトはSSOサーバーによってそのURLに実行され、最後の 'http:// localhost:8083/organizations'パスにリダイレクトされます。解決策はzuulサービスだけを保護することです。そのため、すべての要求をzuulにリダイレクトさせることになりますが、それは残りのサービスを公開したままにすることです。 –

答えて

1

最近、私は同じ問題を抱えています。 =クッキー、のSet-Cookie

  • Zuul

    でKeycloakFilterRouteを紹介
    class KeycloakFilterRoute extends ZuulFilter { 
    
    private static final String AUTHORIZATION_HEADER = "authorization"; 
    
    @Override 
    public String filterType() { 
        return "route"; 
    } 
    
    @Override 
    public int filterOrder() { 
        return 0; 
    } 
    
    @Override 
    public boolean shouldFilter() { 
        return true; 
    } 
    
    @Override 
    public Object run() { 
        RequestContext ctx = RequestContext.getCurrentContext(); 
        if (ctx.getRequest().getHeader(AUTHORIZATION_HEADER) == null) { 
         addKeycloakTokenToHeader(ctx); 
        } 
        return null; 
    } 
    
    private void addKeycloakTokenToHeader(RequestContext ctx) { 
        RefreshableKeycloakSecurityContext securityContext = getRefreshableKeycloakSecurityContext(ctx); 
        if (securityContext != null) { 
         ctx.addZuulRequestHeader(AUTHORIZATION_HEADER, buildBearerToken(securityContext)); 
        } 
    } 
    
    private RefreshableKeycloakSecurityContext getRefreshableKeycloakSecurityContext(RequestContext ctx) { 
        if (ctx.getRequest().getUserPrincipal() instanceof KeycloakAuthenticationToken) { 
         KeycloakAuthenticationToken token = (KeycloakAuthenticationToken) ctx.getRequest().getUserPrincipal(); 
         return (RefreshableKeycloakSecurityContext) token.getCredentials(); 
        } 
        return null; 
    } 
    
    private String buildBearerToken(RefreshableKeycloakSecurityContext securityContext) { 
        return "Bearer " + securityContext.getTokenString(); 
    } 
    
    Zuulにapplication.propertiesに

    zuul.sensitive-ヘッダを追加

    1. :私は、ことによってそれを解決してきました

      }

  • +0

    良いです。私はキークロークチームに私の問題を説明するためにGithubプロジェクトを作り上げ、開発チームメンバーの一人からプルリクエストを受け取りました。ここに[リンク](https://github.com/xtremebiker/zuul-keycloak-test/pull/1)がありますが、それはあなたの役に立つかもしれません。彼らの勧告に従って、私はzuulがステートレスなサービス(ベアラのみのもの)を隠すのは良いが、ユーザーが直接対話するものではないという結論に達した。ここではメーリングリストの[スレッド全体](http://lists.jboss.org/pipermail/keycloak-user/2016-May/006287.html)です。 –

    関連する問題