cancel
Showing results for 
Search instead for 
Did you mean: 

Authentication as a service providers and compatibility with SAP Java AS

Former Member
0 Kudos

Hi,

For several internet facing applications based on SAP and non-SAP, I am looking at the possibility of using an authentication as a service provider to provide common user repository and logon behaviour.

The internet facing SAP systems will all be Java AS based.

In an authentication as a service scenario the third party would perform the authentication of the user (at least the more secure second factor authentication). The result of this authentication will of course have to be passed back to the SAP JAVA AS system, which will have defined a trust towards the third party authentication as a service provider.

I am currently looking at which standards of authentication result tokens are supported by SAP JAVA AS?

(alot is possible through the implementation of custom JAAS login modules, but support is important in this scenarion)

I assume that SAML Assertions (http://help.sap.com/saphelp_nw04/helpdata/en/94/695b3ebd564644e10000000a114084/frameset.htm) are the way to go, but can other tokens also be used ?

For example OpenID/Oauth can probably be implemented, but I am not sure if this is supported.

Also, if anyone else have experience with authentication as a service and SAP system I would love to hear more about your solution architecture.

Regards

Dagfinn

Accepted Solutions (1)

Accepted Solutions (1)

richard_hirsch
Active Contributor
0 Kudos

Hi,

Regarding OpenId: have you seen this [http://www.sdn.sap.com/irj/scn/weblogs?blog=/pub/wlg/9911] [original link is broken] [original link is broken] [original link is broken];?

SAML is definitely the way to go and is actually the standard regarding identity federation.

What sort of external authentication are you talking about? Some sort of third-party identity broker or would the identity provider be another portal?

Are we talking about an extranet portal (partners, etc.) or a portal that is more focused on consumers as end-users?

D.

Former Member
0 Kudos

Hi Richard,

Knew there was some work done on OpenId, but not that it had progressed so far.

Hopefully, this will be a supported part of SAP NetWeaver in future releases.

>

> What sort of external authentication are you talking about? Some sort of third-party identity broker or would the identity provider be another portal?

>

This will be a third-party identity broker which should contain the user repository. Users in SAP back-end system will need to be synchronized with this repository by a tool like Microsoft Identity Integration Server.

We want an access zone (which is delivered as Authentication as a Service) and web front-end zone (which contains both non-SAP system and SAP JAVA AS web front-ends).

The initial logon page will therefore have to be hosted as part of the Authentication as a Service, which on successful authentication will redirect or acts as a proxy for the user to the web front-end zone and including an identity assertion.

>

> Are we talking about an extranet portal (partners, etc.) or a portal that is more focused on consumers as end-users?

>

We're talking about both B2C and B2B. The number of users will be high and it is not an option to distribute RSA type dongles.

Cheers

richard_hirsch
Active Contributor
0 Kudos

> >

> The initial logon page will therefore have to be hosted as part of the Authentication as a Service, which on successful authentication will redirect or acts as a proxy for the user to the web front-end zone and including an identity assertion.

> >

This sound like a normal SAML-based SSO - as you suggested in the initial post.

>

> We're talking about both B2C and B2B. The number of users will be high and it is not an option to distribute RSA type dongles.

What about the identities? Are they known by the partners and the SAP portal? Are the identity ids the same? How is the identity lifecycle dealt with? How are new identities provisioned to the SAP portal? Will the B2B partners host act as IdPs or are third parties involved? You may need to look at some sort of federated identity.

D.

koehntopp
Product and Topic Expert
Product and Topic Expert
0 Kudos

Thread moved - probably more knowledgeable people reading this forum.

Frank.

Former Member
0 Kudos

Hi,

>

>

> What about the identities? Are they known by the partners and the SAP portal? Are the identity ids the same? How is the identity lifecycle dealt with? How are new identities provisioned to the SAP portal? Will the B2B partners host act as IdPs or are third parties involved? You may need to look at some sort of federated identity.

>.

All user identities will be based on e-mail addresses.

The first application application is a CRM based B2Bshop in which will have a SAP backend system as the master for user identities. It will synchronize users with the Authentication as a service provide and include information needed to perform identity lifecycle there. For this application, new identities will always have to be created in SAP backend system (though the request might come from a form hosted by the Authentication as a service provider)

The B2B partners will not federate users yet, but it is important that the architecture allows for this in the future

(compatibility with Active Directory Federation Services 2.0 will then be important)

The authentication as a service provider will be responsible for authentication related information (password, one-time key), whilst the SAP web front-end and backend will be responsible for authorizations. SAP web front-end will most likely have a UME connected to the SAP ABAP backend system.

Dagfinn

richard_hirsch
Active Contributor
0 Kudos

Hi,

I suggest we move this discussion to the wiki where we can create some architectural drawings - I've started a page [here|http://wiki.sdn.sap.com/wiki/display/Community/CAAS-AuthenticationasaserviceprovidersandcompatibilitywithSAPJavaAS] in the new section [Community as a Service|http://wiki.sdn.sap.com/wiki/display/Community/CommunityasaService].

I don't know how much you want to show/ share in such a public manner but I think doing architecture work via diagrams is more valuable.

By the way, what are the reasons that you need an external authentication source when all identities are stored in the SAP Back-end? Wouldn't it be easier to have the SAP NW environment perform the authentication?

D.

Former Member
0 Kudos

> By the way, what are the reasons that you need an external authentication source when all identities are stored in the SAP Back-end? Wouldn't it be easier to have the SAP NW environment perform the authentication?

This is because if you want SAP to perform the authentication as the SAML provider then you have to install and provide the user from SAP IdM as well as it is only shipped as a part of this component, not with "the Netweaver platform" unfortunately.

So, if you don't have an SAP IdM then you need an alternate external authentication provider (which is possibly why Frank Koehntopp moved this thread to the IdM forum).

Cheers,

Julius

Former Member
0 Kudos

>

> By the way, what are the reasons that you need an external authentication source when all identities are stored in the SAP Back-end? Wouldn't it be easier to have the SAP NW environment perform the authentication?

.

There are several reason, some which are specific to the company and others which could be called security best practices.

The key driver is that the SAP back-system is a business critical system which should ideally never be exposed in any way (direct or indirect) towards the internet. In order to provide sufficient security, several mitigating actions will be performed.

The reasons for choosing this "as a service" are more company-specific and could just as well be delivered by the company itself but through non-SAP components. However, the Intrusion detection and prevention are hard so it makes sense to have a provider which has specialized within the security area.

Some key principles in the solution:

1. Authentication should be performed in a separate access security zone, independent of the actual application

2. The result of the authentication should be some form of standardized security token, which is passed to the application server which verifies that it was signed by an authentication provider it trusts

3. The application server will use the same user store as the authentication provider, but will use it to read authorizations (group membership in addition to user object properties). In order to prevent Denial of service attacks, the user store should not be the SAP backend system (though it will probably be populated from the SAP backend system user store)

4. A protocol change must be done when the application communicates with the SAP back-end system (https to application, RFC/JCO to back-end)

4. SAP specific cookies and HTTP headers should be filtered out before reaching the client. This responsibility will usually be the authentication provider, and it also has to re-add them for incoming requests

The wiki page is a good idea. But is it best to do some discussion in this thread and document the "end-result" in the wiki?

Wolfgang: Thanks for the link to the excellent presentation and sorry about the confusion about OAuth. A future requirement for the Authentication as a service provider can be to support self-registration by using openid, but this is not focus for us now.

Cheers

Dagfinn

WolfgangJanzen
Product and Topic Expert
Product and Topic Expert
0 Kudos

By the way, what are the reasons that you need an external authentication source when all identities are stored in the SAP Back-end? Wouldn't it be easier to have the SAP NW environment perform the authentication?

Well, one reason could be: the desired authentication mechanism is not offered / supported by the service provider (here: SAP NetWeaver).

Some key principles in the solution:

1. Authentication should be performed in a separate access security zone, independent of the actual application

2. The result of the authentication should be some form of standardized security token, which is passed to the application server which verifies that it was signed by an authentication provider it trusts

3. The application server will use the same user store as the authentication provider, but will use it to read authorizations(group membership in addition to user object properties). In order to prevent Denial of service attacks, the user store should not be the SAP backend system (though it will probably be populated from the SAP backend system user store)

4. A protocol change must be done when the application communicates with the SAP back-end system (https to application, RFC/JCO to back-end)

5. SAP specific cookies and HTTP headers should be filtered out before reaching the client. This responsibility will usually be the authentication provider, and it also has to re-add them for incoming requests

ad 2: yes, e.g. a SAML Assertion Token

ad 3: no, it will not be the same user store - each SAML 2.0 entity has his own user management, trust management, session management, resource management, etc. - but you "federate" the account (sometimes also called "account linkage"). Kindly notice: SAML 2.0 only covers authentication aspects (SSO, SLO) - authorization statements are not part of SAML 2.0

ad 4: SAML 2.0 only supports http and https

ad 5: no - take care: each SAML 2.0 entity might set his own session cookies; those you must not filter out; SAML 2.0 is user-centric: it is expected that the user (agent) communicates with the SAML IdP as well as with the SAML SPs. Thus, the user agent has sessions with each SAML entity.

Former Member
0 Kudos

>

>

> Some key principles in the solution:

> 1. Authentication should be performed in a separate access security zone, independent of the actual application

> 2. The result of the authentication should be some form of standardized security token, which is passed to the application server which verifies that it was signed by an authentication provider it trusts

> 3. The application server will use the same user store as the authentication provider, but will use it to read authorizations(group membership in addition to user object properties). In order to prevent Denial of service attacks, the user store should not be the SAP backend system (though it will probably be populated from the SAP backend system user store)

> 4. A protocol change must be done when the application communicates with the SAP back-end system (https to application, RFC/JCO to back-end)

> 5. SAP specific cookies and HTTP headers should be filtered out before reaching the client. This responsibility will usually be the authentication provider, and it also has to re-add them for incoming requests

>

>

> ad 2: yes, e.g. a SAML Assertion Token

> ad 3: no, it will not be the same user store - each SAML 2.0 entity has his own user management, trust management, session management, resource management, etc. - but you "federate" the account (sometimes also called "account linkage"). Kindly notice: SAML 2.0 only covers authentication aspects (SSO, SLO) - authorization statements are not part of SAML 2.0

> ad 4: SAML 2.0 only supports http and https

> ad 5: no - take care: each SAML 2.0 entity might set his own session cookies; those you must not filter out; SAML 2.0 is user-centric: it is expected that the user (agent) communicates with the SAML IdP as well as with the SAML SPs. Thus, the user agent has sessions with each SAML entity.

Agree, that the standard SAML scenario doesn't solve all our problems, and in some cases we need some modification.

ad 3: Because SAP Java AS requires a user store and the SAML only provides authentication, not authorization, we will connect it to an LDAP and this must contains the same user id as the authentication provider. We have a couple of different ways to achieve this; though none very good and require unwanted dependencies to the "authentication as a service".

ad 4: Once the SAML token has been verified by the SAP Java AS, it will use SAP Logon Ticket for RFC connection to back-end. As far as I can see there should be no problems theoritically for sending an already existin SAML token over any protocol (but we will not try this here)

ad 5: Correct.In order to avoid exposing our SAP Java AS directly to the internet, we're looking at if the authentication as a service provider should function as a reverse proxy to them and pass the SAML assertion token there. Know that this is not how SAML works and may be difficult to get working. However, it makes sense that the authentication as a service provider delivers identity detection and prevention functionality in addition to SAML based authentication, and then "reverse proxy" is a must.

Regards

Dagfinn

WolfgangJanzen
Product and Topic Expert
Product and Topic Expert
0 Kudos

> Agree, that the standard SAML scenario doesn't solve all our problems, and in some cases we need some modification.

> ad 3: Because SAP Java AS requires a user store and the SAML only provides authentication, not authorization, we will connect it to an LDAP and this must contains the same user id as the authentication provider. We have a couple of different ways to achieve this; though none very good and require unwanted dependencies to the "authentication as a service".

Using an IdM (Identity Management) solution, you might be able to "pre-federate" the accounts (i.e. to provide the required SAML account mapping information to the SAML SP; in that case the user will not be prompted to federate his accounts (IdP account and SP account) the first time he attempts to logon to the SP using SAML). The SAP Identity Management solution provides such a feature.

> ad 4: Once the SAML token has been verified by the SAP Java AS, it will use SAP Logon Ticket for RFC connection to back-end. As far as I can see there should be no problems theoritically for sending an already existin SAML token over any protocol (but we will not try this here)

Well, in that case you are referring to a server-to-server communication (which anyway is beyond the scope of SAML 2.0).

Yes, you can use the Java Destination Service and configure it for a JCo connection to an ABAP system using "Assertion Tickets". They will be issued as long as you did authenticate at the NWAS Java (e.g. using SAML) and as long as NWAS Java knows how to map the Java UserID to an ABAP userID (because that information need to be contained in the Assertion Ticket).

> ad 5: Correct.In order to avoid exposing our SAP Java AS directly to the internet, we're looking at if the authentication as a service provider should function as a reverse proxy to them and pass the SAML assertion token there. Know that this is not how SAML works and may be difficult to get working. However, it makes sense that the authentication as a service provider delivers identity detection and prevention functionality in addition to SAML based authentication, and then "reverse proxy" is a must.

Good advice: try not to violate the standard.

There's no such thing like a SAML proxy. You need to allow the browser to communicate with the SAML 2.0 Identity Provider as well as to communicate with the SAML 2.0 Service Providers - but, of course, you can place some reverse proxies in between browser and SAML IdP / SP - as long as this happens transparently. Do not try to impose the requirement that the browser needs to communicate with the SAML SPs through the SAML IdP - this will not work. An SAML IdP is no proxy but offers communication endpoints, only. Please make yourself familiar with the SAML 2.0 standard and the roles of the various entities defined.

WolfgangJanzen
Product and Topic Expert
Product and Topic Expert
0 Kudos

> As far as I can see there should be no problems theoritically for sending an already existing SAML token over any protocol (but we will not try this here)

Sorry, but this will not work (RFC is not capable of accepting SAML tokens for authentication) - and there's no chance for you to change this. That's a fact you should know.

Former Member
0 Kudos

>

> > ad 5: Correct.In order to avoid exposing our SAP Java AS directly to the internet, we're looking at if the authentication as a service provider should function as a reverse proxy to them and pass the SAML assertion token there. Know that this is not how SAML works and may be difficult to get working. However, it makes sense that the authentication as a service provider delivers identity detection and prevention functionality in addition to SAML based authentication, and then "reverse proxy" is a must.

>

> Good advice: try not to violate the standard.

> There's no such thing like a SAML proxy. You need to allow the browser to communicate with the SAML 2.0 Identity Provider as well as to communicate with the SAML 2.0 Service Providers - but, of course, you can place some reverse proxies in between browser and SAML IdP / SP - as long as this happens transparently. Do not try to impose the requirement that the browser needs to communicate with the SAML SPs through the SAML IdP - this will not work. An SAML IdP is no proxy but offers communication endpoints, only. Please make yourself familiar with the SAML 2.0 standard and the roles of the various entities defined.

In practice what we do is splitting the Service Provider in two parts; one delivered by the external vendor of authentication as a service and and one from our SAP NetWeaver Java AS.

The SP part from the external vendor of is exposed to the internet and handles Denial of service protection and possibly some form of intrusion detection and prevention. It does not validate any SAML tokens against the IdP, but it may check if one exist. The SAP NetWeaver JAVA AS is not exposed to the internet, but through a reverse proxy at the external vendor. For SAP NetWeaver Java AS this is transparent and it will communicates through HTTP POST to the IdP in order to validate the SAML 1.1 browser artifact it received.

Closing this thread for now, but will try to update the wiki once I have some more info.

Answers (1)

Answers (1)

WolfgangJanzen
Product and Topic Expert
Product and Topic Expert
0 Kudos

For several internet facing applications based on SAP and non-SAP, I am looking at the possibility of using an authentication as a service provider to provide common user repository and logon behaviour.

This is a requirement for SAML 2.0 - with NWAS Java in the role of a SAML 2.0 SP (Service Provider) and an external component in the role of a SAML 2.0 IdP (Identity Provider).

See also: [Next Generation SSO for SAP Applications with SAML 2.0|http://www.sdn.sap.com/irj/sdn/security?rid=/library/uuid/30fe0e7b-b334-2d10-45b0-f35afb25a5bc]

> For example OpenID/Oauth can probably be implemented, but I am not sure if this is supported.

OAuth is not about authentication - but only about "controlled access to protected resources" (resource owner grants access to OAuth client). Currently not supported.