Refining the authentication process
Hi all, Currently the authentication process is kind of broken and should be fixed. See the concept page Authentication Initiation [1]. In essence the problem is, that authentication can only be initiated by visiting special authentication pages explicitly or by being redirected. Servlets and scripts (e.g. a 404/NOT FOUND error handler) cannot easily initiate authentication without knowing the URL to the login page. I propose to create a new service interface Authenticator, which is implemented by the existing SlingAuthenticator class (both in the o.a.sling.engine bundle). This interface has a requestAuthentication method, which may be used to initiate authentication from within servlets or scripts and have the requestAuthentication method of the appropriate handler be called for the current request. In addition, the sling:authRequestLogin parameter supported by the HTTP Basic authentication handler should actually be handled by the SlingAuthenticator. This enables any client to initiate authentication by just specifying this parameter and have the SlingAuthenticator call the requestAuthentication method of the appropriate handler be called for the request. This makes the whole authentication initiation process much more transparent and allows for better alignment of login forms to the authentication handlers they are intended to work with. WDYT ? Regards Felix [1] http://cwiki.apache.org/SLING/authentication-initiation.html
Refining the authentication process
Hi all, Currently the authentication process is kind of broken and should be fixed. See the concept page Authentication Initiation [1]. In essence the problem is, that authentication can only be initiated by visiting special authentication pages explicitly or by being redirected. Servlets and scripts (e.g. a 404/NOT FOUND error handler) cannot easily initiate authentication without knowing the URL to the login page. I propose to create a new service interface Authenticator, which is implemented by the existing SlingAuthenticator class (both in the o.a.sling.engine bundle). This interface has a requestAuthentication method, which may be used to initiate authentication from within servlets or scripts and have the requestAuthentication method of the appropriate handler be called for the current request. In addition, the sling:authRequestLogin parameter supported by the HTTP Basic authentication handler should actually be handled by the SlingAuthenticator. This enables any client to initiate authentication by just specifying this parameter and have the SlingAuthenticator call the requestAuthentication method of the appropriate handler be called for the request. This makes the whole authentication initiation process much more transparent and allows for better alignment of login forms to the authentication handlers they are intended to work with. WDYT ? Regards Felix [1] http://cwiki.apache.org/SLING/authentication-initiation.html PS: Sorry, if this comes in as duplicate, but I suspect the first mail got eaten somewhere in space...
Re: Refining the authentication process
Hi Felix, I propose to create a new service interface Authenticator, which is implemented by the existing SlingAuthenticator class (both in the o.a.sling.engine bundle). This interface has a requestAuthentication method, which may be used to initiate authentication from within servlets or scripts and have the requestAuthentication method of the appropriate handler be called for the current request. In addition, the sling:authRequestLogin parameter supported by the HTTP Basic authentication handler should actually be handled by the SlingAuthenticator. This enables any client to initiate authentication by just specifying this parameter and have the SlingAuthenticator call the requestAuthentication method of the appropriate handler be called for the request. I agree with your propossal and understand and share the reasons. +1 In the other hand, and I hope this is not off-topic, I still see a little bit contradictory that Sling let having different authentication handlers, but in the other hand, they are all tied to jcr specification (javax.jcr.Credentials type for instance). I understand this draft [1] is in line with this point, reallly?. BR, Juanjo. [1] http://cwiki.apache.org/SLING/add-resourceresolverfactory-service-interface.html
Re: Refining the authentication process
Hi Juanjo, Juan José Vázquez Delgado schrieb: Hi Felix, I propose to create a new service interface Authenticator, which is implemented by the existing SlingAuthenticator class (both in the o.a.sling.engine bundle). This interface has a requestAuthentication method, which may be used to initiate authentication from within servlets or scripts and have the requestAuthentication method of the appropriate handler be called for the current request. In addition, the sling:authRequestLogin parameter supported by the HTTP Basic authentication handler should actually be handled by the SlingAuthenticator. This enables any client to initiate authentication by just specifying this parameter and have the SlingAuthenticator call the requestAuthentication method of the appropriate handler be called for the request. I agree with your propossal and understand and share the reasons. +1 Thanks. In the other hand, and I hope this is not off-topic, I still see a little bit contradictory that Sling let having different authentication handlers, but in the other hand, they are all tied to jcr specification (javax.jcr.Credentials type for instance). I understand this draft [1] is in line with this point, reallly?. It is not really off-topic. Point is that this proposal is not targeted at this end of the line. Yet, I agree, that we have another issue in the AuthenticationInfo class, which is tied into JCR style login. I think we will solve this issue when we tackle the ResourceResolverFactory implementation [2]. Regards Felix [2] http://cwiki.apache.org/SLING/add-resourceresolverfactory-service-interface.html BR, Juanjo. [1] http://cwiki.apache.org/SLING/add-resourceresolverfactory-service-interface.html