New eBook: REST assured with JAX-RS

I am happy to announce the release of yet another book – REST assured with JAX-RS:-)

To download …

Just visit the book page and click the Add Ebook to Cart button. Don’t worry, the book is absolutely free !:-)

cover_final

Quick preview

It’s structured into distinct sections

  • Warm up: Gives you an idea of what the book is about, what you can expect, JAX-RS & REST introduction
  • Section I: Deals with the basics and covers topics such as Resources, HTTP mapping, HTTP Injection, Client API and Security
  • Section II: Dedicated to Providers – Message Body Readers & Writers, Filters, Interceptors, Exception Mappers and associated topics
  • Section III: Covers slightly advanced topics such as request pipeline, caching, content negotiation etc
  • Miscellaneous: The last portion of the book covers Asynchronous APIs and the future version

Hope you enjoy it ! Feedback, comments, suggestions are always welcome

Cheers!

Posted in Java EE | Tagged , , , | Leave a comment

JPA Entity Manager API notes

Bare basic stuff…

  • Categorizes JPA Entity Manager operations
  • Good for quick glance

Persistence Context Operations

CRUD operations

  • <T> T find(java.lang.Class<T> entityClass, java.lang.Object primaryKey)
  • <T> T find(java.lang.Class<T> entityClass, java.lang.Object primaryKey, LockModeType lockMode)
  • <T> T find(java.lang.Class<T> entityClass, java.lang.Object primaryKey, LockModeType lockMode, java.util.Map<java.lang.String,java.lang.Object> properties)
  • <T> T find(java.lang.Class<T> entityClass, java.lang.Object primaryKey, java.util.Map<java.lang.String,java.lang.Object> properties)
  • <T> T merge(T entity)
  • void persist(java.lang.Object entity)
  • void remove(java.lang.Object entity)

other operations

  • void refresh(java.lang.Object entity)
  • void refresh(java.lang.Object entity, LockModeType lockMode)
  • void refresh(java.lang.Object entity, LockModeType lockMode, java.util.Map<java.lang.String,java.lang.Object> properties)
  • void refresh(java.lang.Object entity, java.util.Map<java.lang.String,java.lang.Object> properties)
  • void flush()

  • void clear()

  • void detach(java.lang.Object entity)
  • boolean contains(java.lang.Object entity)

Operations on self

  • void close()
  • boolean isOpen()

Query Operations

  • Query createNamedQuery(java.lang.String name)
  • <T> TypedQuery<T> createNamedQuery(java.lang.String name, java.lang.Class<T> resultClass)
  • StoredProcedureQuery createNamedStoredProcedureQuery(java.lang.String name)
  • Query createNativeQuery(java.lang.String sqlString)
  • Query createNativeQuery(java.lang.String sqlString, java.lang.Class resultClass)
  • Query createNativeQuery(java.lang.String sqlString, java.lang.String resultSetMapping)
  • Query createQuery(CriteriaDelete deleteQuery)
  • <T> TypedQuery<T> createQuery(CriteriaQuery<T> criteriaQuery)
  • Query createQuery(CriteriaUpdate updateQuery)
  • Query createQuery(java.lang.String qlString)
  • <T> TypedQuery<T> createQuery(java.lang.String qlString, java.lang.Class<T> resultClass)
  • StoredProcedureQuery createStoredProcedureQuery(java.lang.String procedureName)
  • StoredProcedureQuery createStoredProcedureQuery(java.lang.String procedureName, java.lang.Class… resultClasses)
  • StoredProcedureQuery createStoredProcedureQuery(java.lang.String procedureName, java.lang.String… resultSetMappings)
  • CriteriaBuilder getCriteriaBuilder()

Entity Graph operations

  • <T> EntityGraph<T> createEntityGraph(java.lang.Class<T> rootType)
  • EntityGraph<?> createEntityGraph(java.lang.String graphName)
  • EntityGraph<?> getEntityGraph(java.lang.String graphName)
  • <T> java.util.List<EntityGraph<? super T>> getEntityGraphs(java.lang.Class<T> entityClass)

Transaction operations

  • <T> T getReference(java.lang.Class<T> entityClass, java.lang.Object primaryKey)
  • EntityTransaction getTransaction()
  • boolean isJoinedToTransaction()
  • void joinTransaction()

Lock operations

  • void lock(java.lang.Object entity, LockModeType lockMode)
  • void lock(java.lang.Object entity, LockModeType lockMode, java.util.Map<java.lang.String,java.lang.Object> properties)

Miscellaneous

  • java.lang.Object getDelegate()
  • EntityManagerFactory getEntityManagerFactory()
  • FlushModeType getFlushMode()
  • LockModeType getLockMode(java.lang.Object entity)
  • Metamodel getMetamodel()
  • java.util.Map<java.lang.String,java.lang.Object getProperties()
  • void setFlushMode(FlushModeType flushMode)
  • void setProperty(java.lang.String propertyName, java.lang.Object value)
  • <T> T unwrap(java.lang.Class<T> cls)

Posted in Java EE | Tagged , , , | Leave a comment

Custom Security Context in JAX-RS

And the JAX-RS juggernaut continues ….

This blog briefly talks about how to override the default security related information associated with a JAX-RS request i.e. how to mess with the SecurityContext

Wait.. Security Context ?

  • Think of it as a JAX-RS abstraction over HTTPServletRequest for security related information only
  • Can be used for
    • figuring out how the caller was authenticated
    • extracting authenticated Principal info
    • role membership confirmation (programmatic authorization)
    • and whether or not the request was initiated securely (over HTTPS)

Ok, but why would I need a custom implementation ?

It helps when you have a custom authentication mechanism not implemented using standard Java EE security realm

  • your web container will not be aware of the authentication details
  • as a result, the SecurityContext instance will not contain the subject, role and other details (mentioned above)
  • a typical example is token based authentication based on custom (app specific) HTTP headers

Your RESTful application would definitely want to make use of the authenticated caller

  • the JAX-RS request pipeline needs to be aware of the associated ‘security context’
  • make use of it within its business logic

How to…

SecurityContext is an interface after all..

  • just implement it
  • inject it (using @Context) and use it in your resource methods

 

Cheers!

Posted in Java EE | Tagged , , , | Leave a comment

Asynchronous JAX-RS: basics & gotchas

This blog post covers

Man, I tend to blog a lot about JAX-RS and REST !

Basics of server side async JAX-RS

On the server side, asynchronous behaviour is driven by

  • @Suspended: annotation which instructs the container to inject an instance of AsyncResponse and invoke the method asynchronously
  • AsyncResponse: bridge between the application logic and the client request

Since we have clearly expressed our asynchronous requirements, the container will ensure that

  • the calling thread is released
  • the actual business logic is executed in a different thread (in this case its the thread pool taken care of the by the Managed Executor Service in the Java EE container – thanks to Concurrency Utilties in Java EE 7)

Things to watch out for .. a.k.a gotchas

Although the calling (request) thread is released, the underlying I/O thread still blocks until the processing in background thread continues.In the above example, the caller would have to wait 5 seconds since that’s the delay we have purposefully introduced within the code. In simple words, the client (e.g. browser executing a HTTP GET) keeps waiting  until the business logic execution is finished by calling the resume method of the injected AsynResponse object (remember, it’s the bridge b/w the application & the client).

Timeouts to the rescue

One can specify a time out period after which the client gets back a HTTP 503 Service Unavailable response (default convention)

Fine grained time outs

