See D17458 for the previous, narrower case of token revocation in response to Heartbleed (T12313).

Support for Ubuntu 15.10 ended on 2016-07-28.
Did this problem also happen with any later, still supported Ubuntu version (like 16.04) or can this task be closed as obsolete?

This should be fixed by changes in T13024.

This should be fixed by changes in T13024.

Thank you very much!

I fumbled the task ID in D18793, but this should be resolved by that change.

I don't think this or T12421 are valid use cases, for reasons described in T12421, and don't plan to support them.

I can say that this feature would be very nice. I have two LDAP servers in my case and other tools/services that I use allow me to configure both (whether as primary/backup or round-robin). It would be nice if Phabricator allowed specifying multiple LDAP server host names. Of course, I tried that before adding this comment got this error:

I'd love to see support for U2F keys, as well.

i'd like to remark that this ticket is supposed to be about perhaps u2f or other direct hardware security, not saml, and thus i've had to unsubscribe from the recent back and forth :)

In practice, every paying customer who has ever asked us about SAML has wanted to use OneLogin as a SAML provider. OneLogin's breach does not imply SAML is bad; it implies OneLogin is bad. For paying customers who are interested in understanding our stance on SAML support, criticism of OneLogin is materially relevant because they all want to use OneLogin.

@epriestley I'm not saying you didn't do a serious technical evaluation of SAML. I can't see where I might have even vaguely implied that? For all I know you could be an expert on SAML. I've done multiple SAML implementations and frankly I can't blame you for not wanting to do / maintain one.

Why do you believe I haven't performed a serious technical evaluation of SAML?

@epriestley I can see how that last sentence could be perceived as such. I probably should have put a smiley there since it wasn't intended as harsh as you (seem to) perceive it.

Why did you think that a sarcastic, condescending comment was the best way to convince me to reserve judgement?

@epriestley I'm hoping you'll see you shouldn't pass judgement that fast.

@siepkes, what are you hoping to get out of making that comment? How do you believe it benefits you?

@epriestley Onelogin does way more then just SAML. They also do OAuth for example. The screenshot also says to regenerate your Oauth keys. I assume your going to remove all OAuth stuff from Phabricator now?

More on SAML:

In T12547#219587, @epriestley wrote:

Was this on a test install on localhost? I can only reproduce this if the remote address is part of cluster.addresses.

See also somewhat-similar T12592 and T8918.

This would be useful for us as well, we want to migrate from using local authentication (which was very easy to setup when initially bringing up our server) to using LDAP authentication. We had most/all of our users create accounts using their LDAP username but using local authentication, but really we should have set up LDAP from the beginning.

For my own reference, T12570 isn't exactly related but can probably be tested/fixed at the same time.

Stealing this since I think it's session/auth related, not profile picture related: I think the user has a legitimate picture, they just aren't allowed to download it since they have a partial session.

T8918 is related.

In particular, when you connect over HTTP to a security.require-https install, we normally just immediately redirect you to https://....

Was this on a test install on localhost? I can only reproduce this if the remote address is part of cluster.addresses.

Actually, I figured it out... The problem was that I had security.require-https set to true but I hadn't yet setup HTTPS so I was only using plain old HTTP.

I tried to reproduce this on a Phacility host, but it doesn't reproduce there because the first user account is setup via OAuth.

(Just closing this since we haven't seen an update in ~4 months and it isn't actionable.)

Just dropping this here since it's the first hit for "SAML" and makes it easier for me to contextualize things when I quote $50K for it, which I'm starting to think is too low:

(This was incorrectly closed by the text "doesn't actually fix T8918" in rP08de131da525.)

Cool, sounds good.

Thanks for the detailed reply.

In my experience, it is very unusual for organizations to have multiple distinct internal groups with different identity providers. Normally, organizations which value SSO and identity management consolidate identities under a single provider, because that avoids problems like this, greatly simplifies identity management, and doesn't require other pieces of software to support multiple providers.

@epriestley : because it's easier to manage everything from a single instance of phabricator. Phabricator has native support for multiple authentication providers, so I don't see a problem with this.

Why are you sharing an instance between two separate groups with separate identity providers?

@epriestley : we need multiple authentication providers because this is a shared phabricator instance, and thus different groups of users need different IDP.

Why do you have multiple authentication providers?

@epriestley: Yes, we have multiple authentication providers configured and needed in phabricator, and thus "allow auto login" won't work.

Resolved by D17337.

i like that dog's hat. it's a good hat.

100% accurate mockup of this feature

ah, found it. My fault before was, that I only digged into DB phabricator_auth, but i found it now at phabricator_user, table phabricator_session.

No idea, where have you looked so far?

In which table can I find them?

Delete them from the database.

It's critical that we are addressing specific, plausible threat scenarios when implementing security protocols. This task currently lacks such a scenario.

The provider is now being removed from Phabricator, so 2016 Week 49 is the last release to include it.

That didn't seem to be the case. It might have been because we only enforced Google authentication around one year ago, before that users could use a password for authentication. I can check later today, but perhaps the users that ended up with duplicate accounts never setup Google Auth.