irods Security Aspects Willem Elbers CLARIN-ERIC, Netherlands

Transcription

1 irods Security Aspects Willem Elbers CLARIN-ERIC, Netherlands Utrecht,28-29 April 2014

2 Contents Client / Server connections Authentication Within Zone Across Zone Authorization EUDAT B2ACCESS

3 Client / Server connections Image provided by Ton Smeele

4 System port Default: 1247 Client / Server connections Data communication range Default: Optional Database port LDAP authentication: port 636 irods Web Browser: HTTP(S) 80/443

5 Client Authentication Users can authenticate to their home zone in different ways: Default: username/password Since irods 1.0? Users can use the dedicated irods credentials to authenticate with irods PAM with LDAP, Kerberos, Since irods 3.2 Users can use their system credentials to authenticate with irods Kerberos was available standalone since irods 2.1 GSI (Grid Security Infrastructure) Both the clients and servers need to be built with GSI User can use X.509 certificates to authenticate with irods Note: no easy access to attributes in the certificate

6 Client / Server connections client zone1 /zone1 /collection1 /collection2 node1 node2 node3

7 Client / Server connections client zone1 /zone1 /collection1 /collection2 node1 node2 node3

8 Server Authentication: Within Zone A user can authenticate to any server in the irods zone Only the icat enabled server (IES) stores user credential information What happens if a user authenticates to a non-ies? The non-ies will connect to the IES to perform the authentication Use a localzonesid (shared secreted between all irods servers) to make this a little bit more secure than just trusting DNS <3.3.1 only a warning in the log file, >= authentication will fail

9 2.2 response user: willem proxy: willem authenticated: no_user_auth(0) local_user_auth(2) Client 2.1 challenge Non icat Enabled Server 1.1 authenticate willem Auth flag values: no_user_auth(0), remote_user_auth(1), local_user_auth(2), remote_priv_user_auth(3), local_priv_user_auth(4) (opt.) Verify localzonesid 3.1 Verify challenge/response 3.2 Authenticated? yes/no 4.1 authenticate 5.1 challenge 5.2 response Local and remote refer to local or remote zones. "priv" or not indicates whether or not the user is an irods admin. icat Enabled Server user: null willem proxy: null rodsadmin Authenticated: no_user_auth(0) : local_user_auth(2) icat

10 Challenge response irods authentication: Response: MD5 hash of (challenge+password) icat server can verify this by generated the same hash based on credential information stored in the icat OS level authentication (e.g. PAM): Response: MD5 hash of(username, uid, challenge, shared secret) Each of these components come from a trusted source, the uid being the systems user id set by the OS level authentication

11 Client / Server connections client zone1 zone2 /zone1 /collecson1 /collecson2 /zone2 /collecson1 /collecson2 node1 node2 node3 node1 node2

12 Server Authentication: Across Zone When accessing a remote zone, the user is actually authenticated against his/her home zone No sensitive user information is distributed Only works if the remote zone connects to the correct home zone, again DNS is trusted by default. Configure a RemoteZoneSid in the remote zones, which matches the LocalZoneSid of the users home zone. LocalZoneSid qwerty123 RemoteZoneSid tempzone-qwerty123 The server IDs can be scrambled (using iadmin spass), but this doesn t add security Only prevents clear text passwords in the log files

13 iadmin mkzone vzrzge host:port iadmin mkuser eudat#vzrzge rodsuser iadmin mkzone vzmpi host:port iadmin mkuser latuser#vzmpi rodsuser /vzrzge eudat#vzrzge latuser#vzmpi rods#vzsara latuser#vzmpi Federated Data Grid: iadmin mkzone vzsara host:port iadmin mkuser rods#vzsara rodsuser eudat#vrzge rods#vzsara /vzmpi /vzmpi /vzrzge /vzsara iadmin mkzone vzrzge host:port iadmin mkuser eudat#vzrzge rodsuser iadmin mkzone vzsara host:port iadmin mkuser rods#vzsara rodsuser iadmin mkzone vzmpi host:port iadmin mkuser latuser#vzmpi rodsuser /vzsara rods#vzsara latuser#vzmpi eudat#vrzge

14 Authorization: Data Objects The default approach to restrict access to data objects in an irods zone, is by setting ACLs on collections or data objects Modify ACLs (rods admin) with: ichmod Look at ACLs with: ils -A Set ownership, read and write permission on data objects Set inheritance on collections When collections have this attribute set, new dataobjects and collections added to the collection inherit the access permissions (ACLs) of the collection

15 Authorization: Data Objects Implement policies as rules, triggered by irods Policy Enforcement Points (configured in core.re) acpreprocfordataobjopen acpreprocforcollcreate acpreprocforcreate. With the policy enforcement points you can also restrict access to execution of rules

16

17 liu.se ceda.ac.uk dkrz.de B2SHARE B2SAFE OpenID Bridge DFN federason OAuth authorisason server access token Gateway portal B2STAGE CLARIN IDP Unity IdenSty Management Unity / federason database X.509 Google FederaSon User CerSficaSon Authority SAML B2DROP EUDAT Core AAI FuncSons EUDAT Resources 17

18 OpenID Unicore Unity Contrail google MulS (LoA) SAML AuthorizaSon Server CA IDP 1 IDP 2 IDP n SAML ldap DB DN: EUDAT uid Attributes: Community uid

19 Conclusion Default authentication mechanism works out of the box and easy to use, but not scalable With PAM/LDAP or X.509 authentication can be better integrated into existing infrastructure Users must be created in all zones where ACLs should be set irods communication over the wire is not encrypted Sometimes hashed values are used With PAM authentication, the iinit session (client - server) can be encrypted 19

20 Questions Thank you for your attention

21 Authentication: Authorization: PAM: