Re: JAAS Interface to sourceid

Sorry I didn't reply sooner Noah, it was a busy week last week at the
Liberty interoperability event, and I'm just now getting back into the
swing of things.

As I said in my last post (I think), the "Liberty-enabled Client or
Proxy" really shouldn't have been named that, because it implies
(incorrectly) that it's well-suited for client/server apps. Instead, in
my opinion, it should have been named, "Liberty-enabled Browser or
Proxy".

I'm not sure I totally follow your architecture proposal below.. Are you
suggesting there be JAAS code running at both the (rich) client, and at
the SP (server)?

With Jabber, PingID established a scenario whereby Jabber (truly a
client/server app) could harness SourceID, as-is, to perform single
sign-on. It's been proven to work and we will be demonstrating it at the
RSA conference in April.

Here is a write-up of what we did. It entails the "rich client" (in this
case, the Jabber client) poping up a web browser for a quick
authentication, and then closing the browser.

http://www.sourceid.org/discuss/archives/000292.php

After reading this, if we're still not on the same page, then please
push me again! ;)

Thanks,

Bryan



On Wed, 2003-03-19 at 10:09, [email protected] wrote:

    Thank you for replying.  Since the discussions in this mailing list
    are a 
    bit *lite* I'm excited to get any response.
    
    To answer your question, the model I'm looking for is client/server.
    I 
    too have been down the path of using form-based login and share your
    regards to the level of inadequacy for supporting any authentication
    model 
    beyond username/password.  However my "workaround" is to trust the
    public 
    credentials, in this case the username, submitted to the servlet 
    container.  This is obviously vulnerability, but without SSL or TLS
    with 
    client acknowledgement, this is as good as its going to get for now.
    JSR 
    196 looks promising, but alas its not available.
    
    So getting back to the question.  Client/Server authentication using
    JAAS 
    with a Liberty Alliance Login Module that supports the LECP.  As I 
    understand it, the Liberty Protocol (LP) provides a federated
    security 
    backend that appears to the client as a single authority (I'm
    probably 
    over simplifying but) that can provide SP with security credentials
    for a 
    specific user.  If a LECP can translate a security token into a 
    javax.security.Subject with the appropriate artifacts in there
    Public and 
    Private credential sets, then each SP can access the required
    information 
    and run as the Subject.  This type of delegation provides a type of
    Single 
    Sign On for all servers.  If this theory make sense then it requires
    creating a client side authentication module that 'talks' the LP.
    
    I'd imagine something along the lines of
    
    JAAS --> LECP Java Module --> HTML/SOAP Binding 
    JAAS --> SP Java Module --> SOAP Binding to remote database
                    \ --> Optional local Principal Database
                    \ --> Federated database 
    
    JAAS becomes an interface to two java packages. 
    org.sourceid.sso.lecp and 
    org.source.sso.sp and would contain the necessary interfaces for
    playing 
    each role.  Currently the system ties very closely to JSP for the
    client 
    of things, and servlets using redirects for the SP side of things. 
    This 
    makes teasing out the functionality a bit difficult and reuse of the
    util 
    package is difficult because it relies on ServletConfig and other
    Servlet 
    related APIs.
    
    Hopefully I haven't bored my audience or miss the point completely. 
    Since 
    I'm still learning this Protocol, I'm sure I've over simplified
    something, 
    but I think this a good start for creating client/server JAAS login 
    modules for the LP.
    
    I look forward to your comments,
    
    Noah
    
    
    
    
    
    "Bryan Field-Elliot" <[email protected]>
    Sent by: [email protected]
    03/19/03 08:52 AM
    Please respond to sso-dev
     
            To:     <[email protected]>
            cc: 
            Subject:        Re: [SourceID SSO-dev] JAAS Interface to
    sourceid
    
    
    Sorry I didn't respond sooner, I'm traveling this week.
    
    A big question first is, when you refer to using JAAS, are you
    talking 
    about
    in a browser-based app, or in a client/server app? Most servlet
    containers
    support a JAAS interface for authenticating username and password,
    and I
    started to go down this road with Tomcat, but it turned out to be a
    nightmare to try to force Liberty's credential exchange into the
    standard
    "form-based login". see web.xml; and see this thread:
    
    http://www.mail-archive.com/[email protected]/msg84545.html
    
    The thread above has to do with using JAAS at the Servlet Container
    level,
    rather than at a client app UI level.
    
    If instead you're talking about a client/server app (which may or
    may not
    use HTTP to communicate over the wire), then you are right that LECP
    is in
    the ballpark of the correct protocol profile to use. I say in the
    ballpark
    because it's still married to HTTP, and to some extent still expects
    a
    browser of some kind (rather than a generic client application) on
    the
    client. We would have been much happier if LECP were originally
    named
    "Liberty-enabled Browser or Browser Proxy" instead of
    "Liberty-enabled
    Client or Proxy".
    
    Hope this helps get discussion started, I'm not sure if I'm hitting
    your
    aims directly or not.
    
    Thanks,
    
    Bryan
    
    
    ----- Original Message -----
    From: <[email protected]>
    To: <[email protected]>
    Sent: Monday, March 17, 2003 12:09 PM
    Subject: [SourceID SSO-dev] JAAS Interface to sourceid
    
    
    > I'd like to purpose the question:  How hard would it be to us the
    JAAS
    > interface for authentication?  I'm more interested in federating
    the
    > identity of a user across an intranet where JAAS is the user
    interface 
    and
    > the user id and artifacts (if I understand how artifacts are meant
    to be
    > used) are presented as java.security.Principal instances contained
    within
    > a Subject.
    >
    > After a brief run through of the Liberty Alliance Protocol docs,
    it 
    seems
    > this scenario fits the LECP Profile scenario  This would require
    having
    > identity providers and service provider interfaces that are
    decoupled 
    from
    > the web presentation layer (the JSP layer).  The servlets would
    have to
    > morph to the LECP profile as well as the HTTP-Artifact (as I
    understand 
    is
    > the current implementation).
    >
    > The User Client role and the Service Provider role would be in the
    same 
    VM
    > if JAAS is the interface.  A callback handler would need to be put
    into
    > place for each of the security profiles.
    >
    > With this in consideration, where would be a good place to start? 
    The
    > LECP user agent seems to be the most logical because it doesn't
    exist. 
    How
    > much work would it take to get the SP and IDP to understand the
    LECP
    > protocol?
    >
    > TIA,
    > Noah
    > _______________________________________________
    > sso-dev mailing list
    > [email protected]
    > http://mail.sourceid.org/mailman/listinfo/sso-dev
    >
    
    _______________________________________________
    sso-dev mailing list
    [email protected]
    http://mail.sourceid.org/mailman/listinfo/sso-dev
    
    
    _______________________________________________
    sso-dev mailing list
    [email protected]

http://mail.sourceid.org/mailman/listinfo/sso-dev