users@glassfish.java.net

opensso and web2 applications

From: Wim V <wim_at_pizzastop.be>
Date: Mon, 16 Jun 2008 20:35:49 +0200

Hi everyone,

 

 

 

My flash client has no knowledge about security whatsoever, but it does know
.NET webservices.

It is a flash web2 app developed in flex or laszlo that contacts several
webservices at runtime.

The flash client program does not know about technologies like wsit, fam,
samv2 assertions, liberty-ff etc.

 

Users using this client program should however be authenticated using
opensso.

Therefore, when contacting a webservice (method) they're not authorized to
contact, they should be redirected to a login page which, after successful
login, hands them a cookie containing encrypted role and principal
information to successfully authenticate to the webservice.

 

This cookie will be fetched by the webservice's wsp agent and the cookie
contained principal and role info will be put in the web tier security
context.

Then this principal info (as with samlv2 assertions) should be propagated to
the EJB tier as well (ejb and web tier on same jvm / glassfish instance).

(See this related post :
http://forums.java.net/jive/thread.jspa?messageID=279765
<http://forums.java.net/jive/thread.jspa?messageID=279765&tstart=0>
&tstart=0 )

 

Can this be done? (I mean : using a cookie, or at least, transparently
towards the client).

Assertions are definitely the showstopper here, as my flash program doesn't
assert anything, it even has problems with a soap envelope, if you know what
I mean.

So I need a way to have all authorization in a cookie, being transparent to
the flash (or any other web2) client.

Can this be achieved using an STS? (or any other way using opensso?)

 

OR (second path of thinking..)

Can I use the wsc agent to do the required assertions/encryption/signing for
my flash program??

Actually, this would even be better because I'd love to have message level
security and reliable messaging.

But then again, has anyone experience doing this already? How is it done?

 

What I'm trying to accomplish here (and I know I called it "cookie based
authorization" before), could actually better be referred to as being "basic
authorization".

Like in the "basic authentication" we've all used, about ten years ago.

 

All tips, idea's, comments, partial answers, clues, hints, links, etc. most
welcome.

I'll also share what I've come to know, of course.

 

Thank you very much in advance,

 

 

 

Wim Verreycken