Scanning and Gates Intermediate (thu ) Matt Messinger and Ian Strahler

Transcription

1 Intermediate (thu ) Matt Messinger and Ian Strahler

2 Overview An overview of Siriusware s access control solutions Detail on how the Axess Gate integrations are set up. What works & doesn t in the realm of access control What s coming up. 2

3 Basics: Why Access Control? (In)validate tickets and passes Fraud prevention Visitor / usage counts Capacity control Support for flexible programs. What else? Why do you use it / want to use it? 3

4 The Heart of Access Control A Unique Enough ID Pass_no for a pass or ticket Card number / AdditNo RFID Presentation Physical media (ticket or card or rfid chip or bracelet) Printed barcode / phone / tattoo Could be memory (you could recite the digits) Validation Keeping track of uses Indicating approval when allowed, denial when prohibited Following of rules linked to the id / performing necessary actions 4

5 Traditional Architectures Scanman Turnstile Gatekeeper SalesEZ CheckPass SiriusSQL Gst_Pass Axess Smart Controller Turnstile Web Service ww.dll ValidatePass Access 5

6 Where does this information live in SiriusSQL? Passes Tickets Gst_pass Identical except for a few fields Access Gst_actv Acc_actv Guests 6

7 The whole deal All software and hardware seek to bridge the gap between the presentation of an ID and validate against these tables. SiriusSQL 7

8 Software on the Siriusware Side The main validation logic lives in SalesEZ. All the final validation is performed here. CheckPass ValidatePass CheckAndValidatePass GateKeeper and ScanMan read media (interfacing with different hardware) and rely on SalesEZ for these validations In some circumstances, Sales itself performs validations, kind of. However access control is not its function. 8

9 ww.dll Software on the Siriusware Side (cont) Ww.dll now can perform validations (using SalesEZ). Ww.dll is a core component of ecommerce. It s where the low level web API lives Ww.dll also is important for allowing linking between SalesEZ and Axess gates (in one configuration). This ww.dll integration allows a lot more flexibility in how we design solutions. 9

10 Team Axess Team Axess is an Austrian company that provides gate hardware and software Turnstiles, readers, gates, Siriusware has integrated with Axess for a long time, but the solution is very mature at this point Axess is the company, access control is how we refer to it internally. Confusion is inevitable. 1 0

11 Axess Integrations: Live Gate Access module 1. Axess hardware collects scans 2. Axess sends Siriusware the pass or ticket number for validation 3. Siriusware validates and sends Axess the good/bad response 4. Axess opens the gate based on Siriusware response 5. WonderWorks, Ripleys, Natural History Museum of Utah Products are configured in Sirius SOAP web service provides the bridge (SiriusAxessSOAP to ww.dll to SalesEZ)

12 Axess Live Integrations Gate Controller & Reader SiriusAxessSoap ww.dll Axess Gate Essentially identical to Gatekeeper Setup. (Except, no gatekeeper) Also no trickling SalesEZ SiriusSQL 1 2

13 Axess Integrations: Offline Axess Gate Integration module 2 systems connected by an interface Siriusware acts as a very fancy cash register Axess does all encoding and validating of RF cards Offline really means the gates understand to open or stay closed based on the data encoded in the chip RF cards can be reloaded with new purchases At the salespoint using Axess printers By the Axess gates (online) 1 3

14 Axess Partner Integrations Mammoth Mountain Mount Saint Saveur (MSSI) 1 4

15 Axess Partner Integrations Gate Controller (local DB) Axess Main DB Synchronization Service Pass and ticket info SalesEZ trickles SiriusSQL Axess Gate Sales Axess Printer The media transports Information to Axess 1 5

16 The Players Synchronization Service: Tells Axess Database about passes sold Gathers information on scans Axess Database tells gates what to do Siriusware Sales/E-Commerce SiriusSQL Siriusware.Axess.DataSynchronizer Axess SOAP EDE Axess Oracle Database Axess Gates 1 6

