phish108 / authomator Goto Github PK

The checker should have scope policies to provide fine grained access to the different methods and URLs

Currently the user scopes are part of the configuration. This makes things extremely inflexible.

Allow for storage backends for user scopes. authomator needs only read access to these backends. Management of user scopes can be entirely externalised.

A storage backend should return for a provided ( login | backend ) pair the corresponding scope.

Scope Management can be located:

• memory/configuration (source, Key value pairs)
• service (url, access info, method, extra data, userkey, scopekey)

others?

• redis (service, access info, namespace, userkey)
• sqllite (name, relation, usercol, scopecol)
• mysql/maria sql (name, access info, relation, usercol, scopecol)
• LDAP/AD (name, access info, baseCN, query, userkey, scopekey)

In order to have maximum flexibility for customization, the UI should be separate from the service. The service should provide only data endpoints

• info endpoint - provides the available issuers
• User endpoint - provides the user info
• Admin/issuer - provide admin details about the issuers
• Admin/sessions - provide admin details about the current sessions (user+issuer)
• Admin/users - configure the user scopes and origins
• Admin/paths - allows checker to run against all URLs and use internal configs rather then server configs.
• Internal and server configs must word side by side
• The admin/* endpoints are checker protected.
• The UI is checker protected
• The UI has a separate repo/deployment
• The ui uses the service endpoints to configure itself.

This separation gives more flexibility to integrate auth functions into a more complex application. An application can ask the endpoints to receive or update certain functions of the UI.

• rest api
• Gql api
• Ldiff api
• yaml api
• Json api

The user management must not be part of authomator but provided by a separate backend/subsystem.

the new fetch API is better suited for this task

the resolve function of config/index.mjs needs to be context aware. If a reference is made, it should be treated in the context of the containing file.

This makes the logic more complex, but also more user friendly.

If we have two sites with different CNAMEs, then authomator works only for one of them.

The service needs to register, which request URL has been posted.

This needs a bit of adaptation for different sites. The only common element across sites are the ports of the services.

Our configuration may change to:

common: 
    frontend: 
        port: 8080
    checker:
        port: 8081
sites: 
  - common:
          base_url: "https://site1" // some host url for the baseline for all requests
          entrypoint: /auth/ // the entrypoint for the authomator
          success_target: "/home/" // where to point users after successfull authentication
    backend: 
          backendname:
              name: Display Name
              icon: FontAwesomeIcon
              type: github
              baseurl: https://github.com
              client_id: githubs client_id
              client_secret: githubs client_secret
    user:
       - login: username
         scope: internal user scope for acl
  - common: 
          base_url: "https://site2" // some host url for the baseline for all requests
          entrypoint: /auth/ // the entrypoint for the authomator
          success_target: "/success/" // where to point users after successfull authentication
    backend: 
          backendname:
              name: Display Name
              icon: FontAwesomeIcon
              type: github
              baseurl: https://github.enterprise.com
              client_id: githubs client_id
              client_secret: githubs client_secret
    user:
       - login: otherusername
         scope: internal user scope for acl

Instead of having locally stored session id to validate against, we should issue JWT with the session information.

This would allow to store information about the user, scope and the authorised site.

This token should be a JWS+JWE, so it is signed by us and encrypted for us.

use the modern mjs capabilities of nodejs for future compliance and better code isolation

Scope handling needs to be more flexible.

It should be possible to allow all users with certain IT claims to receive a scope without being explicitly configured.

Examples:

Give access to all users with a zhaw.ch address, while excluding students (who would have a @students.zhaw.ch address).

- match: @zhaw.ch
  target: eduid
  claim: email
  scope: user

Give access to all users who belong to an organization:

- match: ZHAW
  target: eduid
  claim: homeorg
  scope: user

Load the configuration from backend.

The configuration includes

• basic settings

  • urls
  • timeouts
  • backends

• auth services

• yaml api

• Json api

• Gql api

• Rest api

• Ldap api

• create autho-admin scope
• Configure User Backend
• Configure Frontends
• Configure Targets
• Monitor active sessions

Add endpoints via configuration.

Test with

• MS AD
• EduID

If an IDP did not provide a refresh_token we must initiate an interactive refresh instead of failing.

via sustainability-zhaw/.github#16

Towards the bottom of the documentation for the

reverse_proxy directive there is a remark on intercepting responses from the upstream.

This should allow us to send status codes instead of redirections. This would allow us to simplify the code and move parts of the configuration to caddy.

forward_auth /api/* autho_autho:8081 {
    uri /
   
    @401-403response {
        status 401,403
    }

   handle_response @401-403response {
        redir * /auth/
   }
}

reverse_proxy /auth/* autho_autho:8080 {

    # handles redirects when needed
    # autho will only send status codes 
    @401-403response {
        status 204,401,403
    }

   handle_response @401-403response {
       redir * /auth/
   }
}

It seems that the aud_method option for endpoints never arrives with the designated target handler.

https://www.npmjs.com/package/winston