29029be31d
* !htt #18919 #19519 Align Java HTTP server DSL with Scala This commits replaces the Java HTTP server DSL with a Java-8 centric one which exposes all scala DSL concepts to be usable from Java, including custom directives, (un)marshallers, rejections, headers, and type safety for path and query parameters. * Add RequestContext and RouteResult to Java DSL fix websockets WIP bring java docs up to date. This applies some updates to the root-level documentation * [htp] Fix java documentation to correctly mention timeouts Timeouts are configured the same in Java and Scala. Hence, linking to the scala docs for timeouts from Java. * =htc fix optionalHeaderValueByType in Java * =htt #20200 fix java testkit always using NoLogging instead logger * +htt actually run new javadsl tests, allow overriding config * =htt improve javadsl test infra with more details when fails * =htt fix bug in wrong path matcher exposed * +htp add missing remaining path matcher * =htp Java DSL cookie tests fixed * =htt Java DSL ParameterDirectivesTest fixed Protect the tweets from scalariform Incorrect response expectations in cache condition directives spec fixed * =htt Path directives for Java DSL * +!htt PathMatchers rewritten, made uniform and tests passing * Bugfix in java reject and a little test-boyscouting * Revert "Incorrect response expectations in cache condition directives spec fixed" This reverts commit cd50e89d45db010309f8249b090ea654ebb11c7a. * +htc HttpAPIsTest is compile time only, not for running Also, moved from the client package since not strictly a client test. SecurityDirectives passing Two faulty tests and two actual bugs. Fix for cache condition spec not working * Not sending in Unit instad of the implicit magnet in the test * HeaderMagnet now works as expected * Java API added for - and + on DateTime PetStore example and test fixed * Annotations to make marshalling work without default constructor * Made model class immutable Incorrect tests fixed Some scaladoc boyscouting as bonus * =htt RequestValTest sprinkled out across multiple directive tests Client ip extraction test with incorrect header name fixed. * =htt Incorrect CodingDirectivesTest fixed. * =htt Bugfix for Java Unmarshaller.firstOf and fixes to JavaRouteTest * =htt MarshallerTest fixed * Missing seal signature added to JavaDSL * More consistent (with Scala) test kit setup for Java * missing Javadocs added * Thread.sleep in default exception handler removed * =htt copy directive docs, prepare for finishing it up * +htt SecurityDirectives.authorize variants and test coverage added * +htt Custom headers in Java DSL * =htt WIP on java docs * +htp add missing parameterOrDefault directive Fixed a lot of doc warnings * =htc intense progress on javadsl docs * =htc #20470 Link to issue about docs and fix compile error compile, migration guide don't mima check http-experimental * =htt Java DSL doc warnings fixed. Only `Could not lex literal_block` ones left now * =htc fix mima settings * =doc fix MethodDirectives doc test with custom method * =htc fix coding directives spec after bad merge * =htc fix concat being corresponding to route() in javadsl * =htt Disable consistency check for route/concat as it fails only on ci server * !htt Minor fixes to PathMatchers
84 lines
3.9 KiB
ReStructuredText
84 lines
3.9 KiB
ReStructuredText
.. _SecurityDirectives-java:
|
|
|
|
SecurityDirectives
|
|
==================
|
|
|
|
.. toctree::
|
|
:maxdepth: 1
|
|
|
|
authenticateBasic
|
|
authenticateBasicAsync
|
|
authenticateBasicPF
|
|
authenticateBasicPFAsync
|
|
authenticateOrRejectWithChallenge
|
|
authenticateOAuth2
|
|
authenticateOAuth2Async
|
|
authenticateOAuth2PF
|
|
authenticateOAuth2PFAsync
|
|
authenticateOrRejectWithChallenge
|
|
authorize
|
|
authorizeAsync
|
|
extractCredentials
|
|
|
|
|
|
.. _authentication-vs-authorization-java:
|
|
|
|
Authentication vs. Authorization
|
|
--------------------------------
|
|
|
|
**Authentication** is the process of establishing a known identity for the user, whereby 'identity' is defined in the
|
|
context of the application. This may be done with a username/password combination, a cookie, a pre-defined IP or some
|
|
other mechanism. After authentication the system believes that it knows who the user is.
|
|
|
|
**Authorization** is the process of determining, whether a given user is allowed access to a given resource or not. In
|
|
most cases, in order to be able to authorize a user (i.e. allow access to some part of the system) the users identity
|
|
must already have been established, i.e. he/she must have been authenticated. Without prior authentication the
|
|
authorization would have to be very crude, e.g. "allow access for *all* users" or "allow access for *noone*". Only after
|
|
authentication will it be possible to, e.g., "allow access to the statistics resource for *admins*, but not for regular
|
|
*members*".
|
|
|
|
Authentication and authorization may happen at the same time, e.g. when everyone who can properly be authenticated is
|
|
also allowed access (which is often a very simple and somewhat implicit authorization logic). In other cases the
|
|
system might have one mechanism for authentication (e.g. establishing user identity via an LDAP lookup) and another one
|
|
for authorization (e.g. a database lookup for retrieving user access rights).
|
|
|
|
|
|
Authentication and Authorization in HTTP
|
|
----------------------------------------
|
|
|
|
HTTP provides a general framework for access control and authentication, via an extensible set of challenge-response
|
|
authentication schemes, which can be used by a server to challenge a client request and by a client to provide
|
|
authentication information. The general mechanism is defined in `RFC 7235`_.
|
|
|
|
The "HTTP Authentication Scheme Registry" defines the namespace for the authentication schemes in challenges and
|
|
credentials. You can see the currently registered schemes at http://www.iana.org/assignments/http-authschemes.
|
|
|
|
At this point Akka HTTP only implements the "'Basic' HTTP Authentication Scheme" whose most current specification can be
|
|
found here: https://datatracker.ietf.org/doc/draft-ietf-httpauth-basicauth-update/.
|
|
|
|
.. _RFC 7235: http://tools.ietf.org/html/rfc7235
|
|
|
|
Low-level OAuth2 "Bearer Token" directives
|
|
------------------------------------------
|
|
The OAuth2 directives currently provided in Akka HTTP are not a full OAuth2 protocol implementation,
|
|
they are only a means of extracting the so called ``Bearer Token`` from the ``Authorization`` HTTP Header,
|
|
as defined in `RFC 6750`_, and allow users to validate and complete the protocol.
|
|
|
|
.. _RFC 6750: https://tools.ietf.org/html/rfc6750
|
|
|
|
|
|
.. _credentials-and-timing-attacks-java:
|
|
|
|
Credentials and password timing attacks
|
|
---------------------------------------
|
|
|
|
When transforming request ``Credentials`` into an application specific user identifier the naive solution for
|
|
checking the secret (password) would be a regular string comparison, but doing this would open up the application to
|
|
timing attacks. See for example `Timing Attacks Explained`_ for an explanation of the problem.
|
|
|
|
.. _Timing Attacks Explained: http://emerose.com/timing-attacks-explained
|
|
|
|
To protect users of the library from that mistake the secret is not available through the API, instead the method
|
|
``Credentials.Provided.verify(String)`` should be used. It does a constant time comparison rather than returning early
|
|
upon finding the first non-equal character.
|
|
|