Is it possible for a WEBSERVICE application to behave like a Service provider and get a validated saml token from IDP?
Any example or any pointers will be helpful.
Related
I have a web app developed using Create-react-app
I host it on IIS, the IIS only response to load the app, there is no server side logic on it (no Express or any other web server)
The app is using a RESTful API on the same IIS, it is out of my control (I cannot make change).
Now one of my client request to add SAML SSO to our app.
I would like to know:
in normal situation, which one is the Service Provider? My IIS Web server? or the API service?
For my case, I cannot implement SAML to API service, my web service only used to load my app without server side logic, how can I implement SAML?
Could any one give me some React implement SAML SSO tutorial or article for reference?
Thanks for any help, any information or suggestion are welcome!
in normal situation, which one is the Service Provider? My IIS Web server? or the API service?
I assume the client wants to authenticate the users using their internal IdP. So your application is the SP. But you will have to define different token service (details below).
With SPA (a single-page-applications) I see the problem, in SAML the user is redirected or posted away from the SAML request and SAML response.
I have a login page to enter id/pw, post them to API server Login endpoint to authenticate and get back a JWT token. After that we use that token in API calls for authentication
The API services are using a JWT token issued based on the provided username/password. I'd recommend to extend the token service (or use a different service) to issue a JWT token based on the provided SAML response - a token swap service. In many OAuth implementations it's called SAML grant type.
I cannot implement SAML to API service, my web service only used to load my app without server side logic, how can I implement SAML?
Usually after the authentication the user is redirected or posted to the SAML ACS endpoint URL, where the server can create sort of session (cookie, parameters, token, ..) and the user is redirected to a URL returned the web page with the session information.
If you are using an SPA, you could use a popup window or SAML with redirect (not with post), where the page could read the SAML response parameters (assertion, signature, ..) and use them in the token swap service mentioned above.
When processing the SAML response, try to use some mature, known, out-of-box libraries, it's a security service and not doing it properly may cause security weaknesses. But you need to do that on the server side, as at the end you need the JWT token consumed by the APIs.
I want to understand how a static site with no backend can use okta with other custom API services hosted on other platforms.
Scenerio:
Website is a angluar/reactjs that is hosted as a "static" website.
I'm assuming when you authenticate using okta in e.g. react/angular website I am able to store the okta session id in local storage or cookie.
How say I create a web service and host that on heroku, how can I figure out if the user has authenticated or not and re-use the session?
The scenario where you have:
A JavaScript frontend application, hosted statically
A backend web service (API), that the JavaScript app makes API requests to
is a classic single-page app (SPA) scenario. The recommended authentication flow is the OpenID Connect implicit flow.
In plain English, you are:
Setting up your JavaScript app to talk to Okta (or another OpenID Connect identity provider)
Getting an access token from the identity provider
Attaching the access token to an API request to authorize it
Your API service could be running on Heroku, or somewhere else. In your API service code, you have to validate the access token before you decide to accept the request. The API service can go back and talk to the identity provider to determine if the user's access token is still valid.
How the API service validates the token depends on what language you are using to build your API service. But, that's basic idea: the access token is what authorizes the user's requests.
For multiple AngularJS services that makes it's own Web API calls, we need to store the authentication token in a centralized place and it shouldn't be repeated. Where should we save the authentication token? I guess we need to write a authentication AngularJS service that would be responsible for log-in/log-out and it stores the generated token in client local storage so this token can be sent with each request to access secure resources on the back-end API. Kindly answer me if my understanding in correct.
Good Morning !!
We have a scenario where a client app hitting a intermediary service (REST - AAD Configured) , will be inturn routed to another Service Endpoint (REST - AAD Configured). While doing so, we are successful in gettting accesstoken at client layer after hit to intermediary service. Now, Intermediary Service should consume an API of another service which is AAD Configured. For doing so, we have made use of BootstrapContext - for which we have got just token but not security token. We did try by making use of same token to consume, but in vain that wasn't helpful.
Exception while consuming REST Service from Intermediary service is nothing but " AAD Login Page HTML " and status is 200 OK.
Kindly Suggest where we missed a piece and suggest needful.
P.S : I have added Intermediary Service in azure portal to client app to have access for consumption and Intermediary service has access to consume REST Service which needs to be consumed. Also, in all layers we are using latest nu-get package of ADAL.
Regards,
Jagadeesh
It sounds like you secured your API using the wrong authentication mechanism - unauthenticated or improperly authenticated API calls should never result in redirects or HTML pages. Also, the bootstrap token you receive is for the first service. The intermediate service should refuse that token as its audience is incorrect. See https://azure.microsoft.com/en-us/documentation/samples/active-directory-dotnet-webapi-onbehalfof/ for the proper pattern.
I have a web api hosted on Azure having Azure AD authentication configured and running properly (all controllers have the Authorized attribute).
The front-end runs AngularJS and authentication of the http requests is implemented by using the amazing ADAL JS library (adalAuthenticationServiceProvider).
Beside the web api I also have a SignalR hub that I'd like to 'protect'. More specifically I need to call (invoke) a method of the Hub from the AngularJS client code. Basically I need to have the Context.User populated in the Hub method.
Any idea how to also authenticate a SignalR invoke under these circumstances?
you can supply token on query parameter as suggested in https://auth0.com/blog/2014/01/15/auth-with-socket-io/ and then process token on your backend