I'm trying to set custom protection to a file with permission to any authenticated user.
I couldn't find any related info in the MIP SDK documentation.
Any comment/suggestions would be most welcome.
I have the same request from a customer, and I'm checking if the following solution is feasible for them.
You could define a label in management portal, configure the protection for Any Authenticated Users, and then set it with SDKs.
EDIT
I implemented and tested this solution and it works as expected.
Be aware that it will take some time before the label is usable in code, after it is created in the portal. In this time-frame an error is thrown by SDKs.
Related
My company has an internal application where I need to pull/display pictures of all the employees from office 365 with out user intervention.
From what I read online I think I need to call Microsoft graph getphoto API in daemon application to achieve this as per this link (https://developer.microsoft.com/en-us/graph/docs/authorization/app_only).
Will this be a right approach? If yes please point me to any C# sample codes related to this.
Appreciate your responses.
Yes, this is exactly the type of application you will want to build. App-only (machine-to-machine) authentication should be used anytime you don't need a user present to execute functionality.
You can take a look at the ASP.NET Core App Only sample to get a sense of how to register and set up your app to use app-only authentication. The sample goes on to use this access token to set up webhooks, but you can replace this logic with your custom code. You will want to select the scope User.ReadBasic.All to have access to users' profile photos.
I'm trying to find a solution to handle authentication on my new application, and I like the approach of IdentityServer3. I would like to hope my requirements are met by IdentityServer3 and it's just my lack of understanding due to my newness with the technology.
My requirements are as follows, and in order of desired execution:
1) If a user requesting authentication is a local (domain) user, they should be authenticated automatically using Active Directory.
2) If a user requesting authentication is not found in Active Directory, they should be authenticated against our own User table.
3) If a user requesting authentication is in neither Authority, we may choose to grant access via Google or Facebook credentials, but that's not a Phase I requirement.
I currently have a working proof of concept using IdentityServer3 as a standalone security server pulling records from the InMemoryUsers, InMemoryClients and InMemoryScopes, and I'm fairly sure I'll be able to expand on those concepts for pulling from our own database.
This problem comes when I try to use Active Directory as the first checkpoint.
I've looked at a couple of resources in an effort to accomplish the Active Directory, but I'm getting all tripped up as I'm not seeing any concise demo that shows the AD piece of the puzzle.
TJ Robinson has a Gist of an ActiveDirectoryUserService that implements IUserService, and that looks to be the most promising, but because of my n00b status, I can't seem to figure out how to roll it into the scheme.
I would really appreciate any suggestions, and, perhaps, links to examples of how to do AD authentication first with a fallback to local authentication.
Thanks in advance,
Ric
In regard to your first requirement...
I believe you should examine the Windows Authentication Service. This is essentially a mini security-token-service that can work as an external identity provider to IdentityServer to provide Windows Authentication (over the WS-Fed protocol).
If you follow that link to the GitHub page, you will find two links to samples that can you get started with this component. One sample has both Identity Server and the Windows Authentication Service hosted separately and the other sample has them hosted together.
A separate option could be to use ADFS (if you have one) as an external identity provider.
Those samples include a custom user service (ExternalRegistrationUserService) that shows those windows users being mapped to an in-memory collection of users (in Identity Server). Your requirements will obviously demand a different implementation of that user service, but I hope this might help get your started with the Windows Auth part.
When I went through this exercise recently, I found a lot of good information in the closed IdentityServer3 issues (for windows auth). Lots of good info on Stack Overflow as well; good luck!
I am very new to Sitecore.
I am converting a web forms application to a Sitecore application where I make an ADFS call and get the user to login. The application returns a Claims object with the Name and EmailAddress.
However, in case of Sitecore, I read that Sitecore directly implements IIdentity and IPrincipal and hence is not possible to utilize the Claims with Sitecore Identity and User (Principal).
I've tried referring to this article.
And downloaded and installed the ADFS.Authentication package.
I have also made changes to the web.config as mentioned in the article.
As i understand, all I need to do is call the Login method:
AuthenticationManager.Login(userId, false);
However, when I run, I get this error:
AuthenticationHelper has not been set. It must be set in Initialize.
How should I proceed? As I understand, by downloading the ADFS.Authentication package, I do not need to do anything and this should take care of converting the claims too. Is my understanding correct?
Please help me.
Thanks!
I've implemented something similar in the past and to get this working I've setup my own Httpmodule to handle the communication back and forth from the remote systems and I did not implement IPrincipal.
Then when authenticated, I log in the user as a Sitecore virtual user and store any information in an encrypted forms cookie, this keeps things nice and simple and you don't have to worry about anything conflicting with Sitecore.
More info on virtual users here:
http://www.sitecoreinsight.com/lightweight-authentication-using-virtual-users-in-sitecore/
I am trying to test the sample code from office365 API, I could login to my account but after that i would always get this exception
AuthenticationFailedException was caught
AADSTS65005: The client application has requested access to resource 'https://outlook.office365.com'. This request has failed because the client has not specified this resource in its requiredResourceAccess list.
Trace ID: 7a39b0bd-1738-418f-984a-feffae5b5d9b
Correlation ID: 16da7c7f-9f0c-468f-a560-a51b1ac9b3bf
Timestamp: 2014-07-09 07:36:34Z
This is the code that I have been testing this code is generated by the API.
Authenticator authenticator = new Authenticator();
var authInfo = await authenticator.AuthenticateAsync("https://outlook.office365.com");
please help me or point-out what I'm doing wrong, this is my first time developing in office365 please help and thank you.
I just came across your question having run into the same error, so since nobody ever answered I figured I would post the answer I found. This error is related to the permissions set to be requested on the app in the Azure dashboard at https://manage.windowsazure.com.
If you go into your app configuration page and scroll to the bottom, you just need to add the corresponding items under the delegated permissions dropdown.
I got the same error. This is what fixed it for me:
Go to https://manage.windowsazure.com
Go to the corresponding app configuration page.
Scroll to the bottom to "permissions to other applications".
Add "Windows Azure Active Directory" application if it is not already there.
Under delegated permissions check "Enabled Sign-on and read user's profiles"
The consent framework associated with requesting authorization requires that your client application is configured with a static set of permissions to the resources (APIs) that it will call. For example, if your app needs to read the signed in user's mail and read and write to their calendar, you need to select Office 365 Exchange Online as a resource and pick the Read mail and Read and write calendar permissions.
This app configuration can be done in a couple of ways - one way is through your dev environment - like Visual Studio. VS2013 and up have a connector that allows you to register a client app and configure its access to O365 cloud resources. Another way is through the Azure Management Portal (under the AD extension, find your application, click on the configure tab, and configure access through the "permissions to other applications" section.
I recommend that you look through https://msdn.microsoft.com/en-us/office/office365/howto/common-app-authentication-tasks and the following sections which show how register apps through Azure Management Portal and through Visual Studio. Also which sample are you trying here? The sample should contain instructions, including the instructions to set the resource and permission scopes your application needs
I am experimenting with Windows Live SDK for Windows Phone and tried to access SkyDrive with some example code from the internet. Now I am a little confused about the Scopes attribute set in my xaml file:
<Microsoft_Live_Controls:SignInButton Content="SignInButton"
ClientId="00000000XXXXXXX"
Scopes="wl.skydrive_update"
RedirectUri="https://oauth.live.com/desktop"
I could create my first folder after logging in and accepting the policy. From now on I was trying to read the root folder with this call:
GetAsync("me/skydrive/files");
But it permanently leads to an System.NotSupportedException in System.Windows.dll and the event handling code is never reached. I couldn't localize the mistake I made, so I tried to change the Scopes attribute, because different examples use different Scopes.
Now comes the confusing part. Every change I met to the Scopes attribute led to the same policy page. Even if I set it to "wl.basic" I had to accept the access and update of the skydrive policy.
I don't get it. I restarted the IDE and emulator and even rebooted my machine at the end.
Does anyone have an explanation for me?
And if there is someone who can help with the exception from above, please feel free to leave a comment.
The website caches the scopes the first time you connect to windows live.
So no matter how you change your sign-in Scopes afterwards, you always get the same policy page.
To force a new page you could delete the windows live application and create a new one, and us the new Client ID.
Source: http://social.msdn.microsoft.com/Forums/en-US/messengerconnect/thread/37be752f-2ebf-4342-ab4e-0e5506415e61