17 Architecture from Axess point of view 1 7

18 SkiData Integration SkiData Main DB Handshake Interface Siriusware s Synchronization Service Pass and ticket info SalesEZ trickles SiriusSQL SkiData Gate Sales Barcode conventions can communicate product information Barcoded tickets and passes 1 8

19 SkiData Integration Still in process, but will be live this fall at Dreamworld in Brisbane, Australia. Similar architecture to Axess Partner, but w/o proprietary printers and w/o RF storage of pass information. Synchronization service pushes pass/ticket info to SkiData and retrieves usage information (similarly to Axess). 1 9

20 A few terms Axess Smart Printer: Expensive piece of hardware from Axess that does all encoding and printing Hopper vs. Hand-Fed Cards 2 0

21 A few terms Media: RF and non-rf Cards that are purchased from Axess. RF cards can be reloaded with new purchases (2 segments) RF cards can be encoded with mag-swipe data used by Sales (1 segment) 2 1

22 WTP Number: A number that uniquely identifies the physical card and is used during the reload process think of it as a Chip ID Used by customers during reload purchases Gate matches card to new purchase data using the WTP number 2 2

23 A few more terms RF Serial Number: This is the real linking number between Siriusware ticket/pass purchases and Axess. WTP Number: used to identify the physical card RF Serial Number: used to identify the tickets/passes loaded onto the card 2 3

24 More on RF Serial Numbers Example: = Project Number from Ports.ini 006 = POS Number from Ports.ini is an incrementing number = Used for Tickets = Used for Passes Cannot Finalize Sales of Axess items without a Project and POS setting POS setting needs to be unique across all salespoints Don t Forget SalesHost! maxkeys.next_axtix, next_axpas 2 4

25 The Flow at the Salespoint 2 5

26 The Flow Web Reload 1. Customer enters WTP number (SW) 2. List of items available for purchase is presented(sw) 3. Customer selects item and completes the web purchase(sw) 4. SalesHost processes the sale(sw) 5. Siriusware sends sale data to Axess server (SW) 6. Customer shows up at the gate, card is bad (AX) 7. Gate checks for any new purchases for that WTP number(ax) 8. New purchase is located, gate encodes the new purchase info into the RF chip(ax) 9. Gate opens(ax) 2 6

27 The Flow Web Reload 2 7

28 Configuration Clients go to Austria to get training! All validation rules are setup in Axess The layout in Siriusware needs to match the values configured in Axess for proper encoding 2 8

29 Configuration <BlankType>1</BlankType><TicketType>15</TicketType><RF>1</RF><Pool>1</Pool><ReaderPersonGr oup>0</readerpersongroup><week>2</week><time>1</time><season>1</season><customertickettype >100</CustomerTicketType><CustomerPersonType>1</CustomerPersonType><Handfeed>1</Handfeed>< ExternalPrint>0</ExternalPrint><CardMask>%DIR:P %FNT:1L %PX:5 %PY:750 %TXL:'<<WTPNUMBERVAR>>'</CardMask><SwipeMask>%B< tmp_swipe >?;< tmp_passno >?</SwipeMask> The layout is critical! This is what links configurations in Axess with Siriusware! TEST TEST TEST AND THEN TEST 2 9

30 Configuration <BlankType>1</BlankType><TicketType>15</TicketType><RF>1</RF><Pool>1</Pool><ReaderPersonGroup>0 </ReaderPersonGroup><Week>2</Week><Time>1</Time><Season>1</Season><CustomerTicketType>100</Cust omertickettype><customerpersontype>1</customerpersontype><handfeed>1</handfeed><externalprint>0 </ExternalPrint><CardMask>%DIR:P %FNT:1L %PX:5 %PY:750 %TXL:'<<WTPNUMBERVAR>>'</CardMask><SwipeMask>%B< tmp_swipe >?;< tmp_passno >?</SwipeMask> Encoding mag-swipe data Requires a reader from Axess 3 0

