[prev in list] [next in list] [prev in thread] [next in thread] 

List:       shibboleth-users
Subject:    RE: Re: [Shib-Users] Custom Authentication
From:       "Scott Cantor" <cantor.2 () osu ! edu>
Date:       2008-07-31 15:03:06
Message-ID: 089001c8f31e$8a01c780$9e055680$ () 2 () osu ! edu
[Download RAW message or body]

> The CF Authentication is valuable to the business because it doesn't
merely
> check that credentials provided by the user are valid, but also enforces
> account lockout after three attempts and some other important checks.  If
we
> were to use the IdP Username/Password handler it would not have these
> additional checks.

Fair enough.
 
> Essentially, what I'm trying to ascertain is whether or not we'll be able
to
> use the CF authentication as the authentication for used to authenticate
> users at the IdP and therefore at all the linked SPs.

Not directly, no. That's because of the limitations of the approach that was
taken in that system. The IdP is just (mostly) a web app. It can do
authentication itself if you want it to, but it also can act as a good
citizen and accept what the web server tells it. Your problem is that your
CF blob doesn't have the ability to protect a basic commodity web server,
and that's a serious problem with anything claiming to be a web
authentication system.

Anyway, the point is that you have authentication on server A (the CF thing)
and you want an authenticated identity on server B (the IdP). That's the
definition of web SSO; ergo you need a web SSO system to connect them.

And worse than that, you need something that can somehow fit into your CF
situation, which I can't really speak to without understanding it (and it's
not high on my TODO list to try ;-)

> It sounds like this would be awkward and it would be better to implement
the
> business rules which the CF authentication currently enforces within a
Java
> web app which could be deployed to protect the IdP.  The CF application
> would then have to have the SP software installed and would have to be
> adjusted in regards to its session management, etc.  What do you think?

That is a possibility, yes. How much work I couldn't say, but it's probably
less work than inventing a new SSO protocol to do the job.

One ugly approach I suppose I should mention is scraping. If you have a way
to "simulate" a client to the CF bits inside the Java of the IdP, you could
theoretically take the user/pass you get there and feed it to the CF app so
as to use it for doing the checks. It's ugly though, and brittle, like any
screen scraping approach.

> I need to understand the reality of the situation, because I will be
writing
> a feasibility report for my organization.   I really want to convince them
> to go down the route of SAML.  Hey, I'd be pretty pleased if that does
> involve changing our architecture to suit, i.e. implementing the business
> model objects in Java rather than CF!!!  (FYI, I'm not a fan of CF... just
> an annoying, limiting layer on top of Java in my opinion.

Your problem isn't CF, it's the broken approach to web authentication that
was taken. That same broken approach can be implemented in Java, CF, .NET,
Ruby, etc. And is, repeatedly. ;-)

> How would the process flow look between the the IdP and the filter in the
> two different scenarios of when the user is and is not already logged in?

I can't speak to that in detail because that depends on the SSO protocol you
implement. At a basic level, the filter's job is to ensure that by the time
what's behind it runs, a login exists. To do that, it will redirect the
browser away from itself if a session doesn't exist, and then interpret some
kind of message in return that is either signed, or represents information
it can verify with a callback to another server. That is roughly how most
SSO protocols work.

> field.  How about the "is not already logged in" scenario?  Would the
> Servlet Filter detect the user hasn't got a session and throw the user to
> some JSP login screen?

No, it redirects them to the server running the authentication part of the
system and it does whatever you want it to. But in this case you'd be
writing a protocol to somehow interface with the CF app and get it to log
you in and then return a secured response to the IdP server for the filter
to handle.

> If so, when the login form gets submitted, and a
> session is created, where would the Java app send the user so that the IdP
> would know which SP was requested in the first place?  This is a little
> cloudy to me right now...

Don't worry about the IdP yet. The IdP isn't really relevant to the hard
aspects of this. Think of it as just a Java app you want to get REMOTE_USER
into.

HTH,
-- Scott


[prev in list] [next in list] [prev in thread] [next in thread]