I need to integrate PingFederate with Salesforce using SP-initiated SSO.
My aim is that users in Active Directory will be automatically logged in when they access the Salesforce Application URL. I have created the SP connection to Salesforce in PingFederate and uploaded the PingFederate Certificate in Salesforce. In Salesforce I have set the IdP Issuer Entity ID to match the one in PingFederate.
For SP-initiated SSO, which URL do I need to give the browser to test if this setup is working correctly?
I believe SFDC requires you to establish who your IDP is via Unsolicited SSO (IDP-Init) before SP-Init is automatically triggered when you attempt to access a SFDC protected page. Once IDP-Init SSO is completed successfully, SFDC sets your last known IDP as a persistent cookie in your browser.
IDP-Init is pretty simple to do in PF. Just ensure that IDP-Init and SP-Init SSO is enabled in your SP Connection. After that, when you look at the SP Connection Summary page, you should then see a "Connection URL" that looks like -- "https://pingfederateserver.com/idp/startSSO.ping?PartnerSpId=
Give it a shot - if it doesn't work the Ping Support team can quickly help.
HTH -
Ian
Related
I have been looking into using an identity provider (IDP) to provide user authentication for a Windows Forms client. The user credentials will be hosted by Auth0. After creating a trial account with Auth0 I have downloaded a sample C# Windows Forms client application that can be used to authenticate to the Auth0 IDP using OpenID Connect ("OIDC"). The WinForms sample application pops up a web browser component, displays the Auth0 login screen, I login to the Auth0 IDP (having setup some test credentials in Auth0) and the WinForms application then is sent an authentication token. All well and good, and if I try to login a second time I no longer need to enter my credentials.
However... the company that I will be fetching authentication data from in production would like to use SAML. Is there any way to do this? Based on what I have read, SAML needs a "Service Provider" that will receive credentials from the IDP. The Service Provider is (typically?) a web site. That does not seem to match very well with what I am trying to do (authenticate a windows client). Is there any way of using SAML to do essentially what I have done using OIDC (fetch authentication information for a user from an IDP)? Would I need to develop a separate Service Provider component for this?
Sounds like what you've done so far is fine architecturally:
A modern desktop app following OIDC standards
This puts you in a good position architecturally, where:
Your app gets tokens from Auth0 using OIDC
Auth0 can reach out and do federated authentication with other standards based identity providers, which could be SAML, OIDC, WS-Federation or anything else
This can be done without changing any code in your app - and your app does not need to understand SAML
Feels like you need to set up a federated connection from Auth0 to the SAML Service Provider, and most commonly this involves these steps:
You give the partner your Entity Id and Response URL, to post tokens to
They give you am Entity Id, Public Key Certificate and request URL
You configure rules around account linking, so that users can be matched between their system and yours
There are prerequisites though, and the external identity provider needs to be SAML 2.0 compliant. My Federated Logins Article may help you to understand the general concepts, though I do not drill into SAML details here.
Completely new to B2C. Tried both of these walkthroughs, but I'm missing something still:
https://github.com/Azure-Samples/active-directory-b2c-advanced-policies/blob/master/Walkthroughs/RP-SAML.md
http://blogs.quovantis.com/saml-based-sso-with-azure-ad-b2c-as-an-idp/
Both of these only describe the policies needed, but I'm pretty sure I need to register an app on B2C still? The problem I have with app registration is that SalesForce gives me a token endpoint URL with a query string:
https://mycompany.cs79.my.salesforce.com/services/oauth2/token?so=00D1h000000Cnli
And B2C won't allow query strings in the reply URL.
Is there any way around this? Salesforce also supports OpenID I think, if that would be better?
::::::::::::UPDATE 6/22::::::::::
SAML:
I found and realized I was missing a critical step on the SalesForce side: adding the authentication provider to my domain's login page. Clicking the new link redirects me to B2C, but I get an immediate error from B2C. Application Insights shows the following exception:
The SAML technical profile 'serviceProviderMetadata' specifies a PartnerEntity URL of 'REMOVED', but fetching the metadata fails with reason 'For security reasons DTD is prohibited in this XML document. To enable DTD processing set the DtdProcessing property on XmlReaderSettings to Parse and pass the settings into XmlReader.Create method.
OpenID:
Using this write-up as a guideline, I've registered the app in B2C and configured the SalesForce side.
Instead of using the Azure AD authorization endpoints, I pulled my B2C tenants endpoints from my meta data URL (login.microsoftonline.com/{tenant}/.well-known/openid-configuration).
This works for my B2C admin account, however, when I try try a test user that isn't a B2C admin I get the following error from the B2C sign-in page:
Sorry, but we’re having trouble signing you in.
AADSTS50020: User account 'REMOVED' from identity provider 'LINK REMOVED' does not exist in tenant 'MTB2CTest' and cannot access the application '5c8b9f4f-cf28-42fe-b629-b87251532970' in that tenant. The account needs to be added as an external user in the tenant first. Sign out and sign in again with a different Azure Active Directory user account.
::::::::::::UPDATE 6/23::::::::::
OpenID:
I’ve found that it works 100% only for my B2C admin account if I don’t use a policy, but doesn't work for other accounts. When I use a policy, only accounts that signed up through the policy can authenticate with B2C (which is great) – but the token doesn’t seem to be reaching SalesForce. I've created two PDFs showing the configuration details and the results from each method (policy and nopolicy) here.
Both of these only describe the policies needed, but I'm pretty sure I need to register an app on B2C still?
Not exactly, you no need to register an app at B2C side. All the configuration you do in Policies is enough.
Did you try Salesforce SAML SSO article https://help.salesforce.com/articleView?id=sso_saml.htm&type=5
Check the above article and try to do configurations at Salesforce side and grab the details required by SAML RP
I hope by following both SAML RP and Configure SAML Settings for Single Sign-On articles you can configure B2C as IDP for Salesforce.
I stumbled on this question while trying to implement Azure AD B2C as an IdP for Salesforce. We used Open ID Connect to enable SSO between the two. This involved setting up an Application in Azure AD B2C, enabling the read scope on that application, and configuring the connection in Salesforce using that application, a custom policy returning a JWT token, and a dummy User Info endpoint.
Check out this answer for exact steps on how we set up Open ID Connect: https://stackoverflow.com/a/61639332/13484109
We have been assigned a task, where we should integrate data from client's Active Directory on weekly basis. Currently we have working Single Sign On implemented with SAML with them. What would be the best approach to handle this situation? I'm still fairly new with SAML, so is it possible to access client's AD with SAML or should it be done with e.g LDAP instead?
All answers are much appreciated
- Andy
SAML is just an XML vocabulary. It has no functionality such as being able to connect to AD and search for users. That's what the Identity Provider (IdP) does. The IdP connects to AD, usually via LDAP, queries the attributes for a user and converts them to SAML format. It then sends the SAML, containing the attributes to the Service Provider (SP).
The point of SAML is the SP doesn't need integration, it just accepts SAML using SSO. So when a user logs in to the SP, the SP redirects them to the IdP, which authenticates them and redirects them back to the SP with their SAML attrobutes.
If you need to export all users from AD on a weekly basis you can just use LDAP and you don't need SSO.
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.
I have a basic question regarding SAML2. Typical flow is that user requests a resource from SP that is protected. SP checks if the user has a security context (say cookie ?), if it does not find a security context, it constructs the AuthRequest and then redirects the browser to the IdP. Now IdP likewise first checks if the user has an existing security context. How does the IdP do this? Does the IdP also use a cookie for this purpose?
Yes. For SAML Web SSO Profile the session is almost always kept as a cookie in the browser at the IDP and SP. However, there are no rules on how to manage this. The IDP could choose to not keep an active session and prompt the user to login for each SSO transaction.
Ian
#Ian - Great Answer. However if the IDP does not maintain a session cookie [B/W Browser and Identity Provider (IDP)] than you miss out on a significant benefit of single sign on (SSO). The SSO User Experience (UX) feature that would be lost is described in the following scenario:
0) Assume IDP is registered with Google Apps and Salesforce.
1) Open Browser. NOTE: SAML is browser based. You need a browser for SAML to work.
2) Try to go to Google Apps; (you have no existing session cookie [B/W Browser and Google Apps]) who then Re-directs you to the IDP.
3) You sign on with your valid IDP credentials.
4) the IDP then stores a session cookie [B/W Browser and IDP] in your browser. (This is the step that #Ian mentioned can be skipped by the IDP)
5) The IDP then redirects you back to Google Apps (via HTTP POST) with SAML token embedded in the POST. You are now in Google Apps. (Now you have a session cookie [B/W Browser and Google Apps] stored on your browser)
5) Try to go to Salesforce.
6) Salesforce sees you have no active session cookie[B/W Browser and Salesforce], so they redirect you to the IDP.
* here is my point of added User Experience (UX) *
7) The IDP will look for a session cookie [B/W Browser and IDP], if the IDP is configured to not store maintain one you have to enter your Single Sign On (SSO) aka IDP Credentials AGAIN.
Discussion on Step7: Entering the SSO credentials for each separate service an extra-step times the number of services you are using. I think the main draw of the implementation is to enter credentials only once and get access to everything (the topic of security aside). However if the IDP does not store a session cookie [B/W Browser and IDP] you are still only using one set of credentials (instead of separate credentials for each service), so life is still easier.
#Ajava - You seem to be confused as to how cookies are used. I hope you can follow my steps above and get better idea of how cookies are used with SAML.
Here is also a good link i found that explains cookies: http://lifehacker.com/5461114/fact-and-fiction-the-truth-about-browser-cookies