Current stuff (or things no one else has talked about yet) (at least while I was in the meeting) - PowerPoint PPT Presentation

1 / 42
About This Presentation
Title:

Current stuff (or things no one else has talked about yet) (at least while I was in the meeting)

Description:

(or things no one else has talked about yet) (at least while I was in the meeting) Ken Klingenstein Director, Internet2 Middleware and Security – PowerPoint PPT presentation

Number of Views:134
Avg rating:3.0/5.0
Slides: 43
Provided by: educ547
Category:

less

Transcript and Presenter's Notes

Title: Current stuff (or things no one else has talked about yet) (at least while I was in the meeting)


1
Current stuff(or things no one else has talked
about yet)(at least while I was in the meeting)
Ken Klingenstein Director, Internet2 Middleware
and Security
2
Topics
  • Federating software update
  • Federations update
  • International
  • InCommon
  • US Gov Eauth federation InCommon B/S
  • Peering of federations
  • USHER and PKI
  • FFIEC
  • User-centric identity, CardSpace, SXIP, etc. and
    the Holy Grail of Identity Management
  • But its really about authorization SOX,
    Privilege Management, Signet and Grouper
  • The wisdom and folly of Anders rant

3
Federating Software Update
  • Shib 1.3 in production for a long time
  • MS WS-Fed capable
  • E-Auth certified
  • GridShib basic capable
  • Shib 2.0 out at the end of the year
  • Shib-a-likes
  • Sun Federation Manager and Shib 1.3/2.0
  • Others

4
Application integration
  • Access to online content, from scholarly to
    popular
  • Access to digital repositories and federated
    search
  • Submissions of materials, from grant proposals to
    tests and exams
  • Non web applications p2p file sharing, Grids,
    etc. are beginning to leverage federated
    identity

5
Shibboleth 2.0 Features
  • What is the definition of Shibboleth 2.0? Is a
    new profile needed?
  • Convergence with commercial Liberty and SAML
    products
  • Support for the published Shibboleth profile
    (would not interoperate with Shibb v1.2?)
  • Support for SAML 2.0 AuthN, Logout, Attribute
    Artifact, and NameID management requests
  • everything but AuthnQuery and AuthzDecisionQuery)
  • how applications would influence the AuthnRequest
    process

6
Shib Add-ons
  • Institutional Privacy Managers (e.g. ShARPE from
    Australia)
  • Personal Privacy Managers
  • Lionshare (peer-to-peer file sharing coupled to
    enterprise)
  • GridShibs

7
Shib adoption
  • As noted below, widespread adoption overseas
  • Several million students and teachers in UK,
    replacing Athens as the bulk content mechanism
  • Production at every university in Switzerland,
    Finland national deployments underway in
    Australia, Germany, Denmark, France, etc
  • Elsevier, EBSCO, Thomson, OCLC, JSTOR, Napster,
    Ruckus, etc all have Shib in production or in an
    upcoming release
  • Several hundred US universities registered in
    InQueue about a hundred in production about 30
    in InCommon

8
Research and Education Federations
  • Growing national federations
  • UK, France, Germany, Switzerland, Australia,
    Netherlands, Norway, Spain, Denmark, etc.
  • Stages range from fully established to in
    development scope ranges from higher ed to
    further education
  • Many are Shib-based all speak SAML on the
    outside
  • Several million users and growing
  • First goals are content access additional goals
    include bandwidth allocation, network monitoring,
    security, etc.

9
US Federations
  • InCommon
  • (InQueue)
  • State-based
  • Texas, UCOP, Maryland, etc.
  • For library use, for roaming access, for payroll
    and benefits, etc.
  • US Gov Federal eAuthentication Initiative

10
InCommon
  • US RE Federation
  • www.incommonfederation.org
  • Members join a 501(c)3
  • Addresses legal, LOA, shared attributes, business
    proposition, etc issues
  • Approximately 35 members and growing
  • A low percentage of national Shib use

11
Key questions in federations
  • It doesnt seem to be about the technology or
    model anymore
  • SAML 2.0 in most IdM vendors blueprints (except
    MS) some will ship with Shib profiles embedded
  • It is about whether the core IdM systems are open
    or proprietary with open APIs.
  • What is the integration with other trust fabrics
    (e.g. eduRoam.us, PKI hierarchy, state and local
    federations)
  • Can federations happen in the US, or will we be
    bi-lateral hell?

12
Inter-federation key issues
  • Peering, peering, peering
  • At what size of the globe?
  • Confederation
  • Tightly coupled autonomous federations
  • How do vertical sectors relate? How to relate to
    a government federation?
  • On what policy issues to peer and how?
  • Legal framework
  • Treaties? Indemnification? Adjudication
  • How to technically implement
  • Wide variety of scale issues
  • WAYF functionality
  • Virtual organization support

