DOCSLIB.ORG

Using Globus Auth to Streamline the Creation, Integration, and Use of Research Services

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Using Globus Auth to Streamline the Creation, Integration, and Use of Research Services Using Globus Auth to Streamline the Creation, Integration, and Use of Research Services Steve Tuecke [email protected] Cloud has transformed how software and platforms are delivered Software as a service: SaaS (web & mobile apps) Platform as a service: PaaS Infrastructure as a service: IaaS PaaS enables more rapid, cheap, and scalable delivery of powerful (SaaS) apps 2 3 Globus SaaS: Research data lifecycle Compute Facility Instrument Globus transfers files reliably, securely 4 Globus controls access to shared 2 files on existing storage; no need to move files to Curator reviews and cloud storage! 7 Transfer approves; data set published on campus or other system 3 Share 1 Researcher 6 Researcher initiates selects files to transfer request; or share, selects Researcher requested automatically user or group, assembles data set; by script, science and sets access describes it using Publication gateway permissions metadata (Dublin core and domain- Repository Collaborator logs in to 5 specific) • Only a Web browser Globus and accesses shared files; no local Publish 6 8 required account required; download via Globus • Use storage system Peers, collaborators search and discover of your choice datasets; transfer and share using Globus • Access using your campus credentials Discover Personal Computer 4 Platform Questions • How do you leverage Globus services in your own applications? • How do you extend Globus with your own services? • How do we empower the research community to create an integrated ecosystem of services and applications? 5 Example: NCAR RDA 6 Prototypical research data portal Identity Provider Globus Web Globus Cloud HTTPS Helper Pages Globus Login Globus Auth Browser Transfer Applications Portal Web REST Other Server (Client) Services Desktop Firewall GridFTP User’s Portal Other Endpoint Endpoint Endpoints (optional) Science DMZ 7 Prototypical research data portal Identity Provider Globus Web Globus Cloud HTTPS Helper Pages Globus Login Globus Auth Browser Transfer Applications Portal Web REST Other Server (Client) Services Desktop Firewall GridFTP User’s Portal Other Endpoint Endpoint Endpoints (optional) Science DMZ 8 Next-Generation Portal Leverages Science DMZ Border Router perfSONAR Firewall WAN Enterprise Data Path Browsing path Query path 10GE perfSONAR perfSONAR Portal server applications: · web server · search · database Science DMZ · authentication Portal Switch/Router Server 10GE 10GE 10GE DTN 10GE 10GE Data Transfer Path DTN 10GE Filesystem (data store) Portal Query/Browse Path 10GE 10GE DTN DTN API DTNs (data access governed by portal) https://fasterdata.es.net/ 9 Globus Transfer API • Nearly all Globus Web App functionality implemented via public Transfer API docs.globus.org/api/transfer • Requests authorized via OAuth2 access token – Authorization: Bearer asdflkqhafsdafeawk 10 Transfer API Functionality • Endpoint search • Endpoint management • Endpoint activation • File operations • Task submission • Task management • Bookmarks • Shared endpoint access rules (ACLs) • Management console 11 Globus Python SDK • Python client library for the Globus Auth and Transfer REST APIs globus.github.io/globus-sdk-python • Public beta, likely to change some • Open source 12 Python SDK Jupyter notebook • Jupyter (iPython) notebook demonstrating use of Python SDK github.com/globus/globus-jupyter-notebooks • Overview • Open source 13 Prototypical research data portal Identity Provider Globus Web Globus Cloud HTTPS Helper Pages Globus Login Globus Auth Browser Transfer Applications Portal Web REST Other Server (Client) Services Desktop Firewall GridFTP User’s Portal Other Endpoint Endpoint Endpoints (optional) Science DMZ 14 Challenge • How to provide: – Login to apps o Web, mobile, desktop, command line – Protect all REST API communications o App à Globus service o App à non-Globus service o Service à service • While: – Not introducing even more identities – Providing least privileges security model – Being agnostic to programming language and framework – Being web friendly – Making it easy for users and developers 15 Globus Auth • Foundational identity and access management (IAM) platform service • Simplify creation and integration of advanced apps and services • Brokers authentication and authorization interactions between: – end-users – identity providers: InCommon, XSEDE, Google, portals – services: resource servers with REST APIs – apps: web, mobile, desktop, command line clients – services acting as clients to other services 16 Globus Auth • Identity and access management PaaS docs.globus.org/api/auth • Introduction • Developer Guide • Reference 17 Based on widely used web standards • OAuth 2.0 Authorization Framework – aka OAuth2 • OpenID Connect Core 1.0 – aka OIDC • Use various OAuth2 and OIDC libraries – Google OAuth Client Libraries (Java, Python, etc.), Apache mod_auth_openidc, etc. – Globus Python SDK 18 Globus account • A Globus account is a set of identities – A primary identity o Identity can be primary of only one account – One or more linked identities o Identity can (currently) be linked to only one account • Account does not have own identifier – An account is uniquely identified using its primary identity 19 Globus Auth interactions Login App HTTPS/REST call Service (Client) (Resource Server) User (Resource Owner) Globus Auth (Authorization Server) Identity Provider 20 Globus Auth interactions Login App HTTPS/REST call Service (Client) (Resource Server) User (Resource Owner) Globus Auth 1.Request authorization (Authorization Server) • For a set of scopes – Login: openid, email, profile – HTTPS/REST APIs Identity • User selects identity provider Provider 21 Globus Auth interactions Login App HTTPS/REST call Service (Client) (Resource Server) User (Resource Owner) Globus Auth 1.Request authorization (Authorization Server) • Using existing identities 2.Authenticates a resource owner – XSEDE, University (via InCommon), Google, web app, etc. Identity • User can link multiple Provider identities into a single Globus Account • No Globus username (Globus ID) required • Globus Auth handles naming details, e.g., ePPN vs ePTID 22 Globus Auth interactions Login App HTTPS/REST call Service (Client) (Resource Server) User (Resource consent Owner) Globus Auth 1.Request authorization (Authorization Server) • Resource is provided by a 2.Authenticates a resource owner resource server 3.Obtains authorization (consent) for • Limited by a scope a client to access a resource Identity Provider 23 Globus Auth interactions Login App HTTPS/REST call Service (Client) (Resource Server) User (Resource access_token Owner) Globus Auth 1.Request authorization (Authorization Server) • Some grant types issue 2.Authenticates a resource owner authorization code, which 3.Obtains authorization (consent) for client exchanges for access a client to access a resource token 4.Issues OAuth2 access_token to Identity • Access token is opaque to client Provider client • May include a refresh token, for offline access 24 Globus Auth interactions Login App HTTPS/REST call Service (Client) (Resource Server) User (Resource id_token Owner) Globus Auth 1.Request authorization (Authorization Server) JWT id_token: 2.Authenticates a resource owner • sub: Globus Auth identity id 3.Obtains authorization (consent) for a client to access a resource • iss: https://auth.globus.org 4.Issues OAuth2 access_token to Identity • name: full name client Provider • preferred_username: 5.May issue OIDC id_token to client • e.g., [email protected] with resource owner identity • email: email contact • other standard OIDC claims 25 Globus Auth interactions Login App HTTPS/REST call Service (Client) Authorization: Bearer <access_token> (Resource Server) User (Resource Owner) Globus Auth 1.Request authorization (Authorization Server) 2.Authenticates a resource owner 3.Obtains authorization (consent) for a client to access a resource 4.Issues OAuth2 access_token to Identity client Provider 5.May issue OIDC id_token to client with resource owner identity 6.HTTPS/REST call with access_token 26 Globus Auth interactions Login App HTTPS/REST call Service (Client) (Resource Server) User (Resource Owner) access_token Globus Auth 1.Request authorization (Authorization Server) RFC 7662: OAuth 2.0 Token 2.Authenticates a resource owner Introspection response: 3.Obtains authorization (consent) for • active: true or false a client to access a resource • client_id 4.Issues OAuth2 access_token to Identity client Provider • scope 5.May issue OIDC id_token to client • sub: Globus Auth identity id with resource owner identity • username: [email protected] 6.HTTPS/REST call with • identity_set: linked identities access_token • email 7.Validates access_token for • name resource server, gets additional info • other standard claims 27 Globus Auth interactions Login App HTTPS/REST call Service (Client) (Resource Server) User Dependent (Resource access_token Owner) Globus Auth Dependent Services 1.Request authorization (Authorization Server) (Resource Servers) 2.Authenticates a resource owner 3.Obtains authorization (consent) for a client to access a resource • Allows resource server to 4.Issues OAuth2 access_token to Identity act as client to other client Provider resource servers 5.May issue OIDC id_token to client • Service uses request with resource owner identity access_token to get a 6.HTTPS/REST call with dependent access_token access_token for each dependent service 7.Validates access_token for • Service acts as client to its resource server, gets additional info dependent services
Load more

