原创

CAS 4 中集成 X.509 证书身份验证处理程序

X.509证书是一个非常技术主题。许多人都知道他们,但任何两个人都很难在没有对共同术语的一些误解的情况下进行讨论。这不是PKI或Java加密的一般讨论的地方,虽然这个主题是基于这两个主题。在配置中有几个关键决定,它们需要以简明的语言解释。这些决定还必须放在各种机构认证策略的背景下。


规划

机构可以建立公钥基础设施以发布可以安装在Web浏览器中的用户证书。最简单的示例是Microsoft Active Directory中内置的证书服务,但是支持所有浏览器和操作系统的更灵活的解决方案存在于Java程序(如EJBCA)中。机构颁发的证书中将有一些字段可以翻译成本地首选的主体名称,而某些通用公共服务发布的证书可能只有一个电子邮件地址。本文档假定您的机构已经具有PKI,并且已经向在某些浏览器中安装了PKI的某些用户颁发了证书。关于这些步骤中的任何一个的说明在这里可以解释的范围之外。

驾驶执照由贵国签发。它包含有关人员的信息(姓名,地址,年龄)和可用于将许可证与其描述的个人(图片,签名)相关联的信息。证书由证书颁发机构(CA)颁发。它包含有关帐户(名称,部门,电子邮件)的信息和可用于证明声称实际上是证书所有者的人的信息(与所有者保密的私钥匹配的公钥) )。然而,虽然只有50个州颁发驾驶执照,但任何组织都可以设置证书颁发机构。如何决定信任CA颁发的证书。

在过去,人们认为会有一些中央行政单位,每个人都相信,可以断言哪些CA是可靠的,哪些不可靠。在大多数情况下,事实证明是不切实际,不具成本效益。因此,常见的做法是每个公司或大学创建自己的CA,然后手动将标识该CA的公钥的证书分发给该机构服务的每个计算机,用户,浏览器或服务器。这对于内部使用(内部网)是很好的,但是当服务器还向外部人(申请人,客户,供应商等)提供信息时,则需要从公共商业CA(特别是VeriSign或Thawte)。

最近的演变是国家政府CA的存在,s用于电子身份证上的证书。如果您属于已经实施了包含正确X.509证书的全国性电子身份证的国家,那么您很幸运。您应该检查您是否可以将这些eID用于您的目的(例如: http : //eid.belgium.be/)。通常这解决了很多问题,在下面的段落中解释。

当任何浏览器连接到https:网站时,证书将作为SSL(也称为TLS)初始化的一部分进行交换。一定数量的公共CA证书由Microsoft,Mozilla或任何其他浏览器的任何人预装在每个浏览器中。基本上,Microsoft在每个Windows版本中安装相同的证书集合,Sun在每个Java版本中安装相同的证书集合。但是,您在公司或校园内创建的任何证书都不是证书颁发机构(CA)的任何应用程序,系统或语言。

有两个问题。我们开始假设您的组织已经能够生成和分发证书,用户可以在Windows(对于IE)或Firefox或其他浏览器中安装证书,并且在该证书的某个地方有一个字段包含主体名称或可以很容易地映射到您想要CAS使用的Principal名称。剩下的问题是确保浏览器,服务器和Java都准备好支持这些机构证书,并且理想地,这些机构证书将是浏览器连接到CAS时唯一交换的证书。

当浏览器通过https:URL连接到CAS时,服务器通过发送自己的证书来标识自己。为了使CAS有任何意义,浏览器必须已经安装了一个证书,该证书标识并信任颁发CAS服务器证书的CA。如果浏览器尚未准备好信任CAS服务器,则弹出一条错误消息,表明服务器不受信任,用户永远不应该相信该错误消息是正常的。你肯定不希望用户将他们的密码发送到声称是CAS的网络上的任何机器。除非您可以在每次访问CAS站点之前在每个用户的浏览器中预安装机构CA证书,否则CAS服务器必须每年都有一些由VeriSign或Thawte发出的商业证书。

在服务器发送标识自身的证书之后,它然后可以发送其愿意接受证书的证书颁发机构的名称的列表。理想情况下,此列表将仅包含一个名称,即内部机构CA的名称,该CA发布内部仅包含具有CAS主体名称的字段的仅限内部Intranet的证书。

用户可以从任意数量的CA安装任意数量的证书到浏览器中。如果这些证书中只有一个来自服务器发送的可接受的CA列表中的CA,则大多数浏览器将自动发送一个证书而不进行询问,并且可以在安全选项卡中配置IE,以便在只有一个可能的选择。这提供了一种用户体验,其中CAS在一些初始设置之后变得对用户透明,并且登录自动地发生。但是,如果托管CAS的服务器在列表中发送多个CA名称,并且在浏览器上匹配多个证书,则会提示用户从列表中选择一个证书。用户交互失败了CAS中证书的大部分目的。

CAS不控制此交换。它由Web服务器处理,Web服务器可以是应用程序服务器。如果在具有大量其他应用程序的大型J2EE服务器中部署CAS,则当浏览器访问CAS时,您可能无法控制应用程序服务器只提供一个CA名称。因此,如果您想在CAS中使用X.509 Certficates,您应该在选择托管环境时考虑此要求。 

理想的选择是选择一个服务器,它可以用VeriSign发布的公共证书来识别自己,但是要求客户端证书只能由内部公司/校园机构颁发。

当CAS获得控制时,浏览器可能已经呈现了用户证书,并将其存储在HttpServletRequest对象中。CAS X.509认证处理程序检查证书并验证它是由受信任的机构授权机构颁发的。CAS X.509证书到主体解析器然后搜索证书的字段以标识一个或多个字段,这些字段可以变成应用程序期望的主体标识符(与用户标识和密码表单标识生成的标识符相同) )。

