SINDES2 AuthN & AuthZ libraries

SINDES2AuthN & AuthZ libraries Jan Dudziec & Ivan Fedorko IT/CF/ASI

Outline • Glossary • Purpose of SINDES • SINDES1 • SINDES2 • AuthN & AuthZ libraries • Summary 2

Glossary • SINDES – Secure Information Delivery System • SINDES1 – in production since 2005 • SINDES2 – currently under testing • Node – a machine in Computer Centre • User – a human • Item – confidential sensitive file stored with SINDES 4

Purpose of SINDES Main goal: Securely store & deliver confidential and sensitive information Important factor: Consistency with Quattor / CDB 6

Purpose of SINDES (1) Secure connection Authenticated client SINDES Server Passwd-header for Cluster A Cluster A Node A1 Node A2 Node A3 Secure storage Content created on the server 7

Purpose of SINDES (2) SINDES Server Top secret config file Cluster A Node A1 Node A2 Node A3 8

Purpose of SINDES (2) SINDES Server Top secret config file Cluster A Node A1 Node A2 New Node A4 – consistency with CDB Node A3 Node A4 9

Outline • Glossary • Purpose of SINDES • SINDES1 • Overview • Limitations • Enhancements • Why to replace • Replacement ideas • SINDES2 • AuthN & AuthZ libraries • Summary 10

SINDES1 Overview Developed in 2005 by Marc Poulhies supervised by VladoBahyl Used by all the Quattor managed machines at CERN (>8.000) Architecture: • Authentication & authorization: • user by Kerberos; • node by X.509 certificates ( build-in Certificate Authority ) • Transfer over HTTPS • Items stored in folder related to node name and cluster cluster / node / item.tar.gz or cluster / item.tar.gz • Extended server side script mechanism • Configuration stored in CDB only 11

SINDES1 Limitations (1) Missing features: • User can not view / modify / download / delete items • No item versioning • Node can not upload items • Fixed file hierarchy structure: • Only two levels: cluster and node (also subcluster needed) • No mechanism to move a machine between clusters 12

SINDES1 Limitations (2) Missing features: • Unattended (fully automated) installation impossible • Time window has to be opened for a new machine • Some scripts require categories (passwd-header for different OS) • Only one SINDES system user • anybody with the access may tamper any file store with SINDES You have access to SINDES = you can modify every item of any node/cluster • no user information in log files 13

SINDES1 Limitations (2) Missing features: • Unattended (fully automated) installation impossible • Time window has to be opened for a new machine • Some scripts require categories (passwd-header for different OS) R Only one SINDES system user • anybody with the access may tamper any file store with SINDES You have access to SINDES = you can modify every item of any node/cluster • no user information in log files 14

SINDES1 Enhancements Two things have been improved (2011): • Now SINDES stores user KRB name in logs • Access control: one can change an item that belongs to node / cluster only if: • is root on the node / all nodes in the cluster, or • is LanDB responsible or main user of the node / all nodes in the cluster we fixed one missing feature 15

Why to replace SINDES1? 16

SINDES1 Replacement ideas In October 2010 we were considering: • Enhance the usability and security in the current version of the system • Find and adopt a new tool, keep the functionality Freeware tools: i.e. wallet by Russ Allbery http://www.eyrie.org/~eagle/software/wallet/ • Investigate new concept and develop the tool People outside of CERN (several Quattor sites) are using SINDES1 and are interested in new features 17

SINDES1 Replacement ideas • Investigate new concept and develop the tool 18

Outline • Glossary • Purpose of SINDES • SINDES1 • SINDES2 • Basic concept • New features • Architecture • Deployment • AuthN & AuthZ libraries • Summary 19

SINDES2 Basic concept • Replace certificates with Kerberos tokens • Delegate authentication to common service • Still provide certificates for other services (server side script) • Use internal DB for configuration • Be independent from (but compatible with) Quattor / CDB • Flexible structure • A single item can be assigned to different levels of hierarchy • Hierarchy can be extended by new levels (e.g. scope: service) • One interface for user and node • Finally users and nodes can do the same operations 20

SINDES2 New features (1) All the features missing in SINDES1 are now satisfied • User can view / modify / download / delete items • Item versioning • Node can upload items • Flexible file hierarchy structure: • One item may go to any node, subcluster, cluster at the same time • Node move between clusters is no longer a problem • Unattended (fully automated) installation is possible • passwd-header for different OS may be distinguished using subclusters now 21

SINDES2 New features (2) 22

SINDES2 Architecture 23

SINDES2 Deployment • In July 2011 we will have • SINDES2 on Quattor Sourceforge with Apache 2.0 License (KTT) People from Quattor Community willing to test and adopt the project • SINDES2 installed on preproduction server • SINDES2 CDB template and ncm component • At least one machine using it • Future deployment will be defined once the test phase is completed • Final deployment strategy: • Move all items from SINDES1 to SINDES2 (tool will be provided) • Block upload in SINDES1 • Change main CDB template of SINDES to use SINDES2 • Use fail-safe ncm component to get data from SINDES2 or if impossible from SINDES1 24

