Skip to Content.
Sympa Menu

shibboleth-dev - Re: [Shib-Dev] Authentication using Shibboleth to an stand alone application.

Subject: Shibboleth Developers

List archive

Re: [Shib-Dev] Authentication using Shibboleth to an stand alone application.


Chronological Thread 
  • From: Caio Honda <>
  • To:
  • Subject: Re: [Shib-Dev] Authentication using Shibboleth to an stand alone application.
  • Date: Wed, 2 Dec 2009 14:18:33 -0300
  • Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=eF0LuYyjBEcu1E7zAFFbAPk0gFY6VdBFiLrx2XVBvukUnJoCDWJh0YjWm5lH4fTwFl HpmSsiMSKvUwRrLbhouSeP4iM06YkmQ1dKfjbXOpazNfDgidcWMhuliknh6BidAz5Fny T1tBCqnm0vyBknT1HCE8nvYVHsHxeUXI7uNMU=

Hi,

To be more specific the client is a Java application for desktop.
This application needs to get the credentials of the User, and then try to access a service that is protected (protected by another
application called Authentication Service-AS). This is currently done through the SASL protocol, where the client JAVA accesses Online services called CA Online (CA eduGAIN SASL online) and obtain the User credentials and a certificate of short duration. The problem is that for every institution in my federation I'll have to have a SASL CA installed. I intend to make the client get a JAVA
SAML Assertion of Shibboleth and can use the AS.

In the site  (https://wiki.man.poznan.pl/perfsonar-mdm/index.php/Authentication_Service_resources)
there's an explanation of the possible scenaries, where im trying to merge both scenaries User Behind a Client e Client in Web containEr.

On Tue, Dec 1, 2009 at 4:10 PM, Scott Cantor <> wrote:
Caio Honda wrote on 2009-12-01:
> Hi,
> Im new on the group, my name is Caio, student of Computer Science and
making
> Scientific initiations, and one of my goals is to make an application
stand
> alone authenticate using Shibboleth.

As usual with this question, you have specified neither what the client
really is here or more importantly what the service you want to authenticate
to is. Because if it's not a web site you have the fundamental problem of
defining how SAML even addresses authentication within the context of the
protocol in question.

What I don't advise doing is hacking up a solution involving web browsers
and web servers to solve a problem that doesn't involve either one (if in
fact that's the case).

> So, thought about simulate
> a browser or something and make requests like an usual browser.

Very ill-advised in most cases.

> The scenary is basically, a client within a Web container, that are web
> applications such as servlets or PHP scripts, can use its container to
> redirect users to the application that need to do, then make them
> authenticate there using their local federation procedures.

If you're asking how to authenticate to a *web site* with a piece of code
that isn't a browser, an answer to that is covered here (possibly minus the
delegation related material if the client were directly controlled by a
user).

https://spaces.internet2.edu/display/ShibuPortal/Home

If that's not what you're asking, then you have to specify the problem.

But the browser profile is for a *browser* to authenticate to a web site and
for IdP authentication to be handled in a browser-friendly manner. It is not
generally suitable for addressing other problems; that's why it's called a
browser profile.

-- Scott





--
Att,
=-=-=-=-=Caio Honda=-=-=-=-=
Graduando em Ciências da Computação
Pesquisador do NUPERC



Archive powered by MHonArc 2.6.16.

Top of Page