JobScheduler Security

Transcription

1 JobScheduler - Job Execution and Scheduling System JobScheduler Security March 2015 March 2015 JobScheduler Security page: 1

2 JobScheduler Security - Contact Information Contact Information Software- und Organisations-Service GmbH Giesebrechtstr. 15 D Berlin Germany Telephone +49 (0) Telefax +49 (0) Mail info@sos-berlin.com Web Last Updated: 03/20/ :00 PM This documentation is based on JobScheduler Version Copyright SOS GmbH Berlin. All rights reserved. All trademarks or registered trademarks are the property of their respective holders. All information and materials in this book are provided "as is" and without warranty of any kind. All information in this document is subject to change without further notice. This product includes software developed by the Apache Software Foundation ( We would appreciate any feedback you have, or suggestions for changes and improvements; please forward your comments to info@sos-berlin.com. March 2015 JobScheduler Security page: 2

3 JobScheduler Security - Table of Contents Table of Contents 1 Installation Configuration of shiro Authentication and Authorization with JID JobScheduler command rest service Glossary March 2015 JobScheduler Security page: 3

4 JobScheduler Security - Installation 1 Installation The SOS Security Server is running as a servlet in a jetty webserver. You can use a running JobScheduler Instance to start a jetty webservice. To enable the SOS Security Server you have to modify the file $scheduler_data/config/web.xml To enable the JobScheduler command rest service plugin in JobScheduler, please add the plugin in the plugin section of the file $scheduler_data/config/scheduler.xml After the <security> element: <plugins> <plugin java_class="com.sos.scheduler.engine.plugins.jetty.jettyplugin"> <plugin.config/> </plugin> <plugin java_class="com.sos.jobscheduler.tools.webservices.soscommandsecurityplugin"> <plugin.config/> </plugin> </plugins> Example: Activating Jetty plugin in JobScheduler To enable the JobScheduler Security Server in the Jetty webservice running in a JobScheduler instance please add this in the file web.xml. <servlet> <servlet-name>jersey REST Service</servlet-name> <servlet-class>com.sun.jersey.spi.container.servlet.servletcontainer</servlet-class> <init-param> <param-name>com.sun.jersey.config.property.packages</param-name> <param-value>com.sos.auth.rest</param-value> </init-param> <load-on-startup>0</load-on-startup> </servlet> <servlet-mapping> <servlet-name>jersey REST Service</servlet-name> <url-pattern>/rest/*</url-pattern> </servlet-mapping> Example: Activating JobScheduler security service in web.xml You also need a file shiro.ini in the classpath of the JobScheduler instance. The most basic shiro.ini file is [users] root = root, all [roles] all = sos:products Example: Basic shiro.ini file With this file you define a user root with the password root and the role all. The role all has all permissions starting with sos:products. To add the file to the class_path, please open the file $scheduler_home/config/factory.ini. Locate the class_path definition March 2015 JobScheduler Security page: 4

5 JobScheduler Security - Installation [java] class_path = c:/shiroini;c:/development/products/jobscheduler/jobscheduler-web-services/target/jobscheduler-web-services jar;$ {SCHEDULER_HOME}/lib/*.jar;${SCHEDULER_HOME}/lib/hibernate/*.jar;${SCHEDULER_HOME}/lib/jetty_ext/*.jar;${SCHEDULER_HOME }/lib/log/nop/*.jar;${scheduler_home}/lib/log/logback/*.jar Example: Class_path in the file factory.ini Please add a directory to the class_path, e.g. c:\shiroini. Save the file shiro.ini into this directory and restart JobScheduler To check whether the service is running you can use this url (Please use the actual values for host and port The answer should be <SOSPermissionShiro/> Example: Basic shiro.ini file To enable the login in JID there must be a record in the table scheduler_instances with the following values If there are more than one record in the table scheduler_instances with is_command_webservice=1 the first one found will be used. If it is not possible to connect to this JobScheduler instance or if the security server specified in this instance is not available, the next JobScheduler instance with is_command_webservice=1 will be used. The $scheduler_data\config\scheduler.xml file of this JobScheduler instance must define a parameter to setup the JobScheduler security server. <param name="security_server_address" value=" Example: Enabling the login in JID March 2015 JobScheduler Security page: 5

6 JobScheduler Security - Configuration of shiro 2 Configuration of shiro shiro will be configured with the file shiro.ini found in the class_path. This file specifies the realm with which the authentication and the authorization will be done. Authentication The authentication will be done by a user name password combination. Authentication method There are three available authentication methods authentication against a database authentication against ldap authentication against a shiro.ini file Configuration with Hibernate To enable the Hibernate Realm, the following shiro.ini must be found in the classpath [main] hibernaterealm = com.sos.dialog.auth.soshibernateauthorizingrealm hibernaterealm.hibernateconfigurationfile=c:\users\nn\documents\sos-berlin.com\jobscheduler\scheduler_current\config\hi bernate.cfg.xml securitymanager.realms = $hibernaterealm cachemanager = org.apache.shiro.cache.memoryconstrainedcachemanager securitymanager.cachemanager = $cachemanager Example: shiro.ini for Hibernate realm The information containing users, roles and right are stored in the following tables March 2015 JobScheduler Security page: 6

7 JobScheduler Security - Configuration of shiro Table with user and passwords. CREATE TABLE SOS_USER ( "ID" NUMBER(9,0), "SOS_USER_NAME" VARCHAR2(250 BYTE), "SOS_USER_PASSWORD" VARCHAR2(250 BYTE), primaray key("id") ) /*MD5 Hash*/ Directly assigned rights to roles or users. CREATE TABLE SOS_USER_RIGHT ( "ID" NUMBER(9,0), "ROLE_ID" NUMBER(9,0), "USER_ID" NUMBER(9,0), "SOS_USER_RIGHT" VARCHAR2(250), primaray key("id") ) Table with roles CREATE TABLE SOS_USER_ROLE ( "ID" NUMBER(9,0), "SOS_USER_ROLE" VARCHAR2(250 BYTE), primaray key("id") ) Assignment of roles to users CREATE TABLE SOS_USER2ROLE ( "ID" NUMBER(9,0), "USER_ID" NUMBER(9,0), "ROLE_ID" NUMBER(9,0), primaray key("id") ) Example: Database tables for Hibernate realm Configuration with LDAP To enable the Realm LDAP, the following shiro.ini must be found in the classpath In the LDAP Realm it is not possible to assign rights directly to an user. The user in LDAP will have a password which is be used for authentication. The user also will be assigned to shiro role. The mapping between shiro role and permissions is specified in the shiro.ini file. The [roles] section specifies the assignment of rights to roles March 2015 JobScheduler Security page: 7

8 JobScheduler Security - Configuration of shiro [main] ldaprealm = com.sos.dialog.auth.sosldapauthorizingrealm ldaprealm.userdntemplate = cn={0},ou=ehp,cn=manager,dc=my-domain,dc=com ldaprealm.searchbase = ou=ehp,cn=manager,dc=my-domain,dc=com ldaprealm.contextfactory.url = ldap://<server>:<port> ldaprealm.groupnameattribute=cn ldaprealm.usernameattribute=sn #Mapping of a ldap group to roles. You can assign more than one role with the seperator sign ldaprealm.grouprolesmap = "<user1>":"<role1> <role2>", \ "<user2>":"<role>" rolepermissionresolver = com.sos.dialog.auth.sospermissionresolveradapter rolepermissionresolver.ini = $inirealm ldaprealm.rolepermissionresolver = $rolepermissionresolver securitymanager.realms = $ldaprealm cachemanager = org.apache.shiro.cache.memoryconstrainedcachemanager securitymanager.cachemanager = $cachemanager securitymanager.sessionmanager.globalsessiontimeout = [roles] <role1> = <permission1>, <permission2> <role2> = <permission1>, <permission2> Example: shiro.ini for LDAP realm Configuration with Ini File It is possible to specify users, roles and passwords in the shiro.ini file without using ldap or a database. The list of users in the section [users] asssigns each user a password (first item after assign sign) and a list of roles. In the section [roles] is a list of roles which have a comma seperated list of permissions. March 2015 JobScheduler Security page: 8

9 JobScheduler Security - Configuration of shiro [users] root = secret, jobscheduler_dashboard_admin ur = ur, joc, joe joe = joe, joe, jid guest = guest [roles] admin = sos:products:jid:joe,sos:products:jid:joc,sos:products:jid:events jobscheduler_dashboard_admin = sos:products:jid:* joc = sos:products:jid:joc joc_admin = sos:products:jid:joc:* joe = sos:products:jid:joe events = sos:products:jid:events jobnet = sos:products:jid:jobnet March 2015 JobScheduler Security page: 9

10 JobScheduler Security - Configuration of shiro Example: shiro.ini for INIFILE realm March 2015 JobScheduler Security page: 10

11 JobScheduler Security - Authentication and Authorization with JID 3 Authentication and Authorization with JID Authentication The authentication will be done by a user name password combination. When starting JID there comes up a form with two fields to identify against the underlying authentication method Authorization A user in JID can have severall roles. Each role can be assigned several rights. With hibernate realm it is also possible to assign rights explicitly to a user. JID knows the roles: JID: To be able to start JID JOE: To see the JOE view JOC: To see the JOC view EVENTS: To see the Events view JOBNET: To see the Jobnet view You can assign additional rights to the following roles. admin joc_admin jobeditor controller workingplan JID knows the rights sos:product:jid:execute To be able to start JID sos:product:jid:joetab:show To see the JOE view sos:product:jid:joctab:show To see the JOC view sos:product:jid:eventtab:show To see the Events view sos:product:jid:jobnettab:show To see the Jobnet view sos:product:jid:jobstart To be able to start jobs and job chains Rights can be specified with wildcards. The right sos:products:jid:* includes all rights starting with sos:products:jid: You can enable a wanted function in JID either by assigning a role or a right to a user. A right can be assigned directly to a user (only hibernate realm) or indirectly to a user by assigning the right to a role which is then assigned to the user. Configure the JobScheduler Security Server The authentication and authorization will be done by the JobScheduler Security Server. This is a REST webservice that can run in a Jetty webserver e.g. within a JobScheduler instance. in the dashboard.cmd sh start script you have to specify the adress of the jetty server March 2015 JobScheduler Security page: 11

12 JobScheduler Security - Authentication and Authorization with JID -scheduler_id= The $scheduler_data\config\scheduler.xml file of the given scheduler_id must contain the parameter to find the security server to use. where host is the host name of the jetty server and port is the port for the jetty server will be read from the table scheduler_instances. The $scheduler_data\config\scheduler.xml file of this JobScheduler instance must define a parameter to setup the JobScheduler security server. <param name="security_server_address" value=" Example: Enabling the login in JID March 2015 JobScheduler Security page: 12

13 JobScheduler Security - JobScheduler command rest service 4 JobScheduler command rest service When the JobScheduler command Restservice is enabled you can execute commands using rest service urls with http post. The command executer needs a valid login done in the SOS Security server. T h e c o m m a n d e x e c u t e r p l u g i n w i l l b e i n s t a l l e d b y a d d i n g t h e p l u g i n i n t h e f i l e $scheduler_data/config/scheduler.xml <plugin java_class="com.sos.jobscheduler.tools.webservices.soscommandsecurityplugin"> <plugin.config/> </plugin> Example: Activating Command Executer plugin in JobScheduler Here is a list of known commands /plugin/security/login /plugin/security/logout /plugin/security/is_enabled /plugin/security/start_job /plugin/security/modify_order /plugin/security/add_order /plugin/security/job_chain /plugin/security/job_chain_modify /plugin/security/job_chain_node_modify /plugin/security/kill_task /plugin/security/modify_job /plugin/security/modify_spooler /plugin/security/process_class /plugin/security/process_class_remove /plugin/security/consumes /plugin/security/remove_job_chain /plugin/security/remove_order /plugin/security/lock /plugin/security/lock_remove /plugin/security/terminate Parameters March 2015 JobScheduler Security page: 13

14 JobScheduler Security - JobScheduler command rest service Command: /start_job job at force name params Command: /modify_order job_chain order action at end_state priority setback state suspended title params runtime Command: /add_order job_chain order at end_state priority replace state title web_service params runtime Command: /job_chain distributed max_orders name orders_recoverable title visible Command: /job_chain_modify job_chain state Command: /job_chain_node_modify job_chain action state Command: /kill_task id immediately job Command: /modify_job job cmd Command: /modify_spooler cmd March 2015 JobScheduler Security page: 14

15 JobScheduler Security - JobScheduler command rest service timeout Command: /process_class scheduler_id name remote_scheduler replace max_processes Command: /process_class_remove process_class Command: /remove_job_chain job_chain Command: /remove_order job_chain order Command: /lock max_non_exclusive name Command: /lock_remove lock Command: /terminate all_schedulers continue_exclusive_operation restart timeout Command: /login user password Command: /logout Example: Parameters for Command Executer The command executer uses the security server configured with the param security_server_address in the file $scheduler_data/config/scheduler.xml The answer of the command executer is xml March 2015 JobScheduler Security page: 15

16 JobScheduler Security - JobScheduler command rest service <sos_security_webservice_answer> <isenabled>true</isenabled> <jobscheduleranswer/> <message> user: root, password: ********, resource: --> authenticated </message> <resource> </resource> <sessionid>607932d aa4c-d a61a</sessionid> <user>root</user> </sos_security_webservice_answer> Example: Answer of the command executer The login provides a session id which must be used with all commands to get the authorization for the command March 2015 JobScheduler Security page: 16

17 JobScheduler Security - Glossary Glossary Job Chains Jobs JOC (JobScheduler Operations Center) JOE (JobScheduler Object Editor) Orders A series of jobs that process orders one after the other. The JobScheduler starts the jobs in a job chain automatically, once a order has been started for the chain. Job chains allow a number of orders to be processed in parallel, by starting multiple instances of jobs (tasks). Programs and scripts that are executed by the JobScheduler have to be embedded in jobs. Jobs can contain either start executable files or contain job scripts that use the JobScheduler program interface. More than one instance of a job (task) may run at any one time, should this be required to scale performance. There are two types of jobs: standalone and order jobs. Whereas order jobs are started by orders within a job chain, standalone jobs can be started independently: either manually, scheduled or by directory monitoring. Standalone jobs cannot be run in job chains. JOC (JobScheduler Operations Center) is the JobScheduler interface for monitoring and controlling JobScheduler objects such as jobs, job chains and orders. JOC is opened in a web browser using the address where [scheduler_host] and [scheduler_port] are the host name and the TCP ports number of the JobScheduler (e.g. JOE is the JobScheduler Object Editor. This is used to configure JobScheduler objects (jobs, job chains, orders, schedules, process classes and locks). JOE is started using the script: $SCHEDULER_HOME \bin\jobeditor.cmd (Windows ) $SCHEDULER_HOME /bin/jobeditor.sh (Unix ) Orders activate the processing of job chains. Orders may also contain parameters for the jobs in a job chain. Every job in a job chain has access to the order parameters. Order parameters overwrite job parameters of the same name. Orders can be started according to time. An order processes the jobs in a job chain one after the other. Orders can be configured so that, if a error in processing a job occurs, the order... is removed from the job chain; continues with a further job in the chain; continues with the job that caused the initial error being repeated stands still - that is the order processing is suspended until it is restarted manually. March 2015 JobScheduler Security page: 17

18 JobScheduler Security - Glossary Schedules Time-based starting of jobs or orders can either be directly specified for each job or order or can be delegated to a schedule. Individual jobs or orders are then referred to this schedule. This means that if several jobs or orders have the same start parameters, these need only be specified once in the schedule. In addition, one schedule can be replaced by another for a particular period of time, thereby increasing the flexibility of setting job and order start parameters. March 2015 JobScheduler Security page: 18