是否可以设置基础项目以跨多个ASP.NET MVC项目使用？(Is it possible to set up a base project for use across multiple ASP.NET MVC projects?)

 你是整合现有的应用程序，还是你只想支持你自己的应用程序？ 
 
 你在寻找真正的SSO还是简单的共享凭证？ SSO正在登录到单个应用程序，并将该凭据传播到其他应用程序（例如登录到Gmail并自动登录到Blogger）。 共享凭证是您可以跨应用程序使用相同的登录名和密码，但凭证本身不会自动传播。 
 
 LDAP是用于管理共享凭证的通用系统。 许多系统允许您将其认证存储指向现有的LDAP服务器。 
 
 例如，如果您在Java EE容器中部署了多个应用程序（也称为电子邮件服务器和基于Web的电子邮件客户端），则所有这些不同的应用程序都可以指向同一个LDAP服务器，并且您的用户将拥有单一登录和所有不同系统的密码，所有系统都使用不同的语言编写，全部部署在不同的机器上。 这是LDAP的面包和黄油使用案例，几乎每个系统都可以处理这种开箱即用的方式。 Glassfish和Tomcat都可以轻松验证LDAP服务器。 Apache（Web服务器），Postgres（数据库），Postfix（电子邮件）等等都可以。 
 
 所以如果你只需要一个共享凭证，那么你现在就可以通过安装一个LDAP服务器来“免费”。 LDAP是一种与DBMS不同的东西，但是一旦你对它进行了一些研究并“得到它”，它确实相当不错。 OpenLDAP是一种流行的LDAP服务器，但我偏爱ApacheDS。 
 
 在Java EE容器中设置它的方法是设置一个“Realm”。 GF和Tomcat都有开箱即用的LDAP领域，我想其余的都可以。 但是坚果就是您需要使用Java EE安全性来利用Realm。 
 
 请参阅Java EE Realm的详细信息，它是容器的一个方面，而不是应用程序。 就像连接池是应用程序利用的容器资源一样。 大多数人希望安全性成为他们应用程序的一部分，他们觉得他们可以更好地控制它。 
 
 这一切都很好，直到你开始获得一堆不同的应用程序，每个人都有不同的配置，并有单独的用户列表和密码策略等。 
 
 LDAP可以解决很多问题，因为您将它们全部配置为使用相同的凭证存储。 
 
 Realm满足了Java EE服务器的需求。 您的应用程序被配置为使用容器提供的Realm。 如果您有多个应用程序和一个Realm，那么他们都可以共享该Realm内的凭据（不管Realm类型）。 
 
 领域可以是任何东西：基于文件，基于数据库，LDAP等。如果容器集群（可以很方便），领域也是集群。 
 
 Java EE安全性的阴暗面以及为什么大多数应用程序避免这种情况的原因是，由于Realm再次是容器的一部分，而不是应用程序，它可能有点难以使用，并且可能不会提供这些功能如用户管理，密码策略等。 
 
 但是，Java EE安全的亮点在于，一旦你处于保护状态，你可以轻松地在代码中充分利用凭证。 一个人登录到Web站点，该凭证可以在Web应用程序中使用，或自动传播回EJB层（永远是远程EJB层），并且信息总是非常方便。 
 
 您可以将您的Web应用程序指向领域，EJB和Web服务。 他们都利用相同的作品。 
 
 为了获得这两种最好的方式，就是利用容器特定的机制来访问容器安全性。 这是Java EE安全性的另一个阴暗面。 
 
 诸如Realms之类的东西，以及直接访问容器安全性都不能跨容器移植。 GF与Tomcat不同，它与WebLogic不同。 这一切都非常接近，但细节不同，因此您的代码无法无缝移植。 
 
 好的一面是在内部应用程序中，大多数人只是利用他们拥有的容器，围绕容器相关的代码进行合理的抽象，并在日期中注明是的，他们将不得不移植到不同的容器。 但是，在实践中。 就像一个数据库一样，一旦选择了一个容器平台，人们往往会紧紧依偎并坚持下去。 
 
 最后，Servlet 3.0（GF3和Tomcat 7）将更多的程序化登录问题标准化，以使它们跨容器更加便携，但其基本概念是相同的。 
 
 现在，SSO。 
 
 SSO是一种不同的野兽。 但是，GF和Tomcat都支持Web应用的SSO。 这使您可以登录到一个Web应用程序，并且无需登录即可轻松访问其他应用程序。 但是SSO有点受限，因为它更多地依赖于容器的安全性及其生命周期，而不是在应用程序的控制下更灵活。 记住，不只是在领域（这是给定的），而是在实际的基于容器的FORM登录，而不是一个自定义的程序化登录。 FORM登录并不是很壮观，但它功能强大并且可以工作。 实施一个Realm，将你的应用程序部署到Tomcat或GF（或GF 3.1中的一个集群）的单个实例中，并且免费获得SSO，所以如果这很重要，那真是太好了。 对于后台应用程序来说可用性不错，但也许不是公共互联网。 
 
 如果您想要更复杂的SSO解决方案，那么您需要查看自定义实施。 OpenSSO就是其中之一，它依赖于SAML和SAML Web配置文件。 但是，还有其他的。 还有CAS，Atlassian Cloud，Kerberos和OAuth。 这些都使用不同于SAML的协议。 如果你想坚持使用SAML，你还可以看看Shibboleth，甚至SimpleSAML（SimpleSAML是一个PHP服务器，作为SAML身份提供者，除此之外，你仍然需要在你的应用程序中使用服务提供者）。 
 
 无论您选择哪种协议，流程基本上都是相同的（这里详细介绍 - 跨域登录 - 如何在从一个域转移到另一个域时自动登录用户 ）。 
 
 但魔鬼在细节中。 而且，男孩，有魔鬼。 
 
 所有这些系统都很复杂。 SSO很复杂。 例如，现在你有单点登录，那么Single Sign Out呢？ 什么关于单次超时？ 用户登录时如何更改凭证？ 关于您的Web服务的STS（安全令牌服务）如何？ （STS为Web服务提供了类似的委托认证机制。） 
 
 SAML向您介绍了大量新词汇以及大量配置。 由于文档不是一流的，而且很大程度上依赖于与更高级别的通用事物相关的标准文档，而不是专门针对您和您的应用程序，所以它不容易被发现。 
 
 如果你不需要真正需要SSO，那么你可能会满足于像中央LDAP存储这样的东西，并从那里继续。 
 
 举个例子，我们的应用程序同时支持数据库和LDAP后端。 他们使用Glassfish和Java EE安全性。 我们完全控制用户体验。 我们还通过SAML（我们编写了自己的身份和服务提供商）支持SSO，并且通过使用我们的代码和第三方代码在Java和其他应用程序中通过LDAP和SSO共享凭证。 光明的一面是这是所有标准的基础。 黑暗的一面是标准是用英语交流的，而英语则需要解释。 
 
 我只是说这可以完成。 我还写了ad hoc，后面的餐巾SSO实现，使用简单的Servlet过滤器，包括同域和跨域（相同的域使用共享cookie简单）。 密码策略，密码恢复，保持活动计时器，多窗口超时和会话管理（这是一个窍门），角色，特权等等等等。 
 
 另外，如果Spring和Spring Security在Spring之外提供了所有这些，我会不屑一顾。 我没有用过它（我不是一个春天的人），但这些人确实知道他们在做什么，所以值得一看。 

