I have been discussing this with the Crowd Support team; but would like to see if others observe the same behaviour (or if it is something I have misconfigured) and whether you consider it expected or a problem.
For this I am using two computers with Firefox and the Firebug add-on (to manipulate cookies). Stash authenticates against Crowd and uses SSO.
On the first computer:
On the second computer:
With my implementation you gain access to Stash on the second computer without having to enter any passwords.
[Sorry, I don't seem to be able to attach any example images to the question]
This is normal and completely expected behaviour of logging in to most websites.
If you can provide the token (the cookie's value) which demonstrates that you have authenticated previously, you must be the same person. Being able to impersonate someone like that by stealing their session cookie is why TLS is so important; it helps prevent session hijacking.
You can add another layer of protection by recording certain validation factors which must be provided together with the token; the server then rejects the token as invalid if the validation factors provided when verifying the token do not match the validation factors provided when the token was created.
Crowd supports this too and off the top of my head (i.e. without checking the code) I believe Crowd will use the IP address of the request which created the session token as a validation factor by default. If SSO is enabled then Stash should be doing the same thing. Did you perform this test on 2 computers which appear to have the same ip address to Crowd/Stash by any chance (e.g. 2 pcs behind NAT, or 1 pc with 2 different browser instances)?
(I'm a Crowd developer.)
Thank you for that explanation. I believe this would be the expected behaviour if the "Require Consistent Client IP Address" option is turned off in the Crown Session Config options.
In my test they are separarte computers, with different IP addresses, on the LAN.
The Crowd debug logs show the IP address is being used as a validation factor. When the second computer uses the duplicate session cookie there are 6 "The token keys don't match" messages then it generates a new token (so the second computer actually gets a new session cookie).
This doesn't happen with Jira; using the SSOSeraphAuthenticator. You are quickly redirected to the log in page.
Ensuring Stash is secure is important to us as this gives access to source code and IP.
Bitbucket Pipelines helps me manage and automate a number of serverless deployments to AWS Lambda and this is how I do it. I'm building Node.js Lambda functions using node-lambda ...
Connect with like-minded Atlassian users at free events near you!Find a group
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no AUG chapters near you at the moment.Start an AUG
We're bringing product updates and pro tips on teamwork to ten cities around the world.Save your spot