Username password entry from server side.

53 views
Skip to first unread message

dnetechno

unread,
May 23, 2014, 1:31:01 PM5/23/14
to confd-us...@googlegroups.com
Currently login username and password are supplied to ConfD using javascript and maapi - therefore from client side.  We are looking for a method to supply confD the username and password from the server side.  Is there a non-javascript maapi that facilitates this?

chriss

unread,
May 23, 2014, 7:28:26 PM5/23/14
to confd-us...@googlegroups.com
Hi,
Could you explain a little more what you are trying to accomplish? If you are trying to establish a login using user credentials, isn't that by definition a "client" action? If you want to run it on the server side, you could have a client daemon using maapi to connect to the server.
-chris

dnetechno

unread,
May 27, 2014, 5:51:13 PM5/27/14
to confd-us...@googlegroups.com
Thanks for the response Chris.  Here is more explanation.

There will be two WebUI login methods:
1) Username and password entered by from client side
2) Certificate/PKI login.  In this case the certificate is validated through the trust chain by the server.  If the certificate is trusted the common name from the certificate is used as the username.  I want to pass this username into ConfD from the server side.

chriss

unread,
May 28, 2014, 2:23:32 AM5/28/14
to confd-us...@googlegroups.com
Hi,
Could you walk me through the authentication process you have thus far, and what you need to complete it? Are you using the ConfD web server and web framework, or some other set of components? Sorry, I just cannot picture what you're trying to do.
- chris


On Friday, May 23, 2014 10:31:01 AM UTC-7, dnetechno wrote:

dnetechno

unread,
May 28, 2014, 12:29:33 PM5/28/14
to confd-us...@googlegroups.com
I will try to explain my objective better than I have so far.

Yes I'm using the ConfD web server and framework.  We are using ConfD in two modes for WebUI login: traditional username/password and SmartCard/PKI:

1) Traditional authentication uses the local ConfD user database including groups. Javascript is used to prompt the user for username and password which are in supplied to ConfD through Maapi.  If Maapi_Authenticate() is successful group information is returned and the management session starts.

2) SmartCard/PKI login is more complicated and involves user certificates and remote authentication.  In this mode, ConfD is configured for external authentication.  Login begins with the user entering their card.  The certificate from their card is validated by the server side using Pathfinder (opensource trustchain discovery and validation).  A valid certificate starts an https session and in my case returns the username (common name from the certificate).  Currently I'm entering the username and password from the client side and ConfD invokes an executable and passes the username to the executable.  In my case the executable is a remote AAA client (RADIUS), which returns Accept and Group information or Reject to ConfD.  Accept and Group information completes the ConfD authentication process and starts the management session (ConfD manual paragraphs 14.4.4 and 14.5).  I need to eliminate the manual username/password input from the client side and replace it with a server side function that provides the username/password (from certificate validation described above) to ConfD.

That's the big picture.

chriss

unread,
May 29, 2014, 6:06:46 PM5/29/14
to confd-us...@googlegroups.com
Hi, sorry for the delay, I am working on urgent release. What releases aren't urgent? :)

I understand the part about the external AAA via radius server, I've implemented that before too. ConfD invokes the external AAA executable for any northbound interface assuming the settings in confd_dyncfg requires it. It seems to me this aspect is secondary, since by this time the common user name is already provided through a client interface.

I still don't understand this part:

"The certificate from their card is validated by the server side using Pathfinder (opensource trustchain discovery and validation).  A valid certificate starts an https session and in my case returns the username (common name from the certificate)." I don' t know how Pathfinder operates in your situation.

It sounds to me like you have a custom web page which supplies a certificate, and ultimately returns a common username to the user via the web page, then the user has to manually reenter it into the COnfD login page? If the common username is returned to the browser from the server, can you not use this in Javascript to then log in the user directly into ConfD? Conceptually you have to pass the user name and password into a client (northbound) interface. But I would think you can handle this as part of your custom browser application.

I guess I still need more understanding of your initial process.

- chris

dnetechno

unread,
Jun 2, 2014, 10:03:39 AM6/2/14
to confd-us...@googlegroups.com
I apologize for my poor explanations causing confusion.  If the certificate from the card is trusted, an https session is started and a custom web page/javascript prompts the user for username and password that will log the user into the ConfD webUI.  Also while validating the trust chain the common name is copied from the certificate (this is on the server side).  The problem is we do know of a way to input this common name to ConfD from the server side.  Currently it can be manually entered by the user from the client side and ultimately becomes Maapi_authenticate().  Our user does not want this and the user probalby does not know the common name, which can be long and not human friendly. 

In short, we want to start a ConfD webUI session from the server side.  Maapi_authenticate() method from the server side.

chriss

unread,
Jun 2, 2014, 12:29:34 PM6/2/14
to confd-us...@googlegroups.com
I'll return to my previous suggestion. On the server side, when you start the custom https session (login page), you could potentially retrieve the common name cached on the server and pre-populate the web form with the common name derived at the time the card was authenticated.You'd use a cgi script to fetch it from the server,  invoked by custom javascript code which is embedded in a custom login page. So, in reality it would still be done by the client using maapi_authenticate.I think you have to do the authentication on the client no matter how you approach it, because the auth info needs to reside in the client browser session. - chris
Reply all
Reply to author
Forward
0 new messages