Following situation:
An SAP OnPremise system is connected over cloud connector to SAP HCP
In the cloud version of the SAP mobile plattform (SMP) I configured the system
I have a hybrid app (using SAP Kapsel SDK) and try to connect to
a) SMP itself (registring)
b) also to the real backend sytem with the data needed
User name of SMP and backend system is not the same
Does anyone have a good tutorial / documentation link how to setup this correct?
I found a very good tutorial about the Kapsel plugins:
- https://blogs.sap.com/2016/10/20/getting-started-kapsel-part-1-sp13/
With a trial account and a trial backend account (same user name) it seems somehow working. But in my situation it is more complex.
Problem in other words (Edit)
I am searching for a way to use user & password from OnPremise system to authenticate against HCPms over a Hybrid app.
May I ask why you require two different users at all? From a usability point of view, it is very awkward for a user to give two sets of credentials for an app. I'd typically recommend to either
configure SCIM in Mobile Services. This would allow you to register with Mobile Services using your back-end credentials
configure no-auth in Mobile Services. While users still need to give their credentials for back-end access, they can register with Mobile Services without credentials at all
The rest depends on your back-end configuration. For example, if it requires Basic auth, configure your back-end connection accordingly and leave the user/password fields empty. When you supply those with your client requests, they will be forwarded to your back-end.
Edit: I misread the question and thought you were using "SAP Cloud Platform Mobile Service", the cloud equivalent of the SAP Mobile Platform. The answer basically remains the same, only the terminology changes (italic):
configure HTTP(s)-based Basic Authentication SSO in Mobile Platform. This would allow you to register with Mobile Platform using your back-end credentials.
configure no-auth in Mobile Platform. While users still need to give their credentials for back-end access, they can register with Mobile Platform without credentials at all
Either way, SCIM for Mobile Service is described in the documentation, and so is Basic authentication for Mobile Platform.
Related
I am pretty new to Authorization/Authentication with openid connect. I guess I lack some basic understanding on how to set up a proper backend infrastructure.
There's a keycloak server running through which I want to authorize/authenticate my customers.
The user logs in by his company credentials and then should be authorized/authenticated against our backend service, which provides a REST-API.
So our part is to implement the backend service and use openid connect as authorization/authentication.
Could you tell me what components/software needs to be implemented on our side?
Often the Authorization Server is an external cloud system that your UIs and APIs just point to, with URLs equivalent to this:
https://api.mycompany.com/myapi
https://web.mycompany.app/myapp
https://login.mycompany.com
Not sure if this quite matches your setup but typically you provide some or all of these domains:
API
Web Hosting
Authorization Server (Keycloak)
My personal preference is to use Local Developer PC Domains to match the above. If it helps you might just be able to repoint my Open Id Connect
Code Sample to your infra once configured, in order to verify that it works.
Be warned possibly noob question ahead.
I'm a little unsure where exactly Azure AD or IdentityServer is supposed to fit in in the overall communication flow.
Here is a scenario that I often face.
Some "dumb" client (e.g. a Windows App that can't use external assemblies or some JavaScript in a web app) has to contact my Web API which will then contact other APIs or other resources.
If I want to try and implement either Azure AD or IdentityServer as a means of authentication and authorization in the Web API, I don't see that this can be done in any other way, than it has to be the Web API that communicates with Azure AD or IdentityServer as the client doesn't have the ability to do so due to the lack of required assemblies.
If this assumption is not correct, then how would I do this?
If it is correct however, then what means of security is there between the client and the Web API other than communicating over HTTPS when the client has to send it's credentials to the Web API, so the Web API can authenticate and authorize the user against either Azure AD or IdentityServer?
If I understand your requirements correctly, then you are able to change the client Windows app, but unable to add external assemblies to it? So you would not be able to add the ADAL NuGet package to it.
You can still use Azure AD authentication - it is possible, but not trivial, to implement the client code yourself.
Or you can, as you already mentioned, pass the user's credentials to the Web API somehow, and then use that to have the Web API do authentication towards Azure AD on behalf of the user. There is a sample app which shows how to use username/password credentials.
This however, goes against the whole OAuth/OpenIdConnect mindset, where your app should never know the user's credentials.
Here:
https://github.com/MicrosoftDocs/azure-docs/blob/master/articles/active-directory/develop/active-directory-v2-protocols-oidc.md
Be careful with trying to use the most recent version of the Azure AD endpoint (just don't use version 2.0, they shot themselves in the foot by excluding all Azure AD webapp registrations & by "securing" web APIs by making them only available to apps with the same appid - as far as I'm concerned, it's unusable until they fix those two issues) - see the "[!NOTE]" near the top of that linked page for the v2.0 limitations.
Is it generally possible to have a Microsoft Azure in the background to act as a SSO Authentication server for Apache auth?
The example is:
There are many users inside the Microsoft Azure
I have a Webpage on a Linux server served by Apache2
The webpage should be protected (exactly like basic-auth) by Azure (via SSO)
If the user is signed in into Azure and has rights, he can see the website
If the user is not signed in, he will be redirected back to Azure's login-page and after successful login will back to the webpage.
Is this generally possible?
If so what technologies/modules do I have to use for apache in order to speak with Azure?
Thanks for any hints towards the right direction.
Update
The Azure server is already fully configured. I just need to sort out the end on Apache.
I think what you are looking for is Azure Active Directory. it is an Identity as a Service product that supports modern protocols like OAuth, OpenID Connect. There's a client SDK called ADAL (Active Directory Authentication Library), but since it's standard protocols, you can integrate with other standard based authentication libraries. For example, the node.js tutorial shows how to use passport.
You didn't mention what web stack you are using but it's most likely listed here:
https://azure.microsoft.com/en-us/documentation/articles/active-directory-developers-guide/
On a side note: if you can host your app on Azure Web App Service then it has built in integration with Azure Active Directory, so you can add a layer of authentication on top of your website without modifying your application code.
More info on that here: https://azure.microsoft.com/en-us/documentation/articles/app-service-mobile-how-to-configure-active-directory-authentication/
I recently started a new project using different carefully-chosen technologies, my project is built as follow :
The approach is API-Centric, which means I'm building a website and an iOS app communicating with an API written using Symfony2. I've successfully managed to write my API, and it is perfectly working.
To gain access to the services provided by the API, the main actors (the website users, the iOS app users and the developers) can authenticate theirself in several ways :
Clients can gain access with a login/password couple through the website interface which is communicating directly with the API through AJAX to validate the provided credentials and set a session. So, when someones logs in our website, they have automatically access to the API as well.
Developers can authenticate theirself through the API using HTTP-Basic over SSL, which will as well generate a session and give them access to the services they are authorized to call.
Also, Developers and clients can gain access to the website and the API using their facebook account through the Facebook Connect functionality. This deletes the step where each actor has to create an account on our website.
So basically, the credentials are provided either through HTTP-Basic or using the Facebook Login functionality.
Now that my authentication system is working and that my clients are able to access the website, I would like them to connect to a real-time server when they log in. Like in Facebook or Google+ if you want where the real-time server manages chat and push informations.
In this case i'm using Node.js and the powerfull socket.io library to manage everything that deals with the real-time side.
Of course, the real-time service will need some credentials to authenticate the user since he is authenticated to the Symfony security system with a session but is not authenticated against the real-time server.
A solution I've been thinking about would be to use the PdoSessionStorage in my API (Symfony side) and store all the active sessions in a database such as MySQL or PostgreSQL. Doing so, I would be able to send to my real-time server the session id generated by symfony and check on the database if the session id provided is correct or not. If he is I'll let the user access the services provided by my real-time server and associate his session with an identity.
But I really don;t know if this is a good solution and I would like some more experienced advices on this and on how to deal with this issue.
Note : For some reasons, I cannot implement OAuth even if it could be a solution to solve this issue using a Single Sign On approach.
I'm currently planning a new web project. Clients are going to connect using a regular web browser and, in case of regular java-enabled cell phones, j2me client. I would really like to make use of the OpenID authentication. In case of regular web browser things are pretty straightforward. However, I am really not sure about installed applications (such as j2me client installed on a mobile device) - regular OpenID authentication is performed by entering username/password on a webpage of particular OpenID provider - which is quite a limitation :)
Has anyone coped with such a situation? Is it possible to create authentication mechanism to the site that uses OpenID from a mobile j2me client?
Currently, I think of solution that users who would like to connect from their mobiles download necessary j2me application from the server web site after they have authenticated themselves (regular browser authentication). The mobile client app could be assembled dynamically on the server with the SSL certificate embedded that is associated with particular logged in OpenID user. After that, j2me client could authenticate to the server without entering any username/password. The data that is going to be stored on the server is not THAT sensitive - considering cases of mobile phone thefts etc.
Can anybody come up with a better solution?
The best solution IMO for what you're doing is to use OAuth combined with OpenID. You're use of OpenID at the RP is fine. But for installed applications that need access to that web site, they should use OAuth to get authorized. The flow would work like this:
User installs app on their device
During install or on first launch, the app has an "Authorize me" button.
The user presses the button and a web browser pops up the web site that the client app needs to access data from.
User logs into that site using their OpenID
Site now asks "do you want to authorize client app X?"
User says yes and closes the browser.
The client app reappears and says "thanks." and now has the OAuth token necessary to access the user's data without the user ever logging in again.