虽然机构可以有一个证书颁发机构向员工,客户,机器,服务和设备颁发证书,但更常见的是机构有一个“根”证书颁发机构,在其整个存在只发出少量证书。这些证书中的每一个都标识颁发特定类别的证书(给学生,工作人员,服务器等)的二级证书颁发机构。可以将CAS配置为信任根管理中心,并隐式地管理其创建的所有辅助授权。然而,这使CAS仅与机构创建的最不可靠的次级证书颁发机构一样安全。在将来的某个时候,一些经理会购买需要新类证书的产品。他将要求创建一个证书颁发机构,将这些证书提供给运行此新产品的计算机。然后他会把这个混乱的管理变成一个初级程序员或顾问。如果CAS信任由根创建的任何权威机构颁发的任何证书,它将信任由已获得控制意图作为特殊用途的孤立CA的人伪造的强大证书。因此,最好将CAS配置为仅接受来自一个辅助CA的证书,该辅助CA专门预期向个人发出证书,而不是信任机构根CA。它将信任由一个已经获得对意图成为特殊目的的隔离CA的控制的伪造证书。因此,最好将CAS配置为仅接受来自一个辅助CA的证书,该辅助CA专门预期向个人发出证书,而不是信任机构根CA。它将信任由一个已经获得对意图成为特殊目的的隔离CA的控制的伪造证书。因此,最好将CAS配置为仅接受来自一个辅助CA的证书,该辅助CA专门预期向个人发出证书,而不是信任机构根CA。


配置服务器

CAS只能在客户端通过TLS / SSL连接时安全操作。因此,无论是否支持X.509证书,CAS安装都将面临为服务器获取证书,安装证书并打开SSL端口的问题。但是,如上所述,当您随后要向之前由用户标识/密码表单驱动的CAS添加X.509支持时,您可能需要使用不同的证书和SSL配置,这可能涉及添加第二个端口。

配置Tomcat

这里所说的任何内容都扩展了Tomcat的Apache参考,可以在http://tomcat.apache.org/tomcat-5.5-doc/ssl-howto.html  ;(这是5.5版本,但SSL配置是相同的所有Tomcat版本)。

Tomcat服务器在TOMCAT_HOME / conf / server.xml中配置了一个或多个<Connector>元素。这些元素中的每一个都定义了一个端口号,Tomcat将在该端口号上侦听请求。支持SSL的连接器配置有一个或两个表示X.509证书集合的文件。

该keystoreFile是X.509证书其中之一的Tomcat将用来标识自己的浏览器的集合。此证书包含运行Tomcat的服务器的DNS名称,HTTP客户端将其用作URL的服务器名称部分。可以使用包含多个证书的文件(在这种情况下,Tomcat将使用存储在别名“Tomcat”下的证书,或者,如果找不到,将使用它找到的也具有关联私钥的第一个证书) 。但是,为了确保没有错误,使用只有一个主机证书的文件,当然还有父证书颁发机构的私钥和链,这是明智的做法。

