1

Using LDAP and Roles to Simplify Web Application Administration

Presented by: Chris Phillips – phillipc@post.queensu.ca, Monday, December 8, 2003

2

About Queen’s University

• Full-time enrolment: 18,409 (2003)

• Academic Staff 994 (tenure and tenure track included)

• Other Staff 2,569 (including medical support staff)

3

About University Information Systems

• Approx 20 people work in UIS, about ½ for the MVS side of the house, the other half on the ‘internet web app’ side.

• Responsible for:– maintaining the core enterprise systems – web applications – leadership in application development and

standards setting

4

Agenda

• Talk about our challenges and goals we set.

• Show how we assembled existing technologies in a unique way to meet these goals.

• Explain both the front and back end operations

• Discussion about some of the technical challenges and the current status of the project.

5

The Challenges

6

The Challenges

• Our portfolio of apps that we support and will be creating will never decrease.

• Our successes drive more applications, their adoption and success increases and become intrinsic to daily operations. We have critical mass now(people get it!).

• Our team size will not necessarily increase at the rate our apps we deliver (then maintain!) do.

• Numerous mini and not so mini web apps deployed with varying flavors of implementation techniques, authentication, and staff needs.

It was evident that we needed to do something.

7

Setting the Goals

Establish Stakeholders as Administrators Enable Delegation

Use RolesBe Platform Agnostic

Must be Easily Replicable

8

Establish Stakeholders as Administrators

• Many reasons why:– Who else would know their processes better?– Who else knows best about who is to do what?– Know characteristics of the role UIS plays in this

area:• We are custodians of the data, not the stewards of

the data.• Access management needs to be auditable to

insure proper ‘chain of authorization’.• We don’t need to be part of that chain, we just

make the chain stronger and easier to see.

9

Enable Delegation

• This is as important for us as it is our stakeholders– This is the where we hand over the keys to the

application to the client and exit from day to day maintenance.

– We model how work is done in the real world.

10

Use Roles

• It’s an immediately recognizable term to the user population and easily understood.

• Using roles allows us to map functionality to the user population, but not down to the user.

• Keeps away from managing itty bitty records and lets us do broad management.

• Some roles can be global in scope (e.g. student, faculty) or as specific as we want them to be.

• Roles can cross organizational boundaries – Dept. affiliation is not necessarily the right way to assign

capabilities

11

Be Platform Agnostic• Want to future-proof our development approach

– We need this ourselves to harmonize our service delivery.

– We know we won’t be able to build every single app on campus nor do we want to.

– However, we are responsible to manage and secure the identities and data that are used in them by virtue of our security policies. This is part and parcel of the custodian role we have.

• Generally speaking the strategy needs to be platform agnostic to not force people to a single technology (because they won’t).

12

Must be Easily Replicable

• “Apps…lots of apps. Better, faster” (a.k.a The Matrix meets The Six Million Dollar man syndrome)

– Authentication and authorization are commodities, not specialties.

• core work is done once and leveraged thousands of times without watering down the effects of it (audit ability, granting and revocation of access)

– We set the gold standard for others to use the same approach in an auditable, safe, and secure manner.

– “Set it and forget it” approach allows dev people to focus on the core business and not how to secure yet another application.

13

Criteria for Success Summary

• Stakeholders need the ability to securely manage the applications we build for them

• Delegation of abilities is needed in order to scale with the magnitude of users (10,000’s)

• Functionality or access should be granted to a Role not the person

• Be platform agnostic. Access to various business functions should be transparent even though they may be in different places or on different technology.

• The approach has to be easily replicable

14

Assembling the Pieces

15

Under the Hood

• We extend Yale’s CAS technology to leverage it’s authentication strategy and add some back end intelligence that interacts with our data in the LDAP server (iPlanet)

• The LDAP server contains more than just Roles and Id’s, it also has the Role to application mappings that enable us to answer:

“Are you who you say you are, AND are you allowed here based on your role?”

16

CAS• CAS stands for Central Authentication Service• Created by Yale and available in JA-SIG clearing

house• Loosely based on Kerberos and uses a ticket granting

strategy authentication protocol.• Central Server manages act of authentication• CAS enabled app never sees userid or password, just

valid users• CAS connector client software needed on the app to

validate tickets via SSL back channel to server for ticket validation.

• Payload in validation response provides info about user

17

The Directory

• More than just identity storage– Contains

• All our roles• uses plain LDAP objects to contain our formalized

hierarchical representation of our app role mappings.

• We leverage the structure and nature of the data with a few well crafted LDAP queries to extract your access privileges.

18

The DIT

dc=queensu,dc=ca

ou=Rolesou=Peopleou=Applications

ou=UIS

ou=App1 ou=App2 etc...

dn: uid=ver1.0,ou=App1ou=ClientA,ou=Applications,dc=queensu,dc=ca

role=App1AdminStudentEmployeeStaffOtherou=ClientA

sid= http://www.somewhere.ca/validateme.jsp

• Grey areas indicate where UIS has administrative control.• The People sub tree contains approximately 65,000 records.• The roles sub tree is flat and boring.• The applications sub tree is where the action is.

19

ou=UIS

ou=App1 ou=App2 etc...

dn: uid=ver1.0,ou=App1ou=ClientA,ou=Applications,dc=queensu,dc=ca

ou=ClientA

sid= http://www.somewhere.ca/validateme.jsp

ou=Applications

Application Sub tree

• The domain of management

• Sponsors within the domain

• Sponsored Applications

• nsRoleDN= cn=Faculty,ou=Roles,dc=queensu,dc=ca

• CAS Service ID

• Application Registry Record

• Application Universe

20

How a Login Works

CAS EnabledWeb App

CAS API

HTTPS CAS

Login PageCollects

userid/passwdSID

1. App redirects user to CAS Login page with Service URL (SID) 2.

User/pass/SID validated in directory &Roles CollectedY/N response determined

3. User, Roles, SID ‘ok’, grant ticket and redirect end user to CAS validation page

4. CAS backend validation of ticket requested

5. NetID and enhanced CAS Payload with Roles returned

dc=queensu,dc=ca

ou=Rolesou=Peopleou=Applications

ou=UIS

ou=App1 ou=App2 etc...

dn: uid=ver1.0,ou=App1ou=ClientA,ou=Applications,dc=queensu,dc=ca

role=App1AdminStudentEmployeeStaffOtherou=ClientA

sid= http://www.somewhere.ca/validateme.jsp

1. X ref of id’s roles to apps

2. Validate SID

Directory contains:

1. Role to App Map

2. Role mgmt Map

CAS Payload Improvements:

1. Roles and addn’l info for app passed as XML

2. Configurable payload depending on Service ID

orService(imap,

webProxy,pam_casfor shell,WEBDav,

etc)

21

The Front End

• We call the web front end to the system ‘GUARDIAN’.

• Secured by NetID and the role of guardian user so it participates as a client of the system itself.

• Sits on top of the directory tree and is the engine that interprets the roles and their mappings to perform the activity of management and delegation.

• Implementation is in progress, but let’s explore the stakeholder use case

22

Use Case for Stakeholder Access

23

Main Menu

24

Your Applications Menu

25

Application Registry Screen

26

Linking Roles to Apps

27

Questions so far?

28

Some Value Propositions

• If you want to just host the authentication and authorization component and nothing else, you can. – delegate the administration of an entire domain to

some else (trusted of course)

• This simple use of our strategy can be a big win.– securing web pages via apache mod_cas and IIS

plug-in. Don’t underestimate the value of this.

• Better overall control of data security – Payload is customizable and configurable

29

Implementation Challenges

• Balancing everyone’s and everything’s privacy concerns

• Being flexible enough to allow stakeholders do what they want (e.g. allow off campus SID’s )

• Data accuracy…no such thing as ‘clean data’ no matter how hard you try to wash it, so build for it!

30

Questions?

31

Thank you for your time!

My Email: phillipc@post.queensu.ca

Questions, comments, and inquiries welcome!

32