Misplaced Pages

#112887

64-444: SSTC may refer to: Security Services Technical Committee; see Security Assertion Markup Language § History Shri Shankaracharya Technical Campus , Bhilai, Chhattisgarh, India Solid state Tesla coil , a Tesla coil that uses semiconductors in place of the traditional spark gap Silver Strand Training Complex , near San Diego, California, U.S. Starship Troopers Chronicles ,

128-467: A circle of trust where each participating domain is trusted to accurately document the processes used to identify a user, the type of authentication system used, and any policies associated with the resulting authentication credentials. Other members of the circle of trust could then examine these policies to determine whether to trust such information. While Liberty was developing ID-FF, the SSTC began work on

192-451: A user agent (usually a web browser) to request a web resource protected by a SAML service provider . The service provider, wishing to know the identity of the requesting user, issues an authentication request to a SAML identity provider through the user agent. The resulting protocol flow is depicted in the following diagram. In SAML 1.1, the flow begins with a request to the identity provider's inter-site transfer service at step 3. In

256-460: A CGI animated television series State Science and Technology Commission , a ministry of the People's Republic of China Sylhet Science And Technology College , Sylhet, Bangladesh Topics referred to by the same term [REDACTED] This disambiguation page lists articles associated with the title SSTC . If an internal link led you here, you may wish to change the link to point directly to

320-415: A RADIUS server. RADIUS proxy servers are used for centralized administration and can rewrite RADIUS packets on the fly for security reasons, or to convert between vendor dialects. The Diameter protocol was intended as the replacement for RADIUS. While both are Authentication, Authorization, and Accounting (AAA) protocols, the use-cases for the two protocols have since diverged. Diameter is largely used in

384-604: A defined use case using a particular combination of assertions, protocols and bindings. A SAML assertion contains a packet of security information: Loosely speaking, a relying party interprets an assertion as follows: Assertion A was issued at time t by issuer R regarding subject S provided conditions C are valid. SAML assertions are usually transferred from identity providers to service providers. Assertions contain statements that service providers use to make access-control decisions. Three types of statements are provided by SAML: Authentication statements assert to

448-619: A defined use case. The most important SAML profile is the Web Browser SSO Profile. SAML 1.1 specifies two forms of Web Browser SSO, the Browser/Artifact Profile and the Browser/POST Profile. The latter passes assertions by value whereas Browser/Artifact passes assertions by reference . As a consequence, Browser/Artifact requires a back-channel SAML exchange over SOAP. In SAML 1.1, all flows begin with

512-592: A minor upgrade to the SAML standard. The resulting SAML 1.1 specification was ratified by the SSTC in September 2003. Then, in November of that same year, Liberty contributed ID-FF 1.2 to OASIS , thereby sowing the seeds for the next major version of SAML. In March 2005, SAML 2.0 was announced as an OASIS Standard. SAML 2.0 represents the convergence of Liberty ID-FF and proprietary extensions contributed by

576-563: A network, usually contain a RADIUS client component that communicates with the RADIUS server. RADIUS is often the back-end of choice for 802.1X authentication. A RADIUS server is usually a background process running on UNIX or Microsoft Windows . The Blast-RADIUS attack breaks RADIUS when it is run on an unencrypted transport protocol like UDP. RADIUS is an AAA (authentication, authorization, and accounting) protocol that manages network access. RADIUS uses two types of packets to manage

640-431: A request at the identity provider for simplicity. Proprietary extensions to the basic IdP-initiated flow have been proposed (by Shibboleth , for example). The Web Browser SSO Profile was completely refactored for SAML 2.0. Conceptually, SAML 1.1 Browser/Artifact and Browser/POST are special cases of SAML 2.0 Web Browser SSO. The latter is considerably more flexible than its SAML 1.1 counterpart due to

704-453: A secure tunnel between the RADIUS servers to ensure that users' credentials cannot be intercepted while being proxied across the internet. This is a concern as the MD5 hash built into RADIUS is considered insecure. RADIUS is transported over UDP/IP on ports 1812 and 1813. The RADIUS packet data format is shown to the right. The fields are transmitted from left to right, starting with the code,

