[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: HTML version of SAML Document Draft 1 for Friday FTF
All, I'm attaching HTML version of the document we'll review and discuss on Friday. The HTML version is the original, but you should use the PDF version (I'm sending it in a separate note) for our discussion, as it includes page and line numbers, which will make it easier for people to direct others to a particular piece of the document. (See attached file: draft-sstc-saml-01.htm.html) Jeff, could you please post these to the web site? Thanks, --bob Bob Blakley Chief Scientist Enterprise Solutions Unit Tivoli Systems, Inc. (an IBM Company)Title: SAML-main
Version | Draft 1 |
Date | 27 February 2001 |
Editor | Bob Blakley |
Comments | First draft
Includes input from the following subgroups: Use Cases and Requirements Request/Response Protocols Bindings Glossary This version is the input to FTF #1 |
The document uses UML-style use-case diagrams to illustrate high-level use cases. The following list is probably sufficient as a crash course in UML use-case diagrams:
Each scenario contains a short description of the scenario, a UML sequence diagram illustrating the action in the scenario, a description of each step, and a list of requirements that are related to the scenario.
Steps:
Steps:
Steps:
Steps:
Steps:
Assume that the user has gone beyond the timeout limit on the source Web site.
Logout
Steps:
Steps:
Steps:
Steps:
The model contains eight elements:
The Primary Domain,
The Secondary Domain,
The Authentication Authority,
The Authorization Authority,
The Session Authority,
The Policy Enforcement Point, and
The Policy Decision Point.
The Primary Domain is an administrative domain in which the Principal can be authenticated without assistance from any other domain.
The Secondary Domain is an administrative domain in which the Principal cannot be authenticated except with assistance from a Primary Domain.
The Principal has at least one name in a namespace sub-tree administered by the Authentication Authority in the Primary Domain. The Authentication Authority binds the Principal's name to an authentication mechanism in a "name assertion".
The Principal may have one or more entitlements in an entitlement-space sub-tree administered by the Authorization Authority in the Primary Domain. The Authorization Authority binds the Principal's entitlements to a name assertion in an "entitlement assertion".
The Principal may have a session state in a session state-space sub-tree administered by the Session Authority. The Session Authority binds the Principal's session state to a name assertion in a "session assertion".
The Policy Enforcement Point authenticates the Principal with the assistance of a Policy Decision Point and controls its access to resources in the Secondary Domain.
The Policy Decision Point authenticates the Principal and determines its eligibility to access resources in the Secondary Domain on the basis of the assertions.
Figure 1 indicates which elements of the model communicate with which other elements.
There are seven authentication data structures:
AuthnAcknowlegment,
AuthnRequest,
AuthnResponse,
AuthnQuery,
AuthnResult and
Ref(AuthnNotification).
AuthzAcknowlegment,
AuthzRequest,
AuthzResponse,
AuthzQuery,
AuthzResult and
Ref(AuthzNotification).
SessionAcknowlegment,
SessionRequest,
SessionResponse,
SessionQuery,
SessionResult and
Ref(SessionNotification).
The Ref(AuthnNotification) data structure is defined in the Bindings section of the specification, not in this, the Protocols, section. The step in which the Principal authenticates itself to the Policy Enforcement Point is not defined in this specification. However, it is a requirement of this step that it provide a posited name for the Principal and an authenticator. The posited name shall include a domain name, identifying the Authentication Authority in the Principal's Primary Domain, and a Principal name. The authenticator may be in any one of a number of forms, including a password, a symmetric-key challenge/response pair, an asymmetric-key challenge/response pair or a document/signature pair.
Discovery of services in a remote domain is outside the scope of this specification.
Protocol exchanges
Principal-centered direct protocol
This protocol may be used when the Principal is capable of relaying messages of unlimited length between the Primary Domain and the Secondary Domain, and when the Secondary Domain is not capable of communicating with the Primary Domain directly at the time at which the Principal communicates with the Secondary Domain.
Figure 2 shows the Principal-centered direct protocol.
It proceeds by the following steps.
This protocol may be used when the Principal is only capable of relaying messages of limited size from the Primary Domain to the Secondary Domain and the Secondary Domain is capable of communicating with the Primary Domain at the time at which the Principal communicates with the Secondary Domain.
Figure 3 shows the Principal-centered indirect protocol.
It proceeds by the following steps.
This protocol may be used when the Principal communicates with the Secondary Domain without being directed by the Primary Domain.
Figure 4 shows the pull protocol.
It proceeds by the following steps.
This protocol may be used when the Principal communicates with the Secondary Domain under the direction of the Primary Domain. Because it requires the Policy Decision Point to maintain state between communication sessions with the Authentication Authority and the Principal, it is less favoured than the Principal-centered protocols.
Figure 5 shows the Push protocol.
It proceeds by the following steps.
This protocol may be used to notify Secondary Domains when a Principal logs off in the Primary Domain.
Figure 6 shows the Primary Domain session-close protocol.
It proceeds by the following steps.
Secondary domain session-close protocol
This protocol may be used when the Principal logs off in the Secondary Domain.
Figure 7 shows the Secondary Domain session-close protocol.
It proceeds by the following steps.
Note: there are separate data structures for authentication, authorization and session exchanges. If an entity needs information on any combination of name, entitlements and session status, it must conduct separate protocols for each. However, these separate protocols may proceed in parallel.
All the data structures incorporate an "extension" field. In the current version of the specification no extensions are defined. Therefore, the extension field must be empty. However, in future versions, the extension may be used to convey policy information or privacy-related release-authorization information, etc.. At such time, this enhanced functionality may be added without disturbing the core structure of the messages
Schema for the data structures can be found in the Schema section of this specification.
AuthnNotification
The AuthnNotification message is used in the Principal-centered direct authentication protocol to send the name assertion from the Authentication Authority to the Principal and from the Principal to the Policy Enforcement Point. It is also used in the Push protocol to send the name assertion from the Authentication Authority to the Policy Decision Point. It contains the following information.
notification-identifier - an identifier assigned by the message originator. It must be unique among all the outstanding AuthnNotification messages.
name-assertion - the name assertion. Optional.
reference - reference to the name assertion. Optional, if the name assertion is absent, then the reference must be present.
sender - the name of the sender, as agreed between the sender and receiver during initialization. It must be unique among all the sender names recognized by the receiver.
intended-receiver - the name of the receiver, as agreed between the sender and receiver during initialization. It must be unique among all the receiver names recognized by the sender. Optional.
extension
AuthnAcknowlegment
The AuthnAcknowlegment message is used in the Push protocol for the Policy Decision Point to acknowledge receipt of the name assertion from the Authentication Authority. It contains the following information.
notification-identifier - the notification identifier supplied in the corresponding AuthnNotification message.
success-indicator - an indication of whether the receiver was able to process the AuthnNotification message.
reference - a reference to the name assertion. Optional.
sender
intended-receiver -
error-code - error code.
Unsupported authentication method
The AuthnRequest message is used in the Principal-centered indirect protocol and the Pull protocol for the Policy Decision Point to request the name assertion from the Authentication Authority. It contains the following information.
request-identifier - an identifier assigned by the message originator. It must be unique among all the outstanding AuthnRequest messages.
posited-name - the Primary Domain and Principal names claimed by the Principal. Optional.
reference to name assertion - a reference to the name assertion. Optional, if the posited name is not present, then this field must be present.
sender - the name of the sender, as agreed between the sender and receiver during initialization. It must be unique among all the sender names recognized by the receiver.
intended-receiver - the name of the receiver, as agreed between the sender and receiver during initialization. It must be unique among all the receiver names recognized by the sender. Optional.
AuthnResponse
The AuthnResponse message is used in the Principal-centered indirect protocol and the Pull protocol for the Authentication Authority to return the name assertion to the Policy Decision Point. It contains the following information.
request-identifier - the request identifier supplied in the corresponding AuthnRequest message.
name-assertion - the name assertion.
success indicator
sender -
intended-receiver -
error code
This protocol is used in the Principal-centered direct and indirect protocols and the Pull and Push protocols for the Policy Enforcement Point to request the Policy Decision Point to perform the authentication of the Principal.
request-identifier - an identifier assigned by the message originator. It must be unique among all the outstanding AuthnQuery messages.
posited name - the name claimed by the Principal.
authenticator - the data used in the authentication exchange between the Policy Enforcement Point and the Principal. This may be a user-name/password combination, a symmetric-key challenge/response combination, an asymmetric-key challenge response combination or a document/signature combination.
name-assertion - the name assertion. Optional.
reference to name assertion - a reference to a name assertion. Optional, at least one of "posited name", "name assertion" or "reference to name assertion" must be present.
sender -
intended-receiver -
This protocol is used in the Principal-centered direct and indirect protocols and the Pull and Push protocols for the Policy Decision Point to return the result of the authentication of the Principal to the Policy Enforcement Point.
request-identifier - the request identifier from the corresponding AuthnQuery message.
success indicator
sender -
intended-receiver -
error code
The AuthzNotification message is used in the Principal-centered direct authorization protocol to send the entitlement assertion from the Authorization Authority to the Principal and from the Principal to the Policy Enforcement Point. It is also used in the Push protocol to send the entitlement assertion from the Authorization Authority to the Policy Decision Point. It contains the following information.
notification-identifier - an identifier assigned by the message originator. It must be unique among all the outstanding AuthzNotification messages.
entitlement-assertion - the entitlement assertion. Optional.
reference - reference to entitlement assertion. Optional, if the entitlement assertion is absent, then the reference must be present.
sender - the name of the sender, as agreed between the sender and receiver during initialization. It must be unique among all the sender names recognized by the receiver.
intended-receiver - the name of the receiver, as agreed between the sender and receiver during initialization. It must be unique among all the receiver names recognized by the sender.
AuthzAcknowlegment
The AuthzAcknowlegment message is used in the Push protocol for the Policy Decision Point to acknowledge receipt of the entitlement assertion from the Authorization Authority. It contains the following information.
notification-identifier - the notification identifier supplied in the corresponding AuthzNotification message.
reference - reference to the entitlement assertion. Optional.
success-indicator - an indication of whether the receiver was able to process the AuthzNotification message.
sender -
intended-receiver -
error-code - error code.
The AuthzRequest message is used in the Principal-centered indirect protocol and the Pull protocol for the Policy Decision Point to request the entitlement assertion from the Authentication Authority. It contains the following information.
request-identifier - an identifier assigned by the message originator. It must be unique among all the outstanding AuthzRequest messages.
posited name - the posited name of the Principal. Optional.
reference to entitlement assertion - reference to an entitlement assertion. Optional. If the posited name is absent, then this field must be present.
sender - the name of the sender, as agreed between the sender and receiver during initialization. It must be unique among all the sender names recognized by the receiver.
intended-receiver - the name of the receiver, as agreed between the sender and receiver during initialization. It must be unique among all the receiver names recognized by the sender. Optional.
AuthzResponse
The AuthzResponse message is used in the Principal-centered indirect protocol and the Pull protocol for the Authorization Authority to return the entitlement assertion to the Policy Decision Point. It contains the following information.
request-identifier - the request identifier supplied in the corresponding AuthzRequest message.
entitlement assertion - the entitlement assertion.
sender -
intended-receiver -
success indicator
error code
This protocol is used in the Principal-centered direct and indirect protocols and the Pull and Push protocols for the Policy Enforcement Point to request the Policy Decision Point to confirm the authorization of the Principal.
request-identifier - an identifier assigned by the message originator. It must be unique among all the outstanding AuthzQuery messages.
action - a compound variable comprising the name of the object method and a sensitivity value for the object that the Principal is attempting to access.
principal name - the authenticated or claimed name of the Principal. Optional. Must be identical to the posited name in any accompanying AuthnQuery message.
entitlement-assertion - the entitlement assertion. Optional.
reference to the entitlement assertion - a reference to the entitlement assertion. Optional, it should be present if the entitlement assertion is absent. Optional. At least one of "principal name", "entitlement assertion" or "reference to entitlement assertion" must be present.
sender -
intended-receiver -
This protocol is used in the Principal-centered direct and indirect protocols and the Pull and Push protocols for the Policy Decision Point to return the result of the authorization of the Principal to the Policy Enforcement Point.
request-identifier - the request identifier supplied in the corresponding AuthzRequest message.
sender -
intended-receiver -
success indicator
error code
The SessionNotification message is used in the Principal-centered direct session protocol to send the session assertion from the Session Authority to the Principal and from the Principal to the Policy Enforcement Point. It is also used in the Push protocol to send the session assertion from the Session Authority to the Policy Decision Point. It is also used in the Primary Domain session close and Secondary Domain session close protocols to indicate that the session with the Principal has been closed. It contains the following information.
notification-identifier - an identifier assigned by the message originator. It must be unique among all the outstanding SessionNotification messages.
session-assertion - the session assertion. Optional.
reference - reference to the session assertion. Optional, if the session assertion is absent, then the reference must be present.
sender - the name of the sender, as agreed between the sender and receiver during initialization. It must be unique among all the sender names recognized by the receiver.
intended-receiver - the name of the receiver, as agreed between the sender and receiver during initialization. It must be unique among all the receiver names recognized by the sender. Optional.
SessionAcknowlegment
The SessionAcknowlegment message is used in the Push protocol for the Policy Decision Point to acknowledge receipt of the session assertion from the Session Authority. It is also used in the Primary Domain session close and Secondary Domain session close protocols to acknowledge that the session with the Principal has been closed. It contains the following information.
notification-identifier - the notification identifier supplied in the corresponding SessionNotification message.
Reference - reference to the session assertion. Optional.
sender -
intended-receiver -
success-indicator - an indication of whether the receiver was able to process the SessionNotification message.
error-code - error code.
The SessionRequest message is used in the Principal-centered indirect protocol and the Pull protocol for the Policy Decision Point to request the session assertion from the Session Authority. It contains the following information.
request-identifier - an identifier assigned by the message originator. It must be unique among all the outstanding SessionRequest messages.
principal name - the name of the Principal. Optional.
reference to session assertion - reference to the session assertion. Optional, is the principal name field is absent, then this field must be present.
sender - the name of the sender, as agreed between the sender and receiver during initialization. It must be unique among all the sender names recognized by the receiver.
intended-receiver - the name of the receiver, as agreed between the sender and receiver during initialization. It must be unique among all the receiver names recognized by the sender. Optional.
SessionResponse
The SessionResponse message is used in the Principal-centered indirect protocol and the Pull protocol for the Session Authority to return the session assertion to the Policy Decision Point. It contains the following information.
request-identifier - the notification identifier supplied in the corresponding SessionRequest message.
session-assertion - the session assertion.
success indication
error code
This protocol is used in the Principal-centered direct and indirect protocols and the Pull and Push protocols for the Policy Enforcement Point to request the Policy Decision Point to confirm the session status of the Principal.
request-identifier - an identifier assigned by the message originator. It must be unique among all the outstanding SessionQuery messages.
principal name - the authenticated or claimed name of the Principal. Optional. Must be identical to the posited name in any associated AuthnQuery message.
session assertion - a session assertion. Optional.
reference to session assertion - a reference to a session assertion. Optional, at least one of "principal name", "session assertion" or "reference to session assertion" must be present.
Sender -
intended-receiver -
This protocol is used in the Principal-centered direct and indirect protocols and the Pull and Push protocols for the Policy Decision Point to return the result of the status evaluation of the Principal to the Policy Enforcement Point.
request-identifier - the identifier from the corresponding SessionQuery message.
session assertion
sender -
intended-receiver -
success indicator
error code
Security considerations
With the exception of the session assertion in the SessionResult message, all assertions must be protected for integrity and authenticity using the XML Digital Signature mechanism. In addition, all protocol exchanges must be protected for integrity and authenticity. Mechanisms other than XML Digital Signature may be used for this latter purpose.
The exchange of Authority keys, certificates and certificate status information between domains is out of scope for this specification.
assertion (aka "security assertion"?)
authn - authentication
authz - authorization
business payload - [Chris F: how is this different or distinguished from "message payload" below? JeffH: good question. I pulled this term, and "message payload" from [S2ML] and we need to figure out semantically what was being referred to in that doc, and then name them appropriately (imho).]
message payload - [Chris F: how is this different or distinguished from "business payload" above? I pulled this term, and "business payload" from [S2ML] and we need to figure out semantically what was being referred to in that doc, and then name them appropriately (imho).]
originating site
package == assertions [+ entitlements] + payload ? - [Chris F: do we want to use the term "message" here? JeffH: I agree it's possible that we do (want to use "message" rather than "package") and should discuss it.]
payload
principal
receiving site
Relying party
root -- "root of the message" (from mime?)
scruitinize
security package - one or more s2ml documents combined into a single MIME entity.
security services
subject
web service
The high-level goal of the Bindings subcommittee is to specify how..
(1) security assertions are embedded in or combined with other objects (e.g. files of various types), communicated from site to site over various protocols, and subsequently scrutinized, and,
(2) security services defined with SAML as message exchanges
(e.g., the Authz protocol utilized between PDP and PEP in [Use Case
2, Straw2])
are mapped into one or more standard messaging protocols such as SOAP/XP
and BEEP.
(1) and (2) MUST be specified in sufficient detail to yield interoperability when independently implemented.
We would expect each security service (e.g., Section 3.1, S2ML) to be given a high-level description by other working groups within SAML. The effort in this sub-group would focus on considerations such as required headers, selection of encoding descriptions etc. such that interoperability can be achieved between providers and consumers of SAML security services, where both parties have selected a standard messaging framework such as SOAP/XP or BEEP.
(a) HTTP
In case of HTTP, there is a sub-case where the user is utilizing a
standard off-the-shelf browser and information about SAML assertions must
be conveyed from one site to another through the browser (i.e., there is
no direct site-to-site interaction). In this case, we need to ensure that
mechanisms for conveying assertions from one site to another be developed
that are based on URLs and HTTP headers (e.g., cookies). Both of these
entities are strongly size constrained. Representing assertions by some
form of "small" fixed-size object is an important consideration here [Section
6.1, S2ML].
[Section 6.2, S2ML] provides some discussion of a HTTP binding
which is not constrained by the use of web browsers.
(b) MIME [Section 6.3 S2ML]
(c) SMTP [Open Issue-2: Relationship to (b) above] [JeffH: I seriously wonder if there are any viable use cases for a SMTP binding that aren't addressed by a definition of MIME packaging for security assertions?]
[Chris F: note
that BEEP, HTTP and ebXML also leverage or are MIME aware. One could make
the same argument for all of these ;-)]
(d) ebXML
(e) SOAP/XP
(f) BEEP
From [BEEP]:
From [SASL]:5. Registration Templates 5.1 Profile Registration Template When a profile is registered, the following information is supplied: Profile Identification: specify a URI[10] that authoritatively identifies this profile. Message Exchanged during Channel Creation: specify the datatypes that may be exchanged during channel creation. Messages starting one-to-one exchanges: specify the datatypes that may be present when an exchange starts. Messages in positive replies: specify the datatypes that may be present in a positive reply. Messages in negative replies: specify the datatypes that may be present in a negative reply. Messages in one-to-many exchanges: specify the datatypes that may be present in a one-to-many exchange. Message Syntax: specify the syntax of the datatypes exchanged by the profile. Message Semantics: specify the semantics of the datatypes exchanged by the profile. Contact Information: specify the postal and electronic contact information for the author of the profile. 5.2 Feature Registration Template When a feature for the channel management profile is registered, the following information is supplied: Feature Identification: specify a string that identifies this feature. Unless the feature is registered with the IANA, the feature's identification must start with "x-". Feature Semantics: specify the semantics of the feature. Contact Information: specify the postal and electronic contact information for the author of the feature.
4. Profiling requirements In order to use this specification, a protocol definition must supply the following information: 1. A service name, to be selected from the IANA registry of "service" elements for the GSSAPI host-based service name form [RFC 2078]. 2. A definition of the command to initiate the authentication protocol exchange. This command must have as a parameter the mechanism name being selected by the client. The command SHOULD have an optional parameter giving an initial response. This optional parameter allows the client to avoid a round trip when using a mechanism which is defined to have the client send data first. When this initial response is sent by the client and the selected mechanism is defined to have the server start with an initial challenge, the command fails. See section 5.1 of this document for further information. 3. A definition of the method by which the authentication protocol exchange is carried out, including how the challenges and responses are encoded, how the server indicates completion or failure of the exchange, how the client aborts an exchange, and how the exchange method interacts with any line length limits in the protocol. 4. Identification of the octet where any negotiated security layer starts to take effect, in both directions. 5. A specification of how the authorization identity passed from the client to the server is to be interpreted.
From [SASL]:
6. Registration procedures Registration of a SASL mechanism is done by filling in the template in section 6.4 and sending it in to iana@isi.edu. IANA has the right to reject obviously bogus registrations, but will perform no review of clams made in the registration form. There is no naming convention for SASL mechanisms; any name that conforms to the syntax of a SASL mechanism name can be registered. While the registration procedures do not require it, authors of SASL mechanisms are encouraged to seek community review and comment whenever that is feasible. Authors may seek community review by posting a specification of their proposed mechanism as an internet- draft. SASL mechanisms intended for widespread use should be standardized through the normal IETF process, when appropriate. 6.1. Comments on SASL mechanism registrations Comments on registered SASL mechanisms should first be sent to the "owner" of the mechanism. Submitters of comments may, after a reasonable attempt to contact the owner, request IANA to attach their comment to the SASL mechanism registration itself. If IANA approves of this the comment will be made accessible in conjunction with the SASL mechanism registration itself. 6.2. Location of Registered SASL Mechanism List SASL mechanism registrations will be posted in the anonymous FTP directory "ftp://ftp.isi.edu/in-notes/iana/assignments/sasl- mechanisms/" and all registered SASL mechanisms will be listed in the periodically issued "Assigned Numbers" RFC [currently STD 2, RFC 1700]. The SASL mechanism description and other supporting material may also be published as an Informational RFC by sending it to "rfc- editor@isi.edu" (please follow the instructions to RFC authors [RFC 2223]). 6.3. Change Control Once a SASL mechanism registration has been published by IANA, the author may request a change to its definition. The change request follows the same procedure as the registration request. The owner of a SASL mechanism may pass responsibility for the SASL mechanism to another person or agency by informing IANA; this can be done without discussion or review. The IESG may reassign responsibility for a SASL mechanism. The most common case of this will be to enable changes to be made to mechanisms where the author of the registration has died, moved out of contact or is otherwise unable to make changes that are important to the community. SASL mechanism registrations may not be deleted; mechanisms which are no longer believed appropriate for use can be declared OBSOLETE by a change to their "intended use" field; such SASL mechanisms will be clearly marked in the lists published by IANA. The IESG is considered to be the owner of all SASL mechanisms which are on the IETF standards track. 6.4. Registration Template To: iana@iana.org Subject: Registration of SASL mechanism X SASL mechanism name: Security considerations: Published specification (optional, recommended): Person & email address to contact for further information: Intended usage: (One of COMMON, LIMITED USE or OBSOLETE) Author/Change controller: (Any other information that the author deems interesting may be added below this line.)
[BEEP] The Blocks Extensible Exchange Protocol Core
http://www.normos.org/ietf/draft/draft-ietf-beep-framework-11.txt
[Glossary] OASIS Security Services TC: Glossary.
http://www.oasis-open.org/committees/security/docs/draft-sstc-hodges-glossary-02.html
[S2ML] S2ML: Security Services Markup Language, Version 0.8a, January
8, 2001.
http://www.oasis-open.org/committees/security/docs/draft-s2ml-v08a.pdf
[SASL] Simple Authentication and Security Layer (SASL)
http://www.ietf.org/rfc/rfc2222.txt
[Shib] Shiboleth Overview and Requirements
http://middleware.internet2.edu/shibboleth/docs/draft-internet2-shibboleth-requirements-00.html
[Straw2] Oasis Security Services Use Cases And Requirements, Straw
Man Draft 2, 9 Feb 2001
http://unique.outlook.net/~evan/a2mluc/usecases-strawman-2.html
Date | By Whom | What |
21 Jan 2001 v00 | Jeff Hodges | Created. |
8 Feb 2001 v01 | Jeff Hodges | Added variouis terms supplied by Bob Blakley and others culled from S2ML 0.8a doc. |
9 Feb 2001 v01 | Jeff Hodges | Cleaned up refs, added refs, added definitions, enhanced or otherwise mangled others. |
Many of the definitions in this glossary are based on those found in these references: [1], [2], [3], [4], [5] (page 57), [6], [7] (Appendix K Glossary), [8], [9], [10], [11], [12], [13], [14], [15], [16], [17], [18], [19], [20],[21], [22], [23], [24], [25], [26], , , , , , , -- to one degree or another. Please refer to those sources for definitions of terms not explicitly defined here. Where possible and convenient, hypertext links directly to definitions within the aforementioned sources are included. Occasionally, definitions are quoted directly from the sources and the source(s) is (are) referenced.
Definitions to be added or otherwise enhanced are marked with a ?
AA or AAA | “Authentication and Authorization”, or “Authentication, Authorization, and Accounting (or Auditing)” – each of the “A”s being a general class of security mechanism. These mechanisms are key building blocks for implementing security architectures. |
ACI | See Access Control Information |
ADF | See Access Decision Function |
ADI | See Access Decision Information |
AEF | See Access Enforcement Function |
AP | See Asserting Party |
AAA Administrative Component | An AAA system component whose users are typically administrators and whose function is mangement of various aspects of a AAA system deployment. |
AAA Service | A network service providing AAA functionality. |
AAA Server | A system
entity that is also an AAA system
component whose function is to make policy
decisions on behalf of requesters. It accepts
and answers queries via some network protocol (TBD). It may or may not
rely on information stored in a (external) repository, e.g. in a directory
service, or a RDBMS, etc. [23]
This component may act in these roles: |
AAA System | A set of AAA system components implementing a network service delivering a AAA service. ? |
AAA System Component | A system entity that is one of the identifiable components of embodiments of AAA systems. ? |
AAA System Deployment | An instance of a deployed AAA system. An AAA System Deployment is typically hosted within and delivers service to a given administrative domain, It also may be utilized to provide services to other administrative domains. |
Access | The ability and means to communicate with or otherwise interact with a system in order to use system resources to either handle information or gain knowledge of the information the system contains. (definition from [1] ) |
Access Control | 1. Protection of system
resources against unauthorized access;
a process by which use of system resources is regulated according to a
security
policy and is permitted by only authorized system
entities (users, programs, processes, or other systems) according to
that policy. (definition from [1]
)
2. The prevention of unauthorized use of a resource, including the prevention of use of a resource in an unauthorized manner [9] |
Access Control Decision | ?The decision arrived at as a result of evaluating the requester’sidentity, the requested operation, and the requested resource in light of applicable security policy. (surprisingly enough, not explicitly defined in [10] ) |
Access Control Information | Any information used for access control purposes, including contextual information [10]. |
Access Control Factors | A request, when it is being processed by a server, may be associated with a wide variety of security-related factors (e.g. section 4.2 of [17]). The server uses these factors to determine whether and how to process the request. These are called access control factors (ACFs). They might include source IP address, encryption strength, the type of operation being requested, time of day, etc. Some factors may be specific to the request itself, others may be associated with the connection via which the request is transmitted, others (e.g. time of day) may be "environmental". [25] |
Access Control Policy | The set of rules that define the conditions under which an access may take place [10]. |
Access Control Policy Rules | Security policy rules concerning the provision of the access control service [10]. |
Access Control Request | See access request. |
Access Decision Function | A specialized function that makes access control decisions by applying access control policy rules to an access request, Access Decision Information (of initiators, targets, access requests, or that retained from prior decisions), and the context in which the access request is made [10]. |
Access Decision Information | The portion (possibly all) of the Access Control Information made available to the Access Decision Function in making a particular access control decision [10]. |
Access Enforcement Function | A specialized function that is part of the access path between an initiator and a target on each access control request and enforces the decision made by the Access Decision Function [10]. |
Access Path | ?(haven’t been able to find a concise def for this with a modicum of looking) |
Access Request | the operations and operands that form part of an attempted access. [10] |
Active Role | ? A role that an actor has donned when performing some operation, e.g. accessing a resource. |
Actor | ?
From [2]: A computational entity (i.e. system
entity) utilizing security services.
Examples of actors include application
servers, application programs, security services (?), transport and
message-level interceptors etc.
Perhaps actor is effectively synonymous with system entity. |
Administrative Domain | An environment or context that is defined by some combination of administrative policies, Internet Domain Name registration(s), civil legal entity(ies) (e.g. individual(s), corporation(s), or other formally organized entity(ies)), plus a collection of hosts, network devices and the interconnecting networks (and possibly other traits). An Administrative Domain may contain or define one or more security domains. An administrative domain may encompass a single site or multiple sites. The traits defining an Administrative Domain may, and in many cases will, evolve over time. Administrative Domains may interact and enter into agreements for providing and/or consuming services across Administrative Domain boundaries. |
Administrator | A person who installs, maintains, and/or makes use of the resources of a AAA System Deployment for system management and/or user management and/or content management purposes (as opposed to application purposes. See also End User). An administrator is typically affiliated with a particular administrative domain and may be affiliated with more than one administrative domain. See also deployer, business administrator, and local administrator. |
Anonymity | The quality or state of being anonymous. |
Anonymous | The condition of having a name [or identity] that is unknown or concealed. [1] |
Application Server | A software system run on a host that provides an execution environment for higher-level applications, for example business-oriented apps. |
Assertion | ?A
piece of data constituting a declaration of identity
or authorizations. See also: credential.
"Data that is transferred to establish the claimed identity of an entity." [9] |
Asserting Party | ? An AAA system component performing a role wherein it generates assertions on behalf of other actors. |
Attack | An assault on system security that derives from an intelligent threat, i.e., an intelligent act that is a deliberate attempt (especially in the sense of a method or technique) to evade security services and violate the security policy of a system. (definition from [1]). |
Attribute | A distinct characteristic of
an object. An object’s attributes are said to describe the object. Objects’
attributes are often specified in terms of their physical traits, such
as size, shape, weight, and color, address, phone number, etc., for real-world
objects. Objects in cyberspace might have attributes describing size, type
of encoding, network address, etc. Which attributes of an object
are salient is decided by the beholder.
Attributes are of various types, and are often represented by an attribute name along with one or more attribute values. See also Attribute Value Assertion, entry. [11][17] |
Attribute Name | The human-palatable name associated with a particular attribute type. |
Attribute List | A data structure consisting of lists of attribute value assertions (aka name-value pairs). [12] |
Attribute Type | An attribute type typically governs whether an attribute is single- or multi-valued, the syntax to which the values must conform, the kinds of matching which can be performed on values of that attribute, and other functions. [17] |
Attribute Value | An attribute value is one or more pieces of data, encoded according to the syntax of the attribute’s type. [17] |
Attribute Value Assertion | An Attribute Value Assertion is an assertion with the general abstract form of “attribute type IS attribute value”. [17] |
Audit | Independent review and examination of records and activities to determine compliance with established usage policies and to detect possible inadequacies in product technical security policies of their enforcement. [8] |
Audit Identity | An identity attribute containing an identity used only for accountability purposes (ECMA 219). [13] |
Authc | See Authentication |
Authn | See Authentication |
Authz | See Authorization |
Authentication | Authentication is the process
of confirming an entity’s asserted identity
with a specified, or understood, level of confidence. [7]
The process of verifying an identity claimed by or for a system entity. [12] |
Authority | An identified computer-based entity which implements a security service (e.g. creation of PACs). [12] |
Authorization | ?
The process of determining what types of activities are permitted. Usually,
authorization is in the context of authentication.
Once you have authenticated an entity, the entity
may be authorized different types of access or
activity. [8]
<rough>The “act of authorization” is when an AEF acts upon information received from an ADF.</rough> The granting of access rights to a subject (for example, a user, or program). [12] |
Authorization Assertion | ?
In concept an authorization assertion is a
statement of policy about a resource,
such as:
the user "noodles" is granted "execute" privileges on the resource "/usr/bin/guitar.” |
Authorization Identity | ? import from rfc2829 and rfc2222 |
Authorized | A system entity or actor is “authorized” if it is granted a right or a permission or a capability to access a system resource. See also authorization. |
Capability | A token that gives its holder the right to access a system resource. Possession of the token is accepted by the access control mechanism as proof that the holder has been authorized to access the resource named or indicated by the token. [12] |
Clearance | Initiator-bound ACI that can be compared with security labels of targets [10]. |
Context | See Contextual Information. |
Contextual Information | Information about or derived from the context in which an access request is made (e.g. time of day). [10]. Effectively synonymous with access control factors. |
Control Attribute | Attributes, associated with a security object that, when matched against the privilege attributes of a security subject, are used to grant or deny access to the security object. [19]? |
Credential | Data that is transferred or presented
to establish either a claimed identity or the
authorizations
of a system entity. (See also: assertion,
authentication information, capability, ticket.)
[1]
"Data that is transferred to establish the claimed identity of an entity." [9] |
Decision | The response of an Access Decision Function to a decision request[12]. |
Decision Request | The message an Access Enforcement Function sends to an Access Decision Function to ask it whether a particular access request should be granted or denied [12]. |
Deployer | An administrator in the act of, and/or (sometimes) primarily responsible for deploying a particular system or systems in an administrative domain’s network infrastructure. |
Deployment Time | The time at which a product is actually configured, tested, and/or put to use, as opposed to its being in the vendor’s development pipeline or in transit between the vendor and a customer. See also site-specific. |
DMZ | “DMZ” is from the military term for an area between two opponents where fighting is prevented. See also [6] and DMZ network. |
DMZ network | DMZ network is a commonly-used, equivalent term for (see also) perimeter network. |
DNS | See Domain Name System. |
Domain Name System | The general-purpose distributed, replicated, data query service used on the Internet for translating host names into Internet addresses. See [6]. |
End User | An entity, usually a human individual, that makes use of resources for application purposes (as opposed to system management purposes. See Administrator). |
End User’s Computer | A host that an end user makes use of for general computational, application, and communication purposes. |
End User Profile | Variouis attributes and attribute values, mapped to a given end user. User attributes are stored in the profile, e.g. identifier(s), name(s), contact information, organizational information, computing infrastructure information, etc. |
End User System | Typically the combination of: an End User, plus the End User’s computer, plus the browser running on that computer. The term “EU System” is used in this document, rather than just the terms “client” or “user” because given the many-tiered architecture, there are many components that act as clients of other components. |
Entitlement | A data structure containing Access Decision Information and/or access control policy rule information in a form which can be used by applications to customize their behavior based on access control policy or to make access control decisions in their own code [12]. |
Entity | See System Entity. |
EU System | A contraction for End User System. |
EUS | See End User System. |
External Network(s) | Networks outside one’s administrative domain and (in typical usage of the term) with which one’s networks are connected. |
Extranet | The part of a company or organization's computer network which is available to outside users, for example, information services for customers and/or suppliers (definition from [14] ). See also extranet in [6]. |
Firewall | A firewall is a device that gives an administrative domain a means to control how their internal network(s) interact with external networks. |
Firewall boundary | A commonly-used term referring to a security perimeter that is largely defined by the existence of a firewall. |
Host | A computer that is attached to a communication subnetwork or internetwork and can use services provided by the network to exchange data with other attached systems. A host is distinguished from other similarly connected and addressable devices on the network, e.g. routers, in that it doesn’t forward Internet Protocol packets that are not addressed to it. A host may be either an end user’s computer or a server. |
HTTP | See Hypertext Transfer Protocol. |
Hypertext Transfer Protocol | A protocol for distributed, collaborative, hypermedia information systems. It is the protocol used by web browsers to communicate with web servers, when the browsers process URLs specified as “http://host…”. See also RFC1945 [15] and RFC2616. [16] |
Identity | A representation (e.g. a string)
uniquely mapped to an entity (e.g. an end user,
an administrator, or some process, or some
network
device).
Initiator ACI passed to the aznAPI. [aznAPI] uses the term to describe anything used as initiator ACI, including names, identity certificates, and capabilities. Note that this usage is unique to [aznAPI] and should not be confused with other uses of the term "identity" in other systems [12]. |
IETF | See Internet Engineering Task Force. |
Initiator | An entity (e.g. human user or computer-based entity) that attempts to access other entities [10]. |
Intermediary | An entity which, after receiving an access request from an initiator, issues another access request on that initiator’s behalf [12]. |
Internal Network | See Intranet. |
Intranet | A local area network which may not be connected to the Internet, but which has some similar functions. Some organizations set up World Wide Web servers on their own internal networks so employees have access to the organization's Web documents. (definition from [14]) See also intranet in [6]. |
IP | Internet Protocol. See also TCP/IP. |
Label | A marking that is bound to a protected resource and that names or designates the security-relevant attributes of that resource (derived from [9]). |
LDAP | See Lightweight Directory Access Protocol. |
Lightweight Directory Access Protocol | A directory access protocol defined in IETF RFCs 2251..2256 (for LDAP version 3). It is largely based on X.500. [17] |
MIME | Multipurpose Internet Mail Extensions [18] -- a standard for imparting structure within otherwise “flat” ascii text. |
Network-based security | The notion of controlling network access and usage, and consequently protecting hosts from attack, via network routing configuration and filtering, the use of firewalls and similar devices, or some combination thereof. See also [5]. |
Network Device or Network Element | For the purposes of this document, one of routers, bridges, repeaters, hubs, switches, etc. |
Network Service | Work performed (or offered) by a server over a network. This may mean simply serving simple requests for data to be sent or stored (as with web servers); or it may be more complex work, such as that of print servers, distributed file servers, X Windows servers, or application servers. (definition largely from [6]) |
Network Topology | A configuration of network devices and hosts, and their interconnections. |
Operation | The action that an initiator’saccess request asks to have performed on a protected resource [12]. |
Origin Server | The server on which a given resource resides or is to be created. |
Origin Site, Originating Site | ? The site where the origin server resides. |
PAC | See Privilege Attribute Certificate. |
Package | = assertions [+ entitlements] + payload ? |
Party | ? An actor or actors participating in some process, such as accessing a resource. See also: system entity, user. |
Passive Role | ? A role that a resource effectively dons when it is the object of some operation. |
Payload | The essential data that is being carried within a packet or other transmission unit. The payload does not include the "overhead" data required to get the packet to its destination. Note that what constitutes the payload may depend on the point-of-view. To a communications layer that needs some of the overhead data to do its job, the payload is sometimes considered to include the part of the overhead data that this layer handles. However, in more general usage, the payload is the bits that get delivered to the end user (or whatever entity) at the destination. [26] |
Perimeter Network | A network between external networks and internal networks whose explicit role is to facilitate creation and management of additional layer(s) of security (as compared to not having a perimeter network). Also sometimes called a DMZ network. See also [5]. |
Perimeter Security | Network-based security applied at the perimeter of one’s security domain. See also [5]. |
Policy, Policies | Concisely, a policy is a mapping of user credentials with authority to act [8]. Policies are often essentially access control lists [8]. |
Principal | ? A uniquely named client or server instance that participates in a network communication. [RFC1510] |
Privilege Attribute | An attribute associated with an initiator that, when matched against control attributes of a protected resource is used to grant or deny access to that protected resource (derived from ECMA TR/46 definition). [19] |
Privilege Attribute Certificate | A data structure containing privilege attributes. May be signed by the authority which generated it [12]. |
Protected Resource | A target, access to which is restricted by an access control policy [12]. |
Protected Web Resources | Web resources whose availability to requesters is being managed, i.e. protected, via some access control mechanism. |
RP | See Relying Party. |
Receiving Site | ? A site that receives, interprets, and acts according to security assertions. Essentially synonymous to relying party. |
Relying Party | ? One who is making a decision contingent upon information or advice from another entity. E.g. an entity that is relying upon various security assertions about some other party(ies), made by yet another party(ies). |
Resource | Synonymous in this document for System Resource. |
Request | ? What clients make to servers. (need to enhance this ;) |
Requester | As in “service requester”, or “requester of resources”. A system entity that is utilizing a protocol to request services from a service. Essentially functionally equivalent to the term client. |
Risk | (a) In the computer system and networking sense: An expectation of loss expressed as the probability that a particular threat will exploit a particular vulnerability with a particular harmful result. (b) More generally: possibility of loss or injury. |
Risk Analysis | Risk analysis involves determining what you need to protect, what you need to protect it from, and how to protect it. It is the process of examining all of your risks, then ranking those risks by level of severity. For example, see the Risk Assessment section of Chapter 2 in [22]. |
Role |
?Dictionaries
define a role as “a character or part played by a performer” or
“a function or position.” Actors don various
types of roles serially and/or simultaneously, e.g. active
roles and passive roles. The notion of
an Administrator is often an example of
a role.
|
Scrutinize | To examine or observe with great care; inspect critically. |
Secure Sockets Layer | A network session-layer protocol which can be sandwiched between application-layer protocols, such as LDAP and HTTP, and the underlying transport protocol, TCP. SSL features facilities for mutual authentication of the client and server, as well as session encryption and integrity protection. See [20]. |
Security | Security refers to a collection of safeguards that ensure the confidentiality of information, protect the system(s) or network(s) used to process it, and control access to it (them). Security typically encompasses the concepts/topics/themes of secrecy, confidentiality, integrity, and availability.It is intended to ensure that a system resists potentially correlated attacks. (definition from [7]) |
Security Architecture | A plan and set of principles for an administrative domain and its security domains that describe (a) the security services that a system is required to provide to meet the needs of its users, (b) the system elements required to implement the services, and (c) the performance levels required in the elements to deal with the threat environment. A complete system security architecture addresses administrative security, communication security, computer security, emanations security, personnel security, and physical security. It prescribes security policies for each. A complete security architecture needs to deal with both intentional, intelligent threats and accidental kinds of threats. A security architecture should explicitly evolve over time as an integral part of its administrative domain’s evolution. (definition largely from [1]) |
Security Assertion | ? An assertion that is typically scrutinized in the context of a security policy. |
Security Domain | An environment or context that is defined by security policies, security models, and a security architecture, including a set of system resources and set of system entities that are authorized to access the resources. An administrative domain may contain one or more security domains. The traits defining a given security domain typically evolve over time. |
Security Mechanism | The logic or algorithm that implements a particular security-enforcing or security-relevant function in hardware and software. [8] |
Security Object | An entity in a passive role to which a security policy applies. [19] |
Security Package | ? one or more security assertions or credentials combined into a single overall, for example, MIME entity. |
Security Perimeter | The boundary of a security domain. |
Security Policy | A set of rules and practices specifying the “who, what, when, why, where, and how” of access to system resources by entities (often, but not always, people). Significant portions of security policies are implemented via security services. Security policies are components of security architectures. |
Security Requirements | The types and levels of protection necessary for equipment, data, information, applications, and facilities to meet security policy [given the results of a risk analysis]. (definition from [8]) |
Security Service | A processing or communication service that is provided by a system to give a specific kind of protection to system resources, where said resources may reside with said system or reside with other systems. E.g. an authentication service. Security services typically implement portions of security policies, and are implemented by security mechanisms. |
Security Subject | An entity in an active role to which a security policy applies. [19] |
Server | Either (1) a host that is used for running applications and or services that are network-accessible. Servers are typically not also used as end users’ computers. See also Server Host; or (2) a process or set of processes running on a host providing a network service. |
Server Host | A host on which a network service is being run. For example, the host upon which a web server is being run is a server host. |
Service | See Network Service. |
Site | A term commonly used to refer to an administrative domain in a geographical sense. Thus site may refer to a particular geographical and/or topological subportion of an administrative domain, or, a site my contain multiple administrative domains, as may be the case at an ASP site. |
Site-specific | A thing or a thing’s deployment configuration that is tailored on a site-by-site basis. For example, how a site performs load balancing of incoming HTTP requests to web server hosts is site-specific. From the vendor’s perspective, site-specific decisions are made at deployment time. |
SSL | See Secure Sockets Layer. |
SSL/TCP/IP | A shorthand notation denoting a protocol stack consisting of the SSL session layer running over the TCP/IP layers. An application layer protocol, e.g. LDAP or HTTP, is typically run on top of the SSL layer (which in turn is running on top of TCP/IP), and uses that layer (SSL) for end-to-end connection security. |
Subject | ? An identifiable entity. See also security subject. |
System Entity | An active element of a system--e.g., an automated process, a subsystem, a person or group of persons--that incorporates a specific set of capabilities. (definition from [1]) |
System Resource | Data contained in an information system (e.g. in the form of files, info in memory, etc); or a service provided by a system; or a system capability, such as processing power or communication bandwidth; or an item of system equipment (i.e., a system component--hardware, firmware, software, or documentation); or a facility that houses system operations and equipment. (definition from [1]) |
Target | An entity to which access may be attempted [10]. |
Threat | A potential for violation of security, which exists when there is a circumstance, capability, action, or event that could breach security and cause harm. That is, a threat is a possible danger that might exploit a vulnerability. A threat can be either "intentional" (i.e., intelligent; e.g., an individual cracker or a criminal organization) or "accidental" (e.g., the possibility of a computer malfunctioning, or the possibility of an "act of God" such as an earthquake, a fire, or a tornado). (definition from [1], See especially [8]) |
TCP or TCP/IP | See Transmission Control Protocol. |
Ticket | ? Aka a token. Specific example: Kerberos Tickets. See [RFC1510]. A ticket may be a credential. |
TLS | See Transport Layer Security. |
Token | ? See ticket. |
Transmission Control Protocol | The transport-layer protocol used on the Internet and most Internet-connected networks. It is layered on top of the Internet Protocol (IP) and the combination of the two is commonly termed “TCP/IP”. |
Transport Layer Security | The IETF version of SSL 3.0. It is essentially/effectively regarded as SSL 3.1. It is specified in RFC2246. A small, but growing, number of servers and clients on the Internet at large presently support it. |
Unauthorized | The opposite of a system entity or requester being authorized. |
URL | See Uniform Resource Locator. |
User | A corporeal human making use of a AAA system component and/or application(s) inhabiting a given administrative domain(s), as a means rather than as an end. (based on “user” from [6]). See also Administrator, End User. |
User Profile or User’s Profile | See End User Profile. |
Uniform Resource Locator | Defined as “a compact string representation for a resource available via the Internet.” See [21]. |
Vulnerability | A flaw or weakness in a system's design, implementation, or operation and management that could be exploited to violate the system's security policy. (definition from [1]) |
Web-based Service | A network service where requesters are typically web browsers being wielded by end-users, and where the content delivered to the end-users’ browsers via the web servers is the network service’s primary end-user interface. |
Web Browser | A software application used to locate and display web pages. |
Web Resource | Any object (e.g. a file (e.g. a web page), a program, or any other system resource) that is being made available to requesters via a web server. Also known as “web-accessible resource”. |
Web Server | A server process running on a server host and answering HTTP requests (at least),and often also several other protocols (e.g. FTP, Gopher). See also HTTP Server in [6]. A web server is typically used to implement a web-based service. |
Web Server Host | A host running a web server that is in turn providing some or all of the web resources accessible via the web server. |
Web Service | See Web-based service. |
Appendix A. References
Available at: http://www.authxml.org/?
Available at: http://www.s2ml.org/downloads/S2MLV08a.pdf
available at: ?
Available at: http://www.ietf.org/rfc/rfc2828.txt
Available at: http://www.oreilly.com/catalog/fire/
Available at: http://foldoc.doc.ic.ac.uk/foldoc/
On-line copy and ordering information available at: http://www.nap.edu/readingroom/books/trust/
Available at: http://www.garlic.com/~lynn/secure.htm
Available at: http://www.iso.ch/infoe/catinfo.html
Available at: http://www.iso.ch/infoe/catinfo.html
Description at: http://www.informit.com/product/1578700701/
Available at: http://www.opengroup.org/publications/catalog/c908.htm
Available at: http://www.ecma.ch/ecma1/STAND/ECMA-219.HTM
Available at: http://www.currents.net/resources/dictionary/
Available at: http://www.normos.org/ietf/rfc/rfc1945.txt
Available at: http://www.normos.org/ietf/rfc/rfc2616.txt
Available at: http://www.normos.org/ietf/rfc/rfc2251.txt
Available at: http://www.normos.org/ietf/rfc/rfc2045.txt
Available at: http://www.ecma.ch/ecma1/TECHREP/E-TR-046.HTM
Available at: http://www.netscape.com/eng/ssl3/
Available at: http://www.rfc-editor.org/rfc/rfc1738.txt
Available at: http://www.oreilly.com/catalog/puis/
Available at: http://www.rfc-editor.org/rfc/rfc2904.txt
Available at: http://www.rfc-editor.org/rfc/rfc2396.txt
Available at: http://www.rfc-editor.org/rfc/rfc2829.txt
Available at: http://whatis.techtarget.com/
ISSUE:[Document/Section Abbreviation-Issue Number: Short
name]
Issue long description.
Possible resolutions, with optional editor resolution
Decision
The issues are informally grouped according to general areas of concern. For this document, the "Issue Number" is given as "#-##", where the first number is the number of the issue group.
The issues are in varying levels of resolution. Some are stated as questions or placeholders for further investigation. Others are stated as problems with resolutions, and still others have full-blown use case scenarios attached.
One proposal is to replace all such terms with a standard actor naming scheme, suggested by Hal Lockhart and adapted by Bob Morgan, as follows:
Possible Resolutions:
UC-1-08:AuthZAttrs, UC-1-09:AuthZDecisions, and UC-1-11:AuthNEvents all address this question to some degree, but this issue is added to state for a general editorial principle for the document.
Possible Resolutions:
Date | 23 Feb 2001 |
Eligible | 18 |
Resolution 1 | 6 |
Resolution 2 | 0 |
Abstain | 3 |
ISSUE:[UC-1-02:ThirdParty] Use case scenario 3 (single sign-on, third party) describes a scenario in which a Web user logs in to a particular 3rd-party security provider which returns an authentication reference that can be used to access multiple destination Web sites. Is this different than Use case scenario 1 (single sign-on, pull model)? If not, should it be removed from the use case and requirements document?
As written, the use case is not truly different from use case scenario 1. However, if the use case scenario is expanded to include multiple destination sites, the importance of this use case becomes more apparent.
The following edition to the single sign-on, third party use case scenario would be added:
In this single sign-on scenario, a third-party security service provides authentication assertions for the user. Multiple destination sites can use the same authentication assertions to authenticate the Web user. Note that the first interaction, between the security service and the first destination site, uses the pull model as described above. The second interaction uses the push model. Either of the interactions could use a different single sign-on model.
Steps:
Date | 23 Feb 2001 |
Eligible | 18 |
Resolution 1 | 7 |
Resolution 2 | 2 |
Abstain | 0 |
ISSUE:[UC-1-03:ThirdPartyDoable] Questions have arisen whether use case scenario 3 is doable with current Web browser technology. An alternative is using a Microsoft Passport-like architecture or scenario.
It seems that at least one possible solution for the third-party security system exists -- that each destination site pass the authentication assertion from the third party security service to the next destination site, just as in peer source and destination scenarios such as use case scenarios 1 and 2.
Therefore, it seems that the scenario is at least theoretically implementable. It will be up to the other subcommittees and implementors of the standard to decide on how to define that implementation.
Possible Resolutions:
Date | 23 Feb 2001 |
Eligible | 18 |
Resolution 1 | 2 |
Resolution 2 | 8 |
Abstain | 0 |
Bob Blakley noted, "I think the proposed implementation only works if you follow direct links, and not if you pick destinations from a history list, use bookmarks, etc..."
ISSUE:[UC-1-04:ARundgrenPush] Anders Rundgren has proposed on security-use an alternative to use case scenario 2 (single sign-on, push model). The particular variation is that the source Web site requests an authorization profile for a resource (e.g., the credentials necessary to access the resource) before requesting access.
Possible Resolutions:
Date | 23 Feb 2001 |
Eligible | 18 |
Resolution 1 | 0 |
Resolution 2 | 3 |
Resolution 3 | 6 |
Abstain | 0 |
Bob Blakley noted, "I can't really see how to do this without significant changes to the current link resolution architecture of web sites -- specifically without making sure both source and destination are expecting to have to handle this flow."
ISSUE:[UC-1-05:FirstContact] A variation on the single sign on use case that has been proposed is one where the Web user goes directly to the destination Web site without authenticating with a definitive authority first.
A single sign-on use case scenario would be added as follows:
In this single sign-on scenario, the user does not first authenticate with their home security domain. Instead, they go directly to the destination Web site, first. The destination site must then redirect the user to a site they can authenticate at. The situation then continues as if in a single sign-on, push model scenario.
Steps:
Date | 23 Feb 2001 |
Eligible | 18 |
Resolution 1 | 6 |
Resolution 2 | 3 |
Abstain | 0 |
Bob Blakley said, " I agree that servers will have to do this, but it can easily be done by writing HTML with no requirement for us to provide anything in our specification."
ISSUE:[UC-1-06:Anonymity] What part does anonymity play in SAML conversations? Can assertions be for anonymous parties? Here, "anonymous" means that an assertion about a principal does not include an attribute uniquely identifying the principal (ex: user name, distinguished name, etc.).
A requirement for anonymity would state:
[CR-1-06-Anonymity] SAML will allow assertions to be made about anonymous principals, where "anonymous" means that an assertion about a principal does not include an attribute uniquely identifying the principal (ex: user name, distinguished name, etc.).
Date | 23 Feb 2001 |
Eligible | 18 |
Resolution 1 | 9 |
Resolution 2 | 0 |
Abstain | 0 |
ISSUE:[UC-1-07:Pseudonymity] What part do pseudonyms play in SAML conversations? Can assertions be made about principals using pseudonyms? Here, a pseudonym is an attribute in an assertion that identifies the principal, but is not the identifier used in the principal's home domain.
A requirement for pseudonymity would state:
[CR-1-07-Pseudonymity] SAML will allow assertions to be made about principals using pseudonyms for identifiers.
Date | 23 Feb 2001 |
Eligible | 18 |
Resolution 1 | 7 |
Resolution 2 | 2 |
Abstain | 0 |
In support of Resolution 1, while voting, Bob Blakley said, "I'm really ambivalent about this. At an implementation level AND at a specification level, I can't see how a pseudonym should differ from a 'real' name. If it shouldn't, then we have no work to do. However, we should at least discuss the issue."
ISSUE:[UC-1-08:AuthZAttrs] It's been pointed out that the concept of an "authentication document" used in the use case and requirements document does not clearly specify the inclusion of authz attributes. Here, authz attributes are attributes of a principal that are used to make authz decisions, e.g. an identifier, or group or role membership.
Since authz attributes are important and are required by [R-AuthZ], it has been suggested that the single sign-on use case scenarios specify when authz assertions are passed between actors.
Possible Resolutions:
Date | 23 Feb 2001 |
Eligible | 18 |
Resolution 1 | 9 |
Resolution 2 | 0 |
Abstain | 0 |
ISSUE:[UC-1-09:AuthZDecisions] The current use case and requirements document mentions "Access Authorization" and "Access Authorization References." In particular, this data is a record of a authorization decision made about a particular principal performing a particular action on a particular resource.
It would be more clear to label this data as "AuthZ Decision Documents" to differentiate from other AuthZ data, such as AuthZ attributes or AuthZ policy. To this point, the mentions of "access authorization" would be changed, and a new requirement would be added as follows:
[CR-1-09-AuthZDecision] SAML should define a data format for recording authorization decisions.
Date | 23 Feb 2001 |
Eligible | 18 |
Resolution 1 | 8 |
Resolution 2 | 0 |
Abstain | 1 |
ISSUE:[UC-1-10:UnknownParty] The current straw man 2 document does not have a use case scenario for exchanging data between security services that are previously unknown to each other. For example, a relying party may choose to trust assertions made by an asserting party based on the signatures on the AP's digital certificate, or through other means.
The following use case scenario would illustrate using assertions from an unknown party.
In this scenario, an application service provider has a policy to allow access to resources for all full-time students at accredited 4-year universities and colleges. It would be difficult for the application service provider to maintain agreements with hundreds of such organizations in order to verify assertions made by those parties. Instead, it chooses to check the key of the asserting party to ensure that the asserting party is a 4-year university.
Steps:
Date | 23 Feb 2001 |
Eligible | 18 |
Resolution 1 | 2 |
Resolution 2 | 7 |
Abstain | 0 |
In voting for resolution 2, Bob Blakley said, " I think this overspecifies behavior... both the 'interesting' flows in the diagram here are from the Application Service Provider to *itself*. Why should we tell the A.S.P. how to make trust decisions about assertions?"
ISSUE:[UC-1-11:AuthNEvents] It is not specified in straw man 2 what authentication information is passed between parties. In particular, specific information about authn events, such as time of authn and authn protocol are alluded to but not specifically called out.
The use case scenarios would be edited to show when information about authn events would be transferred, and the requirement for authn data would be edited to say:
[CR-1-11-AuthN] SAML should define a data format for authentication assertions, including descriptions of authentication events.
Date | 23 Feb 2001 |
Eligible | 18 |
Resolution 1 | 9 |
Resolution 2 | 0 |
Abstain | 0 |
ISSUE:[UC-1-12:SignOnService] Bob Morgan suggests changing the title of use case 1, "Single Sign-on," to "Sign-on Service."
Possible Resolutions:
A scenario would be added to the document as follows:
Scenario X: Single Sign-on, Proxy Model
In this model, the user authenticates to a proxy and then sends a request, including credentials, to the proxy. The proxy generates OSSML assertions, attaches them to the request, and forwards the request to the destination web site. The destination web site replies to the proxy, and the proxy forwards the reply back to the client.
In this model, the user authenticates to a proxy and then sends a request, including credentials, to the proxy. The proxy generates OSSML assertions, attaches them to the request, and forwards the request to the destination web site. The destination web site replies to the proxy, and the proxy forwards the reply back to the client.
Alternatively, the initial message from the client to the proxy could include both the authentication credentials and the request rather than having a separate round-trip for authentication.
Steps:
[CR-2-01-Policy] SAML should define a data format for security policy about resources.
The use case would be inserted as follows (some editing for clarity):
This scenario shows an enterprise A that has outsourced the management of its network devices to a management service provider B. Management messages are exchanged using CIM/XML over HTTP. (CIM or Common Information Model, is a management standard being developed by the Distributed Management Task Force - http://www.dmtf.org/, an XML DTD for CIM has been defined.)
Suppose the operator, Joe, wants to invoke the StopService method. This will be executed by the XML/CIM agent on the managed device, if authorized.
Steps:
The use case would be inserted as follows (some editing for clarity):
In this scenario an ASP, A, is providing an application (possible examples could be a word processor or an ERP application) to users in another enterprise, B. A VPN (for example IPSEC) is used to provide a secure end-to-end tunnel between the client and server.
A major difference between this scenario and the outsource management service scenario is that all assertions are "pulled" in this scenario. This means the assertions are not attached to application messages; instead they must be retrieved either directly from the attribute authority, or a repository. For example, once the client has been authenticated, the SAML evaluation engine in the server needs to retrieve the SAML assertions issued by A and B. This will involve making a request to a repository inside B, traversing both A and B's firewall as shown in the diagram. Similarly the SAML engines in the gateway and client will have to retrieve assertions issued by both authorities.
Steps:
Status: Open
ISSUE:[UC-2-05:B2B Transaction via an e-marketplace or trading hub] Zahid Ahmed proposes the following additional use case scenario for inclusion in the use case and requirements document.
A B2B Transaction involving buyers and suppliers that conduct trade via an e-marketplace that provides trading party authentication and authorization services, and other business services, in support of secure transaction and routing of business document exchanges between trading parties.
Steps:
A B2B Document Exchange Transaction that involves two trading parties such that sending trading party (e.g., Buyer) uses one messaging and transport protocol (e.g., OBI) and receiving party (e.g., Supplier) uses a another messaging/transport protocol (e.g., ebXML). A B2B transaction service must provide relevant security interoperability services as part of its general messaging and application interoperability mechanism.
Steps:
In this scenario the transacting trading parties are members of different e-marketplaces or trading communities. To support B2B transactions between trading parties of different e-markletplaces, the e-marketplaces will provide secure interconnectivity between the set of trading hubs involved in the transaction between the transaction parties. In this manner e-marketplaces will act as trusted intermediaries between transacting trading parties.
Steps:
Use Case Scenario X: ebXML
Steps:
[CR-3-1-UserSession] SAML shall support web user session(s).
Note that this is a duplicate of Oasis security Services Scenario #1
Steps:
Date | 23 Feb 2001 |
Eligible | 18 |
Resolution 1 | 8 |
Resolution 2 | 2 |
Abstain | 0 |
In voting for resolution 1, Jeff Hodges added, "rationale: if there's these "assertions" floating about between various entities that serve to assert the identity of some particular entity, there's notions of "validity time period" (however implemented), and there's notions of "state" relative to the asserted identity, then I feel what we have here meets the definition of a "session", and we ought to use that term (and really figure out what all the implications are)." He also attached the following URLs:
http://foldoc.doc.ic.ac.uk/foldoc/foldoc.cgi?query=session&action=Search http://foldoc.doc.ic.ac.uk/foldoc/foldoc.cgi?query=state
Date | 23 Feb 2001 |
Eligible | 18 |
Resolution 1 | 5 |
Resolution 2 | 5 |
Abstain | 0 |
ISSUE:[UC-3-03:Logout] Should SAML support transfer of information about logout (e.g., a principal intentionally ending a session)? [DavidO: Isn't this covered in UC-3-1? I've kept here for backwards compatibility]
Candidate Requirement:
[CR-3-3-Logout] SAML shall support web user logout.
Date | 23 Feb 2001 |
Eligible | 18 |
Resolution 1 | 5 |
Resolution 2 | 5 |
Abstain | 0 |
In voting for resolution 2, Jeff Hodges added, "rationale: I believe this is subsumed within the topic of [UC-3-1:UserSession] and we should deal with it explicitly in that context."
ISSUE:[UC-3-6:Destination Logout] Should logging out of a destination web site be supported? Advantage: allows web sites control over their local domain, current model implemented on the web. Disadvantage: potentially more interactions between source and destination web sites
Candidate Requirement:
[CR-3-6-Destination Logout] SAML shall support logout at destination web sites
Date | 23 Feb 2001 |
Eligible | 18 |
Resolution 1 | 4 |
Resolution 2 | 5 |
Abstain | 1 |
ISSUE:[UC-3-7:Logout Extent] What is the impact of logging out at a destination web site?
Possible Resolution:
Date | 23 Feb 2001 |
Eligible | 18 |
Resolution 1 | 7 |
Resolution 2 | 0 |
Resolution 3 | 1 |
Abstain | 2 |
Jeff Hodges, abstaining, said, "rationale: needs clarification. E.g. BobB's point in Group3VoteBlakley.html should be considered."
ISSUE:[UC-3-04:StepUpAuthn] "Step-up" authentication is when a receiving party refuses to accept an authentication from an authenticating party and asks for a higher level of authentication. For example, the RP can refuse password authn and require certificate authn. Should SAML support step-up authentication? Should a use case be developed illustrating step-up authn?[DavidO: I don?t think this is applicable to the session requirements, but I?ve kept here for backwards compatibility].
Possible Resolutions:
Date | 23 Feb 2001 |
Eligible | 18 |
Resolution 1 | 5 |
Resolution 2 | 4 |
Abstain | 1 |
ISSUE:[UC-3-05:SessionTimeout] Should timeout be supported?
Candidate requirement:
[CR-3-5-Timeout] SAML shall support timeout of a user log-on.
Date | 23 Feb 2001 |
Eligible | 18 |
Resolution 1 | 6 |
Resolution 2 | 4 |
Abstain | 0 |
In voting for resolution 2, Jeff Hodges added, "rationale: I believe this is subsumed within the topic of [UC-3-1:UserSession] and we should deal with it explicitly in that context."
Bob Blakley said, "However I believe that the phrasing of the requirement is wrong. I think what we should support is expiration of assertions. Timeout is an action a receiving system implements based on observing that an assertion has timed out."
ISSUE:[UC-3-8:Destination Timeout] Should timing out of a session at a destination web site be supported?
Candidate requirement:
[CR-3-8-DestinationTimeout] SAML shall support destination web site timeout.
Date | 23 Feb 2001 |
Eligible | 18 |
Resolution 1 | 4 |
Resolution 2 | 6 |
Abstain | 0 |
In voting for resolution 2, Jeff Hodges added, "rationale: I believe this is subsumed within the topic of [UC-3-1:UserSession] and we should deal with it explicitly in that context."
Bob Blakley said, "I don't feel that I understand well enough what we'd consider doing here to express an opinion yet."
ISSUE:[UC-4-02:AttributeAuthority] Should a concept of an attribute authority be introduced into the SAML use case document? What part does it play? Should it be added in to an existing use case scenario, or be developed into its own scenario?
Status: Open
ISSUE:[UC-4-03:PrivateKeyHost] A concept taken from S2ML. A user may allow a server to host a private key. A credentials field identifies the server that holds the key. Should this concept be introduced into the SAML use case document? As a requirement? As part of an existing use case scenario, or as its own scenario?
Status: Open
ISSUE:[UC-4-04:SecurityDiscover] UC-1-04:ARundgrenPush describes a single sign-on scenario that would require transfer of authorization data about a resource between security zones. Should a service for security discovery be part of the SAML standard?
Possible Resolutions:
[NO-Authn] Authentication methods or frameworks are outside the scope of SAML.
Date | 23 Feb 2001 |
Eligible | 18 |
Resolution 1 For | 1 |
Resolution 1 Against | 10 |
Resolution 2 For | 10 |
Resolution 2 Against | 1 |
Resolution 3 For | 7 |
Resolution 3 Against | 4 |
Abstain | 0 |
NOTE: resolutions for this issue were voted on separately.
ISSUE:[UC-5-02:SASL] Is there a need to develop materials within SAML that explore its relationship to SASL [SASL]?
Possible Resolutions:
Date | 23 Feb 2001 |
Eligible | 18 |
Resolution 1 | 3 |
Resolution 2 | 5 |
Abstain | 2 |
[ISSUE:[UC-5-01:AuthNProtocol] Straw Man 1 explicitly makes challenge-response authentication a non-goal. Is specifying which types of authn are allowed and what protocols they can use necessary for this document? If so, what types and which protocols?
As written, this issue covers a lot of ground. [UC-5-03:AuthNthrough] covers the core issue of the removal of all considerations of modeling authentication methods within SAML, which need not be discussed further in 5-01.
There is an aspect of these requirements that has been discussed and noted as important on the list. There is a need for describing different forms of credentials (name-password, public key, X509 certificates etc) within OSSML. In this sense there is a connection to the different "permitted forms of authn" [2] and OSSML.
REFERENCES: I believe these requirements are consistent with or can be derived from Nigel's suggestion [1] but is perhaps closer to the current style of specification in Strawman 2. It also reflects the discussion in [2] and [3].
[1] http://lists.oasis-open.org/archives/security-use/200102/msg00029.html [2] http://lists.oasis-open.org/archives/security-use/200102/msg00038.html [3] http://lists.oasis-open.org/archives/security-use/200102/msg00064.html
"Challenge-response authentication protocols are outside the scope of the SAML"should be removed from the Strawman 3 document.
[CR-5-01-1-StandardCreds] SAML should provide a data format for credentials including those based on name-password, X509v3 certificates, public keys, X509 Distinguished name, and empty credentials.
[CR-5-01-2-ExtensibleCreds] SAML The credentials data format must support extensibility in a structured fashion.
Date | 23 Feb 2001 |
Eligible | 18 |
Resolution 1 For | 8 |
Resolution 1 Against | 3 |
Resolution 2 For | 8 |
Resolution 2 Against | 3 |
Abstain | 0 |
In voting for resolution 2, Bob Blakley said, "My thinking here is that we need to provide a way to assert what mechanism was used to authenticate the user (e.g. certificate-based authentication) and what the user's authenticated credential resulting from that authentication (e.g. X.509 cert) was. I'm still nervous about allowing the VALUE of the password to be used as credential information as in S2ML, but I do understand why this was done and that it's useful."
Possible Resolutions:
[CR-9-02-3-DisclosureMorgan] SAML should support policy-based disclosure of subject security attributes, based on the identities of parties involved in an authentication or authorization exchange.
[CR-9-02-2-DisclosureBlakley] SAM should support *restriction of* disclosure of subject security attributes, *based on a policy stated by the subject*. *This policy might be* based on the identities of parties involved in an authentication or authorization exchange.
Status: Open
Scenario N: Authorization Service
This use case illustrates an authorization service that provides authorization checks for resource access. This authorization service is expected to operate within a single security domain, where the owner of the resource also controls the policies at the Policy Decision Point corresponding to those resources.
Steps:
Scenario N+1: Authorization Service, First Contact with Authentication
In this scenario, the client makes contact only with the application; there is not a separate authentication phase between the user and the security system.
Steps:
Possible Resolutions:
[CR-13-01-Scalability] SAML should be appropriate for high volume of messages, and for messages between parties made up of several physical machines.
One such requirement was:
[CR-13-02-EfficientMessages] Should support efficient message exchange Integrity checks such as digital signature can add excessive overhead to messages.
One such requirement was:
[CR-13-03-OptionalAuthentication] Authentication should be optional To Satisfy [R-EfficientMessages] Messages may omit authentication altogether.
One such requirement was:
[CR-13-04-OptionalSignatures] Signatures should be optional To Satisfy [R-EfficientMessages] Messages may use a shared secret and Message Authentication code for Authentication in place of digital signature.
[CR-13-05-SecurityPolicy] Security measures in [OSSML] should support common institutional security policies regarding assurance of identity, confidentiality, and integrity.
"Goal [R-Reference] either needs more elaboration or (likely) needs to be dropped. What is a 'reference'? It doesn't have a standard well-understood security meaning nor is it defined in the glossary. This Goal seems to me to be making an assumption about a low-level mechanism for optimizing some of the transfers."One possible, more specific elaboration might be:
[CR-13-06-1-Reference] SAML should define a data format for providing references to authentication and authorization assertions. Here, a "reference" means a token that may not be a full assertion, but can be presented to an asserting party to request a particular assertion.
[CR-13-06-2-Reference-Message] SAML should define a message format for requesting authentication and authorization assertions using references.
[CR-13-06-2-Reference-Size] SAML references should be small. In particular, they should be small enough to be transfered by Web browsers, either as cookies or as CGI parameters.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC