logging.xml enabling

Gilles Badouet badouetg at uni.coventry.ac.uk
Fri Jul 5 11:26:22 EDT 2013


Hi Peter,

edu.vt.middleware.ldap.jaas.JaasAuthenticator




Kind regards





Gilles Rubens Badouet

Student ID: 3940347

Faculty of Engineering and Computing

MSc Network Computing Course

Mobile: 07424486426

________________________________________
From: users-bounces at shibboleth.net [users-bounces at shibboleth.net] on behalf of users-request at shibboleth.net [users-request at shibboleth.net]
Sent: 05 July 2013 16:21
To: users at shibboleth.net
Subject: users Digest, Vol 25, Issue 28

Send users mailing list submissions to
        users at shibboleth.net

To subscribe or unsubscribe via the World Wide Web, visit
        http://shibboleth.net/mailman/listinfo/users
or, via email, send a message with subject or body 'help' to
        users-request at shibboleth.net

You can reach the person managing the list at
        users-owner at shibboleth.net

When replying, please edit your Subject line so it is more specific
than "Re: Contents of users digest..."


Today's Topics:

   1. Re: logging.xml enabling (Peter Schober)
   2. Logout with new shibboleth sp (Justin Russo)
   3. Re: Login issue (Gilles Badouet)


----------------------------------------------------------------------

Message: 1
Date: Fri, 5 Jul 2013 17:11:51 +0200
From: Peter Schober <peter.schober at univie.ac.at>
Subject: Re: logging.xml enabling
To: users at shibboleth.net
Message-ID: <20130705151151.GU16407 at aco.net>
Content-Type: text/plain; charset=us-ascii

* Gilles Badouet <badouetg at uni.coventry.ac.uk> [2013-07-05 16:59]:
> I would like to get some logs for my LDAP JAAS
> configuration. enabled logging in logging.xml for the package
> edu.vt.middleware.ldap, but I dont see any
> edu.vt.middleware.ldap.Ldap line in my idp-process.log neither in
> other shibboleth log files. I enabled the logging by adding the
> following lines in looging.xml:
>
> <logger name="edu.vt.middleware.ldap.jaas.JaasAuthenticator" level="DEBUG"/>
> <logger name="edu.vt.middleware.ldap" level="WARN"/>
>
> I want to see these logs to solve my login issue.

Are you sure you enabled the UsernamePassword login handler in
handler.xml? Maybe post your handler.xml config.
Also:

* Peter Schober <peter.schober at univie.ac.at> [2013-07-05 11:49]:
> Try changing other logging stuff (e.g. anything in there on INFO to
> DEBUG) only to see whether that has an effect. When it does, change it
> back.

Or introduce syntax errors (invalid XML) into logging.xml to make sure
it's actually being read (and change it back afterwards, of course ;)
-peter


------------------------------

Message: 2
Date: Fri, 5 Jul 2013 08:19:36 -0700 (PDT)
From: Justin Russo <justin9 at ymail.com>
Subject: Logout with new shibboleth sp
To: Shib Users <users at shibboleth.net>
Message-ID:
        <1373037576.28578.YahooMailNeo at web163105.mail.bf1.yahoo.com>
Content-Type: text/plain; charset="iso-8859-1"

Hi
Im new to shibboleth and currently using the latest version of shibboleth sp.
I have set everything up and i can login ?using my idp.
for the logout part, i have a button on my page which on click event is linked to the url -?https://mydomain.com/Shibboleth.sso/Logout.

Now this will redirect me to the default shibboleth logout page. I have a few questions.

1. after the default logout page seen, when i hit back button on my browser i can still see the pages of a logged in user, how can i prevent this.

