Authorization Center (CA) is a modern, comprehensive and scalable platform for a centralised management of processes linked with authentication, authorization of operations, access rights control, digital certificates and PKI services handling.

CA can be applied to control customer access to enterprise services, as well as verify personnel privileges (i.e. Contact Center agents or Back Office operators). It can also manage access of technology components to various services or resources.

Access Channels

In the processes of authentication and athorisation, CA uses the concept of access channels. In general, an access channel is identified with applications (and their user interface) or a location, where we need to proceed with user authentication. As example, the following channels are often available:

Transactional WEB interface

Transactional mobile interface

IVR System

Call Center

With support for double-authentication


Mobile advisor application

Partner application

The list of supported access channels depends on the structure of the organisation and is one of the key elements of system parameterization. CA allows to apply various authentication and authorization methods for the channel. In the same way, different channel attributes, such as status or validity are serviced independently.

At the level of channel access, CA audits and controls incidents of unsuccessful authentication or authorization. A set of rules can be parameterized to block access to the given channel after a number of mistakes. It is also possible to block access temporarily, without the need to unlock manually.

Two levels of authorization

The main functionality of CA is to service an authorization account. The authorization account allows for verification of user identity, as well as user's access control to various resources and functions. CA can perform it in two ways:
Basic - 1st level or extended - 2nd level.
Both ways differ by the sort of tools used for authorization. The choice of which one to apply in a given situation stems from business logic and is part of system parameterization.

1st level

First level authorization is used mainly to authenticate the user and his identity. Information about authentication is kept during the session and is used to control passive operations, i.e. read information by the user. CA supports following methods for 1st level authorization:

  • user identifier + static parametrised password (verified strength, set of acceptable characters);
  • user identifier + a number of characters from a static password (support for password masking);
  • user identifier + indication of token (hardware or application);
  • verified device ID + PIN (used in mobile apps);
  • verified device ID + graphical password (used in mobile apps);
  • payment card ID + PIN (used in ATMs);
  • operational authentication (used in Call Center or Branch).

2nd level

For financial operations authorization, in particular for new beneficiaries or for large transaction amounts, 2nd level mechanism is applied. It involves an additional authorization tool, such as:

  • one-time passwords card (OTP) – CA supports also OTPs management, ability to order or renew additional cards;
  • SMS codes – with use of Softax ICC, SMS codes function has also billing support;
  • hardware token support (OTP) based on time control;
  • hardware token challenge–response;
  • application software token challenge–response in mobile app;
  • digital signature, based on private PKI key stored on the SmartCard.

CA supports algorithms required to work with authorization devices working in CAP/DPA and Radius standards and manufacturers like Gemalto, VASCO, RSA and others. It also offers life cycle support services for these authorization devices.

Support for user entitlements

Each user, depending on his role, should have a set of specific entitlements. In case of an individual customer a simple model is satisfactory in most of cases, but in case of a corporate client we need much more sophisticated and extended one.

CA allows to support these both types of clients due to the mechanism of ACL (Access Control List). ACL allows to define all activities, that can be performed by the client on a given object.

System has also the function to change and adjust parameters, what can also be done by the client himself. In addition to that, it allows to define profiles (groups of access rights) what facilitates management of distinct sets of clients.


Multi-signature is an acceptance mechanism, that requires a set of user approvals to accept a given operation, as it is defined in a given scheme in CA. Multi-signature is used mostly in corporate internet banking.

Each operation needs to have named users that have to authorise the operation. Each user of multi-signature uses an appropriate for him authorization tool for the access channel.

Each set of rules referring to the number of required signatures can also have limits for maximum amount of operation. A typical example of such schema would be a use case to sign a bank transfer for 30 000 PLN, which requires only the signature from Chief Accountant, but all transfers with amounts above this limit need a signature of the Board of Management Member, as well as from the Chief Accountant.

SSO supportas a server and a client

Logging-in a user into CA can also be integrated with a session initiation. Using session mechanism, CA can play the SSO (Single Sign-On) role, allowing for an unified process of user's athentication for a group of integrated services or applications. This integration can be done in two ways:

  1. By adaptation of systems to the use of authorization mechanisms available in CA CA, as a standard, uses SAML protocol to authenticate and authorize operation - transfer of session to an integrated service requires creation, sending and verification of an artefact.
  2. By using external authorization mechanisms, typical for integrated systems inside CA. This can require storing in CA user identifiers and their passwords, specific for given system. CA is logging-in a user into a given integrated system, making available just created authorization data (i.e. specific session identifier).

If in a given organisation SSO mechanism is implemented, CA can also be integrated with it, following SSO’s own protocol.

More functions

Limits support

  • Limits for amountsof a single operation or for a summary
  • Limits for number of operations
  • Periodical limitsdaily, monthly, yearly

Many logging-in identifiers

  • Authorization account identifier
  • Additional identifierse-mail, phone no.
  • Any given identifier, provided by the user

Support for work schedule

  • Temporary system access limits
  • Range of days and hours can be configured
  • For each access channel or user

Access control based
on IP address

  • Control of users work locationlist of accepted IP addresses, subnet masks, machine names or device identifiers
  • Protection against scanning accountsAttempts to authentication from same IP address or phone number to a range of authorization accounts are rejected

