JobScheduler - Job Execution and Scheduling System Software Open Source JobScheduler Security October 2014 October 2014 JobScheduler Security page: 1 JobScheduler Security - Contact Information Software Open Source Contact Information Software- und Organisations-Service GmbH Giesebrechtstr. 15 D-10629 Berlin Germany Telephone +49 (0)30 86 47 90-0 Telefax +49 (0)30 8 61 33 35 Mail [email protected] Web http://www.sos-berlin.com Last Updated: 10/24/2014 12:00 PM This documentation is based on JobScheduler Version 1.7.4169. Copyright © 2005-2014 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 (http://apache.org/) We would appreciate any feedback you have, or suggestions for changes and improvements; please forward your comments to [email protected]. October 2014 JobScheduler Security page: 2 JobScheduler Security - Table of Contents Software Open Source Table of Contents 1 Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2 Configuration of shiro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 3 Authentication and Authorization with JID . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 4 JobScheduler command rest service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 5 Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 October 2014 JobScheduler Security page: 3 JobScheduler Security - Installation Software Open Source 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 October 2014 JobScheduler Security page: 4 JobScheduler Security - Installation Software Open Source [java] class_path = c:/shiroini;C:/development/products/jobscheduler/jobscheduler-web-services/target/jobscheduler-web-services-1.7.0.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 http://localhost:40040/jobscheduler/rest/sosPermission/permissions (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="http://<host>:<port>"/> Example: Enabling the login in JID October 2014 JobScheduler Security page: 5 JobScheduler Security - Configuration of shiro Software Open Source 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 October 2014 JobScheduler Security page: 6 JobScheduler Security - Configuration of shiro Software Open Source 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 October 2014 JobScheduler Security page: 7 JobScheduler Security - Configuration of shiro Software Open Source [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 = 1800000 [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. October 2014 JobScheduler Security page: 8 JobScheduler Security - Configuration of shiro Software Open Source [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 October 2014 JobScheduler Security page: 9 JobScheduler Security - Configuration of shiro Software Open Source Example: shiro.ini for INIFILE realm October 2014 JobScheduler Security page: 10 JobScheduler Security - Authentication and Authorization with JID Software Open Source 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 October 2014 JobScheduler Security page: 11 JobScheduler Security - Authentication and Authorization with JID Software Open Source -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="http://<host>:<port>"/> Example: Enabling the login in JID October 2014 JobScheduler Security page: 12 JobScheduler Security - JobScheduler command rest service Software Open Source 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. The command executer plugin will be installed by adding the $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 October 2014 JobScheduler Security page: 13 plugin in the file JobScheduler Security - JobScheduler command rest service Software Open Source Command: /start_job |session_id| |job| |at| |force| |name| |params| Command: /modify_order |session_id| |job_chain| |order| |action| |at| |end_state| |priority| |setback| |state| |suspended| |title| |params| |runtime| Command: /add_order |session_id| |job_chain| |order| |at| |end_state| |priority| |replace| |state| |title| |web_service| |params| |runtime| Command: /job_chain |session_id| |distributed| |max_orders| |name| |orders_recoverable| |title| |visible| Command: /job_chain_modify |session_id| |job_chain| |state| Command: /job_chain_node_modify| |session_id| |job_chain| |action| |state| Command: /kill_task| |session_id| |id| |immediately| |job| Command: /modify_job| |session_id| |job| |cmd| Command: /modify_spooler| |session_id| |cmd| October 2014 JobScheduler Security page: 14 JobScheduler Security - JobScheduler command rest service Software Open Source |timeout| Command: /process_class| |session_id| |scheduler_id| |name| |remote_scheduler| |replace| |max_processes| Command: /process_class_remove| |session_id| |process_class| Command: /remove_job_chain| |session_id| |job_chain| Command: /remove_order| |session_id| |job_chain| |order| Command: /lock| |session_id| |max_non_exclusive| |name| Command: /lock_remove| |session_id| |lock| Command: /terminate| |session_id| |all_schedulers| |continue_exclusive_operation| |restart| |timeout| Command: /login| |user| |password| Command: /logout| |session_id| 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 October 2014 JobScheduler Security page: 15 JobScheduler Security - JobScheduler command rest service Software Open Source <sos_security_webservice_answer> <isEnabled>true</isEnabled> <jobSchedulerAnswer/> <message> user: root, password: ********, resource: http://host:port/jobscheduler/rest/sosPermission --> authenticated </message> <resource> http://host:port/jobscheduler/rest/sosPermission </resource> <sessionId>607932d1-7499-4431-aa4c-d8580879a61a</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 October 2014 JobScheduler Security page: 16 JobScheduler Security - Glossary Software Open Source Glossary Job Chains 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). Jobs 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) 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 http://[scheduler_host]:[scheduler_port] , where [scheduler_host] and [scheduler_port] are the host name and the TCP ports number of the JobScheduler (e.g. http://localhost:4444). JOE (JobScheduler Object Editor) 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 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. October 2014 JobScheduler Security page: 17 JobScheduler Security - Glossary Software Open Source 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. October 2014 JobScheduler Security page: 18
© Copyright 2024