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！
Related
I'm attempting to build SAML SSO in Azure AD for an external app. If I try to create a signing certificate, or import a .pfx that I know was created with SHA256, Azure does not allow the selection of SHA256. The option is greyed out and stuck on SHA-1. The Azure AD tenant is part of a large organization. Could this be a global option or something specific to the tenant itself that is limiting this option? Thank you!
I was trying the same but was able to select any of both signing algorithm options.
Thought it was due to expiry date having need to be between three years from uploading as said in this Manage federation certificates - Azure AD | Microsoft Docs .And checked uploading a new certificate with expiry 2031 and with both algorithms sha-256 and sha-1 each time but still was able to get the options for algorithm successfully.
Possible causes:
Older ASA versions may not support SHA-256 cert presented by Azure
Please check if the certificate is uploaded with required algorithm and check by changing expiration date.
Sometimes it may be due to changes taking time to effect in portal .Retry after giving it sometime by closing all.
Incorrect Configuration properties might also be the cause.
Otherwise you can raise a support request from Overview page > Troubleshooting + Support >New support request.
References:
Azure SAML Implementation | Bitwarden Help & Support
Change signature hash algorithm for Microsoft 365 relying party trust - Azure | Microsoft Docs
Configure ASA AnyConnect VPN with Microsoft Azure MFA through SAML - Cisco
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 have an IdentityServer4 Host as our IDP. We have a 4.6 WEB (SPA) calling an API using Hybrid flow (Calling the API by passing the accessToken). Everything is working as expected. Please note that on the API we are using IdentityServer3.AccessTokenValidation package to authenticate with IdentityServer4.
Scenario
Restarting Identity Server 4 Host causes newly logged do users a 401 unauthorized call to the API. We know of 2 solutions how to solve this issue:
1.) Restart the API App Pool (undesired)
2.) In the API, setup of app.UseIdentityServerBearerTokenAuthentication to set AutomaticRefreshInterval to 5 minutes of caching. After 5 minutes, newly logged on users can now retrieve data from the API.
The question is:
1.) Is there another option we can do beside what is mentioned above?
2.) If we do set the AutomaticRefreshInterval to the lowest possible cache value of 5 minutes, can you foresee any potential issues that we should account for? e.g. performance issues, security concerns, etc?
If using a temporary in-memory signing key then you'll get this behaviour. You need to create a persisted signing credential like an X509 certificate and load it when your IDS4 service starts.
Some guidance here: http://docs.identityserver.io/en/release/topics/startup.html#refstartupkeymaterial
See my answer here for a code sample on how to load a cert or certs from the machine certificate store:
How we can replace AddDeveloperSigningCredential on AWS Serverless Lambda environment?
New to Azure AD... So please don't be too harsh if this is off target. :-)
Technology Stack - Latest Angular 2 with C# Middle tier and latest .Net Framework.
Ideally, What we want to do is use Azure AD B2C to store user credentials and to do the authentication - but we want our 'own' forms on our site to do the login Forms capture and logging - then pass the credentials through an API (REST?) Call (using MS Graph SDK?) to Azure AD B2C and then check the call return for the Authorization content message.
Couple of reasons - control of the application flow, Logging and the "flickering of the URL" (i.e. going from our site URL to login.microsoft... URL and then back to our sites URL).
Is this doable without doing a hack?
Thank you in advance for your help and patience!
You are looking for the "Resource Owner Password Credentials".
This is not currently supported for Azure AD B2C, but you can give user feedback to the B2C team that you want this through the Azure Feedback Forum: Add support for Resource Owner Password Credentials flow in Azure AD B2C and headless authentication in Microsoft Authentication Library
You should also see updates at that location if and when they implement this feature.
The resource owner password credentials flow is now in preview.
In Azure Active Directory (Azure AD) B2C, the following options are
supported:
Native Client: User interaction during authentication happens when
code runs on a user-side device. The device can be a mobile
application that's running in a native operating system, such as
Android, or running in a browser, such as JavaScript.
Public client flow: Only user credentials, gathered by an application, are sent in
the API call. The credentials of the application are not sent.
Add new claims: The ID token contents can be changed to add new claims.
The following flows are not supported:
Server-to-server: The identity protection system needs a reliable IP
address gathered from the caller (the native client) as part of the
interaction. In a server-side API call, only the server’s IP address
is used. If a dynamic threshold of failed authentications is exceeded,
the identity protection system may identify a repeated IP address as
an attacker.
Confidential client flow: The application client ID is
validated, but the application secret is not validated.
From here.
Note that one disadvantage of doing what you're requesting is precisely that you can do "login forms capture and logging", so your application has a chance to see the credentials and perhaps take copies of them; thus your users have to trust you to behave.
The normal web-based flow means that your application doesn't need to be trusted; it never even sees the password at all.
My current setup is a fairly simple one. I am running Identity Server 3 which is used to provide oauth access tokens which can be used against and a number of our web api endpoints. The identity server has custom user service which authenticates requests against a custom user table in our sql database.
We have a new 3rd party software provider, this provider requires that our users (staff in our call centre) logon to their application via a proprietary login, not against our existing user accounts. We have built an api for this 3rd party which they required for their integration, as with the rest of our api's this is secured using oauth bearer tokens via identity server.
Our staff are all locally logged on to an active directory domain. Is it possible to configure identity server to issues auth tokens for a user who is already authenticated against active directory? I like to achieve this without prompting the user for their credentials again.
I've read around and at this point I'm very lost as to the correct approach, some form of federation seems appropriate, but I couldn’t find a reasonable introduction / walkthrough to help me get started.
What is an appropriate approach and are they any relatively easy to consume primers on the subject?
Yes, you should be able to make it work. The samples contain a windows auth provider. Using this, your identity server would authenticate people in without prompting for a password. Once authenticated, it would then issue tokens same as any other auth. You may need to a bit of experimenting to get it working, but from what you've said it should work in your situation.