SID 2014 - Dipendenza da Internet - StefanPe - PUBLIC.pdf

Salve a tutti!

Condivido la presentazione che ho preparato qualche giorno fa per parlare della sicurezza in Internet ai bambini di alcune IV e V elementari; si tratta di incontri organizzati nell'ambito delle iniziative per il Safer Internet Day, a cui Microsoft partecipa da anni. 

Potete scaricarla in formato PDF (parte 1 e parte 2), oppure sfogliarla direttamente via web (attenzione: per vedere bene le animazioni e visualizzare le slide "nascoste", è necessario aprirla in PowerPoint; è possibile farlo da quest'ultimo collegamento). E' ora disponibile anche un'appendice sull'uso di Facebook, pubblicata in formato PDF e PowerPoint.

Due anni fa, avevo preparato una simpatica presentazione (per quanto un po' troppo lunga e dettagliata...) nella quale spiegavo i concetti di base della sicurezza in Internet; ricordo che, a suo tempo (...di fatto, in un passato così recente…), quando chiedevo alle classi <<chi *conosce* Facebook?>> si alzavano pochissime mani.

Oggi mi sembra impensabile riproporre la stessa presentazione di due anni fa: a parità di età, quando domando alle classi <<chi *è su* Facebook?>>, si alzano le mani di moltissimi bambini (parliamo di bambini di 9-10 anni, sebbene Facebook - così come molti altri social network - richieda di avere almeno 13 anni per effettuare l'iscrizione… Del resto, loro sanno benissimo come "ingannarlo"...).

Per quanto appena detto, quest'anno ho pensato di organizzare la presentazione dando per scontato che i bambini conoscano (o intuiscano) molti concetti di base ed immaginando delle situazioni impreviste o difficili da sottoporre alla loro attenzione, per poi ragionare insieme su come possono o devono comportarsi.

Dopo i primi riscontri, devo ammettere che la consapevolezza dei bambini sui pericoli di Internet mi sembra molto migliorata rispetto a due anni fa; ascoltando le loro risposte , mi è venuto più volte il dubbio di aver immaginato per loro delle situazioni fin troppo banali (...per altro, ogni suggerimento per migliorare il contenuto della presentazione è ben gradito!). È pur vero, comunque, che un buon "ripasso" può risultare sempre utile; inoltre, leggendo i giornali (...vi rimando a queste evidenze...), sembra che non tutti gli adolescenti sappiano riconoscere ed evitare i pericoli.

Mi auguro che questo materiale possa essere di aiuto.

Per approfondimenti, vi riporto i collegamenti al sito delle iniziative per il Safer Internet Day ed al sito in cui è descritto l'impegno di Microsoft per un'utilizzo più sicuro e responsabile della rete da parte degli adolescenti.

Condivido i risultati di una ricerca che ho recentemente effettuato tra le notizie pubblicate in Italia nel corso degli ultimi anni, riguardanti il tema della "sicurezza su Internet per gli adolescenti".

Ho effettettuato questo lavoro per prepararmi ad affrontare al meglio i nuovi incontri con adolescenti, genitori ed insegnati, organizzati presso alcune scuole elementari e medie nell'ambito delle iniziative per il Safer Internet Day a cui Microsoft aderisce da anni. Per quanto credo sia giusto rappresentare i pericoli indipendentemente dal numero di casi reali che si sono verificati, mi pare sia comunque utile avere l'evidenza di quanto certe situazioni e certi comportamenti siano comuni.

La ricerca mi ha permesso di redigere una piccola rassegna stampa che - pur nella sua dichiarata ed evidente incompletezza - offre diversi spunti di riflessione ed approfondimento per genitori ed educatori interessati a comprendere le "ultime dinamiche" dei rapporti sociali tra gli adolescenti, che vedono Internet come strumento di comunicazione e palcoscenico. Certo, la mia ricerca è stata fatta con lo scopo di mettere alla luce solo i pericoli e le degenerazioni; lascio al lettore la riflessione su quanto ci sia di positivo nella Social Media Revolution :-).

I risultati di questa ricerca sono disponibili in formato PDF come allegato a questo post ed in formato PowerPoint, visualizzabile via web o scaricabile a questo link.

Segnalo, infine, che aggiornerò la presentazione quando avrò evidenza di nuovi contenuti interessanti da inserire... tempo a disposizione permettendo... (ultimo aggiornamento: 10/5/2012).

Stefano

SID 2012 - Genitori - Evidenze - StefanPe.pdf

Condivido un mio recente lavoro sul tema dell'Open Data.

Si tratta di un documento alquanto corposo (ca. 150 pag.) che contiene una descrizione abbastanza approfondita dei seguenti argomenti:

• concetti, motivazioni, benefici e problematiche dell'Open Data, con particolare riferimento allo scenario italiano;
• motivazioni per l'utilizzo di tecnologie cloud nelle soluzioni Open Data;
• aspetti funzionali, architetturali ed economici della soluzione cloud di Microsoft con modello di servizio di tipo Platform as a Service [PaaS] denominata "Windows Azure";
• aspetti funzionali ed architetturali della soluzione di Open Data denominata "Open Government Data Initiative" [OGDI], basata su Windows Azure e distribuita con modello open source;
• guida passo-passo per la predisposizione di un ambiente demo basato su OGDI e prova di importazione di alcuni dataset della Regione Piemonte (modifiche del codice, configurazioni su Azure, predisposizione dei dati, caricamento e test di accesso)

Il documento è stato redatto tra ottobre e dicembre 2011, nel contesto dello stage di fine corso per il Master in "Interoperabilità per la Pubblica Amministrazione e le Imprese" organizzato dall'Università "La Sapienza" di Roma nell'A.A. 2010-2011. La versione già consegnata all'Università è visualizzabile e scaricabile dal seguente link: "Open Data in Italia: opportunità e soluzioni con le tecnologie cloud di Microsoft" ed è resa disponibile con licenza CC-BY-3.0.

Una brevissima presentazione di tipo "executive summary" (10-15 minuti) sull'Open Data - tratta dai contenuti del suddetto documento - è scaricabile da questo link: presentazione ed è offerta con lo stesso tipo di licenza.

Mi auguro che questo materiale possa essere di aiuto per chi ha l'esigenza di approfondire il tema dei dati aperti e/o per chi desidera comprendere come sperimentare i servizi cloud di Windows Azure e la soluzione OGDI.

More in details, I have setup up a lab with the following protocols and standards:

• WS-Federation (Passive Requestor Profile)
• SAML 2.0 Protocols, Bindings and Profiles
• OpenID 2.0
• OAuth 2.0

Specifically, I have set up a demo environment where the authentication for accessing a single SharePoint Server 2010 web site or a single custom ASP.NET web site can be performed by specifying user credetials available on a wide set of different identity providers:

• Active Directory (directly from SharePoint or through AD FS)
• Shibboleth (allowing the authentication against an LDAP of type AD LDS)
• Windows Live ID, Google Accounts and Facebook (through Windows Azure ACS and AD FS)

This is a logical view of the demo environment:

If you are interested, please look at the following material:

• the demo objectives and evidences on this PowerPoint presentation (web-browsable on SkyDrive);
• the lab environment installation log on this OneNote notebook (web-browsable on SkyDrive).

I hope that you will find this information useful.

 Stefano

In my previous post “Rapid “Data Collection” Solutions – Part 2: designing and implementing a data model” I have considered the problem of “preparing the storage” for the data that need to be collected; in that post I have also described the possibility to implement some kind of “data-completion workflows”, helpful especially when it is desired to automate the filling of “redundant columns”. In the sequent post “Rapid “Data Collection” Solutions – Part 3: designing and implementing the business process” I have considered some aspects of the “business process workflows” (or “human workflows”) implementation.

In this post I will describe the most important concerns that must be addressed when planning and implementing the security model for such a kind of data collection solution.

I will not explain the SharePoint security model: I assume that this is already well known to the reader; if it is not, I suggest starting with the reading of these articles: “Plan site permissions (SharePoint Foundation 2010)” “Plan site permissions (SharePoint Server 2010)” (both articles are about SharePoint 2010 but the same concepts are valid for WSS 3.0 and MOSS 2007). I summarize what is written in these articles with the following sentence (that also gives me the opportunity to set the “security vocabulary” used in the rest of this post):

In SharePoint, the authorization mechanism consists in assigning, on a securable object (web, list, item or folder), one or more permissions levels (set of base permissions) to a security principal (user or group); the assignment can be explicit or inherited from the permissions set on the above securable objects in the site collection hierarchy.

Another important rule that need to be considered here is the following one:

A declarative workflow designed and deployed through SharePoint Designer is always executed in the security context of the user that started the workflow.

Now, it is time to summarize what are the elements that compose the data collection solution described in this and in my previous posts. When considering the involved “securable objects”, it is important to notice that the entire solution is confined into a single SharePoint web; in detail, we have considered the following securable objects:

·         The “main list” containing the result of the data collection initiative; it is worth to highlight that this is the list where the optional “data-completion workflows” and the “business process workflows” are associated.

·         A set of “related lookup lists”, allowing the representation of an optional data model around the collected data

·         A “Tasks list”, containing the tasks assigned to the users involved by the “business process workflow”; with SPD 2007, all the workflows deployed in a web must use the same tasks list; with SPD 2010 you have the option to assign a specific list to each workflow.

·         A hidden “History list” containing the messages logged by the implemented workflows (the messages shown on the workflow’s status page); with SPD 2007, all the workflows deployed in a web must use the same history list; with SPD 2010 you have the option to assign a specific list to each workflow.

·         Optionally a “custom history list”, containing the evolution of the important values in the items subjected to the “business process workflows”.

·         A set of “custom forms” – stored into an hidden document library – automatically created (as “.xsn” files in SharePoint 2010 and as “.aspx” files in SharePoint 2007) during the deployment of the “business process workflow” (why do I explicitly mention these forms? I will explain shortly why they must be considered when planning and implementing the security model…)

What about the “roles” that we have considered in this series of posts? They were not explicitly mentioned until now; it is time to define them. Trying to be generic, it is possible to say that:

·         there are individuals that must be able to prepare and manage the data stored into the “model” designed around the data to be collected;

·         there are individuals that must be involved into the data collection process as contributors only for the part of data that they own;

·         there are individuals that need a read-only access to the collected data.

Certainly, in this way I have not described all the possible situations in details: there are scenarios, for example, where a certain group of individuals must be able to manage only a specific set of the data model designed around the data to be collected. A more detailed description of all the possible security requirements is not practically possible in this post; now I need to consider a more generic and simplified vision, in order to define at least a “base solution” for the security model.

Trying to map these “base security needs” with the SharePoint security model principles and with the declarative workflow security rule mentioned above, we can design the solution described into the following table in terms of permission levels that must be assigned to the involved security principals on the involved securable objects:

In the previous table I have not explicitly considered the standard hidden “history list” where the workflows log their messages, because the permission assignments on this list are managed directly by SharePoint.

The “Read” permission level assignment to the “custom task forms” is done automatically during the workflow deployment; there are situations where you may need to update these assignments by adding new security principals; for more information on this subject I suggest reading this post: “Dynamic tasks assignment and access denied errors in declarative workflows [SPD 2007 only]”.

It is important to notice that the described solution for the security model allows to implement a “separation of contexts”: the users involved by the business process workflow as contributors in the data collection process require the “contribute” permission level on the “tasks list” but do not need the “contribute” permission level on the “main list”, neither when the information provided by these users are copied back in this list (accordingly to the approach that I have described in “Rapid “Data Collection” Solutions – Part 3: designing and implementing the business process”). This is true because this copy is done by the workflow, which is always executed in the security context of the user that started it (the completion of a task by an assignee does not change this security context!).

For the same reason, it is important to notice that the users allowed to start the “business process workflow” require the contribute permission into the (optional) “custom history list” and into the “tasks list”.

The “business process workflow” is normally configured to be started automatically by the creation of a new item in the “main list”; for this reason, in the previous table, I have depicted the “Contribute” permission level as the only permission assignment required on the “main list” for the users allowed to start this workflow. If the startup of this workflow must instead be done as a manual operation, it is possible to require the possession of the “Manage list” base permissions (which is not part of the standard “Contribute” permission level). This option allows to further implement a “separation of contexts”: the contributors of the main list prepare the items where specific enabled users can start the “business process workflow”.

Please note that, in this post, I will not consider the following SharePoint functionalities related to the list content security management:

·         the list item “approval mechanism”;

·         the “item-level security” (I am referring to the options available in the advanced list settings);

In the rest of this post I will consider some specific but quite common security needs:

·         How to avoid the deletion of the items, especially from the “main list” and/or from the “custom history list”?

·         How to protect the value of specific fields for the items in the “main list”?

·         How to protect the “tasks” created by the workflow, in order to allow only their assignee to update and complete them?

Avoiding the deletion of items

A common need consists in avoiding the deletion of the items, especially from the “main list” and/or from the “custom history list”. This requirement can be easily enforced by simply replacing the base “Contribute” permission level with a custom permission level, created as copy of the “Contribute” permission level but deprived of the “Delete items” and “Delete versions” base permissions. This approach, associated with the enablement of the standard versioning mechanism on both lists, allows the complete control over the modifications that happen on both these lists. If you need to have this control while maintaining the right – for your users – to delete the items, you have to set up the SharePoint auditing mechanism.

Protecting specific fields

Another common need consists in “protecting” specific fields, especially in the “main list”; for example, you may not want the contributors on the “main list” to be allowed to change the content of specific list item fields whose value should be automatically managed by the workflow; these fields may contain:

·         the status of the item, according to the process implemented by the business process workflow;

·         the information provided by the involved users in their completed tasks and copied back on the current list item by the same business process workflow.  

We need to point out that this requirement cannot be completely satisfied, because the SharePoint security model does not allow the protection of the fields (the fields are not securable objects). In spite of this limitation, you can implement a strategy allowing a “good protection” of the “sensitive fields”. This strategy may be realized by imposing the following settings on the “main list”:

·         hide these fields from the new/edit item forms (in order to do this, you have to temporarily enable the content types association on the advanced settings of the list; the hide option is then available on the specific content type fields settings);

·         hide these fields from the views associated to the list;

·         add a “shadow field” for each of the fields previously hidden; this shadow field is simply a field of type “calculated value”, showing the content of its related field (for example, an “Item Status – View Only” shadow field should be created with the following formula for its value: “=[Item Status]”, where “Item Status” is the name of the protected sensitive field)

·         add these shadow fields to the views associated to the list;

·         enable the versioning on the list, in order to have a log of the modifications occurred to each item;

·         replace the base “Contribute” permission level – associated to the users allowed to start the business process workflow – with a custom permission level, created as copy of the “Contribute” permission level but deprived of the “Delete items”, “Delete versions” and “Manage Personal Views” base permissions.

When the above settings are enforced, the users will not be able to modify the content of the protected fields by using the standard SharePoint web pages (the list views pages, the list view web parts and the list item forms).

I am suggesting the use of the “shadow fields” because, when you only hide the protected fields in the new/edit list item forms, the users are still enabled to edit their values in any list view showing them; in order to do so, they can simply switch the view in “Datasheet mode” (if the view is not already a “Datasheet View”). By adding the “shadow fields” to the configured list views (instead of directly the protected fields), your users will still be able to see the value of the protected fields but they will not be able to update them.

Please note that this solution requires that your contributors on the “main list” will not be enabled to create personal views (they must be deprived of the “Manage Personal Views” base permissions); otherwise they could create a personal view including the protected fields, making them available for modifications.

It is important to point out that, with the proposed solution, the contributors of the “main list” are still able to modify the value of these protected fields when they access them outside the standard SharePoint web pages. For example, they can modify these fields by editing the list with Access 2007/2010 (using the linked table feature of SharePoint/Access). Fortunately, in the described configuration, the versioning mechanism (to be enabled on the “main list”) and the missing “Delete items” and “Delete versions” base permission assignment allow to find such undesired “behaviors” of your users; in this situations, a proper “communication strategy” addressed to your users is the only way to fill the final gap towards a complete protection of the sensitive fields…

Protecting the tasks items

A third common need consists in protecting the single task items by allowing them to be seen/modified only by their assignees. By default, the items created in the “Tasks list” inherits the security settings of the list; for this reason, all the contributors on this list are allowed to edit /complete/ delete any existing task, no matter to whom the specific task is assigned to.

Unfortunately, it is not possible to obtain this restriction without coding. If the task level security is a requirement, a valuable option could consists in creating, with Visual Studio, a custom action allowing the creation of a task with the “Contribute” permission level automatically granted to its specific assignee (user or group) and, optionally, with the “Read” permission level granted to other users or groups specified somehow.

Please note that the use of the simple “Set Permissions on Item” custom activity available in the “Useful Sharepoint Designer Custom Workflow Activities” (from CodePlex) is not valid: you cannot create a task using the standard “tasks activities” and then set the permissions on the task with that specific custom activity because each of the “tasks activities” cause the stop of the workflow just after the task creation, until the task is completed.

An intermediate and limited solution – allowing a partial protection but not requiring the development and deployment of custom code – consists in limiting, on the “Tasks” list, the use of the “My Tasks” view to all the possible tasks assignees. This can be easily done by deleting the other views and by removing the “Manage Personal Views” base permissions from the permission level assigned to this set of users on this list. This approach has two important leaks:

·         firstly, the users can still access and modify the other list items not shown in the prepared views (the tasks not assigned to them) just by accessing them with one of the many tools that allow this functionality outside the SharePoint web pages. For example, they can modify these tasks by editing the list with Access 2007/2010 (using the linked table feature of SharePoint/Access);

·         secondly, the views can only filter the tasks directly assigned to the current user (the standard “My Tasks” view, for example, uses the filter “”Assigned To” “is equal to” “[Me]”); these views cannot filter the tasks assigned to a group (SharePoint group or Active Directory group or generic identity provider role) to whom the current user belongs.

It is worth to notice that the standard “Approval” workflow template available in MOSS 2007 and SharePoint Server 2010 (but not in WSS 3.0/SharePoint Foundation) enforces the protection of the tasks (if a non-assignee tries to update a task, the operation is aborted with the generic error message “Task update was not accepted”). This behavior is not obtained with a standard permission level grant but with other custom mechanisms. The same behavior is not present in other standard workflow templates; for example, it is not present in the (similar) “Collect Feedback” workflow template available in MOSS 2007/SP 2010.

In my previous post “Rapid “Data Collection” Solutions – Part 2: designing and implementing a data model” I have considered the problem of “preparing the storage” for the data that need to be collected; in that post I have also described the possibility to implement some kind of “data-completion workflows”, helpful especially when it is desired to automate the filling of “redundant columns”.

In this post I will consider the problem of contacting the users that need to provide that data. Sometimes it’s enough to send them an email with the link to the SharePoint list where they are invited to write their data. Other times a more complicated business process need to be implemented: it may happen, for example, that the users to be involved must be chosen with some kind of specific logic; other times, the problem of completing the set of information in a certain “row” can be subjected to a custom review process, where the reviewers can decide to recollect part or all that information from the same authors or from other users.

The tool allowing the creation of zero-code workflow solutions for a SharePoint environment is the “Workflow Designer” (or “Workflow Editor”) in SharePoint Designer [SPD]; this tool – which was already available in SPD 2007 – has been greatly enriched in terms of functionalities and usability in SPD 2010.

While it seems often trivial to write and deploy simple workflows in SPD 2010, the implementation of medium or complex business processes may introduce the need to face tricky challenges; in my previous post “Common Challenges with SharePoint and SharePoint Designer Workflows” I have listed the most important problems and thought that I have encountered – and, somehow, solved… or, sometime, avoided – in my real-world workflow experiences. It may be necessary to consider all of these challenges when implementing a business process for a data collection solution.

One of the mentioned thoughts is especially important in the scenario of a data collection business process; I am referring to the consideration about where to store the collected data; here below I will describe the available options.

The workflows functioning mechanism in SharePoint uses the “Tasks” lists in order to:

1.       wait for any kind of human intervention;

2.       offer, to the involved users, a web user interface (the task form) where they can provide their contribution (data);

3.       automatically resume the execution when the expected contribution is arrived (that is, when the task is completed).

In a specific SharePoint web, a single “Tasks” list can contain the tasks (items) created by different workflow instances of different workflow types running on one or more lists or libraries.

The figure here below gives a visual representation on how the tasks are related to the workflow instances with multiple lists and multiple workflow types.