Given that he has a smart/fat client, I don't think the web form is the
way to go. It's a square peg for a round hole.
Alex, when you execute a successful RoleManager.login(), whatever user
information Orion keeps is automaticaly taken care of. All you need to
do is make sure you maintain the session id in either a cookie or a
rewritten url (;jsessionid=ASDFGHIJKL) in your requests. You don't need
to explicitly create a session in the JSP, either.
If you subsequently want to get the user name or programmatically check
security, use the getCallerPrincipal() or isCallerInRole() methods on
the servlet context or ejb context objects.
You'll need to watch out for session timeouts in your client.
You should seriously consider using SOAP. That is designed for exactly
what you're trying to do. There is a free Apache implementation that
you could probably get running under Orion, and VB will do all the
client work for you.
Jeff
>-----Original Message-----
>From: Hani Suleiman [mailto:[EMAIL PROTECTED]]
>Sent: Monday, April 16, 2001 2:07 PM
>To: Orion-Interest
>Subject: RE: How to enable UserManager support for arbitrary user...
>
>
>> 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
>>
>Why go through any of 1? J2EE does all this for you. All you
>need to do is
>use form auth. Have your login page return whatever xml is required to
>show the VB login box. So whenever you request a protected
>resource, the
>login box will pop up. Disable cookies in the webapp, and then
>read in the
>JSESSIONID from the url and just make sure it's in every
>future request,
>so the servlet container knows where to find your
>authenticated session.
>
> > 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;jses
>sionid=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_
>> > >>
>> > >>
>> > >
>> > >
>> > >
>> >
>> >
>>
>>
>>
>
>
>
