On Fri, 4 Mar 2005 14:30:32 +0100 Bjorn Ove Grotan <bjorn.grotan(a)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(a)duke.cc.uit.no>
<200502230126.54149.kreide(a)online.no>
Message-ID: <011101c522f6$65073ec0$9601a8c0(a)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