CAS
2019-09-04 10:11:03 0 举报AI智能生成
CAS
作者其他创作
大纲/内容
Architecture
System Components
CAS Server
authenticate users
grant access to CAS-enabled services (CAS clients)
CAS Client
Supported Protocols
CAS (versions 1,2 and 3)
SAML 1.1 and 2
OpenID Connect
OpenID
OAuth 2.0
WS Federation
Software Components
describe the CAS server in terms of three Layered subsystems
Web (Spring MVC/Spring Webflow)
The Web tier is the endpoint for communication with all external systems including CAS clients
The Web tier delegates to the ticketing subsystem to generate tickets for CAS client access
Ticketing
generate tickets for CAS client access on successful anthentication
the ticketing subsystem frequently delegates to the authentication subsystem
Authentication
deployment
Overlay
advantages
There is no need to download/build from the source
Upgrades are tremendously easier in most cases by simply adjusting the build script to download the newer CAS release
Rather than hosting the entire software source code, as the deployer you ONLY keep your own local customizations which makes change tracking much easier
Tracking changes inside a source control repository is very lightweight, again simply because only relevant changes (and not the entire software) is managed
working with an overlay
Start with and build the provided basic vanilla build/deployment
Identify the artifacts from the produced build that need changes.These artifacts are generally produced by the build in the target or build directory for Maven
Copy the identified artifacts from the identified above directories over to the src directory
Create the src directory and all of its chuldren,if they don't already exist
Copied paths and file names MUST EXACTLY MATCH their build counterparts,or the change won't take effect.
After changes, rebuild and repeat the process as many times as possible
Double check your changes inside the built binary artifact to make sure the overlay process is working
Configuration
Properties passed to the CAS web application are considered in the following order
1. Command line arguments,starting with -- (e.g. --server.port=9000)
2. Properties from SPRING_APPLICATION_JSON (inline JSON embedded in an environment variable/system property)
3. JNDI attributes from java:comp/env
4. Java System properties
5. OS environment variables
6. Configuration files (i.e. application.properties|yml) indicated by the configuration server and profile
Configuration Server
Standalone
Spring Cloud
reloading changes
Authentication
the CAS authentication process is primarily controlled by an authentication manager,which orchestrates a collection of authentication handlers
Authentication Manager
performs authentication according to the following contract for any given credential
1. Iterate over all configured authentication handlers
2. Attempt to authenticate a credential if a handler supports it
3. On success attempt to resolve a principal
4. Check whether a resolver is configured for the handler that authenticated the credential
5. If a suitable resolver is found, attempt to resolve the principal
6. If a suitable resolver is not found, use the principal resolved by the authentication handler
7. Check whether the security policy (e.g. any,all) is satisfied
8. If security policy is met return immediately
9. Continue if security policy is not met
10. After all credentials have been attermpted check security policy again and throw AuthenticationException if not satisfied
Authentication Handlers
Authentication Sequence
adopters can assign an order value to an authentication handler thereby explicitly positioning it in the collection and controlling its execution sequence
Naming Strategy
Each authentication handler in CAS can be named via CAS settings and if left undefined, the short name of the handler component itself is used
Authentication Policy
Policies in general control the following
Should the authentication chain be stopped after a certain kind of authentication failure ?
Given multiple authentication handlers in a chain, what constitutes a successful authentication event?
Policies are typically activated after
An authentication failure has occurred
The authentication chain has finished execution
Typical use cases of authentication policies may include
Enforce a specific authentication’s successful execution, for the entire authentication event to be considered successful.
Ensure a specific class of failure is not evident in the authentication chain’s execution log
Ensure that all authentication schemes in the chain are executed successfully, for the entire authentication event to be considered successful.
Principal Resolution
Principal resolution converts information in the authentication credential into a security principal that commonly contains additional metadata attributes (i.e. user details such as affiliations, group membership, email, display name).
Methods
LDAP
Database
Apache Shiro
JWT
REST
MongoDb
Custom
So on ....
Delegated Authentication
CAS servers
OAuth2 providers
OpenID providers
So on ..
Throttling Authentication Attempts
IP Address
IP Address and Username
0 条评论
下一页
