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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Vegard Vesterheim wrote:
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.
Although this type of authentication is not built in to NAV today, Bj?rn Ove has identified where to do it; follow the trail from subsystem/webFront/lib/nav/web/__init__.py in function headerparserhandler, which invokes the authentication module of NAV. Although the authentication bits aren't very modular today, they can easily be rewritten to take authentication tokens from the URL or from Apache headers.
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.
This is the reason why NAV performs the authentication step today, either through LDAP or locally. If it didn't, and the LDAP server (or another type of external authentication server) is unreachable, you will be unable to use NAV to debug the network problem, as you can't log in. If the Apache mechanism provides the fallback itself, that would be OK as well.
As a sidenote, regardless of whether NAV performs authentication against the local NAVdb or the remote LDAP, an entry for the user that logs in must be placed in the NAVdb. This entry is used to store user preferences and NAV authorization information. If you do create a third authentication method, you must also make sure to create NAVdb entries for new users that are authenticated through the external system.
- -- Morten Vold NTNU ITEA Integrasjonsgruppen
From Vidar.Faltinsen at uninett.no Mon Mar 7 13:38:07 2005
From: Vidar.Faltinsen at uninett.no (Vidar Faltinsen) Date: Mon Mar 7 13:38:24 2005 Subject: [Nav-users] brake-up Advanced Search web-page In-Reply-To: s2283141.016@HVO-3.hivolda.no References: s2283141.016@HVO-3.hivolda.no Message-ID: Pine.LNX.4.61.0503071331070.32236@valentin.uninett.no
On Fri, 4 Mar 2005, Peder Magne Sefland wrote:
We have put description on many of our swichports, and we want to search on portname.
The only way to do this (so fare I can see) is to go to Home > Report
Switchports and then click on the Advance Search.
But on this page you'll have to scrool sideways pretty long before you find the portname-field
I consider this a bug in the report system, where the advanced page looks very messy in variuos browsers and make it hard to use. Probably an easy fix... Morten?
The best thing would be a field-search in the /report -page
Something like this maybe
Reports
IP Device Center Room search Device search Switchports w/vlan Portname
This is also a good idea. Searching for portnames is an often used feature!
Be aware however that NAV is competing with itself in this matter; another tool, Network Exlorer gives you the ability to search for portnames. Maybe this will be of help?
- Vidar
On Mon, 07 Mar 2005 10:20:36 +0100 Morten Vold morten.vold@ntnu.no wrote:
Vegard Vesterheim wrote:
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.
Although this type of authentication is not built in to NAV today, Bj?rn Ove has identified where to do it; follow the trail from subsystem/webFront/lib/nav/web/__init__.py in function headerparserhandler, which invokes the authentication module of NAV. Although the authentication bits aren't very modular today, they can easily be rewritten to take authentication tokens from the URL or from Apache headers.
OK, considering my limited python skills, and my total unfamiliarity with the NAV source code, I suspect that this rewriting will not be so 'easily' done, but thanks for the hints anyway. I'll take a quick stab at it soon, and report my findings back to the list.
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.
This is the reason why NAV performs the authentication step today, either through LDAP or locally. If it didn't, and the LDAP server (or another type of external authentication server) is unreachable, you will be unable to use NAV to debug the network problem, as you can't log in. If the Apache mechanism provides the fallback itself, that would be OK as well.
Yes, the authentication mechanism needs to be very robust.
As a sidenote, regardless of whether NAV performs authentication against the local NAVdb or the remote LDAP, an entry for the user that logs in must be placed in the NAVdb. This entry is used to store user preferences and NAV authorization information. If you do create a third authentication method, you must also make sure to create NAVdb entries for new users that are authenticated through the external system.
Yes, the user-databases needs to be synchronized, but this could be automated and should be transparent for the end user.
- Vegard -
From Vidar.Faltinsen at uninett.no Mon Mar 7 14:09:56 2005
From: Vidar.Faltinsen at uninett.no (Vidar Faltinsen) Date: Mon Mar 7 14:10:01 2005 Subject: SV: RE: [Nav-users] vlan information from cisco switches In-Reply-To: s226f859.067@HVO-3.hivolda.no References: s226f859.067@HVO-3.hivolda.no Message-ID: Pine.LNX.4.61.0503071348130.32236@valentin.uninett.no
On Thu, 3 Mar 2005, Peder Magne Sefland wrote:
In my nav3beta10 (debian) every switch shows vlan information on ports, except on my two cisco 2980.
model descr serial sw_ver hw_ver fw_ver WS-X2980GBRJ WS-X2980RJ 10/100BaseTx Ethernet Rev. 2.0 JAB05250BZH 5.5(18) 2.0 5.4(1)
model descr serial sw_ver hw_ver fw_ver WS-X2980GBRJ WS-X2980GBRJ 10/100/1000 Ethernet Rev. 1.2 JAB061906WQ 6.3(5) 1.2 6.1(4)
They are running CatOS, but my 5500 is also running CatOS and he is showing vlan information.
This is the information from the web-page /report/swport?b1.netboxid=38 interface module port link Mbps duplex media trunk vlan portname 2/17 2 17 y 100.0 h 0 UPS-Strom snmp
But the vlan information is collected, and I can find it tabell swport
swportid | moduleid | ifindex | port | interface | link | speed | duplex | media | vlan | trunk | portname | to_netboxid | to_swportid ----------+----------+---------+------+-----------+------+-------+--------+-------+------+-------+----------------+-------------+------------- 12069 | 824 | 25 | 17 | 2/17 | y | 100 | h | | 10 | f | UPS-Strom snmp | |
Any ideas?
Be aware that there is an additional table, swportvlan, that contains vlan informartion. It is this table that is used in the report, and I will explain why (Kristian can correct me if I am mistaking):
The gDD plugin that gathers swport data will find vlan values for all non-trunk ports along with other relevant swport data. This is what you see in the swport table.
In turn the networkdiscovery system detects the physical topology of your network. Based on the physical topology (with trunk port information) the vlandiscovery feature detects the actual deployment of the various vlans in your network. This latter process will fill data in swportvlan.
To be consistent, and thereby reveal vlan discovery bugs, we have decided to base the vlan information in the reports on the swportvlan information only (as a minimum we would anyway have to consult the table in order to retrieve vlan information for trunk ports).
My guess is that vlandiscovery is not running, or has a bug that effect you. Check:
1. is the requested information in the swportvlan table (probably not) 2. does "nav status" tell you that Networkdiscovery is running 3. is networkDiscovery-stderr.log updated reasently? does it give you a clue?
- Vidar
-
morten.vold＠ntnu.no -
Vegard.Vesterheim＠uninett.no