On Wed, May 31, 2017 at 10:38 AM, Ruwan Abeykoon <ruw...@wso2.com> wrote:
> > Hi Prabath, > > >> Please check whether my understanding is correct based on the following >> mail.. >> >> 1. We define set of ACR values at the framework level - which are >> agnostic to the inbound protocols. >> 2. Each inbound protocol (OIDC, SAML) - can define their own ACR values - >> but must be mapped to the ACR values defined at the framework level. >> 3. Each ACR value will represent a set of authenticators (or steps) - I >> guess your Table-2 is representing that. >> > Yes. > > > >> 1. If you take OIDC as an example, you can send multiple acr_values in >> the request (space separated - and by preference). I would suggest the >> protocol specific component will pick one out of that - and will pass the >> mapped ACR value to the framework - and the same will be included in the >> response as the value of the acr parameter. >> 2. Once the user is authenticated, the framework will return back the >> authenticators used in each step. Once again the protocol specific >> component has to match these to corresponding AMR values and send back to >> the service provider. >> >> Few suggestions.. >> >> 1. IMO we should let each service provider define multiple authentication >> chains - and one would be the default one (so this will not break the >> current behavior). >> 2. Each chain can be associated with one or more ACR values. >> 3. Right now the authentication chain corresponding to a service provider >> is loaded by its name. But with this design it will be by the name and the >> ACR value. >> > > I will change the architecture with above suggestions. > Yes +1 above changes. IMO; If we are going to achieve actual adaptive authentication, we may need to specially consider about the end user. First end user must be validated & based on the user, we may need to decide the authenticators & also the based on the first steps, second step must be decided. However; I assume that still we have above interface to extend & decide the given authentication chains in customer manner (without the SP given ACR) Thanks, Asela. > > >> >> This will require minimal changes at the framework level. >> >> Also - let's keep adaptive authentication out of this. We can address >> that separately - and I don't think we need to have it for IS 5.5.0. >> >> Noted. I will create new mail thread specific to ACR and AMR and continue > discussion with updated architecture. > > Cheers, > Ruwan > > > On Wed, May 31, 2017 at 3:59 AM, Prabath Siriwardena <prab...@wso2.com> > wrote: > >> Hi Ruwan, >> >> Please check whether my understanding is correct based on the following >> mail.. >> >> 1. We define set of ACR values at the framework level - which are >> agnostic to the inbound protocols. >> 2. Each inbound protocol (OIDC, SAML) - can define their own ACR values - >> but must be mapped to the ACR values defined at the framework level. >> 3. Each ACR value will represent a set of authenticators (or steps) - I >> guess your Table-2 is representing that. >> > Few other things I assume we should be doing (not clearly mentioned in the >> mail).. >> >> > >> 1. If you take OIDC as an example, you can send multiple acr_values in >> the request (space separated - and by preference). I would suggest the >> protocol specific component will pick one out of that - and will pass the >> mapped ACR value to the framework - and the same will be included in the >> response as the value of the acr parameter. >> 2. Once the user is authenticated, the framework will return back the >> authenticators used in each step. Once again the protocol specific >> component has to match these to corresponding AMR values and send back to >> the service provider. >> >> Few suggestions.. >> >> 1. IMO we should let each service provider define multiple authentication >> chains - and one would be the default one (so this will not break the >> current behavior). >> 2. Each chain can be associated with one or more ACR values. >> 3. Right now the authentication chain corresponding to a service provider >> is loaded by its name. But with this design it will be by the name and the >> ACR value. >> >> This will require minimal changes at the framework level. >> >> Also - let's keep adaptive authentication out of this. We can address >> that separately - and I don't think we need to have it for IS 5.5.0. >> >> Thanks & regards, >> -Prabath >> >> >> On Thu, May 25, 2017 at 12:34 AM, Ruwan Abeykoon <ruw...@wso2.com> wrote: >> >>> Hi All, >>> I plan to add the Adaptive authentication on IS. Please provide your >>> feedback on the architecture bellow. >>> >>> References: >>> http://openid.net/specs/openid-connect-core-1_0.html#Authori >>> zationEndpoint >>> https://tools.ietf.org/html/draft-ietf-oauth-amr-values-02 >>> >>> >>> Architecture >>> >>> * <https://www.draw.io/#G0B0bx735ZWbanTEZRQW8zcGFsanc> Figure 1: >>> Framework and Endpoints Authentication Context Class Reference(ACR)* >>> >>> >>> >>> >>> >>> >>> >>> >>> *Different protocols may support different values for ACR. Hence We >>> provide two levels of mapping from protocol based ACR to internal >>> authenticators. 1. Protocol ACR values to Internal ACR valuesThis is a map >>> between external(protocol or customer specific) ACR values to internal >>> representation. This is a key-value pair. Both the key and value are >>> arbitrary Strings. 1. Internal ACR values vs supported Authenticators >>> table. This is a table specifying which “internal ACR” are supported by >>> each “Authenticator”.The Authenticator may be internal authenticator or a >>> federated authenticator. This may be a custom built authenticator or may be >>> installed as a connector. These two information will be added to >>> “identity.xml”, as XML Info-set. These configurations are per server, and >>> can not be changed per tenant >>> basis. OAuthexternalinternal pwdpassword otpsmsotp smssmsotp hwkfido Table >>> 1: ACR mapping based on protocol Note that the “external” value in the >>> above table may be a URI.E.g. >>> urn:oasis:names:tc:SAML:2.0:ac:classes:Password >>> urn:oasis:names:tc:SAML:2.0:ac:classes:X509 >>> urn:federation:authentication:windows >>> urn:oasis:names:tc:SAML:2.0:ac:classes:Kerberos >>> Autnenticator basiciwafidooauth-bearersamlssopasswordY Ysmsotp >>> fido Y Table >>> 2: ACR mapping internal-ACR to Authenticator *Implementation >>> >>> It is the responsibility of the relevant endpoint to decide if ACR is >>> requested at the protocol level and add them into AuthenticatonContext. >>> AutnenticationContext will be enhanced by adding new methods. >>> >>> >>> >>> public void setAcr(List<String> acrRequested); >>> >>> public void setAcrRule(AcrRule acrRule) >>> >>> >>> >>> enum AcrRule { >>> >>> EXACT, >>> >>> MINIMUM, >>> >>> MAXIMUM, >>> >>> BETTER >>> >>> } >>> >>> >>> As of IS 5.3.0, Authentication Sequence is built via >>> FileBasedConfigurationBuilder >>> And UIBasedConfigurationBuilder. A new AdaptiveConfigurationBuilder >>> will be added to wrap the calls to both of the previous builders. The >>> Adaptive builder will examine the Authentication Context to see if there >>> are any ACR requested. If requested, the original sequence will be modified >>> according to requested ACR list. >>> >>> >>> >>> The “AdaptiveConfigurationBuilder” will use an extension mechanism, >>> which can be supplied by OSGI bundle if needed, for any change of the >>> default behaviour. For example this evaluator can be extended with >>> analytics to decide if the current login attempt is suspicious and to >>> select next level of security. >>> >>> >>> public interface AdaptiveAuthenticationEvaluator { >>> >>> >>> >>> /** >>> >>> * Evaluates if this step is applicable on the current authentication >>> context. >>> >>> .. >>> >>> */ >>> >>> boolean isApplicable(StepConfig stepConfig, AuthenticationContext >>> context); >>> >>> } >>> >>> >>> >>> The other aspects of framework remains architecturally unchanged as the >>> framework relies on the bre-bult Sequence to perform authentication >>> completion. >>> >>> >>> >>> >>> >>> Cheers, >>> >>> Ruwan >>> >>> >>> -- >>> >>> *Ruwan Abeykoon* >>> *Associate Director/Architect**,* >>> *WSO2, Inc. http://wso2.com <https://wso2.com/signature> * >>> *lean.enterprise.middleware.* >>> >>> >> >> >> -- >> Thanks & Regards, >> Prabath >> >> Twitter : @prabath >> LinkedIn : http://www.linkedin.com/in/prabathsiriwardena >> >> Mobile : +1 650 625 7950 <(650)%20625-7950> >> >> http://facilelogin.com >> > > > > -- > > *Ruwan Abeykoon* > *Associate Director/Architect**,* > *WSO2, Inc. http://wso2.com <https://wso2.com/signature> * > *lean.enterprise.middleware.* > > -- Thanks & Regards, Asela ATL Mobile : +94 777 625 933 +358 449 228 979 http://soasecurity.org/ http://xacmlinfo.org/
_______________________________________________ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