Are you integrating existing applications, or do you just want to support your own applications?
 
Are you looking for actual SSO or simply shared credentials? SSO is logging in to a single application, and having that credential propagate to another application (such as logging in to Gmail and being automatically logged in to Blogger). Shared credential is you can use the same login name and password across applications, but the credential itself is not automatically propagated.
 
LDAP is a common system used to manage a shared credential. Many systems allow you to point their authentication store to an existing LDAP server. 
 
For example, if you had several apps deployed in a Java EE container, and also, say, an email server and web based email client, all of these diverse applications could be pointed to the same LDAP server and your users would have a single login and password for all of the different systems, all written in different languages, all deployed on different machines. This is a bread and butter use case of LDAP, and pretty much every system can handle this out of the box. Glassfish and Tomcat can both readily validate against an LDAP server. So can Apache (Web server), Postgres (Database), Postfix (email), etc. etc.
 
So if you want simply a shared credential, you get that "for free", right now, by installing an LDAP server. LDAP is a bit of a different beast than something like a DBMS, but once you study it a little and "get it", it's really quite nice. OpenLDAP is a popular LDAP server, but I'm partial to ApacheDS.
 
The way to set that up in a Java EE container is to set up a "Realm". GF and Tomcat both have LDAP realms out of the box, I imagine the rest do to. But the nut there is that you need to use Java EE security to leverage the Realm.
 
See, the detail with a Java EE Realm is that it's an aspect of the CONTAINER, not the application. Just like a connection pool is a container resource that your application leverages. Most people want security to be a part of their application, where they feel they have more control over it.
 
That's all well and good until you start getting a bunch of different applications and everyone is configured differently and has separate user lists, and password policies, etc. etc.
 
