• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Swing client communication...

 
Ranch Hand
Posts: 194
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi guys,

I have been thinking about this for a while, what is the best way for a Swing client to communicate with the server side application?

Two ways I have been thinking about are:

1. Direct calls to the EJB's.
2. Web Service calls via the web container.

I think that for the purposes of our application, direct communication with the EJB's is better because all agents will be within the companies firewall and will have no difficulty talking directly to the EJB. Also in this scenario web service calls create a bigger overhead and also go though the web container requiring more precessing.

I think that web services are good for Swing clients that are external to the companies intranet, i.e. outside the firewall.

I would like to know your thoughts on this and what methods your using.

Thanx for the help.

James.
 
Ranch Hand
Posts: 2023
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I would like to use EJB call.
 
James Turner
Ranch Hand
Posts: 194
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
thanx wise,

Is there an easy way to authenticate the Swing client with JAAS to allow the Swing client to call secure methods on the EJB?
 
Greenhorn
Posts: 15
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
1. In that case where would JAAS module sit? In the App server?

2. Assuming Swing Clients are going to make a RMI/IIOP call over Internet to the EJBs, How is the security context passed? like Security.runAs(subject, action)?

[ June 23, 2006: Message edited by: Johnty Rhodes ]
[ June 24, 2006: Message edited by: Johnty Rhodes ]
 
James Turner
Ranch Hand
Posts: 194
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I surpose the login module would sit on the client. It would use LDAP to compare the username and passwords.

Can the login module sit on the server? Is there a way for a swing client to login remotely?

I think the only way is to login with the login module on the client and then pass the security context via RMI/IIOP to the EJBs.

I may be wrong. Any thoughts on that?

Regards,

James.
 
Johnty Rhodes
Greenhorn
Posts: 15
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
James,

Option which you have given will work for Web Client (i.e., having LoginModule in the Web Server).

But for the Swing Client, How will it get the Subject/Principal, for it to make direct EJB calls?

Your thoughts?

Thanks
 
Ranch Hand
Posts: 311
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hello James,

Originally posted by James Turner:
It would use LDAP to compare the username and passwords.


Good idea, but where?:

Originally posted by James Turner:
I surpose the login module would sit on the client.


1. If you think of login over the Internet: That client-side login module would not add any security, it soon could become the favorite playground for hackers They just need to replace the original client-side login module by a fake.

2. Who needs to login, when, and what for?
a) "User" - what is that? An agent? A customer? ...
b) Should an agent login?:
What for, and under which circumstances (Inter-/intranet ...).
Most important: Are his credentials needed or the credentials of the customer?
Whose credentials are stored and where?
Whose credentials are checked, when and where?


First of all you should decide your architecture acc. to the requirements (timing etc., not only for login):
- web clients (customers) using/wrapping same EJBs as Swing client (agent) calls, - why? - OR
- Swing clients (agent) going through the same web tier (servlet ...) as web clients (customers)?, - why? - OR
- no reuse at all?
What from the requirements are the criteria and reasonings for your decision?!! Write them down! Take your time here.


Originally posted by James Turner:
Can the login module sit on the server?


The login-check generally / logically must take place in the server, as stated above (fakes ...).
So what is that "login module"? A client-side FORM, or GUI-window, ...?
Or the (client-side / server-side?) code sending the say password to the DB and getting back wether ok or not?
Maybe multiple tasks that must be in multiple tiers?
Or "the system" (EJB or browser) performs one of the tasks implicitely anyway, popping up a vendor specific dialog box, ...?


Originally posted by James Turner:
Is there a way for a swing client to login remotely?


Yes!
First reading: Paul Allen et al.: "SCEA...", in the index search for login-config ..., EJB container authentication. This book is not sufficient for understanding login!
Better: read in an EJB book like "Professional EJB".

The most important part for me was that the deployer can set up trust relationships between both kinds of containers, so the EJB container can trust that the call (if coming through the web tier) already has been authenticated by the web container. Thereby the web container simply passes the the credentials to the EJB container. Configuring the trust relationship is vendor specific and a task of the deployer.