The default behaviour (HTTP 503 on time out) might not be suitable for all use cases. For example, you might want to implement a solution where a tracking identifier needs to be sent to the client (for future) if the actual processing does not finish in due time (before timeout triggers). Having the ability to send a custom HTTP response on time out can prove useful. The AsyncResponse API makes this possible via the notion of a time out handler. You can do this by

  • a direct HTTP response (see below example)
  • via an exception (by passing an instance of Throwable to AsyncResponse#resume)

Client side async using the JAX-RS Client API

Using asynchronous behaviour on the client side is pretty easy. All you need to do is obtain an instance of AsyncInvoker by calling async on the Invocation.Builder

Above gotchas applicable here

As you might have already observed, async behaviour in (server side) JAX-RS is not the same as in other typical async APIs i.e. the client is still blocked.

  • You should use the async method (as demonstrated above) to call a server side REST API in an async manner even if the server REST API itself is asynchronous in nature (implemented using @Suspended AsyncResponse) .

I repeat: do not be under the impression that just because the server API is async, your client thread will return immediately

  • The call to async returns an instance of Future object – and you might already know, the get method (of Future)  blocks. So use it with care and at the correct point in your application logic

Further reading

That’s all. Be async. Be safe

Cheers!

 

Posted in Java EE | Tagged , , , , | Leave a comment

Efficient JAX-RS: Conditional GETs & PUTs

This post discusses how to leverage features in the JAX-RS API to execute RESTful operations based on conditions/criteria in order to aid with scalability and performance. It covers

  • which HTTP headers are involved
  • which JAX-RS APIs to use
  • details of the entire request-response flow

Required components

Must know HTTP headers

It would be awesome if you have a basic understanding of (at least some of) these HTTP headers (since these form an important part of the JAX-RS feature discussed in this post). These are best referred from the official HTTP specification document

  • Cache-Control
  • Expires
  • Last-Modified
  • If-Modified-Since
  • If-Unmodified-Since
  • ETag
  • If-None-Match

http-headers-rfc-2616

JAX-RS APIs

  • CacheControl: Again, just a simple class. Why not read one of my existing blog posts on this topic ?
  • EntityTag: JAX-RS equivalent (simple class) of the HTTP ETag header
  • Request: the main API which contains utility methods to evaluate the conditions which in turn determine the criteria for access

What are we trying to achieve ?

A simple interaction with a JAX-RS service can be as follows

  • Client sends a GET request
  • Server replies back with the requested resource (with a HTTP 200 status)
  • It also sends the Cache-Control & Last-Modified headers in response

Cache-Control defines the expiration semantics (along with other fine grained details) for the resource on the basis of which the client would want to

  • revalidate it’s cache i.e. invoke the GET operation for same resource (again)
  • make sure it does so in an efficient/scalable/economic manner i.e. not repeat the same process of exchanging data (resource info) if there are no changes to the information that has been requested

Common sense stuff right ?

Let’s look at how we can achieve this

Option 1

Leverage the Last-Modified and If-Modified-Since headers

 

  • Server sends the Cache-Control & Last-Modified headers as a response (for a GET request)
  • In an attempt to refresh/revalidate it’s cache, the client sends the value of the Last-Modified header in the If-Modified-Since header when requesting for the resource in a subsequent request
  • Request#evaluatePreconditions(Date) determines whether or not the value passed in the If-Modified-Since header is the same as the date passed to the method (ideally the modified date would need to extracted from somewhere and passed on this method)

(slightly) advanced usage

ETag header in action

 

  • In addition to the Last-Modified header, the server can also set the ETag header value to a string which uniquely identifies the resource and changes when it changes e.g. a hash/digest
  • client sends the value of the ETag header in the If-None-Match header when requesting for the resource in a subsequent request
  • and then its over to the Request#evaluatePreconditions(EntityTag)

Note: With the Request#evaluatePreconditions(Date,EntityTag) the client can use both last modified date as well as the ETag values for criteria determination. This would require the client to set the If-Modified-Since header

Making use of the API response…

In both the scenarios

  • if the Request#evaluatePreconditions method returns null, this means that the pre-conditions were met (the resource was modified since a specific time stamp and/or the entity tag representing the resource does not match the specific ETag header) and the latest version of the resource must be fetched and sent back to the client
  • otherwise, a HTTP 304 (Not Modified) response is automatically returned by the Request#evaluatePreconditions method, which can be returned as is

Please note …

  • Choice of ETag: this needs to be done carefully and depends on the dynamics of your application. What are the attributes of your resource whose changes are critical for your clients ? Those are the ones which you should use within your ETag implementation
  • Not a magic bullet: based on the precondition evaluation, you can help prevent unnecessary exchange of data b/w client and your REST service layer, but not between your JAX-RS service and the backend repository (e.g. a database). It’s important to understand this

Can I only improve my GETs …?

No ! the HTTP spec cares abut PUT operations as well; and so does the JAX-RS spec:-)

 

  • Server sends the Cache-Control & Last-Modified headers as a response (for a GET request)
  • In an attempt to send an updated value of the resource, the client sends the value of the Last-Modified header in the If-Unmodified-Since header
  • Request#evaluatePreconditions(Date) determines whether or not the value passed in the If-Unmodified-Since header is the same as the date passed to the method (in your implementation)

So the essence is..

  • If the API returns a non null response, this means that the pre-conditions were not met (HTTP 412) i.e. the resource was in fact modified after the time stamp sent in the If-Unmodified-Since header, which of course means that the caller has a (potentially) stale (outdated) version of the resource
  • Otherwise (for a null output from the API), its a hint for the client to go ahead and execute the update operation
  • In this scenario, what you end up saving is the cost of update operation executed against your database in case the client’s version of the resource is outdated

