[jboss-jira] [JBoss JIRA] (WFLY-1838) Authorisation descision filtered vs. read-only

[Kabir Khan (JIRA)]

    [ https://issues.jboss.org/browse/WFLY-1838?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12795471#comment-12795471 ] 

Kabir Khan commented on WFLY-1838:
----------------------------------

1) do you mean this? 
{code}
[standalone at localhost:9990 /] /subsystem=datasources/data-source=*:read-resource-description
{
    "outcome" => "success",
    "result" => [
        {
            "address" => [
                ("subsystem" => "datasources"),
                ("data-source" => "ExampleDS")
            ],
            "outcome" => "success",
            "result" => {
                "description" => "A JDBC data-source configuration",
                "access-constraints" => {"application" => {"data-source" => {"type" => "datasources"}}},
                "attributes" => {
--SNIP--
                    "security-domain" => {
                        "type" => STRING,
                        "description" => "Specifies the security domain which defines the javax.security.auth.Subject that are used to distinguish connections in the pool",
                        "expressions-allowed" => true,
                        "nillable" => true,
                        "alternatives" => ["user-name"],
                        "min-length" => 1L,
                        "max-length" => 2147483647L,
                        "access-constraints" => {"sensitive" => {
                            "security-domain-ref" => {"type" => "core"},
                            "data-source-security" => {"type" => "datasources"}
                        }},
                        "access-type" => "read-write",
                        "storage" => "configuration",
                        "restart-required" => "no-services"
                    },
--SNIP--
{code}
If I include access-control=true I see the following under access-control
{code}
                "access-control" => {
                    "default" => {
                        "read-config" => true,
                        "write-config" => true,
                        "read-runtime" => true,
                        "write-runtime" => true,
                        "attributes" => {
--SNIP--
                            "security-domain" => {
                                "read-config" => true,
                                "write-config" => true
                            },
 --SNIP--
{code}
So both read-config and write-config of security-domain are sensitive. For the read-resource I see security-domain filtered as I think it should since it is sensitive.
{code}
[standalone at localhost:9990 /] /subsystem=datasources/data-source=ExampleDS:read-resource(){roles=MONITOR}
{
    "outcome" => "success",
    "result" => {
        "allocation-retry" => undefined,
-- SNIP - all the other attributes here, apart from security domain --
    },
    "response-headers" => {"access-control" => [{
        "absolute-address" => [
            ("subsystem" => "datasources"),
            ("data-source" => "ExampleDS")
        ],
        "relative-address" => [],
        "filtered-attributes" => [
            "user-name",
            "security-domain",
            "password"
        ]
    }]}
}
{code}
It seems to me it works the way it should, the sensitive attribute is filtered for MONITOR. If I do this as super user, security-domain is not filtered. I might be missing something.

2) 
a) If an attribute's access is sensitive it will not appear in either read-resource-description or read-resource.
b) If it is read-config=true it will be filtered in read-resource.
c) If it is write-config=true it could be non-filtered in read-resource, since as far as I know read-config=true is the trigger used for filtering (Brian will need to confirm that part)

So if my assumption for c) holds true, you can not assume write values from if it is filtered in read-resource. It works the other way round, the description decides whether it is writable.

                
> Authorisation descision filtered vs. read-only
> ----------------------------------------------
>
>                 Key: WFLY-1838
>                 URL: https://issues.jboss.org/browse/WFLY-1838
>             Project: WildFly
>          Issue Type: Clarification
>          Components: Domain Management
>            Reporter: Heiko Braun
>            Assignee: Kabir Khan
>
> When I look at datasources for example, I can see a difference between :read-resource-description(access-control=true) and the output of :read-resource(){roles=monitor}.
> The first doesn't contain constraints for "security-domain", but the later indicates them as being filtered (access-control response header).
> First question: Is this a bug?
> Second and more general question: Will all filtered attributes be presented as "read=false" & "write=false"?

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira