FIWARE Wednesday Webinars – How to Secure FIWARE Architectures

January 7, 2020 posted by

Good morning everybody. My name is Jason
Fox, I’m the Senior Technical Evangelist the FIWARE Foundation and the subject of
this week’s regular Wednesday webinar is securing FIWARE architectures.
This is a introductory course on the basic introduction to the security
elements which are found within the FIWARE catalogue and we will cover the basic
areas of authentication, authorization and so on. The learning goals for this
session are as follows – you will learn what are “identity management” and “access
control”, and why you need to use them, and which FIWARE components are available to
cover this sort of thing. As is frequently emphasized FIWARE is a
pick-and-mix bag of components, the only one that you
really need is core context management which is the context broker, so if you have
alternative security components then that is also fine but this webinar will cover the security components which are the
generic enablers within the FIWARE catalog itself. Then we will describe what
“authentication” and “authorization” are and how they differ. Depending on your
application, you may want to have a system which is purely based on
authentication, on the other hand you may have more complex security needs, in which case
authorization will come in. The usual standard for this sort of thing on the internet is, OAuth2 and we will describe various OAuth2 flows and
how they are supported. Thereafter getting into the various roles of the various
different enablers: we will briefly go into “What is a PEP proxy?” and “What
is a Policy Decision Point or PDP?” and covering such other acronyms as RBAC,
PPAC, xacml. This will become clearer as the the session goes on, so I won’t
describe what they actually are right now. So let’s get on with the
show. As usual the learning materials behind this session
are all available online under the step-by-step tutorials repository and
you can go there and download all the materials and run through the examples
yourself to see it working in action, so you don’t just have to watch and you can
actually be doing things interactively. The usual prerequisites are
showing on screen. The system is set up using Docker and docker-compose.
you’ll need Git to get hold of the initial stuff and if you’re working on
Windows, because there are a couple of bash scripts involved, you’ll need to run them using Cygwin. There is a mixture of stuff which is done either
programmatically or through direct API calls ( or also through in this case a GUI – which is available for the identity management section) but if we
are sending stuff using HTTP API calls Postman is the preferred tool. Just a recap,
today we’re doing the section in red on the right, which is where the
security enablers tend to congregate. The idea here with the FIWARE
catalog is you’ve got the the five basic chapters and we’ve already covered core
context which is what FIWARE is all about and how to get some information into
your system , which is the IoT robotics and third-party systems, however there is
a kind of multi layer chapter which is the Data API management, publication
and monetization section which covers both how to SELL your data – how to move the
context to make money out of it but also how to SECURE your data because
obviously security is valid across every single layer from processing
down to the actual devices themselves. This is where there is a slight
difference between the two – obviously when you’re selling data, you want to be
open therefore that tends to be green but obviously if you’re securing it, you
want to be able to stop people – so that tends to be in red so that kind of
explains what the difference between this system actually is. Let’s bring up an identity
management tool called Keyrock. Keyrock is an identity manager which holds
things like roles and permissions and what have you within in a
database. As you can see it’s a FIWARE generic enabler
which depends on a MySQL database. In this particular case we are
running the system NOT in secure mode – this is simply to make the tutorial simpler and
is certainly not something you want to do a real live system. So I will be
sending stuff using HTTP rather than HTTPS but obviously you can secure it you can have
an HTTPS port. Within this system there is a default user. Now,
you can see here that the default user is being set up with the username “admin”
and password “1234” – this again is an insecure way of doing things,
though the ideal way to do this is actually to pass all this information
user using Docker secrets rather than doing it in a open plain text fashion but this is, as I
said, just tutorial material – we’re just making making life easy but be aware that you need to
think about how security actually works even in a simple system such as this. So
having got Keyrock up and running, there is a simple a login screen
where you can log in as somebody. If I attempt to log in as someone who
doesn’t exist yet in the system it will say no. if however I go for “admin” and
sign in it will say – you have got an ability to
various different different things. Obviously if you’re using this in a real
system you would delete this initial “admin” super user as soon as you’ve got
real admin users. The basic idea of Keyrock and identity management in general,
covers the entities which are shown on the side of the screen. The idea is that
your central element here is the “application” – which is a
securable FIWARE application consisting of a series of
micro-services. You can infer from this that the system is implicitly multi-tenant. You
can have multiple applications secured using your Keyrock IDM. Now an application offers a
series of roles and permissions – typically you would have a “role”, which
would be the things you’re allowed to do and then “permissions “are a bucket which holds the
actual elements which are being checked. So within each application you will
generally have either “users” which are just individuals who can do things
directly or organizations which are groups of users and in order to reduce
the organisation of the administration burden there is also a relationship
organization role which would mean that you can offer a administration role to
another user who could then just set up people into that particular organization.
So if you say, for example have a management organization, then they would
be able to do a series of things and as people join or leave the management organization
you can do move people around without always annoying the super user. As I
said you don’t necessarily have to use role-based-access-control.
That is know as RBAC, you could just have users and you just need to use authentication. However if you are using
role-based-access-control you need this concept of “roll” and “permission”. Now the because
we’re talking about micro-services here, it’s not purely humans who are actually
interacting with this system – there are other actors
and the two supporting other actors within the Keyrock system are a PEP proxy
which is policy execution point and an IoT agent. IoT agent is how to ensure
that your device’s your sensors or what-have-you are able to access a
context broker which has been secured. … and your PEP proxy, which is what we’ll
see later, is a generic middleware for having a gatekeeper between an insecure outside
the secured system itself. Keyrock as I said, offers both a GUI based and API
based interactions for administration. It allows admins to associate users to
roles and what-have-you and it also offers a simple policy decision
point – PDP. A policy decision point is basically a thumbs-up/thumbs-down on access.
Either “permit” or “deny”. Are you able to do this the action requested? As you can see on the
right – you’ve already seen the basic GUI which can be reskinned as necessary –
you can also send REST requests as shown by the curl statement on the right. For
those of you who are following closely here notice this is a insecure post request
because it’s sending as HTTP not HTTPS so this is something you would not
generally do outside of the tutorial as in this case you would be sending your
username and password in plain text which is totally insecure – but as I said
the reason for doing this for the tutorial is that I won’t need to
bother with getting a certificate or getting through various warnings say
your certificate is self signed or what have you. if you’re going to secure something, do
this properly. Now that’s the last time I’ll cover this particular warning. So let’s log in. Once again we’ve got the
system running on my localhost I’ve got Keyrock setup as localhost:3005 When you log in, you obviously need to send your username and
password in the body of the POST request which is a standard way you would do
it. Again the API is doing the same thing as a user would be doing it with the GUI. As you
send this request… when it has returned it gives some information… It says okay I’m
currently running with basic authorization and i’ve not got authzforce PDP attached which is
one of the FIWARE components which will come in be described later on in the hour actually running
within this system. If you look at the headers you see there’s an X-subject
token header – this is describing “Who am I?” and therefore whether I am permitted to get additional
information back. Now I’m not sure this one is been set up or not – I might l need that newly generated
token itself – but if I try and retrieve the information about the user itself by
sending in the X-Subject token itself which is a long string of a UUID which is placed in there – done.
Now is this going to run or not? No that token has not been set up yet, so let’s
change the request. If I put in a valid token and subject
you can then see that I can actually retrieve back information about myself. I
can also do the usual CRUD actions like create users, modify users,
delete users etc. And as you’d expect from a REST API when you are modifying
stuff it would be a PATCH request and when you’re removing organization It is a DELETE and
so on. Most people probably wouldn’t use the
API directly. For user administration, they’re much more likely to want to go in through the GUI because
it’s a lot easier and simpler. Once again I
can go into the GUI and I can create an application, I can add in information
about me or or whatever and various other bits of information which will
prove useful later on. If you’re interested in the the API, as
you’d expect there’s a swagger specification to this but it’s again
simple CRUD based on the expected verbs. So let’s assume that you’ve got some
users into the system based on that admin user’s authorization we’ve got beforehand. We’re
going to need our users to be able to log in so I’m going to have to start up my system
with a slightly more advanced version of this way where we’ve got preloaded users and multiple components running. So instead of having an empty database with nothing in it we’re going to set
it up which is in a system which has got various users and various people in the
system already. I’ll just go back to that previous slide where it was saying what
the various people in the system actually are. So you’ve got an
application running now – if I go back to my system here – we will now
have a tutorial application available which is running on localhost:3000. Once again we are
failing to use HTTPS. Now what we have here is
that we have various different OAuth2 methods we can use with Keyrock as a way to log in.
These are all standard OAuth 2 flows – OAuth 2 being a industry standard for
getting hold of authentication and we can state that within our system, as far as
the user is concerned, we need to log in on localhost and but within docker you
have an actual IP address or you’d generally have a single full URL on
the web (rather than two separate elements here) Now we have here a client ID and a
secret these are defined within the Keyrock application itself when you create the “application” to say okay this defines the tutorial application to secure and obviously my tutorial “application” itself will have “users”, roles”, “permissions” and so on and so forth. So we
can eventually log in to tutorial application via Keyrock as necessary…. So at the moment the tutorial
application is just periodically being pinged on a health check endpoint –
let’s see what it actually shows. Just to make sure I’ve
logged out of the previous example because I’ve set this system up with exceedingly long life
tokens because it makes life easier for explaining and demonstrating this. Sometimes the browser doesn’t clean out the tokens properly. So if I have a user, I can log-in
using several different methods – we’ve got authcode, client credentials,
implicit grant and user credentials and we’ll just show what that means in the slide here. Firstly a user credentials grant –
this is the typical log-in which was shown at the top of the hour. It is basically the standard
username/password combination – a user wants to logs-in to an application via a client. The
client holds the log-in information and it’s completely trusted. So you just
fill out your username and password and Keyrock will return a response saying “Hey you
can get an access token for this” Now the another way of logging in is
using the authorization code grant which is slightly different. It’s when you’re
logging-in but you have some other secondary application which is got your user in it,
who you also trust. So, for example, if your application log-ins via your github account it doesn’t
have access to all the GitHub usernames and passwords. What you do is you say “Okay go
over there and log-in and they will give me an access code. and having retrieved an
access code I can then request from access code more information about the
user in question and it’s confirming who the user is from another trusted source.
So let’s see these two flows in action. If I log in as Bob-the-Manager directly, Keyrock responds saying “I’ve got an access token”
and I can then use the access token. As you can see we’re using
the user credential grant and we retrieved an access token and once we
have done that we can go back to Keyrock and request more
information – saying “hey this is Bob”. If I have a look at the code, you can see –
we’re looking at the various different grants. This is the
user credential grant – it gets the password, it think it retrieves the user
from the token in question. So it’s making two requests. This is obviously
the case of authenticate (make sure you know who they are) and then get further details
which is what I get I did with Postman earlier on. I’ll log out and I will just
try logging-in using the authorization code. When an application logs-in using the authorization code
– you can see you are automatically pushed to another website. This is the third
party which is going to log-in for us. You get an additional external application, which
is the screen you can see here. We’ve already got this FIWARE tutorial
which is set up in Ke rock protected by OAuth 2 and if I go in as say Alice-the-Admin
with her password and then click sign-in, Keyrock says “Okay I know who you are
but do you really want to let that application called FIWARE
tutorial to read your public information? Because they are going to
find out who you are as well.” And obviously I’m going to say yes and having done
that I get thrown back to the tutorial application. And you can see once again I have
got an access token. If you’re following on on the flow of the code here, you can see that
we have returned to this authcode callback function which is set up within
the identity manager and then it has said “OK I’ve got a code can we swap this code
for a token?” and obviously because tAlice-the-Admin has granted access the response says:
“Yes I, Keyrock have created this code I know who this user is and therefore
you can actually get more information back.” If we log in to Keyrock as Alice you can see FIWARE tutorial has been
set up as an application and it has a client ID and secret which was set up in
the Docker parameters in the first place and also we go back to the
application – FIWARE tutorial has got a series of users associated with it as
well – so that only those users who are recognized and permitted are actually authorized
to go into the system. There are two other main grants – of course
we can refresh each token because they are generally not long-lived. An
implicit grant is a system log-in. Instead of going through this process was saying “I
would like a code, now I would like a token” – it’s a simplified process which can
be done by client-side applications when you’ve got various restrictions in there.
Or indeed, and we will see this later on you can get applications themselves
which wish to say “I would like to be able to access you” – this is a good
example where the application is the one which has got the right to do
things rather than the user has got the right to do things. In this case it’s just
simply a matter of an application requesting an access token. You can see
that the tutorial does support all of these these grant types as necessary. So we
now have users in the system, but in order to let users in and do things we
need to start securing our application. Now I’m restarting the security access tutorial …. We can secure an application with a Policy Enforcement
Point – code within the application itself or we can use a Policy Enforcement Point
(PEP) proxy. To begin with we’ll just deal with enforcing security policies using
the application itself. So I’ll just log out … I’m now logged out. I have no user in the system. I get the debug log on screen as well… If I go to store one… it says “Access denied” – as you can see
what the code is actually trying to do here is trying to authenticate – in other
words check “Is there a user in the system?” and then having been told no
there isn’t a user in the system, it throws me out. If you look at the code in the security module the method for the authenticate is purely a checking
“Have I got a token?” – i.e. have a lot of user setup already. All the application is doing
is rechecking do we have an authorised cookie/session and if
we don’t and we haven’t got a session token throw me out. So let’s log-in as a
user called Bob. Bob is a manager. I want to get an access token
and managers have permission to change prices. This is the price change area which
is permitted to Bob – as you can see in the debug log what is happening here is that we are going
through a basic Policy Decision Point (PDP) which is saying “Does this user have the
correct permission to access things?” and that is way down here deep within the code. So we are able to have a basic Policy Decision Point (PDP). So to check this,
what we do is, we send a token to Keyrock to say “OK has
this user got the relevant permissions to go through and do something?” I’ll show
you on the Postman tool here … When we are requesting a PDP decision
we have got a token of some sort and we say “For this token, for this
particular application, does that token allow you to get on price change?”
for example. Now in this particular case I send it and at first Keyrock replies “Sorry that’s not a
valid token” because that’s not the token which had been created by the user within this
system. if I make the same request with Bob’s actual token … Keyrock now says “Yes that’s a valid token and
this is the information which you can retrieve from that token”. So it says “OK,
for this particular request we are because we are running in basic PDP mode Keyrock is able
to say “Thumbs up! We are permitting access for that particular user”. If I had
logged in as some other user who didn’t have those rights then obviously it
would not be allowed. If I go back to the Keyrock application and look at the IDM data for the
FIWARE tutorial, I have got various users in here, various groups in here, I wish to
manage my roles and the role of “management” in turn has got the ability to
“access price changes” and if I look inside there this has got a simple GUI CRUD
saying this – for that GET request on that end endpoint, the following users have got a
hierarchy of stuff which they are permitted to do. So you can see that by linking “roles” and
“permissions” to “applications” and “users” it is possible to permit or deny various
actions. Now this is what’s known as role based access control (RBAC) and is fine for
relatively simple scenarios where you need a bit more than just saying “I have
a user is it OK?”. So I now have a user and a user can do the following
bits and pieces. Now, so far, we’ve just used applications which are attempting
to get apply security policies. Now we’re going to move on to a situation where individual
microservices themselves want to start talking to each other. In this case we’re going to start putting in a proxy for the Policy Enforcement Point (PEP), in other words the gatekeeper between an
application and the rest of the system. You can see in this particular case
we’re using the Policy Enforcement Point (PEP) to secure the Orion context broker and
so far when you’ve not got a user or you’re supplying with an invalid token it just said “No – Access Denied”. The PEP Proxy is
basically the same job but for services. So we’re hiding the 1026 port and we’re
going to expose and use 1027 instead. You can send a request and access 1027 directly and say
“Okay, I want to get hold of something from the Orion context broker” and the PEP Proxy will
reply “No you haven’t give me a user”. If you’ve got a user in the header which is
obtained via the OAuth flow which we discussed earlier in the hour, the PEP Proxy will make
a request to Keyrock asking “Is this token someone supplied me a valid token? are they allowed to access?” Keyrock itself will say “yes” or “no” and
therefore you as user will be allowed access into protected services. So once again we’re using Keyrock to adjudicate based on role based access (RBAC) and we’re going to have some way
of getting into the system itself I’m still provisioning some devices
but we’ll get in in a second. So let’s get into Postman. If I put in an invalid token or don’t
don’t supply a token. I’m anonymously querying to get hold of all the entities in my system. I send something and the PEP Proxy replies
“No that’s not valid token – go away” However if I now log-in… Each time I’m restarting the previous token has probably
died anyway. So let’s log-in using the Bob’s username and password. I’ve now got
an access token – let’s see what happens if I put my access token in the header. As you
can see I can now access the full data from the Orion context broker because
the PEP proxy has said “I’ve received a token it’s represents a real user and
Keyrock says this user should have access.” Ok. I as the PEPProxy will let them through and pass data from my secured endpoint. That is all that a PEP proxy
does it’s a protection method around the services of a system. Now you can make the protection more
flexible by increasing the level of difficulty within the authentication
process and this is where the final element we’re going to cover today
called Authzforce comes in. Authzforce is purely a Policy Decision Point (PDP). As I
said Keyrock has got a basic RBAC Policy Decision Point based on roles and HTTP
verbs and what-have-you but Authzforce is a much more fliexible Policy Decision point which is what’s known as an XACML server. XACML is
a standard for writing access policies of any sort you like, which are written in XML.
They can be complex and they can be altered on the fly. Now no one in their
right mind would write these things by hand, you can generate them, but it means
that you can have very fine-grained access. If I take a very simple RBAC “role” rule and
we’ll show you the equivalent XACML rule on the right. It is saying for a user to access the bell ring endpoint and I’ll send a POST request
to it I need to be in the “security” role. You can see it’s very verbose – you could
do this in a role-based Keyrock system very very simply, but this means
that you have the flexibility to do many more things. Each rule is one way you can
get an effect ,you can get a permit/allow if you cover all of the elements within a single
rule. The rule itself consists of the target, which is “match this, match this, match
this” but it can also have what’s known as a condition – which is able to be take
more complex elements so you could have a condition “only between nine o’clock
and five o’clock” or you could have a condition which says” I can access all
these records if I created them or if I am the owner of something else which
creates them” – so when it gets more complicated you need to pass more
information. The way that XACML works is you have a series of rules which if you
can pass all the clauses of one of rule you’ll get a thumbs up and then overall that becomes
a policy. And the policy has got a hierarchy as to whether this
is allowable that’s not allowable this is permitted this is this is denied and
you evaluate the policy overall to see whether you can grant access. Beyond
this you can have a series of separate policies so if you think of say a
nightclub, if you want to get into a nightclub you need to be “rich, young and
good-looking” and would mean that you could get in from any combination of
these three elements. It may be except on the “over forties night” in which case
being “young” obviously is no longer applicable and therefore you would have a different set
of rules. So you describe the set of rules in a formal standard. So that
overall Authzforce can evaluate what’s going on. So let’s see if we can get this up and
running once again I’ll show you the actual
diagram Authzforce is now taking the role of the PDP as opposed to Keyrock. It still it takes a little bit of time
to get everything to up start off and running. Obviously once again we’ve got
the usual information within our database which we place there
beforehand. This duplicates the system which had been set up before, the only difference
here is that is that we are now using Authzforce as an additional component. (Get the right page) OK so where are we?
Keyrock is now using this idea of PDP at advanced level which
means that it is not capable of making PDP decision itself. What it does is it
says “Okay, I have a user, I know you’ve got this user and they’ve got the
following roles, but i’m going to delegate the authorization over to
Authzforce. Authzforce is listening on a different port – as you can
see it’s it’s over here (localhost:8080) and then when the PEP Proxy or whatever service will
get told it receives information from Keyrock it then needs to say “Okay Keyrock can’t make a decision. Pass the decision over to Authzforce to make the final adjudication. What they’re authzforce contains is a huge XML file which covers all the rules in this XACML language
and it make the final adjudication as necessary. So Authzforce is the one who is working
out which rules apply, who gets to do what. The complete XACML ruleset can be generated from
within Keyrock if you have advanced rules in your system. I’ll try show an
example quick example if I go into here (I probably need to log out again first). Okay, sign out then sign in again because obviously
the access token for the user I had beforehand won’t have survived. I now go into the FIWARE tutorial application and I have managed my roles… Within my permission that’s a simple rule and this
one you’ve also got the option to have advanced XACML rules which we have set
up in some cases. Off the top of my head I can’t actually remember which ones they are but
they do exist. So let’s look at Authzforce in action. In order to make a request to Authzforce you need to provide within your body all the information which is
required to make a decision. It is little bit bigger because XML is quite extensive and you can see in
this particular case we are sending the subject “this” with the “management”
role within the application “tutorial- docker-site” and we try to get hold of
the “price change” element. If we send that directly it will return again in XML – a
“permit” response. Similarly if we are putting in the wrong information
so we’re saying “Okay I’m in the ‘security’ role and I want to get to the ‘price
change’ endpoint”. I can send that and it will return “deny”. Now all this you have
seen already from the simple RBAC role based application ,but you’d only use authzforce
if you have more complex scenarios. One example I know of is where someone
wanted to have permission to access values when they were in an “abnormal”
state. In that case you would use something like complex event
processing CEP to send an email to someone monitoring this an application saying it’s now in an
“abnormal” state and then you could actually use Authzforce to check permissions to allow
people to access this if the value is beyond a certain threshold.
That’s the sort of thing which can’t be done with basic role based RBAC
because obviously it will depend on the state of the system values as to whether you’re
actually allowed to enter. So programmatically, what happens under
the hood is that I need to sign-in as Bob the manager, I need to get hold of my access
token. I have this access token and when my application uses access token to connect to Keyrock it
replies “Look I know this guy, I know Bob, Bob is a manager has got the management role” and this is my application and this is the other
information I can give you about Bob” but within Keyrock’s authorization decision field
I’m leaving that blank. Keyrock is saying “I’m not going to make a decision
whether to meet to permit or to deny Bob access to the system” Keyrock will also they you “I do
however know that authzforce is an PDP listening over there and Authzforce
is able to adjudicate on this domain”. A domain is a unique ID for setting up a
series of policies. So having received that information you can then , using
the domain and passing in an XML request say “OK, I have this user he is a manager and he is
trying to get access to this endpoint” – in this case we’re getting hold of the Orion context broker /v2/entities endpoint and we can send this
information through and check “Can I get hold of something?” and the answer is “yes
you are allowed to do this”. Now this is programmatically held within the PEP
proxy to either allow or disallow users to get through to the system. So if I now go
back to the debug log… there we go. OK, so we’re now going to
just log out with Bob. If we then log back in as Bob and then attempt to view the store it’s
saying “No, you’re not allowed in there yet”
so the PEP proxy won’t allow the tutorial application to get into the context broker.
I was now to refresh and if I was to go in a second time and it would say “Yes,
that’s fine you can come in and t look at stuff”. I’ll just log out again and if
I log in as Eve I can also attempt to view the store but again it won’t let me in for the
simple reason that Eve has got no has not got any role which is able to
access Orion via the PEP proxy so I’m able to stop people from coming into my
system if I don’t want them to. So that is a brief
introduction to Identity Management and Access Control. Identity Management is
effectively a database – it’s a database which has got the ability to
ensure that only the right individuals get access to resources it’s got things
like usernames and password so you can identify yourself with roles and
permissions and what-have-you. One thing which I didn’t mention is that obviously
Keyrock is designed to be a totally generic security component, so if you want to
hold additional information about users there is actually a “website” attribute in Keyrock users which
can be used for linked data so you can get information on how to work a hold of
further information( like their favorite cats or whatever). If additional information is important for
you that would be held in a separate location because it’s not strictly
anything to do with whether they’re allowed to do stuff or not. Access
Control is the selective restriction of access to resources and effectively it
can be subdivided into various different levels of security.
Authentication is just “Who are you?” and usually if you have a
system which is based on authentication it means an identified user can do everything on
their own account and other people maybe just can view in the account and you
don’t need to have anything more complex than that. Authorization is more restrictive than that saying is “X allowed to do Y to Z?”
and the basic way of doing that is role based authorization RBAC which as you
can see you just have a verb, a resource and a role. Who can do that or not do
that for your permission. You can also get policy based authorization, which as
we’ve seen is more complex when you are attempting to gain access you pass
through the Policy Enforcement Point (PEP) which you can either have as a separate service like a
PEP proxy or you can have it programmatically within the
code of your application and then something else usually a service such as Authzforce or Keyrock will act as a policy decision point (PDP) A PDP decides whether you’re allowed in
or you’re not allowed in. And the administration of these rules (you don’t
really want to set up by hand obviously) is done using a Policy Administration Point (PAP) which is the whole point about having a GUI. There are three
FIWARE enablers which I’ve shown today: Keyrock an identity manager and
its either GUI or API based and also is able to cover non-human actors such as
PEP proxies and IoT Agents and it is implicitly multi-tenant because
you need to pass a client ID and secret in order to get into any system. It is
using the OAuth2 standard which is a way of getting hold of the system. It
doesn’t however do complex authorization, it does basic authorization but
not complex authorization. The PEP proxy is effectively a gatekeeper allowing you
, or to more likely denying you entry to places you’re not supposed to go and in
order to identify these users (not necessarily people) – users and other
actors you are identify them by placing a header in the resource it can be used
to link to either Keyrock PDP or Authzforce PDP and if you were to use the PEP
proxy with Authzforce to the fullest extent you would need to extend
the PEP Proxy code to pass additional information as requested to make sure you have sufficient information to be able to make a decision. As I said if you want to get hold of “All the
records which I am allowed and all my subordinates are allowed”, Authzforce needs to have
more information prior to making that adjudication. You’ll authzforce purely
does the “permit” or “deny” using this XACML based rule set and the difference here
is that everything can be modified on the fly – it’s able to retrieve a new set
of rules at any point as conditions change. It should be
emphasized that there are other ways you can do security around FIWARE and you
there is the APInf Generic Enabler and there are other FIWARE compliant
elements such as Keystone or Telefonica Steelskin. Furthermore, if your scenario
requires it, you may wish to extend your security in other ways, say using IDSA
security or whatever other system is appropriate for you. It goes without saying
that you should always use the most appropriate tools for your use
case. The philosophy with FIWARE is that basically we are an open system, we
are open APIs and we are there to make it easy for you to transfer your data .
Therefore unless you as a developer make the effort lock down your data you are at
risk of a security breach. We are offering you a generic security system you must put this
system around your own data in order to do lock it down. So that is the basic introduction to Identity Management and Access Control
and all that remains is for me to thank you for your time. I hope it was interesting for you and I wish you a good morning.


2 Replies to “FIWARE Wednesday Webinars – How to Secure FIWARE Architectures”

  1. Harry L says:

    Policy Enforcement Point or Policy Execution Point (29':43")?

  2. Harry L says:

    I have been doing a research about FIWARE to prepare for a school presentation about its security aspect and came across this article. I am not sure if the problems the author mentioned in his paper have been addressed? Or the claims aren't correct at all?

Leave a Comment

Your email address will not be published. Required fields are marked *