Your app needs to require claims that describe the user, regardless of where they login from. It should not handle authentication in either case; this should be delegated to a trusted issuer, an STS. This will allow it to interact w/ users in a uniform way irrespective of where and how they authenticate. This means that you're going to need to use ADFS in two roles: that of an Identity Provider (IP) STS and of a Federation Provider (FP) STS. For users of partner companies that don't want to maintain users themselves, you'll be the IP-STS; for those that do, you'll be an FP-STS. In the latter case, ADFS will redirect users from your realm back to the partner's site where their IP-STS will authenticate them and send them to your FP-STS. It will map your partner's user ID and claims into ones that make sense in your realm. This and other information about the user will be included in the set of claims that are issued from your FP-STS. As a result, your app, only trusts your STS regardless of which scenario is appropriate for different users. Note that in this scenerio, there will be two STSs: your ADFS FP-STS and your partner's IP-STS, which may or may not be ADFS. In the other case, there will only be one STS: your IP-STS.
Not every page on your ADFS Web app needs to be accessed via HTTPS; however, everyone that's used in the authentication process should be.
This is really a non-trivial undertaking. If you want to talk about it more, please feel free to get in touch w/ me.
With Git version 1.7.9 and later
Since Git 1.7.9 (released in late January 2012), there is a neat mechanism in Git to avoid having to type your password all the time for HTTP / HTTPS, called credential helpers. (Thanks to dazonic for pointing out this new feature in the comments below.)
With Git 1.7.9 or later, you can just use one of the following credential helpers:
git config --global credential.helper cache
The credential.helper cache value tells Git to keep your password cached in memory for a particular amount of minutes. The default is 15 minutes, you can set a longer timeout with:
git config --global credential.helper "cache --timeout=3600"
Which sets the cache for 1 hour, or:
git config --global credential.helper "cache --timeout=86400"
For 1 day. You can also store your credentials permanently if so desired, see the other answers below.
GitHub's help also suggests that if you're on Mac OS X and used Homebrew to install Git, you can use the native Mac OS X keystore with:
git config --global credential.helper osxkeychain
For Windows, there is a helper called Git Credential Manager for Windows or wincred in msysgit.
git config --global credential.helper wincred # obsolete
With Git for Windows 2.7.3+ (March 2016):
git config --global credential.helper manager
For Linux, you would use (in 2011) gnome-keyring
(or other keyring implementation such as KWallet).
Nowadays (2020), that would be (on Linux)
Fedora
sudo dnf install git-credential-libsecret
git config --global credential.helper /usr/libexec/git-core/git-credential-libsecret
Ubuntu
sudo apt-get install libsecret-1-0 libsecret-1-dev
cd /usr/share/doc/git/contrib/credential/libsecret
sudo make
git config --global credential.helper /usr/share/doc/git/contrib/credential/libsecret/git-credential-libsecret
With Git versions before 1.7.9
With versions of Git before 1.7.9, this more secure option is not available, and you'll need to change the URL that your origin
remote uses to include the password in this fashion:
https://you:password@github.com/you/example.git
... in other words with :password
after the username and before the @
.
You can set a new URL for your origin
remote with:
git config remote.origin.url https://you:password@github.com/you/example.git
Make sure that you use https
, and you should be aware that if you do this, your GitHub password will be stored in plaintext in your .git
directory, which is obviously undesirable.
With any Git version (well, since version 0.99)
An alternative approach is to put your username and password in your ~/.netrc
file, although, as with keeping the password in the remote URL, this means that your password will be stored on the disk in plain text and is thus less secure and not recommended. However, if you want to take this approach, add the following line to your ~/.netrc
:
machine <hostname> login <username> password <password>
... replacing <hostname>
with the server's hostname, and <username>
and <password>
with your username and password. Also remember to set restrictive file system permissions on that file:
chmod 600 ~/.netrc
Note that on Windows, this file should be called _netrc
, and you may need to define the %HOME% environment variable - for more details see:
Best Answer
I encountered the same issue as well and finally figured out the cause. This may occur if the ADFS authentication page url is a non-intranet address.
To resolve the issue, change the wsfederation issuer address in application's web.config to one that would be treated by the browser as an intranet address.
Change the following
to
where xyz is the machine name where ADFS is installed.
Do not change the adfs trust urls though. Keep them as they are since they would be used for matching and establishing trust between your application and ADFS.
The browser treats "xyz.abc.com" as an internet address, and hence displays a login prompt while "xyz" is treated as an intranet address so it automatically forwards logged in user credentials to the application without the user having to specify credentials himself/herself.
After this change, any intranet user would be directly logged in to the application if the browser used is Internet Explorer with default security settings (i.e. "Automatic logon only in Intranet zone" under Security tab -> Internet -> Custom level) or Chrome (since it picks up the settings set for Internet Explorer).
To make the automatic login work in Firefox, the following additional steps would have to be performed:
1) Type about:config into the firefox address bar. You might be warned about editing this section, go ahead anyway.
2) Type "fqdn" in the search bar. You should now see 2 settings i.e. "network.automatic-ntlm-auth.allow-non-fqdn" and "network.negotiate-auth.allow-non-fqdn". Change the values of both to true.