You can also check out SMART white paper - single page that describes the problems in Higher Education that SMART AM solves.

Here comes the second part of our hands-on introduction to our lovable Python UMA implementation – PUMA. As Part I, it may not be all that brief, but it is wildly comprehensive and grants you the hottest superpower on the market: rapidly creating sleek, UMA-enabled Requester Applications.

Architecture overview

Just like with the host application, the requester app also has a central linking entity that is used to identify a user – RequestingParty. A RequestingParty will need an access token for each AM it interacts with, hence: multiple RequesterAccessToken entities. Every entity of this type is of course linked to an AuthorizationManager entity that represents the AM the token pertains to.

So, let’s talk about tokens. The requester application has to deal with two types of tokens:

AM tokens

these are regular OAuth tokens. There’s one per a requesting party-AM pair. This one allows you to access the AM’s endpoints.

RPT

these are used to access resources at the host applications. You will have at least* one per host. You obtain these by asking the AM for it; and for that you need to have the AM token first.

There’s a family of calls that will let you obtain, set, change, update, retrieve (and so on) these tokens, so you need not worry about storing them.

What the flow (usually) looks like

Check out this neat graph to get an idea of what the code flow in a requester application looks like. Remember that your mileage may vary slightly.

Subsequent requests are simpler.

Discovery

This part is identical to what is described in the “host” section (well, you may be interested in different endpoints, but the method is the same). Check it out. ➶

Getting a token

Thankfully, same as host-side. ➶

For starters: making a regular HTTP request

Assume that the user of the requester application (the requesting party, if you will) tells the application to fetch what’s under this URI:

https://pumahostone.appspot.com/api/people/alice/personal/name

In order to act smart, it makes sense to first do a pre-flight request for the resource and see how the server responds. We’re not really interested in the data itself right now, as we expect the request to fail, but the response headers (especially WWW-Authenticate) should contain some really valuable information. So let’s make a pre-flight (note: it’s a HEAD request):

uri = "https://pumahostone.appspot.com/api/people/alice/personal/name"
response = Puma.Util.preflight_request(uri)

response will be an httplib.HTTPResponse object. Two things you’ll want to check for to make sure the object is UMA protected:

• response status is 401
• there’s an UMA-flavored WWW-Authenticate header set, with the name of the AM protecting the resource you just asked for. So you know who to ask for access.

For example (a bit of code from the pumarequesterone application):

if response.status == 401 and Puma.Util.check_www_auth_header(response):
    am_data = Puma.Util.check_www_auth_header(response)
    am = Puma.UMA.discover_am_from_www_auth(am_data)

Something to note about the last line: if the AM had already been discovered, it will simply return the existing AM object from the storage layer.

Now that we have am, we check if we’re OAuth-registered (and if not, we register):

if not am.client_id and not am.client_secret:
    registration_data = Puma.Pouches.RegistrationData()
    registration_data.client_description = "Puma, Requester One."
    registration_data.client_icon = ""
    registration_data.client_url = "https://pumarequesterone.appspot.com"
    registration_data.client_name = "Puma Requester One"
    registration_data.redirect_url = "https://pumarequesterone.appspot.com/callback"

    Puma.OAuth.oauth_registration(am, registration_data)

Now we have the AM out of the way. We’re confident the application is properly set up to talk to it, now let’s make sure the user (also called the Requesting Party, RP for short) is just as ready:

# user_key is the logged-in user's unique identifier

rp = Puma.Util.check_if_user_has_requesting_party_identity(user_key)
if rp is None:
    # first time UMA interaction
    rp = Puma.Util.create_requesting_party_identity(user_key)

A RequestingParty “identity” (an object) is the requester-equivalent of an UMAUser. Refer to the architecture overview if your memory fails you (or you skipped it and are now helplessly scratching your head).

Great. Now, the RequesterAccessToken entity has a dichotomous role:

• contains the AAT
• contains a set of RPTs (internally called an RPT wallet, such an unimaginative name..)

