Shibboleth 3 Idp using ws-fed - saml-2.0

We have Shibboleth 3.4.4 as Idp for Azure, and it works perfectly by using SAML when it comes about logging into the portal. But when we try to enroll Windows 10 devices into AAD we have the problem that it only works if the Idp is able to speak ws-fed and ws-trust
https://learn.microsoft.com/en-us/azure/active-directory/devices/hybrid-azuread-join-federated-domains
We couldn't find the way to make those protocols work with shibboleth.
Is there any tutorial or example, or walkaround that someone has been able to use in any place?
If it is impossible to do with Shibboleth Idp, it would be nice if someone knows other free idp which speaks those protocols.
Thanks in advance!

Shibboleth doesn't support WS-Federation as an identity provider.
You can give Keycloak a shot, it supports WS-Fed passive profile (with some additional limitations) via an extension. This may or may not be enough to manage enrollment of W10 devices into AAD.

Related

Standup a custom SAML IDP

In our organisation we implemented support for OIDC and OAuth2 support recently and we used the node-oidc-provider library to support the same. This way our product acts as an IDP that support Open IDC. We were also able to integrate our product as an IDP into our organisations instance of okta for certain scenarios.
In the same way we are planning to support SAML2 implementation in our security product that currently only supports OIDC. Is this possible and if so is it worth implementing SAML support? One of the reason to support SAML is so that we can talk to snowflake where Azure AD will use our SAML IDP to authenticate users and then provide access to snowflake.
Or the other way is to use Okta as a SAML provider and talk to snowflake. The flow would be users connect to okta and then okta will redirect certain users with a certain domain to our IDP (Supporting Open IDC) and then once that succeeds okta will use SAML to talk to Azure AD which in turn will provide access to snowflake.
Please suggest a good way. If you say we can integrate SAML support also into our existing Open IDC supported IDP what is the best library to use for nodejs.
Thanks

Why Saml is the default option for registering Salesforce as an Enterprise Application is AAD

I am trying to integrate Salesforce with AAD, so I see two available options, either Saml or OpenId Connect.. I do not know which one is better, but I prefer OpenId Connect since it seems to be more modern. So I tried to register Salesforce App in AAD and Saml was the default options, so why is Saml the default option ?! is it better or what? Please note that I am building an API and I need to allow authentication and authorization with Single Sign On.
The Azure AD app gallery contains many popular applications that are already pre-configured to work with Azure AD as an identity provider. These applications will be available in the Enterprise applications and have SAML to perform SSO. Any application which is added directly from the Gallery the default method is SAML based SSO , password based SSO etc.. which depends upon the applications.
Kindly check the difference between the App Registration and Gallery application in Azure portal from the link
In order to get more detailed explanation about SSO types and protocols kindly check the document to get more detailed explanation.
If you have any further queries kindly let me know.

Does LDAP support SAML 2.0 requests?

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.

Can an azure active directory domain be federated with an openid connect IdP like identityserver and does this support Azure AD Join

We currently have a solution where azure ad domains are federated with our ADFS server. This solution uses the WS-Trust and WS-fed protocols. Ws-fed is used for the passive auth flow in the browser, WS-Trust (the usernamemixed endpoint) is used for AAD joined windows 10 devices.
Unfortunately for us, ADFS doen not provide us with all the customization options that we need. Therefore we are looking in to moving to a custom IdP. IdentityServer looks like a good fit. Unfortunately the last version of IdentityServer to support WS-Trust is identityServer2. I'm currently trying to get this to work, but I would much prefer to leave the WS-* protocol behind completely and move to openid connect.
One thing I noticed during my experiments is that the powershell command Get-MsolDomainFederationSettings shows a field OpenIdConnectDiscoveryEndpoint. Does that mean that I can federate my azure domain with openid connect?
Another thing that I noticed is that the azure ad joined windows 10 machine was unexpectedly calling an open id discovery endpoint on my identityserver. That gave a 404 because I don't have it configured. But just the fact that it was called leads me to hope that AAD join could support openid connect.
Is this possible?
The short answer is yes. Both ADFS (2016) Azure AD support OpenID Connect and you can certainly use them as the ultimate IdP in an IDS4 implementation.

Difference between WS-Trust, WS-Fed and SAML 1.1/ 2.0 protocols

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).

Resources