13
In the USInCommon US Gov Fed alignment
  • Promote interop for widespread higher-ed access
    to USG applications
  • grants process, research support, student loans
    ...
  • Static peering
  • Of InCommon Bronze/Silver and EAuth
  • InCommon Bronze is a subset of InCommon, with a
    defined set of Identity procedures and federation
    operations
  • Definition of peering attribute mappings, LOA,
    legal alignment, etc.
  • Draft SAML 2.0 eAuthentication Profile
  • Draft USPerson

14
InCommon Bronze/Silver
  • InCommon B/S is a higher assurance sub-federation
  • Federation operations up a notch over InCommon
  • Members do better Identity Management
  • Bronze members likely a small subset of InCommon
    members common management infrastructure
  • Differences may include
  • Password management and identity proofing for
    some users most users may still be lower level
  • Liability and indemnification
  • Explicit operational responsibilities for members
    and federated operator (signing key revocation,
    etc)
  • Internal audits once a year of IdM practices

15
Coordinating with big players
  • Content providers heavily federation oriented
  • Almost all major academic content providers now
    support Shibboleth and federated identity
  • Important issues include
  • Presenting selection of federations and IdPs to
    users
  • Simple approach to common attributes and release
    policies
  • Business model implications
  • MS using federations to distribute student
    software

16
Virtual organizations and federations
  • One major driver for federations is their ability
    to support effective and scalable AAI for virtual
    organizations.
  • Numerous GridShib projects exist, perhaps too
    many
  • Can a set of peering federations be in place to
    support federated Grid implementations and what
    are the transition strategies?
  • Support the metadata exchange and consistency

17
GridShib
  • A set of approaches seeking to leverage the
    strengths of federated identity and privilege
    management with science Grids
  • Projects in 6-8 different countries, addressing
    different stress points in grids today.
  • Some are kludge layered on kludge some are steps
    in a long-term set of strategies

18
Overall strategy
  • Provide a coherent experience to the user,
    integrating their primary employer IdM with their
    research science needs for authentication and
    privilege management
  • Build an operational trust/attribute layer of
    federations of enterprises to support clusters of
    virtual organizations.
  • Based on Shibboleth and Signet/Grouper and
    Globus, etc.

19
Usher Update
  • It is operational
  • Operations at I2 and Dartmouth
  • PA chaired by Jim Jokl
  • Cert profiles, CP/CPS baked
  • LOA-free
  • A fee schedule is being finalized
  • A few use cases, but applications, sigh

20
FFIEC
  • Insufficiency of single factor authn for most
    on-line banking transactions
  • Lots of alternatives
  • many banks preferring OTP (paper/electronic)
  • digital sig otps
  • smartcards
  • Passive secondary authentication technologies
    being marketed
  • Dynamic risk assessment approaches tied into a
    web-management system
  • Phishing is equally important as authn due to
    e-commerce multifactor does not address well

21
Peer to peer trust and identity
  • A large part of our real lives
  • Has taken lots of on-line forms
  • PGP for email
  • SXIP, Higgins, etc for identity
  • Names versus locations as the permanence
  • In Vista as Cardspace (formerly InfoCard)
  • Self-signed X.509 deep under the covers
  • A great GUI and tight coupling to MS applications
    (videoconferencing, signed email, firewall, file
    sharing, etc.)

22
User-centric identity
  • The integration of the two main streams of trust
  • The enterprise, and federated, IdM
  • The peer-to-peer and group trust of social
    networking
  • Many layers of issues
  • The ones that matters most are the ones closest
    to the user (the eyeballs and the brainmap)
  • OSIS as an open source effort in this space

23
Its authorization, stupid
  • The real issues (once authn is done) are
    authorization.
  • SOX, HIPAA, etc really are authz policies
  • Authorization can be thought of as two phases
  • The compile time assignment of permissions,
    rights, etc to things
  • The run time decision on whether to grant access
    by the resource provider
  • The interesting stuff is the compile time pieces

24
Connecting SoAs, Integrating with Existing
Infrastructure
25
Signet and Grouper
  • Tools to manage privileges and groups
  • Taken together, they can provide tools for the
    static part of the authorization problem
    management of roles and privileges assigned to
    individuals (and other things)
  • Newly released 1.0 versions of both, with a
    combined interface
  • International development community beginning to
    happen

26
Relative Roles of Signet Grouper
  • RBAC model
  • Users are placed into groups (aka roles)
  • Privileges are assigned to groups
  • Groups can be arranged into hierarchies to
    effectively bestow privileges
  • Grouper manages, well, groups
  • Signet manages privileges
  • Separates responsibilities for groups privileges

Grouper
Signet
27
Grouper Overview
  • Mix of manual and automation processes manage a
    common Group Registry
  • Stored in an RDBMS
  • Automation processes provision info from the
    Group Registry to wherever the value of the info
    warrants spending the resources to place it there
  • Two types of managed objects groups and
    namespaces (or naming stems)
  • Groups are created named within namespaces
  • Group management authority is delegatable
  • By group or by namespace

