Re: JAAS Interface to sourceid

NP...just happy to get a response.

I read your description of a rich client using Jabber for authentication. 
This is a very sophisticated way of reusing the browser technology in a 
client server applications.  However, the scenario wouldn't work if a 
browser is not installed on the client.  Be it a thin client or a server 
where users wouldn't typically be found.  Now, this doesn't mean your 
assertion that LECP should be renamed LEBP isn't valid (sorry for the 
double negative).  However, the LECP spec doesn't use anything browser 
related except in parsing the responses from the SP and IDP.  Just so 
we're on the same page, I'm looking at Figure 5 in the 
liberty-architecture-binding-profiles-v1.1.pdf file (line 1098).  If you 
look closely at steps 1, 3, 7, and 11 you'll notice that any socket based 
api could implement the required flow of the application.  The client 
still needs to understand SOAP and XML, but there is no need to process a 
redirect.  This is functionality a compliant internet browser does need to 
implement but a socket based application would not.  This is how I 
interpreted the spec, please let me know if I missed something.

Secondly,  If the LECP (or LEBP) could be implemented using a Facade 
Pattern, then a client developer could drop in the functionality to any 
new client application.  However, since JAAS is a pluggable model for 
authentication and is the recommend way for clients to "view" 
authentication modules, then the next logical step (in my mind anyway ;) 
is to create an JAAS Adaptor to the Facade so any JAAS enabled application 
or container could use the Liberty protocol without having to change any 
line of code.  This means that anyone running Tomcat, JBoss, Weblogic, 
Websphere, Oracle, etc could plug the Liberty Protocol into there 
applications, and well...you get the idea.

As far as the SP is concerned in regards to using JAAS.  I envision 
something similar with the Facade pattern with a JAAS adaptor.  Once major 
difference is that the SP maintains a volatile state of the IDP and is 
constant communication with it.  I'll need to read more to get a sense of 
what is required for the SP.  Hopefully, I'll be able to flush out more 
understanding during our conversation regarding the client.

Look forward to hearing from you,

Noah

PS.  Btw, what have you heard regarding JSR 196...they don't seem that 
active.






Bryan Field-Elliot <[email protected]>
Sent by: [email protected]
03/24/03 04:37 PM
Please respond to sso-dev
 
        To:     [email protected]
        cc: 
        Subject:        Re: [SourceID SSO-dev] 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