Authentication, Security, and Access Control
Who can do what, and how they prove it
Security in Blue Prism rests on two pillars: authentication (how users prove identity) and authorisation (what they are permitted to do). Candidates must understand that Blue Prism supports native database authentication as well as integration with directory services, and that the choice affects how accounts are created and maintained. Directory-integrated authentication reduces administrative overhead but requires correct service account and domain configuration; native accounts are simpler but demand disciplined password and lifecycle management.
Authorisation is role-based. Users are assigned to roles, roles carry permissions over objects, processes, queues, and environment settings, and access rights determine visibility of folders and resources. A common exam trap is conflating a user's role with their licence - a user may hold a role that grants access to a feature but the environment's licensing may still restrict how many concurrent sessions exist. Another trap is forgetting that the account used by the application server services is itself a security principal that needs database rights, separate from human user accounts.
Auditing deserves attention: changes to roles, permissions, and process releases should be traceable. Questions may ask how to investigate who altered a schedule or released a process, and the answer involves the audit trail rather than guesswork.
Rule of thumb: design roles around job function (developer, controller, administrator, viewer) and assign the minimum set, reviewing membership whenever staff change teams.
Worked example: a developer needs to edit processes but not release them to production. Create a role granting edit rights on the relevant folder without release permission, assign the user to it, and confirm the restriction by testing the release action.