How do I authenticate to a Custom Web Api from a SharePoint 2013/2016 single page app? I've seen a couple examples of using session which i really don't want to use, I'm thinking maybe a custom security token service or would it be better to add the web api as a provider hosted app (high trust) since this is on premises?
I found a solution finally, this one actually makes sense: http://blog.baslijten.com/getting-sharepoint-2013-apps-and-webapi-to-work/
Related
Everything I searched for returns info about internal user SSO, not client facing websites.
I need an SSO implimentation that works with sitecore's asp.net membership api or has it's own sitecore security provider to enable users who log in to publicfacingwebsite1.com to be able to be logged in to publicfacingwebsite2.com and logging out of one will log out of the other. I would prefer sitecore's asp.net membership provider as that will probably have the least upgrade implications in the future.
The domains are different top level domains. The websites are separate sites on the same sitecore instance.
I also need the side ability to impersonate a user (log in as the user) from an admin user, but once I have the main implementation, I'm sure I can find a method for the impersonation.
Regards
I would use a third party framework for the SSO part. For instance IdentityServer3
Here is a good introduction on how to use it together with Sitecore
In regards to the membership provider and the profile data, if you are thinking upgradeability, I am not sure it will be so, if you use the native membership provider. Sitecore will most likely switch to ASP.Net Identity in the near future. The ASP.NET Identity is supported in IdentityServer3, so you might obtain a shared user profile by using IdentityServer for the profile as well. But this is all guessing the future.
If you want to use the membership provider and the standard Sitecore profile provider, I am sure you can customize the implicit flow to map the Identity to a Sitecore user.
I am looking for a way to automatically add users to WSO2 API Manager. I have a basic install with the H2 database, but someday I might move to postgres or something like that. What is the best way to add users from say a script?
In Carbon products (APIM, IS), All user store operations can be exposed via web services. External application can use these web services to add/delete/update/get in to user store users and groups. Please note, H2 is not recommended for products`
REST web service according to the SCIM provisioning specification.
SOAP based Web service. You can find more detail from here
I need to create register/login functionality in CQ5. There are three ways
1 - The register/login functionality should be prepared as web service hosted on a Java Application Server and then we can consume data from web services.
2 - The functionality should be prepared as web service based on RESTFull that hosted on CQ itself since AEM is developed around the REST principal and REST web services is certainly one which will be supported. So I believe RESTfull web services can be hosted with CQ5.
3 - Why do we need web services? I do not think it requires web services since my application is not going to communicate with other application and it dont want to expose any services to outside world. Why don't we create register/login functionality as we do in normal web application. Can we create a OSGI bundle that invoke databases to store user details for register/login functionality?
I would go for 3rd option but my concern is AEM is not the place to build our business logic to carry out functions that are not related to content rendering.
which option would you choose and why? Kindly share your ideas and thoughts. I am just looking for best solution to develop register/login functionality in CQ.
Thanks
I think i am late to the party but it might help someone. Yes, you can very well create rest webservices in CQ and they work well. So, you can take that approach.
The way to go about implementing login/registration would be how it is done OOTB but OOTB is also bad in the way it implements it so you have to make modifications to overcome that.
1) You need to register and Authentication handler with CQ. If you are looking for a sample there is a form authentication handler source that you can look at.
2) We have integrated out Auth handler with Active Directory (AD). Since AD is supported by default, so it is easy to integrate with Auth Handlers.
3) Next you need to create a user login token for which you can look into TokenUtil class of CQ or if you are looking to develop SSO, you can look into SSO code that is packaged OOTB.
I have some questions about the use of Liferay and Lyferay web services.
I have read the documentation liferay in particular the chapter 11 and 12 (development/Documentation)about the development (or use) of web services in Liferay ... but this documentation does not seem complete than what you can do (Searching on the web you can find different approaches regarding the use of Liferay).
So, here are my questions / concerns ...
Suppose you develop your portlets in Liferay .. This way I can interact with the 'core' of Liferay and also write the front-end of my webapp that will be on Liferay. For example I can authenticate the user in my webapp using the Liferay API.
If I wanted to have an authentication system to access in my web app through my mobile app?
I'm not crazy .. I also would like to have my own mobile app developed with native code. In this case I would expect to have a REST service to interact with Liferay.
I think that, in this case, I have to expose all of the functionality of my web app (portlet) also as web serivices
For example ... we can reason with regard to the user authentication..
I thought that you can:
1. Use the webservice native Liferay to access from the outside.
2. E'possibile to write my own web service.
In this case, I'll have to write a portlet that is actually a webservice?
When it might be convenient to implement a CAS?
As Liferay works as regards the user session (for authenticated users)?
In this case we will provide somehow username and password.
If successful, I will have a token or session ID?
Here I can read:
To call the AXIS web service using credentials, you would use the
following URL syntax:
http://" + userIdAsString + ":" + password + "#[server.com]:[port]/api/secure/axis/" + serviceName
I did not really understand if this should be done only to authorize the untente during login
I probably I am confused but the official documentation for Liferay is not my friend right now: (
Yes you want to use custom portlet services in your native mobile app...
I have written very simple blog for doing exactly this:
Please follow the below link:
http://integrating-java.blogspot.in/2014/04/liferay-mobile-sdk-custom-services-part_4.html
By this you can use your portlet's custom service in your mobile native application.
And best part is you do not have to go through the authentication process if you use Liferay mobile sdk for this thing direct service call is enough.
I am creating a service that will include a website, a mobile app, and a web service.
Both the website and mobile app will talk to the web service to interact with the database and any other backend items.
I would like users to be able to log in with other services (such as google, facebook, twitter, etc.)
I have two questions in implementing this:
1.) Should I use OpenID or OAuth? I'm not sure which is better for the situation. I have no need to actually access features from a users account, I just want them to be able to log in with accounts they already have,
2.) Where should I implement the authentication? Do I have to implement it both on the website and on the mobile app, or could I have both talk to the web service and do the authentication there?
Thanks
If you are just doing authentication and not syncing any account details, I think OpenID is the way to go. From a security standpoint, I would say to implement your authentication on the website and on the app and not in the webservice. You want to handle credentials the least amount possible and especially avoid sending the credentials via webservice if not using SSL.