Need to integrate Shibboleth SP
Amit Thukral
amit.thukral403 at gmail.com
Mon Jul 29 07:37:16 EDT 2013
Hi Scott,
There were few missing links while I had communicated the my product design
to you last time.
The .so which I am adding will be part of the a module (e.g. webauth) of
our so called web-server.
shibd is up and running fine on the same box.
Current Problem:
==============
Our webserver and most of its code is written in C.
For building shibboleth-sp, I have written a wrapper with "extern" (for
c++) to call it from webauth module.
While I am trying to call shib_child_init for initializing the client
portion of shibboleth library, but it is crashing at following location
inside *"instantiate"*.
However, when I ran the same code for initializing the library
independently from a separate program, the initialization happens fine.
The differences are:
1) the independent program is built using g++, and linked to
*libshibsp.so*whereas for our module we are using gcc along with
libstdc++.
2) the independent program is linked to *libshibsp.so* whereas webserver
program binary is linked to the wrapper* lib**my**shibsp.so *+ other
shibboleth libraries.
3) ldd portion of webserver binary shows two differenct versions of
libstdc++.so whereas the working independent binary shows only
libstdc++.so.6
[root at 105] # ldd webauthbin | grep libstdc++*
libstdc++.so.6 => /home/product/code/firmware/current/lib64/libstdc++.so.6
(0x00007f66f631d000)
libstdc++.so.5 => /usr/lib64/libstdc++.so.5 (0x00007f66f4fee000)
[root at 105] # ldd a.out | grep libstdc++*
libstdc++.so.6 => /home/product/code/firmware/current/lib64/libstdc++.so.6
(0x00007f53da8f0000)
Could this libstdc++.so be a problem for the follwoing crash ? if no, then,
what else could be ?
Despite of spending good amount of time in debugging, I am unable to find
the solution for the same, thus asking you.
shib_child_init portion
================
bool shib_child_init()
{
g_Config=&SPConfig::getConfig();
g_Config->setFeatures(
SPConfig::Listener |
SPConfig::Caching |
SPConfig::RequestMapping |
SPConfig::InProcess |
SPConfig::Logging |
SPConfig::Handlers
);
if (!g_Config->init(g_szSchemaDir, g_szPrefix)) { }
try {
if (!*g_Config->instantiate(g_szSHIBConfig, true)*)
throw runtime_error("unknown error");
}
catch (std::exception& ex) { }
}
Crash:
=====
In function PMemLowWaterMarkInit ...
*** glibc detected *** /mail/data/product/code/firmware/7.8.0.010/bin64/stm:
*munmap_chunk()*: invalid pointer: 0x00007f4bcc1a8478 ***
======= Backtrace: =========
/lib64/libc.so.6[0x7f4bda59b1b8]
/home/product/code/firmware/current/lib64/libstdc++.so.6(_ZNSsD1Ev+0x3d)[0x7f4bd7ced53d]
/home/bws/code/firmware/current/lib64/liblog4shib.so.1(_ZN8log4shib24PropertyConfiguratorImpl17configureCategoryERKSs+0x8d7)[0x7f4bd40b272d]
/home/bws/code/firmware/current/lib64/liblog4shib.so.1(_ZN8log4shib24PropertyConfiguratorImpl11doConfigureERSi+0x74)[0x7f4bd40b390e]
/home/bws/code/firmware/current/lib64/liblog4shib.so.1(_ZN8log4shib24PropertyConfiguratorImpl11doConfigureERKSs+0x32c)[0x7f4bd40b1dd0]
/home/bws/code/firmware/current/lib64/liblog4shib.so.1(_ZN8log4shib20PropertyConfigurator9configureERKSs+0x2e)[0x7f4bd40aef70]
/home/bws/code/firmware/current/lib64/libxmltooling.so.6(_ZN10xmltooling24XMLToolingInternalConfig10log_configEPKc+0x31f)[0x7f4bd4d67bef]
/home/bws/code/firmware/current/lib64/libshibsp.so.6[0x7f4bd60f0bf9]
/home/bws/code/firmware/current/lib64/libshibsp.so.6[0x7f4bd60f3542]
/home/bws/code/firmware/current/lib64/libshibsp.so.6[0x7f4bd60d87cc]
....
(gdb) bt
#0 0x00007f4bda55929b in raise () from /lib64/libc.so.6
#1 0x00007f4bda55a7f3 in abort () from /lib64/libc.so.6
#2 0x00007f4bda595c28 in __libc_message () from /lib64/libc.so.6
#3 0x00007f4bda59b1b8 in malloc_printerr () from /lib64/libc.so.6
#4 0x00007f4bd7ced53d in std::basic_string<char, std::char_traits<char>,
std::allocator<char> >::~basic_string ()
from /home/product/code/firmware/current/lib64/libstdc++.so.6
#5 0x00007f4bd40b272d in
log4shib::PropertyConfiguratorImpl::configureCategory (this=0x7fff321c44b0,
categoryName=@0x7f4bcc053d18)
at PropertyConfiguratorImpl.cpp:171
#6 0x00007f4bd40b390e in log4shib::PropertyConfiguratorImpl::doConfigure
(this=0x7fff321c44b0, in=@0x7fff321c4230)
at PropertyConfiguratorImpl.cpp:88
#7 0x00007f4bd40b1dd0 in log4shib::PropertyConfiguratorImpl::doConfigure
(this=0x7fff321c44b0, initFileName=@0x7fff321c4560)
at PropertyConfiguratorImpl.cpp:72
#8 0x00007f4bd40aef70 in log4shib::PropertyConfigurator::configure
(initFileName=@0x7fff321c4560) at PropertyConfigurator.cpp:17
#9 0x00007f4bd4d67bef in xmltooling::XMLToolingInternalConfig::log_config
(this=0x7f4bd514b500, config=0x7f4bcc07bf28 "native.logger")
at XMLToolingConfig.cpp:350
#10 0x00007f4bd60f0bf9 in XMLConfigImpl (this=0x7f4bcc301620,
e=0x7f4bcc0784b0, first=true, outer=0x7f4bcc0608c0, log=@0x7f4bcc0010c0)
at impl/XMLServiceProvider.cpp:2009
#11 0x00007f4bd60f3542 in background_load (this=0x7f4bcc0608c0) at
impl/XMLServiceProvider.cpp:2371
#12 0x00007f4bd60d87cc in init (this=0x7f4bcc0608c0) at
impl/XMLServiceProvider.cpp:341
#13 0x00007f4bd5fe2d62 in shibsp::SPConfig::instantiate
(this=0x7f4bd64dff60, config=0x7f4bd61d1430 "shibboleth2.xml", rethrow=true)
at SPConfig.cpp:447
#14 0x00007f4bd8a88668 in shib_child_init () at wafsp.cpp:265
#15 0x000000000041669b in AppStart (argc=4, argv=0x7fff321c5208,
ExtraOptionHandler=0, extraOpts=0x0) at ncappmain.c:421
#16 0x000000000040abeb in main (argc=4, argv=0x7fff321c5208) at
cachesysinit.c:94
Thanks a lot in advance for your support.
Regards,
Amit Thukral
On Wed, Jul 10, 2013 at 6:46 AM, Cantor, Scott <cantor.2 at osu.edu> wrote:
> On 7/9/13 9:24 AM, "Amit Thukral" <amit.thukral403 at gmail.com> wrote:
>
> >[athukral]: I have a configuration layer already implemented which is
> >specific to our product so thats why i did not provide those details
> >here. The "shib_check_user" function
> > is part of a .so which is linked to our process "stm" which has the
> >configuration layer already in it.
>
> If you want to use the SP you have to be subordinate to it. The Apache
> module isn't something that acts independently and then sends messages to
> shibd to do a subset of things.
>
> Rather, the module is subordinate to the SP as a whole and the core of the
> system is the ServiceProvider class in libshibsp which runs various
> actions against a request that supports the SPRequest interface. The job
> of the module is to get the shibsp library started up with its
> configuration and then expose the Apache internals via the SPRequest
> interface when requests come into Apache.
>
> Then it is meant to call the relevant ServiceProvider::doXXX methods at
> appropriate times.
>
> You can have all the separate configuration you want but you still must
> instantiate the SP configuration object as part of your configuration
> activity. The Apache module does that in various ways due to Apache
> version differences, but Apache provides hooks for that to happen at the
> right times, and anything else must also, or it won't fit well.
>
> > I went through an apache tutorial on "adding a module to apache" and
> >understood what you meant by configuration layer.
> > I understood that this configuration is specific to what directory is
> >being accessed and what rules etc. should be governing the various
> >operations etc.
>
> That's only part of the picture, other settings are global and influence
> how the library runtime is configured, such as overriding the config file
> path.
>
> > I have all that configuration information which is passed on from my
> >device but I don't know the order in which I should call the shibboleth
> >APIs etc.
> > to make the basic startup happen.
>
> The Apache or IIS modules illustrate how that happens.
>
> > Similarly, I did not know what all configuration I really needed from
> >shibboleth2.xml for basic startup.
> >Since, apache doesn't need some of them to come from shibboleth2.xml
> >so I completely missed them on my another reference setup. Some of them
> >apache picks up from httpd.conf.
>
> That's a special feature that is best ignored in the initial stage of
> getting something working. All of the configuration of how requests get
> handled can be left to the RequestMap. Later, it may be possible to
> enhance things by building something more advanced that can link local
> commands that control content rules to the RequestMap interface. That's
> what's inside the Apache module.
>
> The SP requires that all of that information be exposed through the
> RequestMap API. You cannot provide the information in any other way. Even
> the Apache commands work that way.
>
> > 1) <RequestMapper> - to map various requests to various application-ids.
>
> Not just application-ids. Every property associated with a request.
>
> > 2) <InProcess> for starting up the native logger and if any .so to be
> >loaded dynamically.
> >Is there anything else apart from above that I would need to provide in
> ><SPConfig> to make basic startup work ?
>
> You can't pick and choose. You need to instantiate the entire SP runtime,
> you don't process individual sections of the file.
>
> >3) have not implemented anything similar to ApacheRequestMapper class.
>
> That's optional (and see above, I wouldn't worry about it initially). But
> you cannot make your native content configuration work with the SP unless
> you bridge to it through that kind of class.
>
> > what functions I should be calling to process the incoming request ?
>
> First you need to ensure that the incoming request is wrapped in something
> that implements SPRequest by subclassing AbstractSPRequest and adding the
> custom code needed.
>
> Then you have to call doAuthentication, doExport, doAuthorization, and
> doHandler in appropriate places, the latter being the way requests to the
> /Shibboleth.sso virtual URLs are dispatched.
>
> You can see all of those being called in the Apache module in particular
> Apache hooks.
>
> The doAuthentication/doExport methods are the core work done for each
> request in the check_user hook. The doAuthorization method allows the SP's
> pluggable access control layer to run in the Apache check_access hook.
>
> >[athukral]: I am going through mod_shib.cpp and i believe whatever is
> >being done regarding session/user mgmt etc. is already done in my WAF's
> >configuration layer and I can handle those things there.
>
> The SP doesn't function without doing its own session management, that's
> what most of its code is for. If I could have used an existing session,
> the code would look nothing like it does now.
>
> >In above sentence by "different
> >API" do you mean the API other than Apache, Adfs, IIS etc. for which the
> >supported code is already there ?
>
> I mean whatever proprietary API your web server uses to support modules.
>
> The modules don't do anything fundamental except handle startup/shutdown,
> shim a custom API into the SPRequest interface, and then invoke the
> ServiceProvider doXXX methods at appropriate points in the request flow.
>
> The IIS module is much shorter than the Apache module because the Apache
> module adds two major pieces of work:
>
> - supporting Apache commands via the RequestMap API
> - authorization
>
> But those are optional additions to the basic requirements.
>
> -- Scott
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://shibboleth.net/pipermail/dev/attachments/20130729/70de029b/attachment.html
More information about the dev
mailing list