Recommended publications
  • What Is an Identity Provider? Why Does My Company Need to Become One?
    WHITE PAPER WHAT IS AN IDENTITY PROVIDER? WHY DOES MY COMPANY NEED TO BECOME ONE? Tame Mobile and Cloud Security Risks: Become an IdP Executive Overview Enterprises face security threats from all directions. According to the Identity Theft Resource Center, there were 189 known breaches from January 1 of this year through the beginning of June. Those breaches exposed approximately 13.7 million records. Meanwhile, trends intended to benefit the enterprise, such as cloud computing and mobility, often introduce unintended risks. The weak link in our online economy is trust. If you boil that down further, much of the lack of trust stems from the inability to verify online identities. It is increasingly difficult to know whether people (or companies) on the Internet are who they say they are. To address today’s security risks and to embrace new technology trends such as cloud, mobility and SaaS, enterprises must rethink how they handled their employees’ identities. Fortunately, the industry has been moving towards federated Single Sign On (SSO) solutions, and has been standardizing building blocks like SAML and OpenID. Enterprises should build on these standards in order to become Identity Providers (IdP). By becoming an IdP, companies can better control, enforce and extend security standards to all on-premise and cloud-based applications in their organizations, as well as to mobile devices. This paper will discuss the reasons enterprises should become IdPs, what becoming an IdP involves, and why you should automate as much of this process as possible. Introduction: New Security Risks Undermine Online Business In August 2012, a hacker crafted a wickedly specific social engineering attack to target Wired writer Mat Honan.
    [Show full text]
  • Beyond X.509: Token-Based Authentication and Authorization for HEP
    Beyond X.509: Token-based Authentication and Authorization for HEP Andrea Ceccanti, Marco Caberletti, Enrico Vianello, Francesco Giacomini INFN CNAF CHEP 2018 Sofia, July 12th 2018 The current WLCG AAI In operation since ~2003, and still working nicely: • X.509 trust fabric provided by IGTF (tells services which CAs are trusted) • X.509 certificates provided to users for authentication • Proxy certificates for Single Sign-On (SSO) and delegation • VOMS attribute certificates for attribute-based authorization (issued and Slide by Ákos Frohner signed by VO-scoped VOMS servers) Beyond X.509: Token-based Authentication & Authorization for HEP - CHEP 2018, Sofia 2 Current WLCG AAI: the weak points Usability • X.509 certificates are difficult to handle for users • VOMS does not work in browsers Inflexible authentication • Only one authentication mechanism supported: X.509 certificates • Hard to integrate identity federations Authorization tightly bound to authentication mechanism • VOMS attributes are inherently linked to an X.509 certificate subject Ad-hoc solution • We had to invent our own standard and develop ad-hoc libraries and central services to implement our own AAI Can we do better today? Beyond X.509: Token-based Authentication & Authorization for HEP - CHEP 2018, Sofia 3 A novel AAI for WLCG: main challenges Authentication Delegation • Flexible, able to accomodate • Provide the ability for services to various authentication mechanisms act on behalf of users - X.509, username & password, • Support for long-running EduGAIN, social logins
    [Show full text]
  • Identity Provider for SAP Single Sign-On and SAP Identity Management Document Version: 1.0 – 2017-05-15
    Implementation Guide PUBLIC Identity Provider for SAP Single Sign-On and SAP Identity Management Document Version: 1.0 – 2017-05-15 Identity Provider for SAP Single Sign-On and SAP Identity Management Content 1 Identity Provider for SAP Single Sign-On and SAP Identity Management....................4 1.1 What is SAML 2.0............................................................... 5 SSO with SAML 2.0........................................................... 6 SLO with SAML 2.0............................................................9 Identity Federation...........................................................10 Common Domain and Identity Provider Discovery.....................................14 Identity Provider Proxy........................................................16 1.2 Before Starting................................................................23 System Requirements........................................................ 23 Authorizations..............................................................24 Limitations of the Identity Provider................................................25 1.3 Adding an Identity Provider to Your Network...........................................26 Downloading and Installing the Federation Software................................... 26 Configuring the Identity Provider.................................................27 Enabling the SAML Identity Provider.............................................. 29 Configuring Back-Channel Communication..........................................31 Configuring
    [Show full text]
  • Securing Digital Identities in the Cloud by Selecting an Apposite Federated Identity Management from SAML, Oauth and Openid Connect
    Securing Digital Identities in the Cloud by Selecting an Apposite Federated Identity Management from SAML, OAuth and OpenID Connect Nitin Naik and Paul Jenkins Defence School of Communications and Information Systems Ministry of Defence, United Kingdom Email: [email protected] and [email protected] Abstract—Access to computer systems and the information this sensitive data over insecure channels poses a significant held on them, be it commercially or personally sensitive, is security and privacy risk. This risk can be mitigated by using naturally, strictly controlled by both legal and technical security the Federated Identity Management (FIdM) standard adopted measures. One such method is digital identity, which is used to authenticate and authorize users to provide access to IT in the cloud environment. Federated identity links and employs infrastructure to perform official, financial or sensitive operations users’ digital identities across several identity management within organisations. However, transmitting and sharing this systems [1], [2]. FIdM defines a unified set of policies and sensitive information with other organisations over insecure procedures allowing identity management information to be channels always poses a significant security and privacy risk. An transportable from one security domain to another [3], [4]. example of an effective solution to this problem is the Federated Identity Management (FIdM) standard adopted in the cloud Thus, a user accessing data/resources on one secure system environment. The FIdM standard is used to authenticate and could then access data/resources from another secure system authorize users across multiple organisations to obtain access without both systems needing individual identities for the to their networks and resources without transmitting sensitive single user.
    [Show full text]
  • From Identity-Based Authorization to Capabilities: Scitokens, Jwts, And
    From Identity-Based Authorization to Capabilities: SciTokens, JWTs, and OAuth Jim Basney [email protected] HTCondor Workshop Autumn 2020 25 September 2020 Goals for an HTC Authorization System ● Enable access to HTC! ● Implement appropriate resource/data access policies ● Ease of use ● Manageability ● Distributed/Decentralized 2 Authentication & Authorization Standards ● X.509: Certificates ○ Grid Security Infrastructure (GSI) ○ Virtual Organization Membership Service (VOMS) ● SAML: Security Assertion Markup Language ○ Using XML ○ Single Sign-on for Higher Education: eduGAIN / InCommon / Shibboleth ● JWT: JSON Web Tokens ○ Using JavaScript Object Notation (JSON) ○ Pronounced "jot" ○ Digitally signed, self-describing security tokens ● OAuth: Authorization Framework ○ Optionally using JWTs ○ Tokens for limited access to resources ● OIDC: OpenID Connect ○ An identity layer on top of OAuth ○ Using JWTs 3 X.509 Certificate Attribute Authority Authority Policy Policy Trust End Entity Attribute Certificate Certificate Data Node Submit Execute Policy Node Node Policy Policy 4 SAML Identity Provider Policy Trust Authentication Attribute Assertion Assertion Data Node Submit Execute Policy Node Node Policy Policy 5 JWT / OIDC / OAuth OpenID Authorization Provider Server Policy Policy Trust Access ID Token Token Data Node Submit Execute Policy Node Node Policy Policy 6 Credentials for Authentication / Authorization X.509 SAML OIDC OAuth / JWT Credential Issuer Certificate Authority Identity Provider OpenID Provider Authorization Server Credential
    [Show full text]
  • User Account and Authentication Service
    User Account and Authentication Service © 2020 General Electric Company Contents UAA Service Overview 1 About the User Account and Authentication Security Service 1 UAA Deployment Architecture 1 Understanding UAA and OAuth2 Access Token Flows 4 Obtaining Tokens Using Authorization Code Grant 4 Obtaining Tokens Using Implicit Grant 5 Obtaining Tokens Using Resource Owner Password Credentials Grant 7 Obtaining Tokens Using Client Credentials Grant 7 Understanding UAA and ID Tokens 9 Using UAA to Obtain ID Tokens 9 Get Started With the UAA Service 10 UAA Security Service Setup 10 Creating a UAA Service Instance 10 Binding an Application to the UAA Instance 13 Unbinding the UAA Instance From Your Application 15 Deleting a UAA Instance 15 Configuring the UAA Service Instance 16 About UAA Dashboard 16 Managing Clients 17 Managing Users 24 Creating Password Policies 27 Managing Identity Providers 28 OIDC Federated Authentication 37 Managing Tokens 68 Multifactor Authentication 71 Using UAA for Application Login or Logout Window 76 Using UAA to Set Up Application Login or Logout 76 Customizing the UAA Login Window for Your Application 76 Troubleshooting UAA Service 78 Troubleshooting UAA Service 78 UAA Release Notes 81 ii User Account and Authentication Service UAA Release Notes 81 iii Copyright GE Digital © 2020 General Electric Company. GE, the GE Monogram, and Predix are either registered trademarks or trademarks of General Electric Company. All other trademarks are the property of their respective owners. This document may contain Confidential/Proprietary information of General Electric Company and/or its suppliers or vendors. Distribution or reproduction is prohibited without permission. THIS DOCUMENT AND ITS CONTENTS ARE PROVIDED "AS IS," WITH NO REPRESENTATION OR WARRANTIES OF ANY KIND, WHETHER EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO WARRANTIES OF DESIGN, MERCHANTABILITY, OR FITNESS FOR A PARTICULAR PURPOSE.
    [Show full text]
  • How to Extend Identity Security to Your Apis EXECUTIVE OVERVIEW
    HOW TO EXTEND IDENTITY SECURITY TO YOUR API’S WHITE PAPER TABLE OF CONTENTS 03 EXECUTIVE OVERVIEW 04 INTRODUCTION 05 OAUTH 2.0 – THE PRESENT AND FUTURE CHOICE FOR API PROTECTION How OAuth 2.0 Works 08 SAML – THE GOLD STANDARD FOR IDENTITY FEDERATION How SAML and OAuth 2.0 Work Together 10 OPENID CONNECT – CONVERGENCE IN IDENTITY STANDARDS How Connect Works 11 CONCLUSION 12 SECURING API’S WITH PING IDENTITY 2 WHITE PAPER How to Extend Identity Security to Your APIs EXECUTIVE OVERVIEW The number of users and devices requesting access to applications is growing exponentially, and enterprises are scrambling to adapt their authentication and authorization infrastructure to deal with this fast growth. REST APIs are a critical new application access channel. In a sense, REST APIs are an evolution of the SOAP-based web services of a few years ago. But because they’re much more practical for mobile clients (like native iOS and Android apps), the challenge of scaling more than SOAP web services is compounded. A REST API may be called by millions of clients, which is far more than a SOAP web service. But early deployments of REST APIs were often authenticated by passwords being attached to the client calls. For instance, if the calls were being made on behalf of a particular user (to obtain calendar data as an example) then the user would be asked to share with the API client the password for their account at the calendar provider. This model of authentication has significant privacy and security issues, including: • It’s very hard for the user to subsequently turn off the access for a given client if they want.
    [Show full text]
  • Digital Identity and Identity Management Technologies
    I. Agudo, \Digital Identity and Identity Management Technologies", UPGRADE - The European Journal of the Informatics Professional, vol. 2010, pp. 6 - 12, 2010. NICS Lab. Publications: https://www.nics.uma.es/publications Digital Identity and Identity Management Technologies. Abstract: There are many technologies for identity management available in the form of open specifications, open source tools and commercial applications. Currently, there are some competing standards for identity management. At the beginning SAML was the only viable choice with a higher enough acceptance level. Recently, another technology called WS‐Federation has also gain some attention from the community. Although this technology is not as mature as SAML, it modular design gives it some advantages over SAML. It this work we mainly focus on the WS‐Federation and the family of specifications that surround it. Keywords: Identity Management, Identity Federation, Web Services Introduction It is hard to find a globally accepted definition of the term Identity and even harder to precisely define what is understood by Identity Management. A simplistic approach would consist on defining identity management as user accounts management in a software system. This was the general understanding some decades ago but in the last years, with the emergence of the Internet of Services, more complex aspects have arisen and the identity of its users have become crucial. In the first software systems, the identity of users was managed locally by the system administrator and was only valid for this particular application. In the Internet of Services, anyone can become a user of our applications and is the responsibility of the user to “manage” its identity in a proper way.
    [Show full text]
  • Remote Access to E-Resources Anywhere
    Parveen Bababr Deputy Librarian, JNU (India) Remote Access in simple language is the ability to access a computer / server remotely through a network connection. The users have leverage to work remotely away from the institution/ office while retaining access to a distant computer or network. Remote Access can be applicable for Local Area Networks (LANs), Wide Area Network (WANs) and Virtual Private Networks (VPN) Remote access refers to: Connection to a data-processing system from a remote location, for example through a virtual private network or remote desktop application Remote desktop software, refers to a software or an operating system feature enabling applications to be run remotely on a server while being graphically accessible locally. Direct (Physical) Line: Through the direct line control can be implemented between a computer and institution LAN. Similar line can be used to connect a home LAN and a institution LAN. This network is faster but is more expensive and have high maintenance. The network has routing limitations due to structure of rooting from point to point. Virtual Private Networks: VPN connects to remote site through the internet with encryption and tunneling techniques to access the institution network. VPN is generally used in small organizations. Microsoft Remote Desktop Services (RDS): Remote controlled Access using RDS can be used to access the remote computer/ server on the local machine. Some other solutions like Citrix Virtual Apps, VMware, Parallels Remote Application Server (RAS) can be used through the web browser for clientless access. Other methods include Integrated Service Digital Network, Wireless Network, DSL- Digital Subscriber Line, Cable Modem etc.
    [Show full text]
  • Identityserver4 Documentation Release 1.0.0
    IdentityServer4 Documentation Release 1.0.0 Brock Allen, Dominick Baier Jul 27, 2021 Introduction 1 The Big Picture 3 1.1 Authentication..............................................4 1.2 API Access................................................5 1.3 OpenID Connect and OAuth 2.0 – better together............................5 1.4 How IdentityServer4 can help......................................5 2 Terminology 7 2.1 IdentityServer..............................................7 2.2 User....................................................8 2.3 Client...................................................8 2.4 Resources.................................................8 2.5 Identity Token..............................................8 2.6 Access Token...............................................8 3 Supported Specifications 9 3.1 OpenID Connect.............................................9 3.2 OAuth 2.0................................................9 4 Packaging and Builds 11 4.1 IdentityServer4 main repo........................................ 11 4.2 Quickstart UI............................................... 11 4.3 Access token validation handler..................................... 11 4.4 Templates................................................. 12 4.5 Dev builds................................................ 12 5 Support and Consulting Options 13 5.1 Free support............................................... 13 5.2 Commercial support........................................... 13 6 Demo Server 15 7 Contributing 17 7.1 How to contribute?...........................................
    [Show full text]
  • Background on Identity Federation Technologies for the Public Safety Community
    1 Draft NISTIR 8336 2 Background on Identity Federation 3 Technologies for the Public Safety 4 Community 5 6 William Fisher 7 Mark Russell* 8 Sudhi Umarji 9 Karen Scarfone 10 11 * Former employee; all work for this 12 publication was done while at employer. 13 14 15 16 This publication is available free of charge from: 17 https://doi.org/10.6028/NIST.IR.8336-draft 18 19 20 21 Draft NISTIR 8336 22 Background on Identity Federation 23 Technologies for the Public Safety 24 Community 25 William Fisher 26 Applied Cybersecurity Division 27 Information Technology Laboratory 28 29 Mark Russell* 30 Sudhi Umarji 31 The MITRE Corporation 32 McLean, VA 33 34 Karen Scarfone 35 Scarfone Cybersecurity 36 Clifton, VA 37 38 * Former employee; all work for this 39 publication was done while at employer. 40 41 This publication is available free of charge from: 42 https://doi.org/10.6028/NIST.IR.8336-draft 43 44 June 2021 45 46 47 48 U.S. Department of Commerce 49 Gina Raimondo, Secretary 50 51 National Institute of Standards and Technology 52 James K. Olthoff, Performing the Non-Exclusive Functions and Duties of the Under Secretary of Commerce 53 for Standards and Technology & Director, National Institute of Standards and Technology 54 National Institute of Standards and Technology Interagency or Internal Report 8336 55 80 pages (June 2021) 56 This publication is available free of charge from: 57 https://doi.org/10.6028/NIST.IR.8336-draft 58 Certain commercial entities, equipment, or materials may be identified in this document in order to describe an 59 experimental procedure or concept adequately.
    [Show full text]
  • A Guide to Claims-Based Identity and Access Control
    Second Edition A G UIDE TO C LAIMS -B ASED I DENTITY AND A CCESS C ONTROL Authentication and Authorization for Services and the Web Dominick Baier Vittorio Bertocci Keith Brown Scott Densmore Eugenio Pace Matias Woloski • • • • • • • • • • • • • • • • • • • • • • • • • • a guide to claims-based identity and access control a guide to Claims-Based Identity and Access Control second edition Authentication and Authorization for Services and the Web patterns & practices Microsoft Corporation This document is provided “as-is.” Information and views expressed in this document, including URLs and other Internet website references, may change without notice. You bear the risk of using it. Some examples depicted herein are provided for illustration only and are fictitious. No real association or connection is intended or should be inferred. ©2011 Microsoft. All rights reserved. Microsoft, Active Directory, MSDN, SharePoint, SQL Server, Visual Studio, Windows, Windows Azure, Windows Live, Windows PowerShell, and Windows Server are trademarks of the Microsoft group of companies. All other trademarks are the property of their respective owners. Contents foreword Kim Cameron xvii foreword Stuart Kwan xix foreword Steve Peschka xxi preface Who This Book Is For xxiii Why This Book Is Pertinent Now xxiv A Note about Terminology xxiv How This Book Is Structured xxv About the Technologies xxviii What You Need to Use the Code xxix Application Server xxx ADFS xxx Active Directory xxx Client Computer xxx Who’s Who xxxi acknowledgements xxxiii 1 An Introduction
    [Show full text]