该truststoreFile是X.509证书代表的证书颁发机构的集合从Tomcat是愿意接受用户证书。由于keystoreFile包含颁发标识服务器的证书的CA,所以在CAS配置中的truststoreFile和keystoreFile可以是相同的,其中使用X.509认证的URL(实际上是端口)不是公知的交互式URL (用户ID /密码表)登录,因此它信任的唯一的CA是机构内部CA.

但是,如果您打算通过同一端口同时支持X.509和userid / password验证,建议的策略是在keystoreFile中为此服务器放置一个公共(VeriSign,Thawte)证书,但是只放置机构内部CA证书在truststoreFile。在逻辑上和所有文档中,向浏览器信任的服务器颁发证书的证书颁发机构完全和逻辑上独立于将证书颁发给服务器信任的用户的证书颁发机构。Java保持它们分开,Tomcat保持它们分开,并且浏览器不应该被混淆,如果在SSL协商期间,服务器从发出服务器自己的标识证书的CA之外的CA请求用户证书。在该配置中,

如果先前配置了CAS而没有X.509身份验证,那么您可能已经配置了keystoreFile并加载了识别此服务器的证书。所有你需要添加的是truststoreFile部分。

配置的连接器将如下所示:

<!-- Define a SSL HTTP/1.1 Connector on port 443 -->
<Connector port="443" maxHttpHeaderSize="8192"
       maxThreads="150" minSpareThreads="25" maxSpareThreads="75"
       enableLookups="false" disableUploadTimeout="true"
       acceptCount="100" scheme="https" secure="true"
       clientAuth="want" sslProtocol="TLS"
       keystoreFile="/path/to/keystore.jks" keystorePass="secret"
       truststoreFile="/path/to/myTrustStore.jks" truststorePass="secret" />
<!-- if you do not specify a truststoreFile, then the default java "cacerts" truststore will be used-->

 该  clientAuth =“想”  告诉Tomcat要求浏览器提供用户证书(如果可用)。如果要强制使用用户证书,请将“want”替换为“true”。如果指定“want”并且浏览器没有证书,则下面描述的Webflow配置将请求转发到userid / password表单。

注意:如果在此处指定“true”,则Tomcat将要求浏览器显示由在truststoreFile集合中注册的其中一个证书颁发机构颁发的用户证书。但是,X.509 AuthenticationHandler将配置额外的约束。Tomcat可以接受用户证书(如此处配置),但不能通过AuthenticationHandler的其他测试。Webflow通常会向浏览器发送userid / password表单,因为通常当非交互式登录失败时,交互式登录是备份。因此,如果您想要一个只接受X.509身份验证的URL,只需将“want”更改为“true”是不够的。您还必须更改Webflow,以便浏览器不会转发到交互式表单。

密钥库可以在使用Tomcat时在JKS(由Sun为Java创建的密钥和证书的集合)或PKCS12(基于公共标准的密钥和证书的集合)中。当使用PKCS12和JKS密钥库类型时,您应该使用keystoreType和truststoreType属性指定每个密钥库的类型。

JKS(Java密钥存储)文件格式由Sun当前版本Java的Java开发工具包(JDK)分发的/ bin子目录中提供的工具维护。它记录在http://java.sun.com/j2se/1.4.2/docs/tooldocs/windows/keytool.html。通常,您将使用以下命令导入机构证书颁发机构(发出用户证书的证书)的证书:

keytool --import -alias myAlias \
   -keystore myTrustStore.jks \
   -file certificateForInstitutionalCA.crt

然后myTrustStore.jks将成为Tomcat连接配置元素的truststoreFile参数的值。

Java cacerts

前面的讨论解释了如何配置Tomcat(以及通过它在Java中对Java的支持称为JSSE)在SSL设置期间交换服务器和用户证书。但是,一旦Tomcat(或任何其他Java应用程序服务器)将证书传递给CAS,配置的该部分现在就被隐藏。CAS使用内置的Java对证书的支持来验证和检查已经传递的内容。反过来,这取决于本地Java对证书颁发机构的支持。

在运行CAS的Java运行时环境中,有一个JRE_HOME / lib / security / cacerts文件。虽然它不是以.jks结尾,它是一个JKS文件,它预先配置了VeriSign,Thawte和其他公共证书颁发机构的证书。如果你有一个机构证书颁发机构颁发用户证书,并且如果(如大多数机构),你没有决定自己的心,给VeriSign一吨钱,从他们获得证书颁发机构证书,那么你应该也使用keytool将机构CA证书导入到您要在其下运行CAS的JRE的cacerts集合中。


将发行者添加到信任库

