This use case is very far outside the mainstream and not a good fit for the upstream.

This particular issue is something I'm running into on the test install, before enabling it in production.

Are these tasks for a real instance or a test instance? That is, are these theoretical issues or "omg i hate doing this every day" issues against a production install?

A big banner is totally fine by me. I just proposed an action menu item since it seems simpler.

I'd rather, UI-wise, have a big banner at the top of the user, with a button to just approve them. It seems like if a user in unapproved, that's the quickest solution, and it's then easier to find than picking out a link in the action menu.

So there are two workflows which are annnoying, and one general UI issue.

I don't personally want to add additional action links unless absolutely needed, it devalues the links that already exist there and if we can find another way to link to admin actions, I'd prefer to do that.

We were trying to set this up today. We wanted to have a fully dockerized Phabricator setup for internal use, and need to add LDAP auth provider as the only non-automated step. It's not the end of the world though, but in case someone else wants this maybe a command line tool would be ok.

I would guess this is not an uncommon setup: many LDAP instances have self-signed certificates. Without this knob many standard LDAP setups would not work.

We're not likely to add this into the upstream. Mostly, we're very allergic to adding configuration options (and plan to remove many this year). It could easily be maintained in a fork or local patch.

escalate from that to any other account

No -- you point Phabricator at the new LDAP server by using a compromised administrative account and going to Auth → LDAP and changing ldap.mycompany.com to ldap.evil.com.

This escalation requires control of DNS/networking or something to point phabricator at the new LDAP server, correct?

We haven't seen more requests for this in some time, and dumping the database state is a reasonable solution in the general case (running bin/storage upgrade will always bring an old dump up to date, and we try to migrate and respect settings in almost all cases). If we did see more similar requests, I'd probably favor just documenting that as the recommended approach.

@epriestley I would love to have a configurable session timeout setting in phabricator so that I can set it to something more restrictive than a month.

It looks like we also have access to id here, which is probably (but not necessarily) the same value:

Although this is a rare edge case that we're unlikely to run into again, the fact that it ate up an hour of my life makes me think that spending ~5 hours to fix is worth it just in case we ever do run into this.

• Fixing the most general problem here (T2549) is in the 20-40 hour range.
• Fixing just T6707 is about 1 hour.
• This could also possibly be avoided if Google has permanent primary account identifiers now (instead of email addresses), assuming that both Google accounts were really the same account and they weren't recognized as such because we use email addresses as a primary identifier. I vaguely recall this being an issue when I wrote the integration originally, but Google was evolving auth a lot around that time and there might be a more durable identifier we can use now. This is ~1 hour to check and 2-4 hours to implement if something suitable is available. This problem likely wouldn't be possible with most other OAuth providers, which do have durable identifiers (e.g., user IDs).
• We don't need to use the username as an input to any of the auth hashing, so we could remove the "changing usernames logs you out" interaction. This happens only because all the hashes invalidate, not because there's any fundamental security goal served by invalidating sessions. This is probably 3-6 hours of work.

(It does.)

If you disable passwords as an authentication provider for your test install, does the email content change?

I can't reproduce 'no links' in my test install locally:

This is the email he received:

Yep, shrinidhirao Thank you. Actually found that out recently before reading your message. What I've missed is external account linking functionality for administrator. Each user has to make this action on his own.

Log in first using the OLD method.
Then under user settings settings/panel/external/ link LDAP account.

Hey I've started using Phabricator and quickly setup accounts for colleagues.
Now we put LDAP config and there is a problem. OLD user names are the same as the LDAP ones.. so people who log in through LDAP cannot create account because of duplicates.. any suggestions?

P.S: Setting the session expiry time to 1h as you suggest is very inconvenient in my case. What I actually need is a "normal" expiry time, but using a session cookie on the client. So he gets automatically logged out when he closes the browser, but can use the session as long as necessary if he does not.

@epriestley You asked for reasons for automatic session expiry. Several users of mine expect that their session expires when they close their browser. I think this is the default for many sites: If one wants to login permanently, one has to take specific action to enable it (often a "remember me" checkbox). If one uses a shared computer, the difference between expected and actual behaviour could become a problem.

Since this is both, Phabricator's project management tool and some kind of a demo of the product, enabling (/show off) as much features as possible isn't the badest idea.

In theory, we should also configure these providers:

Gluing two providers together in this way is not a use case we're interested in supporting in the upstream.

My exact usecase:

• I use authentication via libphremoteuser (REMOTE_USER envvar)
• For registration, I want to display the proper real-name and email address
• I need to fetch that from LDAP
• I can conveniently do that (with a small patch) using the PhabricatorLDAPAuthProvider

I'd like to move off of sprites here altogether, so either FontAwesome or nothing.

We would need to have a clearer understanding of how many and why installs want to do this. For now patching your local install sounds like the correct approach.

This is, uh, a... test case? Of, uh, missing provider config? Completely intentional!

