There is good safety features with in MySAP office structure using the SSO technology .Protecting the mySAP.com Office in opposition to attacks requires safety measures that must be based mostly on the Office structure and components installed.The mySAP.com Office gives customers a single point of access to all capabilities, information, and companies wanted to accomplish their each day tasks. Hyperlinks to back end and legacy applications, self-service functions, firm intranet providers, and Web providers are all available within the user’s Workplace. As a outcome of the borders between company intranets and the Internet are blurring, complete safety is vital to guard the companies’ businesses.
The security features used in the mySAP.com Workplace include:
mySAP Office Role-Based Authorization Concept
The mySAP.com role idea relies on the SAP authorization concept.When users go online to their Office, they obtain the personalized LaunchPad, containing hyperlinks to the data and providers for his or her day by day work and MiniApps containing data from accessible applications. Right here, accessible purposes means functions that the person has the best to access. The customers’ personalized menus and the corresponding authorizations are assigned based mostly on the roles they have in the company. Central person administration helps in creating, assigning, and distributing roles and authorizations. Present activity teams might be assigned to roles. Users can individually design the content material of the Launch Pad and the MiniApps, but they cannot change the function definition for security reasons. Only directors can change the function definition to set actions and related MiniApps.
SAP Trust Center Providers
The focus of the SAP Belief Heart Service is to supply global one-step authentication and digital signature know-how for enabling collaborative enterprise scenarios.The trust infrastructure relies on already existing business relationships between SAP and its customers. The SAP Belief Middle supplies more belief than another existing trust heart as a outcome of others don't usually depend on current business relationships. This service supplies a smooth migration from password based authentication to certificate-primarily based authentication.
The Trust Center Service works with the customer’s inside mySAP Workplace to distribute digital certificates-referred to as SAP Passports-to individual users. The SAP Passport relies on the X.509 certificate commonplace and allows data to be encrypted and transmitted safely over intranets and open Internet connections. mySAP.com clients using the Belief Center Companies can ensure that solely licensed companions and workers are accessing information and conducting business in mySAP Marketplaces.
If SAP users wish to apply for a SAP Passport once they go surfing to their Workplace, their UID (person identification) and password is used. The Workplace server transfers the consumer as effectively as the company’s identification to the Internet browser of the user. The Web browser then automatically generates an asymmetric public/private key pair. After receiving and verifying the certificate request containing the user’s and the corporate’s id and the general public key from the Web browser, the Workplace Server approves the certificates request with its digital signature. The Internet browser then sends the accredited certificate request to the SAP Trust Center Service.
mySAP Workplace SSO
As was extensively defined , the mySAP Workplace provides an intranet and Internet portal, which drastically facilitates a large amount of providers, business processes, and knowledge for users. These companies and knowledge are offered by methods that could be each mySAP and non-SAP and would possibly every have different entry and administration policies.
One of the major benefits of the mySAP Workplace is the possibility of logging in solely once (SSO) to entry all services. This log in course of takes places within the Office system, and from there, the customers can work with the providers and functions as outlined of their role and that is perhaps distributed across completely different systems.Which means with the SSO, the customers can navigate by way of the totally different capabilities and providers from the Workplace without requiring to log in every time they access the completely different techniques that may be supporting the functions or providers provided.
This has obvious security considerations for techniques and for access restrictions. mySAP Office can resolve this security challenge with several totally different strategies:
SSO primarily based on user ID and password This method has the advantage of utilizing the prevailing authentication process in SAP R/3 systems. The customers log in to the Office and identify themselves utilizing the same username and password. Once accurately authenticated, the customers receive their personalized function-based menus. They do not have to further determine
themselves (in SAP systems).The mySAP Office supports two different SSO mechanisms based on user ID and password.
The Workplace can be custom-made so that the SSO feature will not be enabled. In this case, the customers must authenticate in each system that they want to access.
SSO Cookies
To configure the SSO surroundings, the Workplace server gives the person identification to the rest of component techniques that make up the company portal. This is finished by utilizing a cookie that the system locates in the user’s Web browser. This cookie will doubtless be obtainable for the remainder of the techniques and is used to correctly establish the customers as they navigate through the element systems.When users log off of the Workplace, the cookie is removed and is not accessible for the Workplace anymore. When the customers need to join again, they should authenticate first.
The requirements for SSO are:
There are also some restrictions to be considered:
When a person first connects to the Office, the corresponding Net server (as defined within the Workplace structure) units a cookie in the user’s Internet browser. When the consumer accesses any of the component programs that are integrated within the Office (and for which he or she has access), the cookie saved in the Web browser is sent to the system. This cookie provides the goal system with the required consumer credentials for authentication and therefore for logging in (executing the report, transaction, or service).
The method circulate for identification utilizing SSO cookies is covered here.Two phases may be established:
Initial connection
1. The user enters the Office URL in the Internet browser or clicks on a link to it.
2. The request is sent to the Workplace server by the Workplace
Middle ware (Net server)
SSO Tickets enhance the safety of the SSO environment and get rid of some of the restrictions that apply to SSO cookies. SSO Tickets are cookies which can be saved in the browser as effectively, but the knowledge saved within the Ticket is completely different from the info stored in SSO cookies. If you're using SSO Tickets, customers must have the identical consumer ID in the entire techniques, however they aren't required to have the same password for these accounts.
In contrast to SSO cookies, SSO Tickets do not retailer the password of the user. The tickets include the ID of the consumer and extra session information. This information is digitally signed with the non-public key of the Office system. The part methods can use the public key of the Workplace server to examine the signature of the ticket.
The SSO Administration Wizard (transaction SSO2) assists you in organizing SSO with Tickets and may mechanically import the public key of the workplace server by means of RFC.
The method flow for identification using SSO Tickets entails two phases.
Initial connection:
SSO Primarily based on Digital Certificates (X.509)
Digital certificates work like digital signatures, as beforehand explained on this chapter. The public key certificates acts as the digital identification that authenticates a person or application.The certificates of a holder contains all of the required data for figuring out the digital signature (the normal public key) and the algorithm that can be used.
The data contained within the X.509 standard is:
As a reminder to create a digital signature, the signatory has a pair of keys: one public, which is equipped to all goal or accomplice techniques, and one non-public, which is utilized by the signatory to generate the digital signature. Not one in all the keys must be obtained in any mathematical method from the other.The public key should be recognized to these methods or receivers in which the digital signature needs to be verified. Usually there is a particular entity referred to as the CA that securely generates and distributes these keys and assign them to users, servers, or signatories. It can be in comparability with the public administration in charge of offering passports to citizens. To digitally sign a document, the signatory makes use of her or his non-public key and the mathematical algorithm to process the document to be signed. The receiver of the digitally signed doc must verify the authenticity of the signature by using the signatory public key, which will have to have been previously received. Each the signature and the document integrity are verified in order to test that the content has not been modified in the transfer process.
There are a quantity of questions that can be deduced from this process. For instance:
The answer is basically that the normal public secret's normally generated by a CA and supplies the pair of keys to a signatory by issuing a digital certificate, which accommodates the required information to ensure that the public key belongs to the correct person. This certificates is utilized by senders to identify themselves to other partners. The public secret's usually distributed by mail or through the use of other companies just like the X.500 Listing Services.
Use of Certificates in the mySAP Office
The user certificates utilizing the X.509 standard for connecting to the Workplace is processed and verified by the Internet server using the SSL protocol.With this kind of connection, there is not any want for getting into a username and password. Within the mySAP atmosphere, the CA is identified as a Belief Center. SAP has enabled its own Trust Center. As a outcome of the protocol used is SSL, the connection between the Net browser and the Web server must be HTTPS.When certificates are used for connecting different SAP system parts, such because the ITS W-Gate, the ITS A-Gate, and the Utility Server, it is essential to use the SNC protocol. The necessities are as follows:
Related posts
sap internet transaction architecture
SAP internet transaction application components
SAP authorization and client administration in mysap.com
SAP Authorization and ALE
CREATION OF SMART FORMS
CREATION OF SMART FORMS PART TWO
CREATION OF SMART FORMS PART THREE
The security features used in the mySAP.com Workplace include:
- SSO, using both person identification and passwords or X.509 consumer certificates with the SSL Web protocol
- Position-primarily based authorization idea
- Simplified maintenance using central user administration
- Knowledge encryption utilizing the SSL protocol and the SAP SNC layer
- Secure business document trade with digital signatures
mySAP Office Role-Based Authorization Concept
The mySAP.com role idea relies on the SAP authorization concept.When users go online to their Office, they obtain the personalized LaunchPad, containing hyperlinks to the data and providers for his or her day by day work and MiniApps containing data from accessible applications. Right here, accessible purposes means functions that the person has the best to access. The customers’ personalized menus and the corresponding authorizations are assigned based mostly on the roles they have in the company. Central person administration helps in creating, assigning, and distributing roles and authorizations. Present activity teams might be assigned to roles. Users can individually design the content material of the Launch Pad and the MiniApps, but they cannot change the function definition for security reasons. Only directors can change the function definition to set actions and related MiniApps.
SAP Trust Center Providers
The focus of the SAP Belief Heart Service is to supply global one-step authentication and digital signature know-how for enabling collaborative enterprise scenarios.The trust infrastructure relies on already existing business relationships between SAP and its customers. The SAP Belief Middle supplies more belief than another existing trust heart as a outcome of others don't usually depend on current business relationships. This service supplies a smooth migration from password based authentication to certificate-primarily based authentication.
The Trust Center Service works with the customer’s inside mySAP Workplace to distribute digital certificates-referred to as SAP Passports-to individual users. The SAP Passport relies on the X.509 certificate commonplace and allows data to be encrypted and transmitted safely over intranets and open Internet connections. mySAP.com clients using the Belief Center Companies can ensure that solely licensed companions and workers are accessing information and conducting business in mySAP Marketplaces.
If SAP users wish to apply for a SAP Passport once they go surfing to their Workplace, their UID (person identification) and password is used. The Workplace server transfers the consumer as effectively as the company’s identification to the Internet browser of the user. The Web browser then automatically generates an asymmetric public/private key pair. After receiving and verifying the certificate request containing the user’s and the corporate’s id and the general public key from the Web browser, the Workplace Server approves the certificates request with its digital signature. The Internet browser then sends the accredited certificate request to the SAP Trust Center Service.
mySAP Workplace SSO
As was extensively defined , the mySAP Workplace provides an intranet and Internet portal, which drastically facilitates a large amount of providers, business processes, and knowledge for users. These companies and knowledge are offered by methods that could be each mySAP and non-SAP and would possibly every have different entry and administration policies.
One of the major benefits of the mySAP Workplace is the possibility of logging in solely once (SSO) to entry all services. This log in course of takes places within the Office system, and from there, the customers can work with the providers and functions as outlined of their role and that is perhaps distributed across completely different systems.Which means with the SSO, the customers can navigate by way of the totally different capabilities and providers from the Workplace without requiring to log in every time they access the completely different techniques that may be supporting the functions or providers provided.
This has obvious security considerations for techniques and for access restrictions. mySAP Office can resolve this security challenge with several totally different strategies:
SSO primarily based on user ID and password This method has the advantage of utilizing the prevailing authentication process in SAP R/3 systems. The customers log in to the Office and identify themselves utilizing the same username and password. Once accurately authenticated, the customers receive their personalized function-based menus. They do not have to further determine
themselves (in SAP systems).The mySAP Office supports two different SSO mechanisms based on user ID and password.
- SSO cookies
- SSO Tickets
- SSO primarily based on certificates (X.509). This method uses digital certificates to determine the person logging on to the Workplace.
The Workplace can be custom-made so that the SSO feature will not be enabled. In this case, the customers must authenticate in each system that they want to access.
SSO Cookies
To configure the SSO surroundings, the Workplace server gives the person identification to the rest of component techniques that make up the company portal. This is finished by utilizing a cookie that the system locates in the user’s Web browser. This cookie will doubtless be obtainable for the remainder of the techniques and is used to correctly establish the customers as they navigate through the element systems.When users log off of the Workplace, the cookie is removed and is not accessible for the Workplace anymore. When the customers need to join again, they should authenticate first.
The requirements for SSO are:
- The users will must have the identical username and password in each of the element methods accessed from the Workplace. If this is not the case, the customers must determine themselves in each of the methods they need to access.
- Users should configure their Web browsers in order that they will accept cookies. Normal Net browser configurations have this default setting. Nonetheless, if the safety options within the browser are set to excessive, then usually the browser doesn't settle for cookies.
There are also some restrictions to be considered:
- The SSO cookie is held on the person’s Internet browser memory. If the consumer closes the browser, the cookie is lost and the consumer has to establish if she or he desires to connect once more to the Workplace.
- The cookie expires after some time (default value is 60 hours). If it expires whereas linked, the system would require the person to authenticate once more within the Workplace.
- The SSO method using cookies works throughout the similar area (the Internet). It signifies that the cookies established by a Web server are only dispatched to Web servers which are in the same domain.
When a person first connects to the Office, the corresponding Net server (as defined within the Workplace structure) units a cookie in the user’s Internet browser. When the consumer accesses any of the component programs that are integrated within the Office (and for which he or she has access), the cookie saved in the Web browser is sent to the system. This cookie provides the goal system with the required consumer credentials for authentication and therefore for logging in (executing the report, transaction, or service).
The method circulate for identification utilizing SSO cookies is covered here.Two phases may be established:
Initial connection
1. The user enters the Office URL in the Internet browser or clicks on a link to it.
2. The request is sent to the Workplace server by the Workplace
Middle ware (Net server)
- The server requests the user to establish with username and password.
- The Office server validates the information. After validation, the
- Workplace sends the user its personalized role-primarily based menu, which is displayed in the Net browser, and the Net server sends the SSO cookie to the consumer’s Net browser.
- Access to the part techniques after initial connection:
- The Web browser sends the cookie to the system the person needs to access (it could possibly be utilizing each ITS and SAPGUI for Home windows).
- The target system verifies the person info that's contained in the cookie. If the knowledge is appropriate, the system allows the consumer to access without needing to authenticate once more . If the information is not right, then the system requests the person for log in information (username and password).
- Cookies are not dispatched to systems whose area is completely different from the domain of the Web server of the Workplace.
- Some safety settings which are out there and some default work for protecting cookies include:
- The cookies are solely sent to systems within the identical area as the Workplace.
- Cookies aren't persistent, which implies that they are not held on the workstation hard disk however in memory.
- Cookies include an expiration time (default is 60 hours). The parameter that sets this limit is user timeout. This parameter is set within the world service file of the Office Middle ware (ITS). This file is global.srvc.
- The cookies’ content is encrypted.
SSO Tickets enhance the safety of the SSO environment and get rid of some of the restrictions that apply to SSO cookies. SSO Tickets are cookies which can be saved in the browser as effectively, but the knowledge saved within the Ticket is completely different from the info stored in SSO cookies. If you're using SSO Tickets, customers must have the identical consumer ID in the entire techniques, however they aren't required to have the same password for these accounts.
In contrast to SSO cookies, SSO Tickets do not retailer the password of the user. The tickets include the ID of the consumer and extra session information. This information is digitally signed with the non-public key of the Office system. The part methods can use the public key of the Workplace server to examine the signature of the ticket.
The SSO Administration Wizard (transaction SSO2) assists you in organizing SSO with Tickets and may mechanically import the public key of the workplace server by means of RFC.
The method flow for identification using SSO Tickets entails two phases.
Initial connection:
- The consumer enters the Workplace URL within the Internet browser or clicks on a hyperlink to it.
- The request is sent to the Workplace server by approach of the Office Middle ware (Internet server).
- The server requests the person to establish with username and password.
- The Workplace server validates the information. After validation, the Office sends the consumer its customized position-based menu, which is displayed within the Net browser. The Office server creates the shopper’s log on Ticket, signs it with its personal key, and sends it by the Workplace Middle ware to the person’s Net browser.
- The Web browser sends the Ticket to the system the user wants to access.
- The goal system verifies the Ticket with the general public key of the Workplace server. If the Ticket is correct, the user ID saved within the Ticket is used for logging on without having to authenticate again. If the information will not be right (for instance, the user has a distinct consumer ID within the system being accessed), the system requests the person for log in information (username and password).
SSO Primarily based on Digital Certificates (X.509)
Digital certificates work like digital signatures, as beforehand explained on this chapter. The public key certificates acts as the digital identification that authenticates a person or application.The certificates of a holder contains all of the required data for figuring out the digital signature (the normal public key) and the algorithm that can be used.
The data contained within the X.509 standard is:
- Normal info
- Version
- Serial quantity
- Validity period
- Certificate proprietor’s data
- Owner’s title
- Proprietor’s distinguished title
- Owner’s public key
- Hash algorithm used for the owner’s signature
- CA data
- CA’s identify
- CA’s distinguished identify
- CA’s public key
- Hash algorithm used for the CA’s signature
- CA’s signature
As a reminder to create a digital signature, the signatory has a pair of keys: one public, which is equipped to all goal or accomplice techniques, and one non-public, which is utilized by the signatory to generate the digital signature. Not one in all the keys must be obtained in any mathematical method from the other.The public key should be recognized to these methods or receivers in which the digital signature needs to be verified. Usually there is a particular entity referred to as the CA that securely generates and distributes these keys and assign them to users, servers, or signatories. It can be in comparability with the public administration in charge of offering passports to citizens. To digitally sign a document, the signatory makes use of her or his non-public key and the mathematical algorithm to process the document to be signed. The receiver of the digitally signed doc must verify the authenticity of the signature by using the signatory public key, which will have to have been previously received. Each the signature and the document integrity are verified in order to test that the content has not been modified in the transfer process.
There are a quantity of questions that can be deduced from this process. For instance:
- How do you know which public key belongs to whom?
- How do we obtain the normal public key from communication companions?
The answer is basically that the normal public secret's normally generated by a CA and supplies the pair of keys to a signatory by issuing a digital certificate, which accommodates the required information to ensure that the public key belongs to the correct person. This certificates is utilized by senders to identify themselves to other partners. The public secret's usually distributed by mail or through the use of other companies just like the X.500 Listing Services.
Use of Certificates in the mySAP Office
The user certificates utilizing the X.509 standard for connecting to the Workplace is processed and verified by the Internet server using the SSL protocol.With this kind of connection, there is not any want for getting into a username and password. Within the mySAP atmosphere, the CA is identified as a Belief Center. SAP has enabled its own Trust Center. As a outcome of the protocol used is SSL, the connection between the Net browser and the Web server must be HTTPS.When certificates are used for connecting different SAP system parts, such because the ITS W-Gate, the ITS A-Gate, and the Utility Server, it is essential to use the SNC protocol. The necessities are as follows:
- Set up a PKI or use a Belief Heart (CA) for getting the certificates.
- Configure the Web servers for managing HTTPS connections.
- Configure the Net servers for accepting person certificates.
- Activate and configure the techniques for utilizing SNC.
- Configure the mySAP systems for utilizing X.509 certificates.
- Establish the mapping between the person certificates and the usernames (identification) within the SAP systems.
- The users additionally should import or install their certificates within the
- Net browser.
Related posts
sap internet transaction architecture
SAP internet transaction application components
SAP authorization and client administration in mysap.com
SAP Authorization and ALE
CREATION OF SMART FORMS
CREATION OF SMART FORMS PART TWO
CREATION OF SMART FORMS PART THREE
No comments :
Post a Comment