SECTION 10

#1732872793113

768-400: A users authorization, or to disconnect a user entirely. Now, several commercial and open-source RADIUS servers exist. Features can vary, but most can look up the users in text files, LDAP servers, various databases, etc. Accounting records can be written to text files, various databases, forwarded to external servers, etc. SNMP is often used for remote monitoring and keep-alive checking of

832-445: A valid username with two realms. Although realms often resemble domains, it is important to note that realms are in fact arbitrary text and need not contain real domain names. Realm formats are standardized in RFC 4282, which defines a Network Access Identifier (NAI) in the form of 'user@realm'. In that specification, the 'realm' portion is required to be a domain name. However, this practice

896-427: Is web-browser single sign-on (SSO). Single sign-on is relatively easy to accomplish within a security domain (using cookies , for example) but extending SSO across security domains is more difficult and resulted in the proliferation of non-interoperable proprietary technologies. The SAML Web Browser SSO profile was specified and standardized to promote interoperability. The SAML specification defines three roles:

960-564: Is a mapping of a SAML protocol message onto standard messaging formats and/or communications protocols. For example, the SAML SOAP binding specifies how a SAML message is encapsulated in a SOAP envelope, which itself is bound to an HTTP message. SAML 1.1 specifies just one binding, the SAML SOAP Binding. In addition to SOAP, implicit in SAML ;1.1 Web Browser SSO are the precursors of

1024-502: Is a networking protocol that provides centralized authentication, authorization, and accounting ( AAA ) management for users who connect and use a network service. RADIUS was developed by Livingston Enterprises in 1991 as an access server authentication and accounting protocol. It was later brought into IEEE 802 and IETF standards. RADIUS is a client/server protocol that runs in the application layer , and can use either TCP or UDP . Network access servers , which control access to

1088-506: Is configuration-dependent on most servers. In addition, the proxying server can be configured to add, remove or rewrite AAA requests when they are proxied over time again. Proxy Chaining is possible in RADIUS and authentication/authorization and accounting packets are usually routed between a NAS Device and a Home server through a series of proxies. Some of advantages of using proxy chains include scalability improvements, policy implementations and capability adjustments. But in roaming scenarios,

