Autorisierung und rollenbasierte Sicherheit in 'NET Anwendungen - PowerPoint PPT Presentation

1 / 23
About This Presentation
Title:

Autorisierung und rollenbasierte Sicherheit in 'NET Anwendungen

Description:

Microsoft Deutschland GmbH. Juergen.Pfeifer_at_microsoft.com. Role-Based Security ... An identity contains information about a user, such as the user's logon name. ... – PowerPoint PPT presentation

Number of Views:69
Avg rating:3.0/5.0
Slides: 24
Provided by: downloadM
Category:

less

Transcript and Presenter's Notes

Title: Autorisierung und rollenbasierte Sicherheit in 'NET Anwendungen


1
Autorisierung und rollenbasierte Sicherheit in
.NET Anwendungen
  • Jürgen Pfeifer
  • Senior Architect Evangelist
  • Developer Platform Strategy Group
  • Microsoft Deutschland GmbH
  • Juergen.Pfeifer_at_microsoft.com

2
Role-Based Security
  • Code runs on behalf of a user
  • Users have roles
  • Declarative and imperative Checks
  • Principals and Identities

IsInRole("Administrator") ??
Identity Jane Roles Administrator, Developer
3
Identities and Principals
  • An identity contains information about a user,
    such as the users logon name. Abstracted by the
    IIdentity Interface.
  • A principal contains role information about a
    user or computer. Abstracted by the IPrincipal
    Interface.
  • The .NET Framework provides
  • WindowsIdentity and WindowsPrincipal objects
  • FormsIdentity and PassportIdentity for ASP.NET
  • GenericIdentity and GenericPrincipal objects
  • Custom and 3rd-Party implementation
  • e.g. an Implementation by IBM to derive
    Identities and Principals from the Tivoli Access
    Manager

4
Performing Security Checks
  • Use Identity and Principal members in code
  • For example, using the Name property of the
    Identity object to check the users logon name
  • For example, using the IsInRole method of the
    Principal object to check role membership

if (String.Compare(myPrin.Identity.Name,
"DOMAIN\\Fred", true)0) // Perform some
action
if (myPrin.IsInRole("BUILTIN\\Administrators"))
// Perform some action
5
Imperative and Declarative Security Checks
  • Use permissions to make role-based security
    checks
  • Imperative checks

PrincipalPermission prinPerm new
PrincipalPermission(null, Teller, true) try
prinPerm.Demand() //Does the above match the
active principal?
  • Declarative checks

PrincipalPermission(SecurityAction.Demand,
Role"Teller", Authenticatedtrue)
6
Application Authorization Needs
  • Resource Managers
  • Well-defined, Persistent Resources.
  • Filesystem, Registry, Directory
  • Gatekeepers
  • Controls access to other applications
  • e.g. Web Server
  • Line of Business Applications
  • Resources arent well defined or persistent
  • Access operations, processes, workflows
  • E.g. Submit expense

7
Impersonation Vs Trusted Subsystem
  • Impersonation
  • Get client token, impersonate, access resources
  • Audit close to data
  • Access Limited to connected user
  • ACLs on Back end need to be maintained
  • Connection pooling is difficult
  • Users can potentially access back end data out
    of band
  • Trusted Subsystem
  • Service Authorizes client requests, performs
    actions in service context
  • Minimizes back end ACL management (grant Service
    needed access)
  • Allows connection pooling.
  • Users cant directly touch back end data
  • Audits must be correlated
  • Service account password must be maintained

8
Goals for Authorization Manager
  • Role-Based framework for LOB Apps
  • Access control defined by job need
  • Rights maintained at Roles not objects
  • Better Manageability
  • Task concept Grouping permissions
  • User centric What can Employees do?
  • Simple No ACL-inheritance
  • More Natural for Development
  • ACLs can be unnatural for some apps
  • Simple, scriptable interfaces

9
Development Goals
  • Simple Natural Role-based development
  • Define Operations, Tasks, Roles, Biz rules
  • Provide flexible application scoped groups
  • Application admins dont need domain admin to
    create groups
  • Platform services do the hard work
  • Policy storage, Common UI
  • Built-in caching, Late-binding support,
  • Auditing

10
Administration Goals
  • User provisioning, not resource protection
  • Assigning groups and users to roles (not objects)
  • Manage Roles and Scopes
  • Not objects and hierarchies.
  • Delegation
  • Common Administration Easy
  • Hide complexity of operations
  • Defining roles, tasks rare (_at_ design)
  • Maintaining Roles Groups

11
Authorization Manager
  • Role
  • What someone may need to be able to do as part of
    their job.
  • Task
  • Work-Units that make sense to administrators
  • Biz Rule (Authorization Script)
  • Script to Dynamically modify Access decision
  • Scope
  • Collection of resources with common policy.
  • Defines where one or more roles may apply
  • Groups
  • Application Specific, Late-bound, Flexible

12
Authorization Manager
AD
XML
AzAuthorizationStore
AzApplication
AzApplicationGroup
Declarative, Query
AzOperation
AzApplicationGroup
AzTask
BizRule
AzRole
AccessCheck
AzClientContext
AzScope (Roles, Tasks, Groups)
13
RoleTasks, TaskOperations
Web Expense Application
Database Operation
Web Operation
Directory Operation
Payment System Operation
14
Role Definitions Assignments, Scopes
Web Expense Application
Role Definitions
Submitter
Administrator
Approver
Submitter Employees
Scope Default
Web Expense Role Assignments
Approver QueryGroup_D1Mgrs Administrator
Jane, Lizzy
Dept 01 Role Assignments
Scope Dept 01
Approver ADGroup_D2Mgrs Administrator
Jane, Charlie
Scope Dept 02
Dept 02 Role Assignments
15
Enterprise Roles
AD
Use AD Groups to populate Application level Roles
Employee (AD Group)
Web Expense Application
Supply Application
DataBase Application
Employee
Employee
Employee
16
Development Model
  • Application Development
  • Implement operations, Tasks, BizRule scripts
  • Install - Declare Policy definition
  • Operations, Tasks (w/ BizRules), Some Roles
  • Runtime
  • AzInitializeAdminMgr,AzInitializeApplication
  • On Client Connect
  • AzInitializeContext (from NT token or UserName or
    Sid)
  • Render UI GetRolesForUser
  • On Operation Request
  • AzClientContext.AccessCheck(Scope, Operation
    Operation Data)
  • Biz Rules are automatically executed.

17
Role-Based Common UI
  • Multiple Applications
  • Application Groups
  • Static, LDAP Query
  • Store-level (Global to Apps in Store )
  • Assign Store-level Groups to Roles
  • Developer Mode
  • Create Apps/Operations

18
New For Longhorn
  • SQL Storage Support
  • Provide SQL storage mechanism
  • Popular request of departmental apps
  • Expanded LDAP Query support
  • Queries on any DN (not just users)
  • Expanded BizRule support
  • Support group membership based on rules

19
New For Longhorn
  • UI object picker customization
  • Add support for Apps to provide ADAM object
    picker
  • Enhanced / Debugging Logging
  • More debugging API
  • Improve V1 logging support
  • Log more events, easier to use

20
Longhorn Improvements
  • Simplify developer experience
  • Role-definition object
  • Simplify Biz Rule usage
  • Performance improvements
  • Optimized interfaces for managed application
  • Store creation
  • Application initialization

21
Fragen und Antworten
22
Mehr Informationen
  • W2K3 Admin Tools Pack (works also on
    XP)http//www.microsoft.com/downloads/details.asp
    x?FamilyIDe487f885-f0c7-436a-a392-25793a25bad7Di
    splayLangen
  • How to use AzMan with ASP.NET 2.0http//msdn.micr
    osoft.com/library/default.asp?url/library/en-us/d
    npag2/html/paght000019.asp
  • How to use AzMan with WSE 3.0http//msdn.microsof
    t.com/msdnmag/issues/05/11/AzManandWSE30/default.a
    spx

23
Ihr Potenzial. Unser Antrieb.
Write a Comment
User Comments (0)
About PowerShow.com