Several Auth Mechanisms and Attribute Release
Francisco Jose Fernandez Rivera
xisco.fernandez at ibsalut.es
Tue Aug 20 04:02:03 EDT 2013
Good morning,
Thanks Scott and Rod for your answers, I appreciate it very much. I will try to explain me better.
LDAP authentication is JAAS based, and I configured as follows:
Config filename: login.config
ShibUserPassAuth {
// Example LDAP authentication
// See: https://wiki.shibboleth.net/confluence/display/SHIB2/IdPAuthUserPass
edu.vt.middleware.ldap.jaas.LdapLoginModule required
ldapUrl="ldap://server_address"
baseDn="ou=users,dc=base"
ssl="true"
userField="sAMAccountName"
serviceUser="shib_apl_user at base "
serviceCredential="*******"
subtreeSearch="true"
userFilter="cn={0}";
};
This allows me to show a form with username and password fields to authenticate to idp.
On the other hand, I configured Kerberos authentication (two different realms) in handler.xml:
<!-- Kerberos Idp -->
<ph:LoginHandler xsi:type="krb:KERBEROS"
kerberosCfg="/etc/krb5.conf"
customUnauthorized="/opt/shibboleth-identityprovider-2.2.0/src/main/webapp/unauthorized.html">
<!-- LoginHandler optional attributes:
kerberosCfg - kerberos configuration file (e.g.: /etc/krb.conf)
customUnauthorized - custom html page for error 401 - Unauthorized. (e.g.: /opt/shibboleth-identityprovider-2.2.1/src/main/webapp/error-404.jsp)
auto_login_durantion - auto login duration (seconds)
loginPagePattern - (default: "/login.jsp") - path for login page
krbServletPattern - (default: "/Authn/Kerberos") - path for kerberos login page
-->
<ph:AuthenticationMethod>urn:oasis:names:tc:SAML:2.0:ac:classes:Kerberos</ph:AuthenticationMethod>
<krb:Realm domain="OFUSCATED">
<krb:principal>HTTP/OFUSCATED at OFUSCATED</krb:principal>
<krb:keytab>/home/shibboleth/Kerberos_Keytab/shibkeytab</krb:keytab>
</krb:Realm>
<krb:Realm domain="ANOTHER_DOMAIN">
<krb:principal>HTTP/OFUSCATED at ANOTHER_DOMAIN</krb:principal>
<krb:keytab>/home/shibboleth/Kerberos_Keytab/shibboleth_dc_pre.keytab</krb:keytab>
<!-- Realm optional elements:
<krb:password>password (if no keytab available)</krb:password> -->
</krb:Realm>
</ph:LoginHandler>
This is working, but, one thing that makes me doubt is that in login.config it seems that I also could have configured Kerberos via JAAS, but following documentation I did it this way.
So, at this moment I have a login page that allows users to enter username/password in a form, or simply press a button for Kerberos login (this is just a test enviornment) and the login process ends successfully.
At this stage, I have to be able to resolve attributes independently of the login mechanism used. This is my attribute-resolver.xml config:
<!-- Resolver SSO Kerberos -->
<resolver:AttributeDefinition id="principalName"
xsi:type="ad:PrincipalName"
dependencyOnly="true">
</resolver:AttributeDefinition>
<resolver:AttributeDefinition id="krb_principalname"
xsi:type="ad:Mapped"
sourceAttributeID="principalName"
dependencyOnly="true" >
<resolver:Dependency ref="principalName" />
<ad:ValueMap>
<ad:ReturnValue>$1</ad:ReturnValue>
<ad:SourceValue>(.+)@(.+)</ad:SourceValue>
</ad:ValueMap>
</resolver:AttributeDefinition>
<resolver:DataConnector id="TEST_ADCorp_LDAP" xsi:type="dc:LDAPDirectory"
ldapURL="ldap://server_address"
baseDN=""ou=users,dc=base""
principal="shib_apl_user at base"
principalCredential="*******">
<resolver:Dependency ref="krb_principalname" />
<dc:FilterTemplate>
<![CDATA[
(&(objectClass=user)(|(sAMAccountName=$requestContext.principalName)(cn=${krb_principalname.get(0)})))
]]>
</dc:FilterTemplate>
</resolver:DataConnector>
I thought the filter I built should work in both situations, because when I log in using LDAP/JAAS, requestContext.principalName has the username value, (for example: U009876), and if I log in using Kerberos principalName has the value U009876 at REALM)
As I configured dependency, the problem arises when I log in using LDAP username/password:
12:45:51.152 - DEBUG [edu.internet2.middleware.shibboleth.idp.profile.saml2.AbstractSAML2ProfileHandler:474] - Resolving attributes for principal U009876 for SAML request from relying party 'https://ofuscated/secure'
12:45:51.152 - DEBUG [edu.internet2.middleware.shibboleth.common.attribute.resolver.provider.ShibbolethAttributeResolver:119] - shibboleth.AttributeResolver resolving attributes for principal U009876
12:45:51.152 - DEBUG [edu.internet2.middleware.shibboleth.common.attribute.resolver.provider.ShibbolethAttributeResolver:275] - Specific attributes for principal U009876 were not requested, resolving all attributes.
12:45:51.152 - DEBUG [edu.internet2.middleware.shibboleth.common.attribute.resolver.provider.ShibbolethAttributeResolver:314] - Resolving attribute uid for principal U009876
12:45:51.153 - DEBUG [edu.internet2.middleware.shibboleth.common.attribute.resolver.provider.ShibbolethAttributeResolver:354] - Resolving data connector TEST_ADCorp_LDAP for principal U009876
12:45:51.153 - DEBUG [edu.internet2.middleware.shibboleth.common.attribute.resolver.provider.ShibbolethAttributeResolver:314] - Resolving attribute krb_principalname for principal U009876
12:45:51.153 - DEBUG [edu.internet2.middleware.shibboleth.common.attribute.resolver.provider.ShibbolethAttributeResolver:314] - Resolving attribute principalName for principal U009876
12:45:51.153 - DEBUG [edu.internet2.middleware.shibboleth.common.attribute.resolver.provider.ShibbolethAttributeResolver:336] - Resolved attribute principalName containing 1 values
12:45:51.153 - DEBUG [edu.internet2.middleware.shibboleth.common.attribute.resolver.provider.attributeDefinition.MappedAttributeDefinition:97] - Attribute Definition krb_principalname: mapping depdenency attribute value U009876
12:45:51.154 - DEBUG [edu.internet2.middleware.shibboleth.common.attribute.resolver.provider.attributeDefinition.ValueMap:84] - Attempting to map attribute value 'U009876'
12:45:51.154 - DEBUG [edu.internet2.middleware.shibboleth.common.attribute.resolver.provider.attributeDefinition.ValueMap:99] - Performing regular expression based comparison
12:45:51.154 - DEBUG [edu.internet2.middleware.shibboleth.common.attribute.resolver.provider.attributeDefinition.MappedAttributeDefinition:119] - Attribute Definition krb_principalname: mapped depdenency attribute value U009876 to the values []
12:45:51.154 - DEBUG [edu.internet2.middleware.shibboleth.common.attribute.resolver.provider.ShibbolethAttributeResolver:336] - Resolved attribute krb_principalname containing 0 values
12:45:51.156 - ERROR [org.apache.velocity:86] - Method get threw exception for reference $krb_principalname in template shibboleth.resolver.dc.TEST_ADCorp_LDAP at [1,73]
12:45:51.779 - ERROR [edu.internet2.middleware.shibboleth.common.attribute.resolver.provider.dataConnector.TemplateEngine:95] - Unable to populate shibboleth.resolver.dc.TEST_ADCorp_LDAP template
org.apache.velocity.exception.MethodInvocationException: Invocation of method 'get' in class java.util.ArrayList threw exception java.lang.IndexOutOfBoundsException: Index: 0, Size: 0 @ shibboleth.resolver.dc.TEST_ADCorp_LDAP[1,93]
So, what I understand it is happening is that the regexp is doing its job and giving me a blank value for krb_principalname, and attribute resolving fails in that case.
That is why I was wondering that I should do some scripting in CDATA section to detect that case and launch one search filter or another, instead of an "all in one" filter. ¿This would be the correct approach?
Thanks in advanced,
Francisco.
-----Mensaje original-----
De: users-bounces at shibboleth.net [mailto:users-bounces at shibboleth.net] En nombre de Cantor, Scott
Enviado el: lunes, 19 de agosto de 2013 15:33
Para: Shib Users
Asunto: Re: Several Auth Mechanisms and Attribute Release
On 8/19/13 8:51 AM, "Rod Widdowson" <rdw at steadingsoftware.com> wrote:
>> I have a test setup with Shibboleth and have implemented login
>> through
>username/password against AD and also Kerberos against the same AD.
>
>When you say ³Username/Password² do you mean "LDAP via JAAS"? If so,
>have you considered implementing is via KRB5 and JAAS? That way you
>might/should get the correct principal. I have not tried this for
>quite some time so things may be different, but I am sure that a one
>stage (which may have been
>1.3) KRB/JAAS gave you a "qualified with the domain" principal...
The V2 code returns the first Principal in the Subject as the "principal name", which is probably somewhat unpredictable. My custom code doesn't return a Java Subject to the IdP, so I don't know what the vanilla behavior is anymore.
Anybody relying on that sort of approach probably oughtn't use request.principalName in the resolver.
-- Scott
--
To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net
More information about the users
mailing list