Let’s leave that for now. We need a RequestingParty, with the AAT. How is an AAT obtained? Well, it’s a regular OAuth token, so, naturally, you have to send the user through an OAuth flow. Code should look familiar:

rat = Puma.Storage.get_rat_for_am(rp, am) #
if rat is None:
    Puma.Util.set_pending_registration(rp, am)
    self.redirect(Puma.OAuth.get_rat_authz_uri_for_am(am, 'https://pumarequesterone.appspot.com/callback'))
    return

Callback expects an authorization code grant will be passed to it via the code parameter:

#::-- inside callback handler ('/callback')

code = self.request.get("code")
if code:
Puma.OAuth.trade_code_for_rat_and_store(
current_user_key,
code,
"https://pumarequesterone.appspot.com/callback",
)

session.set_flash("Callback redirect you here. You should have a requester token now.")
self.redirect('/')
#::--

TBD

host_id = am_data["host_id"]
rpt = Puma.Util.get_rpt_for_host_id(rp, am, host_id)
if not rpt:
    rpt = Puma.Util.obtain_and_store_rpt_for_host_id(rp, am, host_id)

urlparsed = urlparse(resource_uri)

if urlparsed.scheme == 'https':
    hx = httplib.HTTPSConnection(urlparsed.netloc)
else:
    hx = httplib.HTTPConnection(urlparsed.netloc)

headers = {
    'Authorization': 'Bearer ' + str(rpt),
}

hx.request('GET', urlparsed.path, '', headers)

re = hx.getresponse()

This sends a token-equipped (RPT-equipped) HTTP request to the host application. The response will generally be one of:

• HTTP 200 (OK): the host application determined that the token has enough permissions assigned to it, and allowed access; the response body is the requested resource.
• HTTP 403 (Forbidden): the token is fine & valid, but it doesn’t have the required permissions associated with it yet. The response will contain a WWW-Authenticate
  header, with the ticket parameter set. This ticket will be used to upgrade (i.e. assign new permissions to a token).

Since the 403 response is practically guaranteed to be the response with a freshly-acquired RPT, here’s the code that handles it:

if re.status == 403:
www_auth = re.getheader('www-authenticate')
ticket = Puma.Util.ticket_from_www_auth(www_auth)

claims_requested = Puma.UMA.send_ticket_to_claims_endpoint(rat, ticket, www_auth)
# claims_requested will be an array of claims that the requester needs to provide in order to get access

# at the moment, there's only one type of claim that you will encounter:
# that's redirect_required, which asks for a redirect that validates your identity at the AM.
for claim in claims_requested:
if claim['claim_type'] == 'redirect_required':
logging.info("Redirecting to %s" % claim['claim_value'])
self.redirect(claim['claim_value'])