28
Grouper Architecture
29
Five Ways to Delegate Group Management
  1. Create a group and assign someone to manage its
    membership (UPDATE)
  2. Create a group and assign someone to manage who
    manages the groups membership and who can see
    what about the group (ADMIN)
  3. Create a namespace and assign someone to create
    groups within it (CREATE)
  4. Create a namespace and assign someone to manage
    who can create groups within it (STEM)
  5. Allow Self to OPTIN or OPTOUT of membership

30
Signet Overview
  • Analysts define privileges in Signet in
    functional terms and specify associated
    permissions
  • Signet presents this view in a Web UI where users
    assign privileges and delegate authority across
    all areas in which they have authority
  • Signet internally maps assigned privileges into
    system-specific terms needed by applications
  • Stored in an RDBMS, the Privilege Registry
  • Privileges are published as XML docs,
    transformed, provisioned into applications and
    infrastructure services

31
Privileges Building Blocks
  • Functional view
  • Subsystems
  • Categories
  • Functions
  • Scope, Limits
  • Prerequisites Conditions
  • System view
  • Permissions
  • Subject
  • Action
  • Resource

32
Signet Components
Financial system Student Administration HR
system Network access management Research
administration Clinical resources XYZGrid Signet
(Privilege Registry) Grouper (Group Registry)
Subsystems
  • Define domains of ownership and responsibility
  • Reflect real world boundaries
  • Can be large or small

33
Functional View
Subsystems contain
  • Limits
  • Qualifiers, constraints for a privilege.
  • Scope
  • Organizational hierarchy governing distributed
    delegation,
  • Functions
  • The things a person can do what they are
    getting privileges for.
  • Categories
  • Provide useful arrangement of functions within a
    subsystem for reporting, ease of use.

34
Functional View ? Permissions
Calendar
Student Admin
reserve_time
view_schedules
Add/Drop students
Course Support
Course
Schedule Classes
update_course_data
Facilities
reserve_room
Process Applicants
Financial Aid
Financial
Award Scholarships
view_fund_data
Manage Accounts
update_fund_data
Student
student_records
categories
functions
applicant_data
Resources/Permissions
Functional View
35
Provisioning Permissions into Applications
(connectors)
Calendar
CourseWare
Financials
Reporting
or
API
Space Mgmt
Student
36
Provisioning Permissions into Infrastructure
(LDAP)
Calendar
eduPersonEntitlement
CourseWare
Directory
Financials
Reporting
Space Mgmt
Student
37
Privileges Lifecycle
  • Conditions
  • Provides automatic revocation of privileges
  • Date controls -- from date, until date
  • Based on persons status, affiliation, etc.
  • e.g., as long as person is at Stanford
  • Prerequisites
  • Pre-conditions that must be met to activate
    privileges
  • e.g., training

38
Privilege Elements by Example
By authority of the UPCI IRB grantor
UPCI Researchers grantee (group/role)
who have an approved UPCI IRB protocol prerequisite
can access de-identified data and order tissue function
from the network of caTIES participants scope
for Study HD7687 resource
up to 100 patients limit
until January 1, 2006 as long as approved for material transfer conditions
Lifecycle
Privilege
39
The duck test
  • Grouper
  • Binary info youre either in some list or not
  • Identity- or affiliation-based access control or
    distribution
  • Identification layer of an encompassing access
    management scheme
  • Locally tweak or combine other groups
  • Signet
  • Structured, qualified info limits, conditions,
    scope,
  • Oriented to individuals rather than roles
  • Human judgment and chain of authority essential
    for access decisions
  • Enable functional, not just technical, people to
    manage privileges
  • Supports policy control closer to source of
    authority
  • Audit requirements

40
Anders Rant 1
  • Its enterprise to enterprise that matters
  • That implies that roles are useful and important
  • That provides some degrees of enterprise freedom
  • Reasonable non-repudiation is reasonably easy

41
Anders Rant 2
42
InCommon B/S
  • We have used a combination of feedback from this
    credential assessment, the entropy tool, and NIST
    guidelines to determine what was needed to reach
    LOA1.  We have applied a password policy for all
    passwords that are changed that include the
    following
  • 1. It must be at least eight characters in
    length (Longer is
  •    generally better.)
  • 2. It must contain at least one alphabetic and
    one numeric character.
  • 3. It must be significantly different from
    previous passwords.
  • 4. It cannot be the same as the userid.
  • 5. It cannot start or end with the initials of
    the person issued the
  •    userid.
  • 6. It cannot include the first, middle, or last
    name of the person
  •    issued the userid.
  • 7. It cannot contain three or more occurrences of
    the same character.
  • 8. It cannot contain any special characters
    (blanks, single quotes,
  •    double quotes and so on).
  • 9. It should not be information easily obtainable
    about you. This
  •    includes license plate, social security,
    telephone numbers, or
  •    street address.
  • We are also in the process of determining the
    best approach and starting communications for
    enforcing annual password changes.  We believe
    with these changes we are very close to meeting
    requirements for LOA2 as well.
Write a Comment
User Comments (0)
About PowerShow.com