LDAP can fix a lot of that, since you configure them all to use the same credential store.
 
The Realm fills that need on a Java EE server. Your application is configured to use a Realm provided by the container. If you have several applications, and a single Realm, then they all get to share the credentials within that Realm (regardless of the Realm type).
 
Realms can be anything: file based, db based, LDAP, etc. Realms also cluster if the container clusters (which can be handy).
 
The dark side of Java EE security, and why most apps avoid it is that, since, again, the Realm is part of the container, and not the application, it can be a little ungainly to use, and perhaps not offer the features you like in terms of user management, password policies, etc.
 
But the bright side of Java EE security is that once you're under its umbrella, you can leverage the credential all over in your code easily. A person logs in to the web site, and that credential can be used there in the web app, or automatically propagated back to the EJB tier (ever a remote EJB tier), and the information is always handy. 
 
You can point your web apps at a realm, you EJBs, your web services. They all leverage the same pieces.
 
In order to get kind of the best of both worlds is to leverage container specific mechanisms to access the containers security. This is the other dark side of Java EE security.
 
Things like Realms, and direct access to container security are not portable across containers. GF does it different than Tomcat does it different from WebLogic. It's all really close, but differs in details so your code won't port seamlessly.
 
The bright side is for in house apps, most folks simply leverage the container they have, put a reasonable abstraction around the container dependent code, and call it day noting that yes, they will have to port this if and when they move to a different container. But, in practice. much like a database, once a container platform is chosen, folks tend to snuggle in tight and stick with it.
 
Finally, Servlet 3.0 (In GF3 and Tomcat 7) standardizes more of the programmatic login issues to make them more portable across containers, but the underlying concepts are the same.
 
Now, SSO.
 
SSO is a different beast. But, out the gate, both GF and Tomcat support SSO for web apps. This lets you log in to one web app and have be able to easily access others without having to log in to them. But the SSO is a little bit limited since it relies more heavily on the container security and its lifecycle, rather than a more flexible one under the control of the application. Mind, not just on Realms (that's a given), but on the actual container based FORM login, rather than a custom programmatic login. FORM login is not spectacular, but it's functional and it works. Implement a Realm, deploy your apps to a single instance of Tomcat or GF (or a cluster in GF 3.1), and you get SSO for free, so if that's important, it's kind of nice really. It's usability is fine for back office apps, but not perhaps the public internet.
 
If you want a more sophisticated SSO solution, then you need look at custom implementations. OpenSSO is one of those, and it relies on SAML and the SAML web profile. However, there are others. There's CAS, Atlassian Cloud, Kerberos, and OAuth as well. Those are all using different protocols than SAML. If you want to stick with SAML you can also look at Shibboleth, or even SimpleSAML (SimpleSAML is a PHP server that acts as a SAML Identity Provider, among other things, but you still need a Service Provider within your applications).
 
Whatever protocol you choose, the process is basically the same (detailed here -- Cross Domain Login - How to login a user automatically when transferred from one domain to another).
 
But the devil is in the details. And, boy, are there devils.
 
All of these systems are complicated. SSO is complicated. For example, now that you have Single Sign On, what about Single Sign Out? What about Single Time Out? What about credential changes while users are logged in? What about an STS (Secure Token Service) for your Web Services? (STS offers a similar delegated authentication mechanism for web services.)
 
SAML introduces you to a whole lot of new vocabulary, and a lot of configuration. It's not readily picked up since the documentation isn't stellar and relies a lot on standards documents which talk to a higher level of generic things, and not to you and your application specifically.
 
If you don't need really need SSO, then you'll likely be content with something like a central LDAP store and going on from there.
 
All that said, as an example, our applications support both a DB and LDAP backend. They use Glassfish, and Java EE security. We completely control the user experience. We also support SSO via SAML (we wrote our own Identity and Service Providers), and we have both shared credentials via LDAP and SSO across Java and other applications, using our code and third party code. The bright side is this is all standards based. The dark side is that standards are communicated in english, and english is subject to interpretation. 
 
I say this simply to say it can be done. I have also written ad hoc, back of the napkin SSO implementations, both same domain and cross domain (same domain is simple with a shared cookie) using simple Servlet Filters. Password policies, password recovery, keep alive timers, multiple window timeout and session management (that's a hoot), roles, privileges, etc. etc. Been there, done that. 
 
Also, I would be remiss to not mention Spring and Spring Security which offers all of this on top of Spring. I have not used it (I'm not a Spring person), but those folks do know what they are doing so it's worth looking at.