I have a .cer file for each of my IDPs and I have a .pfx for my service. All seems to work fine but if I comment out the lines that adds the certificates to the signing keys (either the IDP or SP certificates) it still works. Looks like they are not being used to me... What test can I do to ensure we are using the certificates to validate responses?
UPDATE: So I have two IDPs configured. The sustainsys stub and Azure AD. Both work well but if I remove the sustainsys certificate all still works fine. If I remove the Azure AD certificate it stops working. How do I control this behaviour?
UPDATE: After checking Katana logs its clear that the Azure AD integration does not work when you do not assign the Azure AD certificate. But why does the sustainsys stub still work?
I worked out you cannot control the behaviour - the Sustainsys library will automatically handle signature validation. The reason why the Sustainsys IDP would work when I commented out where I add the certificate is because I set the federation url which enabled the Sustainsys library to go and fetch the certificate automatically. Once I commented the federation url out, the SAML integration to the Sustainsys stub stopped working. Once it stopped working I assigned the wrong certificate to make sure it would still fail. Then after that I assigned the correct certificate and can see all is working only with the correct certificate.
Related
I have an issue where SSO link based on SAML is failing due to the fact IdP signing certificates are constantly changing.
I (as SP) have a configuration which is based on IdP's federation metadata, it has two signing certificates (X509). Things are working as expected.
Few weeks later, SSO link is broken due to the fact IdP is returning SAML Response with different signing certificate. I checke it's metadata, yep different signing certificates.
How do I implement my end (as SP) that my SAML Request includes x509 being used by IdP?
As well, is it common practice for IdP to constantly change singing certificates? I never had this issue before and I have a handful year-old SSO integration based on the same strategy: exchange of metadata. Is it possible to configure at IdP so that certificates are not being changed?
The IdP is Azure AD.
I (as SP) am using OneLogin PHP toolkit.
My app was configured as non gallery application.
The approach you took - configure non-gallery application give you the full control over the SAML integration. With your full control comes also your full responsibility.
To your question:
is it common practice for IdP to constantly change singing
certificates?
Yes, it is common and good practice. Well, not every two weeks, but at most an year.
Coming back to your changed signing certificate. The link that used in your original question (this one) has an explicit section about certificate. The section is called Review certificate expiration data, status, and email notification. This explains about the certificates. If you continue to read through the same section you will end up seeing another reference: Manage certificates for federated single sign-on in Azure Active Directory, where you will find even more information about certificate management in the IdP side.
We uses Azure AD for the SAML Authentication process. Azure is set up as the trust provider using the Federated Metadata that is published by Microsoft here: https://login.microsoftonline.com/common/FederationMetadata/2007-06/FederationMetadata.xml, we configure X509Certificate value in our system to validate the trust so to authenticate the login. We observe the signing certificate changes, that incurs to the change in the certificate value in turns leads to login issues on our system.
Any clue to fix this? Thanks in advance.
You're right.This is changed by Azure. It's called Signing key rollover. It will affect your application indeed.
For security purposes, Azure AD’s signing key rolls on a periodic
basis and, in the case of an emergency, could be rolled over
immediately. Any application that integrates with Azure AD should be
prepared to handle a key rollover event no matter how frequently it
may occur. If it doesn’t, and your application attempts to use an
expired key to verify the signature on a token, the sign-in request
will fail.
How to resolve this:
I understand what you mean and why. But currently, Azure doesn't have notification for this signing key rollover. I also came across this issue. Acutlly, the best resolved method is make my application to handle key rollover automatically by code.Here is some examples.
Otherwise, you need to write scripts to monitor the chagnes if your application does not support automatic rollover .This GitHub repository contains scripts and instructions on how to do this.
I have reported this issue to the Azure PG Team.
Hope this helps！
I have my own identity authority set up using the Identity Server.
I'm running a native windows application and currently I'm using IdentityModel's OidcClient library to connect on the authority and obtain the token.
I want to add support for Azure AD and since I haven't been able to set-up the application on the Azure AD to use HybridWithProofKey flow, and found this MSAL I've decided to give it a shot.
In MSAL there is a PublicClientApplication class with accepts the string authority in its constructor (source)
When passing my URL in this constructor I imagined it would use the discovery service and found the correct endpoints and to its job. But to my suprise this dont work.
I get following error message:
AADSTS50049: Unknown or invalid instance.
Search on github MSAL for AADSTS50049 returned zero results. I've cloned the project and started with debugging.
I've figured out that the request is sent to my authority url but instead there is a GET request on the
GET https://login.microsoftonline.com/common/discovery/instance?api-version=1.0&authorization_endpoint=https%3A%2F%2Fmyidentityserverhostname%2Fidentityserver%2Foauth2%2Fv2.0%2Fauthorize HTTP/1.1
This request is done in this source and it returns the error above.
So, is MSAL intended to use with non azure authorities?
No. It's a proprietary client library for their proprietary backend.
Yes it can,
You need to use the Azure B2C library, it can be configured with other identity provideer, like facebook, google, linked in etc.
There is also an option to utilise a custom IDP, if it conforms to openId
See here.
https://go.microsoft.com/fwlink/?linkid=854174
Using MSAL.NET with a non-MS OpenID Connect provider is unnecessary, as Microsoft.AspNetCore.Identity provides sufficient support for social logins and other OIDC providers.
Also vendors of custom OpenID Connect servers provide own extensions (see IdentityServer docs and OpenIdDict samples).
As per this official example, MSAL is not required if you're only signing users in. They claim:
MSAL is used for fetching access for accessing protected APIs
BTW, if you're interested in MSAL.JS, then it's a completely different story – https://stackoverflow.com/a/73618966/968003.
I am trying to add a custom domain with SSL in my google app engine project, according to the steps defined here using-custom-domains-and-ssl, i successfully added my domain but when i am trying to add the cert by going to SSL Certificates tap i am seeing a certificate which is already added, now can anyon eplease tell me, can i use this SSL certificate or will i have to add the cert manually by myself.
That would depend on several factors. You should verify the information in the existing certificate is correct before attempting to use it.
If this was a certificate you added previously AND it matches your domain name AND it is not expired, then yes you can continue to use it.
If any of the above is false, you should import your new certificate instead.
I need to invoke a REST-based service from Windows Phone 7.
The service only accepts the request if the following conditions are satisfied:
The request must happen over HTTPS/SSL
The request must be authenticated with a client X509 certificate
I don't control the service, so I can't change the authentication requirements.
On the full framework, we can do things like this:
HttpWebRequest request = (HttpWebRequest)HttpWebRequest.Create(uri);
request.ClientCertificates.Add(accessCertificate);
However, the ClientCertificates property isn't available in Silverlight 4, and neither do any of the X509 classes from the System.Security.Cryptography.X509Certificates namespace seem to be available.
Is it really impossible to make Client Certificate-based HTTPS requests from Windows Phone 7?
Client certificates are not supported by the 3rd party WP7 SDK currently.
Confirmation here for your reference.
Problems with client certification authentication on WP7
Whilst it's possible to install certs on the device through email (referenced in an exhcange integration solution), your app won't use them.
There are only 2 ways to install 3rd party certificates on the device and neither can currently be done through code:
Installing certificates via Windows®
Internet Explorer®
A certificate can
be posted on a website and made
available to users through a
device-accessible URL that they can
use to download the certificate. When
a user accesses the page and taps the
certificate, it opens on the device.
The user can inspect the certificate,
and if they choose to continue the
certificate is installed on the
device.
Installing certificates via email
The certificate installer on
Windows Phone 7 supports .cer, .p7b,
and .pfx files. When installing
certificates via email, make sure your
mail filters do not block .cer files.
Certificates that are sent via email
appear as message attachments. When a
certificate is received, a user can
tap to review the contents and then
tap to install the certificate.
Typically, when an identity
certificate is installed the user is
prompted for the passphrase that
protects it.
You'll have to get the user to perform one of these actions before the app will work with the certificate.
From Windows Phone 7 and Certificates_FINAL_121610.pdf
So you can us oAuth for authentication and pass the token in the request header. If you check out acs.codeplex.com you can see how this is done using the Azure ACS system. I realize you may not be using Azure, but the reference app may help. I would also search for oAuth and Windows Phone 7, I have found a few examples that way too.
As far as SSL, you should be able to do that through the browser with out any issue. You can also open any https Url using an HttpWebRequest, etc.