您将需要使用一个名为“trustore”的特殊密钥库,其中包含您希望信任的用于交付客户端证书的根CA证书。最安全的方法是创建一个新的空白密钥库,并只添加您真正信任的根CA. 但是,您也可以选择简单的方法,并且还信任已经是JVM(cacerts)的默认信任库的所有根CA. 您必须是priveleged用户才能访问JVM的cacerts信任库。每个密钥库都受密码保护。默认的“cacerts”文件的默认密码是“changeit”。

注意:“\”表示该命令应该在同一行上继续。

要将CA证书导入JVM的信任列表:

keytool --import -alias myAlias \
    -keystore $JAVA_HOME/jre/lib/security/cacerts \
    -file filenameForYourTrustedCA.crt

导入应该成功(回答yes以确认导入)。现在,您可以使用由此颁发者颁发的所有证书进行基于证书的登录,例如Tomcat。

或者,以下是创建空密钥库并将可信发行者导入到其中的命令:

keytool -genkey -keyalg RSA -alias "selfsigned" -keystore myTrustStore.jks
 -storepass "secret" -validity 360
 
keytool -delete -alias "sensible-name-for-ca" -keystore myTrustStore.jks
 
keytool --import -alias myAlias \
   -keystore myTrustStore.jks \
   -file filenameForYourTrustedCA.crt

为X.509用户证书配置CAS 


包括处理程序

在您的CAS Maven2 WAR覆盖的pom.xml文件中,添加以下依赖关系:

<dependency>
     <groupId>org.jasig.cas</groupId>
     <artifactId>cas-server-support-x509</artifactId>
     <version>${cas.version}</version>
</dependency>


配置Web流

原始Webflow XML配置文件位于$ {project.home} /cas-server-webapp/src/main/webapp/WEB-INF/login-webflow.xml中。您可以通过从github的CAS修订控制直接获取它的CAS版本的副本。例如,对于3.4.10版本,您可以下载< https://raw.github.com/Jasig/cas/v3.4.10/cas-server-webapp/src/main/webapp/WEB-INF/login-webflow .xml >。

Webflow由一系列操作组成。一些操作是产生真或假结果的测试。其他操作产生命名结果,如“成功”或“错误”。每个结果导致流程移动到另一个操作。

显示带有userid和password字段的窗体的操作是“viewLoginForm”。有两种方法可以访问viewLoginForm。你可以从初步测试的顺序(以查看你是否已经有一个登录cookie,等等),或者你可以回到它,如果你输入一个坏的用户名或密码。配置将更改为将X.509处理添加到初步测试的序列中。

注意:SPNEGO是另一个可选测试。如果您打算同时支持SPNEGO和X.509证书,您必须事先决定哪两个是先行。具体来说,如果用户坐在以“hyde”身份登录的Windows机器上,但浏览器中的X.509证书表明其身份为“jekyll”,则CAS将首先查看并接受两个凭证中的哪一个。然后相应地调整Webflow配置。

首先从“startAuthenticate”检查周围删除XML注释(开始时为“<! - ”,结束处为“ - >”)。

<!--
<action-state id="startAuthenticate">
<action bean="x509Check" />
<transition on="success" to="sendTicketGrantingTicket" />
<transition on="error" to="viewLoginForm" />
</action-state>
-->

在版本3.4.2和更高版本中,将<action bean =“x509Check”/>更改为<evaluate expression =“x509Check”/>。否则,在尝试访问登录页面时将显示“CAS服务器不可用”消息。

虽然状态的名称是“startAuthenticate”,您可以从源中看到这是一个“x509Check”。SPNEGO还使用名称“startAuthenticate”进行测试,因此如果您同时使用SPNEGO和X509,那么其中一个将是“startAuthenticate”,另一个将是其他东西,如“continueAuthenticate”。在这种情况下,第一个(startAuthenticate)的转换on =“error”将从“viewLoginForm”更改为第二个“continueAuthenticate”的id。


版本特定的警告

以下部分适用于版本3.4.2。在以后的版本中,你需要在“renewRequestCheck”和“gatewayRequestCheck”测试中将“generateLoginTicket”替换为“startAuthenticate”。


现在更改上一个测试的结果。它现在读

<if test="${externalContext.requestParameterMap['renew'] != ''
   &amp;&amp; externalContext.requestParameterMap['renew'] != null}"
   then="viewLoginForm"
   else="generateServiceTicket" />