AuthN&Z CERN use cases • Authentication – how client is proving its identity to server • SINDES1, CDB – based on certificates • Lemon – public and private key digest (from SINDES1) • SSH – based on KRB ticket • SINDES2 – based on KRB ticket • AIMS – based on KRB ticket • Authorization – identify user privileges • Check root in CDB • Check LanDB responsible/main user in LanDB • Check e-group membership Logic used by: SINDES1, SINDES2, AIMS 26

AuthN library What we propose: high level PERL wrapper library for perl-KRB5-lib • Simple object oriented interface • Simple error handling Reason: • perl-krb5-lib is complex library for general purpose • perl-krb5-lib requires a lot of code for proper error handling 27

AuthZ library What we propose: high level object oriented PERL library to query: RCDB RLanDB R ActiveDirectory (e-groups) • Simple object oriented interface • Simple error handling Reason: • There are no PERL libraries to implement these queries • Developer must implement raw SQL/SOAP queries 28

AuthN & AuthZ Conclusions We know that Proposed AuthN and AuthZ libraries are nothing new However it • is less complex and easier to use AuthN:J 3 lines of code instead of >60 L AuthZ: J3 lines of code instead of >100 L • has proper error handling inside the library Additional benefits • less lines of code = reduced development time • easier to maintain code relaying on common library • easier to ensure security and avoid mistakes Endorsed by Security Team! 29

AuthN library example • Client use CERN::KrbAuthN; my $krb = CERN::KrbAuthN->get_instance(); my $ticket = $krb->get_ticket(“sindesdev02.cern.ch”, “http”); send($ticket); • Server use CERN::KrbAuthN; my $krb = CERN::KrbAuthN->get_instance(); $krb->set_custom_keytab(“/etc/krb5.keytab.apache”); my $ticket = receive(); $principal = $krb->decode_ticket($ticket, “http”); print $principal{name}.”\@”. $principal{realm}; 30

AuthZ library example • CDB use CERN::AuthZ::CDB; $cdb = CERN::AuthZ::CDB->new(‘cdb’,’usr’,’pwd’); $a = $cdb->is_root_on_node(‘jdudziec’,’sindesdev01’); $b = $cdb->is_root_on_cluster(‘jdudziec’,’lxserv’); • Egroups use CERN::AuthZ::ActiveDirectory; $ad = CERN::AuthZ::ActiveDirectory->new(’usr’,’pwd’); $a = $ad->is_user_in_egroup(‘jdudziec’,’test-egrp’); • LanDB use CERN::AuthZ::LanDB; $landb = CERN::AuthZ::LanDB->new(’usr’, ’pwd’, $ad, $cdb); $a = $landb->is_landb_on_node(‘jdudziec’,’sindesdev01’); $b = $landb->is_landb_on_cluster(‘jdudziec’,’lxserv’);

Summary • SINDES2 benefits • Easier to maintain • Uses standard technologies • Less code than in SINDES1 • Modular internal structure • Less administrative actions • Provides missing features • Convenient user interface • Flexible (and easy to modify) hierarchy structure – finally subcluster! • Versioning • Deployment after enhanced testing phase (with Quattor C.) • AuthN & AuthZ libraries are convenient and simple 33

Summary We would like to thank in particular to (in alphabetical order): • VladoBahyl– IT/DSS • Lionel Cons – IT/GT • Juan Manuel Guijarro– IT/PES • John Hefferman– IT/DSS • Jan Iven– IT/DSS • Sebastian Lopienski– IT/DI • Luis Fernando Munoz Mejias– IT/DI • JaroslawPolok– IT/OIS 34

Thank you We are waiting for your feedback! sindes-dev@cern.ch 35

Backup slides Backup slides 36

Main outline • SINDES2 • AuthN & AuthZ libraries 37

Purpose of SINDES Main goal: Securely store & deliver confidential and sensitive information SINDES1 requirements • Secure data (file) storage • Secure bidirectional file transfer between SINDES server and host / user • Authenticate nodes and users connecting to the system • Keeping consistency with CDB configuration of the host • Server side scripts creating content on the server side (passwd-header) 38

Main outline • SINDES2 • AuthN & AuthZ libraries 39

AuthN & AuthZ What is authentication? - “Tell me who you are” It is the act of confirming the truth of an attribute of a datum or entity. What is authorization? – “I tell what you can do” It is the function of specifying access rights to resources. 40

Authentication steps with Krb • Client steps • get TGT (ticket granting ticket) from KRB Server • ask for ticket for particular service • send the ticket to the server providing service • Server steps • get ticket • decode ticket with local keytab • extract user data from ticket 41

SINDES2 AuthN & AuthZ libraries