Further reading

Cheers!

Posted in Java EE | Tagged , , , | 3 Comments

JAX-RS, JWT & a pinch of JSR 375

This is another version of my previous blog on JAX-RS and JWT which includes a pinch of Java EE Security API (new JSR in Java EE 8). In case you are completely new to JSR 375, please jump to the last section of this blog and use the resources listed there

But, what’s new ?

Uses the following features powered by the draft JSR 375 implementation available here

  • HTTP Basic Authentication
  • an Embedded Identity Store

Changes made…

  • No need to define the actual realm, user and groups in the application server security configuration. The container realm used to act as the identity/credential store. This was replaced by implementation of an Embedded Identity Store by JSR 375. All that was required is the declaration of @EmbeddedIdentityStoreDefinition

jsr-375-annotations-in-action

 

Note: Java EE Security API also provides options for Database and LDAP as Identity Stores

  • POM changes: include the JSR 375 API and its RI

 More on JSR 375

Cheers!

 

 

Posted in Java EE | Tagged , , , , , , , | Leave a comment

JSON Web Token in action with JAX-RS

This post is about using JSON Web Token (JWT) with JAX-RS

It covers

  • Real quick intro to JWT
  • Shows how to use it with JAX-RS (for authentication) with an example

Also

Brief intro to JWT

  • A standard defined by RFC 7519
  • Used to exchange claims
  • Has a pre-defined structure

Anatomy of a JWT

It consists of three parts

  • Header: consists of info like signature mechanism, token type etc.
  • Body (Claims): the meat of the payload
  • Signature: signature of the contents to protect against tampered/malicious JWTs

These three components come together to form the actual token

Benefits

  • Useful for implementing Stateless authentication
  • Compact: less verbose compared to other counterparts like SAML)
  • Flexible: Although its backed by a standard, you are free to choose your signature, claim attributes etc.

Please note that…

  • JWT is not only an authentication mechanism. It’s more about information exchange & it’s usage is limited by your imagination
  • It’s signed, not encrypted: its contents can be picked up over the wire if you do not secure your transport layer (e.g. using HTTPS)

Using JWT with JAX-RS

Let’s look at an example of how we might use JWT in a JAX-RS based application. As stated earlier, this sample uses JWT as a stateless authentication token. The process is split into distinct steps

Getting hold of the JWT

Why do we need a JWT in the first place? It is because the JAX-RS resource is protected and its access is dependent on the presence of a JWT token within the HTTP request (this is achieved by a JAX-RS filter)

Think of JWT as a proxy to the actual username/password (or any other authentication criteria) for your application. You need to actually authenticate using the method required by your application in order to get access to the JWT. In this example, a successfully executed HTTP Basic authentication is the gateway to the token

