Login.config vs. attribute-resolve.xml?

[Chad La Joie]

The two items are wholly separate and each will behave the way in which
you configure it.  If you configure the authentication component that
use LDAPS or LDAP w/ startTLS, then that's what it will do.  If you
configure the attribute resolver no to use LDAPS or startTLS, then
that's what it will do.

On 6/4/12 2:36 PM, Kanuch, Andy wrote:
> So, in terms of encryption,   the login.config will decide if the authentication is encrypted (via LDAPS), but if I were to no encryption for attribute-resolver the attributes would be sent in clear text? (to include the login data listed in the attribute-resolver.xml file?)
> 
> -----Original Message-----
> From: users-bounces at shibboleth.net [mailto:users-bounces at shibboleth.net] On Behalf Of Chad La Joie
> Sent: Monday, June 04, 2012 1:28 PM
> To: Shib Users
> Subject: Re: Login.config vs. attribute-resolve.xml?
> 
> login.config is the JAAS configuration file.  JAAS (Java Authentication and Authorization Service) is a part of the JVM and can be used by the IdP to perform authentication.
> 
> attribute-resolver.xml is used by the IdP to resolve attributes.
> 
> On 6/4/12 2:22 PM, Kanuch, Andy wrote:
>> My IDP working via the testshib page with Active Directory (Huzzah!).  
>> Now I just want to be sure I'm applying best practices for security. 
>> Is there any reason to not use LDAPS over LDAP as the connection protocol?
>>
>>  
>>
>> I'm also bit confused about what role the _login.config_  file plays vs.
>> the DataConnector in _attribute-resolve.xml_.   Both files contain
>> connection information for my LDAP (Active Directory) server.  So when 
>> does Shibboleth refer to each data set for connection information?
>>
>>  
>>
>> _Login.config:_
>>
>>  
>>
>>    edu.vt.middleware.ldap.jaas.LdapLoginModule required
>>
>>       host="DomainController.MyDomain.LOCAL"
>>
>>       port="3268"
>>
>>       base="DC=MyDomain,DC=local"
>>
>>       tls="true"
>>
>>       serviceCredential="62592fmu4tv"
>>
>>       userRoleAttribute="sAMAccountName"
>>
>>       serviceUser="shibboleth.user at MyDomain.local"
>>
>>       subtreeSearch = "true"
>>
>>       userField="samAccountName";
>>
>>  
>>
>>  
>>
>> _Attribute-Resolver.xml_
>>
>>  
>>
>>     <resolver:DataConnector id="myLDAP" xsi:type="LDAPDirectory"
>> xmlns="urn:mace:shibboleth:2.0:resolver:dc"
>>
>>         useStartTLS="true"
>>
>>         ldapURL="ldap://DomainController.MyDomain.LOCAL:389"
>> baseDN="DC=MyDomain,DC=local" principal="shibboleth.user at MyDomain.local"
>>
>>         principalCredential="62592fmu4tv">
>>
>>         <FilterTemplate>
>>
>>             <![CDATA[
>>
>>                 (sAMAccountName=$requestContext.principalName)
>>
>>             ]]>
>>
>>         </FilterTemplate>
>>
>>  
>>
>>         <!-- We rely on the uniqueness of the objectSid.  But it is 
>> binary so we *must* make it so -->
>>
>>         <LDAPProperty name="java.naming.ldap.attributes.binary"
>> value="objectSid"/>
>>
>>         <!-- If we are following from the GC we need thus on -->
>>
>>         <LDAPProperty name="java.naming.referral" value="follow"/>
>>
>>  
>>
>>     </resolver:DataConnector>
>>
>>
>>
>> --
>> To unsubscribe from this list send an email to 
>> users-unsubscribe at shibboleth.net
> --
> To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net
> --
> To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net