1152-595: Is granted to the user by the NAS , an Accounting Start (a RADIUS Accounting Request packet containing an Acct-Status-Type attribute with the value "start") is sent by the NAS to the RADIUS server to signal the start of the user's network access. "Start" records typically contain the user's identification, network address, point of attachment and a unique session identifier. Periodically, Interim Update records (a RADIUS Accounting Request packet containing an Acct-Status-Type attribute with

1216-476: Is known as postfix notation for the realm. Another common usage is prefix notation, which involves prepending the realm to the username and using '\' as a delimiter. Modern RADIUS servers allow any character to be used as a realm delimiter, although in practice '@' and '\' are usually used. Realms can also be compounded using both prefix and postfix notation, to allow for complicated roaming scenarios; for example, somedomain.com\username@anotherdomain.com could be

1280-463: Is not always followed. RFC 7542 replaced RFC 4282 in May 2015. When a RADIUS server receives an AAA request for a user name containing a realm, the server will reference a table of configured realms. If the realm is known, the server will then proxy the request to the configured home server for that domain. The behavior of the proxying server regarding the removal of the realm from the request ("stripping")

1344-532: Is simply a name–value pair . Relying parties use attributes to make access-control decisions. An authorization decision statement asserts that a principal is permitted to perform action A on resource R given evidence E . The expressiveness of authorization decision statements in SAML is intentionally limited. More-advanced use cases are encouraged to use XACML instead. A SAML protocol describes how certain SAML elements (including assertions) are packaged within SAML request and response elements, and gives

SECTION 20

#1732872793113

1408-401: Is transmitted, not how (the latter is determined by the choice of binding). So SAML Core defines "bare" SAML assertions along with SAML request and response elements. A SAML binding determines how SAML requests and responses map onto standard messaging or communications protocols. An important (synchronous) binding is the SAML SOAP binding. A SAML profile is a concrete manifestation of

1472-656: Is used in encrypting passwords; its length is 16 bytes. The RADIUS Attribute Value Pairs (AVP) carry data in both the request and the response for the authentication, authorization, and accounting transactions. The length of the radius packet is used to determine the end of the AVPs. RADIUS is extensible; many vendors of RADIUS hardware and software implement their own variants using Vendor-Specific Attributes (VSAs). Microsoft has published some of their VSAs. VSA definitions from many other companies remain proprietary and/or ad hoc, nonetheless many VSA dictionaries can be found by downloading

1536-409: The 3G space. RADIUS is used elsewhere. One of the largest barriers to having Diameter replace RADIUS is that switches and Access Points typically implement RADIUS, but not Diameter. Diameter uses SCTP or TCP while RADIUS typically uses UDP as the transport layer . As of 2012, RADIUS can also use TCP as the transport layer with TLS for security. The RADIUS protocol is currently defined in

1600-495: The Shibboleth project, as well as early versions of SAML itself. Most SAML implementations support v2.0 while many still support v1.1 for backward compatibility. By January 2008, deployments of SAML 2.0 became common in government, higher education, and commercial enterprises worldwide. SAML has undergone one minor and one major revision since 1.0. The Liberty Alliance contributed its Identity Federation Framework (ID-FF) to

1664-556: The Advancement of Structured Information Standards (OASIS) Security Services Technical Committee (SSTC), which met for the first time in January 2001, was chartered "to define an XML framework for exchanging authentication and authorization information." To this end, the following intellectual property was contributed to the SSTC during the first two months of that year: Building on these initial contributions, in November 2002 OASIS announced

1728-545: The Blast-RADIUS attack. As more dial-up customers used the NSFNET a request for proposal was sent out by Merit Network in 1991 to consolidate their various proprietary authentication, authorization and accounting systems. Among the early respondents was Livingston Enterprises and an early version of the RADIUS was written after a meeting. The early RADIUS server was installed on a UNIX operating system . Livingston Enterprises

1792-619: The HTTP POST Binding, the HTTP Redirect Binding, and the HTTP Artifact Binding. These are not defined explicitly, however, and are only used in conjunction with SAML 1.1 Web Browser SSO. The notion of binding is not fully developed until SAML 2.0. SAML 2.0 completely separates the binding concept from the underlying profile. In fact, there is a brand new binding specification in SAML 2.0 that defines

1856-457: The NAS device via the link-layer protocol—for example, Point-to-Point Protocol (PPP) in the case of many dialup or DSL providers or posted in an HTTPS secure web form. In turn, the NAS sends a RADIUS Access Request message to the RADIUS server, requesting authorization to grant access via the RADIUS protocol. This request includes access credentials, typically in the form of username and password or security certificate provided by

1920-583: The NAS, Proxies and Home Server could be typically managed by different administrative entities. Hence, the trust factor among the proxies gains more significance under such Inter-domain applications. Further, the absence of end to end security in RADIUS adds to the criticality of trust among the Proxies involved. Proxy Chains are explained in RFC 2607 . Roaming with RADIUS exposes the users to various security and privacy concerns. More generally, some roaming partners establish

1984-487: The NAS: 1) Access Reject, 2) Access Challenge, or 3) Access Accept. Each of these three RADIUS responses may include a Reply-Message attribute which may give a reason for the rejection, the prompt for the challenge, or a welcome message for the accept. The text in the attribute can be passed on to the user in a return web page. Authorization attributes are conveyed to the NAS stipulating terms of access to be granted. For example,

SSTC - Misplaced Pages Continue

