As noted in previous posts, You wouldn't need to make a lot of what you
write.
The User field of HTTPSessions is undocumented BECAUSE it should(as per the
spec) be transparent.
Orion usually creates a session implicitly, that is, a session exists even
if you still haven't authenticated. However, resource constraints require
authentication, and that auth is stored for convenience reasons into HTTP
sessions.
SOAP is really a good option. Apache's SOAP is based on soap4j, originally
made in IBM by the same guy that did XML-RPC; Don Box, the ultimate COM
evangelizer is behind it, it is a IETF controlled protocol (so there's less
vendor lockout liability than with J2EE itself, as it's all the time under
Sun's control). Anyway, I'd go for it if services to be provided are really
complicated (number of services and parameters in them), and, SOAP or not,
you'd be better off constructing some proof of concept samples.
Here's what I'd do:
1. A initiate.jsp with two purposes:
a. Obtain a session id
b. Set a user's identity
(a) is accomplished by orion automatically. In every JSP page, there's a
'session' variable wich holds a javax.servlet.http.HTTPSession instance (it
may be an simple implementation or a clustered one, with all of orion's http
session clustering features built in)
(b) is accomplished by using RoleManager.login(username, password) method
sample of invocation:
HTTP GET:
GET /[YOURAPPPATHHERE]/initiate.jsp?username=JPLorandi&password=rambalanga
on the response header you'd get a cookie(it wouldn't disable them)
Set-Cookie: JSESSIONID=JGASDHUIGSAIAIHBH (or something along these lines)
from here on, every request posted should either
(a) contain on its header a cookie field:
Cookie: JSESSIONID=JGASDHUIGSAIAIHBH
(b) be URL rewritted (postfix to the URL):
;jsession=JGASDHUIGSAIAIHBH
example:
http://[YOURHOST]/[YOURAPPPATHHERE]/[a-given-action-page]?param1=somevalue;j
sessionid=JGASDHUIGSAIAIHBH
No need to set form auth, but even if you want to do it, just leave
initiate.jsp unprotected(i.e.: not in any resource collection), both
(browser based form auth & VB client auth) will work just fine.
I hope this, altough may not solve Alex's at-hand problem, will help
someone. I sure would have liked someone gave this explanation to me instead
of having to decompile all orion to find out how the GHU"$%"@ it works.
Regards,
JP
> -----Original Message-----
> From: Alex Paransky [mailto:[EMAIL PROTECTED]]
> Sent: Monday, April 16, 2001 4:47 PM
> To: Orion-Interest
> Subject: RE: How to enable UserManager support for arbitrary user...
>
>
> I belive we *are* using Orion/J2EE sessions. We are not
> doing any of our
> own session management stuff. All our HTTP session is done
> through standard
> J2EE interfaces.
>
> You mentioned that there is a field in the HTTPSession that
> we can set to
> tell Orion what user is using this session? Is this
> documented anywhere on
> the Orion site? If not, can you give a little more detail on
> this field.
> What type of object should be stored into this attribute. As
> I understand
> it, after an object is stored into this "user" attribute in
> the session,
> Orion will use a UserManager to validate and retrieve group/rights
> information about this user for every HTTP call. So all I
> would have to do
> then, is write my own custom, UserManager and tell Orion to use it.
>
> Thanks for your help, I think I am getting closer, here is
> what I plan to
> do:
>
> 1. Create a specific login .JSP page which will:
> a. validate the user
> b. create a session
> c. configure the "user" attribute to the user object
> d. return session id to the client
>
> 2. Client passes the session id on every call as a part of the url
>
> Again, the only part of the above which I am not sure about is 1c...
>
> Thanks.
> -AP_
>
> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of Juan Lorandi
> (Chile)
> Sent: Monday, April 16, 2001 11:26 AM
> To: Orion-Interest
> Subject: RE: How to enable UserManager support for arbitrary user...
>
>
> Alex, I have a few questions and comments,
>
> 1. Which HTTPSession are you using? Orion's or your own? I recommend
> Orion's, tough one on the developments here uses a home-brewn session
> management. This forces us to include a few lines of code
> (with a taglib) in
> almost every page. Also, this renders Orion's J2EE security
> useless (Orion's
> HTTPSession has a User field where it stores either null (not
> authenticated)
> or a User reference to know the session Identity.
> 2. How are you authenticating a user? I presume you aren't
> right now. I
> would go with this:
>
> a. A Custom UserManager(for DB persistence, kinda like
> DataSourceUserManager, but yours)
> b. No custom SessionManager. (Orion has this declared
> as a public
> interface, but has no means to know which is the desired
> implementation;
> pity, session management,URL rewriting, and session + auth
> integration is
> not complaint to standards but purely propietary)
> c. a custom login action jsp/servlet. It takes username
> and password
> paramters and returns a session ID; this might be a cookie or
> URL rewriting
> (you can disable cookies in orion-web.xml)
> d. every new call has either a cookie field set on the
> HTTP header
> or a URL rewrite in the form of:
> http://somehost/somepath/somepage.jsp?a_Whole_Lotta_Params;jse
> ssionid=SOMESE
> SSIONID
>
> That's it.
>
> 3. Are the client and the server in a LAN? Why not using
> JIntegra, J2EE CAS
> or SOAP4j + SOAP Toolkit to integrate them?
>
> I think basically your problem is that your HTTP Session is
> propietary and
> not seamlessly integrated with Orion. All we all would need
> to implement a
> SessionManager of our own without recompiling Orion is a
> SessionManager tag
> much like the UserManager tag in orion-application.xml. Then
> whenever a
> custom SessionManager is needed(in our case, to share
> sessions between Orion
> and IIS) would benefit of many neat things orion does, such
> as automatic URL
> rewriting, transparent session management(the session object
> available in
> JSP) and declarative security, to name a few.
>
> My 2c,
>
> JP
>
> > -----Original Message-----
> > From: Alex Paransky [mailto:[EMAIL PROTECTED]]
> > Sent: Sunday, April 15, 2001 1:03 AM
> > To: Orion-Interest
> > Subject: RE: How to enable UserManager support for arbitrary user...
> >
> >
> > Here is the problem that I am not sure how to really fix.
> >
> > Our EJB application is wrapped with a number of "command"
> > URL's which return
> > XML results. For example:
> > http://localhost/getAccountInformation.jsp?account=2234 would
> > return an XML
> > representation of an account. An
> > http://localhost/addUserToAccount?account=2234&userName=test..
> > . would add a
> > user to a particular account. A Visual Basic client, then
> uses these
> > "command" URLs and resulting XML to present a user interface.
> >
> > Given the above scenario, what would be your recommendation for
> > authenticating the user starting right after I accept the
> > user/password from
> > the VB form (I don't much care for VB specifics, just the
> > part which deals
> > with EJB/JSP/J2EE security).
> >
> > After accepting user authentication information from a VB
> dialog, what
> > should I do next. How do I get this information "registered"
> > with Orion or
> > any j2ee application server so that the deployment descriptor
> > information
> > works correctly.
> >
> > Is this the way J2EE security was meant to be used. A non
> super-user
> > account, cannot execute a setSuperuser(boolean) function on
> > the User bean.
> > Is this how I should be controlling this? Is this the proper
> > method? I was
> > reading the J2EE EJB spec which states that coding security
> > should be the
> > last resort.
> >
> > I am not clear on how to execute the above scenario.
> >
> > Thanks to all the people who have already posted in regards
> > to this issue.
> >
> > -AP_
> >
> > -----Original Message-----
> > From: [EMAIL PROTECTED]
> > [mailto:[EMAIL PROTECTED]]On Behalf Of
> > Jeff Schnitzer
> > Sent: Friday, April 13, 2001 10:09 PM
> > To: Orion-Interest
> > Subject: RE: How to enable UserManager support for arbitrary user...
> >
> >
> > I suggest using an MVC (aka "Model 2") approach, separating
> your view
> > from your controller. One of the controller's
> responsibilities can be
> > to check for authentication and provide to the user either
> > the requested
> > page or the login page.
> >
> > If you use a dispatcher-servlet-action framework for your
> controller,
> > you typically will only need to put the authentication
> > checking code in
> > a base action class from which all protected action classes
> > derive. If
> > you use JSPs as controllers you'll need some sort of code
> in every one
> > (you can use @include for this).
> >
> > You will be much happer if you use an MVC appraoch, trust me.
> > The J2EE
> > automatic form-based authentication is very crude and fails to
> > accomodate simple use cases like automatically logging in new users.
> >
> > You might want to look at WebWork:
> > http://www.sourceforge.net/projects/webwork.
> >
> > BTW, if you use the Orion UserManager (and RoleManager), you
> > should not
> > do your own database lookup. Calling RoleManager.login()
> > causes methods
> > to be called on the UserManager, which can either be your
> class or one
> > of the UserManagers that ship with Orion.
> DataSourceUserManager looks
> > up password and group information in a table.
> >
> > Jeff
> >
> > >-----Original Message-----
> > >From: Alex Paransky [mailto:[EMAIL PROTECTED]]
> > >Sent: Friday, April 13, 2001 3:20 PM
> > >To: Orion-Interest
> > >Subject: RE: How to enable UserManager support for
> arbitrary user...
> > >
> > >
> > >Tim, this IS what I am looking for, but does it mean that I
> > >need to put this
> > >into every .JSP page that I have? Then, somehow (according to
> > >J2EE spec)
> > >Orion will forward this information to all EJB calls and
> > >properly make use
> > >of the deployment descriptor stuff? So every .JSP page will
> > check the
> > >session, find the User object which I stored in there, and
> > >execute this call
> > >with the user.login and user.password?
> > >
> > >Thanks.
> > >-AP_
> > >
> > >-----Original Message-----
> > >From: Tim Endres [mailto:[EMAIL PROTECTED]]
> > >Sent: Friday, April 13, 2001 3:04 PM
> > >To: Orion-Interest
> > >Cc: Alex Paransky
> > >Subject: Re: How to enable UserManager support for
> arbitrary user...
> > >
> > >
> > >Is this what you are looking for?
> > >
> > > RoleManager roleMgr = (RoleManager)
> > > (new InitialContext()).lookup( "java:comp/RoleManager" );
> > > roleMgr.login( "user", "pass" );
> > >
> > >Unfortunately, I think that can only run in the container. To
> > >accomodate
> > >multiple logins under a servlet, we used to use a new
> > InitialContext on
> > >every servlet request and set the appropriate JNDI
> > properties for each
> > >InitialContext construction.
> > >
> > >tim.
> > >
> > >> We have developed a web application with our own
> user/group schema.
> > >> Creating a UserManager to map our schema seems pretty
> > >trivial. What we
> > >are
> > >> NOT clear on is how to tell Orion that a particular user has
> > >logged in.
> > >>
> > >> For example, we start our application with a LOGIN.JSP page,
> > >which accepts
> > >> user name/password, and proceeds to find the user in the
> > >database. After
> > >> the user is found/authenticated, we create an HTTP session,
> > >and store a
> > >> certain User object in the session to tell us who the user
> > >is on the next
> > >> http request.
> > >>
> > >> How do we introduce J2EE security into this picture. In
> > >other words, how
> > >do
> > >> we tell Orion which user is logged on so that it starts
> > >using the security
> > >> attributes/group/rights of the deployment descriptors? Do
> > >we need to put
> > >a
> > >> special attribute into the HTTPSession so that Orion knows
> > >on behalf of
> > >what
> > >> user the request is running?
> > >>
> > >> Thanks.
> > >> -AP_
> > >>
> > >>
> > >
> > >
> > >
> >
> >
>
>
