I have configured Active Directory Federation Service (ADFS) and Web Application Proxy (WAP) with a Non-Claims Aware Relying Party Trust so that I can serve an IIS Web Application to users connecting from the extranet. Keycloak is configured as an external identity provider to perform X.509 authentication of users using a smart card and returning a SAML 2.0 assertion to ADFS. The authorization flow in Keycloak returns the Subject Alternative Name (Other - UPN) as the nameid. A claims rule is set up in ADFS to transform the incoming Name ID value to a UPN, and the domain name of the UPN is replaced with the internal domain name of the intranet.
The final piece of this authentication/authorization scheme is to edit the Active Directory users' UPN to match the incoming UPN, so a kerberos ticket can be granted for the incoming web request.
This all works! Here is the problem:
For users who have not had the final step performed, mapping the X.509 SAN UPN to their Active Directory UPN, the web request returns an HTTP 500 error, and the event log on the WAP records these errors:
Web Application Proxy cannot retrieve a Kerberos ticket on behalf of the user because of the following general API error: The user name or password is incorrect. (0x8007052e).
Web Application Proxy encountered an unexpected error while processing the request. Error: The user name or password is incorrect. (0x8007052e)
Is there any way to customize the error being returned to such a user, to let them know they need to contact their system administrator to have their account configuration updated?
The only powershell error-customization cmdlets I've found don't seem to affect this particular error situation, and it's not particularly helpful to the end user to get a "This page isn't working right now" message.
Related
I have a Keycloak server that is functioning as my identity provider, using X.509 authentication to the users in my realm. I have successfully configured this as an external identity provider (SAML 2.0) to an ADFS server since I'm trying to allow access to an IIS-hosted web application through Web Application Proxy.
My current effort is to configure the claim rules to map the incoming SAML assertion attributes to internal Active Directory user accounts, so that ADFS/WAP can perform integrated Windows authentication internally once the external authentication is mapped to an internal user.
Most of the search results I've found address the exact opposite, assuming that I've authenticated with ADFS and need to map LDAP attributes to an outgoing claim.
Can anyone provide help, or direct me to a good source?
We have a client/server based application that is developed internally. Clients and server communicate over a TCP/IP connection with an application-specific protocol. The clients run on Windows and the server runs on Linux. All machines are in the same Active Directory/Kerberos domain/realm.
Currently, the user enters a username and password when they start the application. The server checks the username and password (authentication). Based on the username, the server also determines access to resources (authorization).
We want to add Single Sign-On (SSO) capabilities to the application. That is, we do not want the user to enter a username and password but we want to automatically logon as the current Windows user.
Of course, determining the current Windows user has to be done securely.
I have come up with the following setup:
I use SSPI (Negotiate) on Windows and GSSAPI on Linux.
When the client connects to the server, it uses AcquireCredentialsHandle (Negotiate) to get the credentials of the current Windows user.
The client uses InitializeSecurityContext (Negotiate) to generate a token based on these credentials.
The client sends the token to the server.
The server uses gss_acquire_cred() to get the credentials of the service. These are stored in a .keytab file.
The server receives the token from the client.
The server uses gss_accept_sec_context() to process the token. This call also returns the "source name", that is the current Windows user of the client.
The server uses the "source name" as the username: the server performs no additional authentication. The server still performs authorization.
This works but I do have some questions:
Is this secure? It should not be possible for the client to specify any other username than the Windows user of the client process. If a user has the credentials to create a process as another user (either legally or illegally) than this is allowed.
Should I perform additional checks to verify the username?
Are there alternative ways to achieve SSO in this setup? What are their pros and cons?
What you've described here is the correct way to authenticate the user. You should not have to worry about the user specifying a different name; that's what Kerberos takes care of for you.
If the client is able to obtain a service ticket, then they must have been able to authenticate against the KDC (Active Directory). The KDC creates a service ticket that includes the user's name, and encrypts it with the service's secret key.
The client would not be able to create a ticket for the server with a fake name, because it doesn't have the necessary key to encrypt the ticket.
Of course, this all assumes that you've set everything up correctly; the client should not have access to the service's keytab file for example, and the service should not have any principals in its key tab except its own.
There's a pretty detailed explanation of how it works here.
I just created an REST API in API Connect and the endpoint works when I test it in the APIC assemble tab. It requires a client id and client secret. When I send a request through Postman, I currently get a “Could not get any response” message from when I try to add them as header values or OAuth authorization. I’m using the request endpoint that’s displayed when I hit the debug button from the successful response on the Assemble tab. Is this the correct endpoint to use? How do I properly include the client id and client secret in a Postman request?
If you get a "Could not get any response in Postman", that means that Postman can't reach the destination of the request.
There are several reasons for that:
Is it an intranet or internet endpoint?
Are you using a proxy? (check proxy config)
Is the hostname resolvable? (try ip)
If it is an https
endpoint, with a self signed certificate, check if you have SSL
Certificate verification enabled (Settings-> general)
On the other hand, to send the client-id and client-secret headers, just click on Headers tab and add both (see the following picture)
Please check the below things to get access to API Connect published services.
Service needs to be allowed to invoke from postman(System from which you are invoking.)
Please check the web-api MPGW service titled in DataPower default domain created when you configure your API connect with DataPower have you created an access control list in the front-side-handler.
Please disable the SSL configuration in the postman, sometime this may create a problem(since the service exposed from API Connect will be with SSL)
From the error you are getting, I suspect there is no connection or only one-way traffic is enabled which means you are blocking response. If there is an issue with the request parameters you are sending, an error will be different saying, wrong client id or client secret.
Testing API which is on-boarded from API Connect will be straightforward or same we invoke other rest services.
Thx Srikanth
I needed to include the client id and client secret in the headers using the correct name for them, which is specified when creating/editing the api under the 'Security Definitions' category as 'Parameter Name'.
I was also hitting the wrong endpoint. To find the correct endpoint click the hamburger icon in the upper left of api connect website, select dashboard, click on the environment you want such as sandbox or dev, click settings, click gateway, then you'll see the endpoint.
I have a external openidconnect identity provider registered with Keycloak. When the client app tries to access the protected resource it gets redirected to KeyCloak login page. On the login page I have the external openidconnect provider buttons enabled. Once the user clicks on the button he is taken to the external identity provider (which is identityserver3 instance). The external provider does authenticate the user and send back a code.
Now the redirecturl for the registered client in the external identity provider is that of keycloak's. So after authentication is successful at the external IDP it send back the code(because it is Auth code flow) to keycloak at a redirect url:
http://localhost:5555/auth/realms/QA/broker/keycloak-client/endpoint?code=7bcf5157105199d50874e64eabf03858&state=wQhNIEKW0Ws6CotZg2EsvOorjDVQlWVvobcM2skPSXo.keycloak-client&session_state=rhgu-BXT8FniG9Z-UARKpp_f-V1nLN-VxFmSE3PSxDg.99b2d903367208e4261fefa475afb1eb
In the URL if you see it ends with endpoint. I don't think that's correct but I cannot change it in KeyCloak (it's disabled) and because of that in the external IDP client configuration.
KeyCloak does not understand above url and errors out with a message "unexpected error when authenticating with Identity Provider"
Isn't KeyCloak supposed to understand the code flow and make another request for token after receiving the code. Then the external IDP will respond with token and Keycloak will send back that token to client(will also store it for future use).
Can someone please share some knowledge on how Keycloak works with external openidconnect ID provider with code flow.
Usually the redirect URI for external identity providers take the form of {keycloak-host}/auth/realms/{realm}/broker/{provider}/endpoint. You have to specify this as the redirect URI when you register your client in the external identity provider. Once the user is authenticated through the external IdP, authorization code will be sent to this url, which in turn will redirect it to the redirect url of your client application (specified when registering the client in Keycloak).
Unexpected error when authenticating with Identity Provider is the general error message sent by Keycloak for several errors that occur during the OAuth flow. You won't be able to determine the actual cause without going through the stack trace or the logs in the prompt.
You are getting this error because keyclaok is unable to get token from identityserver3 by exchanging authorization code. Where did you hosted identityserver3? Does it have a real ca certificate or you are using self sign certificate? Have you configured client_id , secret, token endpoint properly in keycloak external IDP configuration? You can test manually my posting client_id, secret, code (that you received) in token endpoint of identityserver3.
I require help on integration of web service with JOSSO for authentication.
Whenever a request comes from SOAP UI(client) to service, it should be authenticated against an Active Directory server, and if it succeeds then it should hit the service endpoint.
After a long struggle, we came to know JOSSO exposing their login methods as web services also.
But for authenticating against AD, you have to make least two or three web service calls.
Get Assertion Id by passing Username & Password.
Get Session Id by passing Assertion Id.
Get Role information by passing the Session Id.
Just for testing, you can download this wsdl as a project in to SOAP-UI tool and hit to get response.
JOSSO WEB SERVICES WSDL LINK
You can find the same from source code also:
\josso-1.8.3-src\components\josso-ws-v1_2\src\main\wsdl\josso-1.2.wsdl