How Mastodon Configured Login Using SSO - docker-compose

How Mastodon configure login using SSO, such as openid with keycloak? I search in Github and configure Mastodon follow this guide, but it doesn't work.
This is my environment variable:
OIDC_ENABLED=true
OIDC_DISPLAY_NAME=SSO
OIDC_AUTH_ENDPOINT=https://SSO_URL/realms/mastodon/.well-known/openid-configuration
OIDC_ISSUER=https://SSO_URL/realms/mastodon
OIDC_DISCOVERY=true
OIDC_SCOPE="openid,profile"
OIDC_UID_FIELD=uid
OIDC_CLIENT_ID=masto
OIDC_REDIRECT_URI=https://MASTODON_URL/auth/auth/openid_connect/callback
OIDC_SECURITY_ASSUME_EMAIL_IS_VERIFIED=true
OIDC_CLIENT_SECRET=***
I checked the error log via this command but it is empty.
docker-compose logs | grep ERROR
Even the text of the SSO button has not changed.
There is the screenshot of sso button

my config:
OIDC_ENABLED=true
OIDC_DISPLAY_NAME=My IDM
OIDC_DISCOVERY=true
OIDC_ISSUER=https://<keycloak_url>/auth/realms/<real>
OIDC_AUTH_ENDPOINT=https://<keycloak_url>/auth/realms/<real>/.well-known/openid-configuration
OIDC_SCOPE=openid,profile,email
OIDC_UID_FIELD=preferred_username
OIDC_CLIENT_ID=<client id>
OIDC_CLIENT_SECRET=<client secret>
OIDC_REDIRECT_URI=https://<mastodon URL>/auth/auth/openid_connect/callback
OIDC_SECURITY_ASSUME_EMAIL_IS_VERIFIED=true
Tested with Mastondo 3.5.3 and Keycloak 7.0.1
Maybe, only change yours OIDC_SCOPE and OIDC_UID_FIELD environments values.

I cannot comment but Erik suggestion was really good, here is our minimal configuration using Keycloak in discovery mode:
# Enable OIDC
OIDC_ENABLED=true
# Name your button (ignored in current 3.5.3 but fix is done in upcoming releases)
OIDC_DISPLAY_NAME=Login with MySSO
# Where to find your Keycloak OIDC server
OIDC_ISSUER=https://<keycloak_domain>/realms/<my_realm>
# Use discovery to determing all OIDC endpoints
OIDC_DISCOVERY=true
# Scope you want to obtain from OIDC server
OIDC_SCOPE=openid,profile,email
# Field to be used for populating user's #alias
OIDC_UID_FIELD=preferred_username
# Client ID of the client you configured for Mastodon in Keycloak
OIDC_CLIENT_ID=<keycloak_client_id>
# Client secret of the client you configured for Mastodon in Keycloak (in production, use secrets Docker secrets in our case)
OIDC_CLIENT_SECRET=<keycloak_client_secret>
# Where OIDC server should come back after authentication
OIDC_REDIRECT_URI=https://<mastodon_domain>/auth/auth/openid_connect/callback
# Assume emails are verified by the OIDC server
OIDC_SECURITY_ASSUME_EMAIL_IS_VERIFIED=true
So only difference is that we didn't have to add the OIDC_AUTH_ENDPOINT thanks to OIDC discovery.

Related

AWS OpenSearch Goggle Workspace SAML authentications

I have configured a custom SAML app in Google Workspace and configured AWS Opensearch to use SP-initiated SSO.
I am able to access OpenSearch via the URL but I get the following error
Missing Role
No roles available for this user, please contact your system administrator.
I guess there are some SAML attribute mapping and group set up that are required. I've created an opensearch group in Google for users that I wish to have access.
I think the following AWS Opensearch parameters require a value
SAML master backend role
Subject key
Roles key
From what I can see, the issue is that you need to create a custom attribute inside the Admin console of Google Workspace with the "roles" for AWS Opensearch.
You can also read this information in the AWS documentation.
This was resolved using and IdP initiated authentication flow instead. The links posted in answers above helped us implement this.