2048-533: The OASIS SSTC in September 2003: Versions 1.0 and 1.1 of SAML are similar even though small differences exist., however, the differences between SAML 2.0 and SAML 1.1 are substantial. Although the two standards address the same use case, SAML 2.0 is incompatible with its predecessor. Although ID-FF 1.2 was contributed to OASIS as the basis of SAML 2.0, there are some important differences between SAML 2.0 and ID-FF 1.2. In particular,

2112-559: The RADIUS protocol in TLS . However, the packets inside of the TLS transport still use MD5 for packet integrity checks and for obfuscating the contents of certain attributes. The Blast-RADIUS attack breaks RADIUS when it is transported by plain UDP by attacking MD5 within RADIUS. RadSec blocks this attack. Another recommended mitigation is to require Message-Authenticator attributes for all requests and responses. CVE - 2024-3596 has been assigned for

2176-435: The RADIUS server. Additionally, the user's security credentials are the only part protected by RADIUS itself, yet other user-specific attributes such as tunnel-group IDs or VLAN memberships passed over RADIUS may be considered sensitive (helpful to an attacker) or private (sufficient to identify the individual client) information as well. . The RadSec protocol addresses the issue with legacy RADIUS/UDP security by "wrapping"

2240-451: The RFC 2865 Section 5.26 format. The RADIUS protocol transmits obfuscated passwords using a shared secret and the MD5 hashing algorithm. As this particular implementation provides only weak protection of the user's credentials, additional protection, such as IPsec tunnels or physically secured data-center networks, should be used to further protect the RADIUS traffic between the NAS device and

2304-520: The SAML Web Browser SSO Profile, some important third-party profiles of SAML include: The SAML specifications recommend, and in some cases mandate, a variety of security mechanisms: Requirements are often phrased in terms of (mutual) authentication, integrity, and confidentiality, leaving the choice of security mechanism to implementers and deployers. The primary SAML use case is called Web Browser Single Sign-On (SSO) . A user utilizes

2368-500: The SP, the IdP may request some information from the principal—such as a user name and password—in order to authenticate the principal. SAML specifies the content of the assertion that is passed from the IdP to the SP. In SAML, one identity provider may provide SAML assertions to many service providers. Similarly, one SP may rely on and trust assertions from many independent IdPs. SAML does not specify

2432-669: The Security Assertion Markup Language (SAML) 1.0 specification as an OASIS Standard. Meanwhile, the Liberty Alliance , a large consortium of companies, non-profit and government organizations, proposed an extension to the SAML standard called the Liberty Identity Federation Framework (ID-FF). Like its SAML predecessor, Liberty ID-FF proposed a standardized, cross-domain, web-based, single sign-on framework. In addition, Liberty described

2496-513: The actual assertion via a back channel. Such a back-channel exchange is specified as a SOAP message exchange (SAML over SOAP over HTTP). In general, any SAML exchange over a secure back channel is conducted as a SOAP message exchange. On the back channel, SAML specifies the use of SOAP 1.1. The use of SOAP as a binding mechanism is optional, however. Any given SAML deployment will choose whatever bindings are appropriate. RADIUS Remote Authentication Dial-In User Service ( RADIUS )

2560-553: The client has obtained such information, it may choose to authenticate using RADIUS. To do so, the client creates an "Access- Request" containing such Attributes as the user's name, the user's password, the ID of the client and the port ID which the user is accessing. When a password is present, it is hidden using a method based on the RSA Message Digest Algorithm MD5. Accounting is described in RFC 2866. When network access

2624-444: The example flow above, all depicted exchanges are front-channel exchanges , that is, an HTTP user agent (browser) communicates with a SAML entity at each step. In particular, there are no back-channel exchanges or direct communications between the service provider and the identity provider. Front-channel exchanges lead to simple protocol flows where all messages are passed by value using a simple HTTP binding (GET or POST). Indeed,

SSTC - Misplaced Pages Continue

2688-489: The flow outlined in the previous section is sometimes called the Lightweight Web Browser SSO Profile . Alternatively, for increased security or privacy, messages may be passed by reference . For example, an identity provider may supply a reference to a SAML assertion (called an artifact ) instead of transmitting the assertion directly through the user agent. Subsequently, the service provider requests

