Unexpected error when handling authentication request to identity provider альфа банк

Unexpected error when handling authentication request to identity provider альфа банк Типовые ошибки при попытке выполнения авторизации на веб-интерфейсе сервисиса подписи. 1. «OpenIdConnectMessage. Error was not null, indicating an error, Error: ‘unauthorized_client’. Error_Description ( may be empty): ‘The provided credentials of type ‘SharedSecret’ are invalid’. Error_uri (may be empty): ‘error_uri is null’.» Диагностика:Ошибка в […]

Содержание

  1. Unexpected error when handling authentication request to identity provider альфа банк
  2. Unexpected error when handling authentication request to identity provider. #45
  3. Comments

Unexpected error when handling authentication request to identity provider альфа банк

Типовые ошибки при попытке выполнения авторизации на веб-интерфейсе сервисиса подписи.

1. «OpenIdConnectMessage. Error was not null, indicating an error, Error: ‘unauthorized_client’. Error_Description ( may be empty): ‘The provided credentials of type ‘SharedSecret’ are invalid’. Error_uri (may be empty): ‘error_uri is null’.»

Диагностика:
Ошибка в «Журналы приложений и служб -> CryptoPro-> DSS-> IdentityService-> Admins».

Пример:
Source: ClientCredentialsValidator.
The credentials of type ‘SharedSecret’ with value ‘secret_value’ is not registered for client with id ‘cryptopro.dss.frontend.frontend’.

Возможные причины возникновения ошибки:
В настройках доступа по OpenId Connect веб-интерфейса указано значение секрета, не соответствующее зарегистрированному для oauth-клиента центра идентификации.

Рекомендуемое решение:
— Отобразить список значений секретов для oauth-клиента центра идентификации (по умолчанию: cryptopro.dss.frontend.frontend), выполнив командлет: Get-DssClientSecret -ClientId cryptopro.dss.frontend.frontend|fl
— Указать значение действующего секрета: Set-DssFeOidcSettings -ClientSecret
— Перезапустить пул приложения веб-интерфейса: Restart-DssFeInstance

2. unauthorized_client

Диагностика:
Ошибки в «Журналы приложений и служб -> CryptoPro-> DSS-> IdentityService-> Admins».

А) Source: ClientValidator.
The credentials for the client with id ‘cryptopro.dss.frontend.frontend’ of a type ‘SharedSecret’ is invalid. Error ‘unauthorized_client’. Additional info: [The provided credentials of type ‘SharedSecret’ expired at ‘expiration_date’.]

Б) Source: AuthorizeRequestValidator.
The ‘client_id’ parameter in the request is invalid. No registered client with id ‘cryptopro.dss.frontend.frontends is found.’

В) Source: AuthorizeRequestValidator.
The request is invalid. The client with id ‘cryptopro.dss.frontend.frontend’ is not allowed to use ‘AuthorizationCode’ flow.

Возможные причины возникновения ошибки:
— В настройках доступа по OpenId Connect веб-интерфейса указано значение секрета с истекшим сроком действия;
— В настройках доступа по OpenId Connect веб-интерфейса указан идентификатор oauth-клиента, который не зарегистрирован на центре идентификации;
— В списке допустимых для oauth-клиента сценариев отсутствует сценарий «AuthorizationCode».

Рекомендуемое решение:

А) Проверка сроков действия секретов и генерация новых:
— Отобразить список значений секретов для oauth-клиента центра идентификации (по умолчанию: cryptopro.dss.frontend.frontend), выполнив командлет: Get-DssClientSecret -ClientId cryptopro.dss.frontend.frontend|fl
— Если сроки действия всех секретов истекли — сгенерировать новый секрет: Set-DssClient -ClientId cryptopro.dss.frontend.frontend -GenerateSecret -SecretLifetime 0
— Получить значение нового секрета: $secret = (Get-DssClientSecret -ClientId cryptopro.dss.frontend.frontend).value
Указать значение нового секрета в настройках доступа по OpenId Connect веб-интерфейса: Set-DssFeOidcSettings -ClientSecret $secret
— Перезапустить пул приложения веб-интерфейса: Restart-DssFeInstance
— Перезапустить пул приложения центра идентификации: Restart-DssStsInstance

Б) Проверка корректности указанного в настройках доступа по OpenId Connect веб-интерфейса идентификатора oauth-клиента центра идентификации:
— Выполнить командлет: (Get-DssFeOidcSettings).ClientId
— Убедиться, что клиент с идентификатором, полученным на прошлом шаге, есть в списке зарегистрированных на стороне центра идентификации. Идентификаторы клиентов можно получить, выполнив командлет: (Get-DssClient).ClientId
— Если клиент не зарегистрирован — выполнить настройку в соответствие с примером.

В) Добавить для oauth-клиента необходимые сценарии использования:
— Выполнить командлет: Set-DssClient -ClientId ((Get-DssFeOidcSettings).ClientId) -AllowedFlow AuthorizationCode,ClientCredentials,TokenExchange
— Перезапустить пул приложения центра идентификации: Restart-DssStsInstance

3. Страница не найдена

Диагностика:
Ошибка в «Журналы приложений и служб -> CryptoPro-> DSS-> Frontend-> Admins».

Пример:
Ошибка в Веб-приложении:
The controller for path ‘/DssTest/oauth/authorize’ was not found or does not implement IController.
System.Web.HttpException: The controller for path ‘/DssTest/oauth/authorize’ was not found or does not implement IController.

Возможные причины возникновения ошибки:
В настройках доступа по OpenId Connect веб-интерфейса указаны некорректные адреса сервисов.

