i-core / werther Goto Github PK

That would be great if you include a full circle example with the Client Application with frontend and backend parts to the docker-compose.yaml part.

Thanks

Describe the bug
I'm struggling to build this container and enable HTTPS on werther. I'm happy that I have it working with HTTP, and now just needs to add the certificates and enable HTTPS.

I created a certificate and used it with hydra and switched that to https, and thought I also need to do this with werther. But I can't figure out how. I even put Nginx in front of it to handle the https and proxy to werther, but it still complains.

It's probably a lack of understanding on my part, but I'd be grateful for any pointers.

To Reproduce
Steps to reproduce the behavior:
My docker-compose.yml

version: "3"

services:
  hydra-client:
    image: oryd/hydra:v1.0.0-rc.12
    environment:
      HYDRA_ADMIN_URL: https://hydra:4445
    command:
      - clients
      - create
      - --skip-tls-verify
      - --id
      - ${CLIENT_ID}
      - --secret
      - ${CLIENT_SECRET}
      - --response-types
      - id_token,token,"id_token token"
      - --grant-types
      - implicit
      - --scope
      - openid,profile,email
      - --callbacks
      - ${CALLBACK}
      - --post-logout-callbacks
      - ${CALLBACK_LOGOUT}
    deploy:
      restart_policy:
        condition: none
    depends_on:
      - hydra
    healthcheck:
      test: ["CMD", "curl", "-f", "https://hydra:4445"]
      interval: 10s
      timeout: 10s
      retries: 10

  hydra:
    image: oryd/hydra:v1.0.0-rc.12
    environment:
      URLS_SELF_ISSUER: https://localhost:4444
      URLS_SELF_PUBLIC: https://localhost:4444
      URLS_LOGIN: http://localhost:8080/auth/login
      URLS_CONSENT: http://localhost:8080/auth/consent
      URLS_LOGOUT: http://localhost:8080/auth/logout
      WEBFINGER_OIDC_DISCOVERY_SUPPORTED_SCOPES: profile,email,phone
      WEBFINGER_OIDC_DISCOVERY_SUPPORTED_CLAIMS: name,family_name,given_name,nickname,email,phone_number
      DSN: memory
      HTTPS_TLS_CERT_PATH: ${PWD}/certs/ldap.crt
      HTTPS_TLS_KEY_PATH: ${PWD}/certs/ldap.key
    # command: serve all --dangerous-force-http
    command: serve all
    ports:
      - "4444:4444"
      - "4445:4445"
    deploy:
      restart_policy:
        condition: on-failure
    depends_on:
      - werther

  werther:
    image: icoreru/werther:v1.0.0
    environment:
      WERTHER_DEV_MODE: 1
      WERTHER_IDENTP_HYDRA_URL: http://hydra:4445
      WERTHER_ENDPOINTS: ${LDAP_URI}
      WERTHER_LDAP_ENDPOINTS: ${LDAP_URI}
      WERTHER_LDAP_BINDDN: ${LDAP_BINDDN}
      WERTHER_LDAP_BINDPW: ${LDAP_BINDPW}
      WERTHER_LDAP_BASEDN: ${LDAP_BASEDN}
      WERTHER_LDAP_ROLE_BASEDN: "ou=Roles,${LDAP_BASEDN}"
      WERTHER_LDAP_IS_TLS: ${LDAP_TLS}
      WERTHER_LDAP_ATTR_CLAIMS: "cn:name,sn:family_name,givenName:given_name,mail:mail"
    ports:
      - "8080:8080"
    deploy:
      restart_policy:
        condition: on-failure

Test URL

https://localhost:4444/oauth2/auth?client_id=test-client&response_type=token&scope=openid%20profile%20email&state=12345678

Docker Log Output

werther_1       | 2020-04-01T13:17:46.884Z      INFO    [email protected]/rlog.go:43  New request     {"requestID": "5583550f-ce4b-4d91-b925-25da7a46106d", "method": "GET", "url": "/auth/login?login_challenge=ff6b970735544db9a68f2fb4490054ec"}
werther_1       | 2020-04-01T13:17:46.885Z      INFO    identp/identp.go:128    Failed to initiate an OAuth2 login request      {"requestID": "5583550f-ce4b-4d91-b925-25da7a46106d", "error": "failed to initiate login request: invalid character 'C' looking for beginning of value", "errorVerbose": "invalid character 'C' looking for beginning of value\nfailed to initiate login request\ngithub.com/i-core/werther/internal/hydra.(*LoginReqDoer).InitiateRequest\n\t/opt/build/internal/hydra/login.go:28\ngithub.com/i-core/werther/internal/identp.newLoginStartHandler.func1\n\t/opt/build/internal/identp/identp.go:116\nnet/http.HandlerFunc.ServeHTTP\n\t/usr/local/go/src/net/http/server.go:1995\ngithub.com/i-core/routegroup.(*Router).handler.func1\n\t/go/pkg/mod/github.com/i-core/[email protected]/routegroup.go:65\ngithub.com/julienschmidt/httprouter.(*Router).ServeHTTP\n\t/go/pkg/mod/github.com/julienschmidt/[email protected]/router.go:334\ngithub.com/i-core/rlog.NewMiddleware.func1.1\n\t/go/pkg/mod/github.com/i-core/[email protected]/rlog.go:48\nnet/http.HandlerFunc.ServeHTTP\n\t/usr/local/go/src/net/http/server.go:1995\ngithub.com/justinas/nosurf.(*CSRFHandler).handleSuccess\n\t/go/pkg/mod/github.com/justinas/[email protected]/handler.go:179\ngithub.com/justinas/nosurf.(*CSRFHandler).ServeHTTP\n\t/go/pkg/mod/github.com/justinas/[email protected]/handler.go:136\nnet/http.serverHandler.ServeHTTP\n\t/usr/local/go/src/net/http/server.go:2774\nnet/http.(*conn).serve\n\t/usr/local/go/src/net/http/server.go:1878\nruntime.goexit\n\t/usr/local/go/src/runtime/asm_amd64.s:1337", "challenge": "ff6b970735544db9a68f2fb4490054ec"}
werther_1       | 2020-04-01T13:17:46.885Z      DEBUG   [email protected]/rlog.go:49  The request is handled  {"requestID": "5583550f-ce4b-4d91-b925-25da7a46106d", "httpStatus": 500, "duration": "1.012755ms"}
werther_1       | 2020-04-01T13:17:46.948Z      INFO    [email protected]/rlog.go:43  New request     {"requestID": "8a455c6d-ef60-4d2e-ac01-d95d5227fa93", "method": "GET", "url": "/favicon.ico"}
werther_1       | 2020-04-01T13:17:46.948Z      DEBUG   [email protected]/rlog.go:49  The request is handled  {"requestID": "8a455c6d-ef60-4d2e-ac01-d95d5227fa93", "httpStatus": 404, "duration": "5.242µs"}

