I have a general understanding of 1st/3rd party cookies, how cookie syncs work, etc. But not able piece together how Facebooks' new 1st Party cookie option works for their Pixel product.
What's the protocol behind the scenes that is allowing FB to establish a 1st Party relationship on a non-FB domain?
Related
Microsof ADFS supports below federation protocols:
SAML 2.0
WS-Federation
OpenID Connect
Would like to know is it possible to achieve single sign on (SSO) and single logout across different protocols? E.g. user X after he/she successfully login to website A which is protected under SAML 2.0, then the user can access website B which is protected under OpenID Connect without re-login? Both website A and website B point to the same IdP.
There are typically the parties involved. Of these, website B is the modern architecture and can support many forms of authentication:
Website A redirects to SAML Identity Provider (IDP) directly
Website B redirects to Authorization Server (AS) which redirects to the SAML IDP
Single Sign On is represented by a third party session cookie issued for the SAML IDP's domain name. Both apps would redirect to the SAML IDP but only the first would result in a login prompt. Website B may need to send the acr_values OpenID Connect parameter during its redirect, to avoid the user being presented with an authentication selection screen. It should work fine, but test for your providers. The SSO cookie is maintained in current browsers on the second redirect, due to the user gesture of a top level redirect.
Single Sign Out has always been a set of draft standards that work imperfectly in all of the above protocols. Even if the technology works, there would be risks such as also signing the user out of App C, which you do not own. Also, recent browser restrictions on third party cookies mean some techniques may drop the SSO cookie and no longer work. Most stakeholders, including end users and security reviewers, do not expect you to have a perfect Single Logout solution.
I'm a programmer with VERY limited system experience, and I've set up an ADFS 2.0 Rollup 3 server for authentication to Salesforce.
My use cases are:
1. Allow single users to authenticate against their NameID in the UPN.
2. Allow group users to authenticate by membership in a user group.
I would like to have both types of authentication on the same ADFS server. Here is an example of the sign-on screen, where the "Active Directory" button is for single users, and the "Admin Users" are members of a user group.
I have no problem with either group authentication or user authentication on a single ADFS server, but I'd like both on the same ADFS server for a single relying party trust. However, I haven't been able to get that to work.
The entityID is the default,
http://[Server Name]/adfs/services/trust
The login URL is the SAML 2.0 endpoint:
https://[Server Name]/adfs/ls/
I've tried several things that didn't work:
SalesForce requires the "issuer" (in this case, the entityID) and the "login URL" together are unique, so I've tried adding URL parameters to the login URL, since those will get imported into ADFS from the metadata file. That doesn't work though - If I have two relying party trusts, one w/ the parameters, and one without, I'll get signed into one, regardless of which one I'm trying to sign into.
I've also tried adding multiple rules to one, but that generates an error when I try for SSO.
How could I get this to work?
If anyone ever stumbles across this, in order for this to work, the simplest solution is to send different relying party IDs from SalesForce, and have different relying party trusts in ADFS.
In SalesForce, this would appear as two different buttons on the login screen, and in ADFS, this would appear as two different relying parties - One in each system for each relying party ID.
If you are auto-signing in from some application, you'll have to iterate over each relying party trust, and try to authenticate from each.
I can't imagine this very specific use case will be much value, so comment if you want more details, since my 3 year old question has little interest :)
I'm working on a proof of concept app. The basic functionality works, where I can log into one website, link to another site that shares the same STS, and the partner site picks up the credentials properly.
However, the partner site only requests the token if the page that we link to requires authentication (which kind of makes sense I guess).
Ideally, I'd like to link to a partner page that does not require you to be authenticated, BUT if the user IS already authenticated, I'd like to at least be able to recognize them on the partner site.
Currently, if my partner landing page does not require authentication, it doesn't appear that the user is logged in when they arrive. As soon as the user requests a page on the partner site that does require authentication, it then grabs the token without requiring the user to log in.
I've tried playing around with the SecurityTokenReceived and RedirectingToIdentityProvider events, but so far I'm stumped.
Any thoughts are appreciated.
So, the problem you are running up against is in dealing with the SessionAuthenticationModule hijacking the request. This module is responsible for detecting if the user has a valid session (based on a cookie that is written upon a successful redirect from the STS) and if not, to redirect the user to the STS to fetch a valid token. The WSFederationAuthenticationModule supplies the eventing necessary to hook into various stages of the redirection/authentication process.
Based on your description, it sounds like you want the following to happen:
User clicks on a link that redirects to the partner site
At the partner site, the request is intercepted and the system determines if the user is signed-in to the STS or anonymous
If the user has a valid session with the STS, then pull the claims for that user
The problem is, your RP cannot know that the user has a valid session without sending the user to the STS first (the RP's do not talk to each other or the STS. The user's brower is used as the means of communication between the RP's and the STS in the form of WS-Fed directives and SAML tokens passed in the url during redirects). If the user is sent to the STS, then they must authenticate, which could be a problem for anonymous users.
So, I do not think there is a "trick" that you can pull via configuration or interception of the request to determine if the user has a valid session with the STS. You might be able to pass a hint, however, from the referrer that is intercepted by the partner site. This hint could take the form of a parameter on the url that indicates to the partner site that the current user has a valid session and to go ahead and redirect to the STS (absence of this hint would indicate an anonymous user). You could also build a system to "hand-off" knowledge of the signed-in user using a resource that both sites have access to (i.e. database).
As you are sure to learn soon, more often than not, WIF offers pieces to the puzzle, but every situation is different and you have to supply the other pieces on your own.
Hope this helps!
I have a difficult to nail down/solve problem.
I am creating a system that has two parties: The User wants to perform and authorize an action , and the second party that needs to confirm this action has been authorized.
The problem is, only the user that wants to perform the action will have an iphone (in many cases) and thus the ability to get authorization from our server. The second party does not have access to an internet connection, and will not be able to directly confirm that the first user's request was authorized.
So, my problem is... what sort of system/item could I use to ensure that the second party can confirm that the first party's mobile phone action was authorized by our server?
So far, all of the ideas I have come up with can be subverted by a clever hacker that just duplicates what the second party expects to see as a confirmed request. Things like... giving each second party a unique code that needed to be entered on the first party's mobile app in order to receive confirmation. But the clever user could just create a hacked app that mimics what the real app would do. Obviously, that would be a problem because if the second party believes that the action was authorized when it actually wasn't (due to hacking), they would lose out on money/time/etc...
Here is a diagram that may make my question a bit clearer:
Any ideas would be greatly appreciated.
***Edit: I wanted to add - Party 2 does not have access to a mobile device/computer in some cases, so I need to figure out some piece of hardware that could be deployed cheaply but also perform the role of verification.
If I understand your problem correct; you have a trusted server that can authorize an action for Party 1. That is, the server can decide if Party 1 should be allowed to perform an action. You may call this an authorization service. Party 1 then needs to prove that he was authorized to do this action for Party 2. Party 2 cannot contact the authorization service directly to verify this claim.
The natural solution to this is to let the authorization server issue a digitally signed authorization claim to Party 1. This claim can be i.e. an xml that describes what kind of authorizations Party 1 has. The claim must be digitally signed with a private key that only the authorization server knows. Party 1 recieves this claim from the server and send the claim to Party 2. Party 2 verifies the digital signature using the authorization server's public key. If the digital signature is correct, then Party 2 knows that the claim is valid and what kind of autorizations Party 1 got from the authorization server.
To do this, you must generate a key pair on the authorization server and distribute the public key to each instance of Party 2. This only has to be done once. The public key is not a secret, but it is very important that it is the correct key and that no one with malicious intentions can replace the public key at Party 2 with a fake key.
You will need some kind of device at Party 2 that is able to validate a signed claim. Without that, I don't think this scenario is possible to solve.
Is it possible to do part of a web flow in Perl and then transfer the rest of the session to Firefox?
I need to retry(with Perl) logging in to a website which returns 500 every now and then on a successful login, transfer the authenticated session to Firefox, from where I can continue my normal browsing. Is this possible?
If this is possible, how do I do it? Can you point me to some resources on how can transfer the cookie/session, etc ?
To me, it seems that it makes more sense to do everything from within Firefox ... and control that from the outside. MozRepl (the FF extension) and MozRepl (the Perl module) may help you in getting there.
Tricky. You will not be able to have your server log in to the 3rd party service, and then just serve up the session cookie to your user, and redirect him to the 3rd party app. This will not work because cookies are domain specific, and domains cannot access cookies from or set by another domain.
So your service will need to act as an interface to the third party service, and as such you will need to maintain a user session on your server. This user session keeps track of your user, will log in to third party service, and will make requests to the 3rd party service when appropriate. The session on your server will be an http client for this 3rd party service, so it will need to be able to handle cookies correctly - ie mimic a browser.
In terms of setting up and maintaining user sessions, there will be a number of CPAN modules to help you with this.
For more info on managing user sessions in Perl, see https://web.archive.org/web/1/http://articles.techrepublic%2ecom%2ecom/5100-10878_11-1044683.html
Edit: some web services can manage user sessions by injecting a session id into the URL when the client refuses cookies. If your 3rd party service will do this, you could maybe just serve up the login response URL as a redirect to your user. However, this will break if sessions are bound to an IP.