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).
Related
I have an existing IdentityServer4 installation that is used to federate users between things like Google & Microsoft into a single login identity. In my situation, there are no local user credentials/passwords. Just the identity with an associated external provider. I'm trying to migrate to using Azure B2C and am hitting some roadblocks.
I've found that if I use the same ClientId and ClientSecret that IdentityServer is configured with, then I get the same IDs for users when signing in via an external identity provider. Which is great because I need them to be the same in order to try and migrate accounts over by reading them from the existing MSSQL database, and importing into Azure B2C using MS Graph.
I need to allow both Microsoft work accounts, as well as personal ones. So I need to use custom policies to allow for a multi-tenant configuration, since the built in provider doesn't support this.
However as soon as I flip my implementation over from the built in user flows and provider, to using custom policies, I don't get the expected issuerAssignedId anymore. Originally, the IDs looked something like AAAAAAAAAAAAAAAAAAAAAHGFdaj94jfdsgjifdh4ngd (made up, but you get the idea). Now with the custom policies, the issuerAssignedId being recorded in the B2C user looks like a GUID. So not just a different value, but a total different format. Am I missing something here? What would happen if someone has an fully operational AzureB2C install with built in functionality, and later identified a need to move to custom policies. How would users ever be able to look into their existing accounts with an external identity provider?
My TechnicalProfile for the multi-tenant sign is is essentially copy/pasted from their documentation, so I'm not sure what the deal is here?
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.
I have configured Azure B2C as IDP via SAML successfully for a single Service Provider. There are many pieces that i don't understand in this setup even though its working.
I will describe what i have so far and then ask questions later.
Let's say I have two Service Providers,SP1/SP2 both require SAML and a page to signup/signin. SP1 requires loyality_id as custom attribute and SP2 requires product_name attribute.
Here's the source code that works.
Credit/Thanks to this blog
Below is the high level summary of the configuration.
SAML for SP1 (Service Provider 1):
Add signing and encryption keys to the B2C tenant
Register Identity Experience Framework applications
Create web app IdentityExperienceFramework in Azure Active Directory
Create native app ProxyIdentityExperienceFramework in Azure Active Directory
Start from starter pack for LocalAccounts as base
Add Saml2AssertionIssuer to the base policy
Add user journey SignInSaml to the base policy
In Extension Policy override "Local Account SignIn" claims provider and add substitute values for "client_id" and "IdTokenAudience" from apps that were created earlier
Policy file with RelyingParty for SP1
This describes the output claims that are added to the SAML response
Signup/signin policies for SP1:
Create built-in signup and sigin policy
Create Application in Azure B2C blade
So far with this setup, I have two Applications in Azure Active Directory for custom policies and one Application in Azure B2C blade for built-in policy.
According to https://learn.microsoft.com/en-us/azure/active-directory-b2c/active-directory-b2c-create-custom-attributes-profile-edit-custom,
Extension properties can only be registered on an Application object
even though they may contain data for a User. The property is attached
to the application. The Application object must be granted write
access to register an extension property.
What is the "Application" the above paragraph is referring to?
What is the purpose of the apps IdentityExperienceFramework/ProxyIdentityExperienceFramework
To setup for SP2, do I need to create separate Azure Active directory apps for IdentityExperienceFramework/ProxyIdentityExperienceFramework? Or can I use the same ones? How do custom attributes factor in this?
How do I setup custom attributes in this case where SAML is through Custom policy and Signin/Signup is builtin policy
In this case, under what App context are the custom attributes created?
I appreciate any pointers.
Thanks
The application is the one created in the section "Creating a new application to store the extension properties".
The apps purpose is to enable sign-in using local accounts. The same apps can be used accross multiple policies.
Custom attributes are related to the application created in app registrations at Azure AD level, and with the permissions detailed in the configuration docs.
In my Github profile, you can find a different implementation of the B2C as SAML issuer scenario: https://github.com/marcelodiiorio/My-Azure-AD-B2C-use-cases.
Tell me if you have more questions.
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).
I was just playing around with OpenAM and found that authentication can be done through SAML as well as cookie based approach of CDSSO. Now my concern is if I am working in domain like banking and healthcare how feasible it would be to go for CDSSO cookie based approach and is their any organization who is practicing cookie based approach in any such domain.
SAML is designed for connecting independent security "domains". The term "domain" in this instance has nothing to do with network domain names, but a rather more nebulous term, meaning a division between security systems. An example to explain a bit better: Company A uses OpenAM to protect its intranet websites, but they also use services from Salesforce. SAML is the obvious choice here - Salesforce isn't going to use a cookie from OpenAM... How could they? You could also use it to interconnect two different systems inside a company (and domain name), like OpenAM and Siteminder, since those two systems can't communicate directly via their cookies.
CDSSO is primarily designed for use inside an organization that could have multiple domains that they protect. They can have multiple policy servers in multiple domains, but all of those servers are managed by the same OpenAM instance, and they all share a common backend. Lots of organizations use OpenAM's (and OAM's, and Siteminder's) CDSSO capabilities. But they use it inside the systems within their control.
In addition, I can't think of a single service provider that would want you to place one of your OpenAM policy servers inside their network. You wouldn't want them touching your server, and they wouldn't (if they are right in the head) trust you to not be dropping a trojan in their network.
TL;DR:
SAML - outside of an administrative domain
CDSSO - inside an administrative domain
SAML is the standards based way of achieving SSO for, Agents is the proprietary way.
SAML does not offer any authorization (which user is allowed access to a given resource) out-of-the box ... that's the backdraw.