IMO, we should integrate authentication and authorizations with MS4j via annotations ( those annotations can only be used when running within C5). Then everyone do not have to rewrite it every time.
WDYT? --Srinath On Thu, Nov 10, 2016 at 11:02 PM, Ishara Cooray <[email protected]> wrote: > Hi Johann, > > Assuming this implementation is for C5, > > Since API Manager REST APIs are written as micro services we thought of > using msf4j security interceptors for securing REST apis. > It uses introspect endpoint to get the authentication/authorization info. > > How the proposed implementation would help in this scenario? > > > Thanks & Regards, > Ishara Cooray > Senior Software Engineer > Mobile : +9477 262 9512 > WSO2, Inc. | http://wso2.com/ > Lean . Enterprise . Middleware > > On Thu, Nov 10, 2016 at 11:40 AM, Nuwan Dias <[email protected]> wrote: > >> Hi Johann, >> >> I think it would help if you can come up with a sequence diagram which >> explains the exact points in the authentication/authorization process and >> what they actually do :). >> >> Although we decide the granularity of our resource permissions, when it >> comes to customer deployments the granularity we define would be too >> coarse-grained for some customers and too fine-grained for some others. >> Basically the carbon permissions strings we define may or may not be >> sufficient. They may want to define their own and configure. And what >> customers have at their end are users and their groups. So what they would >> at the end of the day do is to map their user groups with these resources >> directly or indirectly. Can you explain the steps needed to be performed by >> a customer to define their own carbon permission (assume they require a new >> one) and how they would map their groups to these resources? >> >> When it comes to REST API resources, having /t/tenantdomain is not >> natural. Therefore I don't think we should mandate having the tenant domain >> in the resource URI. Besides, this model is for C5 right? In which case I >> assume there aren't cases where one tenant accesses services of another >> tenant as such? >> >> Thanks, >> NuwanD. >> >> On Thu, Nov 10, 2016 at 9:21 AM, Johann Nallathamby <[email protected]> >> wrote: >> >>> Authentication and authorization are common requirements for Rest APIs. >>> Since SOAP was the common API standard so far in C4, when it comes to Rest >>> APIs, each product has implemented its own authentication and authorization >>> mechanism. In Identity server so far we haven't had a common authentication >>> and authorization module for Rest APIs. SCIM and OAuth2 Token endpoints >>> were the only Rest APIs in IS so far which had built in authentication and >>> authorization. >>> >>> For IS 5.3.0 we added more Rest APIs and needed a common authentication >>> and authorization module which is externalized, extensible and >>> configuration driven for all the authorization requirements we have had so >>> far. >>> >>> The approach we took for authentication is to write a OSGi service and >>> expose a Java API, which takes in a defined object model which will do the >>> authentication and return the result. Behind the service API we have >>> provided an SPI to plug-in authenticators such as Basic Auth, OAuth2, etc. >>> The clients of this API can be a cxf filter, cxf interceptor, servlet >>> filter or tomcat valve. You can use which ever you want depending on your >>> use case. We can use the relevant configuration files for filters, >>> interceptors, valves, etc. to configure the context paths which need >>> authentication for. >>> >>> Currently we have 3 authenticator implementations. >>> 1. Username/Password >>> 2. OAuth2 >>> 3. X509 - >>> Although technically it is possible to authenticate the end user using >>> X509 certificates, by having a certificate per user and authenticating the >>> user using the CN of the certificate, practically we don't use X509 >>> authentication that way. How we use it in practice is, >>> >>> A. Client certificate authentication without username >>> >>> This approach is used when there is no end user based authorization >>> requirements. As long as the client who is sending the request is trusted >>> and valid. E.g. >>> >>> B. Client certificate authentication with username (trusted sub-system) >>> >>> This is required when there are authorization requirements based on end >>> user. Basically we trust the client that it has authenticated the user >>> successfully and IS will only do the authorization for the user. >>> >>> >>> Another two authenticators in the pipeline are "System User" and "Signed >>> JWT" authenticator. "System User" authenticator means having couple of >>> system wide usernames and passwords that is configured in a text file and >>> secured, which client can authenticate with. >>> >>> For authorization we have provided another OSGi service API, which will >>> also takes in a defined object model and returns the authorization result. >>> The authorization rules can be configured in identity.xml as follows. >>> <ResourceAccessControl> >>> <Resource context="/api/identity/*" secured="true" >>> http-method="all"> >>> <Permissions>/permission/admin/login</Permissions> >>> </Resource> >>> <Resource context="/api/test" secured="true" >>> http-method="put,post"> >>> <Permissions>/permission/admin/test</Permissions> >>> </Resource> >>> </ResourceAccessControl> >>> >>> Like with authentication clients of this authorization API can be a CXF >>> filter, CXF interceptor, servlet filter or tomcat valve. >>> >>> In addition to the above there are two more broad authorization >>> requirements which are are yet to implement. >>> >>> 1. Resource access across tenants - >>> >>> We called it "SaaS" mode in previous releases. It was available for >>> certain admin SOAP APIs in IS. However this has come as a generic >>> requirement for all admin APIs. However we faced some difficulties in >>> implementing this for SOAP services because we don't have a standard model >>> to represent the tenant and user which the resource belongs to. >>> >>> For Rest APIs this is possible. We can specify tenant domain as part of >>> the URL. E.g. api/identity/user/t/wso2.com where "wso2.com" is the >>> tenant. >>> >>> 2. "Self access" and "Delegated access" for the same resource >>> >>> Users can access/update their own resources without any authorization by >>> just doing authentication only. This is known as "Self access". >>> One user in a tenant should be able to do actions on another user's >>> behalf. This is known as "Delegated access". This also was supported for >>> certain admin SOAP APIs in previous IS. For this we specify a distinct >>> permission for users to access/update resources of other users. >>> >>> To implement this requirement we need to specify two parameterized >>> permissions in the authorization module. One for "self access" and one for >>> "delegated access". To identify whether the request is a "self access" one >>> or a "delegated access" one, we need to specify the user in the Rest URL. >>> E.g. api/identity/user/t/wso2.com/hr/john where "wso2.com" is the >>> tenant, "hr" is the userstore domain and "john" is the username. >>> >>> If you are going to secure Rest APIs in your product, please check this >>> implementation and see if it satisfies your requirement and give us >>> feedback where it can be improved. >>> >>> [1] https://github.com/wso2-extensions/identity-carbon-auth-rest >>> >>> -- >>> Thanks & Regards, >>> >>> *Johann Dilantha Nallathamby* >>> Technical Lead & Product Lead of WSO2 Identity Server >>> Governance Technologies Team >>> WSO2, Inc. >>> lean.enterprise.middleware >>> >>> Mobile - *+94777776950* >>> Blog - *http://nallaa.wordpress.com <http://nallaa.wordpress.com>* >>> >> >> >> >> -- >> Nuwan Dias >> >> Software Architect - WSO2, Inc. http://wso2.com >> email : [email protected] >> Phone : +94 777 775 729 >> >> _______________________________________________ >> Architecture mailing list >> [email protected] >> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >> >> > > _______________________________________________ > Architecture mailing list > [email protected] > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > -- ============================ Srinath Perera, Ph.D. http://people.apache.org/~hemapani/ http://srinathsview.blogspot.com/
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
