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.
Related
I am working on a project where we are planning to use SAML 2.0 to send authentication requests to OpenLDAP. Can someone please tell me if its supported or not? I am not able to get the clear answer via Google.
SAML and LDAP are completely different things. SAML is mostly used for Web-based SSO. The identity provider (IdP) part of the access manager software/system you're using (i.e., the one that implements SAML authentication authority) may use a back-end LDAP server (e.g., OpenLDAP) for authenticating users.
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 am quite confused about setting up SAML SSO for an application in Azure Active Directory.
I already have SAML metadata downloaded from the "general" endpoint https://login.microsoftonline.com/[Unique_ID]/FederationMetadata/2007-06/FederationMetadata.xml
However, when I configure my application in AAD, it sets up a signing certificate for the application and there is another link to SAML metadata, which slightly differs from the first, "general", metadata:
The general one contains 3 signing certificates, while the concrete application-specific metadata contains just one: the certificate configured especially for the application on AAD side. The application-specific certificate in not any of the 3 certificates from the general metadata.
The general one is digitally signed, the specific one is not.
Both have the same Entity ID.
I am quite confused about this concept, I haven't seen it on any other IdP server yet. I have already realized I must use the application-specific metadata to configure my Service Party, otherwise the digital signature of SAML assertions will not be verified.
So, my questions are:
Why does AAD provides the option to have application-specific signing certificates and SAML metadata? Why can't I simply use the global metadata/certificates and have all assertions for all applications signed with the same certificate?
Is it somehow possible to disable this feature and only use the global metadata for all Service Parties? The benefit would be clear: having just one IdP metadata instead of N.
Why does AAD provides the option to have application-specific signing certificates and SAML metadata?
One reason this is useful is that you control the certificate rollover. (Not all apps are "well-behaved" and deal correctly with planned certificate rollovers.)
Is it somehow possible to disable this feature and only use the global metadata for all Service Parties?
Sort of.
If you create a new App registration (as opposed to going via Enterprise apps > New app > Custom app), you can do SAML 2.0 against that app, with the details exposed in the "global" federation metadata.
The downside to this approach is that you won't get access to the Enterprise Apps > (app) > Single sign-on section, so you won't be able to do things like choose which attribute is used as the NameID, or have a UI interface to do claims customization (though you can still do custom claims mapping policies).
Sorry I am still very confused, read everywhere telling me oath is a authorisation protocol but it appears using the azure ad oauth code grant, it does promote a login screen to authenticate against the directory, so is it not an authentication process? what is the relationship between the open id connect? thanks!!
the OAuth2.0 protocol has several flows that an identity provider (in your case Azure AD) may implement to support auth.
The Auth Code flow is in fact one of these used by apps to get access tokens for some api. The flow is quite simple, an app redirects the user to the identity providers /authorize endpoint. At this point the user enters their credentials, and the site redirects back to your application with an authorization code and can also issue an ID Token that represents a user (This is the OpenID Connect part). The app takes this code, and POSTs it to the /token endpoint and will be issued an access token and refresh token. With the access token, your app can access whatever api you've requested access for.
For Azure AD specifically, Microsoft has built libraries that handle all these flows and token caching so most of the complexity is abstracted away. There's some simple code samples that you can checkout that you may find helpful. The authentication protocols and scenarios doc for Azure AD may also be really helpful for conceptual information.
What's the difference between WS-Trust, WS-Fed and SAML 1.1/ 2.0 protocols?
My understanding on these protocols gets confused when SAML is used as a security token in WS-Trust and WS-Fed protocols.
Interested in knowing in which scenario these protocols used and what makes them different. Your answers will be easy to understand if NO commercial product/ technology references used.
At a high level, WS-* protocols traditionally were used by Microsoft.
SAML-P (P for protocol) was used by the open source movement and hence Java.
WS-Fed has two profiles - active and passive. Active is for WCF (WS-Trust), passive is browser based (WS-Fed via login page).
Both of these use SAML tokens.
Functionally, both WS-Fed and SAML do the same thing wrt. federation
If you federate two ADFS (Microsoft IDP) together you use WS-Fed. If you add in Sharepoint, it also uses WS-Fed. The tokens passed are in the SAML token format.
If you have a Java application that uses Spring, then that will hook in to ADFS via SAML-P. The tokens passed are in the SAML token format.
this question is old but i struggled finding a correct answer online.
A lot of online posts say, that 'passive / browser' clients use WS-Fed and 'active / smart' use WS-Trust. That is probably because the active use case uses by default a url like '/ws-trust/2005' or '/ws-trust/v1.x/'. This does not seem to be 100% accurate. The great and free book: Claims-based Identity, Second Edition helped me with the issue and I finally found a satisfying answer:
The goal of many of these architectures is to enable federation with either a browser or a smart client. Federation with a smart client is based on WS-Trust and WS-Federation Active Requestor Profile.
These protocols describe the flow of communication between smart clients (such as Windows-based applications) and services (such as WCF services) to request a token from an issuer and then pass that token to the service for authorization.
Federation with a browser is based on WS-Federation Passive Requestor Profile, which describes the same communication flow between the browser and web applications. It relies on browser redirects, HTTP GET, and POST to request and pass around tokens.
SAMLP is just a different protocol when it comes to how things are communicated such as the redirection URL and so on, but the differences are not relevant (in most cases) and simply depend what the client supports (e.g. Java will use SAML). The biggest difference is in my opinion that SAMLP allows an Identity Provider initiated Use Case (which is the most secure one in my opinion), where the User starts on the Identity Provider (e.g. the Web Proxy of your ADFS Server, =Claims Provider in MS terms), instead of starting at the Web Service and then getting redirected to the Service Provider (=Relaying Party in MS terms). Also when we are talking about SAML we usually mean SAML 2.0 while WS-Fed uses SAML 1.x Tokens (and MS calls them Tokens, SAML calls them Assertion... its just a signed and possibly encrypted XML, I think theoretically you could use other Tokens in WS-Fed then SAML but i have never heard of anybody actually doing that).