Welcome to the OSDBU Showcase  
Department Of Veteran Affairs
Freddie Graham
Veteran Relationship Management (VRM)
April 19, 2012
Agenda
Organization & Mission
Goals & Priorities
Requirements Overview
How can you help us
Office of Information and Technology
Project Management
VRM Initiative
Mission: VRM will engage, empower and serve Veterans and other Clients with seamless, secure and on-demand access to benefit information and services
Key Clients:
Veterans and Beneficiaries
Employees and Contractors
Volunteers and VSOs
Business Stakeholders
Enabling our Clients to:
Find uniform information about VA’ s benefits and services, regardless of access channel
Complete self service transactions with VA
Be quickly identified by VA, without having to repeat information
Seamlessly access multiple VA service lines
Current use of Contractors
How can you help us?
Current Contracting Areas
Integration Services
Architecture
Development
Hosting
Hardware/software
Need Companies who are:
Familiar with the VA project environment
Already possess VA credentials or are at least positioned to be cleared quickly
Competent in appropriate technologies and methodologies
Active Directory and Oxford Single Sign-On
Bridget Lewis -ICTST
Adrian Parks -OUCS
Aim
How to link Active Directory to the Oxford Kerberos Single sign-on (SSO) infrastructure
What is Kerberos?
Authentication protocol
Not authorisation
Client and server mutually authenticate
Authentication vs Authorisation
Why Kerberos?
Single sign-on
Centralised authentication
Strong encryption
No passwords over the wire
Kerberos in Oxford
eDirectory
Active Directory
Open Directory
So how does it work ?
Simple, really
Like this
Essential Terminology
Principal î user or service with credentials
Ticket î issued for access to a service
Key Distribution Centre (KDC) î issues tickets for principals in a realm
Realm î set of principals in a Kerberos database, e.g. OX.AC.UK, OUCS.OX.AC.UK
TGT (ticket-granting ticket) î confirms identity; used to obtain further tickets (Single Sign-on)
Kerberos and Active Directory
Kerberos 5 implemented in AD (with added )
Every domain is a Kerberos Realm
Every domain controller is a KDC
Many services can use Kerberos
CIFS, LDAP, HTTP
Kerberos is preferred over NTLM
Trusts between Kerberos Realms
Integrating Active Directory with Oxford Kerberos Realm
Configure Active Directory Kerberos realm to trust Oxford Kerberos realm for authentication
Integrating Active Directory with Oxford Kerberos Realm
Authorization: AD uses SID, not username to determine what a user can do
Usernames must exist in AD (Identity Management)
Oxford usernames must be mapped to Active Directory users
So what does this mean in practice?
The Good …
Use Oxford account to authenticate to AD
No need to issue passwords to new students each year
Devolve password problems to OUCS
Case Study
St Hugh’ s College
~ 20 Public Access PCs
~ 600 Students, intake of ~120 per year
Passwords were issued manually each year
Integrated with Oxford KDCs
Account creation simplified via VB script
Students use Herald password
Administrative overhead reduced for ITSS
Case Study
Language Centre
User base is whole university!
Potentially 40000 users
Historically, all used one shared account
Webauth plus Oxford SSO solution
Users register for AD account via Webauth protected site
AD account generated on the fly
Log in to AD via the Oxford SSO solution
Herald password
But there are some caveats
The Bad …
Access from PCs not in domain
Including via web, e.g. Outlook WebAccess
Some students don’ t know their Oxford password (approx 13%)
Loss of external connectivity to central KDCs
…and some problems
The Ugly …
Fallback authentication is NTLM
KDCs don’ t speak NTLM
Some apps only speak NTLM
Problems integrating other operating systems (OS X, other?)
Summary
Works very well in certain scenarios
E.g. shared filestore for students
Reduced administrative overhead
Not appropriate for all environments
E.g. many services built on Active Directory (Exchange, Sharepoint, Web access to files etc.)
Check time is in sync (throughout domain and to ntp source)
See appendix for details!
How do we set this up?
2. Request a Kerberos principal from the OUCS Systems Development team (sysdev@oucs.ox.ac.uk)
krbtgt/FULL.AD.DOMAIN.NAME
krbtgt/STHUGHS.OX.AC.UK
krbtgt/ZOO.OX.AC.UK
How do we set this up?
How do we set this up?
How do we set this up?
4. Check time is in sync
How do we set this up?
5. On all domain controllers, member servers and workstations, install the Windows Support Tools and run:
Kerbtray
Kerbtray displays tickets
Picture shows TGTs for ITSSCONFADDEMO.OX.AC.UK and OX.AC.UK
Kerbtray
Picture shows tickets for services in Active Directory Realm
Klist
Klist î as Kerbtray but command line
Support Tools
Ksetup
Set up realm information
E.g. set KDCs for a given realm
Ktpass
Manipulating principals
MIT Kerberos for Windows web.mit.edu/kerberos/dist/
Another way of viewing tickets
Maintains its own ticket cache
Can import tickets from Microsoft cache
Some applications can use these tickets
Network Identity Manager
Appendix B î Additional Notes
Time must be within 5 minutes of KDC time
Logon may fail intermittently if logon allowed before network fully initialized (XP/2003)
Group Policy setting
Computer Configuration/ Administrative Templates/System/Logon
Enable setting “Always wait for network on computer startup or user logon”
Terminal Services Patch support.microsoft.com/default.aspx?scid=KB;EN-US;902336
Other notes of interest
Workstation authenticates too: problems for x-realm auth.
DC devolution î KDC patches available
Macs
eDir
preauth, timestamps, lifespan of tickets etc
Appendix C
Web Single-Sign-On with iChain and Novell Access Manager
E. Axel Larsson
Drew University elarsson@drew.edu
TTP EMEA Conference 2007
Agenda
A history of Web SSO at Drew
iChain and Access Manager fundamentals
What is iChain? What is Access Manager?
Networking Considerations
Access Control, Form-Fill, and Identity Injection
Troubleshooting Tools and Tips
Advanced Functionality
Customizing login and logout
Leveraging accelerator/reverse proxy features
A history of Web SSO at Drew
2000-2003: Session Manager
Apache/mod_perl module, Single auth server
Applications needed to be modified to support Session Manager authentication.
Difficult to integrate non-open source or homegrown software.
Special proxy auth module developed to support NetMail WebAccess.
2003-2007: iChain
Blackboard implementation demanded a more robust, non-invasive SSO solution
Significant expansion of third-party apps not under Drew’ s control – GroupWise, Macromedia Breeze, etc.
Migration to Access Manager
Ongoing, expected cutover summer 2007
Today
iChain 2.3
Two iChain appliances
Zeus ZXTM load balancer in front
Approximately 40 web applications
100% coverage for Drew end-user web applications
A few applications
Ad-Astra Portal
Adobe Connect (Macromedia Breeze)
Aptron CampusWeb
Blackboard 6
Ektron Content Management
EZProxy
GWGuardian Web Quarantine
GroupWise WebAccess
GroupWise Mobile
NetStorage
SIRSI Web2 Library Web Catalog
SupportWorks Helpdesk Self-Service
vBulletin Forums
Fundamentals
What is iChain? What is Access Manager?
Networking Considerations
Access Control Policies
Basic Form-Fill
Basic Identity Injection (OLAC)
What is iChain?
Reverse proxy based SSO soft-appliance
Sits in front of web servers
Authenticates clients and applies access control policies
Authenticates clients to backend web servers on the behalf of users.
Two principle facilities for providing single-sign-on
Form-Fill
OLAC – Object Level Access Control (now called Identity Injection in AM3)
What does Access Manager add?
Unified administration console
iManager-based
Manage configuration for proxy appliances, identity servers, policies, etc. from one place
Identity Server
Federation
SAML 1.1, SAML 2, and Liberty Alliance
SSL VPN
J2EE Agents
Access Gateway appliance is the direct replacement for the iChain appliance
Networking Considerations
AuthN/AuthZ for your web apps are delegated to the Access Gateway proxy
Web servers trust injected identity information provided by the Access Gateway
Clients should not have direct access to backend web servers.
Web servers should be placed in a private network behind the Access Gateway
Fault tolerance for the Access Gateway will require use of an L4 switch (load balancer)
Beware of NAT issues with Access Manager and L4 switches
iChain networking at Drew
Authentication and Access Policies
Protected resources defined by URL path:
i.e. www.drew.edu/secret-stuff/*
iChain -three levels
Public -Allows anonymous access
Restricted -Requires any authenticated user
Secure -Uses ACLs (static or dynamic membership) to determine access
Access Manager adds
Identity server roles -Based upon a number of criteria. LDAP attributes, Liberty profile fields, client IP address, time of day, etc.
ACL policies for SSO applications
Blanket approach
Protected resource for the entire site:
i.e. webmail.drew.edu/*
Require auth for all access
Surgical approach
Trust the application’ s session management
Application may offer differentiated content for anonymous and authenticated users
Only protected the login endpoint (either a page with a login form, or basic auth)
Example: Spam.drew.edu/* — Public Spam.drew.edu/Quarantine/login.aspx — Restricted
The basics of Form Fill
Non-invasive integration method
Fills out login forms on behalf of user
Done client-side, form HTML is substituted with JavaScript generated by the appliance
Form matching criteria
URL
Text on page
Form filling
User’ s login credentials
LDAP attributes
Can pass embedded JavaScript back to client
Identity Injection (Called OLAC in iChain)
Injects identity information into HTTP requests from the client
HTTP Authorization header (HTTP Basic Auth)
Arbitrary HTTP Headers
Arbitrary query string (GET parameters)
Useful for
Applications that support basic auth
Applications designed for SSO integration (look for header based SSO in the docs)
Home-grown apps designed only for deployment behind the access gateway
When things go wrong
Troubleshooting tools
Firefox
Web-developer’ s toolbar
Tamper data extension
Interception proxy
Burp Proxy -portswigger.net/proxy
Test scripts
On the web server -to print out request variables and compare with expected
Traffic analysis
On the Access Gateway appliance (tcpdump or pktscan) to capture traffic
On the client -Wireshark
Advanced Functionality
Integrating login and logout with your applications
Embedded login forms
Single logout
Seamlessly integrating multiple applications with path-based multihoming
Embedded login forms
Replace application login forms with Access Manager or iChain login forms
Provides a seamless experience for the user
Works well for applications that provide differentiated content to anonymous / authenticated users.
Conditional display of login form facilitated by identity injection. (ID injection works on public resources)
In form POST need:
Username
Password
URL of site to redirect to after successful login
Single logout
Replace application logout links with iChain/Access Manager logout links
Can also be a post-logout redirect for applications that support it.
iChain – site/cmd/ICSLogout
Access Manager – https://IdentityServer:Port/nidp/app/logout
Path-based multi-homing
Allows you to stitch together multiple applications under a single URL namespace
Example setup at Drew: www.drew.edu/*
An ASP.NET based content management system running under IIS 6 on Windows Server 2003 www.drew.edu/admblog/*
A Drupal based blog running under Apache on a SLES 9 server www.drew.edu/qfsearch/*
The Novell QuickFinder engine running on NetWare
Common Problems and Solutions: Four Scenarios
1 – Improper cache control headers
2 – Embedded JavaScript on login forms
3 – Loopback communication
4 – Out of band HTTP and non-HTTP access by clients
Improper cache control
Beware of applications that do not set proper cache control headers on their responses
Access Gateway is a caching reverse proxy
Results of improperly cached content can range from merely embarrassing to a serious security issue.
Remember, the AG doesn’ t cause the issue, but may make it apparent for the first time.
Improper cache control
How do we fix it?
Fix the application (ideal)
Cache-control: private (allow pages to be cached by the browser but not intermediate proxies)
Cache-control: no-cache, no-store and Pragma: no-cache (do not allow the page to be cached anywhere)
Access Gateway / iChain workarounds
Pin-list with the bypass option. Tells the AG what URL patterns may not be cached on the appliance.
Disable allow pages to be cached at browser . Inserts cache control headers in all returned pages.
JavaScript in login forms
Some applications use JavaScript embedded in their login forms to manipulate form vars before posting back to the server.
Example: Blackboard Basic Edition MD5 hashes the password in JavaScript in an onSubmit form method.
Workarounds
Form-fill policies work by returning custom JavaScript to the client that fills and then auto-submits the form.
Configure form-fill policy to allow JavaScript code to pass unaltered to the client. Configure onSubmit action in form-fill policy.
Loopback communication
Applications assume that server-side components can communicate with each other using the public DNS name of the web server.
I.e. Blackboard Basic Edition tries to connect to it’ s MS SQL database at blackboard.site.edu.
Won’ t work because public DNS names of the application point to the Access Gateway or L4 switch.
Some applications do not allow for configuration of this behavior either due to poor design or software license restrictions. (single server deployment only)
Workaround
HOSTS file entry on each backend web server pointing the public host name of the site at itself or 127.0.0.1
Out-of-band communication
Some web applications make use of external helper programs or applets
Applets may need to connect to other services running on non-standard ports on the application server.
Examples
Blackboard Virtual Classroom on port 8010
Breeze Meeting / Flash Communication Server on port 1935
What to do?
Can we get the applet to talk directly to some other address than the hostname of the web server (the AG box)?
No – The security model for Java and Flash applets restricts them to opening socket connections to the box from which they were downloaded.
Use Access Gateway tunnels to open up ports on the AG
Out-of-band communication
HTTP requests by external applets
Must contain an AG session cookie to be considered authenticated.
Not a problem if the request goes through the browser’ s HTTP client. I.e. if the applet is embedded on a web page.
If the app launches an external helper program (Example: Breeze Presenter’ s Plugin) it will not have access to the browser’ s cookies. AG will deny request.
Workarounds
Use an interception proxy to figure out what URLs that external application is requesting. Alter AG access control rules as needed.
If the URLs needed are many and varied, consider using a surgical access control policy instead of a blanket policy.
Single sign-on authentication: introduction
GWS-WG session, IVOA interop meeting, Kyoto, May 2005
Guy Rixon
SSO: what does it mean?
Allow the user to exercise all pre-agreed rights in the VO by signing on once, per UI, per interactive session, to any conforming UI.
As above, but signing on once per session to any conforming UI is sufficient to make all rights available via all conforming UIs.
Basic requirements
Let resource providers make authorization decisions.
Follow natural patterns of access based on agreements between communities and groups.
Supply credentials to inform auth. decisions.
Unlock all user credentials with one sign-on per session.
Make it as simple as possible (but no simpler!)
Axiom: users are registered
User has to establish an identity once (single registration) to use the VO.
Have to authenticate this identity to resources to get in.
Registration generates credentials for authenticating to services.
Issue: where are users registered?
Separately by each service provider (e.g. each archive site)?
Centrally in the IVO?
Centrally in regional VO project?
In their natural community (e.g. university department)?
Issue: when are credentials issued?
At registration, direct to human user?
At session sign-on, to user’ s agent?
Axiom: we support groups
Service provider grants access to groups of users
S/w making auth. decision needs access to group details and membership.
Issue: where are groups defined?
Separately at each service provider?
By user communities?
Same place as users are registered?
Somewhere else?
Axiom: we use digital signatures
For s/w agents authenticating to services:
We use public-key cryptography
We use X.509 identity certificates
Certificates issued by CAs
C.f. human users signing on to VO at start of session
Probably use passwords for that
Issue: how are certificate issued?
Who by?
National/commercial CAs (outside IVO)?
Central CA for IVO?
CAs in regional VO projects?
CAs in user communities?
To whom?
To human users (reusable, long-term cert.)
To s/w agents (single-session proxy cert.)
Axiom: we support delegation
Some work is delegated between a chain of services
e.g. Application -> workflow engine -> DAL -> VOStore.
Delegation of work implies delegation of access rights.
Issue: is delegation controlled?
Use of service implies delegation of all user’ s access?
User can veto delegation?
User can specify delegation of specific right
E.g. write once to particular file on particular VOStore.
Mobile Single Sign On System
Souheil Lazghab
The security protocol should secure:
First, the Bluetooth communication between the PICDEM FS USB Demo board and the mobile phone device.
Second, the access credentials stored in the RMS residing on the mobile phone.
Third, provide a secure authentication mechanism between the user and the sso MIDlet.
To achive these goals:
RC4
SHA-1
AES-128
Problems!
The limitation of the processing power and storage size of the PICDEM FS USB Demo board device.
The limitation of the development environment for both Java and embedded system.
Conclusion
100 % security does never exist in any system.
The security protocol offers a good security level to the SSO prototype.
The degree of security could be ameliorated if it will be included early in the design process.
