I have configured the travelocity app to work running on a localhost with the Identity Server running on the local host. Works well
Then I rebuild the travelocity app to work with an external IS - changing the travelocity.properties
SAML2.IdPURL
OAuth2.TokenURL
OpenId.ProviderURL
to point to a public IS with valid SSL Certs
When I supplied https://www.mydomainname.com/commonauth in the Facebook "Valid OAuth redirect URIs" - the travelocity throws up an error "URL Blocked: This redirect failed because the redirect URI is not whitelisted in the app’s Client OAuth Settings. Make sure Client and Web OAuth Login are on and add all your app domains as Valid OAuth Redirect URIs."
with the redirect contain the IP Address of the server rather than the domain name of the server
When I supply the IP address for commonauth, it fails with "SAML2 Response Issuer verification failed " - I am assuming it is because the ssl certs doesn't match the ipaddress.
So why and where is the redirect-uri being converted to IP-Address?
And mainly how can I resolve this?
You need to change the SAML2.IdPEntityId property in the travelocity.properties to match the value of the
Residentity IDP --> Inbound Authentication Configs --> SAML --> SAML issuer value.
After you configure your IS with a hostname.
You can verify the steps you followed with the steps in blog [1].
Related
I have an issue when validating tokens using the keycloak-nodejs-connect library deployed to a kubernetes cluster - specifically when using the internal kubernete's service address for keycloak as the auth-server-url. I am using keycloak version 10.0.1.
Our workflow is as follows - our web app authenticates with a public keycloak client to obtain an access token. This token is attached to requests to the db for data. The db (hasura) uses an auth hook to validate the token before allowing access to its data. This auth hook implements the keycloak-nodejs-connect lib and through the provided middleware calls the grantManager's validateToken. However when the connect lib is configured with kubernete's service address (http://keycloak:8080/auth/) it is guaranteed to error on the issuer match because the issuer property in the JWT token (iss) will be the frontend url configured in the keycloak server (https://keycloak.public.address.uk/auth/).
Is there a way to provide a frontend and backend url to the keycloak-nodejs-connect library so that the issuer validation can occur whilst using the backend url to speak to keycloak via a kubernete's service - or should I be configuring keycloak a certain way so that the issuer is different? I am specifically needing to use a kubernete's service address here rather than a public address for keycloak communications in my cluster.
The following source location hyperlinks try to highlight the issue in code:
nodejs connect server url config (note only one url available used
for both keycloak server communication and issuer validation)
Where the config is applied
Where the token issuer is validated against the configured keycloak auth server
Keycloak server's front end url
One example of how the issuer is set to the frontend url when the token
is being generated
Many thanks for any help,
Andy.
I have configured ADFS 3.0 in my lab and trying to integrate with Salesforece. When I try to access the SalesForce using ADFS. It redirects me to ADFS login page which is expected behavior but after entering the credentials, it automatically redirect to internal IP Address instead of DNS name. I have checked on ADFS server but nothing found abnormal.
First URL (Login Page)
https://adfs.mycompany.com/adfs/ls/?SAMLRequest=
After entering the credentails, redirects to below URL
https://10.25.218.25/adfs/ls/?SAMLRequest=
Please help.
End point URL : https://i.stack.imgur.com/4k1cb.png
I'm trying to do this:
https://dummiesite.com --> http://dummiesite.com
and
http://dummiesite.com --> http://new.dummiesite.com
and
http://new.dummiesite.com --> https://new.dummiesite.com
So no matter what site the user goes, it will allways be redirected to https://new.dummiesite.com
The problem:
With I have a wildcard certificate for *.site.com. But it is only valid for all the subdomains of site.com, not for site.com itself. With lighttpd I cannot use more than one certificate per IP (I have only one), so when the user goes to https://dummiesite.com, it gets an error because the certificate is not valid.
That is why I'm trying to redirect https://dummiesite.com to http://dummiesite.com. How can I do it without a valid certificate and without showing the user errors?
Thanks for your help
You can't with the current certificate. HTTPS is HTTP inside an SSL tunnel, so before you can do the redirect at the HTTP level the SSL connection has to be established. But this fails because your certificate does not match the hostname. You need to get a certificate which includes both *.dummiesite.com and dummiesite.com (yes, this is possible).
If a website is being redirected, does the original domain name need to have an SSL certificate, or the redirected domain name or both?
Both, because the redirection is an HTTP-level thing which happens inside the SSL envelope. The client needs to establish an SSL connection to the original host name before it sees the redirect, then after following the redirect it must establish another SSL connection to the target host name.
If you're redirecting between the www and non-www forms of the same domain, it's often the case that one certificate will cover both (using the "subject alternative name" mechanism). For example, I have a site with a certificate from RapidSSL, and when you ask them for a certificate securing www.example.com they automatically issue it with a SAN for the plain example.com form included. I have a single Apache HTTPD with two name-based virtual host definitions on the same IP address pointing to the same certificate.
In order to secure my Rest Services, I have enabled SSL in IIS and Created a Self-Signed Certificate and assigned it to the HTTPS binding in IIS. I exported the same as pfx file and added the same in IE also but when I try to access the Services, I get the following error on Windows 7, Enterprise edition
HTTP Error 403.7 - Forbidden
The page you are attempting to access requires your browser to have a Secure Sockets Layer (SSL) client certificate that the Web server recognizes.
And on Windows Server 2003, this is
HTTP Error 403.7 - Forbidden: SSL client certificate is required.
Internet Information Services (IIS)
I am not sure what shall I do except adding the certificate in IE under “Personal” and “Trusted Root Certification Authorities”? Could you please suggest me some step, in order to make this work.
Note: I have tried with “Self-Signed Certificates” as well as with Certificates generated from Microsoft “Certificate Services” also.
Any help is greatly appreciated.
SSL is used to verify the identity of the server, not the identity of the client. The error suggests (http://support.microsoft.com/kb/199215, "This is used for authenticating you as a valid user of the resource. ") the server wants to identify the client. Which of the two are you trying to do?
Edit: SSL requires the public part of the SSL certificate to be available to the client. Adding it to the trusted root certificates seems to me to be the only way to make the public part of a self-signed certificate available to the browser.