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).
Related
I have been trying to understand when to use OAuth vs SAML. Several sites, including this one -- https://dzone.com/articles/saml-versus-oauth-which-one, say when a mobile device is involved, OAuth 2 is preferred ("If your usecase involves mobile devices, then OAuth2 with some form of Bearer Tokens is appropriate"). But from what I am reading about SAML and OAuth, they accomplish two different things. SAML is used for single sign-on while OAuth is used for accessing specific resources (as opposed to creating a user session in another system). So I'm not clear on why the device the end user is using should affect the decision of when each protocol is used. Do I have this right?
For SSO, use OpenID Connect which sits on top of OAuth.
Using that gives you the full range.
This is better than SAML because:
SAML requires greater cryptographic functionality
SAML requires browser redirects (not suitable for mobile applications)
OIDC uses REST - much simpler
API calls require OAuth token. Won't work with SAML token.
I am working on a skill where i want to link the skill to a 3rd party api. The issue is the 3p server does not have Oath enabled and works off on username/password authentication.
I wanted to understand what are my options here. Can i create a middleware which works on oath authentication and then calls the api via username/password?
Any pointers on this would be great to help me move forward.
Amazon's account linking system is made mainly for services with OAuth 2 authentication, or no authentication at all. It doesn't support services that require authentication that cannot support the OAuth 2 standard.
Since you don't control the 3rd party API your options are, hence, more limited.
Technically speaking, it is feasible to create your own 'middleman' credential service, which implements OAuth 2 and serves as a proxy to talk to the external 3rd party API. However, this would violate Amazon's security policy, which states: "you may not handle, store or transmit credentials on behalf of the user." So your skill may not be allowed if you try to do it this way. Even if it were allowed, it's pretty risky storing plaintext credentials on your server for users in this way.
Since (I assume) you don't control the 3rd party API, there's not really any way you can do this with Amazon's account linking feature.
Google supports several identity verification flows for third parties:
https://developers.google.com/identity/choose-auth
Looking at OAuth, the cryptographic primitive is that I can connect using HTTPS and Google can assert to me the identity of the visitor.
This method does not allow me to prove to another skeptic that this certain person completed Google login. This is because HTTPS is plausible deniable.
Is there a different login mechanism for Google where I can prove to a third party that a certain person logged in?
I'm not sure if plausible deniability in the cryptographic sense is applicable to HTTPS - if I understand it correctly you'd need specific support for multiple keys decoding the message in different ways for that, i.e. special software, not just HTTPS.
But regardless, Google authentication (and any other 3rd party identity provider service) fundamentally relies on the trust in the information coming from the identity provider.
If you don't consider the 3rd party identity provider supplied information good enough as proof for another skeptic then you won't be able to use any such identity provider service, you'd have to roll out your own authentication scheme.
I have spent days researching into both technologies but I am still confused.
Thanks
Saml 2.0 is an older standard, invented before single page applications, REST APIs and mobile phone apps. It focuses on web application single sign on and single sign out.
OpenID Connect does web apps too, but adds support for SPAs and mobile apps and handles API security. So in many ways OIDC is the more capable of them.
There are however some things that SAML2 can do that is not in OIDC:
Federations, where one central entity presents an aggregated metadata file containing information about many Identity Providers and applications (Service Providers). InCommon in the US is one. The new European eID system eIDAS is a SAML2 federation too.
Idp initiated sign on - where the Idp is a kind of application portal. Note that this opens to session pinning attacks and is sometimes not appropriate to allow.
Application (Service Provider / Relying Party) metadata that allows the Idp to be configured by importing metadata describing the application.
Note that API security is offered in the SAML2 specs, through the ECP profile but hardly anyone uses it and there are very few implementations.
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.