Aha, I see. The only real difference between GitHub Enterprise and GitHub.com is a couple of URLs (github.com -> yourdomain, and api.github.com -> yourdomain/api/v3/), which is what I was hoping to be able to configure with my proposal :(

I don't believe it is practical to modularize OAuth more than it is already modularized. OAuth doesn't define how to get information about user accounts (like email, account ID, profile picture, etc)., so the GitHub vs Amazon vs Etc choice is irreducible.

Judging by the code, it looks like the OAuth logic is fairly cleanly separated from the various specific OAuth implementations (which inherit from it). Instead of (or as well as) giving us a collection of hardcoded GitHub/Amazon/Asana/Disqus OAuth providers in the auth options, could there just be a catch-all configurable OAuth provider option?

There's no way to do this right now. You can use the "Generic" icon until we eventually build a modular way to provide icons. This isn't a priority; see T5447 for some rough context and timelines.

I have Allow Registration option unchecked for that auth provider and that causes no grey text to be displayed in 2nd row.

Oh, and that also wouldn't solve the problem that central auth was aimed at solving, which is:

In theory, we could:

• Primarily, their username may collide with a Phacility username, and this seems hard to resolve in a way that makes any sense to users.
• We don't want them to lose access to their Phacility account if they leave the company.
• We don't have any account synchronization code in the upstream, and don't really want to add it since it would only serve Phacility use cases.

Is there any reason that you can't simply allow registrations via other OAuth providers which implicitly registers accounts in the cluster (and links them)? This way an administrator could enable the JIRA provider with a white list on the email address domains allowed, and then everyone can just login with their JIRA account (obviously each new person that registers on the instance would increase the billing amount per month).

Of course; any properly rotated token should form a loop.

I think the point here is that while some math like attack scenarios * session length = risk is good and valid, unless you can talk about specific attack scenarios we're not concerned about the effect session length has on increasing risk. General discussions about how websites can be attacked with no specific technical knowledge of how Phabricator mitigates these attacks are not helpful to us; we really do benefit though from specific discussions.

Nope, I'm not pitching consulting services. I joined the conversation at the request of a member of my ops team, I am stating that allowing a token to remain valid for 30 days needlessly increases the attack surface of the application.

Maybe this is a misread, but it sounds like you're pitching your consulting services without really knowing anything about Phabricator. It's open source; if you have questions about the implementation you can look at the source code. If you identify vulnerabilities, you can submit them through our HackerOne program.

In T4806#98677, @epriestley wrote:

Cross site request forgery (CSRF) attacks specifically take advantage of persistent session tokens and use them to take action as the user that was granted the token.

We rotate CSRF tokens. They are not the same as session tokens.

The tokens that allow for persistent access to a site can be used for CSRF attacks. Do you have specific protections in place to keep this from happening?

Cross site request forgery (CSRF) attacks specifically take advantage of persistent session tokens and use them to take action as the user that was granted the token.

There are actually legitimate security controls when you have sessions that don't expire. Cross site request forgery (CSRF) attacks specifically take advantage of persistent session tokens and use them to take action as the user that was granted the token.

In general, if your organization has a well-meaning policy or compliance guideline which mandates a behavior, but the behavior is not actually desirable on its own in the absence of the compliance concern (i.e., in practice, the mandated behavior is arbitrary), we are very unlikely to implement support in the upstream. We recommend you:

At least in Chrome, you can enforce a session-only cookie policy in Settings > Advanced Settings > Privacy > Content Settings > Cookies. But, as far as I can see, this is entirely pointless for session cookies.

Can you walk me through the specific concern? It seems misguided to limit login session cookies for privacy reasons: to get a session cookie, you must uniquely identify yourself to the server and prove your identity. We necessarily know who you are because the entire purpose of a login session is to prove that.

T7390 originates from information privacy rules, not from security related rules. I assume this rule stems from the greater rule that personally identifying information about users shall be kept to a minimum.

T7390 has another compliance-driven request.

The way the logic actually works, I think the fix is really in PhabricatorAuthLoginController near line 117:

We should enforce uniqueness. The fix is probably something like:

So some code is written assuming that the linked accounts will be unique per provider because the configuration ui implies that there is only one linked account per provider. This isn't enforced by the database, however, and it's not really well enforced anywhere.

I was also able to reproduce this with my Google accounts. I have a personal and business Gmail accounts. I mistakenly linked the personal account but I can't delete it because it's the "last" account. So I "refreshed" it and selected the business Gmail account thinking it would replace the old one, but instead, it created another one and now I'm also stuck with two linked account and the query error.

For the case of not letting users use MFA because the administrative overhead associated with factor loss is a bigger problem than unauthorized access, we're also potentially open (see also T6115) to letting user accounts have a setting like "Multi-Factor Auth: Required / Optional / Forbidden" or similar, although we'd like to see use cases justifying this in the wild (i.e., actual overhead caused by users losing factors) before pursuing it, because it may be possible to satisfy the needs for this with simpler rules (e.g., just a "required for administrators" flag). I suspect we'll end up with both a per-account flag and some group-requirement mechanism, but it would be nice to avoid building this if we don't really need it.

For now, administrators can strip authentication factors from an account by following this guide, although from the discussion in the task linked to T7309 it looks like you're already aware of that: