Web based single sign on
Caleb Racey,
Web development officer,
Webteam, customer services, ISS
IAMSECT project officer,
http://iamsect.ncl.ac.uk
Systems admin (focusing on SSO)
Agenda
• The need for SSO
• Shibboleth
Theory
– Technology overview
– How it works
Practicalities
– How to install it
– What to do afterwards
Shibboleth Theory
• The need for single sign on (SSO)
– User perspectives
– Admin perspectives
• The future of SSO
– Shibboleth
– What it is
– How it works
The need for web SSO
Proliferation of web based systems
VLEs (Blackboard, Zope, webCt, Moodle)
Library catalogues
Webmail
ePortfolios
eJournals and eResources
Grid
etc etc
The need for web SSO
Proliferation of password stores in an institute:
Campus login
Library login
Medical school login
Comp Sci Login
Athens
Lack of integration
even when one username and password still many logins
Users and administrators overburdened
User Survey
Quantify burden on Users
200+ participants
iPod shuffle prize
1 winner =
Users overload, Survey says:
How many Internet accounts?
number users
200
150
100
50
0
1 to 3
4 to 6
7 to 10
number of accounts
11+
Users overload, Survey says:
How many times in an average day do
you type in a username and password?
300
no users
250
200
150
100
50
0
1
2 to 5 6 to15 16 to30
logins
30+
Users overload, Survey says:
Do you keep a written record of your computer
accounts?
300
no users
250
200
150
100
50
0
never
rarely
regularly
always
Users overload, Survey says:
Do you use a different password for each
account?
250
no users
200
150
100
50
0
never
rarely
regularly
always
Users overload, Survey says:
Do you use a tool to help manage computer
accounts?
250
no users
200
150
100
50
0
never
rarely
regularly
always
Summary of survey
Users overloaded with different passwords
and overloaded with login prompts
Half are using best practise with passwords
Half are not!
Current web username and password
provision needs improvement.
Administering a password system
Easy to setup, the pain comes later once
people use it:
Technical pain
• Securing the system
• Backing up the system
• Clustering the system
• Administering the system
Administering a password system
Management pain
• Adding new users
• Expiring old users
• Changing passwords
• Distributing passwords
• Ensuring “proper” passwords used
Real world example
Real World example
Real World example
Summary
• User are overloaded with authentication
tokens already
• There is explosive growth in the use of
username and passwords
• Administering usernames and passwords
is painful and expensive.
The Solution
One university password store:
–
–
–
–
One password to remember
One set of admins
One set of infrastructure
One education effort
In Ncl:
pre-existing Campus username and password
- stable, robust well resourced
For the Web
Web Sign On and Shibboleth
Shibboleth
Why the daft name?
Shibboleth: And the Gileadites seized the passages of the
Jordan before the Ephraimites; and it was so, that when
those Ephraimites who had escaped said, "Let me go
over," that the men of Gilead said unto him, "Art thou an
Ephraimite?" If he said, "Nay," then said they unto him,
"Say now 'Shibboleth.'" And he said "Sibboleth," for he
could not frame to pronounce it right. Then they took him
and slew him at the passages of the Jordan; and there
fell at that time of the Ephraimites forty and two
thousand. (Judges 12:5-6, King James Version of the
Bible)
i.e. The first recorded use of a password
Shibboleth
Federated Single Sign on standard from
American Unis via Internet2
Based on SAML (Security Assertion Markup
Language)
Summary: Athens and Microsoft passport
functionality combined with added privacy
What you need to know about
shibboleth
•
•
•
•
•
How it works
What attributes are
What federations are
Your Identity stays at home
Privacy sensitive by default
Terminology
Identity provider (IdP): The password store e.g. ncl
Service provider (SP): The application owner e.g.
ejournal
The core concepts of shib
•
•
•
•
Usable for on and off campus resources
A user is authenticated at “home”
Home knows who and what a user is
Service providers make access decision based
on what a user is
• Service providers should only know the
minimum about a user
Builds on top of pre-existing sign on (pubcookie)
Core concepts of shib (technical)
• User redirected to home to authenticate
and redirected back once authenticated.
• Authorisation is based on attribute
description of a user sent between the two
servers in the background
• Federations are used to group together
service providers and institutes who can
agree to the same rules
What the user sees
User attempts to access Service
User redirected to ‘WAYF’
https://wayf.sdss.ac.uk/shibboleth-wayf/...
User selects their Identity
Provider
https://weblogin.ncl.ac.uk/cgi-bin/index.cgi
IdP authenticates User
Active
Directory
User redirected back to Service
Active
Directory
https://shib.ncl.ac.uk/shibboleth/
HS?...
User accesses Service
Active
Directory
http://bruno.dur.ac.uk/
Shib for unfederated apps
WAYF is transparent and optional
Active
Directory
Shibboleth
“Shibboleth, is a bit like the duck which
moves serenely through the water, but
is paddling furiously beneath the
surface.”
- Derek Morrison, the Auricle
Shibboleth Process
Simplified
User accesses
protected resource...
1
2
3
...credentials and
agreed information
passed back to service
provider.
...user is redirected to
their home institution
for authentication...
Benefits of shib
• Federated access control !
• Allows access control based on attributes
i.e. enhanced authorisation
• Allows “secure” access control over http
and https
• Prevents application developer from
having to worry about login process
Demonstration (live)
• EDINA EMOL
• SDSS federation WAYF
Attributes
Attributes are what shib uses to authorise.
• Descriptive information about a user
• Can technically be any descriptive text
e.g. has green eyes
Privacy sensitivities mean external attributes
limited
Internal attributes not so limited
How to identify useful attributes
(theory)
• the attributes that are required by the web
application;
• your institutes privacy policy;
• which attributes you can collect in a timely
and scalable manner;
Identifying attribute (reality)
• Type and format will be decided by the
federation you join
• Different Federations still likely to use the
same standards
• You are not limited by federation, it is just
there for convenience
Attribute identification (detail)
For external consumption current attribute
use is limited to a dull but useful core
One major attribute standard in real use at
present: EduPerson
One current seriously used attribute:
edupersonScopedAffiliation
eduPersonScopedAffiliation
•
•
•
•
MACE-Dir eduPerson attribute
Example: member@ed.ac.uk
Gives subject’s relationship to an institute
At present can be one of:
member, student, employee, faculty, staff,
alum, affiliate.
• Many resources licensed on these terms
• “member” is all providers want to know for now
Attribute identification (detail)
Several more contemplated:
• eduPersonPrincipalName
• eduPersonTargetedID
• Given name
• Surname
• Common name
• eduPersonEntitlement
eduPersonPrincipalName
MACE-Dir eduPerson attribute
Examples:
– ncr18@ncl.ac.uk, caleb.racey@ncl.ac.uk
• Equivalent to username
• Must be long lived and non recycled
• Must be unique
eduPersonEntitlement
• MACE-Dir eduPerson attribute
• Examples:
– http://provider.co.uk/resource/contract.html
– urn:mace:ac.uk:sdss.ac.uk:entitlement:emol.sdss.ac.uk:restricted
• states user’s entitlement to a particular resource
• Service provider must trust identity provider to
issue entitlement
• Good fine grained fall-back approach.
eduPersonTargetedID
• MACE-Dir eduPerson attribute
Example: sObw8cK@ncl.ac.uk
• A persistent user pseudonym, specific to a given
service, intended to enable personal
customisation
• Value is an uninformative but constant
• Allows personalisation and saved state without
compromising privacy…much
• Issues about stored vs. generated forms
In flux at the moment
Attribute use in the Real world
SDSS usage for Edina resources:
eduPersonScopedAffiliation:
Biosis, EMOL, Times archive, EIG, Zetoc Alert, Zetoc
Search, Hairdressing
eduPersonTargetId
Zetoc search
eduPersonPrincipalName:
LandMap
Attributes for internal use
To be determined by the needs of
application developers
e.g. users department, course, year of study,
undergraduate or postgraduate,
outstanding fines etc.
To be decided in consultation with
application developers
Internal attributes (technical)
Need to be accessible in 3 seconds
LDAP or SQL querying
ideally consistent for different user groups,
i.e. staff and student attributes are in the
same place.
Advanced attributes
N-tier authentication
Potential to distribute “tokens” as attributes
e.g. NTLM or Kerberos tickets
Might be a solution to the n-tier problem
i.e. allow a portal to tell a user if they have
new email without the portal having “read
everything” permissions on mail store
Privacy sensitive
Attributes once aggregated are filtered
twice:
• Site wide policy as to what to release to
that service
• Overridden by User defined policy as to
what can be released
Attribute release policies
Attributes filtered through 2 release policies:
Site policy for all users arp.site.xml
User policy for that user arp.$Username.xml
User policy overrides site policy (for
paranoid users)
Attribute exchange format
• Attribute passed as SAML assertions
• SAML supports exchange of most
meaningful information
Text
– Kerberos tickets
– Images?
What is SAML
Security Assertion Markup Language
Xml for saying what someone is.
SAML = accepted and used standard
(MS/IBM/Sun/SAP/Oracle etc)
What SAML looks like
<Assertion xmlns="urn:oasis:names:tc:SAML:1.0:assertion"
AssertionID="_cc4528c6c29553ef23190249f829e65c" IssueInstant="2006-03-28T10:46:48.565Z"
Issuer="urn:mace:ac.uk:sdss.ac.uk:provider:identity:lock.ncl.ac.uk" MajorVersion="1" MinorVersion="1">
<Conditions NotBefore="2006-03-28T10:46:48.565Z" NotOnOrAfter="2006-03-28T11:16:48.565Z">
<AudienceRestrictionCondition>
<Audience>urn:mace:ac.uk:sdss.ac.uk:provider:service:emol.sdss.ac.uk</Audience>
<Audience>urn:mace:ac.uk:sdss.ac.uk:federation:sdss</Audience></AudienceRestrictionCondition></Condi
tions>
<AttributeStatement><Subject><NameIdentifier Format="urn:mace:shibboleth:1.0:nameIdentifier"
NameQualifier="urn:mace:ac.uk:sdss.ac.uk:provider:identity:lock.ncl.ac.uk">_1b4b75b3d32cd5as1237s
qensad8h127612</NameIdentifier></Subject>
<Attribute xmlns:typens="urn:mace:shibboleth:1.0" AttributeName="urn:mace:dir:attributedef:eduPersonScopedAffiliation"
AttributeNamespace="urn:mace:shibboleth:1.0:attributeNamespace:uri"> <AttributeValue
Scope="ncl.ac.uk" xsi:type="typens:AttributeValueType">
</AttributeValue></Attribute>
member
<Attribute xmlns:typens="urn:mace:shibboleth:1.0" AttributeName="urn:mace:dir:attributedef:eduPersonPrincipalName“
AttributeNamespace="urn:mace:shibboleth:1.0:attributeNamespace:uri"> <AttributeValue
Scope="
" xsi:type="typens:AttributeValueType">
</AttributeValue> </Attribute>
ncl.ac.uk
</AttributeStatement>
</Assertion>
ncr18
Federations
Club of institutes agreeing to attribute formats and
code of conduct
Organisational convenience, not technically
necessary, easy enough to bypass and setup
agreement between two parties independently
Designed to cut down managerial overhead of
having a relationship with many service
providers
Can be in multiple Federations and have Bilateral
Agreements.
UK Federations
Development SDSS federation
Production - UK Access Management Federation
Launches in September
- for HE and FE
SDSS membership will roll into production federation
Athens:
Test federation for shib/athens Gateway
Bilateral Deployment
• Shib has no need for a federation.
• Federation handy place to stick the rules,
procedures, advertise services
• Deployment possible with no federation
https://authdev.it.ohio-state.edu/twiki/bin/view/Shibboleth/BilateralDeployment
Why we are backing shibboleth
Many competeing standards: MS passport, liberty alliance,
Ping identity
Shib has the momentum and drive in our sector
Standards based so interoperable.
“Identity + Access management is a process not a
technology” -Gartner
i.e. The approach is more important than the technology.
Shibboleth momentum worldwide
Actively Used in America, Switzerland, Finland
Australia, Hungary, Croatia actively deploying
Rest of Europe contemplating
American government looking at for governmental apps
Microsoft and Sun both interested in SAML/shibboleth, SAP
SAML based, IBM interested.
SAML technical editor = Shib lead developer
Momentum UK
JISC funded core middle ware program
£7 million over next 3 years
BECTA has settled on shibboleth
NHS in early stages but interested
Athens will be fully Shib compatible by 2007
Regionally:
£200k has come to Newcastle/Durham
£40k regionally via EPICS
Shibboleth in Newcastle
IAMSECT project
JISC funded, collaboration with Durham and
Northumbria
SAPIR project
Newcastle Library based
EPICS ePortfolios tag on
Life long learning portfolios transferable between
NORMAN institutes
IAMSECT
Pilot study: federated access to resources between
Durham and Newcastle
Medical students already shared
Shib enable
Durham blackboard
Newcastle Zope VLE
Newcastle Blackboard
Learn lessons with medics then role out for entire student
population.
SAPIR
• Replace Athens with Shib
• Metalib portal Shib access
• Access to the Reading list management
system.
• Aleph Library Management system access
The future of SSO technology
SAML standard about to hit 2.0
Support for multifactor auth
Single sign out
Support for browserless apps e.g. Lionshare
Liberty alliance (Sun&co) Microsoft, SAP
converging on SAML
Theory of shib,
summary
Single sign on badly needed
What shib is
How it works
The core concepts
The technology
Federated single sign on a reality
Momentum is behind shib
Shib,
How to do it
Installation
• Guides
• Overview
– Password stores
– Certificates
– Federations
– Attributes
– Release policies
• Special cases (windows, no federation)
Installation Guides
Guides at:
http://iamsect.ncl.ac.uk/deliverables/
http://www.matu.ac.uk/
http://www.switch.ch/aai/tech/
http://shib.kuleuven.be/
http://shibboleth.internet2.edu/
Guides are Mature, shib no longer bleeding edge
Overview
Setup the software:
Use Shib 1.3 much easier and better
Guided install via ant
Draft docs at
http://iamsect.ncl.ac.uk/deliverables/docs/shib_install_1_3/
Tricky bits
Authenticate against password store.
Get https Certificates.
Join federation's
Setup Attributes
Authn against Password Store
Choose:
1) password store
-.htpasswd, Active Directory, NIS, kerb, Radius
2) login technology;
- sets $REMOTE_USER on apache
Pubcookie
CAS
mod_auth_kerb
mod_auth_*
Pubcookie
Pubcookie
In use for 2+ years
Stable resilient infrastructure
Apache and Microsoft IIS
Can use LDAP or Kerberos to authenticate
Can used unix NIS (potential for migration)
Supports multiple Auth e.g. password and secure-Id
number
Possibly to heavy weight, Do something lightweight with
mod_auth_*
Certificates
Magic incantations:
openssl req -new -key idp.key > idp.csr.2006
Ugly + opaque + fiddly, but easy to do with a recipe
Signing:
Signing by CA required for Trust chain.
Thawte, Globalsign, SDSS, Athens
For 2 federation deployment (e.f. SDSS + athens) then
they need to share a CA and you have to use that.
Multiple CAs on one site
AA needs to be on separate virtual server from the login page.
Most shift the port
<shib.ncl.ac.uk:443>
login, cert = shib.ncl.ac.uk.crt (thawte signed )
< shib.ncl.ac.uk:8443>
AA, cert = shib.ncl.ac.uk.crt (thawte signed )
Can use a separate virtual server
<shib.ncl.ac.uk:443>
login, cert = shib.ncl.ac.uk.crt (thawte signed )
< aa.ncl.ac.uk:443>
AA, cert = aa.ncl.ac.uk.crt (SDSS signed )
Joining Federations
Admin:
SDSS: Letter on headed paper from high up saying you
will behave
Athens: Password policy audit
Fill in large form, talk to your Athens admin
• compatible CA signed cert.
• Athens and SDSS both support Thawte: can use same
one
Certificates
Required to communicate securely.
Signing by CA required for Trust chain.
Which CA ?
Prototyping, SDSS Athens
- free, easy.
Globalsign, Thawte, verisign
- £100 per year, easy once setup, setup is nasty.
Attributes administration
The process of setting up an attribute:
• Aggregation
• Release
• Acceptance
Aggregating Easy Attributes
<SimpleAttributeDefinition
id="urn:mace:dir:attribute-def:eduPersonAffiliation">
<DataConnectorDependency requires="echo"/>
</SimpleAttributeDefinition>
<CustomDataConnector id="echo"
class="edu.internet2.middleware.shibboleth.aa.attrresolv
.provider.SampleConnector"/>
Heavy weight Attributes
<SimpleAttributeDefinition id="urn:mace:dir:attribute-def:eduPersonEntitlement“
sourceName="sdssentitlement“ smartScope=“ncl.ac.uk”>
<DataConnectorDependency requires="db6"/>
</SimpleAttributeDefinition>
<JDBCDataConnector id="db6"
dbURL="jdbc:mysql://thing.ncl.ac.uk/database?user=thing&amp;password=thing"
dbDriver="com.mysql.jdbc.Driver"
maxActive="10"
maxIdle="5">
<Query>
SELECT course_code,
CASE course_code
WHEN 'A101' THEN 'urn:mace:ac.uk:sdss.ac.uk:entitlement:emol.sdss.ac.uk:restricted'
WHEN 'A106' THEN 'urn:mace:ac.uk:sdss.ac.uk:entitlement:emol.sdss.ac.uk:restricted'
WHEN 'O106' THEN 'urn:mace:ac.uk:sdss.ac.uk:entitlement:emol.sdss.ac.uk:restricted'
WHEN '3019P' THEN 'urn:mace:ac.uk:sdss.ac.uk:entitlement:emol.sdss.ac.uk:restricted'
WHEN '3384P' THEN 'urn:mace:ac.uk:sdss.ac.uk:entitlement:emol.sdss.ac.uk:restricted'
WHEN '5826P' THEN 'urn:mace:ac.uk:sdss.ac.uk:entitlement:emol.sdss.ac.uk:restricted'
ELSE 'none' END
as sdssentitlement FROM CMstudentdata WHERE loginid = ?</Query>
</JDBCDataConnector>
Release policies
ARP.xml
<Rule>
<Description>EMOL service at EDINA</Description>
<Target>
<Requester>
urn:mace:ac.uk:sdss.ac.uk:provider:service:emol.sdss.ac.uk
</Requester>
</Target>
<Attribute name="urn:mace:dir:attributedef:eduPersonEntitlement">
<Value release="permit">
urn:mace:ac.uk:sdss.ac.uk:entitlement:emol.sdss.ac.uk:restricted
</Value>
</Attribute>
</Rule>
Release policies
AAP.xml
<AttributeRule Name="urn:mace:dir:attributedef:eduPersonAffiliation“
Header="Shib-EP-UnscopedAffiliation"
Alias="unscoped-affiliation">
<AnySite>
<Value Type="regexp">
^[M|m][E|e][M|m][B|b][E|e][R|r]$
</Value>
</AnySite>
</AttributeRule>
Complex attributes
•
•
•
•
Use case
Generation
Problems
Lessons learned
Complex attributes: Example
“Medic restrict”
• Accessing medical content at EMOL
• Subset of resources e.g. Autopsy content
Requires entitlement attribute:
edupersonEntitlement
urn:mace:ac.uk:sdss.ac.uk:entitlement:emol.sdss.ac.uk:restricted
Complex attributes: students
• “Relatively” easy for studentsSimpleAttributeDefinition
id="urn:mace:ac.uk:sdss.ac.uk:entitlement:emol.sdss.ac.uk“
sourceName="sdssentitlement“
SELECT course_code,
CASE course_code
WHEN 'A101' THEN
'urn:mace:ac.uk:sdss.ac.uk:entitlement:emol.sdss.ac.uk:restricted'
WHEN 'A106' THEN
'urn:mace:ac.uk:sdss.ac.uk:entitlement:emol.sdss.ac.uk:restricted'
ELSE 'none' END
as sdssentitlement FROM CMstudentdata WHERE loginid = ?
• Find out if student is on one of three medical courses
Complex attributes: Staff
• Staff, registered manually over years
• Pick their own usernames, own email
address – most didn’t use @ncl.ac.uk
address
• No connection between Athens id and
Newcastle id
• NHS staff have ncl usernames
Solution?
Admin Problems
•
•
•
•
No tools to help the admin (yet)
Editing verbose opaque xml files by hand
Looking in verbose opaque log files
Asking others to look in verbose opaque
log files at their end
• Security gets in the way
• Magic is cool flexible but hard to grasp.
Reality check
Shibboleth setup is relatively easy!
Recipes will get you a working usable install:
- you don’t have to understand it all to use it
Most of the complexity comes with advanced use
cases.
Techies like me talk about problems not successes
Technical help
• Us
– http://iamsect.ncl.ac.uk/deliverables/
• MATU
- http://www.matu.ac.uk/
• Internet2 –
– http://shibboleth.internet2.edu/
– https://authdev.it.ohiostate.edu/twiki/bin/view/Shibboleth/WebHome
• SDSS federation –
– http://sdss.ac.uk/wiki/wiki.pl?SdssWiki
Windows Installation
Recent, Java only install on tomcat
http://shib.kuleuven.be/docs/idp/install-idp-1.3-windows2003.shtml
Needs ssl certs and keys in pks12 format
c:\pki>openssl pkcs12 -export -in idp.crt -inkey idp.key -out idp.p12 name "tomcat" -CAfile myRootCA.crt -caname myRootCA -CAfile
myFirstIntermediateCA.crt -caname MyFirstInte[...] -chain
May have Limited SAML profile support:
- probably good enough.
SAML Profiles
What are profiles?
Different flows and use cases for exchanging
SAML assertions.
Profile defines constraints and/or extensions of the
core protocols/assertions for a particular use
case.
Basically it a flavour of SAML to be used in a
particular way
SAML Profiles
The profiles:
Post (default)
IdP encodes the form data in an HTML form via the user's browser assertion to the
SP. Javascript in th form allows auto-submit as a HTTP POST to the SP's assertion
consumer service. The authentication assertion passes through the user's browser in
the clear, in privacy sensitive environments it is not usual for attributes to be included
(so-called AttributePush). Instead, the SP performs an attribute query to the IdP's
attribute authority over an SSL-protected channel to acquire the subject's attributes.
Artifact
IdP returns an opaque reference (artifact) to attribute assertion to SP via an HTTP
redirect. The SP dereferences it to acquire the original assertion by accessing the
IdP's artifact resolution service
Attribute Push (new)
Delivery of attributes together with a SAML authentication assertion. Eliminates an
extra SOAP callback/query for the attribute information. It is the default in 1.3 when
the BrowserArtifact Profile is used, but can be enabled with BrowserPOST as well. In
that case, attribute information will be pushed through the client and this may have
privacy implications in some environments.
Post installation
Creating a coherent user experience?
Branding
Error handling
Hardening the install
Monitorring
Clustering
Branding user experience
At present no Cohesive user experience:
lack of clarity?
user education problems?
Why Brand?
• Users know what the process is
• Can educate about security
– Prevent spoofing, phishing
• They can complain about it properly :
– i.e. not “the internet is broken again”
http://www.internet2.edu/trademarks/shibboleth/
Logos and branding
Support Issues
Testing
• The need for testing
• How to test
• Access Problems:
-why they will happen
-what they look like
-what should they look like
The need for testing
The fantasy
Shibboleth need accurate, easily locatable user information
The reality
Information stores are:
• dispersed,
• inaccessible,
• incomplete,
• out of sync,
• conflicting.
Attributes accuracy is “a best effort” not a certainty
Things will go wrong
Examples
EdupersonScoped Affiliation
• Ability to login should = ncl affiliation
- NHS staff
-101 edge cases
EdupersonEntitlement medic restrict
urn:mace:ac.uk:sdss.ac.uk:entitlement:emol.sdss.ac.uk:restricted
Identifying medics is hard,
There will be plenty of problems
The problem of testing
• How do you test access control setup for
all the different user types?
• Test users are difficult to setup,
• In multiple attribute store scenario they
have to be in all stores.
• some stores don’t understand “fake users”
When things go wrong
• Middleware is invisible:
- when it works
- when it doesn’t
- users unaware of what success looks
like, therefore unaware of failure
-federated content means federated errors
Similar to networking problems
Access to EMOL
Access without proper scopedAffiliation
Access to EMOL
Access without medical entitlement
• Tells you something is wrong
• However no obvious route to rectify it
Local VLE
Access by non med school user
What improperly registered medics see
WAYFs
The “Best Worst” solution
- ugly but usable
- itching for better solutions
- not Technically necessary
Need to get user from SP to IdP to login
- Many approaches
Standard WAYF
Multi fed WAYF
Direct linking
Passing IdP as parameter
Seamless WAYF
Seamless WAYF
Auto WAYF redirection for users with a Kerberos login
e.g. users on campus machines:
Requires:
Browser supports Negotiate authentication and
permits use by WAYF.
Kerberos cross-realm trust must exist between each
IdP and the WAYF
If Login server + browser support Negotiate then Auto
login
Degrades gracefully for home users.
Service Hardening
Automated Monitoring
Problematic:
monitor across 3 sites:
IdP, SP, WAYF.
Monitor 4 stages
Login
Attribute aggregation
Attribute release
Attribute acceptance
“Just because it is up doesn’t mean it is working”
Service Hardening
Service starts hard:
2 years of operation, no daemon failures.
Modular clusterable architecture,
Login store (AD) clusterable
weblogin cluserable
Shib now clusterable
(HAshib last piece in puzzle)
Questions?