[fcrepo-user] problem adding datastreams after moving data from one filesystem to another

[Scott Prater]

We encountered a worrisome problem today after filling up a filesystem and being forced to move our data to another filesystem. After the move and rebuild, we can no longer add datastreams to objects.

I'm running Fedora 3.4, with the default Akubra low-level storage module.

Here's what happened:

1. filesystem /fedora/data filled up, Fedora (and Tomcat) hung.
2. I shut down Fedora, Tomcat, Postgres.
3. I moved the directory /fedora/data/objects to another filesystem, /fedora/db01/objects.
4. I moved the directory /fedora/data/datastreams to another filesystem, /fedora/db01/datastreams.
5. I made symlinks from the original locations to the new locations:
/fedora/data/objects -> /fedora/db01/objects
/fedora/data/datastreams -> /fedora/db01/datastreams
6. I started up Postgres, and ran fedora-rebuild.sh twice, once to rebuild the database and once to rebuild the resource index. The rebuild completed successfully.
7. I then started up Tomcat + Fedora, and I was able to view all the objects.
8. I then did a test ingest of an object, and a stub object was successfully created, with a DC datastream. I verified that I could find the object and the datastream on the filesystem (both through the direct path and through the symlinked path). I verified that permsissions were correct at every directory level, and at the file level.

I then try to add a datastream to the test object, and I receive this error (truncated):

ERROR 2010-10-05 14:51:16.424 [http-9090-1] (WebApplicationImpl) Internal server error
javax.ws.rs.WebApplicationException: org.fcrepo.server.errors.GeneralException: Unable to add or modify object (commit canceled)
[...]
Caused by: java.io.IOException: Rename failed for an unknown reason.
at org.akubraproject.fs.FSBlob.moveTo(FSBlob.java:151) [akubra-fs-0.3.jar:na]

I've tested this with the REST API, through the web admin interface, and through the java GUI admin tool, and the results are the same in all three cases. This error occurs regardless of whether I'm adding a datastream to a newly-created object or attempting to add a datastream to an older object.

This may properly be an Akubra matter, but I thought I would bring it up here, first. Any suggestions or help would be greatly appreciated.

thanks,

-- Scott

Following is the full stack trace:

ERROR 2010-10-05 14:51:16.424 [http-9090-1] (WebApplicationImpl) Internal server error
javax.ws.rs.WebApplicationException: org.fcrepo.server.errors.GeneralException: Unable to add or modify object (commit canceled)
at org.fcrepo.server.rest.BaseRestResource.handleException(BaseRestResource.java:168) [fcrepo-server-3.4.jar:na]
at org.fcrepo.server.rest.DatastreamResource.addOrUpdateDatastream(DatastreamResource.java:583) [fcrepo-server-3.4.jar:na]
at org.fcrepo.server.rest.DatastreamResource.addDatastream(DatastreamResource.java:358) [fcrepo-server-3.4.jar:na]
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [na:1.6.0_21]
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) [na:1.6.0_21]
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) [na:1.6.0_21]
at java.lang.reflect.Method.invoke(Method.java:597) [na:1.6.0_21]
at com.sun.jersey.server.impl.model.method.dispatch.AbstractResourceMethodDispatchProvider$ResponseOutInvoker._dispatch(AbstractResourceMethodDispatchProvider.java:175) [jersey-bundle-1.0.3.1.jar:1.0.3.1]
at com.sun.jersey.server.impl.model.method.dispatch.ResourceJavaMethodDispatcher.dispatch(ResourceJavaMethodDispatcher.java:67) [jersey-bundle-1.0.3.1.jar:1.0.3.1]
at com.sun.jersey.server.impl.uri.rules.HttpMethodRule.accept(HttpMethodRule.java:163) [jersey-bundle-1.0.3.1.jar:1.0.3.1]
at com.sun.jersey.server.impl.uri.rules.RightHandPathRule.accept(RightHandPathRule.java:111) [jersey-bundle-1.0.3.1.jar:1.0.3.1]
at com.sun.jersey.server.impl.uri.rules.ResourceClassRule.accept(ResourceClassRule.java:71) [jersey-bundle-1.0.3.1.jar:1.0.3.1]
at com.sun.jersey.server.impl.uri.rules.RightHandPathRule.accept(RightHandPathRule.java:111) [jersey-bundle-1.0.3.1.jar:1.0.3.1]
at com.sun.jersey.server.impl.uri.rules.RootResourceClassesRule.accept(RootResourceClassesRule.java:63) [jersey-bundle-1.0.3.1.jar:1.0.3.1]
at com.sun.jersey.server.impl.application.WebApplicationImpl._handleRequest(WebApplicationImpl.java:689) [jersey-bundle-1.0.3.1.jar:1.0.3.1]
at com.sun.jersey.server.impl.application.WebApplicationImpl.handleRequest(WebApplicationImpl.java:647) [jersey-bundle-1.0.3.1.jar:1.0.3.1]
at com.sun.jersey.server.impl.application.WebApplicationImpl.handleRequest(WebApplicationImpl.java:638) [jersey-bundle-1.0.3.1.jar:1.0.3.1]
at com.sun.jersey.spi.container.servlet.WebComponent.service(WebComponent.java:309) [jersey-bundle-1.0.3.1.jar:1.0.3.1]
at com.sun.jersey.spi.container.servlet.ServletContainer.service(ServletContainer.java:425) [jersey-bundle-1.0.3.1.jar:1.0.3.1]
at com.sun.jersey.spi.container.servlet.ServletContainer.service(ServletContainer.java:590) [jersey-bundle-1.0.3.1.jar:1.0.3.1]
at javax.servlet.http.HttpServlet.service(HttpServlet.java:717) [servlet-api.jar:na]
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290) [catalina.jar:6.0.29]
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) [catalina.jar:6.0.29]
at org.fcrepo.server.security.servletfilters.FilterRestApiFlash.doFilter(FilterRestApiFlash.java:66) [fcrepo-server-3.4.jar:na]
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235) [catalina.jar:6.0.29]
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) [catalina.jar:6.0.29]
at org.fcrepo.server.security.servletfilters.FilterSetup.doFilter(FilterSetup.java:235) [fcrepo-server-3.4.jar:na]
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235) [catalina.jar:6.0.29]
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) [catalina.jar:6.0.29]
at org.fcrepo.server.security.servletfilters.FilterSetup.doFilter(FilterSetup.java:235) [fcrepo-server-3.4.jar:na]
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235) [catalina.jar:6.0.29]
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) [catalina.jar:6.0.29]
at org.fcrepo.server.security.servletfilters.FilterSetup.doFilter(FilterSetup.java:235) [fcrepo-server-3.4.jar:na]
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235) [catalina.jar:6.0.29]
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) [catalina.jar:6.0.29]
at org.fcrepo.server.security.servletfilters.FilterSetup.doFilter(FilterSetup.java:235) [fcrepo-server-3.4.jar:na]
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235) [catalina.jar:6.0.29]
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) [catalina.jar:6.0.29]
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233) [catalina.jar:6.0.29]
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191) [catalina.jar:6.0.29]
at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:563) [catalina.jar:6.0.29]
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127) [catalina.jar:6.0.29]
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) [catalina.jar:6.0.29]
at org.apache.catalina.valves.RequestFilterValve.process(RequestFilterValve.java:269) [catalina.jar:6.0.29]
at org.apache.catalina.valves.RemoteAddrValve.invoke(RemoteAddrValve.java:81) [catalina.jar:6.0.29]
at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:555) [catalina.jar:6.0.29]
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) [catalina.jar:6.0.29]
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:298) [catalina.jar:6.0.29]
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:857) [tomcat-coyote.jar:6.0.29]
at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:588) [tomcat-coyote.jar:6.0.29]
at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:489) [tomcat-coyote.jar:6.0.29]
at java.lang.Thread.run(Thread.java:619) [na:1.6.0_21]
Caused by: org.fcrepo.server.errors.GeneralException: Unable to add or modify object (commit canceled)
at org.fcrepo.server.storage.DefaultDOManager.doCommit(DefaultDOManager.java:1438) [fcrepo-server-3.4.jar:na]
at org.fcrepo.server.storage.SimpleDOWriter.commit(SimpleDOWriter.java:508) [fcrepo-server-3.4.jar:na]
at org.fcrepo.server.management.DefaultManagement.addDatastream(DefaultManagement.java:572) [fcrepo-server-3.4.jar:na]
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [na:1.6.0_21]
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) [na:1.6.0_21]
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) [na:1.6.0_21]
at java.lang.reflect.Method.invoke(Method.java:597) [na:1.6.0_21]
at org.fcrepo.server.messaging.NotificationInvocationHandler.invoke(NotificationInvocationHandler.java:68) [fcrepo-server-3.4.jar:na]
at $Proxy0.addDatastream(Unknown Source) [na:na]
at org.fcrepo.server.management.ManagementModule.addDatastream(ManagementModule.java:227) [fcrepo-server-3.4.jar:na]
at org.fcrepo.server.rest.DatastreamResource.addOrUpdateDatastream(DatastreamResource.java:467) [fcrepo-server-3.4.jar:na]
... 50 common frames omitted
Caused by: org.fcrepo.common.FaultException: java.io.IOException: Rename failed for an unknown reason.
at org.fcrepo.server.storage.lowlevel.akubra.AkubraLowlevelStorage.rename(AkubraLowlevelStorage.java:363) [fcrepo-server-3.4.jar:na]
at org.fcrepo.server.storage.lowlevel.akubra.AkubraLowlevelStorage.safeOverwrite(AkubraLowlevelStorage.java:306) [fcrepo-server-3.4.jar:na]
at org.fcrepo.server.storage.lowlevel.akubra.AkubraLowlevelStorage.replace(AkubraLowlevelStorage.java:244) [fcrepo-server-3.4.jar:na]
at org.fcrepo.server.storage.lowlevel.akubra.AkubraLowlevelStorage.replaceObject(AkubraLowlevelStorage.java:150) [fcrepo-server-3.4.jar:na]
at org.fcrepo.server.storage.lowlevel.akubra.AkubraLowlevelStorageModule.replaceObject(AkubraLowlevelStorageModule.java:79) [fcrepo-server-3.4.jar:na]
at org.fcrepo.server.storage.DefaultDOManager.doCommit(DefaultDOManager.java:1334) [fcrepo-server-3.4.jar:na]
... 60 common frames omitted
Caused by: java.io.IOException: Rename failed for an unknown reason.
at org.akubraproject.fs.FSBlob.moveTo(FSBlob.java:151) [akubra-fs-0.3.jar:na]
at org.akubraproject.map.IdMappingBlob.moveTo(IdMappingBlob.java:69) [akubra-map-0.3.jar:na]
at org.fcrepo.server.storage.lowlevel.akubra.AkubraLowlevelStorage.rename(AkubraLowlevelStorage.java:361) [fcrepo-server-3.4.jar:na]
... 65 common frames omitted
--
Scott Prater
Library, Instructional, and Research Applications (LIRA)
Division of Information Technology (DoIT)
University of Wisconsin - Madison
pra...@wisc.edu

[Scott Prater]

Another item of information: Ingesting FOXML files works without a problem, induicating that this may be a problem with the copy/replace functionality?

Also, I simplified the process somewhat: really, the new data is spread across three different filesystems, with the symlinks occuring at the top-level hash character directories:

/fedora/data/objects/0 -> /fedora/db01/objects/0
/fedora/data/objects/1 -> /fedora/db02/objects/1
etc.

I mention this, as it occurs to me that perhaps Akubra, as part of its safe move/rename function, is attempting to create temporary hard links across filesystems? Just a guess...

-- Scott

[Scott Prater]

I think I may have found the source of the problem.

In org.akubraproject.fs.FSBlob, this is what happens when an object gets moved:

if (!file.renameTo(other)) {
if (!file.exists())
throw new MissingBlobException(getId());

throw new IOException("Rename failed for an unknown reason.");
}

file.renameTo() is a java.io.File method that may or may not move files across symlinks and filesystems, depending on your platform (I'm running Solaris 10, so go figure):

http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4073756

Googling turns up a rich history of problems with the java.io.File renameTo() method when other filesystems and symlinks are involved. Best practice these days seems to be to use java.nio.file instead:

http://download.oracle.com/javase/tutorial/essential/io/legacy.html

Chris: shall I open to a bug report in the Akubra JIRA issue tracker?

[Chris Wilper]

Hi Scott,

Good find. Yes, please submit it to the Akubra tracker. It appears
that java.nio.file.Path is a Java 1.7+ class, so it doesn't look like
we can use it, but I'm sure we can muster up a suitable 1.6-compatible
workaround.

- Chris

> ------------------------------------------------------------------------------
> Beautiful is writing same markup. Internet Explorer 9 supports
> standards for HTML5, CSS3, SVG 1.1,  ECMAScript5, and DOM L2 & L3.
> Spend less time writing and  rewriting code and more time creating great
> experiences on the web. Be a part of the beta today.
> http://p.sf.net/sfu/beautyoftheweb
> _______________________________________________
> Fedora-commons-users mailing list
> Fedora-com...@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/fedora-commons-users
>

[Scott Prater]

Hi, Chris --

Yes, I had hoped that I could find the java.nio.file package for Java
1.6, but no such luck.

I did download the latest Akubra from trunk, and I made some
modifications to FSBlob to implement a fairly failsafe copy-and-delete
function within moveTo(), which I'm now testing. I do have a few
developer administrivia questions for you, which I'll ask offline.

thanks,

-- Scott

[Scott Prater]

I opened an issue in the Akubra issue tracking system:

https://jira.duraspace.org/browse/AKUBRA-1

Issue number 1 :)