After the redirect is complete, you should end up back at the requester application, your RPT now bearing new powers. You should now try to access the resource again (this can be automated – look at the code for /callback to see the trickery.

This time the request should be a 200 OK:

if re.status == 200:
    # resource requested in response body
    response_body = re.read()

And you’re done.

An insight into PumaRequesterOne: the tiny mighty callback handler

Apart from acting as a regular OAuth 2.0 callback handler, the requester’s /callback also needs to double as a permission upgrade redirect handler (vague? see previous paragraphs about the redirect_required claim).

So /callback handles four cases, as outlined below:

class RequesterCallbackHandler(webapp.RequestHandler):
    def get(self):

    #
    # two ways through this:
    # - regular OAuth flow (code)
    # - claims flow (x-oauth_*):
    # ~ alice to alice
    # ~ alice to bob
    #

    code = self.request.get("code")
    x_oauth_access_granted = self.request.get("x-oauth_access_granted") # alice-to-alice
    x_oauth_access_req = self.request.get("x-oauth_access_req") # alice-to-bob
    claim_status = self.request.get("claim_status") # openid claim

    if code:
        # standard OAuth 2.0 flow

    elif x_oauth_access_granted:
        # post-claims redirect; access granted (Alice-to-Alice)

    elif x_oauth_access_req:
        # post-claims redirect; access requested (Alice-to-Bob)

    elif claim_status:
        #

    else:
        # fallback.

    if session['transaction_type'] == 'fetch':
        self.redirect('/fetch')
    elif session['transaction_type'] == 'update':
        self.redirect('/update')

Let’s get to work, then.

Terminology

Before we talk, we need to establish some fundamental terminology:

• host application: a regular web application that hosts data of some kind (which you would be interested in sharing) — be it pictures, your grades, your personal data, anything.
• requester application: a web application that would like to use data hosted by another application (the host application, described above)
• authorization manager: at the very center of UMA sits the authorization manager. The essential piece of the puzzle — you should check UMA’s wiki for a wealth of information.
• PAT: protection API token (previously: host access token). A simple OAuth 2.0 access token; used by the hosting application to interact with the AM.
• AAT: authorization API token (previously: requester access token). A simple OAuth 2.0 access token; used by the requesting application to interact with the AM to identify the requesting party (the user of the requesting application)
• RPT: requester permission token. A token used for representing permissions over at particular host. This is the token that is used during any UMA interaction between the host and requester applications.
• policy: a setting at the AM that describes who can access what; for example: “Alice@gmail.com can access my calendar”
• token upgrade: we say a token is upgraded when new permissions are assigned to it

Custom MIME types

Look through the list. This should give you an overview of the messages used in UMA.

• application/uma-scope+json: represents an UMA scope
• application/uma-resource-set+json: represents a resource set description
• application/uma-status+json: represents a response containing information about the status of a token
• application/uma-requested-permission+json: used when the host asks the AM to issue a new ticket to allow token upgrade.
• application/uma-permission-ticket+json: indicates that the response contains a ticket – an opaque value that can be used by the requester application to add new permissions to a token.
• application/uma-access-token+json: indicates that the response contains a new token. For example, this is the case when the requesting application asks the AM to issue an RPT for a new host.

Puma’s anatomy

Visualization is key!

As you may have somehow noticed, calls and objects are split into five categories:

• Puma.UMA.*- the essence of UMA. Resource management, token handling — here’s the place.
  • .discover_am_endpoints(…)
  • .register_resource(…)
  • .check_token_status(…)
  • … et al
• Puma.OAuth.*- everything that pertains to the OAuth-flavored side of UMA, bespoken for Puma. From trading grants, via tokens, all the way to gluing together those authorization URLs.
  • .get_authz_uri(…)
  • .trade_code_for_hat_and_store(…)
  • .refresh_token(…)
  • … et al
• Puma.Util.*- utility functions for Puma. Not merely optional helpers, so be sure to pay attention to these.
  • .get_owner_of_resource(…)
  • … et al
• Puma.Storage.* – an attempt to abstract away from the reality of the underlying data storage mechanisms.
• Puma.Pouches.*- objects that act as containers and help you make sure that all those calls get just the data they need. Simple as that.
  • .ResourceSetDescription
  • .RegistrationData
  • … et al

Host application

Imagine an application that stores some of your most often used personal data (perhaps an address? or list of schools attended?); imagine also that the application can expose your data the the world via a RESTful API, such that – just as an example – your home address would be accessible under..

https://app.example.com/people/alice/address/home

For example, on our own Puma Host One, Alice’s home address is available under:

https://pumahostone.appspot.com/api/people/alicja/address/home

Architecture overview

So it’s assumed that the application has some notion of users/accounts, and that users are uniquely identifiable by an ID of some sort. That is the only part of the application’s infrastructure that Puma needs to be able to tap into (and even this in a very superficial and completely non-intrusive manner). How it builds on top of that can be seen below (explanation follows, of course):

” alt=”" width=”90%” />

Let’s step through this:

AuthorizationManager

These entities hold information about known (discovered) authorization managers. The data they hold is related to the two phases an AM introduction process goes through:

• discovery: the AM’s endpoints (in other words, the API), used to register resources, do token magic and so on.
• registration: the AM’s [OAuth] credentials, most importantly the client_id and client_secret

ResourceMap

A single ResourceMap entity represents and holds information on a resource, existing on the host, that has been set up for protection with UMA.
Data stored includes, among others..

• the resource URI
• the ID of the resource
• the resource name & short description (optional)

UMAUser

Of course, the aforementioned entities need to be linked together somehow. After all, we’ll be asking questions such as:

• what AM does $user want to use?
• who owns a ResourceMap?
• … and obviously many more (but they’re all just as trivial)

Enter UMAUser. The user’s UMA-powered alter-ego identity on the host application.
It has a monogamous relation (has) with an AuthorizationManager, an outside User entity; as well as a polygamous (has-many) relationship with ResourceMaps.

Simple enough. Let’s get some action.

Discovery

Any application that wishes to talk with the AM must first learn about its endpoints; each endpoint has a well-defined, specific role to fulfill. The go-to place for learning about the AM’s endpoints is always:

http://www.smartam.net/.well-known/uma-configuration

While you don’t even need to interact with it directly, it’s probably a good idea to know that an uma-configuration file looks like this:

{
    "version": "1.0",
    "issuer": "http://www.smartam.net",
    "dynamic_client_registration_supported": "yes",
    "token_types_supported": ["artifact"],
    "host_grant_types_supported": [
        "authorization_code",
        "client_credentials"
     ],
    "claim_types_supported": ["openid"],
    "client_dynamic_registration_endpoint": "http://www.smartam.net/api/oc/register",
    "host_token_endpoint": "http://www.smartam.net/oauth/token",
    "host_user_endpoint": "http://www.smartam.net/oauth/authorize",
    "resource_set_registration_endpoint": "http://www.smartam.net/api/uma/resource_reg",
    "token_status_endpoint": "http://www.smartam.net/api/uma/validation",
    "permission_registration_endpoint": "http://www.smartam.net/api/uma/permissions_reg",
    "requester_token_endpoint": "http://www.smartam.net/oauth/token",
    "requester_user_endpoint": "http://www.smartam.net/oauth/authorize",
    "permission_request_endpoint": "http://www.smartam.net/api/uma/permissions_grant/ticket"
}

All you have to do with Puma is:

am = Puma.UMA.discover_am_endpoints("www.smartam.net")

What it does:

• reads the JSON resource found under .well-known/uma-configuration
• parses it, extracting endpoint info
• stores the data deep below, in the storage layer, as an AuthorizationManager entity.
• if the call is ever made with the same hostname that was just discovered, the call simply returns the existing AM data

And you might want to keep that am object near. Because after discovery you’ll usually need…

Registration

To talk to the AM, the host needs to obtain an OAuth 2.0 token for use with the AMs endpoints. This is the PAT, or protection access token. We’ll need to go through a really standard OAuth flow to get it. For that, our applications need to be registered with the AM – in an OAuth sense; that means they need to have a client_id and client_secret.

Normally, the application is manually registered by the owner. Because it would be impossible to guarantee that every host and requester application out there would be registered with any AM they might be asked to work with (and the beauty of UMA is also in the freedom to choose an AM), AMs may support dynamic registration.

It’s pretty straightforward. Actually, one could argue that it’s easier than manual registration. So how do you register?

Puma.OAuth.oauth_registration(am, registration_data)

.. where registration_data is (let’s call it rd to make it short):

rd = Puma.Pouches.RegistrationData(
    client_name="Puma Host One",
    client_description="Puma Host One.",
    client_url="https://pumahostone.appspot.com",
    client_icon="https://pumahostone.appspot.com/static/images/resource_icon.png",
    redirect_url="https://pumahostone.appspot.com/callback"
)

After this call, you’re all set. The application has been officially introduced to the AM.

Getting a token

To interact with the AM, the application has to get a token that represents the user of behalf of whom it is to communicate. This is a standard, nearly boring, OAuth 2.0 flow. The application should direct its user to a specially crafted authorization URL. The endpoint is:

http://www.smartam.net/oauth/authorize

That’s not enough. A proper URL that will lead to an authorization dialog at the AM is more like the following:

http://www.smartam.net/oauth/authorize?
client_id=host_client_id&
redirect_uri=http://host.example.com/redirect&
response_type=code

Puma will generate this for you without a problem. It takes a unique user identifier as an input, looks up the AM the user is set to use and constructs a proper authorization dialog URL. Handy:

authz_uri = Puma.OAuth.authz_uri_for_user(uma_user, redirect_uri)

You should redirect the user to this URI. When the user selects “allow” (or similar; hopefully anyway!) they will be redirected to your redirect URI. The handler for that URI should extract the code parameter and call:

Puma.UMA.trade_code_for_hat_and_store(code, redirect_uri)

… which will go through the rest of the OAuth 2.0 flow. That is, it will send the code to the appropriate endpoint over at the AM and receive a regular OAuth access token.

Registering a resource

When the hosting application wants to start protecting a resource, it first needs to register the resource with the AM. Registration is simple and intuitive – the resource registration endpoint is:

http://www.smartam.net/api/uma/resource_reg

This endpoint expects to find a resource set description in the request – this is a JSON object that should look like this:

{
    "name": "Photo Album",
    "icon_uri": "http://www.example.com/icons/flower.png",
    "scopes": [
        "http://photoz.example.com/dev/scopes/view",
        "http://photoz.example.com/dev/scopes/all"
    ]
}

The AM responds with an HTTP 201 Created response akin to this:

HTTP/1.1 201 Created
Content-Type: application/uma-status+json
ETag: 126x358adkfgw3
...

{
"status": "created",
"_id": (id of created resource set),
}

With Puma, you need to initialize and fill out an object that imitates the resource set description, Pouches.Puma.ResourceSetDescription:

description = Puma.Pouches.ResourceSetDescription()
description.scopes = [
    "https://pumahostone.appspot.com/uma/scopes/read",
    "https://pumahostone.appspot.com/uma/scopes/write"
]
description.name = "A name for the resource you're registering."
description.icon_uri = "http://unsettling-icons.org/icons/resource.png"
description._id = pre_generated_id

rx = Puma.UMA.register_resource(user_key, description)
[/pumacode]

Doing well. Now that the AM knows that it should be prepared for protecting such a resource (creating policies, handling token inquiries), all that needs to be done is tell the application itself that it should from now on...

[sourcecode language="python" wraplines="false"]
(continued)

rx = Puma.UMA.register_resource(user_key, description)
response_body = response.read()

# success!
if rx.status == 201:
    json_data = json.loads(response_body) # parse the JSON data into an object

# pull ETag from headers
etag = response.getheader('ETag')
# pull the policy uri from the JSON response
policy_uri = json_data['policy_uri']

# creating a ResourceMap
map = Puma.Util.create_resource_map(real_uri, pre_generated_id, etag, name, icon_uri, policy_uri, user_key)

An insight into PumaHostOne: registering resources

PumaHostOne uses a separate handler to handle resource registration.

Available at /uma/register-resource, it handles any requests to register a resource. You will most likely want to copy this solution, if you decide to implement your own application.

A simplified (logging and some error checking has been stripped) version of the final handler is below, with comments (feel encouraged to check out the real handler as it contains some additional sanity checks that you might want to use as well!):

class RegisterResourceHandler(webapp.RequestHandler):
    @login_required
    def post(self):
      session = Session(self)
      current_user_key = session['key']

      user_key = current_user_key
# --- data from request (name, icon_uri, scopes?)
name = self.request.get('resource_name', None)
icon_uri = self.request.get('icon_uri', None)
scopes = self.request.get('scopes', None)
real_uri = self.request.get('uri', None)

# generate id (here, needed when constructing path)
pre_generated_id = Puma.Util.generate_resource_set_id(real_uri)

# devise a resource set description
description = Puma.Pouches.ResourceSetDescription()

# NOTE: hosting these scopes on AppEngine (be it static or dynamic) turned out to be unreliable
# .. bad luck, perhaps, but we kept getting timeouts. Hence the scopes moved to S3.
# Just a heads-up.

description.scopes = [
    "http://smartcdn.s3.amazonaws.com/pumahost/dev_scopes/read.json",
    "http://smartcdn.s3.amazonaws.com/pumahost/dev_scopes/write.json"
]

description.name = name
description.icon_uri = "http://cdn1.iconfinder.com/data/icons/Mobile-Icons/128/04_maps.png"
description._id = pre_generated_id

rx = Puma.UMA.register_resource(user_key, description)
body = rx.read()

# success, create map
if rx.status == 201:

    json_data = json.loads(body)

    etag = rx.getheader('ETag') # pull ETag from headers
    policy_uri = json_data['policy_uri']

    Puma.Util.create_resource_map(real_uri, pre_generated_id, etag, name, icon_uri, policy_uri, user_key)

    session.set_flash("Resource registered.")
else:
    session.set_flash("Something went wrong.")

# redirect the user back to where he came from
self.redirect('/')

An insight into PumaHostOne: smart-embedding “share”/”manage” buttons

If you’re of the curious type, you’ve already seen PumaHostOne. The buttons to the right of each resource are the subject of our little chat right now.

That’s actually an iframe. In order to allow nice separation of Puma & application code, PumaHostOne has a separate handler that is meant to be used inside an iframe, and display either:

• a share! button, if the resource is not yet shared (insight: no ResourceMap)
• settings & stop sharing buttons, when the resource is being protected.

How does it work?

• the handler sits at /internal/uma_mini_panel
• input parameters are:
  • uri – the URI of the resource; this is fundamental
  • name – a name for the resource; this is auxiliary
• so for example, the iframe’s src could be:

/internal/uma_mini_panel?
uri=http://example.com/api/alice/address&
name=Alice’s%20Address

• on receiving such a request, the handler first checks to see if the resource identified by uri is protected (i.e. – again – no ResourceMap for this URI*)
• if the resource is protected..
  • retrieves the policy URI for the resource and creates a settings button
  • retrieves the ID for the resource and glues together a working stop sharing
• if the resource is NOT protected..
  • creates a share!, which on click will send a request to /uma/register-resource, using the name parameter supplied.

Again, don’t be shy and take a peek at the source code. The handler you’re looking for is called UMAMiniPanelHandler. We’re not always that bad at coming up with names, promise.

Checking token status

Whenever an UMA requester makes a request, the requester’s access token is included inside a WWW-Authenticate header. Like this:

WWW-Authenticate: Bearer 39mal1487ig819ree417ee389

The host’s job, in order to determine if the requester is allowed to access the requested resource, is to pass that token to the token status endpoint at the AM — effectively asking “what can this token do?”. Upon receiving a token status description, the host can check if the required access (e.g. a DELETE)

While this step is done by the Warden – a piece of middleware that you can simply wrap your API handler in, here’s what the Warden calls under the hood:

token_status = Puma.UMA.check_token_status(am, hat, request_body)

token_status is an httplib.HTTPResponse object. If you call .read() on it, you’ll have the response body in front of you. An example response looks like this:

[
   {
        "resource_set_id": "119n278b3600",
        "scopes": [
            "https://host.example.com/actions/read",
            "https://host.example.com/actions/write"
        ],
        "exp": 1500819380
    },
    {
        "resource_set_id": "mn07689b5v74",
        "scopes": [
            "https://host.example.com/actions/read",
        ],
        "exp": 1500814321
    }
]

For example (way too carefully detailed):

1. a GET request for /alice/personal/name arrives at the host
2. host finds a requester token in WWW-Authenticate
3. host looks up the AM that protects this resource
4. host asks AM about the status of the token
5. AM replies with response just like the one above
6. host translates /alice/personal/name to a resource id
7. turns out the id is mn07689b5v74 — there are permissions associated with this resource for this token, good!
8. host translates GET to https://host.example.com/actions/read (the application must know how to translate actions on particular resources to actions/scopes. There’s no magic here, this is pretty much configured by the owner of the app.)
9. host finds that this token can read (GET) this resource (mn07689b5v74) — actions for this resource does contain the correct scope URI.
10. access is granted!

So if the application finds that the the token has sufficient permissions associated with it, it may simply grant access, and the story ends..

If it turns out that the RPT did not have enough permissions to access the requested resource, the host application goes to the AM and asks to register a sufficient permission with the token. The AM sends back a ticket, an opaque value, which is then sent back to the requester by the host. The token is ready to be upgraded.

Upon receiving a ticket (in the WWW-Authenticate header) from the host, the requester contacts the appropriate AM endpoint, passes the ticket, and receives a list of claims required in order to finish the upgrade (i.e. association of new permissions with the RPT).

All this business is swiftly handled by the Warden.

So at last, as a bonus:

Understanding the warden

One of the central parts of UMA is the decision process that happens at the host application whenever a resource is requested. Imagine a request for https://host-application.com/api/people/alice/personal/name, a resource representing Alice’s personal name, is received by the HTTP server. The response is routed to the appropriate handler script that has to carefully analyze the request, and – in most non-trivial cases – consult the AM, inquiring about the validity of the token presented and any associated permissions.

The structure of PumaHostOne can be broken down into two main scripts:

1. main.py
   the application logic, frontend, the tangible web application itself
2. restapi-ng.py
   handler for the RESTful API provided by the application

Now, the server knows to route any requests for paths beginning with "/api" to restapi-ng.py, and everything else to main.py.

However, when UMA comes into play, someone has to intercept every API-destined  request and give a verdict on what to do with it. The first, most basic decision is: is the resource UMA protected? Has the user chosen to restrict access to this resource with UMA? If the requested resource is protected, a *ResourceMap* object for the resource’s URI exists in the datastore. Take a look at this truly trivial if .. else, taken straight from the Warden’s code (note that the warden uses a pure WSGI interface to ease any eventual porting efforts):

path = environ['PATH_INFO']</pre>
map = ResourceMap.gql("WHERE real_uri = :1", path.strip('/')).get() # (stripping for consistency)
if map:
# check if resource contains an access token
# speak UMA from now on.
else:
# resource is not protected, pass
# (this may be unclear to people ignorant of CGI/WSGI, read up?)
return self.app(environ, start_response)

Case one: If no such object exists, the user hasn’t decided to use UMA for access management and the request is let through to the real API handler, which prepares a response based on its own logic and responds back to the requester. The warden interferes no more.

Case two: If, however, a ResourceMap object is found, the warden has to act accordingly to the UMA protocol – check for an access token, ask the AM about the status of the token, respond to the requester with a UMA response and so on.

And for the chart-inclined:

It looks like we’re done here. Got questions? We’re here for you. Now go build awesome stuff!

• Puma code repository: https://bitbucket.org/smartproject/puma-gae
• Building a host application with Puma: right this way
• Building a requester application with Puma: over here

• PumaHostOne: https://bitbucket.org/smartproject/pumahostone
• PumaRequesterOne: https://bitbucket.org/smartproject/pumarequesterone

Learn more about the flow using SMARTAM by viewing the following two presentations:

• http://www.slideshare.net/smartjisc/smart-uma-alicetobob-sharing
• http://www.slideshare.net/smartjisc/smart-uma-alicetoalice-sharing

All code is released under the Apache 2.0 license.

“I’ve experienced quite a bit about how open source works. It’s been a wonderful learning experience for me and definitely turned me from someone who thought open source code and developers were somehow not as good as closed source equivalents into a person who knows that the opposite is most definitely the case!”(Mark Little, Red Hat, blog)

Indisputable fact of today’s worlds is an existence of many IT companies that based their success on the Open Source. Talend, Alfresco, Cloudera, Mozilla and last but not least: Red Hat/JBoss (How JBoss did it!) are great examples of that.

Many more, Google, Facebook, Microsoft and Yahoo and many more, provides commercial services, and are not entirely based on open source projects, but helps their communities, seeing obviously support business model in there. Growing popularity of cloud computing has been giving birth of new open source cloud platforms, high performance distributed computing, decentralized and scalable databases. Many of these solutions does not have comparable closed ones and all of them in some way constitute of the revenue for the enterprises.

Even though, many businesses are constantly striving for using closed source software provided by “big vendor’s”, with very expensive and professional marketing machine. Good, that there is slow, but visible movement towards open products build within communities. Benefits of that movement are getting more and more visible, followed by many successful stories. That is caused by many advantages of the Open Source.:

• No vendor lock-in

• Continuity

• Companies competition

• Zero entry cost

• Reduced overall costs

• Zero purchase fee.
• No license fees, e.g. for every product user (does not increase cost when you organization grows)
• No organizational administrative costs to purchase software, updates etc.
• Competition in the markets keeps lower support costs and quality services
• Eliminated risk of closing project by the vendor or vendor bankruptcy

• Security and quality

• Engineers are happy

• Easier to add new features

• Benefit from each other

• Have influence on a standard

Very often reference implementation of the standard specification is implemented as open source project. It allows all involved in the standard parties to work on the development to fulfill all theirs priorities. Even more often happens that implementation is done beforehand standardization. If your organization is one of its creators, you can influence the way that standard goes.

This article is a mix of our thoughts and discussions over last ApacheCon NA 2011 in Vancouver, BC that SMART project was able to attend. Thanks very much for TAC team for the support.

The first presentation is an attempt to enhance the graphical interface by use of visualizations in order to make the interface more self-explanatory and intuitive for the end-user.

The other presentation on Trusted Claims explains the concept of Claims-based Access Control and its role in UMA. The brief summary of his contribution can be seen here:

According to this approach the decision to grant access to a protected resource is made based on the requesting party information such as name, age, email address, role, location or credit score. In the presentation two user scenarios are shown: Enterprise class scenario and social/web class scenerio.

The OAuth 2.0 Python library has been released under the Apache 2.0 license and we plan to continue further development. As always, we very much appreciate feedback and we’re open to suggestions on how to make the library better!

To obtain an API KEY you need to log into your account at www.smartam.net. Go to an account page, and generate your API KEY.

]]> http://smartjisc.wordpress.com/2011/06/30/domenico-jacek-join-smart/feed/ 0 maciejmachulak smart_team http://smartjisc.wordpress.com/2011/06/30/smartam-with-history-log-and-access-requests-log/ http://smartjisc.wordpress.com/2011/06/30/smartam-with-history-log-and-access-requests-log/#comments Thu, 30 Jun 2011 11:05:36 +0000 maciejmachulak http://smartjisc.wordpress.com/?p=503 ]]> We have just launched a new release of SMARTAM at www.smartam.net. Apart from fixing a few bugs, this release comes with two brand new features:

• History log
• Access requests log

History log is a list enabling you to see who accessed your resources and when. This way you are given even more control over protection of your resources and you are always able to follow what happens to your data. The other feature - Access requests – is a list of notifications from your friends who have heard about your data (e.g. newly uploaded photos) and have sent you a request to be able to access this data. You can then easily grant access to the requested data (according to your preferences!) instantly as this feature is located in the sidebar on almost all the pages of SMARTAM. This way you will be always sure that you didn’t missed anybody while setting security and privacy settings for your resources! Read more to see example screenshots!