we are implementing SSO solution with our customers.Due to its complex nature and time sensitivity, we employed a third party security partner firm that can act as SP and redirect the request after authenticating the user.
The third party firm is now telling me they are going to send SAML response to our application to further validate.
My question is , Given that SAML response is already validated at our third party provider(who is acting as SP on our behalf), why we(application owner) again have to do SAML assertion?
I was expecting it is going to be a redirect from the third party with some token to validate so that our application can skip the login validation part.
but I wanted to talk to them with research facts and industry practice. Can anyone help? please let me know if i am missing something here.
The usual practice when using such intermediary SP for SSO to (typically a legacy) application is to:
process and validate the SAML Authentication Response and the Assertion at the SP
SP then encodes a cookie on a common domain or a token provided as a request parameter/HTTP header
cookie/token is typically constructed using a symmetric cryptography with a shared secret and e.g. HMAC
SP redirects user to the application which verifies the provided cookie or token and grants access
I don't think you're missing anything. Perhaps your provider just confused things and gave you wrong information. It makes sense to include the SAML token itself in the response from SP to your application (e.g. for audit purposes), but it makes no sense to expect your application to understand or validate the SAML message once it's been done already by the intermediary SP.
Related
Right now I'm rolled in a project where we want to create an SAML IDP with Node.
Problem:
We have a system that implements an API REST and this API authenticates users, its response has the information of the authenticated user... just as an API response (nothing about SAML).
The point is to aggregate the responses from the API in a SAML IDP system, where some SAML requests (XML) arrive from Service Providers. The SAML IDP system internally queries the API, gets the authentication information, and responds as a SAML Response (XML) to the Service Provider.
I was looking for easy solutions for this problem like Okta, OneLogin, but the problem is that those companies authenticate the user and the one who authenticates in my system is the API, I can't change that because the project was defined as that.
My question is:
Do you know about a system that provides SAML configurations but authenticates with an external API?
We are using samlify Node Library to attack this problem, do you have information about the performance of this library?
Do you have any idea how to solve this problem easily?
We are planning to deploy with lambdas is this a good practice for this kind of problem?
I'm not an expert about SAML so if you have documents about creating a SAML IDP or any help would be useful.
Thank you for reading and sorry for my English.
Do you know about a system that provides SAML configurations but authenticates with an external API?
First, you have to remember that SAML is a protocol; it's the language that a service provider may choose to speak to the identity provider. The task of validating user credentials and authenticating a user is entirely separate from the protocol. An SP may choose to send a SAML authentication request to an IdP, and the IdP is free to authenticate the user however it sees fit. The two usually have nothing to do with each other.
Second, there are plenty of IdPs that allow you to:
Turn on the SAML2 functionality so the IdP can speak the SAML2 protocol.
Validate user credentials using a custom REST API. The IdP would reach out to your API to validate the credentials it receives from the user, and would the finally produce a SAML2 response back to the SP.
An example of such an IdP would be: https://github.com/apereo/cas. It allows you to have it act as a SAML2 IdP and supports a REST API for user authentication.
While it may not 100% fit your use case OOTB, it's a good starting point. You should never begin from scratch and re-invent the wheel. To "create a SAML IDP that authenticates with an API from scratch" is generally a good way of asking for a lifetime of punishment.
PS Your other questions should likely be posted as separate posts/questions.
I am developing a SPA application in angular and I have a lot of confusion about the correct way to implement authentication and authorization.
First of all, the application is a first-party app, which means that I am developing both the authorization server and resource servers.
The users that logs in the application must have full access to their resources on the platform.
So, I am doing it using OAuth2.0 and I have a couple of doubts about the domain of the protocol as well as security concerns.
First question:
The first question is if OAuth should be actually used to authorize first party applications. From my understanding this is a delegation protocol used to grant a third-party application controlled access to the user's resources on the platform, upon user consent. How does this fit in the context of a first-party app? In that case the app should get an access token with a scope that allows full access, right?
Second question:
Since this is a Single Page Application I couldn't store a secret on client side. So I am opting for using the authorization code grant with PKCE which would seem to be appropriate to manage this scenario. In this case I wouldn't ask for a refresh token but I would only retrieve the access token and using silent check to refresh it. I do not want to have refresh token insecurely stored on the browser. Is this PKCE really secure? The secret is generated dynamically but a attacker could eventually create a system using the same public client id and managing the PKCE properly, and finally get an access token that, in my case, gives full access to the users resources.
I could in the future allow controlled access to my app's resources to third party app, that's also one of the reason why I stick with OAuth.
The first question is if OAuth should be actually used to authorize first party applications. From my understanding this is a delegation protocol used to grant a third-party application controlled access to the user's resources on the platform, upon user consent. How does this fit in the context of a first-party app? In that case the app should get an access token with a scope that allows full access, right?
Yes, this makes sense to me. We skip the 'grant permissions' step for our own apps.
Is this PKCE really secure?
Yes, even without PKCE, authorization_code is pretty secure. Adding PKCE solves a a few potential security issues, but I would be somewhat inclined to call them edge cases. It is definitely right now the recommended choice.
The PKCE rfc has more information about the motivations behind PKCE:
https://www.rfc-editor.org/rfc/rfc7636#section-1
I actually came here looking for the answer to Question 1. My take is that in situations where we have no third party apps requiring access to our APIs we do not need OAuth. If we still need to use OAuth, then we can use Resource Owner Password Flow for first party apps. I have not seen any convincing answer anywhere confirming or rejecting this opinion but this is purely based on my understanding of OAuth.
Now, I am mainly writing this to answer Question 2. PKCE protocol is secure and attacker would not get token in this scenario. The reason is that the Authorization Server uses pre-registered "Redirect Uri" to send the token to. To be precise, the Auth Server would simply ask the browser to redirect user to "Redirect Uri appended with Access Token". Browsers do not allow javascript interception of Redirection requests. Therefore, an attacker would not be able to get hold of the token and the user will be redirected from attacker's site to yours at the end.
My Node.js (MeteorJS) site will be interacting with a 3rd party platform via SSO using SAML 2.0 (their requirement). Essentially, when a logged-in user (on my site) clicks a specific link on our site, we're supposed to create a SAML token (with some specific attributes related to the user, in addition to required SAML 2.0 ones) and then POST it to the 3rd party platform's URL. They will process the token and then send a redirect to the user's browser, which will redirect the user to the 3rd party platform's site with the user being logged into the 3rd party platform's user account without the user having to log into that system, specifically. (Sorry for the re-stating of SSO basics, but I just want to be thorough to explain our the situation at hand).
The 3rd party platform is acting as the Service Provider (SP), and they have provided me with the payload attributes I need to add to the SAML Assertion (unencrypted is fine) to properly log the user into their system.
I have asked the support team at the 3rd party platform some questions about what I need to do on my side to set up the SAML engine. I have never used or implemented SAML before, so I'm learning on the fly and researching everything I can find heavily. Anyway, the support member said the following:
Your SAML engine (acting as the IDP) creates your SAML token and that
token is just posted to the [3rd party platform's] endpoint. From
that point you’ve given all control to [the 3rd party platform] and we process the token with intent to return the redirect back into your browser window.
Since we're acting as our own IDP (we know who the logged-in user is, and we know the information that we need to send over in the SAML token based on their user account), it appears that all I need to do is create a SAML token with the appropriate attributes and just HTTP post it programmatically. Am I missing anything?
With SAML being an "older" technology and Node being a "newer" one, the documentation on implementing a SAML engine in Node is quite sparse. Most everything I see regarding SAML and Node (here on S/O and elsewhere) usually points to passport-saml, and the like, with some vague examples related to token authentication and IDP endpoints. From what I'm gathering, it seems like most all of that is overkill for what I need to do, but being a complete SAML newbie, I'm not totally sure and I'm looking to you all for your guidance.
The abridged version of my question is:
If I just need to POST a SAML token in a Node environment, is it as simple as creating a token with the payload attributes and setting that token programmatically in a FORM where the action is the URL provided by the 3rd party SP and the response is the SAML Assertion token? Also, what recommendations do you have for Node libraries (or at least examples with details) that would create that token for me? Most all examples and libraries I see appear to be overkill for what I actually need to provide, but having no reference to compare against, I'm not sure.
Many, many thanks to anyone who can help me out with this one!
I am working on asp.net web api 2 and used JWT for authentication. The application is working fine as it generates token on login request from user, and then user can use that token for subsequent request. But I have some security concerns like
What if the token is stolen from user's browser, How can server detect a valid request among two requests sent from two different computers.
When user will sign out, how server can detect that this particular token is now invalid/loggedout. As I read about log out, it is merely deletion of token from client browser, so stolen token will still be there, requesting from other pc.
How can server revoke a token when expiration period reached?
Please comment if my question is not clear.
Please find the answers as below:
1) Access tokens like cash, if you have it then you can use it, if you have valid access token there is no way to identify if the request is coming Authorized party or not, thats why HTTPS must be used with OAuth 2.0 and bearer tokens.
2) Self contained tokens like JWT are not revocable, so there is no DB checks and this is the beauty of it, you need to leave those tokens until they expire. If you used reference tokens then you will be able to revoke them, but the draw back for this approach is hitting the DB with each API call to validate the token.
3) Already answered in part 2.
You can check my series of posts about this topic using the below links:
Token Based Authentication using ASP.NET Web API 2, Owin, and
Identity.
AngularJS Token Authentication using ASP.NET Web API 2.
JSON Web Token in ASP.NET Web API 2 using Owin.
When it comes to JWT revocation the general idea seems to be either that:
it simply can't be done
or it can be done, but it goes against the stateless nature of JWT.
I generally don't agree with either. First JWT is just a token format (Learn JSON Web Tokens), yes it can be used to shift some state from servers to clients, but that does not impose any restriction on what we can and should do to consider them valid from the point of view of our application.
Second, if you understand the implications and the associated cost of implementing revocation functionality and you think it's worthwhile to use self-contained tokens instead of alternatives that could simplify revocation but increase the complexity elsewhere then you should go for it.
Just one more word on the stateless thing, I think I could only agree to it in the remote chance that the application receiving and validating tokens does not maintain any state at all. In this situation, introducing revocation would mean introducing a persistent store where one did not exist before.
However, most applications already need to maintain some kind of persistent state so adding a few more bits to track blacklisted/invalid tokens is a non-issue. Additionally, you only need to track that information until the token expiration date.
Having covered the general theory, lets go through your individual questions:
If your security requirements mandate that you need to employ additional measures to try to detect malicious use of a token then you're free to do so. A simple example would be blacklisting a token if you detect usage of the same token coming from very different geographical locations.
With support for token revocation in place the application logout scenario would just need to include a step to blacklist the associated token.
I may be missing something here, but if the token expiration time was reached the regular process to validate a JWT would already include a check to make sure that the token was not yet expired.
If I have a custom Secure Token Service that specifically lists out allowed audiences and checks if the token is coming from one of of those audiences and also checks the thumbprint and issuer of the X509 certificate, do I need WSFederation?
Since my STS is checking that the the token already came from a specific application and was routed through my ACS, aren't I verifying all of the things I need to? I know that Application A sent a request to the ACS which sent a request to Application B all from the custom STS, so where does Federated Identity fit in this picture?
Edit for clarity:
Sorry I was a bit unclear in the orignal post. I think the confusion came because I used STS instead of security token handler (Way different things, just a typo).
Application A is a custom login service, which displays the login options for the user, google/facebook/yahoo/etc. Logging in through these service gets the token from the ACS and returns it to application B, the Relying Party. This RP has a custom security token handler which accepts the token and validates that it is has an audience URI matching application A. It also validates that the issuer was the ACS and the thumbprint matches the one of the cert used to sign the token via the ACS.
This means that theoretically application B knows, that application A was used to login (as it came from that audienceURI) and that the ACS sent the token (as it was the issuer and the thumbprint matches). What I am asking is if federated identity is necessary for application B? What exactly do you gain by using it, if you've already proved where the token came from?
your question might need some clarification.
First, you might want to explain specifically what you mean by application A and application B, and how your STS fits in this scenario. Applications don't typically issue tokens, only STSes do. In this sense, ACS doesn't connect applications to each other, it connects relying party applications to third party identity providers.
Second, if you're talking about authentication over the web, and you have a custom identity provider STS that's issuing tokens for ACS, then you're probably already using WS-Federation. If however your token acquisition is not browser based, and you're making back-end HTTP calls to ACS, then WS-Federation is not relevant to the scenario.
Third, from the point of view of the STS, the set of allowed audiences is not about token issuers, it refers to entities that will consume tokens issued by that STS. That is, it's the set of subjects that the STS will issue tokens to. This could be applications themselves, or other intermediary STSes along the federation chain. (ACS for example acts as such an intermediary)
Fourth, when you're validating the issuer's certificate on an incoming token, you must do more than just compare the thumbprint. The thumbprint is not part of the token's cryptographic proof. You must validate the token's digital signature in order to verify that the token issuer owns the private key of the certificate.
I hope this clears things up, but if it doesn't answer your question please let me know.