Good success,
Thomas
[ June 25, 2006: Message edited by: Thomas Taeger ]
 
Johnty Rhodes
Greenhorn
Posts: 15
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thomas thanks for your reply.

Web Tier can use JAAS authentication in the Web server itself and Web Server will take care of propagating the Subject to the App Container for each session.

But for the 'Stand-Alone' Swing Clients
1. How will Swing Clients get the Subject?
2. How will it propagate it for subsequent EJB calls? (I read it somewhere that Subject.doAS() over remote calls will not propagate the Subject. And we have to use some RMI interceptor to propagate)

Not sure whether my understanding is correct.

Looking forward your comments on this.

Thanks
 
Thomas Taeger
Ranch Hand
Posts: 311
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hello James,

Originally posted by James Turner:
... what is the best way for a Swing client to communicate with the server side application?
...
2. Web Service calls via the web container.


I would not call them Web Services because the only thing we need here is a dedicated remote interface. Web Services in contrast are provided in the web without knowing what clients they could be good for later (and optionally calling other peer Web Services).

For that what you mean probabely the phrase "web container" or just "web interface" would be more precise.

However I totally agree with you in your main point:

Originally posted by James Turner:
I think that for the purposes of our application, direct communication with the EJB's is better because all agents will be within the companies firewall and will have no difficulty talking directly to the EJB.


... and I would like to add the given requirement of different response times.


Originally posted by James Turner:
I think that web [interfaces] are good for Swing clients that are external to the companies intranet, i.e. outside the firewall.


Even for remote (Internet) interactions you do not need a web interface between, this is important to know.
Swing clients can directly remotely call EJB methods over the Internet (after looking up etc.).
If you are not sure how, then just hide that by a client-side Business Delegate along with a client-side Service Locator (looking up the EJB, narrowing, caching etc. somehow). See Deepak Alur et al. "Core J2EE Patterns" - also the examiners know this book and even the implementation of these two patterns, and also client developers know how to implement.

Thomas
 
James Turner
Ranch Hand
Posts: 194
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Thomas,

Thank you for your post, it is very interesting.

From what you have said, are you saying that web services are the way to go for connecting a swing client to the EJBs? It seems a little overkill since the Swing client can access them directly, the only issue is authentication of the swing clients.

I have assumed the swing clients are within the companies firewall.

Regards,

James.
 
Thomas Taeger
Ranch Hand
Posts: 311
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hello Johnty,

please note that I have not been talking about JAAS but about interaction between clients and EJBs in general and mentioned only implicite login mechanisms that must be provided by the containers.

- For web logins basic / form authentication is standardized.

- For client logins, i.e. from a client application container to a EJB container there is no standard but a "must" that the provider of an EJB container and of the according client.jar must support container based authentication somehow.

Thomas
 
Thomas Taeger
Ranch Hand
Posts: 311
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by James Turner:
are you saying that web services are the way to go for connecting a swing client to the EJBs?


No, pretty exactly the contrary (probabely you forgot a negation)

You do not need Web Services for connecting Swing clients to EJBs.

You should not name web interfaces "Web Services", see the Web Services specification.

You do not even need a web interface between the Swing client and the EJB.

As said:
Swing clients can directly remotely call EJB methods over the Internet (after looking up etc.).

Thomas
 
James Turner
Ranch Hand
Posts: 194
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Thomas,

I am sorry I am a little lost here...

I should then communicate with the EJB's directly via RMI/IIOP? My issue is how do I authenticate the Swing client so that it can pass the security context so it can access the secured EJBs?

Thank you for your help, it is much appreciated.

Regards,

James.
 
Thomas Taeger
Ranch Hand
Posts: 311
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by James Turner:
I am sorry I am a little lost here...


So was I. The literature is pretty bad according to this. I do not know many EJB books, but "Professional EJB", Wrox, (my old? edition is up to EJB 2.0 only), mostly gave me what I searched for. Maybe others know even better / newer books on EJB container authentication.

Another reason for confusion is that this area at the last is in the responsibility of the deployer. But we architects must know what we can design so he can deploy it later.


Originally posted by James Turner:
I should then communicate with the EJB's directly via RMI/IIOP?


Yes (or RMI/JRMP).


Originally posted by James Turner:
how do I authenticate the Swing client so that it can pass the security context so it can access the secured EJBs?


You need not pass anything.

The EJB container automatically fetches
a) lazily (as soon as needed the first time) and
b) only once

the credentials via an automatic callback to the client.
It asks the user by a vendor specific dialog to authenticate - again in a vendor specific manner, but most often by entering a password, acc. to what the deployer required for that method.


By the way: Is there anything special behind what you call "security context" in the area of EJB?

Thomas
[ June 25, 2006: Message edited by: Thomas Taeger ]
 
Johnty Rhodes
Greenhorn
Posts: 15
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thanks Thomas. Now I got the point for Swing Clients !

So the App Server which we choose determines the Client jar to be placed in Swing Client side, for remote authentication.

I think in Weblogic (weblogic.jar) Authenticate.authenticate() does this. [This is JAAS based]

Thanks
[ June 25, 2006: Message edited by: Johnty Rhodes ]
 
Thomas Taeger
Ranch Hand
Posts: 311
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Johnty Rhodes:
I think in Weblogic (weblogic.jar) Authenticate.authenticate() does this.


In 8.1, isn't it bea\weblogic81\server\lib\wlclient.jar, and must be copied to the client machines although it originally is provided in server\lib ?

Thomas
 
Johnty Rhodes
Greenhorn
Posts: 15
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Yeah. You are right. It is wlclient.jar

Pls Correct me if I am wrong.

We will be using the subject returned by this Client classes and then use like Subject.doAs(subject, yourAction).
- Where yourAction will wrap the EJB calls.

I am not able to find any book or online resource, which talks about remote client JAAS authentication. Please let me know if you know any.

Thanks
 
James Turner
Ranch Hand
Posts: 194
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Thomas,

Thank you for your help, from my understanding you are going down a non-standard route by using proprietary protocols of the specific app server.

I had the idea of using JAAS because it was standard. The only think I was confused about was how to use JAAS in a Swing client.

If at all possible I would like to follow the standards route; I think it is the best way. Although I am not sure how best to implement JAAS in the Swing client.

Thank you for your help, any comments are greatly appreciated.

Regards,
James.
 
Ranch Hand
Posts: 149
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
JAAS Authentication of Java clients

http://e-docs.bea.com/wls/docs61/security/prog.html#1039659
 
James Turner
Ranch Hand
Posts: 194
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thank you Maris, much appreciated.
 
Maris Orbidans
Ranch Hand
Posts: 149
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

If at all possible I would like to follow the standards route;



J2EE spec. says that JAAS API should be supported in application client. So it's better to use JAAS than any server specific way (JNDI auth.) to authenticate SWING clients, indeed.

But how are you going to document this design choice ? In sequence diagramm ?

BTW here is an interesting article JAAS Authentication Tutorial

http://java.sun.com/j2se/1.4.2/docs/guide/security/jaas/tutorials/GeneralAcnOnly.html#SampleAcnClass
[ June 27, 2006: Message edited by: Maris Orbidans ]
 
Thomas Taeger
Ranch Hand
Posts: 311
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by James Turner:
If at all possible I would like to follow the standards route


Hi all,
I feel that you assume that only JAAS were a standard.

As I wrote client/EJB login is implemented vendor specificly.
That in my opinion does not necessarily mean that there would be any vendor specific interface. As far as I know there is not even any interface that a vendor has to implement. He just has to implement the described login behaviour somehow.

For a simple form login for me this seams to be sufficient, and I designed for it.

1. What are the reasons why JAAS necesseraly must be used?

2. What in general are the advantages of JAAS compared to standard form login?

Thomas
 
Maris Orbidans
Ranch Hand
Posts: 149
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Thomas Taeger:
2. What in general are the advantages of JAAS compared to standard form login?



We are discussing authentication of SWING clients. Of course, there is no point to reinvent the wheel and use something different than form-based authentication for web interface.


