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.
Related
I'm planning to federate external Identity Providers (Google,Microsoft,GitHub,...) to my applications.
In my applications for security reasons we want MFA to be enabled for every user.
Is there any way to detect if the user authenticated himself using "Google" with MFA?
I understand that federating an external Idp, the user identification responsibility is transferred to the external Idp, so I doubt that what I'm asking would be possible.
Thanks in advance.
OaicStef
P.S.: In my applications, I manage the authentication with Identity Server 4.
The amr claim is what you're looking for but it's optional so it's not for certain that all providers will provide it and if they do they may provide the data in different ways - e.g. one might return ["pwd","otp"] to describe a situation where a password and a one-time code were used and another may just just use "mfa".
The best thing to do would be to experiment and observe what each service does both with and without MFA enabled and adapt as neccessary.
If it's not something you can guarantee then there's also the option of implementing your own MFA features - libs for using TOTP-based authenticator apps or FIDO2/WebAuthn are readily available.
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.
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).
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.