OASIS Web Service Security token

There are two main methods to pursue Web Service Security. W3C uses encryption and XML methods to ensure that data from Web services is not blocked. OASIS (WS-I also handed over its preliminary work to OASIS) uses a secure password-based approach to ensure that only authenticated users can access Web services. Last month, we focused on W3C security methods. This month, we will focus on the OASISWeb Service Security password method.

The OASIS standard is generally used as the WS-* standard. WS stands for Web Services, and asterisks are understood as any aspect of the specific standard search. For example, Security standards are based on the WS-Security Standards, which are generally abbreviated as WSS.

WS-Security proposes a set of SOAP extension standards to allow secure SOAP message exchange. This standard complies with multiple security password formats, trust domains, secure signature formats, and encryption technologies. The standard provides three main construction modules to build OASIS Based on password security, that is, message integrity, message confidentiality, and the ability to integrate secure passwords into messages. The OASIS website provides links to important security password standard files, including Kerberos and SAML.

Other OASIS standards are based on the highest WS-Security Standards to build a Web Service Security stack. WSS is the foundation. Create WS-Trust, WS-SecureConversation, and WS-SecurityPolicy. The top layer is SAML.

WS-Trust is the first to create a complete WSS. It provides some extensions to the WS-Security Specification to handle the release, consolidation, and verification of Security passwords, ensure that the interoperability of participants is in a trusted and secure data exchange environment.

By creating and maintaining trust rules and security password creation and exchange rules, Web services are more secure. However, the system still has vulnerabilities. WS-SecureConversation was introduced to help fill gaps between WS-Security and WS-Trust with the concept of Security content. According to the WS-SecureConversation 1.3 OASIS standard, "security content is an abstract concept that guides the use of established authentication statuses and performance related to the security of negotiated key append ."

The WS-SecurityPolicy standard connects WSS and related standards to the WS-Policy framework, which reflects how WS-* is subject to the limitations and requirements of Web Service expressions. WS-SecurityPolicy defines policy assertions for the use of all other WS-* security standards to ensure that necessary information is provided to determine the interaction of Web Services, and to ensure the adequacy between various Web service security protocols.

At the top layer of all WS-* security standards, OASIS advocates SAML and Security asserted markup language. SAML focuses on Single Sign-On (SSO) among multiple domains, provides attribute-based authentication, and provides better security for Web Services. To ensure single-point logon in multiple domains, the SAML method commands the provisioning service provider. The principal and the user use identity Provider registration to manage their security identities. Third-party identity Provider systems have more advantages in browser cookies and require one-to-one Web application relationships.

By decoupling identity management tasks from Web service providers, SAML ensures that end users can log on to and access multiple services because each service will review the identity Provider. This decoupling also allows attribute-based authentication. the identity Provider can maintain user attribute information, such as a user's position in the Organization. These attributes are subsequently used by Web applications for authentication decisions. SAMl and SOAP messages provide security for Web Services at the same time. Therefore, SAML acts as a Security password provider in the WS-Security Framework.