Рекомендуемое решение:
Выполнить настройку доступа по OpenId Connect веб-интерфейса, в соответствие с примером.

4. «Запрос HTTP запрещен для схемы аутентификации клиентов «Anonymous»

Диагностика:
Ошибка в «Журналы приложений и служб -> CryptoPro-> DSS-> Frontend-> Admins».

Пример:
В процессе работы Веб-интерфейса произошла ошибка:
Произошла ошибка во время работы контроллера CryptoPro.DSS.Web.Frontend.Admins.Controllers.CertificatesController
Действие List
System.ServiceModel.Security.MessageSecurityException: Запрос HTTP запрещен для схемы аутентификации клиентов «Anonymous».

Возможные причины возникновения ошибки:
— Для пулов приложений DSS не был предоставлен доступ к закрытым ключам сервисных сертификатов DSS;
— В расширении EKU (Extended Key Usage) сервисных сертификатов DSS отсутствует назначение 1.3.6.1.5.5.7.3.2 — Проверка подлинности клиента;
— В хранилище «Доверенные корневые центры сертификации» локального компьютера сервера DSS присутствуют несамоподписанные сертификаты;
— В хранилище «Доверенные корневые центры сертификации» локального компьютера сервера DSS не установлены сертификаты издателей сервисных сертификатов DSS;
— Невозможно выполнить проверку сервисных сертификатов DSS на отзыв.

Рекомендуемое решение:
— Убедиться, что пулам приложений DSS был предоставлен доступ к закрытым ключам сервисных сертификатов DSS.
— Убедиться, что в расширении EKU (Extended Key Usage) сервисных сертификатов DSS присутствует назначение 1.3.6.1.5.5.7.3.2 — Проверка подлинности клиента.
— Удалить/перенести в другие хранилища несамоподписанные сертификаты из хранилища «Доверенные корневые центры сертификации» локального компьютера сервера DSS, если таковые имеются. Найти такие сертификаты можно, выполнив командлет: Get-Childitem cert:LocalMachineroot -Recurse | Where-Object <$_.Issuer -ne $_.Subject>
— Убедиться, что в хранилище «Доверенные корневые центры сертификации» локального компьютера сервера DSS установлены сертификаты издателей сервисных сертификатов DSS.
— Обеспечить проверку сервисных сертификатов DSS на отзыв (путем установки CRL в хранилище «Промежуточные центры сертификации» локального компьютера сервера DSS или обеспечив доступность CRL по ссылкам, указанным в расширении «Точки распространения списков отзыва» сервисных сертификатов DSS).

5. Требуется делегирование

Диагностика:
Ошибка в «Журналы приложений и служб -> CryptoPro-> DSS-> Frontend-> Admins».

Пример:
Идентификатор экземпляра: 1/Frontend.
В процессе работы Веб-интерфейса произошла ошибка:
Произошла ошибка во время работы контроллера CryptoPro.DSS.Web.Frontend.Controllers.CertificatesController
Действие List
System.ServiceModel.FaultException`1[[CryptoPro.DSS.Common.Service.DssFault, CryptoPro.DSS.Common, Version=1.17.0.0, Culture=neutral, PublicKeyToken=cb703a801b9b4b55]]: Требуется делегирование.

Возможные причины возникновения ошибки:
В рамках одной сессии браузера была выполнена попытка сперва авторизоваться в личном кабинете оператора, а затем — в веб-интерфейсе сервиса подписи.

Рекомендуемое решение:
— Перезапустить браузер и попробовать еще раз авторизоваться в веб-интерфейсе сервиса подписи;
— Открыть новую вкладку браузера в режиме «Инкогнито», и авторизоваться через нее в веб-интерфейсе сервиса подписи.

6. Message: Authorization has been denied for this request

Диагностика:
Ошибка в «Журналы приложений и служб -> CryptoPro-> DSS-> SignServer-> Admins».

Пример:
Instance Unique Identifier: 1/signserver Source: Microsoft.Owin.Security.OAuth.OAuthBearerAuthenticationMiddleware Message: Authentication failed
System.IdentityModel.Tokens.SecurityTokenSignatureKeyNotFoundException: IDX10505: Unable to validate signature. The ‘Delegate’ specified on TokenValidationParameters, returned a null SecurityKey.

Возможные причины возникновения ошибки:
— На сервисе подписи не настроены отношения доверия с центром идентификации;
— Истек срок действия сервисного сертификата сервиса подписи.

Рекомендуемое решение:
— Запросить отпечаток сервисного сертификата ЦИ: $idp_cert = (Get-DssStsProperties).ServiceCertificate
— Указать отпечаток сервисного сертификата ЦИ на сервисе подписи: Add-DssClaimsProviderTrust -IssuerName realsts -Thumbprint $idp_cert
Примечание: если при выполнении второго командлета в Powershell возникла ошибка «Доверенный издатель с именем realsts уже добавлен в коллекцию» — необходимо выполнить командлет: Set-DssClaimsProviderTrust -IssuerName realsts -NewThumbprint $idp_cert
— Проверить срок действия сервисного сертификата сервиса подписи. Если срок действия истек — необходимо перевыпустить его и скорректировать настройки в соответствие с руководством;
— Перезагрузить пулы приложений центра идентификации и сервиса подписи, выполнив командлеты: Restart-DssStsInstance и Restart-DssSignServerInstance

7. IDX10505: Unable to validate signature. The ‘Delegate’ specified on TokenValidationParameters, returned a null SecurityKey.

Диагностика:
Ошибка в «Журналы приложений и служб -> CryptoPro-> DSS-> Frontend-> Admins».

Пример:
Instance Unique Identifier: 1/frontend Source: Microsoft.Owin.Security.OAuth.OAuthBearerAuthenticationMiddleware Message: Authentication failed
System.IdentityModel.Tokens.SecurityTokenSignatureKeyNotFoundException: IDX10505: Unable to validate signature. The ‘Delegate’ specified on TokenValidationParameters, returned a null SecurityKey.

Возможные причины возникновения ошибки:
— На веб-интерфейсе не настроены отношения доверия с центром идентификации;
— Истек срок действия сервисного сертификата веб-интерфейса.

Рекомендуемое решение:
— Запросить отпечаток сервисного сертификата ЦИ: $idp_cert = (Get-DssStsProperties).ServiceCertificate
— Указать отпечаток сервисного сертификата ЦИ на веб-интерфейсе: Add-DssFeClaimsProviderTrust -IssuerName realsts -Thumbprint $idp_cert
Примечание: если при выполнении второго командлета в Powershell возникла ошибка «Доверенный издатель с именем realsts уже добавлен в коллекцию» — необходимо выполнить командлет: Set-DssFeClaimsProviderTrust -IssuerName realsts -NewThumbprint $idp_cert
— Проверить срок действия сервисного сертификата веб-интерфейса. Если срок действия истек — необходимо перевыпустить его и скорректировать настройки в соответствие с руководством;
— Перезагрузить пулы приложений центра идентификации и веб-интерфейса, выполнив командлеты: Restart-DssStsInstance и Restart-DssFeInstance

Источник

Unexpected error when handling authentication request to identity provider. #45

I am getting this error «Unexpected error when handling authentication request to identity provider.» when I try to configure resourceId with multiple ids (space delimited). I appreciate on any help to resolve it.

The text was updated successfully, but these errors were encountered:

Works fine for the single patient resourceId. For multiple ids, I see this event (invalid_user_credentials) logged in keycloak even though I provide correct login details.

which version of keycloak?
anything useful in the keycloak server logs?

This is the error i see in the server logs:

16:08:21,867 WARN [org.keycloak.events] (default task-65) type=LOGIN_ERROR, realmId=d1283bbc-de4a-4978-8e9c-cac7feee267d, clientId=inferno, userId=null, ipAddress=172.17.0.1, error=invalid_user_credentials, auth_method=openid-connect, auth_type=code, redirect_uri=http://localhost:4567/inferno/static/, code_id=55a44f94-d0ae-455c-b883-55efd985c336, username=fhiruser, authSessionParentId=55a44f94-d0ae-455c-b883-55efd985c336, authSessionTabId=_CA2MdLA-FY

16:17:41,095 INFO [org.alvearie.keycloak.PatientSelectionForm] (default task-65) Client request is missing the ‘aud’ parameter, using ‘http://localhost:4080/’ from config.

16:17:41,098 WARN [org.keycloak.services] (default task-65) KC-SERVICES0013: Failed authentication: javax.ws.rs.ProcessingException: RESTEASY004655: Unable to invoke request: org.apache.http.conn.HttpHostConnectException: Connect to localhost:4080 [localhost/127.0.0.1] failed: Connection refused (Connection refused)

at jdk.internal.reflect.GeneratedMethodAccessor969.invoke(Unknown Source)

Caused by: org.apache.http.conn.HttpHostConnectException: Connect to localhost:4080 [localhost/127.0.0.1] failed: Connection refused (Connection refused)

Caused by: java.net.ConnectException: Connection refused (Connection refused)

at java.base/java.net.PlainSocketImpl.socketConnect(Native Method)

16:17:41,100 WARN [org.keycloak.events] (default task-65) type=LOGIN_ERROR, realmId=d1283bbc-de4a-4978-8e9c-cac7feee267d, clientId=inferno, userId=null, ipAddress=172.17.0.1, error=invalid_user_credentials, auth_method=openid-connect, auth_type=code, redirect_uri=http://localhost:4567/inferno/static/, code_id=55a44f94-d0ae-455c-b883-55efd985c336, username=fhiruser, authSessionParentId=55a44f94-d0ae-455c-b883-55efd985c336, authSessionTabId=ShD-AVp7eo4

I was able to fix the earlier issue by setting FHIR_BASE_URL=http://172.30.96.1:4080/ (instead of localhost:4080) for alvearie/keycloak-config. Now I am stuck with this error. Looks like it is trying to pull the patient resource and it is failing due to launch/context or scope in the token.

17:00:36,556 WARN [org.alvearie.keycloak.PatientSelectionForm] (default task-10) Response with code 400

«text»: «Cannot enforce ‘patient/*’ claims without a launch context.»

Yes, the patient context picker will try to find which patients the user has access to and present them to the user via a picklist. For that request to the FHIR server, it’s setting the patient/Patient.read scope on the following line: https://github.com/Alvearie/keycloak-extensions-for-fhir/blob/main/keycloak-extensions/src/main/java/org/alvearie/keycloak/PatientSelectionForm.java#L199
But it looks like the FHIR server you’re using it with is rejecting that. I assume thats a local instance of the microsoft fhir-server?
I havn’t ever tried with that one, but I’d love for this to work. Can you provide some info about what is needed to work with it?

Thanks for your quick response Lee! Appreciate your help resolving this!

I am using firely server. I am passing the scopes «launch/patient openid fhirUser offline_access patient/*.read» when I get new access token. Is that correct?

What is the fhir api url being used to get the patient resources (for multiple)? So I can make a separate api call using postman and verify it.

I was getting this same error when I was trying with single resourceId in the user profile which I was able to fix it by turning it on «Add to access token » in «Patient ID Token Mapper» under «launch/context» scope.

The patient selector is finally shows up when I disable smart authorization in firely server. Looks like there is some issue going on with the scope & launch context in my setup.

Finally I figured out why it is failing on getting patient resources. When I enable SMART Authorization in firely server, it looks for «user/*» scope to get the patient resources. But you have set «patient/Patient.read» scope to get patient resources which supposed to be used only in patient context (launch/patient). Did you try/test patient picker using IBM FHIR Server without SMART Authorization enabled?

On IBM FHIR Server, we apply the patient/* scopes to the patient context(s) associated with the patient_id claim that we include in the access token.
When our server sees that context, it automatically scopes the request to resources in those compartments.

Even though the keycloak client is sort of a «trusted» client of the FHIR server, I thought it would be a nice double-check to set this patient context on the batch read of the Patient resources . basically asking the FHIR Server ensure that we only get Patient resources for the patient picker that the end user actually has access to.

However, I can see the logic in using user/Patient.read instead of patient/Patient.read for this request (since patient/ scopes are typically for a single-paitent context) and I think that could work for our server too. I think its really no less secure because the same code that is setting the patient_id claim is also the code that is specifying the set of Patient resources to read by id.

I can give that a try on our server if you give it a try on yours. let me know how it goes.

Thanks for detail reply.

Looks like you have configured a claim «patient» (to pass the selected patient’s id from the patient picker) which supposed to be used for patient compartment. It works fine in my setup with firely server. The other one «patient_id» claim is used to pass the resourceId which is configured at the user profile. Patient picker is using this claim to prepare the bundle request and get those patient resources. Is that correct?

Looks like you have configured a claim «patient» (to pass the selected patient’s id from the patient picker) which supposed to be used for patient compartment.

«patient» is the key that comes back on the token response and that is defined by the spec. but we don’t use that as the name of the claim within the access token. for that we use «patient_id». we originally got that from a MITRE reference implementation I believe, but it should be considered implementation detail. the spec doesn’t put any requirements on the content of the access token (it is «opaque» to the client).

For the batch read that we perform from keycloak, we set this patient_id claim to the list of resourceId associated with the user. the same set of ids we try to read.

The documentation for that is at https://github.com/Alvearie/keycloak-extensions-for-fhir#the-patient-context-picker
but it doesn’t go into detail on this patient_id claim.
Unfortunately, because the interaction between the smart auth server and the fhir server is not covered by the specification, I don’t know if there is a truly interoperable way to do that. However, like I said above, if you can confirm that setting user/Patient.read instead of patient/Patient.read will work for you server, I’m willing to consider changing to that.

Sorry for the delay response.

I was able to make it work only after setting the scope to «user/Patient.read». Please refer/read authorization section in the below url — «But with a scope of ‘patient/’ you are required to also have a ‘patient=…’ launch context to know to which patient the user connects».

You may also setup and try using trial version if you have time.

To be clear, having a patient=123 scope like they seem to require is totally custom (just as custom as the IBM FHIR Server’s patient_id claim).
Personally, I like my approach of using a separate claim more.

Источник

This is the error i see in the server logs:

16:08:21,867 WARN [org.keycloak.events] (default task-65) type=LOGIN_ERROR, realmId=d1283bbc-de4a-4978-8e9c-cac7feee267d, clientId=inferno, userId=null, ipAddress=172.17.0.1, error=invalid_user_credentials, auth_method=openid-connect, auth_type=code, redirect_uri=http://localhost:4567/inferno/static/, code_id=55a44f94-d0ae-455c-b883-55efd985c336, username=fhiruser, authSessionParentId=55a44f94-d0ae-455c-b883-55efd985c336, authSessionTabId=_CA2MdLA-FY

16:17:41,095 INFO [org.alvearie.keycloak.PatientSelectionForm] (default task-65) Client request is missing the ‘aud’ parameter, using ‘http://localhost:4080/’ from config.

16:17:41,098 WARN [org.keycloak.services] (default task-65) KC-SERVICES0013: Failed authentication: javax.ws.rs.ProcessingException: RESTEASY004655: Unable to invoke request: org.apache.http.conn.HttpHostConnectException: Connect to localhost:4080 [localhost/127.0.0.1] failed: Connection refused (Connection refused)

at org.jboss.resteasy.resteasy-jaxrs@3.15.1.Final//org.jboss.resteasy.client.jaxrs.engines.ApacheHttpClient4Engine.invoke(ApacheHttpClient4Engine.java:341)

at org.jboss.resteasy.resteasy-jaxrs@3.15.1.Final//org.jboss.resteasy.client.jaxrs.internal.ClientInvocation.invoke(ClientInvocation.java:464)

at org.jboss.resteasy.resteasy-jaxrs@3.15.1.Final//org.jboss.resteasy.client.jaxrs.internal.ClientInvocation.invoke(ClientInvocation.java:65)

at org.jboss.resteasy.resteasy-jaxrs@3.15.1.Final//org.jboss.resteasy.client.jaxrs.internal.ClientInvocationBuilder.post(ClientInvocationBuilder.java:232)

at deployment.keycloak-extensions-0.0.1-SNAPSHOT.jar//org.alvearie.keycloak.PatientSelectionForm.authenticate(PatientSelectionForm.java:123)

at org.keycloak.keycloak-services@15.0.2//org.keycloak.authentication.DefaultAuthenticationFlow.processSingleFlowExecutionModel(DefaultAuthenticationFlow.java:446)

at org.keycloak.keycloak-services@15.0.2//org.keycloak.authentication.DefaultAuthenticationFlow.processFlow(DefaultAuthenticationFlow.java:253)

at org.keycloak.keycloak-services@15.0.2//org.keycloak.authentication.DefaultAuthenticationFlow.processSingleFlowExecutionModel(DefaultAuthenticationFlow.java:389)

at org.keycloak.keycloak-services@15.0.2//org.keycloak.authentication.DefaultAuthenticationFlow.continueAuthenticationAfterSuccessfulAction(DefaultAuthenticationFlow.java:186)

at org.keycloak.keycloak-services@15.0.2//org.keycloak.authentication.DefaultAuthenticationFlow.processAction(DefaultAuthenticationFlow.java:164)

at org.keycloak.keycloak-services@15.0.2//org.keycloak.authentication.AuthenticationProcessor.authenticationAction(AuthenticationProcessor.java:950)

at org.keycloak.keycloak-services@15.0.2//org.keycloak.services.resources.LoginActionsService.processFlow(LoginActionsService.java:312)

at org.keycloak.keycloak-services@15.0.2//org.keycloak.services.resources.LoginActionsService.processAuthentication(LoginActionsService.java:283)

at org.keycloak.keycloak-services@15.0.2//org.keycloak.services.resources.LoginActionsService.authenticate(LoginActionsService.java:267)

at org.keycloak.keycloak-services@15.0.2//org.keycloak.services.resources.LoginActionsService.authenticateForm(LoginActionsService.java:340)

at jdk.internal.reflect.GeneratedMethodAccessor969.invoke(Unknown Source)

at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)

at java.base/java.lang.reflect.Method.invoke(Method.java:566)

at org.jboss.resteasy.resteasy-jaxrs@3.15.1.Final//org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:138)

at org.jboss.resteasy.resteasy-jaxrs@3.15.1.Final//org.jboss.resteasy.core.ResourceMethodInvoker.internalInvokeOnTarget(ResourceMethodInvoker.java:546)

at org.jboss.resteasy.resteasy-jaxrs@3.15.1.Final//org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTargetAfterFilter(ResourceMethodInvoker.java:435)

at org.jboss.resteasy.resteasy-jaxrs@3.15.1.Final//org.jboss.resteasy.core.ResourceMethodInvoker.lambda$invokeOnTarget$0(ResourceMethodInvoker.java:396)

at org.jboss.resteasy.resteasy-jaxrs@3.15.1.Final//org.jboss.resteasy.core.interception.PreMatchContainerRequestContext.filter(PreMatchContainerRequestContext.java:358)

at org.jboss.resteasy.resteasy-jaxrs@3.15.1.Final//org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTarget(ResourceMethodInvoker.java:398)

at org.jboss.resteasy.resteasy-jaxrs@3.15.1.Final//org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:365)

at org.jboss.resteasy.resteasy-jaxrs@3.15.1.Final//org.jboss.resteasy.core.ResourceLocatorInvoker.invokeOnTargetObject(ResourceLocatorInvoker.java:150)

at org.jboss.resteasy.resteasy-jaxrs@3.15.1.Final//org.jboss.resteasy.core.ResourceLocatorInvoker.invoke(ResourceLocatorInvoker.java:104)

at org.jboss.resteasy.resteasy-jaxrs@3.15.1.Final//org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:440)

at org.jboss.resteasy.resteasy-jaxrs@3.15.1.Final//org.jboss.resteasy.core.SynchronousDispatcher.lambda$invoke$4(SynchronousDispatcher.java:229)

at org.jboss.resteasy.resteasy-jaxrs@3.15.1.Final//org.jboss.resteasy.core.SynchronousDispatcher.lambda$preprocess$0(SynchronousDispatcher.java:135)

at org.jboss.resteasy.resteasy-jaxrs@3.15.1.Final//org.jboss.resteasy.core.interception.PreMatchContainerRequestContext.filter(PreMatchContainerRequestContext.java:358)

at org.jboss.resteasy.resteasy-jaxrs@3.15.1.Final//org.jboss.resteasy.core.SynchronousDispatcher.preprocess(SynchronousDispatcher.java:138)

at org.jboss.resteasy.resteasy-jaxrs@3.15.1.Final//org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:215)

at org.jboss.resteasy.resteasy-jaxrs@3.15.1.Final//org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:245)

at org.jboss.resteasy.resteasy-jaxrs@3.15.1.Final//org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:61)

at org.jboss.resteasy.resteasy-jaxrs@3.15.1.Final//org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:56)

at javax.servlet.api@2.0.0.Final//javax.servlet.http.HttpServlet.service(HttpServlet.java:590)

at io.undertow.servlet@2.2.5.Final//io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:74)

at io.undertow.servlet@2.2.5.Final//io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:129)

at org.keycloak.keycloak-wildfly-extensions@15.0.2//org.keycloak.provider.wildfly.WildFlyRequestFilter.lambda$doFilter$0(WildFlyRequestFilter.java:41)

at org.keycloak.keycloak-services@15.0.2//org.keycloak.services.filters.AbstractRequestFilter.filter(AbstractRequestFilter.java:43)

at org.keycloak.keycloak-wildfly-extensions@15.0.2//org.keycloak.provider.wildfly.WildFlyRequestFilter.doFilter(WildFlyRequestFilter.java:39)

at io.undertow.servlet@2.2.5.Final//io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:61)

at io.undertow.servlet@2.2.5.Final//io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131)

at io.undertow.servlet@2.2.5.Final//io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:84)

at io.undertow.servlet@2.2.5.Final//io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62)

at io.undertow.servlet@2.2.5.Final//io.undertow.servlet.handlers.ServletChain$1.handleRequest(ServletChain.java:68)

at io.undertow.servlet@2.2.5.Final//io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)

at org.wildfly.extension.undertow@23.0.2.Final//org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)

at io.undertow.core@2.2.5.Final//io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)

at io.undertow.servlet@2.2.5.Final//io.undertow.servlet.handlers.RedirectDirHandler.handleRequest(RedirectDirHandler.java:68)

at io.undertow.servlet@2.2.5.Final//io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:117)

at io.undertow.servlet@2.2.5.Final//io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57)

at io.undertow.core@2.2.5.Final//io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)

at io.undertow.core@2.2.5.Final//io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)

at io.undertow.servlet@2.2.5.Final//io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)

at io.undertow.core@2.2.5.Final//io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60)

at io.undertow.servlet@2.2.5.Final//io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77)

at io.undertow.core@2.2.5.Final//io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50)

at io.undertow.core@2.2.5.Final//io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43)

at io.undertow.core@2.2.5.Final//io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)

at org.wildfly.extension.undertow@23.0.2.Final//org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)

at io.undertow.core@2.2.5.Final//io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)

at org.wildfly.extension.undertow@23.0.2.Final//org.wildfly.extension.undertow.deployment.GlobalRequestControllerHandler.handleRequest(GlobalRequestControllerHandler.java:68)

at io.undertow.servlet@2.2.5.Final//io.undertow.servlet.handlers.SendErrorPageHandler.handleRequest(SendErrorPageHandler.java:52)

at io.undertow.core@2.2.5.Final//io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)

at io.undertow.servlet@2.2.5.Final//io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:269)

at io.undertow.servlet@2.2.5.Final//io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:78)

at io.undertow.servlet@2.2.5.Final//io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:133)

at io.undertow.servlet@2.2.5.Final//io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:130)

at io.undertow.servlet@2.2.5.Final//io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48)

at io.undertow.servlet@2.2.5.Final//io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43)

at org.wildfly.extension.undertow@23.0.2.Final//org.wildfly.extension.undertow.security.SecurityContextThreadSetupAction.lambda$create$0(SecurityContextThreadSetupAction.java:105)

at org.wildfly.extension.undertow@23.0.2.Final//org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1530)

at org.wildfly.extension.undertow@23.0.2.Final//org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1530)

at org.wildfly.extension.undertow@23.0.2.Final//org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1530)

at org.wildfly.extension.undertow@23.0.2.Final//org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1530)

at io.undertow.servlet@2.2.5.Final//io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:249)

at io.undertow.servlet@2.2.5.Final//io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:78)

at io.undertow.servlet@2.2.5.Final//io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:99)

at io.undertow.core@2.2.5.Final//io.undertow.server.Connectors.executeRootHandler(Connectors.java:387)

at io.undertow.core@2.2.5.Final//io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:841)

at org.jboss.threads@2.4.0.Final//org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)

at org.jboss.threads@2.4.0.Final//org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1990)

at org.jboss.threads@2.4.0.Final//org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1486)

at org.jboss.threads@2.4.0.Final//org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1377)

at org.jboss.xnio@3.8.4.Final//org.xnio.XnioWorker$WorkerThreadFactory$1$1.run(XnioWorker.java:1280)

at java.base/java.lang.Thread.run(Thread.java:829)

Caused by: org.apache.http.conn.HttpHostConnectException: Connect to localhost:4080 [localhost/127.0.0.1] failed: Connection refused (Connection refused)

at org.apache.httpcomponents.core//org.apache.http.impl.conn.DefaultHttpClientConnectionOperator.connect(DefaultHttpClientConnectionOperator.java:156)

at org.apache.httpcomponents.core//org.apache.http.impl.conn.PoolingHttpClientConnectionManager.connect(PoolingHttpClientConnectionManager.java:376)

at org.apache.httpcomponents.core//org.apache.http.impl.execchain.MainClientExec.establishRoute(MainClientExec.java:393)

at org.apache.httpcomponents.core//org.apache.http.impl.execchain.MainClientExec.execute(MainClientExec.java:236)

at org.apache.httpcomponents.core//org.apache.http.impl.execchain.ProtocolExec.execute(ProtocolExec.java:186)

at org.apache.httpcomponents.core//org.apache.http.impl.execchain.RetryExec.execute(RetryExec.java:89)

at org.apache.httpcomponents.core//org.apache.http.impl.execchain.RedirectExec.execute(RedirectExec.java:110)

at org.apache.httpcomponents.core//org.apache.http.impl.client.InternalHttpClient.doExecute(InternalHttpClient.java:185)

at org.apache.httpcomponents.core//org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:83)

at org.apache.httpcomponents.core//org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:56)

at org.jboss.resteasy.resteasy-jaxrs@3.15.1.Final//org.jboss.resteasy.client.jaxrs.engines.ApacheHttpClient4Engine.invoke(ApacheHttpClient4Engine.java:336)

… 87 more

Caused by: java.net.ConnectException: Connection refused (Connection refused)

at java.base/java.net.PlainSocketImpl.socketConnect(Native Method)

at java.base/java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:399)

at java.base/java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:242)

at java.base/java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:224)

at java.base/java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392)

at java.base/java.net.Socket.connect(Socket.java:609)

at org.apache.httpcomponents.core//org.apache.http.conn.socket.PlainConnectionSocketFactory.connectSocket(PlainConnectionSocketFactory.java:75)

at org.apache.httpcomponents.core//org.apache.http.impl.conn.DefaultHttpClientConnectionOperator.connect(DefaultHttpClientConnectionOperator.java:142)

… 97 more

16:17:41,100 WARN [org.keycloak.events] (default task-65) type=LOGIN_ERROR, realmId=d1283bbc-de4a-4978-8e9c-cac7feee267d, clientId=inferno, userId=null, ipAddress=172.17.0.1, error=invalid_user_credentials, auth_method=openid-connect, auth_type=code, redirect_uri=http://localhost:4567/inferno/static/, code_id=55a44f94-d0ae-455c-b883-55efd985c336, username=fhiruser, authSessionParentId=55a44f94-d0ae-455c-b883-55efd985c336, authSessionTabId=ShD-AVp7eo4

В остальном работающий так, как ожидалось сервер Keycloak вызывает у меня головную боль с тех пор, как я начал пытаться реализовать действия, инициированные приложением.

Предыдущий поиск

Поскольку поиск по теме приводит к скудному отбору практического материала, мне пришлось пройти через проектный документ для AIA, особенно раздел потоков.

Среда

  • Плащ 15
    • Серверная часть базы данных PostgreSQL
    • Keycloak как развертывание k8s
    • Используемый клиент временно имеет все возможности для разработки.
  • Бэкэнд Node.JS с keycloak-connect и выражением в качестве сервера

Что я пробовал

Согласно проектному документу (Вот запись в группы Google, где сказано, что функция «в значительной степени получилась так, как задумано») потоки должны быть построены как

../realms/myrealm/protocol/openid-connect/auth
    ?response_type=code
    &client_id=myclient
    &redirect_uri=https://myclient.com
    &kc_action=update_profile

Что привело к этому коду в моем движке шаблонов:

`${keycloak.config.realmUrl}/protocol/openid-connect/auth?response_type=code&client_id=${keycloak.config.clientId}&redirect_uri=${new URLSearchParams("http://localhost:3000/account").toString()}&kc_action=update_profile`

(pug variable) keycloak.config заполняется с использованием keycloak.getConfig(), где keycloak — это экземпляр соединения keycloak.

Механизм шаблонов правильно подставляет переменные в ссылку, которая ведет к моему экземпляру keycloak, где я получаю (немецкий эквивалент) это сообщение об ошибке:

Unexpected error when handling authentication request to identity provider

(Немецкий:

Unerwarteter Fehler während der Bearbeitung der Anfrage an den Identity Provider.

Находятся

Другие поставщики удостоверений не настроены.

Вопрос

Как правильно вызвать мой Keycloak, чтобы запустить AIA, если способ, описанный в проектном документе, приводит к этой ошибке?

1 ответ

Лучший ответ

После моего собственного исследования я понял, что это работает. Сообщение об ошибке вводит в заблуждение, потому что у меня нет другого поставщика удостоверений, настроенного для этого экземпляра.

Ожидается, что параметр kc_action будет ВСЕМИ ЗАГЛАВНЫМИ БУКВАМИ. Так

`${keycloak.config.realmUrl}/protocol/openid-connect/auth?response_type=code&client_id=${keycloak.config.clientId}&redirect_uri=${new URLSearchParams("http://localhost:3000/account").toString()}&kc_action=update_profile`

Должно быть

`${keycloak.config.realmUrl}/protocol/openid-connect/auth?response_type=code&client_id=${keycloak.config.clientId}&redirect_uri=${new URLSearchParams("http://localhost:3000/account").toString()}&kc_action=UPDATE_PROFILE`

Это нужно где-то задокументировать, чтобы люди могли найти, потому что я не видел, чтобы это явно упоминалось в «документации».

Я также поднял запрос на улучшение документации Keycloak, чтобы официально задокументировать AIA.


0

damnedOperator
1 Дек 2021 в 12:20

«Ошибка: аутентификация не удалась» – ExpressVPN

«VPN-соединение: аутентификация пользователя не удалась» – NordVPN

Вы не одиноки, когда сталкиваетесь с ошибкой «VPN Authentication Failed» – это одна из наиболее часто сообщаемых проблем VPN. Как пользователь VPN, я знаю, как важно оставаться защищенным в сети, а не идти на компромисс в отношении безопасности. Так что не волнуйтесь – я придумала 11 методов, которые вы можете использовать, чтобы исправить эту ошибку и быстро восстановить и запустить VPN .

Сообщения об ошибках проверки подлинности на NordVPN и ExpressVPN

1. Перезагрузите компьютер

Иногда самые простые решения являются лучшими. Как и многие технические проблемы, ошибку «VPN Authentication Failed» иногда можно решить, перезагрузив устройство . Это очищает кэш памяти и останавливает любой код, который не работает должным образом, чтобы VPN мог начать заново.

2. Отключите ваш брандмауэр

Если вы используете брандмауэр, он может блокировать ваш VPN-клиент. Чтобы выяснить, является ли это проблемой, вам нужно временно отключить брандмауэр, чтобы убедиться, что он что-то исправляет . Убедитесь, что вы отключили как сторонние, так и встроенные брандмауэры (например, брандмауэр Защитника Windows). Это необходимо сделать для публичных и частных сетей – эта опция должна быть в настройках вашего брандмауэра.

Это не постоянное решение, и отключение брандмауэра может сделать ваш компьютер уязвимым для угроз безопасности. Если проблема связана с вашим брандмауэром, вам нужно изменить настройки или переключиться на другой брандмауэр .

3. Попробуйте проводное соединение

Иногда проблемы с вашим маршрутизатором могут помешать правильному подключению VPN . Это не часто, но это случается, особенно если вы используете два связанных маршрутизатора. Попробуйте подключиться к маршрутизатору с помощью кабеля Ethernet вместо беспроводного подключения и посмотрите, решит ли это проблему.

Если использование двух маршрутизаторов вызывает проблемы, вы можете исправить это, включив режим моста . Метод для этого варьируется в зависимости от модели, поэтому проверьте руководство вашего маршрутизатора.

4. Используйте другой протокол VPN

В большинстве VPN вы можете выбрать, какой протокол IP использовать . Наиболее распространенными являются TCP (протокол управления передачей) и UDP (протокол пользовательских дейтаграмм). Основное отличие состоит в том, что TCP включает исправление ошибок , то есть он отправляет все, что повреждено или не получено из-за проблем с соединением. Поскольку UDP этого не делает, он быстрее, но может быть менее надежным.

Переключение между протоколами может устранить ошибку «VPN Authentication Failed» , ускоряя ваше соединение, особенно если вы переходите с TCP на UDP . Вы найдете эту опцию в настройках вашего VPN-приложения. Обратите внимание, что качество вашего соединения может ухудшиться, если вы переключите протоколы.

5. Попробуйте альтернативный DNS-сервер

По умолчанию ваш VPN-клиент, вероятно, будет использовать DNS-серверы вашего VPN-провайдера. Это снижает риск утечек DNS, но иногда вызывает проблемы с подключением . Чтобы проверить, является ли это проблемой, попробуйте использовать другие DNS-серверы . В настройках вашего VPN-приложения вам нужно отключить опцию «Использовать только DNS-серверы VPN». Имейте в виду, что это может немного увеличить риск утечки DNS.

6. Попробуйте другую сеть WiFi

Если ни одно из предыдущих решений не помогло вам, возможно, проблема в вашей сети Wi-Fi. Чтобы узнать, так ли это, попробуйте использовать VPN в общедоступной точке доступа WiFi или в доме друга . Если VPN работает в этих других сетях, ваша проблема может быть в этом. Взгляните на настройки Интернета и WiFi и попытайтесь определить причины проблем с VPN.

7. Подключитесь к другому серверу VPN

Если вы пытаетесь подключиться, возможно, сервер VPN, который вы используете, слишком медленный или имеет слишком много пользователей . Большинство приложений VPN позволяют выбирать между несколькими серверами в каждом доступном месте. Попробуйте перейти на другой и посмотреть, поможет ли это.

Помните, что чем ближе вы находитесь к серверу, тем быстрее он будет . Например, если вы находитесь в Европе и вам необходимо подключиться к американскому серверу, серверы на восточном побережье должны быть быстрее, чем на западе.

Если вы используете VPN на своем маршрутизаторе, а не через клиент на вашем устройстве, переключение между серверами более сложное . Способ зависит от вашего роутера и провайдера VPN. Если вы не уверены, как это сделать, проверьте документацию для вашего маршрутизатора и VPN .

8. Переустановите свой VPN

Поврежденная установка вашей VPN может привести к ошибке «VPN Authentication Failed» . Если вы подозреваете, что это может быть проблемой, попробуйте удалить и переустановить VPN-клиент . Избегайте других ошибок, используя программное обеспечение для удаления, чтобы удалить все записи реестра и файлы из первой установки.

9. Убедитесь, что ваша VPN-подписка активна

Если вы используете платный VPN-сервис, срок действия вашей подписки истек . Кроме того, вы, возможно, создали учетную запись, но еще не купили подписку.

Чтобы решить эту проблему, войдите в свою учетную запись на веб-сайте вашего провайдера VPN и убедитесь, что ваша подписка была оплачена .

10. Убедитесь, что не слишком много одновременных подключений

Большинство VPN-сервисов ограничивают количество устройств, которые могут быть подключены к VPN одновременно . Если вы подключили несколько устройств, возможно, вы превысили лимит. Посетите веб-сайт вашего поставщика услуг VPN, чтобы подтвердить количество одновременных подключений. Если вы превысили лимит, отключите все устройства, которые вы не используете .

11. Попробуйте лучше VPN

Если вы перепробовали все вышеперечисленные решения и у вас все еще есть проблемы, вы можете подумать о более качественном VPN-сервисе . Бесплатные VPN более низкого уровня могут быть медленными и подвержены другим проблемам с подключением. Напротив, услуги премиум-класса очень быстрые и гораздо реже вызывают проблемы . Например, ExpressVPN предлагает неограниченную пропускную способность и имеет встроенную функцию проверки скорости, которая поможет вам выбрать самый быстрый сервер.

Для тех, кто ограничен в бюджете, NordVPN имеет много тех же функций, что и ExpressVPN, по более доступной цене . Сервис не такой быстрый, но он известен своей надежностью. Или, если вы смотрите много онлайн-контента, вы можете попробовать CyberGhost . Компания гарантирует, что вы всегда будете подключены к самому быстрому доступному серверу, а также имеет серверы, оптимизированные для различных потоковых сервисов .

Все эти VPN предоставляют гарантии возврата денег, так что вы можете попробовать их некоторое время и получить полный возврат средств, если вы не удовлетворены .

Получите лучший VPN сейчас!

Вывод

Ошибка «VPN Authentication Failed» может быть распространена, но исправить ее просто. С этими решениями вы скоро снова будете в безопасности.

Испытываете другие проблемы с подключением? Ознакомьтесь с этим руководством по исправлению наиболее распространенных кодов ошибок VPN .

Статья была переведена для сайта https://vpn.inform.click
Источник: www.wizcase.com

Понравилась статья? Поделить с друзьями:
  • Unexpected error when authenticating with identity provider перевод
  • Unexpected error 485
  • Unexpected error vimeworld
  • Unexpected error 40230 vba
  • Unexpected error 336