On Fri, 4 Mar 2005 14:30:32 +0100 Bjorn Ove Grotan bjorn.grotan@itea.ntnu.no wrote:
Vegard Vesterheim:
Are there any possibilities to use an external authentication mechanism in NAV. In UNINETT, we are looking at so-called single-sign-on solutions for web applications. In our setup, the authentication process can be performed by the web server, not by the web applications. We have implemented this by hooking custom authentication methods into the Apache request cycle.
Authentication is handled by subsystem/webFront/lib/nav/web/auth.py and likewize with authorization: subsystem/lib-python/src/nav/auth.py The authenticationmodule is initiated from subsystem/webFront/lib/nav/web/__init__.py in function headerparserhandler.
There's a file ldapAuth.py for example on how to use ldap as external source of authentication. We used this internally for testing for a while, but had to let it go because of broken openssl/openldap in RedHat Linux.
Hmm, either I am misunderstanding your response, or you misunderstood my question. I would like to implement 'single-sign-on' (log in once, get access to several services), but you talk about a 'shared userdatabase', this is not the same thing. You say that one can have alternative authentication mechanisms *within* NAV, this is nice, but I don't want that. I would like for NAV to *not do authentication at all*, but instead rely on 'higher powers' (in my case: Apache) to do this. In principle this would imply skipping the local authentication handling in NAV altogether. Apache does the authentication part, and NAV picks up the authenticated username and just does the authorization.
I don't remember the specifics anymore, but I think we added some functionality to first try ldap, then local database if ldapAuth was used.. maybe someone else can comment on this?
Well, a kind of fallback mechanism with a local userdatabase in NAV could be useful. For instance if the central login-service is unavailable, a local emergency fallback could be helpful.
I realize that in order for authorization to be performed correctly, the user must probably be registered in NAV as well, but this is another issue altogether. My main interest is avoiding the extra username/password dialog in NAV.
The NAV userdatabase using ldapAuth mentioned above, also has a means for describing where the source of this user credentials come from, so you can have - say all your organization in ldap where they update their passwords in ldap - and store external users and testusers inside the NAV database.
In case anyone is wondering about relations with the FEIDE project: This is only partly related to FEIDE, the issue should be of general interest.
I was thinking of making python-bindings to Moria, but I haven't had the time yet. Not mainly for this system, but for similar use.
OK, this is a different matter altogether, but we have done some very preliminary experimentation with this. We have been able to talk to Moria services via Python SOAP modules. Let me know if this is of any interest to you.
But again, I am not asking how to *add* functionality to NAV, rather I am asking how to *remove* functionality so that one could use a single-sign-on solution.
- Vegard -
From odd.hauge at himolde.no Mon Mar 7 10:16:49 2005
From: odd.hauge at himolde.no (Odd Arne Hauge (HSM)) Date: Mon Mar 7 10:16:54 2005 Subject: [Nav-users] Cricket and interface description for giga-router-interfaces, and some problems with HP 5308 switches References: 20050222104551.H42633@duke.cc.uit.no 200502230126.54149.kreide@online.no Message-ID: 011101c522f6$65073ec0$9601a8c0@molde.bravida.no
Hi.
Getting the description for giga-router-interfaces in cricket: # diff /usr/local/nav/cricket/cricket-config/giga-router-interfaces/.nav /usr/local/src/nav/nav-3.0_beta10/subsystem/statTools/cricket/cricket-config/giga-router-interfaces/.nav 15c15 < descr = select nettype,netident from gwportprefix left join prefix using (prefixid) left join vlan using (vlanid) where gwportid=$id and netident is not null ---
descr = select nettype,netident from gwport left join prefix using (prefixid) left join vlan using (vlan) where gwportid=$id and netident is not null
I'm also having some problems with HP5308XL Switches. This is a layer 3 switch, but it seems like Nav is unable to detecet the router-interfaces for the box and the vlans.
Another minor issue is in the report. When you select Core Switches the report lists all the switches, also the switches defined as GSW type. But when you select the report Core Switch Ports no switch ports from boxes defined as GSW are listed.
Regards Odd Arne Hauge