将测试的结果从“viewLoginForm”更改为“startAuthenticate”,以便当测试为true时,跳转到上面取消注释的测试。现在回到几个测试gatewayRequestCheck和做几乎相同的事情:

<if test="${externalContext.requestParameterMap['gateway'] != ''
   &amp;&amp; externalContext.requestParameterMap['gateway'] != null
   &amp;&amp; flowScope.service != null}"
   then="redirect"
   else="viewLoginForm" />

一个区别是,在此测试中,更改为“startAuthenticate”的“viewLoginForm”位于测试的else部分。

现在已经配置了WebFlow本身,必须定义上面提到的“x509Check”bean。这是在/WEB-INF/cas-servlet.xml文件中完成的。转到该文件并查找带有id =“x509Check”的已注释的bean。bean定义的正确未注释版本是:

<bean
   id="x509Check"
   p:centralAuthenticationService-ref="centralAuthenticationService"
   class="org.jasig.cas.adaptors.x509.web.flow.X509CertificateCredentialsNonInteractiveAction" >
   <property name="centralAuthenticationService" ref="centralAuthenticationService"/>
</bean>

如果这匹配注释中的内容,则只需删除注释。如果没有,那么用这个代码替换注释的bean。


配置认证处理程序

一个bean必须添加到认证处理程序列表中。在文件WEB-INF / deployerConfigContext中找到<bean id =“authenticationManager”>。在它里面,有一个

<property name =“authenticationHandlers”>。在它是一个<list>。在此列表中,添加:
<bean
   class="org.jasig.cas.adaptors.x509.authentication.handler.support.X509CredentialsAuthenticationHandler">
         <property name="trustedIssuerDnPattern" value="CN=Hogwarts Certifying Authority.+" />
         <!--
         <property name="maxPathLength" value="3" />
         <property name="checkKeyUsage" value="true" />
         <property name="requireKeyUsage" value="true" />
         -->
</bean>

当然,您将使用与将颁发您准备信任的用户证书的证书颁发机构的名称匹配的模式替换trustedIssuerDnPattern的value参数中的正则表达式。这应该只包括机构CA,您希望颁发可能安装在浏览器中用于CAS身份验证的用户证书。浏览器将用户证书和颁发用户证书的CA的证书以及每个连续颁发的CA的证书返回给任何CA充当根。如果此链中的任何可分辨名称与trustedIssuerDnPattern正则表达式匹配,则用户证书是可接受的。

这与Tomcat执行的用户证书链(或托管CAS的任何其他应用程序服务器进行的可比较检查)的truststoreFile检查是分开的。它还与Java执行的用户证书链的cacerts检查分开。所有这些检查必须匹配,此外,链中的一个CA必须具有与trustedIssuerDnPattern匹配的DN。

你不应该对X509CredentialsAuthenticationHandler的参数自己过多信任。请记住,如果任何人具有将由您的truststoreFile和cacerts验证的流氓CA,则他们可以使用它来创建具有所需的任何DN的辅助CA,然后使用它来伪造用户证书。但是,如果CAS必须与需要将其他(非用户)机构CA配置到服务器和JVM的其他代码共享应用程序服务器,则这是一种将CAS缩减到一个预期CA的方法。 

请注意,您可以使用正则表达式定义一系列可信发行者。强烈建议将根CA列为受信任的颁发者,尽管可以列出链中的任何发放者以接受客户端证书。在执行这些检查时,证书链会从根证书转移到最终用户证书

此证书是否仍然有效?

这是受信任发行者的证书吗?[default =。*]

pathLength是否在配置的限制内?[default = 1]

checkKeyUsage:检查客户端证书的密钥使用扩展的值,如果它存在于最终用户证书[default = false]

requireKeyUsage:fail是密钥使用扩展不在最终用户证书中[default = false]

检查中间证书的数量

OR如果是和最终用户证书:(

可选)证书是否包含正确的KeyUsage约束?

链中是否有受信任的发行者?

保持WEB-INF / deployerConfigContext文件打开以进行下一步。


将凭据配置为主解析器

一个bean必须添加到WEB-INF / deployerConfigContext文件中的凭证到主解析器列表中。在“authenticationManger”中找到具有<list>的属性name =“credentialsToPrincipalResolvers”。为此列表添加一个bean。但是,您使用的bean确切取决于您将X.509证书字段解析为交互式用户标识/密码登录产生的相同类型的Principal名称的策略。

org.jasig.cas.adaptors.x509.authentication.principal.X509CertificateCredentialsToDistinguishedNamePrincipalResolver - 检索完整的专有名称并将其用作标识符。

