I am able to communicate to ADFS server and authenticate users successfully. I have a question regarding the endpoint address.
My Question:
When communicating to ADFS , can I provide domain name in the place of address.
https://address/adfs/services/trust/13/UsernameMixed
when I try to enter domain name channel cannot be created. I want to know if I am missing any setting in my server DNS.
When you authenticate you go to:
https://xxx/adfs/ls
You need the same for:
https://xxx/adfs/services/trust/13/UsernameMixed
Related
Requesting for some help here. Kind of stuck with a use case. We are trying to integrate OneLogin with our app via Spring security.
The entry point to our application is Azure App Gateway that routes the requests to load balancer further routing to the VMs where the service is deployed. Everything works fine if we DONOT override the hostname in Backend settings for any incoming request, leading to the App Gateway host only getting passed for every request. Here the App Gateway URL being set as the redirect URI in Spring security auth endpoint call.
The problem appears when the Apigee is used as the entry point to our application. Apigee routes the request to App Gateway routing it further to load balancer and VMs. Here, we DO have to override the host as Apigee host name in order to authenticate the client to the OneLogin server. The Apigee endpoint is set as the redirect URI in the Spring security auth endpoint call.
However, the server responds back with "possible CSRF detected - state parameter was required but no state could be found" error. Tried different possible solutions from other SO links to resolve this error like providing a session cookie name, but did not help. Our OneLogin server and client application are also in different domains.
The only thing that works here is when we DONOT override the hostname in Azure App Gateway Backend settings and pass the App Gateway URL as the redirect URI in auth endpoint call. But the problem is it shows the App Gateway URL in the user browser, which we do not want because in an ideal scenario, the user should see only the Apigee host in the browser url and not the App Gateway host. So, is there any way to re-route/redirect/override the URL to Apigee URL in Azure App Gateway settings without the call being made to Apigee endpoint. Just the user sees the Apigee url in the browser, but internally all calls are made to App Gateway endpoint only.
Or the other solution could be to prevent the CSRF issue when Apigee hostname is used as the redirect URL in the auth endpoint instead of App Gateway host. But not sure how to resolve that.
• In your scenario, when you are not overriding the hostname in the Azure application gateway backend settings and pass the ‘Application Gateway’ URL as redirect URL in the ‘Authorization endpoint call’, the application gateway URL is shown in the user’s browser which is not desired since the Apigee host redirects the authentication requests to the ‘App gateway’ endpoint.
Therefore, without the call to be made to the ‘Apigee’ endpoint, you can surely redirect it to the Apigee redirect URL in the Azure application gateway settings by configuring the ‘Rewrite URI rules’ in the gateway. These rewrite rules will check for any presence of configured URLs or specific paths and will therefore, change the original URI path to the new path configured. As a result, please follow the below given snapshots as steps for configuring the same as stated above: -
Thus, as shown above, you can configure the ‘Rewrite rules’ in a ‘Standard V2’ SKU application gateway for redirecting response requests of ‘authorization endpoint call’ from application gateway URL to the Apigee endpoint hostname configured. In this way, when the application gateway URL is shown in the browser, it will be rewrited to the apigee endpoint hostname’s URL in the browser and accordingly the user at the receiving end will be able to see the Apigee endpoint hostname as a result fulfilling your requirement.
For more details regarding the above, kindly refer the below link: -
https://learn.microsoft.com/en-us/azure/application-gateway/rewrite-http-headers-url#modify-a-redirection-url
Mostly just a question about the next steps to do to figure out why the azure test environment isn't connecting to my specified smtp server. Currently when finishing up my form, its supposed to email the information to a specific email and upon calling that I get a 500 internal server error. I've checked my solution and saw that on my personal ip, i connected and was denied access because my ip is not white listed. All of the outbound ip addresses in the azure environment are whitelisted, but i noticed when doing a ping in cmd to the test environment, I would just get the standard cloudapp.net ip. I've seen people solve this problem with a static ip. Are there other ways to do this without needing a static ip(mostly for trying to keep costs low)?
Thanks!
so the issue was that the outgoing ip addresses didn't match the ip address of the site. It was the external ip in custom domains that needed to be whitelisted in order to work.
I am trying to use the WebSphere Liberty Profile OIDC Client feature. I have the feature installed and configured, but I am confused about what URL I should be using to connect to it. In the WLP Knowledge Center, it shows an example like this:
https://server.example.com:443/oidc/endpoint/PROVIDER_NAME/authorize
But when my WLP server comes up, I see the following URL in the log:
com.ibm.ws.webcontainer.osgi.DynamicVirtualHost I addWebApplication SRVE0250I: Web Module OpenID Connect Client Redirect Servlet has been bound to default_host.
com.ibm.ws.http.internal.VirtualHostImpl A CWWKT0016I: Web application available (default_host): http://ibm669-r9v0dvb:11080/oidcclient/
I don't know whether to use 'oidcclient' (probably) or 'oidc'. I also don't know what to put as the PROVIDER_NAME. I tried using the ID of my OIDCClient:
<openidConnectClient id="oidcRP"
clientId="${oauth.client.id}"
clientSecret="${oauth.client.secret}"
authorizationEndpointUrl="${oauth.authorize.endpoint}"
tokenEndpointUrl="${oauth.token.endpoint}"
httpsRequired="false"
redirectToRPHostAndPort="https://myhost.com:443">
I tried connecting with this, but it's not finding it:
http://ibm669-r9v0dvb:11080/oidcclient/endpoint/oidcRP/authorize?scope=openid&response_type=code&client_id=XXX&redirect_uri=https://myhost.com:443
com.ibm.ws.webcontainer.extension.DefaultExtensionProcessor W handleRequest SRVE0190E: File not found: /endpoint/oidcRP/authorize
Can anyone tell me what URL I should be using to connect to the client?
The Liberty openidConnectClient feature enables Liberty as a client to openid connect provider. The configuration parameters inside openidConnectClient are information about openidConnectProvider, for example, the openidConnect provider's authorization endpoint and token endpoint.
What is your openid connect provider? Liberty also can be configured as openid Connect provider. If you also want to use Liberty as openid connect provider, you can create another Liberty instance and enable openidConnectProvider feature.
I want to be able to get the default credentials from a within a windows service. However if I call
var credentials = CredentialCache.DefaultCredentials;
Or
var networkCredentials = CredentialCache.DefaultNetWorkCredentials;
The NetworkCredential returned (as an ICredential) the UserName and Domain etc are empty. I am running the windows service under a domain account.
If I create a simple console application then a valid credential is returned.
The reason I need this is to be able to set the credentials on a signalR HubConnection. The SignalR service is running in IIS with Windows Authentication enabled. The only way I can see to do this is to set the HubConnection.Credentials property. But as explained above I cannot get the credentials when I am running in a windows service.
Can anyone help?
I found this was not the issue after all and not being able to retrieve the credentials was a red herring (I found I could not retrieve them in the console either), when calling into the SignalR hub the identity is passed and the request authenticated by IIS.
But to conclude. This was my stupid mistake, nothing to do with the default credentials.
As a side note, the credentials are not available to retrieve on purpose see
link
I have created a project in MVC that connects to TFS and brings the work items , i am displaying those work items according to my requirement. My project worked well on localhost , as soon i deployed it on some server , i am failing to connect to TFS , all it says is "Unauthorised".
Any help ?
You are running into the dreaded double hop authentication problem.
In AD you are authenticated by virtue of a Kerberos token. That token is issues to the machine that you are logged into and is only valid on that machine or one it directly connects to.
So you can use your local host token to authenticate to TFS, but as soon as you have a second hop (local->webserver->tfs) your authentication fails.
This is security by design.
To resolve this you need to use SetSPN to create a Service Principal Name (SPN) in AD that allows you to reuse the token on the web server.
You can create an SPN that only works for the webserver but you can't then deploy elsewhere. A better way is to create an SPN for the service account that you run the WebServer AppPool under. Then you can run it anywhere.