Desktop (please complete the following information):

• OS: Debian Buster
• Browser Firefox
• Version 74.0

Is your feature request related to a problem? Please describe.
The readme describes that the role claim generated by werther has the following format:

{
    "https://github.com/i-core/werther/claims/roles": {
        "App1": ["role1", "role2"],
    }
}

However, I believe that there exist several apps that need the following format instead:

{
    "https://github.com/i-core/werther/claims/roles": ["role1", "role2"]
}

Describe the solution you'd like
I am not sure whether the following is the best solution, but I propose the following. For each app (e.g. App1), also add a claim

{
    "https://github.com/i-core/werther/claims/roles/App1": ["role1", "role2"]
}

Describe alternatives you've considered

• Or just flatten the roles dictionary.
• Or use a different scope for each app.

Additional context

I'm trying to set up Kantega SSO for Confluence, using the OpenID Connect protocol.

Hello, I'm trying to run this using docker-compose, but I was failed because 3000 port is not found anywhere.
So where is the react app located, should I build my own?

Is your feature request related to a problem? Please describe.
I am using Hydra/Werther with many different oauth2/oidc consumers, when users have to login to those consumers they have to put in their username/password individually for every consumer.

Describe the solution you'd like
I would like the werther login to persist user sessions for a configurable amount of time.

Describe alternatives you've considered
I've looked at and adjusted the various environment settings but have yet to figure out a fix to this issue

Hello,

I'm having some problems getting this working with an outside ldap server (openldap), I get an incorrect username or password error when logging in but I'd like to see some debug information so I can determine what the root cause is.

Right now I'm thinking it could be one of three things.

1. The ldap property (cn=user or uid=user) isn't what is being used to authenticate

2. The encryption algorithm that I've used to encrypt the password doesn't match what the ldap client is using.

3. Another configuration problem that I'm not yet seeing.

Describe the bug

I have WERTHER_WEB_BASE_PATH set to /werther/ which works correctly to show the UI.

There are two cases that can happen:

• Successful login: Everything works as expected
• Invalid Credentials: everything seems to work correctly, the user is redirected to the correct page, but this time, if I send the correct credentials the base path is no longer respected, and instead of POST-ing to /werther/auth/login, it POSTs to /auth/login

To Reproduce
Steps to reproduce the behavior:

1. Set WERTHER_WEB_BASE_PATH
2. Navigate to the new URL
3. Put in invalid credentials
4. Put in valid credentials <- this will redirect wrongly

Expected behavior

The base path is respected even on retries

Desktop (please complete the following information):

• OS: macOS
• Browser: Firefox
• Version: 121.0b6

Additional context
Add any other context about the problem here.

Hi,
thanks for providing this good hydra companion :)
I'd like to install it for some french users but it will be easier for them if we can translate UI.
I can work on it, but I don't know anything about i18n stuff with golang, do you have any opinion? A library of choice?

Describe the bug
werther uses go-ldap v2 which has problems running on my arm device giving error like
level":"info","ts":1586183401.5116482,"caller":"[email protected]/rlog.go:43","msg":"New request","requestID":"92f290e1-fe52-4a48-88ce-238ffeb71372","method":"POST","url":"/auth/login?login_challenge=c4d68ac1df8e41ad9436f5f23476f9d0"} 2020/04/06 14:30:01 ldap: recovered panic in processMessages: runtime error: invalid memory address or nil pointer dereference {"level":"info","ts":1586183401.5147185,"caller":"identp/identp.go:181","msg":"Failed to authenticate a login request via the OAuth2 provider","requestID":"92f290e1-fe52-4a48-88ce-238ffeb71372","error":"failed to login to a LDAP woth a service account: LDAP Result Code 200 \"Network Error\": ldap: response channel closed","errorVerbose":"LDAP Result Code 200 \"Network Error\": ldap: response channel closed\nfailed to login ...

To Reproduce
run current version of werther on an arm device and try to do an ldap auth request through Login page

Additional context
This is common issue caused by go-ldap v2 and can be fixed by updating werther to use go-ldap v3.

for reference similar issues are following
hashicorp/vault#6135
portainer/portainer#3244
go-ldap/ldap#195

the objectClass for the roles is hardcoded and doesn't find the roles for objectClass=groupofnames | groupOfUniqueNames

in ldapclient.go