2752-544: The following authorization attributes may be included in an Access-Accept: When a client is configured to use RADIUS, any user of the client presents authentication information to the client. This might be with a customizable login prompt, where the user is expected to enter their username and password. Alternatively, the user might use a link framing protocol such as the Point-to-Point Protocol (PPP), which has authentication packets which carry this information. Once

2816-539: The following standalone bindings: This reorganization provides tremendous flexibility: taking just Web Browser SSO alone as an example, a service provider can choose from four bindings (HTTP Redirect, HTTP POST and two flavors of HTTP Artifact), while the identity provider has three binding options (HTTP POST plus two forms of HTTP Artifact), for a total of twelve possible deployments of the SAML 2.0 Web Browser SSO Profile. A SAML profile describes in detail how SAML assertions, protocols, and bindings combine to support

2880-418: The full AAA process: Access-Request, which manages authentication and authorization; and Accounting-Request, which manages accounting. Authentication and authorization are defined in RFC 2865 while accounting is described by RFC 2866. The user or machine sends a request to a Network Access Server (NAS) to gain access to a particular network resource using access credentials. The credentials are passed to

2944-494: The hop-by-hop security model, rather than end-to-end encryption , meant that if several proxy RADIUS servers are in use, every server must examine, perform logic on and pass on all data in a request. This exposes data such as passwords and certificates at every hop. RADIUS servers also did not have the ability to stop access to resources once an authorisation had been issued. Subsequent standards such as RFC 3576 and its successor RFC 5176 allowed for RADIUS servers to dynamically change

3008-467: The identifier, the length, the authenticator and the attributes. Assigned RADIUS Codes (decimal) include the following: The Identifier field aids in matching requests and replies. The Length field indicates the length of the entire RADIUS packet including the Code, Identifier, Length, Authenticator and optional Attribute fields. The Authenticator is used to authenticate the reply from the RADIUS server, and

3072-399: The intended article. Retrieved from " https://en.wikipedia.org/w/index.php?title=SSTC&oldid=975458634 " Category : Disambiguation pages Hidden categories: Short description is different from Wikidata All article disambiguation pages All disambiguation pages Security Assertion Markup Language#History An important use case that SAML addresses

3136-532: The method of authentication at the identity provider. The IdP may use a username and password, or some other form of authentication, including multi-factor authentication . A directory service such as RADIUS , LDAP , or Active Directory that allows users to log in with a user name and password is a typical source of authentication tokens at an identity provider. The popular Internet social networking services also provide identity services that in theory could be used to support SAML exchanges. The Organization for

3200-408: The new "plug-and-play" binding design of SAML 2.0. Unlike previous versions, SAML 2.0 browser flows begin with a request at the service provider. This provides greater flexibility, but SP-initiated flows naturally give rise to the so-called Identity Provider Discovery problem, the focus of much research today. In addition to Web Browser SSO, SAML 2.0 introduces numerous new profiles: Aside from

3264-437: The principal (typically a human user), the identity provider (IdP) and the service provider (SP). In the primary use case addressed by SAML, the principal requests a service from the service provider. The service provider requests and obtains an authentication assertion from the identity provider. On the basis of this assertion, the service provider can make an access control decision, that is, it can decide whether to perform

SECTION 50

#1732872793113

3328-406: The processing rules that SAML entities must follow when producing or consuming these elements. For the most part, a SAML protocol is a simple request-response protocol. The most important type of SAML protocol request is called a query . A service provider makes a query directly to an identity provider over a secure back channel. Thus query messages are typically bound to SOAP. Corresponding to

3392-461: The request, such as the user's network address or phone number, account status, and specific network service access privileges. Historically, RADIUS servers checked the user's information against a locally stored flat file database. Modern RADIUS servers can do this, or can refer to external sources—commonly SQL , Kerberos , LDAP , or Active Directory servers—to verify the user's credentials. The RADIUS server then returns one of three responses to

