Out of curiosity, why aren't you using SOAP? Seems like that is
designed to do exactly what you want, and I'm sure there is terrific VB
support for it.
You can use J2EE security, but the usual paradigms for J2EE
authentication aren't going to do you much good.
You probably just want a login.jsp?name=xxx&password=xxx url and from
within that call RoleManager.login(). Since you have a fat client, you
don't need to worry about the user trying to access a protected page
without logging in; the client can be smart about what users are allowed
to do.
Make sure you're properly handling the http cookie returned by the
server otherwise your login isn't going to "stick"... security is
associated with the session, of course.
IMHO, support for HTTP-based RPC in J2EE is very poor, and MS is way
ahead of the game here.
Jeff
>-----Original Message-----
>From: Alex Paransky [mailto:[EMAIL PROTECTED]]
>Sent: Saturday, April 14, 2001 10:03 PM
>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_
>>>
>>>
>>
>>
>>
>
>
>