I feel that you assume that only JAAS were a standard.



AFAIK it's only standard way to authenticate application (not WEB) EJB clients


1. What are the reasons why JAAS necesseraly must be used?



It might be better for portability reasons. Of course, in practice we often use vendor specific JNDI authentication, but it's not ideal.
[ June 28, 2006: Message edited by: Maris Orbidans ]
 
Maris Orbidans
Ranch Hand
Posts: 149
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

I surpose the login module would sit on the client. It would use LDAP to compare the username and passwords.



Yes, the login module should be on the client side, but you don't need to implement it! The J2EE vendor should provide an implementation, for example, for WL it's weblogic.security.auth.login.UsernamePasswordLoginModule.

[http://edocs.bea.com/wls/docs70/security/fat_client.html]

You can write vendor independent code that uses JAAS API to login. That's the benefit of JAAS.

I am not sure though whether SUN Java Application server supports client side JAAS modules.
 
Thomas Taeger
Ranch Hand
Posts: 311
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Maris Orbidans:
We are discussing authentication of SWING clients.


You are right in that the term "form-based authentication" is reserved for web clients, sorry.

However for application clients there is a kind of authentication between the client application container and the EJB container, normally popping up a login dialog, aside from JAAS. As I wrote: "For client logins, i.e. from a client application container to a EJB container there is no standard but a "must" that the provider of an EJB container and of the according client.jar must support container based authentication somehow." As I mentioned the way how this is implemented is vendor specific, i.e. not standardized, but the fact of the existence of this container-to-container-authentication is standard. Therefore JASS may be the only standard implementation of this authentication but JAAS is not the only standard mechanism that we can trust on.

That is why I would like to hear some reasons why it is worth for me to learn more about JAAS.
Especially what are the reasons why or when JAAS necesseraly must be used?
I would prefere to read some reasonings as I try to provide short reasonings too - not only links (though links can additionally be very helpfull for digging into later).

Originally posted by Maris Orbidans:
Of course, in practice we often use vendor specific JNDI authentication, but it's not ideal.


To be honest, the term "JNDI authentication" (or "vendor specific JNDI authentication") is new to me.
What I know is authentication via LDAP and accessing the LDAP server through JNDI as usual. Is this what you mean?

Why do you think authentication through LDAP (via JNDI) is not ideal? What are the reasons?

Thomas
[ June 28, 2006: Message edited by: Thomas Taeger ]
 
Maris Orbidans
Ranch Hand
Posts: 149
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator


To be honest, the term "JNDI authentication" (or "vendor specific JNDI authentication") is new to me.
What I know is authentication via LDAP and accessing the LDAP server through JNDI as usual. Is this what you mean?



The term "JNDI authentication" is used in WL documentation and it means that you put client credentials in a hashtable what you pass to JNDI InitialContext. This was the only way to authenticate EJB application clients in first J2EE servers when JAAS was not available. Here is an example for WL.




That is why I would like to hear some reasons why it is worth for me to learn more about JAAS.
Especially what are the reasons why or when JAAS necesseraly must be used?



I don't claim that JAAS must be used necesseraly. But it might be better, because JNDI authentication, as you saw in the code example , is vendor specific. But if you use JAAS then in case you migrate to other J2EE server you would need only to change JAAS authentication module name in a config file.


Why do you think authentication through LDAP (via JNDI) is not ideal? What are the reasons?



I think it would matter only for the server whether you use database or an LDAP server where to store user credentials, groups etc. You could write JAAS login module for the server, if you'r server doesn't provide it already.

But it's not relevant for the client, because it's not the client that should decide whether user's credentials are acceptable. IMO The discussion here is only about what API should we use to send user password to the server.
 
Thomas Taeger
Ranch Hand
Posts: 311
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thank you for translating the BEA Weblogic term "JNDI authentication".

Up to here I understood two differences between container based authentication and JAAS:
1. In container based authentication we need to provide two parameters (INITIAL_CONTEXT_FACTORY and PROVIDER_URL).
. In JAAS we need to provide one parameter (JAAS authentication module name).
2. In container based authentication you may provide the parameters a) in a config file or b) hard coded (as in your example).
. In JAAS we [always] provide the parameter in a config file.

