Thank Heikki, My main requirement is to implement an ACL (Accept/Reject) based on source and destination of the request I know that Calling-Station-Id is a string, I'm "not satisfied" of this, but I did not find a better solution
The second requirement is to assign different roles to the a user based on some "esoteric rules" ... If requests arrive from A to B, the moon is in the Seventh House And Jupiter aligns with Mars... sometime a I hate sellers A simplified example OpsA: a my tech guy CustA: a customer user CustB: a customer user RotuerA: The Router in the customer office CustomerNet: customer's office network MyNet: my office network PublicNet: the internet To RotuerA OpsA should be to obtain the following permissions: - From MyNet -> FullAccess (usual business) - From CustomerNet -> FullAccess (in site assistance ) - From PublicNet -> ShowOnly (initial troubleshooting on "on call" from home) CustA: - From CustomerNet -> ShowOnly (they want it and sales guys sold it!!! ) - From PublicNet -> PingOnly (like above and I'll live some years less for this !!!) CustB: - From CustomerNet -> ShowOnly (like above) - From PublicNet -> REJECT Obviously I can ask to OpsA to use a different account form home but I can't do the same with the customer My idea is to add to the user profile VSAs with the tuple "source ; destination ; AuthorizeGroup" . Username = OpsA, ... My-ACL = MyNet;RotuerA;FullAccess, My-ACL = CustomerNet;RotuerA;FullAccess, My-ACL = PublicNet;RotuerA;ShowOnly Username = CustA, ... My-ACL = CustomerNet;RotuerA;ShowOnly, My-ACL = PublicNet;RotuerA;PingOnly Username = CustB, ... My-ACL = CustomerNet;RotuerA;ShowOnly . and user a Hook to override Access/Reject and return the AuthorizeGroup by matching My-ACL The Hook work quite fine but there was the "context problem" that override the AuthorizeGroup between the sessions Ok, probably it not be the normal business override the own credential but it could be happen. and it's a bug from the "Hook point of view" Any comments and suggestions are welcomed Cheers -- Fabio -----Messaggio originale----- Da: [email protected] [mailto:[email protected]] Per conto di Heikki Vatiainen Inviato: venerdì 15 marzo 2013 07:05 A: [email protected] Oggetto: Re: [RADIATOR] TACACS: context & Calling-Station-Id On 03/14/2013 06:18 PM, Fabio Prina wrote: > I'm developing a hook to return different "GroupMemberAttr" based on the > Calling-Station-Id and NAS-IP-Address of the request. > The same user from 2 different clients can has different permissions > but; "the context" is based only on NAS-IP-Address and this cause me > permissions override between sessions Hello Fabio, NAS-IP-Address gets its value from the TACACS+ TCP connection's peer IP address. Calling-Station-Id is an ascii string, possibly empty, that should describe where the user is coming from. See http://tools.ietf.org/html/draft-grant-tacacs-02 > So I patched the ServerTACACSPLUS.pm to be able to use also > Calling-Station-Id in the "context" This makes authorization different based on where the user is logging in from. Can you tell why you could not use two different user (role) names for different authorization rules. This would help to better understand the implications of this patch. > If needed in attach you can find my horrible patch I've added a > Parameter (flag) "RemoteInContext" to enable/disable the option Thanks, Heikki -- Heikki Vatiainen <[email protected]> Radiator: the most portable, flexible and configurable RADIUS server anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald, Platypus, Freeside, TACACS+, PAM, external, Active Directory, EAP, TLS, TTLS, PEAP, TNC, WiMAX, RSA, Vasco, Yubikey, MOTP, HOTP, TOTP, DIAMETER etc. Full source on Unix, Windows, MacOSX, Solaris, VMS, NetWare etc. _______________________________________________ radiator mailing list [email protected] http://www.open.com.au/mailman/listinfo/radiator _______________________________________________ radiator mailing list [email protected] http://www.open.com.au/mailman/listinfo/radiator