How to set up gcloud to use credentials from identity federation with OIDC

On this page, it is explained how to set up workload identity federation and how to use it with the (Python) client libraries.
This is done by setting the GOOGLE_APPLICATION_CREDENTIALS environment variable. However, this does not work for the gcloud SDK itself, as this uses other methods for configuring credentials.
Normally, using a service account key, one would run gcloud auth activate-service-account [ACCOUNT] --key-file=KEY_FILE, but this does not work for workload identity federation credentials.
How can you set up gcloud to use workload identity federation from an OIDC identity provider?
Starting from gcloud SDK version 363.0.0, this can now be done using the --cred-file flag:
gcloud auth login --cred-file=/path/to/workload/identity/config/file
(You might need to add a --brief flag as well)
Note: earlier versions might work as well as it was already present but undocumented before 363.0.0
Source: https://cloud.google.com/sdk/docs/release-notes#36300_2021-11-02

"Unexpected error when authenticating with identity provider" error when Keycloak broker is configured as a client to another Keycloak instance

I am getting an error when I try to login to Keycloak by using it as a broker.1 I am using credentials from another keycloak instance to login. So far, I am redirected to the correct login page but after entering my credentials I receive an error.
I have set up Keycloack Identity Brokering on computer 1 by following the basic steps.2 I have used the generated redirection URI of the broker to register a new client on computer 2 in another Keycloak instance.3 The client configuration present on computer 2 4 is then used to fill in Authorization URL, Token URL, Client ID and Client Secret on the Identity Broker on Computer 1. 5
I may be leaving important fields missing. Pictures are attached for reference.
I have changed some settings to get the broker to work with the other Keycloak instance. I am now sending client secret as basic auth with signed verification off. I have also enabled back-channel logout. Hope this helps someone else.
I fixed this problem by regenerating the client secret on the identity provider side and using it on keycloak. The keycloak realm data import was not working very well for me apparently.
In my case I needed to empty the hosted domain field in the "Identity providers" configuration of my Google identity provider in Keycloak.
See also:
Keycloak Google identity provider error: "Identity token does not contain hosted domain parameter"

Rancher Keycloak authentication setup

I'm trying to setup Rancher to use Keycloak as an authentication provider and following the setups laid out here. The last step says to export the metadata in the SAML Metadata IDPSSODescriptor format but I only see SAML Metadata SPSSODescriptor as an option. I've tried using that but authentication isn't working - it opens another window with the same Keycloak setup page when clicking the Authenticate with Keycloak button to validate the setup. There are no errors in the Docker logs for either the Rancher or Keycloak containers when running docker logs CONTAINER command.
I'm wondering if I need to do something specific to setup Keycloak as an IDP to get the correct metadata option but I can't find anything in their documentation.
For Keycloak 6.0 and up, along with the location of the IDPSSODescriptor even its format has changed. This doc explains how that can be edited to be used by Rancher
From the Installation tab, choose the SAML Metadata IDPSSODescriptor format option and download your file.
Or you can directly visit Keycloak URL with IDPSSODescriptor metadata:
https://<keycloak-domain>/auth/realms/<realm>/protocol/saml/descriptor

Using AAD for client auth still requires cert

I've created a new cluster with AAD for client auth using ARM by following the document linked to below. The cluster deployed and my app works fine but my browser is still asking me to select an X.509 certificate when I attempt to use the SF Explorer at: https://mycluster.northcentralus.cloudapp.azure.com:19080/Explorer
I thought when I hooked up Azure AD that the client cert would no longer be needed. Note that I do see that the SF Explorer displays my name in the upper right (with a logout option), indicating to me it's using AAD.
So, what's up with this? Any ideas?
https://azure.microsoft.com/en-us/documentation/articles/service-fabric-cluster-creation-via-arm/
That happens if there's an issue with AAD authentication - the cluster will fallback to certificate authentication.
If SF Explorer isn't re-directing to an AAD login page at all, then double-check that the web application reply URL in the AAD cluster application matches the SF Explorer URL.
If the re-direction is happening and AAD login was successful, then double-check that the AAD cluster application has the expected user roles and that your user has been assigned a role.