Uploaded image for project: 'WildFly Elytron'
  1. WildFly Elytron
  2. ELY-2136

Configuring client to authenticate with remote Wildfly

    XMLWordPrintable

Details

    • Clarification
    • Resolution: Not a Bug
    • Major
    • None
    • None
    • Authentication Client
    • None
    • Undefined

    Description

      Some assistance needed:

       

      I am trying to configure a jax-rs based web application to invoke EJB services from a remote Wildfly application as per the attached design.
       

      The part which is causing me issues is to ensure the calls to the EJB service are done having authenticated the user with the service, handled by WildflyAuthenticationFilter. Having followed the Programmatic approach the current sample code is as follows:

        @Override
        public void doFilter( ServletRequest req, ServletResponse response, FilterChain chain)
            throws IOException, ServletException {
          HttpServletRequest request=(HttpServletRequest)req;
          String authorizationHeader=request.getHeader("Authorization");
          if(authorizationHeader==null) {
            chain.doFilter(req, response);
          } else {
            String token=authorizationHeader.substring("Bearer".length()).trim();
            AuthenticationConfiguration config=AuthenticationConfiguration.empty()
              .useProviders(() -> new Provider[] { new WildFlyElytronSaslPlainProvider() })
              .setSaslMechanismSelector(SaslMechanismSelector.NONE.addMechanism("PLAIN"))
              .usePassword(token)
              .useRealm("myccustomrealm2");
              AuthenticationContext context=AuthenticationContext.empty().with(MatchRule.ALL, config);
              Runnable runnable= new Runnable() {
            @Override
            public void run() {
              chain.doFilter(req,response);
            }
          };
          context.run(runnable);
          }
        }
      

      The relevant bits of wildfly server configuration are as follows:

      /subsystem=elytron/custom-realm=myccustomrealm1:add(module=mymodule, class-name=com.example.MyCustomRealm1, configuration={\
        configProp = "my config value"\
      })
      /subsystem=elytron/custom-realm=myccustomrealm2:add(module=mymodule, class-name=com.example.MyCustomRealm2, configuration={\
        configProp = "my config value 2"\
      })
      /subsystem=elytron/distributed-realm=final-realm:add(realms=[myccustomrealm1, myccustomrealm2])
      
      /subsystem=elytron/security-domain=mysecuritydomain:add(realms=[{realm=myccustomrealm1,role-decoder=NAME-from-roles-attribute}, {realm=myccustomrealm2,role-decoder=NAME-from-roles-attribute}], default-realm=myccustomrealm1, permission-mapper=default-permission-mapper)
      
      /subsystem=elytron/sasl-authentication-factory=my-sasl:add(sasl-server-factory=elytron, security-domain=mysecuritydomain, mechanism-configurations=[\
        {mechanism-name=PLAIN }\
        {mechanism-name=ANONYMOUS }\
      ])
      /subsystem=remoting/http-connector=http-remoting-connector:write-attribute(name=sasl-authentication-factory, value=my-sasl)
      

      So the problems I have encountered are:

      1. Is the SASL "PLAIN" mechanism the right one to use? I only want to pass the token to the backend as it is (without any hashing) and the implementation com.example.MyCustomRealm2 to decode it, validate it and work out who the user is and what roles it has?
        • As a workaround, I could get the filter to also decode the token beforehand, find out who the user is and pass it together with the token
      2. Having worked around that, it then seems that "useRealm" does not have any effect. When the call is made, it is only "myccustomrealm1" being invoked.

      Any guidance will be appreciated.

      Attachments

        Activity

          People

            dvilkola@redhat.com Diana Krepinska
            avscta Alex Stoia (Inactive)
            Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved: