🇺🇸United States @minkahb

Hi,

I am able to successfully connect to the Apigee Management API with this module using OAuth.

However, I noticed that if the token expires, traffic does not reach the Apigee Management API until the machine user token is manually refreshed as per this Apigee documentation: 

https://docs.apigee.com/api-platform/system-administration/using-oauth2#...

Is there a way to send a refresh token request from within the module once the configuration is saved, or does saving the configuration cause a refresh token to be sent as needed?

I may have resolved the issue.

Instead of trying to save the connection at /admin/config/apigee-edge/settings, I went to /admin/config/system/keys, configured the settings there and successfully saved them, then ran "drush cex" to ensure the config was updated.

After that, I confirmed I was able to register a new user in Drupal and the user was also present as a developer in the Apigee Management Console.

Hi,

I am using the apigee_edge module version 2.0.11 and Drupal 9.5.7 with PHP 8.2.3.

I am trying to configure the module to use OAuth as per:

https://www.drupal.org/docs/contributed-modules/apigee-edge/configure-th... → .

I was able to successfully test the connection, but subsequent tests fail with the error message:

Failed to connect to the OAuth authorization server. The given username or password is incorrect. Error message: "error":"unauthorized","error_description Login policy rejected authentication

I checked the Apigee server sso logs and I see two messages;

One is:

ClientAuthenticationSuccess ('edgecli authenticated successfully')

The other is:

BadRequestEvent Status:401 Error:{"error":"unauthorized","error_description":"Login policy rejected authentication"}

 I noticed that if I wait a day, the connection test succeeds.

I reverted to samlauth 8.x-3.8 and was able to get this to work once I used the correct certificate.

This is what I had to enable in /var/www/devportal/web/sites/default/settings.php :

$settings['reverse_proxy'] = TRUE;

$settings['reverse_proxy_addresses'] = [$_SERVER['REMOTE_ADDR']];

Just to wrap this up, the issue was because I was using the wrong certificate.

Hi,

I have a site on Drupal 9.5.3, with php 8.3.2. I installed samlauth 8.x-3.8 via composer. I wanted the ACS url to return as https instead of http.

I enabled various reverse_proxy values in settings.php and now I see the ACS url with https, but I get the error "invalid_response; reason given for last error: Signature validation failed. SAML Response rejected" .

I went back to samlauth 8.x-3.2, and I am still getting the error "invalid_response; reason given for last error: Signature validation failed. SAML Response rejected".

Hi,

I have a Drupal 9.5.3, with php 8.3.2. I installed samlauth 8.x-3.8 via composer. I wanted the ACS url to return as https instead of http.

I enabled various reverse_proxy values in settings.php and now I see the ACS url with https, but I get the error "invalid_response; reason given for last error: Signature validation failed. SAML Response rejected" .

I went back to samlauth 8.x-3.2, and I am still getting the error "invalid_response; reason given for last error: Signature validation failed. SAML Response rejected".

Sorry, I re-read the thread and it seems the solution is to use 3.2 for now?

Hi,

I'm using samlauth version samlauth 8.x-3.8, and I'm getting the message "Signature validation failed. SAML Response rejected."

I tried various reverse_proxy settings in settings.php in order to get the module to use https for the acs URL.

No matter what I set for these values, I get the error:

$settings['reverse_proxy_addresses']

$settings['reverse_proxy_header']

$settings['reverse_proxy_proto_header']

$settings['reverse_proxy_host_header']

I also have these settings enabled:

$settings['reverse_proxy'] = TRUE;

$settings['reverse_proxy_trusted_headers'] = \Symfony\Component\HttpFoundation\Request::HEADER_X_FORWARDED_ALL | \Symfony\Component\HttpFoundation\Request::HEADER_FORWARDED;

Hi,

I was able to get this to work once I had access to my internal Okta configuration, where I was able to create a custom attribute for the email address.

Thanks for your help!

Thanks for the response. I will try what you suggested.

minkahb → created an issue.

Update:

I am now able to see samlauth messages at /admin/reports/dblog.

The only message type I see is a debug message, and what's concerning is that when the SAML request is being sent, the User is Anonymous (not verified).

So I am going to follow that path of troubleshooting and this particular issue I raised can be closed.

My IdP is sending the email address as a unique ID attribute.

When I go to admin/config/people/saml/authmap to map this, I enter in the email address and am able to find a user to map to.

When select "Apply", I see the message "Not configured to automatically link accounts", and when I exit admin/config/people/saml/authmap and sign back in, I see the values I entered where not saved.

My configuration is:

OS: CentOS 7
Drupal version : 9.5.3
samlauth version: version: '8.x-3.8'
PHP Version: 8.2.1
NGINX Version: nginx/1.22.1

I enabled all the debugging options at admin/config/people/saml, but I am unsure if any of this is being logged. I checked these locations and didn't find anything:

/var/log/messages
/var/log/nginx/access.log
/var/log/nginx/error.log
/var/log/php-fpm/error.log

I also checked /admin/reports/dblog, and don't see anything being logged here.

minkahb → created an issue.