I had someone reach out to me with a couple of queries about source code encryption in Team Services. I don't know and can't find an answer to online (Google fell flat?).
The question is: Can a company control their own encryption of source code at rest with Team services? Essentially, this would mean controlling their own keys and having the ability to pull access logs for people accessing the source control.
I believe the answer is still no. Microsoft may encrypt, but I don't believe there is a provision for a company to control their own source control security if it goes on the cloud.
The answer is just as what you think: No for now. Microsoft use kinds of ways (Check this link for details: Visual Studio Team Services Data Protection) to protect the customer data, but the way which you are asking isn't supported for now.
You can submit a feature request on VSTS User Voice for this.
Related
I have a question about Microsoft DevOps (formerly Visual Studio Team Services or VSTS). I have multiple applications that are set up as separate projects, but we have basically one team of devs. Some of the older projects are TFS based some are git.
Ideally I would like to create a board based on the team and 'attach' projects to the board. Or something that ends up being roughly the equivalent of this.
I can't seem to find anything close to this. Does anyone have any ideas? Or any suggestions?
Thanks for your help!
As I mentioned in my comment you can use the AzureDevOps Rest API.
Representational State Transfer (REST) APIs are service endpoints that
support sets of HTTP operations (methods), which provide create,
retrieve, update, or delete access to the service's resources
Most REST APIs are accessible through our client
libraries,
which can be used to greatly simplify your client code.
Once you created your own board, you can fill up the details using the REST API response.
I need to develop a chatbot with these properties:
Platform - Skype for Business On-Premise
Function - Replies to user queries by looking in various knowledgebases (Multiple Platforms - Databases, Web APIs, etc.)
Basic textual conversation to begin with and will gradually evolve to send attachments
No calls/videos, just chat
Will be hosted on an external server with organisation VPN
A simple sip will be created for the chatbot which can be pinged by any user. I should be able to get this through to our IT dept.
Limited time for development
Scalability is an essential requirement but the organisation is fairly new to this, so they might be patient and allow me to make mistakes
My research has led me to these possible approaches:
SfB SDK - I have rejected this approach because it requires the client to be running at all times and doesn't seem to be scalable
UCMA with Application Endpoint - Haven't rejected this approach, but seems like I'll not go ahead with this because creation of Application Platforms seems tedious and requires me to make a lot of SfB server related IT requests
UCMA with User Endpoint - Great affinity towards this. I have experimented Tom Morgan's (thoughtstuff.co.uk) stuff and this seems like something I can start off right away
UCWA with Application Endpoint - Rejected this approach, because UCWA (from my research) appears unsuitable for On-premise and the setup also seems time consuming
UCWA with User Endpoint - Haven't rejected this approach, but I'm not sure if the Web API way is really a good approach for On-premise platform
I'd like to ask how am I doing so far, but that seems too vague
What would you suggest is a good way to achieve this?
Also, can someone be patient enough to reply the drawbacks and advantages of each approach for my use case. I'd like to make an informed decision and not reject any approach, just because of a misunderstood overhead
I have been asking around in my organisation and other circles.
And since I am not receiving any quick responses, I'll keep adding what I have learnt.
This way a person in the dev community will have a log of how I went with this.
UCWA is better suited for S4B online (compared to on premise) and is generally used by people who are comfortable with RESTful and have low familiarity with .NET development
UCMA is apparently THE WAY to go and for any on-premise bot requirements, preferably with an application endpoint.
So for our development, we are starting with UCMA user endpoint so that we can deliver a basic start as a version-one
And meanwhile we shall also get in touch with the IT department and Lync administrators for creation of Application Endpoints
Once we have this the same functionality that we had with the user endpoint will be copied over to the Application Endpoint version
Keep watching this space for further updates
Hi I am using CAS for SSO. But problem is that i want reset password,register new user on CAS login screen.Does CAS provide these services or i have to implement?
Or Any other SSO solution exist which fulfill my requirement.
CAS is just a SSO frontend to your existing identity management solution (database, LDAP etc). It does not include any identity management features itself (create user account, reset password etc). I have recently been using the Cloudseal platform which is a full identity management solution and so far I am pretty impressed. I believe Atlassians Crowd also includes this although I have not used it. There are probably other products out there as well.
Both of these are commercial products although they are both free for the first 50 users. Crowd is a traditional standalone platform which you download, install and configure but Cloudseal is a hosted service so there is no installation and less config.
You can certainly modify the spring weblog and login page to allow for the functionality that of course you'd have to implement. You should also ask the question on #cas-user mailing list to see if a similar need in the community has been implemented by other users which you may be able to take advantage of. I remember only recently someone raised the same question to the list and there was a bit of interest in getting this feature developed and integrated. You may want to revisit the topic on the mailing list.
Hope this helps.
I am investigating an open source solution for IdM.
So far, my choices are OpenIDM, OpenAM, Josso & CAS.
But most solutions are focusing on SSO, however my requirements are more on user management and provisioning. Can Josso/CAS/OpenIDM provide user provisioning/deprovisioning, group policy , etc? Any open source alternative to Atlassian Crowd, matching in every functionality?
The open source solutions that you mention focus largely on SSO, not identity management. JOSSO has a user provisioning feature but AFAIK it does not include group policies. If you are looking for a full identity management solution you would need to look at the commercial products like Cloudseal, Crowd, Oracle etc.
I want to keep things as simple as possible and I don't want a complicated security mechanism. Basically I need for a user an ID and an e-mail address and I really don't want to bother about other things. Also, I was a minimum overhead in terms of security (if there is anoter provider who can do it for me, that's even better).
What is the simplest way to do this? I was thinking about incorporating LiveID or OpenID by I don't know what are the advantages/disadvantages.
I am working with the Azure SDK.
If you use the Windows Azure Access Control Service, you can basically outsource all identity management. Take a look at the Windows Azure Platform Training Kit - there's a lab called "Introduction to the AppFabric Access Control Service 2.0" that will get you up and running quickly. Currently, you can choose any combination of the following identity providers:
WS-Federation
Facebook
Windows Live ID
Google
Yahoo!
"Simple" for whom?
The simplest strategy for you would probably be to use ASP.NET's standard SQL-based authentication provider. You just run a script against your database to set up all the tables, and then you use ASP.NET's built-in utility methods to authenticate. Give your user-specific tables a foreign key reference to that user's ID, and you're good to go. We've done this, and never had any trouble with it. It's a tried and well-used system, so you know you won't be introducing any security invulnerabilities by hacking your own solution together. (see SqlMembershipProvider vs a custom solutions)
If you want something simple for the user, then an OpenId solution would be my pick. Set up something like StackOverflow has, where you can let users choose an account from a number of trusted providers to allow them to log in. From the user's perspective, it's really nice not to have to remember one more username and password for one more site.