Embed Size (px)
Citation preview
1
Using LDAP and Roles to Simplify Web Application Administration
Presented by: Chris Phillips – [email protected], 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?
32
