Hi All,
On Wed, Apr 20, 2016 at 3:04 PM, Malithi Edirisinghe <[email protected]> wrote: > [moving to dev@] > > On Wed, Apr 20, 2016 at 2:59 PM, Malithi Edirisinghe <[email protected]> > wrote: > >> Hi All, >> >> In STS and PassiveSTS user attributes for the SAML attribute statement >> are retrieved by invoking a call back handler. >> Previously, when building the SAML 1.1 assertion and SAML 2.0 assertion, >> this call back handler was invoked if and only if claims were requested, >> with the STS token request, via */wst:RequestSecurityToken/wst:Claims* >> or */wst:RequestSecurityToken/wst:Claims/@Dialect*. >> >> if (data.getClaimDialect() != null && data.getClaimElem() != null) { >> SAMLStatement attrStatement = >> createSAMLAttributeStatement((SAMLSubject)subject.clone(), data, config); >> statements.add(attrStatement); >> } >> >> Later, with the fixes done to support WS-Trust for Office 365 [1], this >> check has been removed from the rampart only at the SAML 1.1 assertion >> building path, and moved to our call back handler implementation. >> As per Kasun, this has been done since the active STS request initiated >> from Office 365 side does to request claims with the token request, but >> expects claims in the token response. Therefore, he has improved the code >> to lookup for the requested claims configured for the service provider if >> no claims are requested with the token request. This was handled at the >> call back handler. In order to make sure that the call back handler is >> invoked, even though claims are not requested with the token request, >> initial check has been removed. >> >> So now I have below concerns. >> 1. Previously, call back handler was invoked if and only if claims were >> requested. But now, for SAML 1.1 it can be invoked, either claims are >> requested or not. Therefore, call back handler implementations, who >> expected that the requested claims could not be null, should now check if >> requested claims could be null before processing. Unless they may fail at >> runtime. >> >> SInce, the specification does not specifically point on what to be done when no claims requested with the token request and since office 365 expects claims even though claims are not requested with the token request, we have moved the full control of retrieving claims for the call back handler. Otherwise, the rampart it self, limits handling claims when they are not requested with the token request > 2. This fix has been applied only in the SAML 1.1 flow. For consistency, I >> think SAML 2.0 should behave the same way. >> > We will be fixing SAML 2.0 flow, to behave in the same way for consistency. >> Thanks, >> Malithi. >> >> [1] https://wso2.org/jira/browse/IDENTITY-4421 >> >> -- >> >> *Malithi Edirisinghe* >> Senior Software Engineer >> WSO2 Inc. >> >> Mobile : +94 (0) 718176807 >> [email protected] >> > > > > -- > > *Malithi Edirisinghe* > Senior Software Engineer > WSO2 Inc. > > Mobile : +94 (0) 718176807 > [email protected] > -- *Malithi Edirisinghe* Senior Software Engineer WSO2 Inc. Mobile : +94 (0) 718176807 [email protected]
_______________________________________________ Dev mailing list [email protected] http://wso2.org/cgi-bin/mailman/listinfo/dev