[Scott Prater]

The topic of using Shibboleth for authentication and XACML for authorization has heated up again in our organization.

Here is our ideal scenario:

* Authentication with Shibboleth, Shibboleth attributes made available for use in Fedora XACML policies: made possible by servlet filters developed at other institutions

* XACML policies stored as Fedora objects, inheritable rules, indexed in the resource index, cached:  made possible by FeSL

However, it appears that if FeSL is enabled (necessary to get the new and improved version of the XACML implementation), then FeSL JAAS is also enabled, and so the Shibboleth authentication piece will be disabled or bypassed (right?).

We'd like to have our cake and eat it, too, ideally without having to wrestle with developing a JAAS Shibboleth plugin.  Is there a way to separate FeSL authentication from FeSL authorization, enable the latter, but not the former? Thoughts? 

Some background reading:

https://jira.duraspace.org/browse/FCREPO-577
https://wiki.duraspace.org/display/FCR30/Fedora+Security+Layer+%28FeSL%29

thanks in advance,

-- Scott

[Chris Wilper]

Hi Scott,

Actually FeSL AuthN and AuthZ are now separate options at
install-time, so enabling one shouldn't force you to use the other. If
you find that's happening, it's a bug that needs to be
addressed...it's certainly not intentional. But the first release we
did with FeSL included did force them to both either be on or off, so
that may be a source of confusion if you're using an older version.

Also, I'm not sure if you're aware of this, but Adam Soroka has been
putting together a non-FeSL servlet filter that allows Shib
integration. I believe he's planning on having something available for
others to check out sometime after the 3.5 release.

- Chris