2. i know that when i click logout (https://mydomain.com/Shibboleth.sso/Logout), i go to the deafult shib logout page, i also have a custom logout page, can i redirect it to my custom logout page but at the backend make sure everything works fine. How can i achieve this.
I believe i have to modify my shibboleth2.xml file. currenlty all i have there is -

<Logout>SAML2 Local</Logout>


could you please provide the syntax on how i can redirect to my custom logout page and make sure the shibboleth logout happens as default in backend.

thanks and appreciate you time.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://shibboleth.net/pipermail/users/attachments/20130705/d7342466/attachment-0001.html

------------------------------

Message: 3
Date: Fri, 5 Jul 2013 15:20:37 +0000
From: Gilles Badouet <badouetg at uni.coventry.ac.uk>
Subject: Re: Login issue
To: "users at shibboleth.net" <users at shibboleth.net>
Message-ID:
        <1939041E7E86BB4297EB69590F1F928F65F2F28B at AMSPRD0112MB561.eurprd01.prod.exchangelabs.com>

Content-Type: text/plain; charset="us-ascii"


Hi Peter,

>Try changing other logging stuff (e.g. anything in there on INFO to
>DEBUG) only to see whether that has an effect. When it does, change it
>back.

I changed all to DEBUG and it took effect. But still cant see lines for edu.vt.middleware.ldap regarding
<logger name="edu.vt.middleware.ldap" level="WARN"/>

and  edu.vt.middleware.ldap.jaas.JaasAuthenticator regarding the added
<logger name="edu.vt.middleware.ldap.jaas.JaasAuthenticator" level="DEBUG"/>

Kind regards





Gilles Rubens Badouet

Student ID: 3940347

Faculty of Engineering and Computing

MSc Network Computing Course

Mobile: 07424486426

________________________________________
From: users-bounces at shibboleth.net [users-bounces at shibboleth.net] on behalf of users-request at shibboleth.net [users-request at shibboleth.net]
Sent: 05 July 2013 16:01
To: users at shibboleth.net
Subject: users Digest, Vol 25, Issue 27

Send users mailing list submissions to
        users at shibboleth.net

To subscribe or unsubscribe via the World Wide Web, visit
        http://shibboleth.net/mailman/listinfo/users
or, via email, send a message with subject or body 'help' to
        users-request at shibboleth.net

You can reach the person managing the list at
        users-owner at shibboleth.net

When replying, please edit your Subject line so it is more specific
than "Re: Contents of users digest..."


Today's Topics:

   1. AW: browser refresh problem? (Ortner Nikolaus)
   2. disclosure of  IP address in cookie (Gruber Bernhard SAI sIT)
   3. Re: Login issue (Peter Schober)
   4. Re: browser refresh problem? (Peter Schober)
   5. Re: disclosure of  IP address in cookie (Peter Schober)
   6. AW: browser refresh problem? (Gruber Bernhard SAI sIT)
   7. logging.xml enabling  (Gilles Badouet)
   8. Re: Remote IdP not responding? (Roger Jagoda)


----------------------------------------------------------------------

Message: 1
Date: Fri, 5 Jul 2013 09:35:00 +0000
From: Ortner Nikolaus <N.Ortner at fh-kaernten.at>
Subject: AW: browser refresh problem?
To: 'Shib Users' <users at shibboleth.net>
Message-ID:
        <30128BCB0B9FDB4AAFB81E09D52830DE3A2870B2 at EXMBX01.technikum.local>
Content-Type: text/plain; charset="us-ascii"

> Is this intended? Is browser refresh not supported?

I have no problem with a refresh (using a standard IdP-install, UsernamePasswordAuthHandler).



------------------------------

Message: 2
Date: Fri, 5 Jul 2013 09:40:09 +0000
From: Gruber Bernhard SAI sIT <Bernhard.Gruber at s-itsolutions.at>
Subject: disclosure of  IP address in cookie
To: "users at shibboleth.net" <users at shibboleth.net>
Message-ID: <2A3EAA02A1991E40B836DE3BAEF7CAF24A8CD1F1 at M0183.s-mxs.net>
Content-Type: text/plain; charset="us-ascii"

During a security test of our shibboleth base solution, the following issue was reported to us:

Finding
The iDP component discloses an internal IP address in the value of the _idp_lc_session cookie. The truncated and base64 decoded value of the cookie is as follows.
127.0.0.1|<sessionID>
Risk
The disclosed information might help an attacker in formulating further attacks.
Recommendation
Management should review to options to change the affected cookie value.


Is there a possibility to remove the IP-Address from the cookie?




------------------------------

Message: 3
Date: Fri, 5 Jul 2013 11:48:42 +0200
From: Peter Schober <peter.schober at univie.ac.at>
Subject: Re: Login issue
To: users at shibboleth.net
Message-ID: <20130705094842.GK16407 at aco.net>
Content-Type: text/plain; charset=us-ascii

* Gilles Badouet <badouetg at uni.coventry.ac.uk> [2013-07-05 01:05]:
> Hi Peter,
> >How are you authenticating users in your IdP?
> >Do you use the default edu.vt.middleware.ldap.jaas.LdapLoginModule in
> >login.config? (If you post your config make sure to remove any
> >passwords prior to sending). If so the line I sent you should have
> >lots of information on the LDAP connection, try searching your
> >idp-process.log for lines with "fgrep edu.vt.middleware.ldap.jaas".
>
> I am authenticating users using LDAP through Apache Directory Studio
> 2.0.

Apache Directory Studio is a Directory User Agent ("client") but from
the web page I see it also contains an "Embedded ApacheDS" DSA.
  I don't see what connecting to something like this should achieve
(obviously this is unsuitable for any real use of the IdP and you
don't seem to know enough about the server to connect an LDAP client
to it) but that's your choice.

> I also tried OpenDJ 2.7 but was having the same issue.

The IdP can certainly connect to most or any LDAPv3 DSA, so if it
"doesn't work" it's something in the way you have set up things.
At the provided level of detail (none) it's not really possible to
suggest anything. How to get logs from your DSA is not a topic for
this list.

> I cant see the above lines in idp-process.log.

It will only be there if you modified your logging.xml as indicated in
a previous email (and either restarted the IdP or waited for 10
minutes for the modified logging config to become active).

Try changing other logging stuff (e.g. anything in there on INFO to
DEBUG) only to see whether that has an effect. When it does, change it
back.

> I just know that there is connection between IDP and LDAP server on
> a basis of the login page redirected when the resource is
> requested. The log content I see in LDAP DSA side is only about its
> internal operation and status and when I make a modification on it.

These two sentences sound contradictory to me. If the DSAs log does
not show /any/ connection from the IdP there simply might not be one.
Also the login page will always show up if the UsernamePassword
handler is active (and the RemoteUser one is not).

Impossible to say for me, of course, not knowing the DSA software and
its configuration (loggig, ACLs, etc.).

Ignoring the DSA (as I can't really help with that) lets concentrate
on getting your IdP logs going as described above.
-peter


------------------------------

Message: 4
Date: Fri, 5 Jul 2013 11:49:49 +0200
From: Peter Schober <peter.schober at univie.ac.at>
Subject: Re: browser refresh problem?
To: users at shibboleth.net
Message-ID: <20130705094949.GL16407 at aco.net>
Content-Type: text/plain; charset=us-ascii

* Ortner Nikolaus <N.Ortner at fh-kaernten.at> [2013-07-05 11:35]:
> > Is this intended? Is browser refresh not supported?
>
> I have no problem with a refresh (using a standard IdP-install,
> UsernamePasswordAuthHandler).

+1 (no problem)

-peter


------------------------------

Message: 5
Date: Fri, 5 Jul 2013 12:16:22 +0200
From: Peter Schober <peter.schober at univie.ac.at>
Subject: Re: disclosure of  IP address in cookie
To: users at shibboleth.net
Message-ID: <20130705101622.GM16407 at aco.net>
Content-Type: text/plain; charset=us-ascii

* Gruber Bernhard SAI sIT <Bernhard.Gruber at s-itsolutions.at> [2013-07-05 11:40]:
> During a security test of our shibboleth base solution, the
> following issue was reported to us:

This mailing list not the proper way to report (percieved) security issues:

  "If you [...] would like to report a potentially security sensitive
   issue with one of the products, please use the form below or send an
   email to contact at shibboleth.net.
   http://shibboleth.net/about/contact.html

> The iDP component discloses an internal IP address in the value of
> the _idp_lc_session cookie. The truncated and base64 decoded value
> of the cookie is as follows.

I can't find the string "_idp_lc_session" (or "_idp_lc_") in the IdP's
source code, so unless I'm looking at the wrong code (very well
possible) an unmodified IdP does not set a cookie with that name.

> 127.0.0.1|<sessionID>

IDP_SESSION_COOKIE_NAME (defaulting to "_idp_session") has a somewhat
similar format, and does include the HTTP User Agent's own IP address.

Personal note (IMHO): I somehow doubt an attacker needs that cookie
only to find out a client's IP address. S/he either attacks the client
or the network the client is on, in which case the client's IP address
will be apparent, or attacks the IdP (or the network the IdP is on),
where the client's IP address is known as well, without decoding HTTP
Cookie values.
Also note that that same IP address will be written into the
SubjectConfirmation/SubjectConfirmationData/@Address attribute in an
authentication assertion, which will be given out to relying parties.
-peter


------------------------------

Message: 6
Date: Fri, 5 Jul 2013 14:04:19 +0000
From: Gruber Bernhard SAI sIT <Bernhard.Gruber at s-itsolutions.at>
Subject: AW: browser refresh problem?
To: Shib Users <users at shibboleth.net>
Message-ID: <2A3EAA02A1991E40B836DE3BAEF7CAF24A8CD3DC at M0183.s-mxs.net>
Content-Type: text/plain; charset="iso-8859-1"

I see the difference beween the two login handler here:

UsernamePasswordLoginHandler does a redirect to the login servlet.
ExternalAuthnSystemLoginHandler does a server side forward to the login servlet.

With UsernamePasswordLoginHandler the browser shows the URL of the login servlet and the refresh goes to the login servlet.
With ExternalAuthnSystemLoginHandler the browser shows the URL of the AuthenticationEngine and the refresh goes to the AuthenticationEngine.
After the first submit to the login servlet (with wrong credential to stay on the page), the browser shows the URL of the login servlet and refresh is no longer a problem.

So I will have to change the login handler or add one redirect.


-----Urspr?ngliche Nachricht-----
Von: users-bounces at shibboleth.net [mailto:users-bounces at shibboleth.net] Im Auftrag von Ortner Nikolaus
Gesendet: Freitag, 05. Juli 2013 11:35
An: 'Shib Users'
Betreff: AW: browser refresh problem? [ccs][bayes][heur]

> Is this intended? Is browser refresh not supported?

I have no problem with a refresh (using a standard IdP-install, UsernamePasswordAuthHandler).

--
To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net


------------------------------

Message: 7
Date: Fri, 5 Jul 2013 14:57:43 +0000
From: Gilles Badouet <badouetg at uni.coventry.ac.uk>
Subject: logging.xml enabling
To: "users at shibboleth.net" <users at shibboleth.net>
Message-ID:
        <1939041E7E86BB4297EB69590F1F928F65F2F265 at AMSPRD0112MB561.eurprd01.prod.exchangelabs.com>

Content-Type: text/plain; charset="iso-8859-1"

I would like to get some logs for my LDAP JAAS configuration. enabled logging in logging.xml for the package edu.vt.middleware.ldap, but I dont see any edu.vt.middleware.ldap.Ldap line in my idp-process.log neither in other shibboleth log files. I enabled the logging by adding the following lines in looging.xml:

<logger name="edu.vt.middleware.ldap.jaas.JaasAuthenticator" level="DEBUG"/>
<logger name="edu.vt.middleware.ldap" level="WARN"/>

I want to see these logs to solve my login issue.





Kind regards





Gilles Rubens Badouet

Student ID: 3940347

Faculty of Engineering and Computing

MSc Network Computing Course

Mobile: 07424486426
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://shibboleth.net/pipermail/users/attachments/20130705/39d49a2f/attachment-0001.html

------------------------------

Message: 8
Date: Fri, 5 Jul 2013 11:00:21 -0400
From: Roger Jagoda <rberryj3 at gmail.com>
Subject: Re: Remote IdP not responding?
To: Shib Users <users at shibboleth.net>
Message-ID:
        <CAE6nv=FPsV7wsFnkMXTuvtF2WhOy_iFCTfwC4MHGN9xkTo7iDw at mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1

Scott,

Very solid analysis.


This exercise is just a test for a new client (with firewall issues, etc).
We are setting up just the barest SP for their test:


We have our entityID (under "ApplicationDefaults"):

<ApplicationDefaults
entityID="https://corpshibtest.ourcompany.com/Shibboleth.sso"
        REMOTE_USER="ShibTest" eppn persistent-id targeted-id">


We have their IdP SSO lines:

<SSO entityID="https://shibboleth.testdb.idp2.edu">
       SAML2 SAML1
</SSO>


The local metadata from the client (sent to us because of firewall
issues, physical file in the server's file tree):

   <MetadataProvider type="XML" file="/etc/shibboleth/testdb-idp2-metadata.xml"
backingFilePath="/var/cache/shibboleth/testdb-idp2-metadata.xml"
maxRefreshDelay="86400">
   </MetadataProvider>



Some logout info:

<!-- SAML and local-only logout. -->
<Logout>SAML2 Local</Logout>


The usual Attribute extractor:

<AttributeExtractor type="XML" validate="true" reloadChanges="false"
path="attribute-map.xml"/>


Our Sessions settings:

<Sessions lifetime="7200" timeout="3600" checkAddress="false"
relayState="ss:mem" handlerSSL="true" cookieProps="https">
</Sessions>

We do have these lines (they are in all our SPs):

        <!-- Use a SAML query if no attributes are supplied during SSO. -->
        <AttributeResolver type="Query" subjectMatch="true"/>

    <!-- Default filtering policy for recognized attributes, lets
other data pass. -->
        <AttributeFilter type="XML" validate="true"
path="attribute-policy.xml"/>

Could they be involved in our error?

</ApplicationDefaults>


That's it. We really thought this was going to be easy. We do this
with every new SP customer so we can trap out variables, work through
IdP problems, etc.
This should be no problem, but you have seen the errors. It's a
mystery here why it is not working. The only "oddity" is that the
metaprovider is from a local file (provided by the customer). It
should still work.

The latest try (with the native.log error) was with the vhost change
in the location block:

<Location /index.php.phpinfo>
   AuthType shibboleth
   ShibRequestSetting entityID https://sso.brown.edu/idp/shibboleth
   ShibRequireSession On
   require valid-user
   ShibUseHeaders On
</Location>


(in using that we commented out the SSO entityID from the IdP point,
(which is what you picked up on):

<!--
 <SSO entityID="https://shibboleth.testdb.idp2.edu">
       SAML2 SAML1
</SSO>
-->


In our other SPs, we will have to use the Location Block changes  as
we have the same service for many IdP sources.
But that's another thread.

We changed the above to another IdP (not supplied by local file but by
the actual <SSO> URL):


            <SSO entityID="https://shibboleth2.shidb.idp2.edu">
              SAML2 SAML1
            </SSO>

and everything works just fine.


Thoughts?


--RJ

====================================

Roger Jagoda
rberryj3 at gmail.com
==============================================


On Wed, Jul 3, 2013 at 6:40 PM, Cantor, Scott <cantor.2 at osu.edu> wrote:
>> This is the error (from native.log):
>>
>> 2013-07-03 16:55:24 ERROR Shibboleth.Apache [2092] shib_check_user: No
>> default session initiator found, check configuration.
>>
>> I  know we're on the right track. Do we need to quote the
>> ShibRequestSetting arguments?
>
> No, you've mangled something in the default configuration. Just undo what you changed. You need a <SSO> element, and that's it. You've apparently removed it, and replaced it with, I guess, nothing. Otherwise I can't think how you could end up with *no* session initiator installed.
>
> I still have no clear picture what your original issue is/was. It's never been clear whether you have multiple idPs here or not. If not, then you shouldn't need to do anything special. If you do, then indeed Chris' suggestion applies, to set the IdP based on resource URL. That is not an issue unless that's the problem you need to solve.
>
> -- Scott
>
>
> --
> 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

End of users Digest, Vol 25, Issue 27
*************************************




------------------------------

--
To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net

End of users Digest, Vol 25, Issue 28
*************************************




More information about the users mailing list