Shibboleth IdP is partially working with LDAP, but SAMLResponse NameID (and attributes) are missing
o haya
ohaya1001 at gmail.com
Thu Apr 10 16:50:53 UTC 2025
Hi,
1) I want to confirm that the IdP is at context /idp, but the Tomcat is
listening at port 34887, e.g., the Shibboleth IdP metadata is available at
https://idp01.xxxx.com:34487/idp/shibboleth
2) FYI, I want to confirm that I do try to read every message/email, but
honestly, sometimes, I don't fully understand every detail of ever message
:(...
3) The IdP that is "in front of" the Shibboleth IdP allows us to set some
parameters for the requests it sends to the Shibboleth IdP:
*Requested Name ID format:* currently 'unspecified'
*Identity provider user attribute* currently 'cn' (this is the
attribute at the Shibboleth IdP end)
*Identity domain user attribute * currently 'Username' (this is the
attribute at the "in front" IdP end)
We've tested with different combinations... some cause the in front IdP to
flag the SAMLResponse as causing an error; some cause the in front IdP to
NOT flag the SAMLResponse as an error, but indicates that there was no user
was in the response.
The combination above caused the latter and when we look at the
SAMLResponse the NameID format is 'transient' and contains like a random
string.
I was checking in the Shibboleth IdP logs and saw this:
2025-04-10 11:48:46,732 - 100.36.xx.yy - INFO
> [org.ldaptive.auth.Authenticator:372] - Authentication succeeded for dn:
> cn=test1,ou=People,dc=xxxx,dc=com
> 2025-04-10 11:48:46,733 - 100.36.xx.yy - INFO
> [net.shibboleth.idp.authn.impl.LDAPCredentialValidator:176] - Credential
> Validator ldap: Login by 'test1' succeeded
> 2025-04-10 11:48:46,963 - 100.36.xx.yy - INFO
> [net.shibboleth.idp.authn.impl.FinalizeAuthentication:201] - Profile Action
> FinalizeAuthentication: Principal test1 authenticated
> 2025-04-10 11:48:47,067 - 100.36.xx.yy - DEBUG
> [org.opensaml.saml.saml2.profile.impl.AbstractResponseShellAction:213] -
> Profile Action AddStatusResponseShell: Setting Issuer to
> https://idp01.xxxx.com/idp/shibboleth
> 2025-04-10 11:48:47,084 - 100.36.xx.yy - DEBUG
> [org.opensaml.saml.common.profile.impl.AddInResponseToToResponse:106] -
> Profile Action AddInResponseToToResponse: Attempting to add InResponseTo to
> outgoing Response
> 2025-04-10 11:48:47,119 - 100.36.xx.yy - DEBUG
> [org.opensaml.saml.saml2.profile.SAML2ActionSupport:78] - Profile Action
> AddAuthnStatementToAssertion: Created Assertion
> _4081d5fc783976b6df13fee4228a5b44
> 2025-04-10 11:48:47,142 - 100.36.xx.yy - DEBUG
> [org.opensaml.saml.saml2.profile.SAML2ActionSupport:102] - Profile Action
> AddAuthnStatementToAssertion: Added Assertion
> _4081d5fc783976b6df13fee4228a5b44 to Response
> _e27dc13bea1b4217ce218e63c7c7dc4e
> 2025-04-10 11:48:47,194 - 100.36.xx.yy - DEBUG
> [org.opensaml.saml.saml2.profile.impl.AddNameIDToSubjects:278] - Profile
> Action AddNameIDToSubjects: Attempting to add NameID to outgoing Assertion
> Subjects
> 2025-04-10 11:48:47,196 - 100.36.xx.yy - DEBUG
> [org.opensaml.saml.common.profile.logic.MetadataNameIdentifierFormatStrategy:80]
> - Metadata specifies the following formats: []
> 2025-04-10 11:48:47,196 - 100.36.xx.yy - DEBUG
> [org.opensaml.saml.saml2.profile.impl.AddNameIDToSubjects:315] - Profile
> Action AddNameIDToSubjects: Candidate NameID formats:
> [urn:oasis:names:tc:SAML:2.0:nameid-format:transient]
> 2025-04-10 11:48:47,197 - 100.36.xx.yy - DEBUG
> [org.opensaml.saml.saml2.profile.impl.AddNameIDToSubjects:389] - Profile
> Action AddNameIDToSubjects: Trying to generate NameID with Format
> urn:oasis:names:tc:SAML:2.0:nameid-format:transient
>From the above, seems like the Shibboleth IdP was able to successfully
authenticate the user "test1", but determined that the format for the
NameID in the response should be transient and it populated that with a
generated value instead of the username "test1".
I think in earlier messages, it was mentioned to figure out the attribute
resolver first, but it seems like if we could get the nameId format to
something other than transient, it might be helpful?
4) I was wondering, in general, if there might be things in the log files
to that might be helful to figure out why the SAMLResponse messages are not
providing the attributes and nameid? Can I bump up the loglevels and would
that provide information that might be helpful?
FYI, here's my current logback.xml (it is mostly original):
<?xml version="1.0" encoding="UTF-8"?>
> <configuration>
>
> <!--
> Variables for simplifying logging configuration.
> http://logback.qos.ch/manual/configuration.html#variableSubstitution
> -->
>
> <!--
> If you want to use custom properties in this config file,
> we load the main property file for you.
> -->
> <variable file="${idp.home}/conf/idp.properties" />
>
> <!-- Location and retention. -->
>
> <variable name="idp.logfiles"
> value="${idp.logfiles:-${idp.home}/logs}" />
> <variable name="idp.loghistory" value="${idp.loghistory:-180}" />
>
> <!-- Much higher performance if you operate on DEBUG. -->
> <!-- <variable name="idp.process.appender" value="ASYNC_PROCESS" /> -->
>
> <!-- Logging level shortcuts. -->
> <variable name="idp.loglevel.idp" value="${idp.loglevel.idp:-INFO}" />
> <variable name="idp.loglevel.ldap" value="${idp.loglevel.ldap:-WARN}"
> />
> <variable name="idp.loglevel.messages"
> value="${idp.loglevel.messages:-DEBUG}" />
> <variable name="idp.loglevel.encryption"
> value="${idp.loglevel.encryption:-INFO}" />
> <variable name="idp.loglevel.opensaml"
> value="${idp.loglevel.opensaml:-DEBUG}" />
> <variable name="idp.loglevel.shared"
> value="${idp.loglevel.shared:-INFO}" />
> <variable name="idp.loglevel.props"
> value="${idp.loglevel.props:-INFO}" />
> <variable name="idp.loglevel.httpclient"
> value="${idp.loglevel.httpclient:-INFO}" />
>
> <!-- Don't turn these up unless you want a *lot* of noise. -->
> <variable name="idp.loglevel.spring"
> value="${idp.loglevel.spring:-WARN}" />
> <variable name="idp.loglevel.container"
> value="${idp.loglevel.container:-ERROR}" />
> <variable name="idp.loglevel.xmlsec"
> value="${idp.loglevel.xmlsec:-INFO}" />
>
> <!-- =========================================================== -->
> <!-- ============== Logging Categories and Levels ============== -->
> <!-- =========================================================== -->
>
> <!-- Logs IdP, but not OpenSAML, messages -->
> <logger name="net.shibboleth.idp" level="${idp.loglevel.idp}"/>
>
> <!-- Logs OpenSAML, but not IdP, messages -->
> <logger name="org.opensaml.saml" level="${idp.loglevel.opensaml}"/>
>
> <!-- Logs supporting code. -->
> <logger name="net.shibboleth.shared" level="${idp.loglevel.shared}"/>
>
> <!-- Logs LDAP related messages -->
> <logger name="org.ldaptive" level="${idp.loglevel.ldap}"/>
>
>
>
>
> <!-- JL - From https://help.switch.ch/aai/guides/idp/installation/
> Section 6.5 - to log authen fail/success -->
> <logger name="org.ldaptive.auth.Authenticator" level="INFO" />
>
>
>
>
>
> <!-- Logs embedded HTTP client messages -->
> <logger name="org.apache.hc" level="${idp.loglevel.httpclient}"/>
>
> <!-- Logs inbound and outbound protocols messages at DEBUG level -->
> <logger name="PROTOCOL_MESSAGE" level="${idp.loglevel.messages}" />
>
> <!-- Logs unencrypted SAML at DEBUG level -->
> <logger name="org.opensaml.saml.saml2.encryption.Encrypter"
> level="${idp.loglevel.encryption}" />
> <logger name="org.opensaml.saml.saml2.encryption.Decrypter"
> level="${idp.loglevel.encryption}" />
>
> <!-- Logs system properties during startup at DEBUG level -->
> <logger name="net.shibboleth.idp.admin.impl.LogImplementationDetails"
> level="${idp.loglevel.props}" />
>
> <!-- Especially chatty. -->
> <logger name="org.apache.xml.security" level="${idp.loglevel.xmlsec}"
> />
> <logger name="org.springframework" level="${idp.loglevel.spring}"/>
> <logger name="org.apache.catalina" level="${idp.loglevel.container}"/>
> <logger name="org.eclipse.jetty" level="${idp.loglevel.container}"/>
>
>
> <!-- =========================================================== -->
> <!-- ============== Low Level Details or Changes =============== -->
> <!-- =========================================================== -->
>
> <!-- Process log. -->
> <appender name="IDP_PROCESS"
> class="ch.qos.logback.core.rolling.RollingFileAppender">
> <File>${idp.logfiles}/idp-process.log</File>
>
> <rollingPolicy
> class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy">
>
> <fileNamePattern>${idp.logfiles}/idp-process-%d{yyyy-MM-dd}.log.gz</fileNamePattern>
> <maxHistory>${idp.loghistory}</maxHistory>
> </rollingPolicy>
>
> <encoder
> class="ch.qos.logback.classic.encoder.PatternLayoutEncoder">
> <charset>UTF-8</charset>
> <Pattern>%date{ISO8601} - %mdc{idp.remote_addr} - %level
> [%logger:%line] - %msg%n%ex{short}</Pattern>
> </encoder>
>
> <!-- Ignore Velocity status page error. -->
> <filter class="ch.qos.logback.core.filter.EvaluatorFilter">
> <evaluator>
> <matcher>
> <Name>VelocityStatusMatcher</Name>
> <regex>ResourceManager\s*: unable to find resource
> 'status\.vm' in any resource loader\.</regex>
> </matcher>
>
> <expression>VelocityStatusMatcher.matches(formattedMessage)</expression>
> </evaluator>
> <OnMatch>DENY</OnMatch>
> </filter>
> </appender>
>
> <appender name="ASYNC_PROCESS"
> class="ch.qos.logback.classic.AsyncAppender">
> <appender-ref ref="IDP_PROCESS" />
> <discardingThreshold>0</discardingThreshold>
> </appender>
>
> <appender name="IDP_WARN"
> class="ch.qos.logback.core.rolling.RollingFileAppender">
> <!-- Suppress anything below WARN. -->
> <filter class="ch.qos.logback.classic.filter.ThresholdFilter">
> <level>WARN</level>
> </filter>
>
> <File>${idp.logfiles}/idp-warn.log</File>
>
> <rollingPolicy
> class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy">
>
> <fileNamePattern>${idp.logfiles}/idp-warn-%d{yyyy-MM-dd}.log.gz</fileNamePattern>
> <maxHistory>${idp.loghistory}</maxHistory>
> </rollingPolicy>
>
> <encoder
> class="ch.qos.logback.classic.encoder.PatternLayoutEncoder">
> <charset>UTF-8</charset>
> <Pattern>%date{ISO8601} - %mdc{idp.remote_addr} - %level
> [%logger:%line] - %msg%n%ex{full}</Pattern>
> </encoder>
>
> <!-- Ignore Velocity status page error. -->
> <filter class="ch.qos.logback.core.filter.EvaluatorFilter">
> <evaluator>
> <matcher>
> <Name>VelocityStatusMatcher</Name>
> <regex>ResourceManager\s*: unable to find resource
> 'status\.vm' in any resource loader\.</regex>
> </matcher>
>
> <expression>VelocityStatusMatcher.matches(formattedMessage)</expression>
> </evaluator>
> <OnMatch>DENY</OnMatch>
> </filter>
> </appender>
>
> <!-- Audit log. -->
> <appender name="IDP_AUDIT"
> class="ch.qos.logback.core.rolling.RollingFileAppender">
> <File>${idp.logfiles}/idp-audit.log</File>
>
> <rollingPolicy
> class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy">
>
> <fileNamePattern>${idp.logfiles}/idp-audit-%d{yyyy-MM-dd}.log.gz</fileNamePattern>
> <maxHistory>${idp.loghistory}</maxHistory>
> </rollingPolicy>
>
> <encoder
> class="ch.qos.logback.classic.encoder.PatternLayoutEncoder">
> <charset>UTF-8</charset>
> <Pattern>%msg%n</Pattern>
> </encoder>
> </appender>
>
> <!-- Consent audit log. -->
> <appender name="IDP_CONSENT_AUDIT"
> class="ch.qos.logback.core.rolling.RollingFileAppender">
> <File>${idp.logfiles}/idp-consent-audit.log</File>
>
> <rollingPolicy
> class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy">
>
> <fileNamePattern>${idp.logfiles}/idp-consent-audit-%d{yyyy-MM-dd}.log.gz</fileNamePattern>
> <maxHistory>${idp.loghistory}</maxHistory>
> </rollingPolicy>
>
> <encoder
> class="ch.qos.logback.classic.encoder.PatternLayoutEncoder">
> <charset>UTF-8</charset>
> <Pattern>%msg%n</Pattern>
> </encoder>
> </appender>
>
> <!-- F-TICKS syslog destination. -->
> <appender name="IDP_FTICKS"
> class="ch.qos.logback.classic.net.SyslogAppender">
> <syslogHost>${idp.fticks.loghost:-localhost}</syslogHost>
> <port>${idp.fticks.logport:-514}</port>
> <facility>AUTH</facility>
> <suffixPattern>[%thread] %logger %msg</suffixPattern>
> </appender>
>
> <!-- Top level loggers. -->
>
> <logger name="Shibboleth-Audit" level="ALL">
> <appender-ref ref="${idp.audit.appender:-IDP_AUDIT}"/>
> </logger>
>
> <logger name="Shibboleth-FTICKS" level="ALL" additivity="false">
> <appender-ref ref="${idp.fticks.appender:-IDP_FTICKS}"/>
> </logger>
>
> <logger name="Shibboleth-Consent-Audit" level="ALL">
> <appender-ref ref="${idp.consent.appender:-IDP_CONSENT_AUDIT}"/>
> </logger>
>
> <root level="${idp.loglevel.root:-INFO}">
> <appender-ref ref="${idp.process.appender:-IDP_PROCESS}"/>
> <appender-ref ref="${idp.warn.appender:-IDP_WARN}" />
> </root>
>
> <!-- Example routing Password flow auditing to separate location
> (extend to other flows as needed). -->
>
> <!--
> <appender name="IDP_PASSWORD_AUDIT"
> class="ch.qos.logback.core.rolling.RollingFileAppender">
> <File>${idp.logfiles}/idp-password-audit.log</File>
>
> <rollingPolicy
> class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy">
>
> <fileNamePattern>${idp.logfiles}/idp-password-audit-%d{yyyy-MM-dd}.log.gz</fileNamePattern>
> <maxHistory>${idp.loghistory}</maxHistory>
> </rollingPolicy>
>
> <encoder
> class="ch.qos.logback.classic.encoder.PatternLayoutEncoder">
> <charset>UTF-8</charset>
> <Pattern>%msg%n</Pattern>
> </encoder>
> </appender>
>
> <logger name="Shibboleth-Audit.Password" level="ALL"
> additivity="false">
> <appender-ref ref="IDP_PASSWORD_AUDIT"/>
> </logger>
> -->
>
> </configuration>
>
If someone could suggest which ones to bump up, I'd be glad to try that?
Thanks, and sorry for the longish message...
Jim
<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail>
Virus-free.www.avast.com
<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail>
<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
On Thu, Apr 10, 2025 at 11:49 AM Peter Schober via users <
users at shibboleth.net> wrote:
> Peter Schober via users <users at shibboleth.net> [2025-04-10 17:45 CEST]:
> > Anyway, try `-k https://localhost:34487` instead of all of the above.
> > Same for the aacli.
>
> -k -u https://localhost:34487/idp
>
> Or use the IDP_BASE_URL env var instead, as documented.
>
> to be precise. That's still assuming the IDP has been deployed to the
> context /idp
>
> -peter
> --
> For Consortium Member technical support, see
> https://shibboleth.atlassian.net/wiki/x/ZYEpPw
> To unsubscribe from this list send an email to
> users-unsubscribe at shibboleth.net
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20250410/ab9b310f/attachment.htm>
More information about the users
mailing list