31 Configuration Siriusware Pass Action Specifics and Access Template Why?? Scans/Reads from gates are regularly gathered and then trickled into Siriusware for validation Important for general research and exchanges Valid Date, Total Uses, Total Use Deduction, Shifts=1 Day vs. Don t Use Shifts Allows Siriusware functionality such as DTL and Revenue Recognition to co-exist with the Axess Gate validation Still used for any salespoint validation programs (%E discounts, IHC features, etc.) 3 1

32 Under the hood Relevant tables and stored procedures Activity types (gst_actv, acc_actv) Type 150 = Card Encoded Type 151 = WTP Reload 3 2

33 Summary Siriusware has a very flexible architecture around access control Siriusware has a number of its own solutions. Siriusware is open for integrations (Axess / SkiData)

34 Please fill out the course evaluations provided. Your opinion matters and helps us provide the best seminar experience possible. Course Name Presenter Name(s)

35 Scanman Hardware Scanman is for mobile (symbol) units Connects straight to SalesEZ Symbol 9060 / 9090 / 9090rfid Ruggedized Good to 40 below brrr Symbol 5590 Less expensive Better for indoor 3 5

36 Gatekeeper Runs on a PC and links to a turnstile (usually boon edam / tomsed) Serial activated 3 6

37 Similarities and differences between Access Control options 3 7

38 Barcodes and Mag Swipes Base 38 is used a lot We refer to it as encryption a lot, but it isn t. It s really just encoding. A prefix is optional, but only 1 blank prefix. Presence of a prefix indicates the presence of an expiration date and an encrypted pass number Prefix indicates what table to use for validation If there is no prefix The blank prefix settings are used There can be no embedded expiration date The pass is never encrypted 3 8

39 Barcodes and Mag Swipes Scan Elements Expiration Date An embedded expiration date is always checked first. XX is a placeholder that is ALWAYS valid. The first character is the day, the second is the month Base38 is used to encode the day and month Must follow a prefix Evaluation requires a rollover month Eg. 21 is January 2 2C is December 2 DC is December

40 Self Validation and Validation Templates Each pass, when validated by a scanner or gate will perform a self-validation (based on the template). UNLESS that scanner or gate specifies a DCI template to use. Physical Location is another way to exclude a scanner. Ways to control how a particular scanner interacts. 4 0

41 WAN Validation Less important these days, but valuable to know about. Passes can refer to another SalesEZ at another site for validation. 4 1

42 How to deal with RF Cards RFID can be used in a number of ways 1. Write to the card just like we would a barcode. It works just like a barcode, easy to understand But, it works just like a barcode. It s not really using the technology 2. Read a unique ID and link it to a pass. Put the chip ID in addit_no or swipe_no or some field. 3. Use the RF media to store the state of the pass. This has the most potential (or a hybrid approach). Currently, the Axess partner scenario uses this, and no other Siriusware solutions. Siriusware uses both #1 and #2 4 2

43 HF vs. UHF HF means High Frequency and typically has a shorter read range, but less trouble with reading a card that wasn t intended. Axess uses HF exclusively Good PC reader/encoder for HF as well (Omnikey) so sirius can integrate. 4 3

44 UHF UHF means Ultra High Frequency and can read from a distance. Symbol RF scanner uses UHF. An OK integration with Ensyc Block for PC read / encode. Better integration with Zebra Printer for batch printing / encoding. 4 4

45 Let s talk cascading This is more of an access control question, but worth examining. Cascading works differently for pass records vs. tickets. Both Passes and tickets are affected by: 4 5

46 Cascading Passes use the guest_no in order to find other passes to validate. Tickets use the masterpass column in the access record. Can be configured item by item Allows the 1 ticket for many venue situation to work cleanly. Can use either the location or DCI setting to control how cascading occurs

47 Ticket Cascading Setup In the Action Template for a Ticket product