White-list and

  • Black list supportset of parameters causing rejection of an operation
  • White list supportset of exceptions from the black list
  • Ability to integrate it with anti-fraud systems

Can be managed by the users themselves

  • Current authorization tool
  • Way of login
  • Active access chanels
  • Values for limits
  • Additional access limitations

Support for staff access control

Access and authorization mechanisms described above, can also be applied for internal staff members i.e. authorising access based on IP address or with use of token device or Smart Card.

This can be applied for staff involved in customer service (Call Center agents or Back Office staff) or for all other groups of employees for whom CA can be used as a control mechanism for access to various enterprise resources or to staff dedicated services.


CA makes available a mechanism, that allocates so-called Pass to customers accounts (composed of an identifier + password). This passes enable access to additional systems that operate in the enterprise. We can use such a pass, if a given system’s API requires a dedicated user authentication to call a function.

Passes replace an execution of an operation in an external system, done by „technical account”. As a result, the operations are not anonymous, what enables audit of all operations, executed by each staff member. We can also set up all entitlements in one central point, even if they are related to many different core systems in the enterprise.

Employees access management process

CA offers three-level mechanism of employees access rights approval i.e. from the level of the Manager, IT Specialist and Security Officer.

At each stage full auditability is implemented, including also paper based documentation, which often is required by internal enterprise legislation.

VPN support

CA can also be used for management of access to VPN services. It includes authorization to the service with tools such as token device using challenge-response mechanism or Smart Card.

Directory services

Employee access to given systems can be defined in directory services supported by Active Directory or LDAP. CA can be integrated with these platforms and unifies access management process for the company.

In addition to that, CA can also provide stand-alone directory services what gives an opportunity to integrate CA with external systems on as-needed basis.

Temporary replacement mechanism

CA gives you temporary allocation of the role to a given authorization channel by asigning a set of dates (starting and ending access dates). In the same way, you can also delegate access rights, what can be used for temporary employee substitution.

Administration Console

Softax’s Authorization Center provides an Administration Console.

Key management functions include:

  • user management – adding, blocking, removal of user accounts,
  • building user organisation hierarchy, describing delegation and collaboration patterns e.g. organization - partner company – an employee of this company,
  • management of user attributes, access and authorization rights,
  • role profile definition that include predefined sets of rights for given roles,
  • authentication and authorization methods management, including method allocation to given systems,
  • configuration of typical user schedule,
  • definition of notifications related to any attempts of unsuccessful, successful or out of the ordinary context logging-in.

PKI infrastructure

PKI (Public Key Infrastructure) is a portfolio of services that in conjunction with procedures can be used to create, keep, verify, use or revoke digital certificates.

CA makes available PKI services including following domains:

  • management of unqualified certificates (issue, disable etc.),
  • creation of digital signature with use of qualified certificates,
  • time stamping function – with access to an external, qualified source of time measurement,
  • digital signature function – generating or maintenance of digital signatures,
  • digital signature verification function,
  • creation or distribution of CRL for issued digital signatures,
  • CRL processing for all external certificates registered in CA,
  • encryption and decryption of information, supported by hardware solutions (HSM)
    or cryptographic services.


Softax solutions in the area of PKI are compliant with the following standards and norms:

  • RFC3280 Certificate profile X509 in ver. 3 and list of recalled certificates (CRL)
  • PKCS#10 Request certificate format
  • SPKAC Request certificate format supported by browsers based on Mozilla engine and Opera browser
  • PKCS#11 Standard defining communication with cryptographic devices oraz cards
  • RFC3369 Format for CMS - Certificate Message Syntax
  • RFC3211 Algorithm description for data encryption with password support
  • RFC2560 Protocol and service description for Online Certificate Status Protocol (online verification of certificate status)
  • RFC3029 Protocol and service description for Data Validation and Certificate Status (data validation and certificate status)
  • ETSI TS 101 903 v. 1.3.2 Signature format XADES in ver. 1.3.2.
  • RFC3161 Date stamp service protocol
  • PKCS#12 Archive file format for storing private keys
  • PEM Storage format for certificates and/or private keys
  • DER Information encoding format following ASN.1 norm – Distinguished Encoding Rules
  • PKCS#5 Data encryption standard with use of password based on PBKDF schema (making of key based password)
  • RFC3039 Qualified certificate profile
  • RFC4514 DN (Distinguished Name) binary encoded names presentation approach
  • RFC3126 Electronic signature format that ensure its long term validity for legal proof

Supported integration patterns

CA functions are available as webservices in SOAP standard including WS-Security. It allows other systems and applications for access and use of authorization functions. The scope of functions covers practically all CA available functionality:

  • management of accounts and authorization channels,
  • access rights management,
  • authentication,
  • authorization,
  • PKI services,
  • digital certificates management.

CA supports integration with external authorization systems based on protocols such as RADIUS, LDAP, SAML, Active‑Directory. Integrated systems can provide hardware based token generation (i.e. RSA, Vasco, Gemalto). In addition to that, local or network based HSM can be used or HSM services can be emulated within CA.

CA can be put in place with full range of features or just with a subset of its functionality. The way of implementation depends on the context of a given enterprise and client requirements.

An additional solution building block, increasing the level of organisation security, can be fraud detection system, for example Softax IFD. CA has functions allowing integration with IFD, what can be performed by passing information to IFD or collecting it from IFD.