Are there any more differences?

Thomas
 
Ranch Hand
Posts: 174
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Guys can we summarize the discussion till now as follows
1. Form based authentication can be used for web clients.
2. JAAS can be used for swing clients. This is vendor neutral and its assumed that each time business method on EJB is invoked, security credentials are passed to the EJB's.This data would be propogated over SSL hence would be secure.

But I still have following queries
1. We don't have a common login mechanism for web and rich client.
2. We are using JAAS as e don't want to be vendor dependent for authentication. But we would have to write vendor specific code from remote client to connect to a particular server for eg in weblogic

Hashtable env = new Hashtable();
env.put(Context.INITIAL_CONTEXT_FACTORY,
"weblogic.jndi.WLInitialContextFactory");
env.put(WLContext.PROVIDER_URL, "t3://weblogic:7001");

So why can't we add security crdentials in the env
env.put(WLContext.SECURITY_AUTHENTICATION "strong");
env.put(Context.SECURITY_PRINCIPAL, "javaclient");
env.put(Context.SECURITY_CREDENTIALS, "certforclient");

This connection and validation code can be extracted in a common component which can be changed when the server chnages.

Any comments ?
[ July 03, 2006: Message edited by: Vinays Singh ]
 
Greenhorn
Posts: 2
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Lads..

This is my first day in this forum and I have started enjoying the level of interaction and information being shared..Pretty impressive..

Coming into to topic of JAAS being preferred mechanism for Swing Client to interact with Application Server..I dont understand what do we mean by :-
=============================================================================
2. JAAS can be used for swing clients. This is vendor neutral and its assumed that each time business method on EJB is invoked, security credentials are passed to the EJB's.This data would be propogated over SSL hence would be secure.
=============================================================================

Is it required that we need to use SSL for Swing Client to Interact with App Server ??
Any ideas or thoughts..

Cheers,
SAM
 
Rancher
Posts: 43081
77
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Sam,

Welcome to JavaRanch.

On your way in you may have missed that JavaRanch has a policy on display names, and yours does not comply with it; specifically, a first name and a last name are required. Please adjust it accordingly, which you can do right here. Thanks for your prompt attention to this matter.
 
Vinay Singh
Ranch Hand
Posts: 174
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Sam
It is a mandatory requirement that all communications between client and server should be secured. This stands true for web client as well as swing clients.
 
Subhendu Mohapatra
Greenhorn
Posts: 2
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thanks Vinay..
So are we talking about tunneling through SSL..request response from Swing client to App Server in order for it to be secure.

Or do we have any better ways of doing the same.


Also another thought..Would just writing a note regarding the preferred way of communication suffix the need for secure communication requirement or is there any better way..

Thanks again..
 
Ulf Dittmer
Rancher
Posts: 43081
77
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hello smohapat-

Welcome to JavaRanch.

On your way in you may have missed that JavaRanch has a policy on display names, and yours does not comply with it; specifically, a first name and a last name are required. Please adjust it accordingly, which you can do right here. Thanks for your prompt attention to this matter.
 
Ranch Hand
Posts: 1183
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Good Day,

It's interesting that the product which I use, Intraspect, uses JAAS for strictly web clients.

As the documentation says:

JAAS Login Modules

VBCS uses the Java Authentication and Authorization Service (JAAS) framework provided by Sun Microsystems to offer authentication hooks, specifically through JAAS Login Modules.
The JAAS framework supports multiple Login Modules, which can be used in conjunction with one another. Each Login Module defines one type of authentication.
For example, an installation that has an HTTP basic Login Module may or may not include a Login Module that performs an LDAP lookup or bind. Use of multiple Login Modules is known as stacking.
The JAAS configuration can specify that both modules must return a login success before user authentication is approved, or that the basic module is sufficient for authentication and that the LDAP module is used if the first module fails.



Regards,
Dan
 
reply
    Bookmark Topic Watch Topic
  • New Topic