org.jasig.cas.adaptors.x509.authentication.principal.X509CertificateCredentialsToIdentifierPrincipalResolver - 将标识符的某些子集转换为主体的ID。

org.jasig.cas.adaptors.x509.authentication.principal.X509CertificateCredentialsToSerialNumberPrincipalResolver - 使用证书的唯一序列号。

org.jasig.cas.adaptors.x509.authentication.principal.X509CertificateCredentialsToSerialNumberAndIssuerDNPrincipalResolver - 使用CA名称和该CA证书的唯一序列号,为此证书创建一个最可能的全局唯一引用,作为类似于DN的条目。

从一个简单的例子开始,它使用可分辨名称中的第一个CN字段并将其用作Principal:

<bean
   class="org.jasig.cas.adaptors.x509.authentication.principal.X509CertificateCredentialsToIdentifierPrincipalResolver">
   <property name="identifier" value="$OU $CN" />
</bean>

此bean基于“identifier”属性的value属性中的模式创建一个主体。该值具有由“$”形成的变量,后跟DN中的字段的名称。因此,为了扫描具有“CN = Potter,OU = Gryffindor,DC = hogwarts,DC = edu”的可分辨名称的证书,它将CN =匹配到标识符的$ CN,并将OU =匹配到$ OU的模式,产生一个主要的名字“格兰芬多波特”。

可以从证书中提取字段,然后通过LDAP查找(包括在CAS 3.1中)将其解析为主体名称。这是一个相当复杂的示例,有关更多详细信息,请参阅LDAP文档:

<property name="credentialsToPrincipalResolvers">
[...]
            <bean
                class="org.jasig.cas.authentication.principal.CredentialsToLDAPAttributePrincipalResolver" >
                <!-- the LDAP resolver uses any kind of CredentialsResolver that will first extract a value from the request.
                    The extracted value will then be matched against an LDAP attribute as configured below -->
                <property name="credentialsToPrincipalResolver">
                    <!--
                        This resolver this will create a unique ID of form:
                        SERIALNUMBER=<certificate_serial_number>, <certificate_issuerDN>
                        eg: SERIALNUMBER=25263647932548882251489395556682941778, SERIALNUMBER=200301, CN=Citizen CA, C=BE
                        ["SERIALNUMBER=" and ", " can be configured, see included source]
                        This should be stored and compared in LDAP using a record with schema description:
                         *  EQUALITY distinguishedNameMatch
                         *  SYNTAX 1.3.6.1.4.1.1466.115.121.1.12   [=distinguishedName]
                    -->
                    <bean class="org.jasig.cas.adaptors.x509.authentication.principal
                    .X509CertificateCredentialsToSerialNumberAndIssuerDNPrincipalResolver" />
                </property>
                <!-- attribute that needs to be matched to in LDAP: -->
                <property name="filter" value="eIDnumber=%u" />
                <!-- to be retrieved from LDAP as the new principal (logged in user) for CAS: -->
                <property name="principalAttributeName" value="uid" />
                <property name="searchBase" value="ou=people,dc=domain,dc=be" />
                <!-- reference to LDAP server configuration: -->
                <property name="contextSource" ref="LdapContextSource" />
            </bean>
[...]
        </list>
    </property>
[...]
    </bean>
    <!-- for LDAP lookups; check CAS LDAP documentation for more details -->
    <bean id="LdapContextSource" class="org.jasig.cas.adaptors.ldap.util.AuthenticatedLdapContextSource">
        <property name="pooled" value="true" />
        <!-- remove userName and password if you can do anonymous lookup of the necessary values -->
        <property name="userName" value="CN=root" />
        <property name="password" value="secret" />
        <property name="urls">
            <list>
                <value>ldap://localhost/</value>
            </list>
        </property>
    </bean>
 </beans>

关注下方微信公众号“Java精选”(w_z90110),回复关键字领取资料:如HadoopDubboCAS源码等等,免费领取资料视频和项目。 

涵盖:程序人生、搞笑视频、算法与数据结构、黑客技术与网络安全、前端开发、Java、Python、Redis缓存、Spring源码、各大主流框架、Web开发、大数据技术、Storm、Hadoop、MapReduce、Spark、elasticsearch、单点登录统一认证、分布式框架、集群、安卓开发、iOS开发、C/C++、.NET、Linux、Mysql、Oracle、NoSQL非关系型数据库、运维等。

相关推荐

评论

分享:

支付宝

微信