Are you crystal clear on Stellent security model

Last week I was doing one of my presentations on Stellent security model. Its stunning how after all these years this of all Stellent aspects, still manages to confuse even most experienced admins. ARE YOU CRYSTAL CLEAR ON STELLENT SECURITY MODEL? If not – here's your magic bullet – it requires a paradigm shift.

Start with the basic terminology. You will need to understand what Stellent means by such commonly used terms such as "group" or "account". Believe me – its' not what everyone's thinking!

When you get comfortable with the glossary – draw a diagram how all of this fits together. Drive home how content is assigned into groups, how group access is controlled by roles and how account hierarchy works.

Once you get that down – check how Folders are used to impose virtual hierarchy on otherwise flat repository.

Check out my presentation below. It covers the same ground in a little bit more details and may become a good road map for you…. Good luck

Oracle Stellent
SECURITY model

Lessons learned

Dmitri Khanine

dk at stellentexperts dot com

Oracle Stellent Security

• Powerful but can be confusing

• Requires careful planning

• Professional help is not always an answer

– Why? Explained later in this presentation….

Security Model Overview

• Any security model made of:

– Authentication

– Authorization

• Authentication

– Stellent

– Windows

– Active Directory

– LDAP

– Custom

• Authorization

– Groups

– Roles

– Accounts

• Authentication and Authorization combo:
(LDAP, Active Directory, Custom)

– Allows mapping of existing org structure to Stellent security principals

– Stops the agony of maintaining permissions of the same user in multiple places

– Covered in detail later in this presentation

Security planning

• Long ranging implications of overly complex and under-designed models

– Users will be able to do more then it is mandated or even safe for them to do

– Access may be denied in unpredictable situations

– Hard to debug user access issues

– New content will follow the model and increase the cost of correcting the model

On Content Revisions

• Major benefit of content management…

• Each revision can have different metadata

– To update security on a content item all revisions need to be updated

– Even if you don’t add new content – changing of security gets more expensive over time

Security planning

• Long ranging implications of overly complex and under-designed models

• Easier to start with a good model then change later

BUT

• Security model can be changed at any time

… How to plan a security model – later in this presentation

Basic terminology:Major source of confusion

• Groups –

– Windows: a set of users

– Stellent: a piece of metadata

• Accounts –

– Windows: user record

– Stellent: a piece of metadata

Security at a glance

• Groups and accounts used together

Why is it so confusing?

• Robust, time tested system

• Hundreds of customers worldwide

• Is it just terminology?

Paradigm shift

• Single flat repository instead of conventional taxonomy

– No permission inheritance in the base system

– Optional Folders components required for some of support hierarchies BUT

– Folders are no longer synchronized with web site navigation (as of v. 7.x)

Groups

• A “tag” on a content item

• Helps to group items with same security level

• Used verbatim

• Limited to 30 characters

• Access to groups specified by user role membership

Roles

• Specifies user access level to various groups

• User can belong to multiple roles

Accounts

– Another “tag” on a content item

BUT

– Supports hierarchy

– User access to accounts specified directly

• Accounts support hierarchy, based on a “Starts with” substring rule

• RW on ca/on will give Read and Write access to

• ca/on/montreal

• ca/on/toronto

• ca/on/Ottawa

– Slashes are optional

• RW on ca,on will give Read and Write access to

• ca,on.montreal

• ca,on-toronto

• Ca,on=>ottawa

– Length limited to 35 characters

– Can be created on the fly…

Ignore these and get in trouble:

• Account text box lets people create ad-hoc accounts that others can not access

How I plan Stellent security

• Name all types of people who will at any time access the system

• Will they be authenticated? How?

• What will they do on the system?

Case study

• Model features after security redesign:

– Roles follows user’ job function, not organizational unit

– Groups describe access level

– Accounts segment content by organizational unit and web site section

Oracle Stellent Security:

• Requires careful planning

– Authentication

– Authorization

- Groups, Roles, Accounts

BUT

• Bad model can be corrected at any time

• Requires paradigm shift in thinking and can be confusing

• Professional help is not always an answer

– Must have experience implementing Stellent security models

Must be able to explain Stellent Security concepts without mystifying them

• Questions?