3456-430: The service for the connected principal. At the heart of the SAML assertion is a subject (a principal within the context of a particular security domain) about which something is being asserted. The subject is usually (but not necessarily) a human. As in the SAML 2.0 Technical Overview, the terms subject and principal are used interchangeably in this document. Before delivering the subject-based assertion from IdP to

3520-402: The service provider that the principal did indeed authenticate with the identity provider at a particular time using a particular method of authentication. Other information about the authenticated principal (called the authentication context ) may be disclosed in an authentication statement. An attribute statement asserts that a principal is associated with certain attributes. An attribute

3584-403: The source code of open source RADIUS implementations, for example FreeRADIUS . RFC 2865 Section 5.26 provides a suggested encoding which most vendors follow: Some vendors use different formats. For example, some vendors drop the "Vendor Length" field, or they use 2 octets for the "Vendor Type" and/or the "Vendor Length" fields. RFC 8044 Section 3.14 defines the "vsa" data type which mandates

3648-569: The three types of statements, there are three types of SAML queries: The result of an attribute query is a SAML response containing an assertion, which itself contains an attribute statement. See the SAML 2.0 topic for an example of attribute query/response . Beyond queries, SAML 1.1 specifies no other protocols. SAML 2.0 expands the notion of protocol considerably. The following protocols are described in detail in SAML 2.0 Core: Most of these protocols are new in SAML 2.0 . A SAML binding

3712-420: The two specifications, despite their common roots, are incompatible. SAML is built upon a number of existing standards: SAML defines XML-based assertions and protocols, bindings, and profiles. The term SAML Core refers to the general syntax and semantics of SAML assertions as well as the protocol used to request and transmit those assertions from one system entity to another. SAML protocol refers to what

3776-525: The user can be billed accordingly; the data is also commonly used for statistical purposes and for general network monitoring. RADIUS is commonly used to facilitate roaming between ISPs , including by: RADIUS facilitates this by the use of realms , which identify where the RADIUS server should forward the AAA requests for processing. A realm is commonly appended to a user's user name and delimited with an '@' sign, resembling an email address domain name. This

3840-447: The user. Additionally, the request may contain other information which the NAS knows about the user, such as its network address or phone number, and information regarding the user's physical point of attachment to the NAS. The RADIUS server checks that the information is correct using authentication schemes such as PAP , CHAP or EAP . The user's proof of identification is verified, along with, optionally, other information related to

3904-407: The value "interim-update") may be sent by the NAS to the RADIUS server, to update it on the status of an active session. "Interim" records typically convey the current session duration and information on current data usage. Finally, when the user's network access is closed, the NAS issues a final Accounting Stop record (a RADIUS Accounting Request packet containing an Acct-Status-Type attribute with

SECTION 60

#1732872793113

3968-404: The value "stop") to the RADIUS server, providing information on the final usage in terms of time, packets transferred, data transferred, reason for disconnect and other information related to the user's network access. Typically, the client sends Accounting-Request packets until it receives an Accounting-Response acknowledgement, using some retry interval. The primary purpose of this data is that

4032-496: Was acquired by Lucent Technologies and together with Merit steps were taken to gain industry acceptance for RADIUS as a protocol. Both companies offered a RADIUS server at no charge. In 1997 RADIUS was published as RFC 2058 and RFC 2059, current versions are RFC 2865 and RFC 2866. The original RADIUS standard specified that RADIUS is stateless and should run over the User Datagram Protocol (UDP). For authentication it

4096-682: Was envisaged that RADIUS should support the Password Authentication Protocol (PAP) and the Challenge-Handshake Authentication Protocol (CHAP) over the Point-to-Point Protocol . Passwords are hidden by taking the MD5 hash of the packet and a shared secret, and then XORing that hash with the password. The original RADIUS also provided more than 50 attribute-value pairs, with the possibility for vendors to configure their own pairs. The choice of

#112887