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.
Related
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
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.
I am using a SaaS application and I want to use our own LDAP to Login to that 3rd party application. I want to provide a link to that application in my Portal. Both the applications are hosted in Cloud and are Spring based.
Please let me know where to Start and how to go about implementing SP initiated SAML.
Thanks!
First of all you need a SAML IDP that authenticates against LDAP e.g. shibboleth.
Then you need a client side SAML stack.
Refer: SAML : SAML connectivity / toolkit.
You could also look at IDaaS e.g. Auth0 or Okta.
I have my own identity authority set up using the Identity Server.
I'm running a native windows application and currently I'm using IdentityModel's OidcClient library to connect on the authority and obtain the token.
I want to add support for Azure AD and since I haven't been able to set-up the application on the Azure AD to use HybridWithProofKey flow, and found this MSAL I've decided to give it a shot.
In MSAL there is a PublicClientApplication class with accepts the string authority in its constructor (source)
When passing my URL in this constructor I imagined it would use the discovery service and found the correct endpoints and to its job. But to my suprise this dont work.
I get following error message:
AADSTS50049: Unknown or invalid instance.
Search on github MSAL for AADSTS50049 returned zero results. I've cloned the project and started with debugging.
I've figured out that the request is sent to my authority url but instead there is a GET request on the
GET https://login.microsoftonline.com/common/discovery/instance?api-version=1.0&authorization_endpoint=https%3A%2F%2Fmyidentityserverhostname%2Fidentityserver%2Foauth2%2Fv2.0%2Fauthorize HTTP/1.1
This request is done in this source and it returns the error above.
So, is MSAL intended to use with non azure authorities?
No. It's a proprietary client library for their proprietary backend.
Yes it can,
You need to use the Azure B2C library, it can be configured with other identity provideer, like facebook, google, linked in etc.
There is also an option to utilise a custom IDP, if it conforms to openId
See here.
https://go.microsoft.com/fwlink/?linkid=854174
Using MSAL.NET with a non-MS OpenID Connect provider is unnecessary, as Microsoft.AspNetCore.Identity provides sufficient support for social logins and other OIDC providers.
Also vendors of custom OpenID Connect servers provide own extensions (see IdentityServer docs and OpenIdDict samples).
As per this official example, MSAL is not required if you're only signing users in. They claim:
MSAL is used for fetching access for accessing protected APIs
BTW, if you're interested in MSAL.JS, then it's a completely different story – https://stackoverflow.com/a/73618966/968003.
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).