> ------------------------------------------------------------------------------
> Enable your software for Intel(R) Active Management Technology to meet the
> growing manageability and security demands of your customers. Businesses
> are taking advantage of Intel(R) vPro (TM) technology - will your software
> be a part of the solution? Download the Intel(R) Manageability Checker
> today! http://p.sf.net/sfu/intel-dev2devmar

[Scott Prater]

Thanks, Chris.  That improvement to allow separate enabling of AuthN and AuthZ had slipped under my radar.  I'll give that a try (I'm currently running Fedora 3.4.2).  I'll also update the wiki documentation.

Concerning Adam's work: in fact, my question was prompted by a side conversation I've recently had with Adam on that very topic.  We hope to be early adopters/beta testers of his servlet filter.

I'll report back here on my experiments.

-- Scott

On 03/22/11, Chris Wilper wrote:
> Hi Scott,
>
> Actually FeSL AuthN and AuthZ are now separate options at
> install-time, so enabling one shouldn't force you to use the other. If
> you find that's happening, it's a bug that needs to be
> addressed...it's certainly not intentional. But the first release we
> did with FeSL included did force them to both either be on or off, so
> that may be a source of confusion if you're using an older version.
>
> Also, I'm not sure if you're aware of this, but Adam Soroka has been
> putting together a non-FeSL servlet filter that allows Shib
> integration. I believe he's planning on having something available for
> others to check out sometime after the 3.5 release.
>
> - Chris
>
> On Tue, Mar 22, 2011 at 10:32 AM, Scott Prater <pra...@wisc.edu> wrote:

> > ------------------------------------------------------------------------------
> > Enable your software for Intel(R) Active Management Technology to meet the
> > growing manageability and security demands of your customers. Businesses
> > are taking advantage of Intel(R) vPro (TM) technology - will your software
> > be a part of the solution? Download the Intel(R) Manageability Checker
> > today! http://p.sf.net/sfu/intel-dev2devmar
> > _______________________________________________
> > Fedora-commons-users mailing list
> > Fedora-com...@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/fedora-commons-users
> >

--

[fe...@fedora-commons.org]

It may be useful for me to mention here that Swithun Crowe of St. Andrews, Scott and myself will be taking a look at the servlet filter question in the next few weeks and hopefully will have something concrete to bring back o he community at some point not long after that.

---
A. Soroka
Online Library Environment
the University of Virginia Library

[Swithun Crowe]

Hello

I have Adam's non-FeSL SSO servlet filter working with XACML. But now that
it is working, I'd like to break things again.

At my institution, Shibboleth protected pages will redirect you to a login
page, and upon successful authentication, send you back to the protected
page. If Shibboleth is the only method of authentication and a required
method, then this is fine for interacting with Fedora using a modern web
browser.

But there are a few instances where this won't work well. The command line
client utilities won't be able to authenticate you, as, with SSO, Fedora
doesn't have access to your credentials.

A work around here is to use a different host name when running the client
utilities, e.g. localhost instead of the more qualified name that the SSO
knows about.

Another example is that of chaining SSO authentication with the other
methods found in FeSL (user file, LDAP etc.). FeSL takes your credentials,
and then uses the methods specified in jaas.conf. Shibboleth requires that
you visit a special page where you enter your credentials. I'm not sure
whether it is possible for Fedora to take your username/password and
conduct the SSO authentication behind the scenes, and if successful,
replicate the HTTP headers and cookies, so that you stay signed on.

Looking at the authenticate method in AuthFilterJAAS.java, an
authenticated subject is found in the session by using the value of the
authorization HTTP header, which contains the username and password of the
subject. So, even if you have authenticated using SSO, FeSL won't know
this, and will ask you to authenticate again.

The filters should work independently of each other. But they should have
some common way of recognising is you are logged in or not. And maybe they
should have a common means of obtaining user credentials.

I don't have any answers or suggestions yet. Maybe someone else does.

Swithun.

--
The University of St Andrews is a charity registered in Scotland: SC013532

[Scott Prater]

Hi, Swithun --

On 04/04/2011 04:59 AM, Swithun Crowe wrote:

> Another example is that of chaining SSO authentication with the other
> methods found in FeSL (user file, LDAP etc.). FeSL takes your credentials,
> and then uses the methods specified in jaas.conf. Shibboleth requires that
> you visit a special page where you enter your credentials. I'm not sure
> whether it is possible for Fedora to take your username/password and
> conduct the SSO authentication behind the scenes, and if successful,
> replicate the HTTP headers and cookies, so that you stay signed on.

Part of the goal of SSO systems like PubCookie and Shibboleth is to
minimize traffic of credentials in requests: a user goes to a
third-party host and enters their credentials there, with the
communication between the browser and the authentication host encrypted
over HTTPS. Once they authenticate, they receive a ticket in a cookie,
and/or some HTTP headers, that applications can be configured to
recognize and use to make authorization decisions. This way,
applications never need to know the user's credentials; they just need
to know where to forward the user to get authenticated, and they need to
know what to look for in the returning user's request to determine if
they've been authenticated, and make a decision about their level of
authorization. Both Pubcookie and Shibboleth rely on the HTTP protocol,
and the browser's ability to redirect a user from one host to another,
to control this triangular transaction (user, authentication host, and
destination web application).

A filter could be written to somehow get user credentials from Fedora
and forward them, but that would break the whole point of the SSO model
-- remove handling of credentials from the destination applications.
This same problem exists for Subversion, and other command-line
applications: there's no way to redirect the user from one host to
another and back again at the command line, the only workaround is to
fake a user HTTP transaction on the web application host, which means
the web application has to solicit the credentials from the user -- a
big no-no. I think that's why you haven't seen any shibboleth+svn
command line plugins, although it's clearly desired.

I think your suggestion of chained authentication methods and filters
would be the way to go. The two most common ways of interacting with
Fedora are through a web interface (which can be protected by
Shibboleth) and at the command line, which could be protected by an Xml
user file, an ldap server, or any other credential store that's
available locally and configurable in JAAS. Command line access is
generally for management and administration, and as such, would usually
be restricted to a small number of users; web access is more typical of
the world at large, and lends itself better to SSO.

I'm sure there are use cases that can turn the above scenarios on their
head, but I wonder how common they are; and if they are compelling
enough to deliberately break the SSO security model.

-- Scott

--
Scott Prater
Library, Instructional, and Research Applications (LIRA)
Division of Information Technology (DoIT)
University of Wisconsin - Madison

pra...@wisc.edu

[Swithun Crowe]

Hello

SP> I think your suggestion of chained authentication methods and filters
SP> would be the way to go. The two most common ways of interacting with
SP> Fedora are through a web interface (which can be protected by
SP> Shibboleth) and at the command line, which could be protected by an Xml
SP> user file, an ldap server, or any other credential store that's
SP> available locally and configurable in JAAS. Command line access is
SP> generally for management and administration, and as such, would usually
SP> be restricted to a small number of users; web access is more typical of
SP> the world at large, and lends itself better to SSO.

Thanks for the explanation. The lack of SSO support in command line
applications should have been an indication that it wasn't widely
considered to be a good idea. That said, there is a (Shibboleth only) SSO
client library:

https://wiki.shibboleth.net/confluence/display/SHIB2/ECP

I discovered afterwards that it is possible to make SSO optional, which
took away most of my worries.

[Scott Prater]

On 04/05/2011 11:33 AM, Swithun Crowe wrote:

> Thanks for the explanation. The lack of SSO support in command line
> applications should have been an indication that it wasn't widely
> considered to be a good idea. That said, there is a (Shibboleth only) SSO
> client library:
>
> https://wiki.shibboleth.net/confluence/display/SHIB2/ECP
>

That's interesting link, I hadn't seen that before -- thanks! Looks
like it does what you proposed -- basically implement the SAML/HTTP
transactions natively within applications. Judging by the notes to
implementers, that would not be a trivial project to undertake.