This is what happens

  1. The application executes a GET request to the URL http://<host&gt;:<port>/<context-root>/auth/token with the HTTP Authorization header containing user credentials
  2. HTTP Basic authentication kicks in. This is enforced by the web.xml (snippet below) which ensures that any request to the /auth/* is not allowed to pass unauthenticated
  3. In case of a successful authentication, the JWT is returned in the HTTP response header

Here is an excerpt form the web.xml

web_xml_snippet

Quick review of JWT creation code and its result

 

JWT in action

  • The JWT is sent by app in the subsequent request for the JAX-RS resource i.e.http:<host>:<port>/<context-root>/resources/books
  • The JAX-RS Container Request Filter kicks in – it checks for the presence of the JWT , verifies it. The verification process implicitly checks for presence of the required claim attributes as well as the signature validation

JWT verification snippet

  • It allows the request to go through in case of successful verification, otherwise, the filter returns a HTTP 401 Unauthorized response to the client
  • A container response filter ensures that the JWT is added as a part of the response header again. It only does so when the JWT verification was successful – this is made possible using the contextual state/information sharing feature provided by JAX-RS Request Filters

Other considerations

Choice of claim attributes

In this example, we just used the standard sub (subject) attribute in the claim. You are free to use others. I would highly recommend reading section 4 of the JWT RFC for deeper insight

jwt_rfc_doc_claims_section

JWT expiration

One should also consider expiring the JWT token after a finite time. You would need to

  • Make use of the exp claim attribute (standard)
  • Think about refreshing the JWT token (after expiry)

Revisiting the Stateless paradigm..

Although the initial authentication was executed using HTTP Basic, the application does not rely on a Session ID for authorising subsequent requests from the same user. This has the following implications

  • There is no need to store the session ID on the server side
  • There is no need to sync this session ID to multiple application nodes in a cluster

As stated above, JWT is helping us with Stateless authentication (it is not very different from the HTTP protocol itself)

  • Our JWT contains all the required data (claim) for the conversation (in this case authentication)
  • We pass the token with each HTTP request (only to access resources which are protected by the JWT to begin with)
  • The application does not need to repetitively authenticate the user (via the username-password combo)

Now we can scale:-)

You can have multiple instances (horizontally scaled across various nodes/clusters) of your JAX-RS service and yet you need not sync the state of the token between various nodes. If a subsequent request goes to different node than the previous request, the authentication will still happen (provided you pass the JWT token)

Using the sample project

If you want to play around with the example, please follow hese steps

  • Get the maven project and build it (same old maven clean install)
  • Deploy on a Java EE 7 container
  • Tweak your server security options to protect it using a realm named file and ensure that you include the members under the users group. Both these constraints are dictated by the web.xml descriptor (see above) – you can also choose to modify it as per your choice. Here is a snapshot from the Payara server

test-jwt-snippet-3

  • Issue a HTTP GET to http://localhost:8080/jax-rs-with-jwt/auth/token
  • Copy the token in the HTTP response header (jwt)

test-jwt-snippet-1

  • Issue a GET request to http://localhost:8080/jax-rs-with-jwt/resources/books and include the JWT in the HTTP Authorization header (prepend it with Bearer)

test-jwt-snippet-2

 

I am sure there are lots of other uses of JWT itself. Hopefully this gives a decent starting point to using them within your JAX-RS services

Cheers!

Posted in Java EE | Tagged , , , , , , | 4 Comments

Sharing data between JAX-RS filters

This is a quick post which points out how to share contextual user-defined (custom) data between JAX-RS filters

Filter execution

  • It is chain based: one filter gets executed after another
  • Request filters are executed before Response filters
  • If a filter throws an exception, the chain breaks and other filters are skipped i.e. an exception from a Request filter will auto-abort all other Request filters. The same is applicable to Response filters

For more info, please do check out one of my existing blog posts which discussed JAX-RS server side processing pipeline in depth

Sharing data b/w filters

JAX-RS API enables sharing of user-defined data amongst filters associated with a particular request

  • It is abstracted in the form of a Map<String,Object> (pretty natural choice) via the ContainerRequestContext interface
  • Get all the custom properties using the getPropertyNames() method
  • The value of a specific property can be fetched (from the Map) using getProperty(String name)
  • Overwrite an existing property or a add a new one using setProperty(String name, Object val)

Examples

Here is how multiple Request filters can share user-defined contextual data amongst themselves

Another example where a Response filter uses the contextual data set by a Request filter

To be noted…

The same capability is available in the Client side JAX-RS filters as well. The only difference is that you would be interacting with an instance of the ClientRequestContext

Further reading

Cheers !

Posted in Java EE | Tagged , , , | 4 Comments

Binding strategies for JAX-RS filters and interceptors

JAX-RS 2.0 defines multiple ways using which server side filters and interceptors can be bound to their target components.

  • Global Binding
  • Named Binding
  • Dynamic Binding

Global Binding

By default, JAX-RS filters and interceptors are bound to all the methods of resource classes in an application. That is, both request (pre and post) and response filters will be invoked whenever any resource method is invoked in response to a HTTP request by the client. This convention can be overridden using named binding or dynamic binding.

Named Binding

Filters and interceptors scoping can be handled in a fine-grained manner (based on per resource class/method)

 

NoteIf it is applied to a class, the filter/interceptor will be bound to all its resource methods

Dynamic Binding

JAX-RS provides the DynamicFeature interface to help bind filters and interceptors dynamically at runtime. They can be used in tandem with the more static way of binding made possible using@NamedBinding

The injected instance of the ResourceInfo interface helps you choose the resource method in dynamic fashion by exposing various methods and the FeatureContext interface allows us to register the filter or interceptor once the resource method has been selected.

For more on JAX-RS 2.0 …

Cheers!

Posted in Java EE | Tagged , , | 8 Comments

Basics of security in Oracle Mobile Cloud Service..

This blog post covers the following security aspects of the Oracle Mobile Cloud service platform in brief

  • The security features
  • It’s foundations
  • Supported mechanisms (protocols)

What are the security features ?

Oracle MCS supports the following

  • Authentication: verifying the identity (and associated credentials) of a mobile app user
  • Authorization: restricting the access arena of the authenticated mobile app user to a set of resources configured for his.her role
  • Identity propagation: ability to pass on security context of authenticated users to external systems (APIs, services)

Building blocks

Authorization, authentication and user management capabilities are powered by the following core components

  • Users: valid users of your mobile apps
  • Roles: they help define permissions/privileges for your mobile app users
  • Realms: container for user information (including credentials) and associated roles
  • Mobile Backend: a container for resources to be used by the mobile apps i.e. APIs and related associations such as realms, storage collections etc.

Wait.. what are we protecting ?

In MCS, (almost) everything flows via the Mobile Backend. The protected artefacts are

  • Platform APIs: exposes a rich set of features – user management, storage, notification, device registration, offline data, analytics, database access & management, application configuration
  • Custom APIs: you can build your own set of APIs and expose them via RESTful end points (based on JavaScript and Node.js)
  • Connector APIs: a facade layer on top of heterogenous external systems/service/endpoints (REST, SOAP, cloud/on-premise applications etc.)

Simple flow

An end user uses the mobile app feature which in turn invokes the APIs configured within the Mobile Backend which is linked to the particular mobile app. The authentication and authorization is taken care of by the realm associated with the Mobile Backend

Access gateways for MCS resources

Mobile apps access core MCS backend resources using

  • REST API: MCS features/platform APIs have a RESTful interface for HTTP based clients
  • Platform specific SDK (Android, iOS, Windows, JavaScript): makes it easy for mobile app developers to use the MCS Platform features (mentioned above) infrastructure and things like authentication etc. are handled in a seamless manner

Inbound Authentication support

Invocations triggered via mobile apps pass through the MCS backend layer which are protected using the below mentioned techniques

  • HTTP Basic: send the Authorization header with the base 64 encoded username and password information as well as an additional Oracle-Mobile-Backend-ID header which consists of the ID of the Mobile Backend to which the resource (API) is associated with
  • OAuth: a combination of the (pre configured) OAuth client ID & secret along with (optional) username & password combination is required to fetch the OAuth token which is then sent to the configured OAuth endpoint

Here is an example showing a simple HTTP GET request (to fetch information for user jdoe) invoked at a REST endpoint and the authorization headers in action

Difference b/w OAuth and HTTP Basic

The following are the differences (in the context of Oracle MCS)

  • For OAuth, the Base64 encode username-password combo is replaced by the OAuth token and is prepended with Bearer e.g. Authorization: Bearer <my-oauth-token-007>
  • Also, the Oracle-Mobile-Backend-ID header is not required in case of OAuth mode

Anonymous login

If you do not want to leverage username & password combination, you can just configure your mobile backend to use an anonymous token which can then be passed by the mobile app (client). This is applicable for HTTP Basic authentication

Inbound Authorization

Authorization revolves around user-role memberships which itself is defined within a realm. The Mobile Backend allows for configuration where one can specify which roles are allowed to access which Custom API endpoints i.e. one can define a permission based access model with the help of roles e.g. users belonging to PREMIUM role can access advanced features while others cannot

Outbound Identity Propagation

Oracle MCS provides the capability to propagate (authenticated) identity information while interacting with external services. As mentioned above, Connector APIs help facilitate this. They are available in three flavors, each of which cater to a different category of service

  • REST Connector APIs – facade over external REST services
  • SOAP Connector API – layer on top of external SOAP endpoints
  • ICS Connector API – helps integrate with other cloud as well as on-premise services

External services invoked by the above mentioned components might have their custom security restrictions. Oracle MCS provides abstracts this with the help of Oracle Web Service Manager strategies/policies which can be declaratively applied on top your connector APIs

  • HTTP Basic header
  • SAML token
  • WSS UserName token

Note: There might be different sub-types of the above mentioned policies which result in the multiple permutations and combinations e.g. HTTP basic over SSL, SAML 2.0 token, WSS username token over SSL etc. 

There are a lot of details which were omitted, but hopefully, this helps get an overview of security basics of Oracle MCS along with some of its related features

Cheers!

Posted in Java, Oracle Cloud, Oracle Mobile Cloud Service, Oracle PaaS | Tagged , , | Leave a comment